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">N1950=06-0020</td>
  12 </tr>
  13 <tr>
  14 <td align="left">Date:</td>
  15 <td align="left">2006-02-24</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 R41)</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>R41:
  49 2006-02-24 pre-Berlin mailing.
  50 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>.
  51 Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.
  52 Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.
  53 </li>
  54 <li>R40:
  55 2005-12-16 mid-term mailing.
  56 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#535">535</a>.
  57 </li>
  58 <li>R39:
  59 2005-10-14 post-Mont Tremblant mailing.
  60 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>.
  61 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.
  62 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#497">497</a> from Review to Ready.
  63 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#514">514</a> from New to Open.
  64 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#519">519</a> from New to Ready.
  65 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
  66 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
  67 </li>
  68 <li>R38:
  69 2005-07-03 pre-Mont Tremblant mailing.
  70 Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
  71 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>
  72 </li>
  73 <li>R37:
  74 2005-06 mid-term mailing.
  75 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>.
  76 </li>
  77 <li>R36:
  78 2005-04 post-Lillehammer mailing. All issues in "ready" status except
  79 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
  80 previously in "DR" status were moved to "WP".
  81 </li>
  82 <li>R35:
  83 2005-03 pre-Lillehammer mailing.
  84 </li>
  85 <li>R34:
  86 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>.
  87 </li>
  88 <li>R33:
  89 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
  90 </li>
  91 <li>R32:
  92 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
  93 new issues received after the 2004-07 mailing.  Added
  94 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>.
  95 </li>
  96 <li>R31:
  97 2004-07 mid-term mailing: reflects new proposed resolutions and
  98 new issues received after the post-Sydney mailing.  Added
  99 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-active.html#478">478</a>.
 100 </li>
 101 <li>R30:
 102 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 103 Voted all "Ready" issues from R29 into the working paper.
 104 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>.
 105 </li>
 106 <li>R29:
 107 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>.
 108 </li>
 109 <li>R28:
 110 Post-Kona mailing: reflects decisions made at the Kona meeting.
 111 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>.
 112 </li>
 113 <li>R27:
 114 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>.
 115 </li>
 116 <li>R26:
 117 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
 118 All issues in Ready status were voted into DR status.  All issues in
 119 DR status were voted into WP status.
 120 </li>
 121 <li>R25:
 122 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>.
 123 </li>
 124 <li>R24:
 125 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
 126 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
 127 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
 128 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
 129 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
 130 </li>
 131 <li>R23:
 132 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>.
 133 Moved issues in the TC to TC status.
 134 </li>
 135 <li>R22:
 136 Post-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>.
 137 </li>
 138 <li>R21:
 139 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>.
 140 </li>
 141 <li>R20:
 142 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 143 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
 144 <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
 145 not discussed at the meeting.
 146
 147 All Ready issues were moved to DR status, with the exception of issues
 148 <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>.
 149
 150 Noteworthy issues discussed at Redmond include
 151 <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>,
 152 <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>.
 153 </li>
 154 <li>R19:
 155 Pre-Redmond mailing.  Added new issues
 156 <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>.
 157 </li>
 158 <li>R18:
 159 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
 160 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
 161 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>.
 162
 163 Changed status of issues
 164 <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>
 165 <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>
 166 <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>
 167 <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>
 168 <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>
 169 <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>
 170 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
 171 to DR.
 172
 173 Changed status of issues
 174 <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>
 175 <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>
 176 <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>
 177 <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>
 178 <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>
 179 <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>
 180 <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>
 181 <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>
 182 <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>
 183 to Ready.
 184
 185 Closed issues
 186 <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>
 187 <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>
 188 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
 189 as NAD.
 190
 191 </li>
 192 <li>R17:
 193 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 194 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>.
 195 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>.
 196 </li>
 197 <li>R16:
 198 post-Toronto mailing; reflects actions taken in Toronto. Added new
 199 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
 200 <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>,
 201 <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>,
 202 <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>,
 203 <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>,
 204 <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>,
 205 <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>,
 206 <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>,
 207 <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>,
 208 <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>,
 209 <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>,
 210 <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>,
 211 <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>,
 212 <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
 213 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
 214 <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
 215 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
 216 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
 217 the bug in enough places.
 218 </li>
 219 <li>R15:
 220 pre-Toronto mailing. Added issues
 221 <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
 222 changes so that we pass Weblint tests.
 223 </li>
 224 <li>R14:
 225 post-Tokyo II mailing; reflects committee actions taken in
 226 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)
 227 </li>
 228 <li>R13:
 229 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>.
 230 </li>
 231 <li>R12:
 232 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
 233 <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
 234 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
 235 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
 236 </li>
 237 <li>R11:
 238 post-Kona mailing: Updated to reflect LWG and full committee actions
 239 in Kona (99-0048/N1224). Note changed resolution of issues
 240 <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>
 241 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
 242 "closed" documents.  Changed the proposed resolution of issue
 243 <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
 244 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
 245 </li>
 246 <li>R10:
 247 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 248 <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>,
 249 <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
 250 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 251 </li>
 252 <li>R9:
 253 pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
 254 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
 255 "closed" documents. (99-0030/N1206, 25 Aug 99)
 256 </li>
 257 <li>R8:
 258 post-Dublin mailing. Updated to reflect LWG and full committee actions
 259 in Dublin. (99-0016/N1193, 21 Apr 99)
 260 </li>
 261 <li>R7:
 262 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>,
 263 <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>,
 264 <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>,
 265 <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)
 266 </li>
 267 <li>R6:
 268 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>,
 269 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 270 </li>
 271 <li>R5:
 272 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
 273 <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
 274 for making list public. (30 Dec 98)
 275 </li>
 276 <li>R4:
 277 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
 278 <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
 279 issues corrected. (22 Oct 98)
 280 </li>
 281 <li>R3:
 282 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>
 283 added, many issues updated to reflect LWG consensus (12 Oct 98)
 284 </li>
 285 <li>R2:
 286 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,
 287 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
 288 </li>
 289 <li>R1:
 290 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
 291 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
 292 </li>
 293 </ul>
 294 <h2>Defect Reports</h2>
 295 <hr>
 296 <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>
 297 <p>The change specified in the proposed resolution below did not make
 298 it into the Standard. This change was accepted in principle at the
 299 London meeting, and the exact wording below was accepted at the
 300 Morristown meeting.</p>
 301 <p><b>Proposed resolution:</b></p>
 302 <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
 303 from:</p>
 304
 305 <blockquote>
 306   <p>It is unspecified whether a name from the Standard C library
 307   declared with external linkage has either extern "C" or
 308   extern "C++" linkage.</p>
 309 </blockquote>
 310
 311 <p>to:</p>
 312
 313 <blockquote>
 314   <p>Whether a name from the Standard C library declared with external
 315   linkage has extern "C" or extern "C++" linkage
 316   is implementation defined. It is recommended that an implementation
 317   use extern "C++" linkage for this purpose.</p>
 318 </blockquote>
 319 <hr>
 320 <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.support.start.term"> [lib.support.start.term]</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>
 321 <p>We appear not to have covered all the possibilities of
 322  exit processing with respect to
 323 atexit registration. <br>
 324 <br>
 325 Example 1: (C and C++)</p>
 326
 327 <pre>    #include &lt;stdlib.h&gt;
 328     void f1() { }
 329     void f2() { atexit(f1); }
 330
 331     int main()
 332     {
 333         atexit(f2); // the only use of f2
 334         return 0; // for C compatibility
 335     }</pre>
 336
 337 <p>At program exit, f2 gets called due to its registration in
 338 main. Running f2 causes f1 to be newly registered during the exit
 339 processing. Is this a valid program? If so, what are its
 340 semantics?</p>
 341
 342 <p>
 343 Interestingly, neither the C standard, nor the C++ draft standard nor
 344 the forthcoming C9X Committee Draft says directly whether you can
 345 register a function with atexit during exit processing.</p>
 346
 347 <p>
 348 All 3 standards say that functions are run in reverse order of their
 349 registration. Since f1 is registered last, it ought to be run first,
 350 but by the time it is registered, it is too late to be first.</p>
 351
 352 <p>If the program is valid, the standards are self-contradictory about
 353 its semantics.</p>
 354
 355 <p>Example 2: (C++ only)</p>
 356
 357 <pre>
 358     void F() { static T t; } // type T has a destructor
 359
 360     int main()
 361     {
 362         atexit(F); // the only use of F
 363     }
 364 </pre>
 365
 366 <p>Function F registered with atexit has a local static variable t,
 367 and F is called for the first time during exit processing. A local
 368 static object is initialized the first time control flow passes
 369 through its definition, and all static objects are destroyed during
 370 exit processing. Is the code valid? If so, what are its semantics?</p>
 371
 372 <p>
 373 Section 18.3 "Start and termination" says that if a function
 374 F is registered with atexit before a static object t is initialized, F
 375 will not be called until after t's destructor completes.</p>
 376
 377 <p>
 378 In example 2, function F is registered with atexit before its local
 379 static object O could possibly be initialized. On that basis, it must
 380 not be called by exit processing until after O's destructor
 381 completes. But the destructor cannot be run until after F is called,
 382 since otherwise the object could not be constructed in the first
 383 place.</p>
 384
 385 <p>If the program is valid, the standard is self-contradictory about
 386 its semantics.</p>
 387
 388 <p>I plan to submit Example 1 as a public comment on the C9X CD, with
 389 a recommendation that the results be undefined. (Alternative: make it
 390 unspecified. I don't think it is worthwhile to specify the case where
 391 f1 itself registers additional functions, each of which registers
 392 still more functions.)</p>
 393
 394 <p>I think we should resolve the situation in the whatever way the C
 395 committee decides. </p>
 396
 397 <p>For Example 2, I recommend we declare the results undefined.</p>
 398
 399 <p><i>[See reflector message lib-6500 for further discussion.]</i></p>
 400
 401 <p><b>Proposed resolution:</b></p>
 402 <p>Change section 18.3/8 from:</p>
 403 <blockquote>
 404   First, objects with static storage duration are destroyed and
 405   functions registered by calling atexit are called. Objects with
 406   static storage duration are destroyed in the reverse order of the
 407   completion of their constructor.  (Automatic objects are not
 408   destroyed as a result of calling exit().) Functions registered with
 409   atexit are called in the reverse order of their registration.  A
 410   function registered with atexit before an object obj1 of static
 411   storage duration is initialized will not be called until obj1's
 412   destruction has completed. A function registered with atexit after
 413   an object obj2 of static storage duration is initialized will be
 414   called before obj2's destruction starts.
 415 </blockquote>
 416 <p>to:</p>
 417 <blockquote>
 418   First, objects with static storage duration are destroyed and
 419   functions registered by calling atexit are called. Non-local objects
 420   with static storage duration are destroyed in the reverse order of
 421   the completion of their constructor. (Automatic objects are not
 422   destroyed as a result of calling exit().) Functions registered with
 423   atexit are called in the reverse order of their registration, except
 424   that a function is called after any previously registered functions
 425   that had already been called at the time it was registered. A
 426   function registered with atexit before a non-local object obj1 of
 427   static storage duration is initialized will not be called until
 428   obj1's destruction has completed. A function registered with atexit
 429   after a non-local object obj2 of static storage duration is
 430   initialized will be called before obj2's destruction starts. A local
 431   static object obj3 is destroyed at the same time it would be if a
 432   function calling the obj3 destructor were registered with atexit at
 433   the completion of the obj3 constructor.
 434 </blockquote>
 435 <p><b>Rationale:</b></p>
 436 <p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
 437 supporting to the proposed resolution.</p>
 438 <hr>
 439 <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>
 440 <p>At the very end of the basic_string class definition is the signature: int
 441 compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
 442 following text this is defined as: returns
 443 basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
 444 basic_string&lt;charT,traits,Allocator&gt;(s,n2); </p>
 445
 446 <p>Since the constructor basic_string(const charT* s, size_type n, const Allocator&amp; a
 447 = Allocator()) clearly requires that s != NULL and n &lt; npos and further states that it
 448 throws length_error if n == npos, it appears the compare() signature above should always
 449 throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
 450 null terminated character array. </p>
 451
 452 <p>This appears to be a typo since the obvious intent is to allow either the call above or
 453 something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
 454
 455 <p>This would imply that what was really intended was two signatures int compare(size_type
 456 pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
 457 charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
 458 <p><b>Proposed resolution:</b></p>
 459 <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>
 460 (at the very end of the basic_string synopsis) which reads:</p>
 461
 462 <blockquote>
 463   <p><tt>int compare(size_type pos1, size_type n1,<br>
 464   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
 465   size_type n2 = npos) const;</tt></p>
 466 </blockquote>
 467
 468 <p>with:</p>
 469
 470 <blockquote>
 471   <p><tt>int compare(size_type pos1, size_type n1,<br>
 472   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s) const;<br>
 473   int compare(size_type pos1, size_type n1,<br>
 474   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
 475   size_type n2) const;</tt></p>
 476 </blockquote>
 477
 478 <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>
 479 paragraphs 5 and 6 which read:</p>
 480
 481 <blockquote>
 482   <p><tt>int compare(size_type pos, size_type n1,<br>
 483   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; charT * s, size_type n2
 484   = npos) const;<br>
 485   </tt>Returns:<tt><br>
 486   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 487   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 488   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
 489 </blockquote>
 490
 491 <p>with:</p>
 492
 493 <blockquote>
 494   <p><tt>int compare(size_type pos, size_type n1,<br>
 495   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s) const;<br>
 496   </tt>Returns:<tt><br>
 497   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 498   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 499   basic_string&lt;charT,traits,Allocator&gt;( s ))<br>
 500   <br>
 501   int compare(size_type pos, size_type n1,<br>
 502   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s,
 503   size_type n2) const;<br>
 504   </tt>Returns:<tt><br>
 505   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 506   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 507   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
 508 </blockquote>
 509
 510 <p>Editors please note that in addition to splitting the signature, the third argument
 511 becomes const, matching the existing synopsis.</p>
 512 <p><b>Rationale:</b></p>
 513 <p>While the LWG dislikes adding signatures, this is a clear defect in
 514 the Standard which must be fixed.&nbsp; The same problem was also
 515 identified in issues 7 (item 5) and 87.</p>
 516 <hr>
 517 <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>
 518 <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
 519 &lt;class InputIterator&gt; insert(iterator, InputIterator,
 520 InputIterator) makes no sense. It refers to a member function that
 521 doesn't exist. It also talks about the return value of a void
 522 function. </p>
 523
 524 <p>(2) Several versions of basic_string::replace don't appear in the
 525 class synopsis. </p>
 526
 527 <p>(3) basic_string::push_back appears in the synopsis, but is never
 528 described elsewhere.  In the synopsis its argument is const charT,
 529 which doesn't makes much sense; it should probably be charT, or
 530 possible const charT&amp;. </p>
 531
 532 <p>(4) basic_string::pop_back is missing. </p>
 533
 534 <p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
 535 = npos) make no sense. First, it's const charT* in the synopsis and
 536 charT* in the description. Second, given what it says in RETURNS,
 537 leaving out the final argument will always result in an exception
 538 getting thrown. This is paragraphs 5 and 6 of
 539 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>
 540
 541 <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>,
 542 there's a note for X::move(s, p, n). It says "Copies correctly
 543 even where p is in [s, s+n)". This is correct as far as it goes,
 544 but it doesn't go far enough; it should also guarantee that the copy
 545 is correct even where s in in [p, p+n). These are two orthogonal
 546 guarantees, and neither one follows from the other. Both guarantees
 547 are necessary if X::move is supposed to have the same sort of
 548 semantics as memmove (which was clearly the intent), and both
 549 guarantees are necessary if X::move is actually supposed to be
 550 useful. </p>
 551 <p><b>Proposed resolution:</b></p>
 552 <p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
 553 <br>
 554 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
 555 <br>
 556 ITEM 2:&nbsp; Not a defect; the Standard is clear.. There are ten versions of replace() in
 557 the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
 558 <br>
 559 ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
 560 [lib.basic.string]) from:</p>
 561
 562 <p>&nbsp;&nbsp;&nbsp;&nbsp; void push_back(const charT)<br>
 563 <br>
 564 to<br>
 565 <br>
 566 &nbsp;&nbsp;&nbsp;&nbsp; void push_back(charT)<br>
 567 <br>
 568 Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
 569 <br>
 570 &nbsp;&nbsp;&nbsp; void basic_string::push_back(charT c);<br>
 571 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to append(static_cast&lt;size_type&gt;(1), c);<br>
 572 <br>
 573 ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
 574 <br>
 575 ITEM 5: Duplicate; see issue 5 (and 87).<br>
 576 <br>
 577 ITEM 6: In table 37, Replace:<br>
 578 <br>
 579 &nbsp;&nbsp;&nbsp; "Copies correctly even where p is in [s, s+n)."<br>
 580 <br>
 581 with:<br>
 582 <br>
 583 &nbsp;&nbsp;&nbsp;&nbsp; "Copies correctly even where the ranges [p, p+n) and [s,
 584 s+n) overlap."</p>
 585 <hr>
 586 <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>
 587 <p>It appears there's an important guarantee missing from clause
 588 22. We're told that invoking locale::global(L) sets the C locale if L
 589 has a name. However, we're not told whether or not invoking
 590 setlocale(s) sets the global C++ locale. </p>
 591
 592 <p>The intent, I think, is that it should not, but I can't find any
 593 such words anywhere. </p>
 594 <p><b>Proposed resolution:</b></p>
 595 <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>,
 596 paragraph 2:&nbsp; </p>
 597
 598 <blockquote>
 599   <p>No library function other than <tt>locale::global()</tt> shall affect
 600   the value returned by <tt>locale()</tt>. </p>
 601
 602 </blockquote>
 603 <hr>
 604 <a name="9"><h3>9.&nbsp;Operator new(0) calls should not yield the same pointer</h3></a><p><b>Section:</b>&nbsp;18.4.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>
 605 <p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
 606 section 3.7.3.1 of CD2 seems to allow for the possibility that all
 607 calls to operator new(0) yield the same pointer, an implementation
 608 technique specifically prohibited by ARM 5.3.3.Was this prohibition
 609 really lifted? Does the FDIS agree with CD2 in the regard? [Issues
 610 list maintainer's note: the IS is the same.]</p>
 611 <p><b>Proposed resolution:</b></p>
 612 <p>Change the last paragraph of 3.7.3 from:</p>
 613 <blockquote>
 614   <p>Any allocation and/or deallocation functions defined in a C++ program shall
 615   conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
 616 </blockquote>
 617 <p>to:</p>
 618 <blockquote>
 619   <p>Any allocation and/or deallocation functions defined in a C++ program,
 620   including the default versions in the library, shall conform to the semantics
 621   specified in 3.7.3.1 and 3.7.3.2.</p>
 622 </blockquote>
 623 <p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
 624 <blockquote>
 625   <p>If the size of the space requested is zero, the value returned shall not be
 626   a null pointer value (4.10).</p>
 627 </blockquote>
 628 <p>to:</p>
 629 <blockquote>
 630   <p>Even if the size of the space requested is zero, the request can fail. If
 631   the request succeeds, the value returned shall be a non-null pointer value
 632   (4.10) p0 different from any previously returned value p1, unless that value
 633   p1 was since passed to an operator delete.</p>
 634 </blockquote>
 635 <p>5.3.4/7 currently reads:</p>
 636 <blockquote>
 637   <p>When the value of the expression in a direct-new-declarator is zero, the
 638   allocation function is called to allocate an array with no elements. The
 639   pointer returned by the new-expression is non-null. [Note: If the library
 640   allocation function is called, the pointer returned is distinct from the
 641   pointer to any other object.]</p>
 642 </blockquote>
 643 <p>Retain the first sentence, and delete the remainder.</p>
 644 <p>18.4.1 currently has no text. Add the following:</p>
 645 <blockquote>
 646   <p>Except where otherwise specified, the provisions of 3.7.3 apply to the
 647   library versions of operator new and operator delete.</p>
 648 </blockquote>
 649 <p>To 18.4.1.3, add the following text:</p>
 650 <blockquote>
 651   <p>The provisions of 3.7.3 do not apply to these reserved placement forms of
 652   operator new and operator delete.</p>
 653 </blockquote>
 654 <p><b>Rationale:</b></p>
 655 <p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
 656 supporting to the proposed resolution.</p>
 657 <hr>
 658 <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>
 659 <p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is
 660 not documented in 23.3.5.2. </p>
 661
 662 <p>(2) The class synopsis only gives a single signature for bitset&lt;&gt;::operator[],
 663 reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
 664 on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
 665
 666 <p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
 667 trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
 668 go in the Effects clause.</p>
 669 <p><b>Proposed resolution:</b></p>
 670 <p>ITEMS 1 AND 2:<br>
 671 <br>
 672 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>),
 673 replace the member function <br>
 674 <br>
 675 <tt>&nbsp;&nbsp;&nbsp; reference operator[](size_t pos);<br>
 676 </tt><br>
 677 with the two member functions<br>
 678 <br>
 679 <tt>&nbsp;&nbsp;&nbsp; bool operator[](size_t pos) const; <br>
 680 &nbsp;&nbsp;&nbsp; reference operator[](size_t pos); <br>
 681 </tt><br>
 682 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>,
 683 immediately after paragraph 45:</p>
 684
 685 <blockquote>
 686   <p><tt>bool operator[](size_t pos) const;</tt><br>
 687   Requires: pos is valid<br>
 688   Throws: nothing<br>
 689   Returns: <tt>test(pos)</tt><br>
 690   <br>
 691   <tt>bitset&lt;N&gt;::reference operator[](size_t pos);</tt> <br>
 692   Requires: pos is valid<br>
 693   Throws: nothing<br>
 694   Returns: An object of type <tt>bitset&lt;N&gt;::reference</tt> such that <tt>(*this)[pos]
 695   == this-&gt;test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this-&gt;set(pos,
 696   val);</tt></p>
 697 </blockquote>
 698 <p><b>Rationale:</b></p>
 699 <p>The LWG believes Item 3 is not a defect. "Formatted
 700 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>.
 701 </p>
 702 <hr>
 703 <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>
 704 <p>In 27.6.1.2.3, there is a reference to "eos", which is
 705 the only one in the whole draft (at least using Acrobat search), so
 706 it's undefined. </p>
 707 <p><b>Proposed resolution:</b></p>
 708 <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
 709 "charT()"</p>
 710 <hr>
 711 <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>
 712 <p>locale::combine is the only member function of locale (other than constructors and
 713 destructor) that is not const. There is no reason for it not to be const, and good reasons
 714 why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
 715 paragraph 6: "An instance of a locale is immutable." </p>
 716
 717 <p>History: this member function originally was a constructor. it happened that the
 718 interface it specified had no corresponding language syntax, so it was changed to a member
 719 function. As constructors are never const, there was no "const" in the interface
 720 which was transformed into member "combine". It should have been added at that
 721 time, but the omission was not noticed. </p>
 722 <p><b>Proposed resolution:</b></p>
 723 <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
 724 "const" to the declaration of member combine: </p>
 725 <blockquote>
 726   <pre>template &lt;class Facet&gt; locale combine(const locale&amp; other) const; </pre>
 727 </blockquote>
 728 <hr>
 729 <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>
 730 <p>locale::name() is described as returning a string that can be passed to a locale
 731 constructor, but there is no matching constructor. </p>
 732 <p><b>Proposed resolution:</b></p>
 733 <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
 734 "<tt>locale(name())</tt>" with
 735 "<tt>locale(name().c_str())</tt>".
 736 </p>
 737 <hr>
 738 <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.ctype.byname.special"> [lib.locale.ctype.byname.special]</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>
 739 <p>The new virtual members ctype_byname&lt;char&gt;::do_widen and do_narrow did not get
 740 edited in properly. Instead, the member do_widen appears four times, with wrong argument
 741 lists. </p>
 742 <p><b>Proposed resolution:</b></p>
 743 <p>The correct declarations for the overloaded members
 744 <tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
 745 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>
 746 <hr>
 747 <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>
 748 <p>This section describes the process of parsing a text boolean value from the input
 749 stream. It does not say it recognizes either of the sequences "true" or
 750 "false" and returns the corresponding bool value; instead, it says it recognizes
 751 only one of those sequences, and chooses which according to the received value of a
 752 reference argument intended for returning the result, and reports an error if the other
 753 sequence is found. (!) Furthermore, it claims to get the names from the ctype&lt;&gt;
 754 facet rather than the numpunct&lt;&gt; facet, and it examines the "boolalpha"
 755 flag wrongly; it doesn't define the value "loc"; and finally, it computes
 756 wrongly whether to use numeric or "alpha" parsing.<br>
 757 <br>
 758 I believe the correct algorithm is "as if": </p>
 759
 760 <pre>  // in, err, val, and str are arguments.
 761   err = 0;
 762   const numpunct&lt;charT&gt;&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(str.getloc());
 763   const string_type t = np.truename(), f = np.falsename();
 764   bool tm = true, fm = true;
 765   size_t pos = 0;
 766   while (tm &amp;&amp; pos &lt; t.size() || fm &amp;&amp; pos &lt; f.size()) {
 767     if (in == end) { err = str.eofbit; }
 768     bool matched = false;
 769     if (tm &amp;&amp; pos &lt; t.size()) {
 770       if (!err &amp;&amp; t[pos] == *in) matched = true;
 771       else tm = false;
 772     }
 773     if (fm &amp;&amp; pos &lt; f.size()) {
 774       if (!err &amp;&amp; f[pos] == *in) matched = true;
 775       else fm = false;
 776     }
 777     if (matched) { ++in; ++pos; }
 778     if (pos &gt; t.size()) tm = false;
 779     if (pos &gt; f.size()) fm = false;
 780   }
 781   if (tm == fm || pos == 0) { err |= str.failbit; }
 782   else                      { val = tm; }
 783   return in;</pre>
 784
 785 <p>Notice this works reasonably when the candidate strings are both empty, or equal, or
 786 when one is a substring of the other. The proposed text below captures the logic of the
 787 code above.</p>
 788 <p><b>Proposed resolution:</b></p>
 789 <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,
 790 change "&amp;&amp;" to "&amp;".</p>
 791
 792 <p>Then, replace paragraphs 15 and 16 as follows:</p>
 793
 794 <blockquote>
 795
 796   <p>Otherwise target sequences are determined "as if" by
 797   calling the members <tt>falsename()</tt> and
 798   <tt>truename()</tt> of the facet obtained by
 799   <tt>use_facet&lt;numpunct&lt;charT&gt;&nbsp;&gt;(str.getloc())</tt>.
 800   Successive characters in the range <tt>[in,end)</tt> (see
 801   [lib.sequence.reqmts]) are obtained and matched against
 802   corresponding positions in the target sequences only as necessary to
 803   identify a unique match. The input iterator <tt>in</tt> is
 804   compared to <tt>end</tt> only when necessary to obtain a
 805   character. If and only if a target sequence is uniquely matched,
 806   <tt>val</tt> is set to the corresponding value.</p>
 807
 808 </blockquote>
 809
 810 <blockquote>
 811   <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
 812   successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
 813   <tt>str.eofbit</tt> if, when seeking another character to match, it is found that
 814   <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
 815   <tt>(str.failbit|str.eofbit)</tt>if
 816   the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
 817   <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
 818   <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
 819   <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
 820   <tt>true</tt>:"1"
 821   and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
 822   and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
 823   <tt>err==str.failbit</tt>. --end example]</p>
 824 </blockquote>
 825 <hr>
 826 <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>
 827 <p>In the list of num_get&lt;&gt; non-virtual members on page 22-23, the member
 828 that parses bool values was omitted from the list of definitions of non-virtual
 829 members, though it is listed in the class definition and the corresponding
 830 virtual is listed everywhere appropriate. </p>
 831 <p><b>Proposed resolution:</b></p>
 832 <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>
 833 another get member for bool&amp;, copied from the entry in
 834 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>
 835 <hr>
 836 <a name="19"><h3>19.&nbsp;"Noconv" definition too vague</h3></a><p><b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.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>
 837 <p>
 838 In the definitions of codecvt&lt;&gt;::do_out and do_in, they are
 839 specified to return noconv if "no conversion is
 840 needed". This definition is too vague, and does not say
 841 normatively what is done with the buffers.
 842 </p>
 843 <p><b>Proposed resolution:</b></p>
 844 <p>
 845 Change the entry for noconv in the table under paragraph 4 in section
 846 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> to read:
 847 </p>
 848 <blockquote>
 849   <p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
 850   and input sequence is identical to converted sequence.</p>
 851 </blockquote>
 852 <p>Change the Note in paragraph 2 to normative text as follows:</p>
 853 <blockquote>
 854   <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
 855   same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
 856   <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
 857   unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
 858 </blockquote>
 859 <hr>
 860 <a name="20"><h3>20.&nbsp;Thousands_sep returns wrong type</h3></a><p><b>Section:</b>&nbsp;22.2.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 861 <p>The synopsis for numpunct&lt;&gt;::do_thousands_sep, and the
 862 definition of numpunct&lt;&gt;::thousands_sep which calls it, specify
 863 that it returns a value of type char_type. Here it is erroneously
 864 described as returning a "string_type". </p>
 865 <p><b>Proposed resolution:</b></p>
 866 <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
 867 "string_type" to "char_type". </p>
 868 <hr>
 869 <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>
 870 <p>In the second table in the section, captioned "Required
 871 instantiations", the instantiations for codecvt_byname&lt;&gt;
 872 have been omitted. These are necessary to allow users to construct a
 873 locale by name from facets. </p>
 874 <p><b>Proposed resolution:</b></p>
 875 <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
 876 "Required instantiations", in the category "ctype"
 877 the lines </p>
 878
 879 <blockquote>
 880   <pre>codecvt_byname&lt;char,char,mbstate_t&gt;,
 881 codecvt_byname&lt;wchar_t,char,mbstate_t&gt; </pre>
 882 </blockquote>
 883 <hr>
 884 <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>
 885 <p>The description of basic_istream&lt;&gt;::open leaves unanswered questions about how it
 886 responds to or changes flags in the error status for the stream. A strict reading
 887 indicates that it ignores the bits and does not change them, which confuses users who do
 888 not expect eofbit and failbit to remain set after a successful open. There are three
 889 reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
 890 and eofbit on call to open(). </p>
 891 <p><b>Proposed resolution:</b></p>
 892 <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:
 893 </p>
 894
 895 <blockquote>
 896   <p>A successful open does not change the error state.</p>
 897 </blockquote>
 898 <p><b>Rationale:</b></p>
 899 <p>This may seem surprising to some users, but it's just an instance
 900 of a general rule: error flags are never cleared by the
 901 implementation. The only way error flags are are ever cleared is if
 902 the user explicitly clears them by hand.</p>
 903
 904 <p>The LWG believed that preserving this general rule was
 905 important enough so that an exception shouldn't be made just for this
 906 one case.  The resolution of this issue clarifies what the LWG
 907 believes to have been the original intent.</p>
 908
 909 <hr>
 910 <a name="24"><h3>24.&nbsp;"do_convert" doesn't exist</h3></a><p><b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.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>
 911 <p>The description of codecvt&lt;&gt;::do_out and do_in mentions a
 912 symbol "do_convert" which is not defined in the
 913 standard. This is a leftover from an edit, and should be "do_in
 914 and do_out". </p>
 915 <p><b>Proposed resolution:</b></p>
 916 <p>In 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>, paragraph 3, change
 917 "do_convert" to "do_in or do_out". Also, in 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, change "do_convert()" to "do_in
 918 or do_out". </p>
 919 <hr>
 920 <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>
 921 <p>In the description of operator&lt;&lt; applied to strings, the standard says that uses
 922 the smaller of os.width() and str.size(), to pad "as described in stage 3"
 923 elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
 924 <p><b>Proposed resolution:</b></p>
 925 <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>
 926 <br>
 927 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
 928 ..."<br>
 929 <br>
 930 to: <br>
 931 <br>
 932 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
 933 ..."</p>
 934 <hr>
 935 <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>
 936 <p>In paragraph 6, the code in the example: </p>
 937
 938 <pre>  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
 939   basic_istream&lt;charT,traits&gt;::sentry(
 940            basic_istream&lt;charT,traits&gt;&amp; is, bool noskipws = false) {
 941       ...
 942       int_type c;
 943       typedef ctype&lt;charT&gt; ctype_type;
 944       const ctype_type&amp; ctype = use_facet&lt;ctype_type&gt;(is.getloc());
 945       while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
 946         if (ctype.is(ctype.space,c)==0) {
 947           is.rdbuf()-&gt;sputbackc (c);
 948           break;
 949         }
 950       }
 951       ...
 952    }</pre>
 953
 954 <p>fails to demonstrate correct use of the facilities described. In
 955 particular, it fails to use traits operators, and specifies incorrect
 956 semantics. (E.g. it specifies skipping over the first character in the
 957 sequence without examining it.) </p>
 958 <p><b>Proposed resolution:</b></p>
 959 <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>
 960 paragraph 6.</p>
 961 <p><b>Rationale:</b></p>
 962 <p>The originally proposed replacement code for the example was not
 963 correct. The LWG tried in Kona and again in Tokyo to correct it
 964 without success. In Tokyo, an implementor reported that actual working
 965 code ran over one page in length and was quite complicated. The LWG
 966 decided that it would be counter-productive to include such a lengthy
 967 example, which might well still contain errors.</p>
 968 <hr>
 969 <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>
 970 <p>The string::erase(iterator first, iterator last) is specified to return an element one
 971 place beyond the next element after the last one erased. E.g. for the string
 972 "abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
 973 while 'd' has not been erased. </p>
 974 <p><b>Proposed resolution:</b></p>
 975 <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>
 976
 977 <blockquote>
 978   <p>Returns: an iterator which points to the element immediately following _last_ prior to
 979   the element being erased. </p>
 980 </blockquote>
 981
 982 <p>to read </p>
 983
 984 <blockquote>
 985   <p>Returns: an iterator which points to the element pointed to by _last_ prior to the
 986   other elements being erased. </p>
 987 </blockquote>
 988 <hr>
 989 <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>
 990 <p>The description of the vector form of ctype&lt;char&gt;::is can be interpreted to mean
 991 something very different from what was intended. Paragraph 4 says </p>
 992
 993 <blockquote>
 994   <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
 995   table()[(unsigned char)*p]. </p>
 996 </blockquote>
 997
 998 <p>This is intended to copy the value indexed from table()[] into the place identified in
 999 vec[]. </p>
1000 <p><b>Proposed resolution:</b></p>
1001 <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>
1002
1003 <blockquote>
1004   <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
1005   the value table()[(unsigned char)*p]. </p>
1006 </blockquote>
1007 <hr>
1008 <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>
1009 <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
1010 a function ios_base::init, which is not defined. Probably they mean
1011 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>,
1012 paragraph 3. </p>
1013 <p><b>Proposed resolution:</b></p>
1014 <p>[R12: modified to include paragraph 5.]</p>
1015
1016 <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>
1017
1018 <blockquote>
1019   <p>ios_base::init </p>
1020 </blockquote>
1021
1022 <p>to </p>
1023
1024 <blockquote>
1025   <p>basic_ios&lt;char&gt;::init </p>
1026 </blockquote>
1027
1028 <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
1029 should read </p>
1030
1031 <blockquote>
1032   <p>basic_ios&lt;wchar_t&gt;::init </p>
1033 </blockquote>
1034 <hr>
1035 <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>
1036 <p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in &lt;cctype&gt;,
1037 where they are in fact defined elsewhere to appear in &lt;clocale&gt;. </p>
1038 <p><b>Proposed resolution:</b></p>
1039 <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
1040 "&lt;cctype&gt;" to read "&lt;clocale&gt;". </p>
1041 <hr>
1042 <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>
1043 <p>Paragraph 6, says "An instance of <tt>locale</tt> is
1044 <i>immutable</i>; once a facet reference is obtained from it,
1045 ...". This has caused some confusion, because locale variables
1046 are manifestly assignable. </p>
1047 <p><b>Proposed resolution:</b></p>
1048 <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>
1049
1050 <blockquote>
1051   <p>An instance of <tt>locale</tt> is immutable; once a facet
1052   reference is obtained from it, that reference remains usable as long
1053   as the locale value itself exists.</p>
1054 </blockquote>
1055
1056 <p>with</p>
1057
1058 <blockquote>
1059   <p>Once a facet reference is obtained from a locale object by
1060   calling use_facet&lt;&gt;, that reference remains usable, and the
1061   results from member functions of it may be cached and re-used, as
1062   long as some locale object refers to that facet.</p>
1063 </blockquote>
1064 <hr>
1065 <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>
1066 <p>The description of the required state before calling virtual member
1067 basic_streambuf&lt;&gt;::pbackfail requirements is inconsistent with the conditions
1068 described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
1069 Specifically, the latter says it calls pbackfail if: </p>
1070
1071 <p>&nbsp;&nbsp;&nbsp; traits::eq(c,gptr()[-1]) is false </p>
1072
1073 <p>where pbackfail claims to require: </p>
1074
1075 <p>&nbsp;&nbsp;&nbsp; traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
1076
1077 <p>It appears that the pbackfail description is wrong. </p>
1078 <p><b>Proposed resolution:</b></p>
1079 <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>
1080
1081 <blockquote>
1082   <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
1083 </blockquote>
1084
1085 <p>to </p>
1086
1087 <blockquote>
1088   <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
1089   </p>
1090 </blockquote>
1091 <p><b>Rationale:</b></p>
1092 <p>Note deliberate reordering of arguments for clarity in addition to the correction of
1093 the argument value.</p>
1094 <hr>
1095 <a name="33"><h3>33.&nbsp;Codecvt&lt;&gt; mentions from_type</h3></a><p><b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.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>
1096 <p>In the table defining the results from do_out and do_in, the specification for the
1097 result <i>error</i> says </p>
1098
1099 <blockquote>
1100   <p>encountered a from_type character it could not convert </p>
1101 </blockquote>
1102
1103 <p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
1104 an internT for do_out. </p>
1105 <p><b>Proposed resolution:</b></p>
1106 <p>In 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 4, replace the definition
1107 in the table for the case of _error_ with </p>
1108
1109 <blockquote>
1110   <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
1111 </blockquote>
1112 <hr>
1113 <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>
1114 <p>In paragraph 19, Effects:, members truename() and falsename are used from facet
1115 ctype&lt;charT&gt;, but it has no such members. Note that this is also a problem in
1116 22.2.2.1.2, addressed in (4). </p>
1117 <p><b>Proposed resolution:</b></p>
1118 <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:
1119 clause for member put(...., bool), replace the initialization of the
1120 string_type value s as follows: </p>
1121
1122 <blockquote>
1123   <pre>const numpunct&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(loc);
1124 string_type s = val ? np.truename() : np.falsename(); </pre>
1125 </blockquote>
1126 <hr>
1127 <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>
1128 <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
1129 named "unitbuf". Unlike other manipulators, it's not listed
1130 in synopsis. Similarly for "nounitbuf". </p>
1131 <p><b>Proposed resolution:</b></p>
1132 <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
1133 the entry for "nouppercase", the prototypes: </p>
1134
1135 <blockquote>
1136   <pre>ios_base&amp; unitbuf(ios_base&amp; str);
1137 ios_base&amp; nounitbuf(ios_base&amp; str); </pre>
1138 </blockquote>
1139 <hr>
1140 <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>
1141 <p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
1142 specified badly, so that an implementation which only keeps the last value stored appears
1143 to conform. In particular, it says: </p>
1144
1145 <p>The reference returned may become invalid after another call to the object's iword
1146 member with a different index ... </p>
1147
1148 <p>This is not idle speculation; at least one implementation was done this way. </p>
1149 <p><b>Proposed resolution:</b></p>
1150 <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
1151 paragraph 4, replace the sentence: </p>
1152
1153 <blockquote>
1154   <p>The reference returned may become invalid after another call to the object's iword
1155   [pword] member with a different index, after a call to its copyfmt member, or when the
1156   object is destroyed. </p>
1157 </blockquote>
1158
1159 <p>with: </p>
1160
1161 <blockquote>
1162   <p>The reference returned is invalid after any other operations on the object. However,
1163   the value of the storage referred to is retained, so that until the next call to copyfmt,
1164   calling iword [pword] with the same index yields another reference to the same value. </p>
1165 </blockquote>
1166
1167 <p>substituting "iword" or "pword" as appropriate. </p>
1168 <hr>
1169 <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>
1170 <p>In the overview of locale semantics, paragraph 4, is the sentence </p>
1171
1172 <blockquote>
1173   <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
1174   the standard exception bad_cast. </p>
1175 </blockquote>
1176
1177 <p>This is not supported by the definition of use_facet&lt;&gt;, and represents semantics
1178 from an old draft. </p>
1179 <p><b>Proposed resolution:</b></p>
1180 <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
1181 expression </p>
1182
1183 <blockquote>
1184   <p>(or, failing that, in the global locale) </p>
1185 </blockquote>
1186 <hr>
1187 <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>
1188 <p>It has been noticed by Esa Pulkkinen that the definition of
1189 "facet" is incomplete. In particular, a class derived from
1190 another facet, but which does not define a member <i>id</i>, cannot
1191 safely serve as the argument <i>F</i> to use_facet&lt;F&gt;(loc),
1192 because there is no guarantee that a reference to the facet instance
1193 stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
1194 <p><b>Proposed resolution:</b></p>
1195 <p>In the definition of std::use_facet&lt;&gt;(), replace the text in paragraph 1 which
1196 reads: </p>
1197
1198 <blockquote>
1199   <p>Get a reference to a facet of a locale. </p>
1200 </blockquote>
1201
1202 <p>with: </p>
1203
1204 <blockquote>
1205   <p>Requires: <tt>Facet</tt> is a facet class whose definition
1206   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>
1207 </blockquote>
1208
1209 <p><i>[
1210 Kona: strike as overspecification the text "(not inherits)"
1211 from the original resolution, which read "... whose definition
1212 contains (not inherits) the public static member
1213 <tt>id</tt>..."
1214 ]</i></p>
1215
1216 <hr>
1217 <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>
1218 <p>Following the definition of istreambuf_iterator&lt;&gt;::operator++(int) in paragraph
1219 3, the standard contains three lines of garbage text left over from a previous edit. </p>
1220
1221 <blockquote>
1222   <pre>istreambuf_iterator&lt;charT,traits&gt; tmp = *this;
1223 sbuf_-&gt;sbumpc();
1224 return(tmp); </pre>
1225 </blockquote>
1226 <p><b>Proposed resolution:</b></p>
1227 <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
1228 end of paragraph 3. </p>
1229 <hr>
1230 <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>
1231 <p>Paragraph 3 of the locale examples is a description of part of an
1232 implementation technique that has lost its referent, and doesn't mean
1233 anything. </p>
1234 <p><b>Proposed resolution:</b></p>
1235 <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
1236 initialization/identification system depends...", or (at the
1237 editor's option) replace it with a place-holder to keep the paragraph
1238 numbering the same. </p>
1239 <hr>
1240 <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>
1241 <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,
1242 which may throw an exception". However, ios_base offers no
1243 interface to set or to test badbit; those interfaces are defined in
1244 basic_ios&lt;&gt;. </p>
1245 <p><b>Proposed resolution:</b></p>
1246 <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
1247 paragraph 2, and also in paragraph 4, as follows. Replace</p>
1248
1249 <blockquote>
1250   <p>If the function fails it sets badbit, which may throw an exception.</p>
1251 </blockquote>
1252
1253 <p>with</p>
1254
1255 <blockquote>
1256   <p>If the function fails, and <tt>*this</tt> is a base sub-object of
1257   a <tt>basic_ios&lt;&gt;</tt> object or sub-object, the effect is
1258   equivalent to calling <tt>basic_ios&lt;&gt;::setstate(badbit)</tt>
1259   on the derived object (which may throw <tt>failure</tt>).</p>
1260 </blockquote>
1261
1262 <p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
1263 setstate(badbit).]</i></p>
1264
1265 <hr>
1266 <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>
1267 <p>The basic_string&lt;&gt; copy constructor: </p>
1268
1269 <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1270              size_type n = npos, const Allocator&amp; a = Allocator()); </pre>
1271
1272 <p>specifies an Allocator argument default value that is
1273 counter-intuitive. The natural choice for a the allocator to copy from
1274 is str.get_allocator(). Though this cannot be expressed in
1275 default-argument notation, overloading suffices. </p>
1276
1277 <p>Alternatively, the other containers in Clause 23 (deque, list,
1278 vector) do not have this form of constructor, so it is inconsistent,
1279 and an evident source of confusion, for basic_string&lt;&gt; to have
1280 it, so it might better be removed. </p>
1281 <p><b>Proposed resolution:</b></p>
1282 <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
1283 constructor as follows: </p>
1284
1285 <blockquote>
1286   <pre>basic_string(const basic_string&amp; str);
1287 basic_string(const basic_string&amp; str, size_type pos, size_type n = npos,
1288              const Allocator&amp; a = Allocator());</pre>
1289 </blockquote>
1290
1291 <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
1292 as above. Add to paragraph 5, Effects:</p>
1293
1294 <blockquote>
1295   <p>In the first form, the Allocator value used is copied from
1296   <tt>str.get_allocator()</tt>.</p>
1297 </blockquote>
1298 <p><b>Rationale:</b></p>
1299 <p>The LWG believes the constructor is actually broken, rather than
1300 just an unfortunate design choice.</p>
1301
1302 <p>The LWG considered two other possible resolutions:</p>
1303
1304 <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
1305 constructor as follows:</p>
1306
1307 <blockquote>
1308   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1309              size_type n = npos);
1310 basic_string(const basic_string&amp; str, size_type pos,
1311              size_type n, const Allocator&amp; a); </pre>
1312 </blockquote>
1313
1314 <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
1315 as above. Add to paragraph 5, Effects: </p>
1316
1317 <blockquote>
1318   <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
1319   value <tt>str.get_allocator()</tt>. </p>
1320 </blockquote>
1321
1322 <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
1323 the declaration of the copy constructor as follows: </p>
1324
1325 <blockquote>
1326   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1327              size_type n = npos); </pre>
1328 </blockquote>
1329
1330 <p>The proposed resolution reflects the original intent of the LWG. It
1331 was also noted by Pete Becker that this fix "will cause
1332 a small amount of existing code to now work correctly."</p>
1333
1334 <p><i>[
1335 Kona: issue editing snafu fixed - the proposed resolution now correctly
1336 reflects the LWG consensus.
1337 ]</i></p>
1338 <hr>
1339 <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>
1340 <p>Many of the specifications for iostreams specify that character
1341 values or their int_type equivalents are compared using operators ==
1342 or !=, though in other places traits::eq() or traits::eq_int_type is
1343 specified to be used throughout. This is an inconsistency; we should
1344 change uses of == and != to use the traits members instead. </p>
1345 <p><b>Proposed resolution:</b></p>
1346
1347 <p><i>[Pre-Kona: Dietmar supplied wording]</i></p>
1348
1349 <p>List of changes to clause 27:</p>
1350 <ol>
1351 <li>
1352    In lib.basic.ios.members paragraph 13 (postcondition clause for
1353    'fill(cT)') change
1354
1355 <blockquote>
1356      fillch == fill()
1357 </blockquote>
1358
1359    to
1360
1361 <blockquote>
1362      traits::eq(fillch, fill())
1363 </blockquote>
1364
1365
1366 </li>
1367 <li>
1368    In lib.istream.unformatted paragraph 7 (effects clause for
1369    'get(cT,streamsize,cT)'), third bullet, change
1370
1371 <blockquote>
1372      c == delim for the next available input character c
1373 </blockquote>
1374
1375    to
1376
1377 <blockquote>
1378      traits::eq(c, delim) for the next available input character c
1379   </blockquote>
1380
1381 </li>
1382 <li>
1383    In lib.istream.unformatted paragraph 12 (effects clause for
1384    'get(basic_streambuf&lt;cT,Tr&gt;&amp;,cT)'), third bullet, change
1385
1386 <blockquote>
1387      c == delim for the next available input character c
1388 </blockquote>
1389
1390    to
1391
1392 <blockquote>
1393      traits::eq(c, delim) for the next available input character c
1394 </blockquote>
1395
1396 </li>
1397 <li>
1398    In lib.istream.unformatted paragraph 17 (effects clause for
1399    'getline(cT,streamsize,cT)'), second bullet, change
1400
1401 <blockquote>
1402      c == delim for the next available input character c
1403 </blockquote>
1404
1405    to
1406
1407 <blockquote>
1408      traits::eq(c, delim) for the next available input character c
1409   </blockquote>
1410
1411 </li>
1412 <li>
1413    In lib.istream.unformatted paragraph 24 (effects clause for
1414    'ignore(int,int_type)'), second bullet, change
1415
1416 <blockquote>
1417      c == delim for the next available input character c
1418 </blockquote>
1419
1420    to
1421
1422 <blockquote>
1423      traits::eq_int_type(c, delim) for the next available input
1424      character c
1425 </blockquote>
1426
1427 </li>
1428 <li>
1429    In lib.istream.unformatted paragraph 25 (notes clause for
1430    'ignore(int,int_type)'), second bullet, change
1431
1432 <blockquote>
1433      The last condition will never occur if delim == traits::eof()
1434 </blockquote>
1435
1436    to
1437
1438 <blockquote>
1439      The last condition will never occur if
1440      traits::eq_int_type(delim, traits::eof()).
1441 </blockquote>
1442
1443 </li>
1444 <li>
1445    In lib.istream.sentry paragraph 6 (example implementation for the
1446    sentry constructor) change
1447
1448 <blockquote>
1449      while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
1450 </blockquote>
1451
1452    to
1453
1454 <blockquote>
1455      while (!traits::eq_int_type(c = is.rdbuf()-&gt;snextc(), traits::eof())) {
1456 </blockquote>
1457
1458 </li>
1459 </ol>
1460
1461 <p>List of changes to Chapter 21:</p>
1462
1463 <ol>
1464 <li>
1465    In lib.string::find paragraph 1 (effects clause for find()),
1466    second bullet, change
1467
1468 <blockquote>
1469      at(xpos+I) == str.at(I) for all elements ...
1470 </blockquote>
1471
1472    to
1473
1474 <blockquote>
1475      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1476 </blockquote>
1477
1478 </li>
1479 <li>
1480    In lib.string::rfind paragraph 1 (effects clause for rfind()),
1481    second bullet, change
1482
1483 <blockquote>
1484      at(xpos+I) == str.at(I) for all elements ...
1485 </blockquote>
1486
1487    to
1488
1489 <blockquote>
1490      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1491 </blockquote>
1492
1493 </li>
1494 <li>
1495    In lib.string::find.first.of paragraph 1 (effects clause for
1496    find_first_of()), second bullet, change
1497
1498 <blockquote>
1499      at(xpos+I) == str.at(I) for all elements ...
1500 </blockquote>
1501
1502    to
1503
1504 <blockquote>
1505      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1506 </blockquote>
1507
1508 </li>
1509 <li>
1510    In lib.string::find.last.of paragraph 1 (effects clause for
1511    find_last_of()), second bullet, change
1512
1513 <blockquote>
1514      at(xpos+I) == str.at(I) for all elements ...
1515 </blockquote>
1516
1517    to
1518
1519 <blockquote>
1520      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1521 </blockquote>
1522
1523 </li>
1524 <li>
1525    In lib.string::find.first.not.of paragraph 1 (effects clause for
1526    find_first_not_of()), second bullet, change
1527
1528 <blockquote>
1529      at(xpos+I) == str.at(I) for all elements ...
1530 </blockquote>
1531
1532    to
1533
1534 <blockquote>
1535      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1536 </blockquote>
1537 </li>
1538
1539 <li>
1540    In lib.string::find.last.not.of paragraph 1 (effects clause for
1541    find_last_not_of()), second bullet, change
1542
1543 <blockquote>
1544      at(xpos+I) == str.at(I) for all elements ...
1545 </blockquote>
1546
1547    to
1548
1549 <blockquote>
1550      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1551 </blockquote>
1552 </li>
1553
1554 <li>
1555    In lib.string.ios paragraph 5 (effects clause for getline()),
1556    second bullet, change
1557
1558 <blockquote>
1559      c == delim for the next available input character c
1560 </blockquote>
1561
1562    to
1563
1564 <blockquote>
1565      traits::eq(c, delim) for the next available input character c
1566 </blockquote>
1567 </li>
1568
1569 </ol>
1570
1571 <p>Notes:</p>
1572 <ul>
1573 <li>
1574   Fixing this issue highlights another sloppyness in
1575   lib.istream.unformatted paragraph 24: this clause mentions a "character"
1576   which is then compared to an 'int_type' (see item 5. in the list
1577   below). It is not clear whether this requires explicit words and
1578   if so what these words are supposed to be. A similar issue exists,
1579   BTW, for operator*() of istreambuf_iterator which returns the result
1580   of sgetc() as a character type (see lib.istreambuf.iterator::op*
1581   paragraph 1), and for operator++() of istreambuf_iterator which
1582   passes the result of sbumpc() to a constructor taking a char_type
1583   (see lib.istreambuf.iterator::operator++ paragraph 3). Similarily, the
1584   assignment operator ostreambuf_iterator passes a char_type to a function
1585   taking an int_type (see lib.ostreambuf.iter.ops paragraph 1).
1586 </li>
1587 <li>
1588   It is inconsistent to use comparisons using the traits functions in
1589   Chapter 27 while not using them in Chapter 21, especially as some
1590   of the inconsistent uses actually involve streams (eg. getline() on
1591   streams). To avoid leaving this issue open still longer due to this
1592   inconsistency (it is open since 1998), a list of changes to Chapter
1593   21 is below.
1594 </li>
1595 <li>
1596   In Chapter 24 there are several places with statements like "the end
1597   of stream is reached (streambuf_type::sgetc() returns traits::eof())"
1598   (lib.istreambuf.iterator paragraph 1, lib.ostreambuf.iter.ops
1599   paragraph 5). It is unclear whether these should be clarified to use
1600   traits::eq_int_type() for detecting traits::eof().
1601 </li>
1602 </ul>
1603
1604 <hr>
1605 <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>
1606 <p>See lib-6522 and edit-814.</p>
1607 <p><b>Proposed resolution:</b></p>
1608 <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
1609 basic_streambuf&lt;char&gt;) from:</p>
1610
1611 <pre>         virtual streambuf&lt;char&gt;* setbuf(char* s, streamsize n);</pre>
1612
1613 <p>to:</p>
1614
1615 <pre>         virtual streambuf* setbuf(char* s, streamsize n);</pre>
1616
1617 <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
1618 int_type:</p>
1619
1620 <pre>     namespace std {
1621        class strstream
1622          : public basic_iostream&lt;char&gt; {
1623        public:
1624          // Types
1625          typedef char                                char_type;
1626          typedef typename char_traits&lt;char&gt;::int_type int_type
1627          typedef typename char_traits&lt;char&gt;::pos_type pos_type;</pre>
1628 <hr>
1629 <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>
1630 <p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
1631 section has two RETURNS clauses, and they make no sense as
1632 stated. They make perfect sense, though, if you swap them. Am I
1633 correct in thinking that paragraphs 2 and 4 just got mixed up by
1634 accident?</p>
1635 <p><b>Proposed resolution:</b></p>
1636 <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>
1637 <hr>
1638 <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>
1639 <p>27.4.2.1.1, paragraph 2, says that class failure initializes the
1640 base class, exception, with exception(msg). Class exception (see
1641 18.6.1) has no such constructor.</p>
1642 <p><b>Proposed resolution:</b></p>
1643 <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>
1644
1645 <blockquote>
1646   <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
1647 </blockquote>
1648 <hr>
1649 <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>
1650 <p>Two problems</p>
1651
1652 <p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
1653 returns. Does it return f, or does it return the previous
1654 synchronization state? My guess is the latter, but the standard
1655 doesn't say so.</p>
1656
1657 <p>(2) 27.4.2.4 doesn't say what it means for streams to be
1658 synchronized with stdio.  Again, of course, I can make some
1659 guesses. (And I'm unhappy about the performance implications of those
1660 guesses, but that's another matter.)</p>
1661 <p><b>Proposed resolution:</b></p>
1662 <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>
1663 returns clause from:</p>
1664
1665 <blockquote>
1666   <p><tt>true</tt> if the standard iostream objects (27.3) are
1667   synchronized and otherwise returns <tt>false</tt>.</p>
1668 </blockquote>
1669
1670 <p>to:</p>
1671
1672 <blockquote>
1673   <p><tt>true</tt> if the previous state of the standard iostream
1674   objects (27.3) was synchronized and otherwise returns
1675   <tt>false</tt>.</p>
1676 </blockquote>
1677
1678 <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>,
1679 paragraph 2:</p>
1680
1681 <blockquote>
1682 <p>When a standard iostream object str is <i>synchronized</i> with a
1683 standard stdio stream f, the effect of inserting a character c by</p>
1684 <pre>  fputc(f, c);
1685 </pre>
1686
1687 <p>is the same as the effect of</p>
1688 <pre>  str.rdbuf()-&gt;sputc(c);
1689 </pre>
1690
1691 <p>for any sequence of characters; the effect of extracting a
1692 character c by</p>
1693 <pre>  c = fgetc(f);
1694 </pre>
1695
1696 <p>is the same as the effect of:</p>
1697 <pre>  c = str.rdbuf()-&gt;sbumpc(c);
1698 </pre>
1699
1700 <p>for any sequences of characters; and the effect of pushing
1701 back a character c by</p>
1702 <pre>  ungetc(c, f);
1703 </pre>
1704
1705 <p>is the same as the effect of</p>
1706 <pre>  str.rdbuf()-&gt;sputbackc(c);
1707 </pre>
1708
1709 <p>for any sequence of characters.  [<i>Footnote</i>: This implies
1710 that operations on a standard iostream object can be mixed arbitrarily
1711 with operations on the corresponding stdio stream.  In practical
1712 terms, synchronization usually means that a standard iostream object
1713 and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
1714 </blockquote>
1715
1716 <p><i>[pre-Copenhagen: PJP and Matt contributed the definition
1717 of "synchronization"]</i></p>
1718
1719 <p><i>[post-Copenhagen: proposed resolution was revised slightly:
1720 text was added in the non-normative footnote to say that operations
1721 on the two streams can be mixed arbitrarily.]</i></p>
1722 <hr>
1723 <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>
1724 <p>As written, ios_base has a copy constructor and an assignment
1725 operator. (Nothing in the standard says it doesn't have one, and all
1726 classes have copy constructors and assignment operators unless you
1727 take specific steps to avoid them.) However, nothing in 27.4.2 says
1728 what the copy constructor and assignment operator do. </p>
1729
1730 <p>My guess is that this was an oversight, that ios_base is, like
1731 basic_ios, not supposed to have a copy constructor or an assignment
1732 operator.</p>
1733
1734 <p>
1735 Jerry Schwarz comments: Yes, its an oversight, but in the opposite
1736 sense to what you're suggesting. At one point there was a definite
1737 intention that you could copy ios_base. It's an easy way to save the
1738 entire state of a stream for future use. As you note, to carry out
1739 that intention would have required a explicit description of the
1740 semantics (e.g. what happens to the iarray and parray stuff).
1741 </p>
1742 <p><b>Proposed resolution:</b></p>
1743 <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
1744 constructor and operator= members as being private.</p>
1745 <p><b>Rationale:</b></p>
1746 <p>The LWG believes the difficulty of specifying correct semantics
1747 outweighs any benefit of allowing ios_base objects to be copyable.</p>
1748 <hr>
1749 <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>
1750 <p>The std::sort algorithm can in general only sort a given sequence
1751 by moving around values. The list&lt;&gt;::sort() member on the other
1752 hand could move around values or just update internal pointers. Either
1753 method can leave iterators into the list&lt;&gt; dereferencable, but
1754 they would point to different things. </p>
1755
1756 <p>Does the FDIS mandate anywhere which method should be used for
1757 list&lt;&gt;::sort()?</p>
1758
1759 <p>Matt Austern comments:</p>
1760
1761 <p>I think you've found an omission in the standard. </p>
1762
1763 <p>The library working group discussed this point, and there was
1764 supposed to be a general requirement saying that list, set, map,
1765 multiset, and multimap may not invalidate iterators, or change the
1766 values that iterators point to, except when an operation does it
1767 explicitly. So, for example, insert() doesn't invalidate any iterators
1768 and erase() and remove() only invalidate iterators pointing to the
1769 elements that are being erased. </p>
1770
1771 <p>I looked for that general requirement in the FDIS, and, while I
1772 found a limited form of it for the sorted associative containers, I
1773 didn't find it for list. It looks like it just got omitted. </p>
1774
1775 <p>The intention, though, is that list&lt;&gt;::sort does not
1776 invalidate any iterators and does not change the values that any
1777 iterator points to. There would be no reason to have the member
1778 function otherwise.</p>
1779 <p><b>Proposed resolution:</b></p>
1780 <p>Add a new paragraph at the end of 23.1:</p>
1781
1782 <blockquote>
1783   <p>Unless otherwise specified (either explicitly or by defining a function in terms of
1784   other functions), invoking a container member function or passing a container as an
1785   argument to a library function shall not invalidate iterators to, or change the values of,
1786   objects within that container. </p>
1787 </blockquote>
1788 <p><b>Rationale:</b></p>
1789 <p>This was US issue CD2-23-011; it was accepted in London but the
1790 change was not made due to an editing oversight. The wording in the
1791 proposed resolution below is somewhat updated from CD2-23-011,
1792 particularly the addition of the phrase "or change the values
1793 of"</p>
1794 <hr>
1795 <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>
1796 <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:
1797 it should be titled "basic_ios&lt;&gt;() effects", not
1798 "ios_base() effects". </p>
1799
1800 <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
1801 resolution.]</p>
1802
1803 <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
1804 different things wrong with it, some of which I've already discussed
1805 with Jerry, but the most obvious mechanical sort of error is that it
1806 uses expressions like P(i) and p(i), without ever defining what sort
1807 of thing "i" is.
1808 </p>
1809
1810 <p>(The other problem is that it requires support for streampos
1811 arithmetic. This is impossible on some systems, i.e. ones where file
1812 position is a complicated structure rather than just a number. Jerry
1813 tells me that the intention was to require syntactic support for
1814 streampos arithmetic, but that it wasn't actually supposed to do
1815 anything meaningful except on platforms, like Unix, where genuine
1816 arithmetic is possible.) </p>
1817 <p><b>Proposed resolution:</b></p>
1818 <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
1819 "ios_base() effects" to "basic_ios&lt;&gt;()
1820 effects". </p>
1821 <hr>
1822 <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>
1823 <p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
1824 The important question is whether basic_ios::~basic_ios() destroys
1825 rdbuf().</p>
1826 <p><b>Proposed resolution:</b></p>
1827 <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>
1828
1829 <blockquote>
1830   <p><tt>virtual ~basic_ios();</tt></p>
1831   <p><b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
1832 </blockquote>
1833 <p><b>Rationale:</b></p>
1834 <p>The LWG reviewed the additional question of whether or not
1835 <tt>rdbuf(0)</tt> may set <tt>badbit</tt>.  The answer is
1836 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
1837 by the LWG, which removed from the original proposed resolution a
1838 footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
1839 <tt>badbit</tt>".</p>
1840 <hr>
1841 <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>
1842 <p>The class synopsis for basic_streambuf shows a (virtual)
1843 destructor, but the standard doesn't say what that destructor does. My
1844 assumption is that it does nothing, but the standard should say so
1845 explicitly. </p>
1846 <p><b>Proposed resolution:</b></p>
1847 <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>
1848
1849 <blockquote>
1850   <p><tt>virtual&nbsp; ~basic_streambuf();</tt></p>
1851   <p><b>Effects</b>: None.</p>
1852 </blockquote>
1853 <hr>
1854 <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>
1855 <p>Several member functions in clause 27 are defined in certain
1856 circumstances to return an "invalid stream position", a term
1857 that is defined nowhere in the standard. Two places (27.5.2.4.2,
1858 paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
1859 a definition in _lib.iostreams.definitions_, a nonexistent
1860 section. </p>
1861
1862 <p>I suspect that the invalid stream position is just supposed to be
1863 pos_type(-1).  Probably best to say explicitly in (for example)
1864 27.5.2.4.2 that the return value is pos_type(-1), rather than to use
1865 the term "invalid stream position", define that term
1866 somewhere, and then put in a cross-reference. </p>
1867
1868 <p>The phrase "invalid stream position" appears ten times in
1869 the C++ Standard.  In seven places it refers to a return value, and it
1870 should be changed. In three places it refers to an argument, and it
1871 should not be changed. Here are the three places where "invalid
1872 stream position" should not be changed:</p>
1873
1874 <blockquote>
1875   <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>
1876   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>
1877   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
1878   </p>
1879 </blockquote>
1880 <p><b>Proposed resolution:</b></p>
1881 <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
1882 object of class pos_type that stores an invalid stream position
1883 (_lib.iostreams.definitions_)" to "Returns
1884 <tt>pos_type(off_type(-1))</tt>".
1885 </p>
1886
1887 <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
1888 an object of class pos_type that stores an invalid stream
1889 position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
1890
1891 <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
1892 stores an invalid stream position" to "the return value is
1893 <tt>pos_type(off_type(-1))</tt>". </p>
1894
1895 <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
1896 invalid stream position (27.4.3)" to "returns
1897 <tt>pos_type(off_type(-1))</tt>" </p>
1898
1899 <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
1900 returns an invalid stream position (_lib.iostreams.definitions_)"
1901 to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
1902 </p>
1903
1904 <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
1905 stores an invalid stream position" to "the return value is
1906 <tt>pos_type(off_type(-1))</tt>" </p>
1907
1908 <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
1909 stores an invalid stream position" to "the return value is
1910 <tt>pos_type(off_type(-1))</tt>"</p>
1911 <hr>
1912 <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>
1913 <p>The class summary for basic_streambuf&lt;&gt;, in 27.5.2, says that
1914 showmanyc has return type int. However, 27.5.2.4.3 says that its
1915 return type is streamsize. </p>
1916 <p><b>Proposed resolution:</b></p>
1917 <p>Change <tt>showmanyc</tt>'s return type in the
1918 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>
1919 <hr>
1920 <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>
1921 <p>21.1.3.2, paragraph 3, says "The types streampos and
1922 wstreampos may be different if the implementation supports no shift
1923 encoding in narrow-oriented iostreams but supports one or more shift
1924 encodings in wide-oriented streams". </p>
1925
1926 <p>That's wrong: the two are the same type. The &lt;iosfwd&gt; summary
1927 in 27.2 says that streampos and wstreampos are, respectively, synonyms
1928 for fpos&lt;char_traits&lt;char&gt;::state_type&gt; and
1929 fpos&lt;char_traits&lt;wchar_t&gt;::state_type&gt;, and, flipping back
1930 to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
1931 char_traits&lt;char&gt;::state_type and
1932 char_traits&lt;wchar_t&gt;::state_type must both be mbstate_t. </p>
1933 <p><b>Proposed resolution:</b></p>
1934 <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
1935 begins "The types streampos and wstreampos may be
1936 different..." . </p>
1937 <hr>
1938 <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>
1939 <p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
1940 next pointer for the input sequence by n." </p>
1941
1942 <p>The straightforward interpretation is that it is just gptr() +=
1943 n. An alternative interpretation, though, is that it behaves as if it
1944 calls sbumpc n times. (The issue, of course, is whether it might ever
1945 call underflow.) There is a similar ambiguity in the case of
1946 pbump. </p>
1947
1948 <p>(The "classic" AT&amp;T implementation used the
1949 former interpretation.)</p>
1950 <p><b>Proposed resolution:</b></p>
1951 <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>
1952
1953 <blockquote>
1954   <p>Effects: Advances the next pointer for the input sequence by n.</p>
1955 </blockquote>
1956
1957 <p>to:</p>
1958
1959 <blockquote>
1960   <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
1961 </blockquote>
1962
1963 <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
1964 effects.</p>
1965 <hr>
1966 <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>
1967 <p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
1968 formatted input functions. Some of the functions defined in section
1969 27.6.1.2 explicitly say that those requirements apply ("Behaves
1970 like a formatted input member (as described in 27.6.1.2.1)"), but
1971 others don't. The question: is 27.6.1.2.1 supposed to apply to
1972 everything in 27.6.1.2, or only to those member functions that
1973 explicitly say "behaves like a formatted input member"? Or
1974 to put it differently: are we to assume that everything that appears
1975 in a section called "Formatted input functions" really is a
1976 formatted input function? I assume that 27.6.1.2.1 is intended to
1977 apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
1978 is not intended to apply to extractors like </p>
1979
1980 <pre>    basic_istream&amp; operator&gt;&gt;(basic_istream&amp; (*pf)(basic_istream&amp;));</pre>
1981
1982 <p>and </p>
1983
1984 <pre>    basic_istream&amp; operator&gt;&gt;(basic_streammbuf*);</pre>
1985
1986 <p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
1987 output. </p>
1988
1989 <p>Comments from Judy Ward: It seems like the problem is that the
1990 basic_istream and basic_ostream operator &lt;&lt;()'s that are used
1991 for the manipulators and streambuf* are in the wrong section and
1992 should have their own separate section or be modified to make it clear
1993 that the "Common requirements" listed in section 27.6.1.2.1
1994 (for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
1995 apply to them. </p>
1996
1997 <p>Additional comments from Dietmar Kühl: It appears to be somewhat
1998 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
1999 function" but since these functions are defined in a section
2000 labeled "Formatted input functions" it is unclear to me
2001 whether these operators are considered formatted input functions which
2002 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
2003 just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
2004 set (... but setting <tt>noskipws</tt> using the manipulator syntax
2005 would also skip whitespace :-)</p> <p>It is not clear which functions
2006 are to be considered unformatted input functions. As written, it seems
2007 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
2008 functions. However, it does not really make much sense to construct a
2009 sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
2010 unclear what happens to the <tt>gcount()</tt> if
2011 eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
2012 <tt>sync()</tt> is called: These functions don't extract characters,
2013 some of them even "unextract" a character. Should this still
2014 be reflected in <tt>gcount()</tt>? Of course, it could be read as if
2015 after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
2016 (the last unformatted input function, <tt>gcount()</tt>, didn't
2017 extract any character) and after a call to <tt>putback()</tt>
2018 <tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
2019 function <tt>putback()</tt> did "extract" back into the
2020 stream). Correspondingly for <tt>unget()</tt>. Is this what is
2021 intended?  If so, this should be clarified. Otherwise, a corresponding
2022 clarification should be used.</p>
2023 <p><b>Proposed resolution:</b></p>
2024 <p>
2025 In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
2026 Change the beginning of the second sentence from "The conversion
2027 occurs" to "These extractors behave as formatted input functions (as
2028 described in 27.6.1.2.1).  After a sentry object is constructed,
2029 the conversion occurs"
2030 </p>
2031
2032 <p>
2033 In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
2034 Add an effects clause.  "Effects: None.  This extractor does
2035 not behave as a formatted input function (as described in
2036 27.6.1.2.1).
2037 </p>
2038
2039 <p>
2040 In 27.6.1.2.3, [lib.istream::extractors], paragraph 2.  Change the
2041 effects clause to "Effects: Calls pf(*this).  This extractor does not
2042 behave as a formatted input function (as described in 27.6.1.2.1).
2043 </p>
2044
2045 <p>
2046 In 27.6.1.2.3, [lib.istream::extractors], paragraph 4.  Change the
2047 effects clause to "Effects: Calls pf(*this).  This extractor does not
2048 behave as a formatted input function (as described in 27.6.1.2.1).
2049 </p>
2050
2051 <p>
2052 In 27.6.1.2.3, [lib.istream::extractors], paragraph 12.  Change the
2053 first two sentences from "If sb is null, calls setstate(failbit),
2054 which may throw ios_base::failure (27.4.4.3).  Extracts characters
2055 from *this..." to "Behaves as a formatted input function (as described
2056 in 27.6.1.2.1).  If sb is null, calls setstate(failbit), which may
2057 throw ios_base::failure (27.4.4.3).  After a sentry object is
2058 constructed, extracts characters from *this...".
2059 </p>
2060
2061 <p>
2062 In 27.6.1.3, [lib.istream.unformatted], before paragraph 2.  Add an
2063 effects clause.  "Effects: none. This member function does not behave
2064 as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
2065 </p>
2066
2067 <p>
2068 In 27.6.1.3, [lib.istream.unformatted], paragraph 3.  Change the
2069 beginning of the first sentence of the effects clause from "Extracts a
2070 character" to "Behaves as an unformatted input function (as described
2071 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
2072 character"
2073 </p>
2074
2075 <p>
2076 In 27.6.1.3, [lib.istream.unformatted], paragraph 5.  Change the
2077 beginning of the first sentence of the effects clause from "Extracts a
2078 character" to "Behaves as an unformatted input function (as described
2079 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
2080 character"
2081 </p>
2082
2083 <p>
2084 In 27.6.1.3, [lib.istream.unformatted], paragraph 7.  Change the
2085 beginning of the first sentence of the effects clause from "Extracts
2086 characters" to "Behaves as an unformatted input function (as described
2087 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2088 characters"
2089 </p>
2090
2091 <p>
2092 [No change needed in paragraph 10, because it refers to paragraph 7.]
2093 </p>
2094
2095 <p>
2096 In 27.6.1.3, [lib.istream.unformatted], paragraph 12.  Change the
2097 beginning of the first sentence of the effects clause from "Extracts
2098 characters" to "Behaves as an unformatted input function (as described
2099 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2100 characters"
2101 </p>
2102
2103 <p>
2104 [No change needed in paragraph 15.]
2105 </p>
2106
2107 <p>
2108 In 27.6.1.3, [lib.istream.unformatted], paragraph 17.  Change the
2109 beginning of the first sentence of the effects clause from "Extracts
2110 characters" to "Behaves as an unformatted input function (as described
2111 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2112 characters"
2113 </p>
2114
2115 <p>
2116 [No change needed in paragraph 23.]
2117 </p>
2118
2119 <p>
2120 In 27.6.1.3, [lib.istream.unformatted], paragraph 24.  Change the
2121 beginning of the first sentence of the effects clause from "Extracts
2122 characters" to "Behaves as an unformatted input function (as described
2123 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2124 characters"
2125 </p>
2126
2127 <p>
2128 In 27.6.1.3, [lib.istream.unformatted], before paragraph 27.  Add an
2129 Effects clause: "Effects: Behaves as an unformatted input function (as
2130 described in 27.6.1.3, paragraph 1).  After constructing a sentry
2131 object, reads but does not extract the current input character."
2132 </p>
2133
2134 <p>
2135 In 27.6.1.3, [lib.istream.unformatted], paragraph 28.  Change the
2136 first sentence of the Effects clause from "If !good() calls" to
2137 Behaves as an unformatted input function (as described in 27.6.1.3,
2138 paragraph 1).  After constructing a sentry object, if !good() calls"
2139 </p>
2140
2141 <p>
2142 In 27.6.1.3, [lib.istream.unformatted], paragraph 30.  Change the
2143 first sentence of the Effects clause from "If !good() calls" to
2144 "Behaves as an unformatted input function (as described in 27.6.1.3,
2145 paragraph 1).  After constructing a sentry object, if !good() calls"
2146 </p>
2147
2148 <p>
2149 In 27.6.1.3, [lib.istream.unformatted], paragraph 32.  Change the
2150 first sentence of the Effects clause from "If !good() calls..." to
2151 "Behaves as an unformatted input function (as described in 27.6.1.3,
2152 paragraph 1).  After constructing a sentry object, if !good()
2153 calls..."  Add a new sentence to the end of the Effects clause:
2154 "[Note: this function extracts no characters, so the value returned
2155 by the next call to gcount() is 0.]"
2156 </p>
2157
2158 <p>
2159 In 27.6.1.3, [lib.istream.unformatted], paragraph 34.  Change the
2160 first sentence of the Effects clause from "If !good() calls" to
2161 "Behaves as an unformatted input function (as described in 27.6.1.3,
2162 paragraph 1).  After constructing a sentry object, if !good() calls".
2163 Add a new sentence to the end of the Effects clause: "[Note: this
2164 function extracts no characters, so the value returned by the next
2165 call to gcount() is 0.]"
2166 </p>
2167
2168 <p>
2169 In 27.6.1.3, [lib.istream.unformatted], paragraph 36.  Change the
2170 first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
2171 as an unformatted input function (as described in 27.6.1.3, paragraph
2172 1), except that it does not count the number of characters extracted
2173 and does not affect the value returned by subsequent calls to
2174 gcount().  After constructing a sentry object, if rdbuf() is"
2175 </p>
2176
2177 <p>
2178 In 27.6.1.3, [lib.istream.unformatted], before paragraph 37.  Add an
2179 Effects clause: "Effects: Behaves as an unformatted input function (as
2180 described in 27.6.1.3, paragraph 1), except that it does not count the
2181 number of characters extracted and does not affect the value returned
2182 by subsequent calls to gcount()."  Change the first sentence of
2183 paragraph 37 from "if fail()" to "after constructing a sentry object,
2184 if fail()".
2185 </p>
2186
2187 <p>
2188 In 27.6.1.3, [lib.istream.unformatted], paragraph 38.  Change the
2189 first sentence of the Effects clause from "If fail()" to "Behaves
2190 as an unformatted input function (as described in 27.6.1.3, paragraph
2191 1), except that it does not count the number of characters extracted
2192 and does not affect the value returned by subsequent calls to
2193 gcount().  After constructing a sentry object, if fail()
2194 </p>
2195
2196 <p>
2197 In 27.6.1.3, [lib.istream.unformatted], paragraph 40.  Change the
2198 first sentence of the Effects clause from "If fail()" to "Behaves
2199 as an unformatted input function (as described in 27.6.1.3, paragraph
2200 1), except that it does not count the number of characters extracted
2201 and does not affect the value returned by subsequent calls to
2202 gcount().  After constructing a sentry object, if fail()
2203 </p>
2204
2205 <p>
2206 In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1.  Change
2207 the beginning of the third sentence from "The formatting conversion"
2208 to "These extractors behave as formatted output functions (as
2209 described in 27.6.2.5.1).  After the sentry object is constructed, the
2210 conversion occurs".
2211 </p>
2212
2213 <p>
2214 In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1.  Add an
2215 effects clause: "Effects: None. Does not behave as a formatted output
2216 function (as described in 27.6.2.5.1).".
2217 </p>
2218
2219 <p>
2220 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2.  Change the
2221 effects clause to "Effects: calls pf(*this).  This extractor does not
2222 behave as a formatted output function (as described in 27.6.2.5.1).".
2223 </p>
2224
2225 <p>
2226 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4.  Change the
2227 effects clause to "Effects: calls pf(*this).  This extractor does not
2228 behave as a formatted output function (as described in 27.6.2.5.1).".
2229 </p>
2230
2231 <p>
2232 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6.  Change the first
2233 sentence from "If sb" to "Behaves as a formatted output function (as
2234 described in 27.6.2.5.1).  After the sentry object is constructed, if
2235 sb".
2236 </p>
2237
2238 <p>
2239 In 27.6.2.6 [lib.ostream.unformatted], paragraph 2.  Change the first
2240 sentence from "Inserts the character" to "Behaves as an unformatted
2241 output function (as described in 27.6.2.6, paragraph 1).  After
2242 constructing a sentry object, inserts the character".
2243 </p>
2244
2245 <p>
2246 In 27.6.2.6 [lib.ostream.unformatted], paragraph 5.  Change the first
2247 sentence from "Obtains characters" to "Behaves as an unformatted
2248 output function (as described in 27.6.2.6, paragraph 1).  After
2249 constructing a sentry object, obtains characters".
2250 </p>
2251
2252 <p>
2253 In 27.6.2.6 [lib.ostream.unformatted], paragraph 7.  Add a new
2254 sentence at the end of the paragraph: "Does not behave as an
2255 unformatted output function (as described in 27.6.2.6, paragraph 1)."
2256 </p>
2257 <p><b>Rationale:</b></p>
2258 <p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
2259 by Judy Ward and Matt Austern.  This proposed resolution is section
2260 VI of that paper.</p>
2261 <hr>
2262 <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>
2263 <p>The introduction to the section on unformatted input (27.6.1.3)
2264 says that every unformatted input function catches all exceptions that
2265 were thrown during input, sets badbit, and then conditionally rethrows
2266 the exception. That seems clear enough. Several of the specific
2267 functions, however, such as get() and read(), are documented in some
2268 circumstances as setting eofbit and/or failbit. (The standard notes,
2269 correctly, that setting eofbit or failbit can sometimes result in an
2270 exception being thrown.) The question: if one of these functions
2271 throws an exception triggered by setting failbit, is this an exception
2272 "thrown during input" and hence covered by 27.6.1.3, or does
2273 27.6.1.3 only refer to a limited class of exceptions? Just to make
2274 this concrete, suppose you have the following snippet. </p>
2275
2276 <pre>
2277   char buffer[N];
2278   istream is;
2279   ...
2280   is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
2281   is.read(buffer, N);</pre>
2282
2283 <p>Now suppose we reach EOF before we've read N characters. What
2284 iostate bits can we expect to be set, and what exception (if any) will
2285 be thrown? </p>
2286 <p><b>Proposed resolution:</b></p>
2287 <p>
2288 In 27.6.1.3, paragraph 1, after the sentence that begins
2289 "If an exception is thrown...", add the following
2290 parenthetical comment: "(Exceptions thrown from
2291 <tt>basic_ios&lt;&gt;::clear()</tt> are not caught or rethrown.)"
2292 </p>
2293 <p><b>Rationale:</b></p>
2294 <p>The LWG looked to two alternative wordings, and choose the proposed
2295 resolution as better standardese.</p>
2296 <hr>
2297 <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>
2298 <p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
2299 "calls rdbuf()-&gt;pubsync() and, if that function returns -1
2300 ... returns traits::eof()." </p>
2301
2302 <p>That looks suspicious, because traits::eof() is of type
2303 traits::int_type while the return type of sync() is int. </p>
2304 <p><b>Proposed resolution:</b></p>
2305 <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
2306 <tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
2307 </p>
2308 <hr>
2309 <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>
2310 <p>Clause 27 details an exception-handling policy for formatted input,
2311 unformatted input, and formatted output. It says nothing for
2312 unformatted output (27.6.2.6). 27.6.2.6 should either include the same
2313 kind of exception-handling policy as in the other three places, or
2314 else it should have a footnote saying that the omission is
2315 deliberate. </p>
2316 <p><b>Proposed resolution:</b></p>
2317 <p>
2318 In 27.6.2.6, paragraph 1, replace the last sentence ("In any
2319 case, the unformatted output function ends by destroying the sentry
2320 object, then returning the value specified for the formatted output
2321 function.") with the following text:
2322 </p>
2323 <blockquote>
2324 If an exception is thrown during output, then <tt>ios::badbit</tt> is
2325 turned on [Footnote: without causing an <tt>ios::failure</tt> to be
2326 thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &amp;
2327 badbit) != 0</tt> then the exception is rethrown.  In any case, the
2328 unformatted output function ends by destroying the sentry object,
2329 then, if no exception was thrown, returning the value specified for
2330 the formatted output function.
2331 </blockquote>
2332 <p><b>Rationale:</b></p>
2333 <p>
2334 This exception-handling policy is consistent with that of formatted
2335 input, unformatted input, and formatted output.
2336 </p>
2337 <hr>
2338 <a name="64"><h3>64.&nbsp;Exception handling in <tt>basic_istream::operator&gt;&gt;(basic_streambuf*)</tt>
2339 </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>
2340 <p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
2341 different ways, depending on whether the second sentence is read as an
2342 elaboration of the first. </p>
2343 <p><b>Proposed resolution:</b></p>
2344 <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
2345 "If the function inserts no characters ..." with:</p>
2346
2347 <blockquote>
2348   <p>If the function inserts no characters, it calls
2349   <tt>setstate(failbit)</tt>, which may throw
2350   <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
2351   because it caught an exception thrown while extracting characters
2352   from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
2353   (27.4.4.3), then the caught exception is rethrown. </p>
2354 </blockquote>
2355 <hr>
2356 <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>
2357 <p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
2358 "Performs an operation that is defined separately for each class
2359 derived from strstreambuf". This is obviously an incorrect
2360 cut-and-paste from basic_streambuf. There are no classes derived from
2361 strstreambuf. </p>
2362 <p><b>Proposed resolution:</b></p>
2363 <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
2364 clause which currently says "Performs an operation that is
2365 defined separately for each class derived from strstreambuf"
2366 with:</p>
2367
2368 <blockquote>
2369   <p><b>Effects</b>: implementation defined, except that
2370   <tt>setbuf(0,0)</tt> has no effect.</p>
2371 </blockquote>
2372 <hr>
2373 <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>
2374 <p>Extractors for char* (27.6.1.2.3) do not store a null character
2375 after the extracted character sequence whereas the unformatted
2376 functions like get() do. Why is this?</p>
2377
2378 <p>Comment from Jerry Schwarz: There is apparently an editing
2379 glitch. You'll notice that the last item of the list of what stops
2380 extraction doesn't make any sense. It was supposed to be the line that
2381 said a null is stored.</p>
2382 <p><b>Proposed resolution:</b></p>
2383 <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
2384 item from:</p>
2385
2386 <blockquote>
2387   A null byte (<tt>charT()</tt>) in the next position, which may be
2388   the first position if no characters were extracted.
2389 </blockquote>
2390
2391 <p>to become a new paragraph which reads:</p>
2392
2393 <blockquote>
2394   Operator&gt;&gt; then stores a null byte (<tt>charT()</tt>) in the
2395   next position, which may be the first position if no characters were
2396   extracted.
2397 </blockquote>
2398 <hr>
2399 <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.vector"> [lib.vector]</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>
2400 <p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
2401
2402 <p>(Please note that this is entirely separate from the question of
2403 whether a vector iterator is required to be a pointer; the answer to
2404 that question is clearly "no," as it would rule out
2405 debugging implementations)</p>
2406 <p><b>Proposed resolution:</b></p>
2407 <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.vector"> [lib.vector]</a>,
2408 paragraph 1. </p>
2409
2410 <blockquote>
2411   <p>The elements of a vector are stored contiguously, meaning that if
2412   v is a <tt>vector&lt;T, Allocator&gt;</tt> where T is some type
2413   other than <tt>bool</tt>, then it obeys the identity <tt>&amp;v[n]
2414   == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt; v.size()</tt>.</p>
2415 </blockquote>
2416 <p><b>Rationale:</b></p>
2417 <p>The LWG feels that as a practical matter the answer is clearly
2418 "yes".  There was considerable discussion as to the best way
2419 to express the concept of "contiguous", which is not
2420 directly defined in the standard.  Discussion included:</p>
2421
2422 <ul>
2423   <li>An operational definition similar to the above proposed resolution is
2424     already used for valarray (26.3.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a>).</li>
2425   <li>There is no need to explicitly consider a user-defined operator&amp;
2426     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)
2427     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
2428     requirements for operator&amp;.</li>
2429   <li>There is no issue of one-past-the-end because of language rules.</li>
2430 </ul>
2431 <hr>
2432 <a name="70"><h3>70.&nbsp;Uncaught_exception() missing throw() specification</h3></a><p><b>Section:</b>&nbsp;18.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.exception"> [lib.support.exception]</a>, 18.6.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>
2433 <p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
2434
2435 <p>uncaught_exception() doesn't have a throw specification.</p>
2436
2437 <p>It is intentional ? Does it means that one should be prepared to
2438 handle exceptions thrown from uncaught_exception() ?</p>
2439
2440 <p>uncaught_exception() is called in exception handling contexts where
2441 exception safety is very important.</p>
2442 <p><b>Proposed resolution:</b></p>
2443 <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.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.exception"> [lib.support.exception]</a>, and 18.6.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>
2444 <hr>
2445 <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>
2446 <p>The locale facet member <tt>time_get&lt;&gt;::do_get_monthname</tt>
2447 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,
2448 consistent with do_get_weekday and with its specified use by member
2449 get_monthname. However, in the synopsis, it is specified instead with
2450 four arguments. The missing argument is the "end" iterator
2451 value.</p>
2452 <p><b>Proposed resolution:</b></p>
2453 <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
2454 the declaration of member do_monthname as follows:</p>
2455
2456 <pre>  virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&amp;,
2457                                      ios_base::iostate&amp; err, tm* t) const;</pre>
2458 <hr>
2459 <a name="74"><h3>74.&nbsp;Garbled text for <tt>codecvt::do_max_length</tt>
2460 </h3></a><p><b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.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;8 Sep 1998</p>
2461 <p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
2462 clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
2463 parentheses and a spurious <b>n</b>.</p>
2464 <p><b>Proposed resolution:</b></p>
2465 <p>Replace 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 11 with the
2466 following:</p>
2467
2468 <blockquote>
2469   <b>Returns</b>: The maximum value that
2470   <tt>do_length(state, from, from_end, 1)</tt> can return for any
2471   valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
2472   <tt>state</tt>. The specialization <tt>codecvt&lt;char, char,
2473   mbstate_t&gt;::do_max_length()</tt> returns 1.
2474 </blockquote>
2475 <hr>
2476 <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"> [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; Matt
2477 Austern&nbsp; <b>Date:</b>&nbsp; 18 Sep 1998</p>
2478 <p>The class synopses for classes <tt>codecvt&lt;&gt;</tt> (22.2.1.5)
2479 and <tt>codecvt_byname&lt;&gt;</tt> (22.2.1.6) say that the first
2480 parameter of the member functions <tt>length</tt> and
2481 <tt>do_length</tt> is of type <tt>const stateT&amp;</tt>. The member
2482 function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
2483 paragraph 9) say that the type is <tt>stateT&amp;</tt>.  Either the
2484 synopsis or the summary must be changed. </p>
2485
2486 <p>If (as I believe) the member function descriptions are correct,
2487 then we must also add text saying how <tt>do_length</tt> changes its
2488 <tt>stateT</tt> argument. </p>
2489 <p><b>Proposed resolution:</b></p>
2490 <p>In 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>, and also in 22.2.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>,
2491 change the <tt>stateT</tt> argument type on both member
2492 <tt>length()</tt> and member <tt>do_length()</tt> from </p>
2493
2494 <blockquote>
2495   <p><tt>const stateT&amp;</tt></p>
2496 </blockquote>
2497
2498 <p>to</p>
2499
2500 <blockquote>
2501   <p><tt>stateT&amp;</tt></p>
2502 </blockquote>
2503
2504 <p>In 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, add to the definition for member
2505 <tt>do_length</tt> a paragraph:</p>
2506
2507 <blockquote>
2508   <p>Effects: The effect on the <tt>state</tt> argument is ``as if''
2509   it called <tt>do_in(state, from, from_end, from, to, to+max,
2510   to)</tt> for <tt>to</tt> pointing to a buffer of at least
2511   <tt>max</tt> elements.</p>
2512 </blockquote>
2513 <hr>
2514 <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"> [lib.locale.codecvt]</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>
2515 <p>This issue concerns the requirements on classes derived from
2516 <tt>codecvt</tt>, including user-defined classes. What are the
2517 restrictions on the conversion from external characters
2518 (e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
2519 Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
2520 the I/O library make? </p>
2521
2522 <p>The question is whether it's possible to convert from internal
2523 characters to external characters one internal character at a time,
2524 and whether, given a valid sequence of external characters, it's
2525 possible to pick off internal characters one at a time. Or, to put it
2526 differently: given a sequence of external characters and the
2527 corresponding sequence of internal characters, does a position in the
2528 internal sequence correspond to some position in the external
2529 sequence? </p>
2530
2531 <p>To make this concrete, suppose that <tt>[first, last)</tt> is a
2532 sequence of <i>M</i> external characters and that <tt>[ifirst,
2533 ilast)</tt> is the corresponding sequence of <i>N</i> internal
2534 characters, where <i>N &gt; 1</i>. That is, <tt>my_encoding.in()</tt>,
2535 applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
2536 ilast)</tt>. Now the question: does there necessarily exist a
2537 subsequence of external characters, <tt>[first, last_1)</tt>, such
2538 that the corresponding sequence of internal characters is the single
2539 character <tt>*ifirst</tt>?
2540 </p>
2541
2542 <p>(What a "no" answer would mean is that
2543 <tt>my_encoding</tt> translates sequences only as blocks. There's a
2544 sequence of <i>M</i> external characters that maps to a sequence of
2545 <i>N</i> internal characters, but that external sequence has no
2546 subsequence that maps to <i>N-1</i> internal characters.) </p>
2547
2548 <p>Some of the wording in the standard, such as the description of
2549 <tt>codecvt::do_max_length</tt> (22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>,
2550 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
2551 possible to pick off internal characters one at a time from a sequence
2552 of external characters. However, this is never explicitly stated one
2553 way or the other. </p>
2554
2555 <p>This issue seems (and is) quite technical, but it is important if
2556 we expect users to provide their own encoding facets. This is an area
2557 where the standard library calls user-supplied code, so a well-defined
2558 set of requirements for the user-supplied code is crucial. Users must
2559 be aware of the assumptions that the library makes. This issue affects
2560 positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
2561 and several of <tt>codecvt</tt>'s member functions. </p>
2562 <p><b>Proposed resolution:</b></p>
2563 <p>Add the following text as a new paragraph, following 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 2:</p>
2564
2565 <blockquote>
2566 <p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
2567 (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>
2568 <pre>    do_out(state, from, from_end, from_next, to, to_lim, to_next)
2569 </pre>
2570 would return <tt>ok</tt>, where <tt>from != from_end</tt>, then
2571 <pre>    do_out(state, from, from + 1, from_next, to, to_end, to_next)
2572 </pre>
2573 must also return <tt>ok</tt>, and that if
2574 <pre>    do_in(state, from, from_end, from_next, to, to_lim, to_next)
2575 </pre>
2576 would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then
2577 <pre>    do_in(state, from, from_end, from_next, to, to + 1, to_next)
2578 </pre>
2579 <p>must also return <tt>ok</tt>.  [<i>Footnote:</i> Informally, this
2580 means that <tt>basic_filebuf</tt> assumes that the mapping from
2581 internal to external characters is 1 to N: a <tt>codecvt</tt> that is
2582 used by <tt>basic_filebuf</tt> must be able to translate characters
2583 one internal character at a time.  <i>--End Footnote</i>]</p>
2584 </blockquote>
2585
2586 <p><i>[Redmond: Minor change in proposed resolution.  Original
2587 proposed resolution talked about "success", with a parenthetical
2588 comment that success meant returning <tt>ok</tt>.  New wording
2589 removes all talk about "success", and just talks about the
2590 return value.]</i></p>
2591
2592 <p><b>Rationale:</b></p>
2593
2594   <p>The proposed resoluion says that conversions can be performed one
2595   internal character at a time.  This rules out some encodings that
2596   would otherwise be legal.  The alternative answer would mean there
2597   would be some internal positions that do not correspond to any
2598   external file position.</p>
2599   <p>
2600   An example of an encoding that this rules out is one where the
2601   <tt>internT</tt> and <tt>externT</tt> are of the same type, and
2602   where the internal sequence <tt>c1 c2</tt> corresponds to the
2603   external sequence <tt>c2 c1</tt>.
2604   </p>
2605   <p>It was generally agreed that <tt>basic_filebuf</tt> relies
2606   on this property: it was designed under the assumption that
2607   the external-to-internal mapping is N-to-1, and it is not clear
2608   that <tt>basic_filebuf</tt> is implementable without that
2609   restriction.
2610   </p>
2611   <p>
2612   The proposed resolution is expressed as a restriction on
2613   <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
2614   than a blanket restriction on all <tt>codecvt</tt> facets,
2615   because <tt>basic_filebuf</tt> is the only other part of the
2616   library that uses <tt>codecvt</tt>.  If a user wants to define
2617   a <tt>codecvt</tt> facet that implements a more general N-to-M
2618   mapping, there is no reason to prohibit it, so long as the user
2619   does not expect <tt>basic_filebuf</tt> to be able to use it.
2620   </p>
2621 <hr>
2622 <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>
2623 <p>typo: event_call_back should be event_callback &nbsp; </p>
2624 <p><b>Proposed resolution:</b></p>
2625 <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
2626 "event_call_back" to "event_callback". </p>
2627 <hr>
2628 <a name="79"><h3>79.&nbsp;Inconsistent declaration of polar()</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.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.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>
2629 <p>In 26.2.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>
2630 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;); </pre>
2631
2632 <p>In 26.2.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>
2633 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
2634
2635 <p>Thus whether the second parameter is optional is not clear. </p>
2636 <p><b>Proposed resolution:</b></p>
2637 <p>In 26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> change:</p>
2638 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;);</pre>
2639
2640 <p>to:</p>
2641 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
2642 <hr>
2643 <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.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.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;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2644 <p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
2645 class complex. This redundancy should be removed.</p>
2646 <p><b>Proposed resolution:</b></p>
2647 <p>Reduce redundancy according to the general style of the standard. </p>
2648 <hr>
2649 <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>
2650 <p>Many string member functions throw if size is getting or exceeding
2651 npos. However, I wonder why they don't throw if size is getting or
2652 exceeding max_size() instead of npos.  May be npos is known at compile
2653 time, while max_size() is known at runtime. However, what happens if
2654 size exceeds max_size() but not npos, then? It seems the standard
2655 lacks some clarifications here.</p>
2656 <p><b>Proposed resolution:</b></p>
2657 <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
2658 described in this clause...") add a new paragraph:</p>
2659
2660 <blockquote>
2661   <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
2662   <tt> max_size()</tt> then
2663   the operation throws <tt>length_error</tt>.</p>
2664 </blockquote>
2665 <p><b>Rationale:</b></p>
2666 <p>The LWG believes length_error is the correct exception to throw.</p>
2667 <hr>
2668 <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>
2669 <p>The constructor from a range:</p>
2670
2671 <pre>template&lt;class InputIterator&gt;
2672          basic_string(InputIterator begin, InputIterator end,
2673                       const Allocator&amp; a = Allocator());</pre>
2674
2675 <p>lacks a throws clause. However, I would expect that it throws
2676 according to the other constructors if the numbers of characters in
2677 the range equals npos (or exceeds max_size(), see above). </p>
2678 <p><b>Proposed resolution:</b></p>
2679 <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
2680 constructors which say "Throws: length_error if n ==
2681 npos."</p>
2682 <p><b>Rationale:</b></p>
2683 <p>Throws clauses for length_error if n == npos are no longer needed
2684 because they are subsumed by the general wording added by the
2685 resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
2686 <hr>
2687 <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>
2688 <p>The effect of operator &gt;&gt; for strings contain the following item:</p>
2689
2690 <p>&nbsp;&nbsp;&nbsp; <tt>isspace(c,getloc())</tt> is true for the next available input
2691 character c.</p>
2692
2693 <p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
2694 <p><b>Proposed resolution:</b></p>
2695 <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>
2696
2697 <blockquote>
2698   <p><tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
2699 </blockquote>
2700
2701 <p>with:</p>
2702
2703 <blockquote>
2704   <p><tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
2705 </blockquote>
2706 <hr>
2707 <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>
2708 <p>Operator &gt;&gt; and getline() for strings read until eof()
2709 in the input stream is true. However, this might never happen, if the
2710 stream can't read anymore without reaching EOF. So shouldn't it be
2711 changed into that it reads until !good() ? </p>
2712 <p><b>Proposed resolution:</b></p>
2713 <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>
2714 <blockquote>
2715 Effects: Begins by constructing a sentry object k as if k were
2716 constructed by typename basic_istream&lt;charT,traits&gt;::sentry k( is). If
2717 bool( k) is true, it calls str.erase() and then extracts characters
2718 from is and appends them to str as if by calling str.append(1, c). If
2719 is.width() is greater than zero, the maximum number n of characters
2720 appended is is.width(); otherwise n is str.max_size(). Characters are
2721 extracted and appended until any of the following occurs:
2722 </blockquote>
2723 <p>with:</p>
2724 <blockquote>
2725 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
2726 sentry converts to true, calls str.erase() and then extracts
2727 characters from is and appends them to str as if by calling
2728 str.append(1,c). If is.width() is greater than zero, the maximum
2729 number n of characters appended is is.width(); otherwise n is
2730 str.max_size(). Characters are extracted and appended until any of the
2731 following occurs:
2732 </blockquote>
2733
2734 <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>
2735 <blockquote>
2736 Effects: Begins by constructing a sentry object k as if by typename
2737 basic_istream&lt;charT,traits&gt;::sentry k( is, true). If bool( k) is true,
2738 it calls str.erase() and then extracts characters from is and appends
2739 them to str as if by calling str.append(1, c) until any of the
2740 following occurs:
2741 </blockquote>
2742 <p>with:</p>
2743 <blockquote>
2744 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
2745 by subsequent calls to basic_istream&lt;&gt;::gcount().  After
2746 constructing a sentry object, if the sentry converts to true, calls
2747 str.erase() and then extracts characters from is and appends them to
2748 str as if by calling str.append(1,c) until any of the following
2749 occurs:
2750 </blockquote>
2751
2752 <p><i>[Redmond: Made changes in proposed resolution.  <tt>operator&gt;&gt;</tt>
2753 should be a formatted input function, not an unformatted input function.
2754 <tt>getline</tt> should not be required to set <tt>gcount</tt>, since
2755 there is no mechanism for <tt>gcount</tt> to be set except by one of
2756 <tt>basic_istream</tt>'s member functions.]</i></p>
2757
2758 <p><i>[Curaçao: Nico agrees with proposed resolution.]</i></p>
2759
2760 <p><b>Rationale:</b></p>
2761 <p>The real issue here is whether or not these string input functions
2762 get their characters from a streambuf, rather than by calling an
2763 istream's member functions, a streambuf signals failure either by
2764 returning eof or by throwing an exception; there are no other
2765 possibilities.  The proposed resolution makes it clear that these two
2766 functions do get characters from a streambuf.</p>
2767 <hr>
2768 <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>
2769 <p>The standard does not state, how often a function object is copied,
2770 called, or the order of calls inside an algorithm. This may lead to
2771 surprising/buggy behavior. Consider the following example: </p>
2772
2773 <pre>class Nth {    // function object that returns true for the nth element
2774   private:
2775     int nth;     // element to return true for
2776     int count;   // element counter
2777   public:
2778     Nth (int n) : nth(n), count(0) {
2779     }
2780     bool operator() (int) {
2781         return ++count == nth;
2782     }
2783 };
2784 ....
2785 // remove third element
2786     list&lt;int&gt;::iterator pos;
2787     pos = remove_if(coll.begin(),coll.end(),  // range
2788                     Nth(3)),                  // remove criterion
2789     coll.erase(pos,coll.end()); </pre>
2790
2791 <p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
2792 happens because the usual implementation of the algorithm copies the
2793 function object internally: </p>
2794
2795 <pre>template &lt;class ForwIter, class Predicate&gt;
2796 ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op)
2797 {
2798     beg = find_if(beg, end, op);
2799     if (beg == end) {
2800         return beg;
2801     }
2802     else {
2803         ForwIter next = beg;
2804         return remove_copy_if(++next, end, beg, op);
2805     }
2806 } </pre>
2807
2808 <p>The algorithm uses find_if() to find the first element that should
2809 be removed. However, it then uses a copy of the passed function object
2810 to process the resulting elements (if any). Here, Nth is used again
2811 and removes also the sixth element. This behavior compromises the
2812 advantage of function objects being able to have a state. Without any
2813 cost it could be avoided (just implement it directly instead of
2814 calling find_if()). </p>
2815 <p><b>Proposed resolution:</b></p>
2816
2817 <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>
2818 <blockquote>
2819 [Note: Unless otherwise specified, algorithms that take function
2820 objects as arguments are permitted to copy those function objects
2821 freely.  Programmers for whom object identity is important should
2822 consider using a wrapper class that points to a noncopied
2823 implementation object, or some equivalent solution.]
2824 </blockquote>
2825
2826 <p><i>[Dublin: Pete Becker felt that this may not be a defect,
2827 but rather something that programmers need to be educated about.
2828 There was discussion of adding wording to the effect that the number
2829 and order of calls to function objects, including predicates, not
2830 affect the behavior of the function object.]</i></p>
2831
2832 <p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
2833 have a clear statement of "predicate" in the
2834 standard. People including me seemed to think "a function
2835 returning a Boolean value and being able to be called by an STL
2836 algorithm or be used as sorting criterion or ... is a
2837 predicate". But a predicate has more requirements: It should
2838 never change its behavior due to a call or being copied. IMHO we have
2839 to state this in the standard. If you like, see section 8.1.4 of my
2840 library book for a detailed discussion.]</i></p>
2841
2842 <p><i>[Kona: Nico will provide wording to the effect that "unless
2843 otherwise specified, the number of copies of and calls to function
2844 objects by algorithms is unspecified".&nbsp; Consider placing in
2845 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>
2846
2847 <p><i>[Santa Cruz: The standard doesn't currently guarantee that
2848   functions object won't be copied, and what isn't forbidden is
2849   allowed.  It is believed (especially since implementations that were
2850   written in concert with the standard do make copies of function
2851   objects) that this was intentional.  Thus, no normative change is
2852   needed.  What we should put in is a non-normative note suggesting to
2853   programmers that if they want to guarantee the lack of copying they
2854   should use something like the <tt>ref</tt> wrapper.]</i></p>
2855
2856 <p><i>[Oxford: Matt provided wording.]</i></p>
2857
2858
2859 <hr>
2860 <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>
2861 <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
2862 <tt>*r++</tt> of:</p>
2863
2864 <p>&nbsp;&nbsp; <tt>{ T tmp = *r; ++r; return tmp; }</tt></p>
2865
2866 <p>There are two problems with this.  First, the return type is
2867 specified to be "T", as opposed to something like "convertible to T".
2868 This is too specific: we want to allow *r++ to return an lvalue.</p>
2869
2870 <p>Second, writing the semantics in terms of code misleadingly
2871 suggests that the effects *r++ should precisely replicate the behavior
2872 of this code, including side effects.  (Does this mean that *r++
2873 should invoke the copy constructor exactly as many times as the sample
2874 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
2875 problem.</p>
2876
2877 <p><b>Proposed resolution:</b></p>
2878 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
2879 for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".
2880 <p><b>Rationale:</b></p>
2881 <p>This issue has two parts: the return type, and the number of times
2882   the copy constructor is invoked.</p>
2883
2884 <p>The LWG believes the the first part is a real issue.  It's
2885   inappropriate for the return type to be specified so much more
2886   precisely for *r++ than it is for *r.  In particular, if r is of
2887   (say) type <tt>int*</tt>, then *r++ isn't <tt>int</tt>,
2888   but <tt>int&amp;</tt>.</p>
2889
2890 <p>The LWG does not believe that the number of times the copy
2891   constructor is invoked is a real issue.  This can vary in any case,
2892   because of language rules on copy constructor elision.  That's too
2893   much to read into these semantics clauses.</p>
2894
2895 <p>Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since
2896    we're told (24.1/3) that forward iterators satisfy all the requirements
2897    of input iterators, we can't impose any requirements in the Input
2898    Iterator requirements table that forward iterators don't satisfy.</p>
2899 <hr>
2900 <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>
2901 <p>Set::iterator is described as implementation-defined with a
2902 reference to the container requirement; the container requirement says
2903 that const_iterator is an iterator pointing to const T and iterator an
2904 iterator pointing to T.</p>
2905
2906 <p>23.1.2 paragraph 2 implies that the keys should not be modified to
2907 break the ordering of elements. But that is not clearly
2908 specified. Especially considering that the current standard requires
2909 that iterator for associative containers be different from
2910 const_iterator. Set, for example, has the following: </p>
2911
2912 <p><tt>typedef implementation defined iterator;<br>
2913 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // See _lib.container.requirements_</tt></p>
2914
2915 <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
2916 to T (table 65). Disallowing user modification of keys by changing the
2917 standard to require an iterator for associative container to be the
2918 same as const_iterator would be overkill since that will unnecessarily
2919 significantly restrict the usage of associative container. A class to
2920 be used as elements of set, for example, can no longer be modified
2921 easily without either redesigning the class (using mutable on fields
2922 that have nothing to do with ordering), or using const_cast, which
2923 defeats requiring iterator to be const_iterator. The proposed solution
2924 goes in line with trusting user knows what he is doing. </p>
2925
2926 <p><b>Other Options Evaluated:</b> </p>
2927
2928 <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
2929 first sentence, and before "In addition,...", add one line:
2930 </p>
2931
2932 <blockquote>
2933   <p>Modification of keys shall not change their strict weak ordering. </p>
2934 </blockquote>
2935
2936 <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>
2937
2938 <blockquote>
2939   <p>At the end of paragraph 5: "Keys in an associative container
2940   are immutable." At the end of paragraph 6: "For
2941   associative containers where the value type is the same as the key
2942   type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
2943   constant iterators. It is unspecified whether or not
2944   <tt>iterator</tt> and <tt>const_iterator</tt> are the same
2945   type."</p>
2946 </blockquote>
2947
2948 <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
2949 currently reads:</p>
2950
2951 <blockquote>
2952   <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
2953   comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
2954   container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
2955   == false &amp;&amp; comp(k2, k1) == false.</p>
2956 </blockquote>
2957
2958 <p>&nbsp; add the following:</p>
2959
2960 <blockquote>
2961   <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
2962   value whenever it is evaluated. [Note: If k2 is removed from the container and later
2963   reinserted, comp(k1, k2) must still return a consistent value but this value may be
2964   different than it was the first time k1 and k2 were in the same container. This is
2965   intended to allow usage like a string key that contains a filename, where comp compares
2966   file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
2967   reinserted, comp(k1, k2) must again return a consistent value but this value may be
2968   different than it was the previous time k2 was in the container.]</p>
2969 </blockquote>
2970 <p><b>Proposed resolution:</b></p>
2971 <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
2972 the indicated location:</p>
2973
2974 <blockquote>
2975   <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
2976   calling comp(k1, k2) shall always return the same
2977   value."</p>
2978   <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
2979   <p>At the end of paragraph 6: "For associative containers where the value type is the
2980   same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
2981   iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
2982   are the same type."</p>
2983 </blockquote>
2984 <p><b>Rationale:</b></p>
2985 <p>Several arguments were advanced for and against allowing set elements to be
2986 mutable as long as the ordering was not effected. The argument which swayed the
2987 LWG was one of safety; if elements were mutable, there would be no compile-time
2988 way to detect of a simple user oversight which caused ordering to be
2989 modified.  There was a report that this had actually happened in practice,
2990 and had been painful to diagnose.  If users need to modify elements,
2991 it is possible to use mutable members or const_cast.</p>
2992
2993 <p>Simply requiring that keys be immutable is not sufficient, because the comparison
2994 object may indirectly (via pointers) operate on values outside of the keys.</p>
2995
2996 <p>
2997 The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
2998 to be different types to allow for potential future work in which some
2999 member functions might be overloaded between the two types.  No such
3000 member functions exist now, and the LWG believes that user functionality
3001 will not be impaired by permitting the two types to be the same.  A
3002 function that operates on both iterator types can be defined for
3003 <tt>const_iterator</tt> alone, and can rely on the automatic
3004 conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
3005 </p>
3006
3007 <p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
3008 <hr>
3009 <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.template.slice.array"> [lib.template.slice.array]</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>
3010 <p>This is the only place in the whole standard where the implementation has to document
3011 something private.</p>
3012 <p><b>Proposed resolution:</b></p>
3013 <p>
3014 Remove the comment which says "// remainder implementation defined" from:
3015 </p>
3016
3017 <ul>
3018   <li>26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>
3019 </li>
3020   <li>26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a>
3021 </li>
3022   <li>26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a>
3023 </li>
3024   <li>26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
3025 </li>
3026 </ul>
3027 <hr>
3028 <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.exception"> [lib.exception]</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>
3029 <p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
3030 exception::what() is left unspecified. This issue has implications
3031 with exception safety of exception handling: some exceptions should
3032 not throw bad_alloc.</p>
3033 <p><b>Proposed resolution:</b></p>
3034 <p>Add to 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.exception"> [lib.exception]</a> paragraph 9 (exception::what notes
3035 clause) the sentence:</p>
3036
3037 <blockquote>
3038   <p>The return value remains valid until the exception object from which it is obtained is
3039   destroyed or a non-const member function of the exception object is called.</p>
3040 </blockquote>
3041 <p><b>Rationale:</b></p>
3042 <p>If an exception object has non-const members, they may be used
3043 to set internal state that should affect the contents of the string
3044 returned by <tt>what()</tt>.
3045 </p>
3046 <hr>
3047 <a name="109"><h3>109.&nbsp;Missing binders for non-const sequence elements</h3></a><p><b>Section:</b>&nbsp;20.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binders"> [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;Bjarne Stroustrup&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
3048
3049 <p>There are no versions of binders that apply to non-const elements
3050 of a sequence. This makes examples like for_each() using bind2nd() on
3051 page 521 of "The C++ Programming Language (3rd)"
3052 non-conforming. Suitable versions of the binders need to be added.</p>
3053
3054 <p>Further discussion from Nico:</p>
3055
3056 <p>What is probably meant here is shown in the following example:</p>
3057
3058 <pre>class Elem {
3059   public:
3060     void print (int i) const { }
3061     void modify (int i) { }
3062 }; </pre>
3063 <pre>int main()
3064 {
3065     vector&lt;Elem&gt; coll(2);
3066     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::print),42));    // OK
3067     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::modify),42));   // ERROR
3068 }</pre>
3069
3070 <p>The error results from the fact that bind2nd() passes its first
3071 argument (the argument of the sequence) as constant reference. See the
3072 following typical implementation:</p>
3073
3074 <blockquote>
3075   <pre>template &lt;class Operation&gt;
3076 class binder2nd
3077   : public unary_function&lt;typename Operation::first_argument_type,
3078                           typename Operation::result_type&gt; {
3079 protected:
3080   Operation op;
3081   typename Operation::second_argument_type value;
3082 public:
3083   binder2nd(const Operation&amp; o,
3084             const typename Operation::second_argument_type&amp; v)
3085       : op(o), value(v) {} </pre>
3086   <pre> typename Operation::result_type
3087   operator()(const typename Operation::first_argument_type&amp; x) const {
3088     return op(x, value);
3089   }
3090 };</pre>
3091 </blockquote>
3092
3093 <p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
3094
3095 <blockquote>
3096   <pre>template &lt;class Operation&gt;
3097 class binder2nd
3098   : public unary_function&lt;typename Operation::first_argument_type,
3099                           typename Operation::result_type&gt; {
3100 protected:
3101   Operation op;
3102   typename Operation::second_argument_type value;
3103 public:
3104   binder2nd(const Operation&amp; o,
3105             const typename Operation::second_argument_type&amp; v)
3106       : op(o), value(v) {} </pre>
3107   <pre> typename Operation::result_type
3108   operator()(const typename Operation::first_argument_type&amp; x) const {
3109     return op(x, value);
3110   }
3111   typename Operation::result_type
3112   operator()(typename Operation::first_argument_type&amp; x) const {
3113     return op(x, value);
3114   }
3115 };</pre>
3116 </blockquote>
3117 <p><b>Proposed resolution:</b></p>
3118
3119 <p><b>Howard believes there is a flaw</b> in this resolution.
3120 See c++std-lib-9127.  We may need to reopen this issue.</p>
3121
3122 <p>In 20.3.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binder.1st"> [lib.binder.1st]</a> in the declaration of binder1st after:</p>
3123 <blockquote>
3124   <p><tt>typename Operation::result_type<br>
3125   &nbsp;operator()(const typename Operation::second_argument_type&amp; x) const;</tt></p>
3126 </blockquote>
3127 <p>insert:</p>
3128 <blockquote>
3129   <p><tt>typename Operation::result_type<br>
3130   &nbsp;operator()(typename Operation::second_argument_type&amp; x) const;</tt></p>
3131 </blockquote>
3132 <p>In 20.3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binder.2nd"> [lib.binder.2nd]</a> in the declaration of binder2nd after:</p>
3133 <blockquote>
3134   <p><tt>typename Operation::result_type<br>
3135   &nbsp;operator()(const typename Operation::first_argument_type&amp; x) const;</tt></p>
3136 </blockquote>
3137 <p>insert:</p>
3138 <blockquote>
3139   <p><tt>typename Operation::result_type<br>
3140   &nbsp;operator()(typename Operation::first_argument_type&amp; x) const;</tt></p>
3141 </blockquote>
3142
3143 <p><i>[Kona: The LWG discussed this at some length.It was agreed that
3144 this is a mistake in the design, but there was no consensus on whether
3145 it was a defect in the Standard.  Straw vote: NAD - 5.  Accept
3146 proposed resolution - 3.  Leave open - 6.]</i></p>
3147
3148 <p><i>[Copenhagen: It was generally agreed that this was a defect.
3149 Strap poll: NAD - 0.  Accept proposed resolution - 10.
3150 Leave open - 1.]</i></p>
3151
3152 <hr>
3153 <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>
3154 <p>Member istreambuf_iterator&lt;&gt;::equal is not declared
3155 "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==,
3156 which is const, calls it. This is contradictory. </p>
3157 <p><b>Proposed resolution:</b></p>
3158 <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>,
3159 replace:</p>
3160
3161 <blockquote>
3162   <pre>bool equal(istreambuf_iterator&amp; b);</pre>
3163 </blockquote>
3164
3165 <p>with:</p>
3166
3167 <blockquote>
3168   <pre>bool equal(const istreambuf_iterator&amp; b) const;</pre>
3169 </blockquote>
3170 <hr>
3171 <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>
3172 <p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
3173 constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
3174 reads "<i>s</i> is not null". However, <i>s</i> is a
3175 reference, and references can't be null. </p>
3176 <p><b>Proposed resolution:</b></p>
3177 <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>
3178
3179 <p>Move the current paragraph 1, which reads "Requires: s is not
3180 null.", from the first constructor to the second constructor.</p>
3181
3182 <p>Insert a new paragraph 1 Requires clause for the first constructor
3183 reading:</p>
3184
3185 <blockquote>
3186   <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
3187 </blockquote>
3188 <hr>
3189 <a name="114"><h3>114.&nbsp;Placement forms example in error twice</h3></a><p><b>Section:</b>&nbsp;18.4.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>
3190 <p>Section 18.4.1.3 contains the following example: </p>
3191
3192 <pre>[Example: This can be useful for constructing an object at a known address:
3193         char place[sizeof(Something)];
3194         Something* p = new (place) Something();
3195  -end example]</pre>
3196
3197 <p>First code line: "place" need not have any special alignment, and the
3198 following constructor could fail due to misaligned data.</p>
3199
3200 <p>Second code line: Aren't the parens on Something() incorrect?&nbsp; [Dublin: the LWG
3201 believes the () are correct.]</p>
3202
3203 <p>Examples are not normative, but nevertheless should not show code that is invalid or
3204 likely to fail.</p>
3205 <p><b>Proposed resolution:</b></p>
3206 <p>Replace the <u> first line of code</u> in the example in
3207 18.4.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:
3208 </p>
3209
3210 <blockquote>
3211   <pre>void* place = operator new(sizeof(Something));</pre>
3212 </blockquote>
3213 <hr>
3214 <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>
3215 <p>D.7.4.1 strstream constructors paragraph 2 says: </p>
3216
3217 <blockquote>
3218   <p>Effects: Constructs an object of class strstream, initializing the base class with
3219   iostream(&amp; sb) and initializing sb with one of the two constructors: </p>
3220   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
3221   elements. The constructor is strstreambuf(s, n, s). </p>
3222   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
3223   elements that contains an NTBS whose first element is designated by s. The constructor is
3224   strstreambuf(s, n, s+std::strlen(s)).</p>
3225 </blockquote>
3226
3227 <p>Notice the second condition is the same as the first. I think the second condition
3228 should be "If mode&amp;app==app", or "mode&amp;app!=0", meaning that
3229 the append bit is set.</p>
3230 <p><b>Proposed resolution:</b></p>
3231 <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>
3232 paragraph 2, change the first condition to <tt>(mode&amp;app)==0</tt>
3233 and the second condition to <tt>(mode&amp;app)!=0</tt>.</p>
3234 <hr>
3235 <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>
3236 <p>The <b>effects</b> clause for numeric inserters says that
3237 insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
3238 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
3239 int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
3240 <tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
3241 delegated to <tt>num_put</tt>, and that insertion is performed as if
3242 through the following code fragment: </p>
3243
3244 <pre>bool failed = use_facet&lt;
3245    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3246    &gt;(getloc()).put(*this, *this, fill(), val). failed();</pre>
3247
3248 <p>This doesn't work, because <tt>num_put&lt;&gt;</tt>::put is only
3249 overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
3250 long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
3251 void*</tt>. That is, the code fragment in the standard is incorrect
3252 (it is diagnosed as ambiguous at compile time) for the types
3253 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
3254 int</tt>, and <tt>float</tt>. </p>
3255
3256 <p>We must either add new member functions to <tt>num_put</tt>, or
3257 else change the description in <tt>ostream</tt> so that it only calls
3258 functions that are actually there. I prefer the latter. </p>
3259 <p><b>Proposed resolution:</b></p>
3260 <p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
3261
3262 <blockquote>
3263 <p>
3264 The classes num_get&lt;&gt; and num_put&lt;&gt; handle localedependent numeric
3265 formatting and parsing.  These inserter functions use the imbued
3266 locale value to perform numeric formatting.  When val is of type bool,
3267 long, unsigned long, double, long double, or const void*, the
3268 formatting conversion occurs as if it performed the following code
3269 fragment:
3270 </p>
3271
3272 <pre>bool failed = use_facet&lt;
3273    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3274    &gt;(getloc()).put(*this, *this, fill(), val). failed();
3275 </pre>
3276
3277 <p>
3278 When val is of type short the formatting conversion occurs as if it
3279 performed the following code fragment:
3280 </p>
3281
3282 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
3283 bool failed = use_facet&lt;
3284    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3285    &gt;(getloc()).put(*this, *this, fill(),
3286       baseflags == ios_base::oct || baseflags == ios_base::hex
3287          ? static_cast&lt;long&gt;(static_cast&lt;unsigned short&gt;(val))
3288          : static_cast&lt;long&gt;(val)). failed();
3289 </pre>
3290
3291 <p>
3292 When val is of type int the formatting conversion occurs as if it performed
3293 the following code fragment:
3294 </p>
3295
3296 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
3297 bool failed = use_facet&lt;
3298    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3299    &gt;(getloc()).put(*this, *this, fill(),
3300       baseflags == ios_base::oct || baseflags == ios_base::hex
3301          ? static_cast&lt;long&gt;(static_cast&lt;unsigned int&gt;(val))
3302          : static_cast&lt;long&gt;(val)). failed();
3303 </pre>
3304
3305 <p>
3306 When val is of type unsigned short or unsigned int the formatting conversion
3307 occurs as if it performed the following code fragment:
3308 </p>
3309
3310 <pre>bool failed = use_facet&lt;
3311    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3312    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;unsigned long&gt;(val)).
3313 failed();
3314 </pre>
3315
3316 <p>
3317 When val is of type float the formatting conversion occurs as if it
3318 performed the following code fragment:
3319 </p>
3320
3321 <pre>bool failed = use_facet&lt;
3322    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3323    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;double&gt;(val)).
3324 failed();
3325 </pre>
3326
3327 </blockquote>
3328
3329 <p><i>[post-Toronto: This differs from the previous proposed
3330 resolution; PJP provided the new wording.  The differences are in
3331 signed short and int output.]</i></p>
3332 <p><b>Rationale:</b></p>
3333 <p>The original proposed resolution was to cast int and short to long,
3334 unsigned int and unsigned short to unsigned long, and float to double,
3335 thus ensuring that we don't try to use nonexistent num_put&lt;&gt;
3336 member functions.  The current proposed resolution is more
3337 complicated, but gives more expected results for hex and octal output
3338 of signed short and signed int.  (On a system with 16-bit short, for
3339 example, printing short(-1) in hex format should yield 0xffff.)</p>
3340 <hr>
3341 <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>
3342 <p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
3343 <tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
3344 <tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
3345 formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
3346
3347 <pre>typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3348 iostate err = 0;
3349 use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, val);
3350 setstate(err);</pre>
3351
3352 <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,
3353 <tt>num_get&lt;&gt;::get()</tt> is only overloaded for the types
3354 <tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
3355 int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
3356 <tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
3357 <tt>void*</tt>. Comparing the lists from the two sections, we find
3358 that 27.6.1.2.2 is using a nonexistent function for types
3359 <tt>short</tt> and <tt>int</tt>. </p>
3360 <p><b>Proposed resolution:</b></p>
3361 <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
3362 two lines (1st and 3rd) which read:</p>
3363 <blockquote>
3364   <pre>operator&gt;&gt;(short&amp; val);
3365 ...
3366 operator&gt;&gt;(int&amp; val);</pre>
3367 </blockquote>
3368
3369 <p>And add the following at the end of that section (27.6.1.2.2) :</p>
3370
3371 <blockquote>
3372   <pre>operator&gt;&gt;(short&amp; val);</pre>
3373   <p>The conversion occurs as if performed by the following code fragment (using
3374   the same notation as for the preceding code fragment):</p>
3375   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3376   iostate err = 0;
3377   long lval;
3378   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
3379         if (err == 0
3380                 &amp;&amp; (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval))
3381                 err = ios_base::failbit;
3382   setstate(err);</pre>
3383   <pre>operator&gt;&gt;(int&amp; val);</pre>
3384   <p>The conversion occurs as if performed by the following code fragment (using
3385   the same notation as for the preceding code fragment):</p>
3386   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3387   iostate err = 0;
3388   long lval;
3389   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
3390         if (err == 0
3391                 &amp;&amp; (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval))
3392                 err = ios_base::failbit;
3393   setstate(err);</pre>
3394 </blockquote>
3395
3396 <p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
3397 <hr>
3398 <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>
3399 <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>
3400
3401 <p>"An implementation may strengthen the exception-specification
3402 for a function by removing listed exceptions." </p>
3403
3404 <p>The problem is that if an implementation is allowed to do this for
3405 virtual functions, then a library user cannot write a class that
3406 portably derives from that class. </p>
3407
3408 <p>For example, this would not compile if ios_base::failure::~failure
3409 had an empty exception specification: </p>
3410
3411 <pre>#include &lt;ios&gt;
3412 #include &lt;string&gt;
3413
3414 class D : public std::ios_base::failure {
3415 public:
3416         D(const std::string&amp;);
3417         ~D(); // error - exception specification must be compatible with
3418               // overridden virtual function ios_base::failure::~failure()
3419 };</pre>
3420 <p><b>Proposed resolution:</b></p>
3421 <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>
3422
3423 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
3424 exception-specification for a function"</p>
3425
3426 <p>to:</p>
3427
3428 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
3429 exception-specification for a non-virtual function". </p>
3430 <hr>
3431 <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>
3432
3433 <p>The original issue asked whether a library implementor could
3434 specialize standard library templates for built-in types.  (This was
3435 an issue because users are permitted to explicitly instantiate
3436 standard library templates.)</p>
3437
3438 <p>Specializations are no longer a problem, because of the resolution
3439 to core issue 259.  Under the proposed resolution, it will be legal
3440 for a translation unit to contain both a specialization and an
3441 explicit instantiation of the same template, provided that the
3442 specialization comes first.  In such a case, the explicit
3443 instantiation will be ignored.  Further discussion of library issue
3444 120 assumes that the core 259 resolution will be adopted.</p>
3445
3446 <p>However, as noted in lib-7047, one piece of this issue still
3447 remains: what happens if a standard library implementor explicitly
3448 instantiates a standard library templates?  It's illegal for a program
3449 to contain two different explicit instantiations of the same template
3450 for the same type in two different translation units (ODR violation),
3451 and the core working group doesn't believe it is practical to relax
3452 that restriction.</p>
3453
3454 <p>The issue, then, is: are users allowed to explicitly instantiate
3455 standard library templates for non-user defined types?  The status quo
3456 answer is 'yes'.  Changing it to 'no' would give library implementors
3457 more freedom.</p>
3458
3459 <p>This is an issue because, for performance reasons, library
3460 implementors often need to explicitly instantiate standard library
3461 templates.  (for example, std::basic_string&lt;char&gt;)  Does giving
3462 users freedom to explicitly instantiate standard library templates for
3463 non-user defined types make it impossible or painfully difficult for
3464 library implementors to do this?</p>
3465
3466 <p>John Spicer suggests, in lib-8957, that library implementors have a
3467 mechanism they can use for explicit instantiations that doesn't
3468 prevent users from performing their own explicit instantiations: put
3469 each explicit instantiation in its own object file.  (Different
3470 solutions might be necessary for Unix DSOs or MS-Windows DLLs.)  On
3471 some platforms, library implementors might not need to do anything
3472 special: the "undefined behavior" that results from having two
3473 different explicit instantiations might be harmless.</p>
3474
3475 <p><b>Proposed resolution:</b></p>
3476   <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>
3477   <blockquote>
3478     A program may explicitly instantiate any templates in the standard
3479     library only if the declaration depends on the name of a user-defined
3480     type of external linkage and the instantiation meets the standard library
3481     requirements for the original template.
3482   </blockquote>
3483
3484 <p><i>[Kona: changed the wording from "a user-defined name" to "the name of
3485   a user-defined type"]</i></p>
3486
3487 <p><b>Rationale:</b></p>
3488 <p>The LWG considered another possible resolution:</p>
3489 <blockquote>
3490   <p>In light of the resolution to core issue 259, no normative changes
3491   in the library clauses are necessary.  Add the following non-normative
3492   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>
3493   <blockquote>
3494     [<i>Note:</i> A program may explicitly instantiate standard library
3495     templates, even when an explicit instantiation does not depend on
3496     a user-defined name. <i>--end note</i>]
3497   </blockquote>
3498 </blockquote>
3499
3500 <p>The LWG rejected this because it was believed that it would make
3501   it unnecessarily difficult for library implementors to write
3502   high-quality implementations.  A program may not include an
3503   explicit instantiation of the same template, for the same template
3504   arguments, in two different translation units.  If users are
3505   allowed to provide explicit instantiations of Standard Library
3506   templates for built-in types, then library implementors aren't,
3507   at least not without nonportable tricks.</p>
3508
3509 <p>The most serious problem is a class template that has writeable
3510   static member variables.  Unfortunately, such class templates are
3511   important and, in existing Standard Library implementations, are
3512   often explicitly specialized by library implementors: locale facets,
3513   which have a writeable static member variable <tt>id</tt>.  If a
3514   user's explicit instantiation collided with the implementations
3515   explicit instantiation, iostream initialization could cause locales
3516   to be constructed in an inconsistent state.</p>
3517
3518 <p>One proposed implementation technique was for Standard Library
3519   implementors to provide explicit instantiations in separate object
3520   files, so that they would not be picked up by the linker when the
3521   user also provides an explicit instantiation.  However, this
3522   technique only applies for Standard Library implementations that
3523   are packaged as static archives.  Most Standard Library
3524   implementations nowadays are packaged as dynamic libraries, so this
3525   technique would not apply.</p>
3526
3527 <p>The Committee is now considering standardization of dynamic
3528   linking.  If there are such changes in the future, it may be
3529   appropriate to revisit this issue later.</p>
3530 <hr>
3531 <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>
3532 <p>Section 27.5.2 describes the streambuf classes this way: </p>
3533
3534 <blockquote>
3535
3536 <p>The class streambuf is a specialization of the template class basic_streambuf
3537 specialized for the type char. </p>
3538
3539 <p>The class wstreambuf is a specialization of the template class basic_streambuf
3540 specialized for the type wchar_t. </p>
3541
3542 </blockquote>
3543
3544 <p>This implies that these classes must be template specializations, not typedefs. </p>
3545
3546 <p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
3547 <p><b>Proposed resolution:</b></p>
3548 <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
3549 sentences). </p>
3550 <p><b>Rationale:</b></p>
3551 <p>The <tt>streambuf</tt>  synopsis already has a declaration for the
3552 typedefs and that is sufficient. </p>
3553 <hr>
3554 <a name="123"><h3>123.&nbsp;Should valarray helper arrays fill functions be const?</h3></a><p><b>Section:</b>&nbsp;26.3.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.3.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.3.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.3.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>
3555 <p>One of the operator= in the valarray helper arrays is const and one
3556 is not. For example, look at slice_array. This operator= in Section
3557 26.3.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>
3558
3559 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const valarray&lt;T&gt;&amp;) const;</tt> </p>
3560
3561 <p>but this one in Section 26.3.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>
3562
3563 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const T&amp;); </tt></p>
3564
3565 <p>The description of the semantics for these two functions is similar. </p>
3566 <p><b>Proposed resolution:</b></p>
3567
3568 <p>26.3.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>
3569 <blockquote>
3570
3571    <p>In the class template definition for slice_array, replace the member
3572    function declaration</p>
3573     <pre>      void operator=(const T&amp;);
3574     </pre>
3575    <p>with</p>
3576     <pre>      void operator=(const T&amp;) const;
3577     </pre>
3578 </blockquote>
3579
3580 <p>26.3.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>
3581 <blockquote>
3582
3583    <p>Change the function declaration</p>
3584     <pre>      void operator=(const T&amp;);
3585     </pre>
3586    <p>to</p>
3587     <pre>      void operator=(const T&amp;) const;
3588     </pre>
3589 </blockquote>
3590
3591 <p>26.3.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>
3592 <blockquote>
3593
3594    <p>In the class template definition for gslice_array, replace the member
3595    function declaration</p>
3596     <pre>      void operator=(const T&amp;);
3597     </pre>
3598    <p>with</p>
3599     <pre>      void operator=(const T&amp;) const;
3600     </pre>
3601 </blockquote>
3602
3603 <p>26.3.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>
3604 <blockquote>
3605
3606    <p>Change the function declaration</p>
3607     <pre>      void operator=(const T&amp;);
3608     </pre>
3609    <p>to</p>
3610     <pre>      void operator=(const T&amp;) const;
3611     </pre>
3612 </blockquote>
3613
3614 <p>26.3.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>
3615 <blockquote>
3616
3617    <p>In the class template definition for mask_array, replace the member
3618    function declaration</p>
3619     <pre>      void operator=(const T&amp;);
3620     </pre>
3621    <p>with</p>
3622     <pre>      void operator=(const T&amp;) const;
3623     </pre>
3624 </blockquote>
3625
3626 <p>26.3.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>
3627 <blockquote>
3628
3629    <p>Change the function declaration</p>
3630     <pre>      void operator=(const T&amp;);
3631     </pre>
3632    <p>to</p>
3633     <pre>      void operator=(const T&amp;) const;
3634     </pre>
3635 </blockquote>
3636
3637 <p>26.3.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>
3638 <blockquote>
3639
3640    <p>In the class template definition for indirect_array, replace the member
3641    function declaration</p>
3642     <pre>      void operator=(const T&amp;);
3643     </pre>
3644    <p>with</p>
3645     <pre>      void operator=(const T&amp;) const;
3646     </pre>
3647 </blockquote>
3648
3649 <p>26.3.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>
3650 <blockquote>
3651
3652    <p>Change the function declaration</p>
3653     <pre>      void operator=(const T&amp;);
3654     </pre>
3655    <p>to</p>
3656     <pre>      void operator=(const T&amp;) const;
3657     </pre>
3658 </blockquote>
3659
3660
3661 <p><i>[Redmond: Robert provided wording.]</i></p>
3662
3663 <p><b>Rationale:</b></p>
3664 <p>There's no good reason for one version of operator= being const and
3665 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
3666 matters: these functions are now callable in more circumstances.  In
3667 many existing implementations, both versions are already const.</p>
3668 <hr>
3669 <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>
3670 <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>
3671 ctype_byname&lt;charT&gt;::do_scan_is() and do_scan_not() are declared
3672 to return a const char* not a const charT*. </p>
3673 <p><b>Proposed resolution:</b></p>
3674 <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
3675 <tt>do_scan_not()</tt> to return a <tt> const
3676 charT*</tt>. </p>
3677 <hr>
3678 <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.template.valarray"> [lib.template.valarray]</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>
3679 <p>In Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> valarray&lt;T&gt;::operator!() is
3680 declared to return a valarray&lt;T&gt;, but in Section 26.3.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.unary"> [lib.valarray.unary]</a> it is declared to return a valarray&lt;bool&gt;. The
3681 latter appears to be correct. </p>
3682 <p><b>Proposed resolution:</b></p>
3683 <p>Change in Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> the declaration of
3684 <tt>operator!()</tt> so that the return type is
3685 <tt>valarray&lt;bool&gt;</tt>. </p>
3686 <hr>
3687 <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>
3688 <p>Typos in 22.2.1.1.2 need to be fixed.</p>
3689 <p><b>Proposed resolution:</b></p>
3690 <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>
3691
3692 <pre>   do_widen(do_narrow(c),0) == c</pre>
3693
3694 <p>to:</p>
3695
3696 <pre>   do_widen(do_narrow(c,0)) == c</pre>
3697
3698 <p>and change:</p>
3699
3700 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
3701
3702 <p>to:</p>
3703
3704 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
3705 <hr>
3706 <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.auto.ptr"> [lib.auto.ptr]</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>
3707 <p>There are two problems with the current <tt>auto_ptr</tt> wording
3708 in the standard: </p>
3709
3710 <p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
3711 because <tt>auto_ptr&lt;Derived&gt;::auto_ptr_ref</tt> is unrelated to
3712 <tt>auto_ptr&lt;Base&gt;::auto_ptr_ref</tt>.  <i>Also submitted by
3713 Nathan Myers, with the same proposed resolution.</i></p>
3714
3715 <p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
3716 <tt>auto_ptr_ref</tt> argument. </p>
3717
3718 <p>I have discussed these problems with my proposal coauthor, Bill
3719 Gibbons, and with some compiler and library implementors, and we
3720 believe that these problems are not desired or desirable implications
3721 of the standard. </p>
3722
3723 <p>25 Aug 1999: The proposed resolution now reflects changes suggested
3724 by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
3725 "assignment operator" to "public assignment
3726 operator", 2) changed effects to specify use of release(), 3)
3727 made the conversion to auto_ptr_ref const. </p>
3728
3729 <p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
3730 states that the conversion from auto_ptr to auto_ptr_ref should
3731 be const.  This is not acceptable, because it would allow
3732 initialization and assignment from _any_ const auto_ptr!  It also
3733 introduces an implementation difficulty in writing this conversion
3734 function -- namely, somewhere along the line, a const_cast will be
3735 necessary to remove that const so that release() may be called.  This
3736 may result in undefined behavior [7.1.5.1/4]. The conversion
3737 operator does not have to be const, because a non-const implicit
3738 object parameter may be bound to an rvalue [13.3.3.1.4/3]
3739 [13.3.1/5]. </p>
3740
3741   <p>Tokyo: The LWG removed the following from the proposed resolution:</p>
3742
3743   <p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, and 20.4.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr.conv"> [lib.auto.ptr.conv]</a>,
3744   paragraph 2, make the conversion to auto_ptr_ref const:</p>
3745   <blockquote>
3746     <pre>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() const throw();</pre>
3747   </blockquote>
3748 <p><b>Proposed resolution:</b></p>
3749 <p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, move
3750 the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
3751
3752 <p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, add
3753 a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
3754
3755 <blockquote>
3756   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</pre>
3757 </blockquote>
3758
3759 <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.auto.ptr.conv"> [lib.auto.ptr.conv]</a>: </p>
3760
3761 <blockquote>
3762   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw()</pre>
3763
3764   <b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
3765   p</tt> that <tt>r</tt> holds a reference to.<br>
3766   <b>Returns: </b><tt>*this</tt>.
3767
3768 </blockquote>
3769 <hr>
3770 <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>
3771 <p>Currently, the standard does not specify how seekg() and seekp()
3772 indicate failure. They are not required to set failbit, and they can't
3773 return an error indication because they must return *this, i.e. the
3774 stream. Hence, it is undefined what happens if they fail. And they
3775 <i>can</i> fail, for instance, when a file stream is disconnected from the
3776 underlying file (is_open()==false) or when a wide character file
3777 stream must perform a state-dependent code conversion, etc. </p>
3778
3779 <p>The stream functions seekg() and seekp() should set failbit in the
3780 stream state in case of failure.</p>
3781 <p><b>Proposed resolution:</b></p>
3782 <p>Add to the Effects: clause of&nbsp; seekg() in
3783 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
3784 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>
3785
3786 <blockquote>
3787   <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
3788   </p>
3789 </blockquote>
3790 <p><b>Rationale:</b></p>
3791 <p>Setting failbit is the usual error reporting mechanism for streams</p>
3792 <hr>
3793 <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>
3794 <p>Table 67 (23.1.1) says that container::erase(iterator) returns an
3795 iterator. Table 69 (23.1.2) says that in addition to this requirement,
3796 associative containers also say that container::erase(iterator)
3797 returns void.  That's not an addition; it's a change to the
3798 requirements, which has the effect of making associative containers
3799 fail to meet the requirements for containers.</p>
3800 <p><b>Proposed resolution:</b></p>
3801
3802 <p>
3803 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
3804 requirements, change the return type of <tt>a.erase(q)</tt> from
3805 <tt>void</tt> to <tt>iterator</tt>.  Change the
3806 assertion/not/pre/post-condition from "erases the element pointed to
3807 by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>.
3808 Returns an iterator pointing to the element immediately following q
3809 prior to the element being erased. If no such element exists, a.end()
3810 is returned."
3811 </p>
3812
3813 <p>
3814 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
3815 requirements, change the return type of <tt>a.erase(q1, q2)</tt>
3816 from <tt>void</tt> to <tt>iterator</tt>.  Change the
3817 assertion/not/pre/post-condition from "erases the elements in the
3818 range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1,
3819 q2)</tt>.  Returns q2."
3820 </p>
3821
3822 <p>
3823 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
3824 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
3825 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
3826 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:
3827 change the signature of the first <tt>erase</tt> overload to
3828 </p>
3829 <pre>   iterator erase(iterator position);
3830 </pre>
3831 <p>and change the signature of the third <tt>erase</tt> overload to</p>
3832 <pre>  iterator erase(iterator first, iterator last);
3833 </pre>
3834
3835
3836 <p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p>
3837
3838 <p><i>[Post-Kona: the LWG agrees the return type should be
3839 <tt>iterator</tt>, not <tt>void</tt>.  (Alex Stepanov agrees too.)
3840 Matt provided wording.]</i></p>
3841
3842 <p><i>[
3843  Sydney: the proposed wording went in the right direction, but it
3844  wasn't good enough. We want to return an iterator from the range form
3845  of erase as well as the single-iterator form. Also, the wording is
3846  slightly different from the wording we have for sequences; there's no
3847  good reason for having a difference.  Matt provided new wording,
3848  which we will review at the next meeting.
3849 ]</i></p>
3850
3851 <hr>
3852 <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.list.capacity"> [lib.list.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>
3853 <p>The description reads:</p>
3854
3855 <p>-1- Effects:</p>
3856
3857 <pre>         if (sz &gt; size())
3858            insert(end(), sz-size(), c);
3859          else if (sz &lt; size())
3860            erase(begin()+sz, end());
3861          else
3862            ;                           //  do nothing</pre>
3863
3864 <p>Obviously list::resize should not be specified in terms of random access iterators.</p>
3865 <p><b>Proposed resolution:</b></p>
3866 <p>Change 23.2.2.2 paragraph 1 to:</p>
3867
3868 <p>Effects:</p>
3869
3870 <pre>         if (sz &gt; size())
3871            insert(end(), sz-size(), c);
3872          else if (sz &lt; size())
3873          {
3874            iterator i = begin();
3875            advance(i, sz);
3876            erase(i, end());
3877          }</pre>
3878
3879 <p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
3880 with David Abrahams. They had a discussion and believe there is
3881 no issue of exception safety with the proposed resolution.]</i></p>
3882 <hr>
3883 <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>
3884 <p>The title says it all.</p>
3885 <p><b>Proposed resolution:</b></p>
3886 <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,
3887 after operator= in the map declaration:</p>
3888
3889 <pre>    allocator_type get_allocator() const;</pre>
3890 <hr>
3891 <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.vector.cons"> [lib.vector.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;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3892 <p>The complexity description says: "It does at most 2N calls to the copy constructor
3893 of T and logN reallocations if they are just input iterators ...".</p>
3894
3895 <p>This appears to be overly restrictive, dictating the precise memory/performance
3896 tradeoff for the implementor.</p>
3897 <p><b>Proposed resolution:</b></p>
3898 <p>Change 23.2.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a>, paragraph 1 to:</p>
3899
3900 <p>-1- Complexity: The constructor template &lt;class
3901 InputIterator&gt; vector(InputIterator first, InputIterator last)
3902 makes only N calls to the copy constructor of T (where N is the
3903 distance between first and last) and no reallocations if iterators
3904 first and last are of forward, bidirectional, or random access
3905 categories. It makes order N calls to the copy constructor of T and
3906 order logN reallocations if they are just input iterators.
3907 </p>
3908 <p><b>Rationale:</b></p>
3909 <p>"at most 2N calls" is correct only if the growth factor
3910 is greater than or equal to 2.
3911 </p>
3912 <hr>
3913 <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>
3914 <p>I may be misunderstanding the intent, but should not seekg set only
3915 the input stream and seekp set only the output stream? The description
3916 seems to say that each should set both input and output streams. If
3917 that's really the intent, I withdraw this proposal.</p>
3918 <p><b>Proposed resolution:</b></p>
3919 <p>In section 27.6.1.3 change:</p>
3920
3921 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
3922 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
3923
3924 <p>To:</p>
3925
3926 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
3927 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::in). </pre>
3928
3929 <p>In section 27.6.1.3 change:</p>
3930
3931 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
3932 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
3933
3934 <p>To:</p>
3935
3936 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
3937 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::in). </pre>
3938
3939 <p>In section 27.6.2.4, paragraph 2 change:</p>
3940
3941 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
3942
3943 <p>To:</p>
3944
3945 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::out). </pre>
3946
3947 <p>In section 27.6.2.4, paragraph 4 change:</p>
3948
3949 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
3950
3951 <p>To:</p>
3952
3953 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::out). </pre>
3954
3955 <p><i>[Dublin: Dietmar Kühl thinks this is probably correct, but would
3956 like the opinion of more iostream experts before taking action.]</i></p>
3957
3958 <p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
3959 incorrect, his implementation already implements the Proposed
3960 Resolution.]</i></p>
3961
3962 <p><i>[Post-Tokyo: Matt Austern comments:<br>
3963 Is it a problem with basic_istream and basic_ostream, or is it a problem
3964 with basic_stringbuf?
3965 We could resolve the issue either by changing basic_istream and
3966 basic_ostream, or by changing basic_stringbuf. I prefer the latter
3967 change (or maybe both changes): I don't see any reason for the standard to
3968 require that std::stringbuf s(std::string("foo"), std::ios_base::in);
3969 s.pubseekoff(0, std::ios_base::beg); must fail.<br>
3970 This requirement is a bit weird. There's no similar requirement
3971 for basic_streambuf&lt;&gt;::seekpos, or for basic_filebuf&lt;&gt;::seekoff or
3972 basic_filebuf&lt;&gt;::seekpos.]</i></p>
3973 <hr>
3974 <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>
3975 <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>
3976
3977 <p>-4- In the call to use_facet&lt;Facet&gt;(loc), the type argument
3978 chooses a facet, making available all members of the named type. If
3979 Facet is not present in a locale (or, failing that, in the global
3980 locale), it throws the standard exception bad_cast. A C++ program can
3981 check if a locale implements a particular facet with the template
3982 function has_facet&lt;Facet&gt;(). </p>
3983
3984 <p>This contradicts the specification given in section
3985 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>:
3986 <br><br>
3987 template &lt;class&nbsp; Facet&gt; const&nbsp; Facet&amp; use_facet(const
3988 locale&amp;&nbsp; loc); <br>
3989 <br>
3990 -1- Get a reference to a facet of a locale. <br>
3991 -2- Returns: a reference to the corresponding facet of loc, if present. <br>
3992 -3- Throws: bad_cast if has_facet&lt;Facet&gt;(loc) is false. <br>
3993 -4- Notes: The reference returned remains valid at least as long as any copy of loc exists
3994 </p>
3995 <p><b>Proposed resolution:</b></p>
3996 <p>Remove the phrase "(or, failing that, in the global locale)"
3997 from section 22.1.1. </p>
3998 <p><b>Rationale:</b></p>
3999 <p>Needed for consistency with the way locales are handled elsewhere
4000 in the standard.</p>
4001 <hr>
4002 <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>
4003 <p>The sentence introducing the Optional sequence operation table
4004 (23.1.1 paragraph 12) has two problems:</p>
4005
4006 <p>A. It says ``The operations in table 68 are provided only for the containers for which
4007 they take constant time.''<br>
4008 <br>
4009 That could be interpreted in two ways, one of them being ``Even though table 68 shows
4010 particular operations as being provided, implementations are free to omit them if they
4011 cannot implement them in constant time.''<br>
4012 <br>
4013 B. That paragraph says nothing about amortized constant time, and it should.&nbsp;</p>
4014 <p><b>Proposed resolution:</b></p>
4015 <p>Replace the wording in 23.1.1 paragraph 12&nbsp; which begins ``The operations in table 68 are provided only..."
4016 with:</p>
4017
4018 <blockquote>
4019   <p>Table 68 lists sequence operations that are provided for some types of sequential
4020   containers but not others. An implementation shall provide these operations for all
4021   container types shown in the ``container'' column, and shall implement them so as to take
4022   amortized constant time.</p>
4023 </blockquote>
4024 <hr>
4025 <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>
4026 <p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
4027 say:<br>
4028 <br>
4029 &#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();</tt></p>
4030
4031 <p>Surely the document meant to say ``<tt>xpos &lt; size()</tt>'' in both places.</p>
4032
4033 <p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
4034 proposed resolution.]</i></p>
4035 <p><b>Proposed resolution:</b></p>
4036 <p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
4037 <br>
4038 &#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();<br>
4039 <br>
4040 </tt>to:<br>
4041 <tt><br>
4042 </tt>&#8212; <tt>xpos &lt;= pos</tt> and <tt>xpos &lt; size();</tt></p>
4043 <hr>
4044 <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>
4045 <p>The lexicographical_compare complexity is specified as:<br>
4046 <br>
4047 &nbsp;&nbsp;&nbsp;&nbsp; "At most min((last1 - first1), (last2 - first2))
4048 applications of the corresponding comparison."<br>
4049 <br>
4050 The best I can do is twice that expensive.</p>
4051
4052 <p>Nicolai Josuttis comments in lib-6862: You mean, to check for
4053 equality you have to check both &lt; and &gt;? Yes, IMO you are
4054 right! (and Matt states this complexity in his book)</p>
4055
4056 <p><b>Proposed resolution:</b></p>
4057 <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>
4058     <blockquote>
4059     At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
4060     applications of the corresponding comparison.
4061     </blockquote>
4062
4063 <p>Change the example at the end of paragraph 3 to read:</p>
4064     <blockquote>
4065     [Example:<br>
4066     <br>
4067     &nbsp;&nbsp;&nbsp; for ( ; first1 != last1 &amp;&amp; first2 != last2 ;
4068     ++first1, ++first2) {<br>
4069     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first1 &lt; *first2) return true;<br>
4070     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first2 &lt; *first1) return false;<br>
4071     &nbsp;&nbsp;&nbsp; }<br>
4072     &nbsp;&nbsp;&nbsp; return first1 == last1 &amp;&amp; first2 != last2;<br>
4073     &nbsp;&nbsp;&nbsp;<br>
4074     --end example]
4075     </blockquote>
4076 <hr>
4077 <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.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#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Herb Sutter&nbsp; <b>Date:</b>&nbsp;9 May 1999</p>
4078 <p>In 23.2.1.1 paragraph 6, the deque ctor that takes an iterator range appears
4079 to have complexity requirements which are incorrect, and which contradict the
4080 complexity requirements for insert(). I suspect that the text in question,
4081 below, was taken from vector:</p>
4082 <blockquote>
4083   <p>Complexity: If the iterators first and last are forward iterators,
4084   bidirectional iterators, or random access iterators the constructor makes only
4085   N calls to the copy constructor, and performs no reallocations, where N is
4086   last - first.</p>
4087 </blockquote>
4088 <p>The word "reallocations" does not really apply to deque. Further,
4089 all of the following appears to be spurious:</p>
4090 <blockquote>
4091   <p>It makes at most 2N calls to the copy constructor of T and log N
4092   reallocations if they are input iterators.1)</p>
4093   <p>1) The complexity is greater in the case of input iterators because each
4094   element must be added individually: it is impossible to determine the distance
4095   between first abd last before doing the copying.</p>
4096 </blockquote>
4097 <p>This makes perfect sense for vector, but not for deque. Why should deque gain
4098 an efficiency advantage from knowing in advance the number of elements to
4099 insert?</p>
4100 <p><b>Proposed resolution:</b></p>
4101 <p>In 23.2.1.1 paragraph 6, replace the Complexity description, including the
4102 footnote, with the following text (which also corrects the "abd"
4103 typo):</p>
4104 <blockquote>
4105   <p>Complexity: Makes last - first calls to the copy constructor of T.</p>
4106 </blockquote>
4107 <hr>
4108 <a name="146"><h3>146.&nbsp;complex&lt;T&gt; Inserter and Extractor need sentries</h3></a><p><b>Section:</b>&nbsp;26.2.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>
4109 <p>The <u> extractor</u> for complex numbers is specified as:&nbsp;</p>
4110
4111 <blockquote>
4112
4113 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4114      basic_istream&lt;charT, traits&gt;&amp;&nbsp;<br>
4115      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;  is, complex&lt;T&gt;&amp;  x);<br>
4116 &nbsp;<br>
4117 Effects: Extracts a complex number x of the form: u, (u), or (u,v),
4118 where u is the real part and v is the imaginary part
4119 (lib.istream.formatted).&nbsp;<br>
4120 Requires: The input values be convertible to T. If bad input is
4121 encountered, calls is.setstate(ios::failbit) (which may throw
4122 ios::failure (lib.iostate.flags).&nbsp;<br>
4123 Returns: is .</p>
4124
4125 </blockquote>
4126 <p>Is it intended that the extractor for complex numbers does not skip
4127 whitespace, unlike all other extractors in the standard library do?
4128 Shouldn't a sentry be used?&nbsp;<br>
4129 <br>
4130 The <u>inserter</u> for complex numbers is specified as:</p>
4131
4132 <blockquote>
4133
4134 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4135      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
4136      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;  o, const complex&lt;T&gt;&amp;  x);<br>
4137 <br>
4138 Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
4139 <br>
4140      template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4141      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
4142      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; o, const complex&lt;T&gt;&amp; x)&nbsp;<br>
4143      {&nbsp;<br>
4144              basic_ostringstream&lt;charT, traits&gt; s;&nbsp;<br>
4145              s.flags(o.flags());&nbsp;<br>
4146              s.imbue(o.getloc());&nbsp;<br>
4147              s.precision(o.precision());&nbsp;<br>
4148              s &lt;&lt; '(' &lt;&lt; x.real() &lt;&lt; "," &lt;&lt; x.imag() &lt;&lt; ')';&nbsp;<br>
4149              return o &lt;&lt; s.str();&nbsp;<br>
4150      }</p>
4151
4152 </blockquote>
4153
4154 <p>Is it intended that the inserter for complex numbers ignores the
4155 field width and does not do any padding? If, with the suggested
4156 implementation above, the field width were set in the stream then the
4157 opening parentheses would be adjusted, but the rest not, because the
4158 field width is reset to zero after each insertion.</p>
4159
4160 <p>I think that both operations should use sentries, for sake of
4161 consistency with the other inserters and extractors in the
4162 library. Regarding the issue of padding in the inserter, I don't know
4163 what the intent was.&nbsp;</p>
4164 <p><b>Proposed resolution:</b></p>
4165 <p>After 26.2.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
4166 Notes clause:</p>
4167
4168 <blockquote>
4169
4170 <p>Notes: This extraction is performed as a series of simpler
4171 extractions. Therefore, the skipping of whitespace is specified to be the
4172 same for each of the simpler extractions.</p>
4173
4174 </blockquote>
4175 <p><b>Rationale:</b></p>
4176 <p>For extractors, the note is added to make it clear that skipping whitespace
4177 follows an "all-or-none" rule.</p>
4178
4179 <p>For inserters, the LWG believes there is no defect; the standard is correct
4180 as written.</p>
4181 <hr>
4182 <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>
4183 <p>The library had many global functions until 17.4.1.1 [lib.contents]
4184 paragraph 2 was added: </p>
4185
4186 <blockquote>
4187
4188 <p>All library entities except macros, operator new and operator
4189 delete are defined within the namespace std or namespaces nested
4190 within namespace std. </p>
4191
4192 </blockquote>
4193
4194 <p>It appears "global function" was never updated in the following: </p>
4195
4196 <blockquote>
4197
4198 <p>17.4.4.3 - Global functions [lib.global.functions]<br>
4199 <br>
4200 -1- It is unspecified whether any global functions in the C++ Standard
4201 Library are defined as inline (dcl.fct.spec).<br>
4202 <br>
4203 -2- A call to a global function signature described in Clauses
4204 lib.language.support through lib.input.output behaves the same as if
4205 the implementation declares no additional global function
4206 signatures.*<br>
4207 <br>
4208     [Footnote: A valid C++ program always calls the expected library
4209     global function. An implementation may also define additional
4210     global functions that would otherwise not be called by a valid C++
4211     program. --- end footnote]<br>
4212 <br>
4213 -3- A global function cannot be declared by the implementation as
4214 taking additional default arguments.&nbsp;<br>
4215 <br>
4216 17.4.4.4 - Member functions [lib.member.functions]<br>
4217 <br>
4218 -2- An implementation can declare additional non-virtual member
4219 function signatures within a class: </p>
4220
4221   <blockquote>
4222
4223 <p>-- by adding arguments with default values to a member function
4224 signature; The same latitude does not extend to the implementation of
4225 virtual or global functions, however. </p>
4226
4227   </blockquote>
4228 </blockquote>
4229 <p><b>Proposed resolution:</b></p>
4230 <p>     Change "global" to "global or non-member" in:</p>
4231 <blockquote>
4232   <p>17.4.4.3 [lib.global.functions] section title,<br>
4233   17.4.4.3 [lib.global.functions] para 1,<br>
4234   17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2
4235            places in the footnote,<br>
4236   17.4.4.3 [lib.global.functions] para 3,<br>
4237   17.4.4.4 [lib.member.functions] para 2</p>
4238 </blockquote>
4239 <p><b>Rationale:</b></p>
4240 <p>
4241 Because operator new and delete are global, the proposed resolution
4242 was changed from "non-member" to "global or non-member.
4243 </p>
4244 <hr>
4245 <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>
4246 <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
4247 do_falsename() functions in the example facet BoolNames should be
4248 const. The functions they are overriding in
4249 numpunct_byname&lt;char&gt; are const. </p>
4250 <p><b>Proposed resolution:</b></p>
4251 <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
4252 two places:</p>
4253 <blockquote>
4254   <p><tt>string do_truename() const { return "Oui Oui!"; }<br>
4255   string do_falsename() const { return "Mais Non!"; }</tt></p>
4256 </blockquote>
4257 <hr>
4258 <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>
4259 <p><b>Proposed resolution:</b></p>
4260 <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>
4261
4262 <blockquote>
4263 <p>Returns: The first iterator i in the range [first1, last1) such
4264 that for some <u>integer</u> j in the range [first2, last2) ...</p>
4265 </blockquote>
4266
4267 <p>to:</p>
4268
4269 <blockquote>
4270 <p>Returns: The first iterator i in the range [first1, last1) such
4271 that for some iterator j in the range [first2, last2) ...</p>
4272 </blockquote>
4273 <hr>
4274 <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>
4275 <p>For both sequences and associative containers, a.clear() has the
4276 semantics of erase(a.begin(),a.end()), which is undefined for an empty
4277 container since erase(q1,q2) requires that q1 be dereferenceable
4278 (23.1.1,3 and 23.1.2,7).  When the container is empty, a.begin() is
4279 not dereferenceable.<br>
4280 <br>
4281 The requirement that q1 be unconditionally dereferenceable causes many
4282 operations to be intuitively undefined, of which clearing an empty
4283 container is probably the most dire.<br>
4284 <br>
4285 Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
4286 q2) is required to be a valid range, stating that q1 and q2 must be
4287 iterators or certain kinds of iterators is unnecessary.
4288 </p>
4289 <p><b>Proposed resolution:</b></p>
4290 <p>In 23.1.1, paragraph 3, change:</p>
4291 <blockquote>
4292   <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>
4293 </blockquote>
4294 <p>to:</p>
4295 <blockquote>
4296   <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range<u>
4297   in a</u></p>
4298 </blockquote>
4299 <p>In 23.1.2, paragraph 7, change:</p>
4300 <blockquote>
4301   <p>p and q2 are valid iterators to a, q <u> and q1</u> are valid dereferenceable
4302   iterators to a, [q1, q2) is a valid range</p>
4303 </blockquote>
4304 <p>to</p>
4305 <blockquote>
4306   <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
4307   <u>into a</u></p>
4308 </blockquote>
4309 <hr>
4310 <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>
4311 <p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
4312 because there is no function <tt>is()</tt> which only takes a character as
4313 argument. Also, in the effects clause (paragraph 3), the semantic is also kept
4314 vague.</p>
4315 <p><b>Proposed resolution:</b></p>
4316 <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
4317 clause from:</p>
4318 <blockquote>
4319   <p>"... such that <tt>is(*p)</tt>
4320 would..."</p>
4321 </blockquote>
4322 <p>to:&nbsp; "... such that <tt>is(m, *p)</tt>
4323  would...."</p>
4324 <hr>
4325 <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>
4326 <p>The description of the array version of <tt>narrow()</tt> (in
4327 paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
4328 takes only three arguments because in addition to the range a default
4329 character is needed.</p>
4330
4331 <p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
4332 two signatures followed by a <b>Returns</b> clause that only addresses
4333 one of them.</p>
4334
4335 <p><b>Proposed resolution:</b></p>
4336 <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>
4337 paragraph 10 from:</p>
4338 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
4339
4340 <p>to:</p>
4341 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to),
4342 respectively.</p>
4343
4344 <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>
4345 <pre>        char        narrow(char c, char /*dfault*/) const;
4346         const char* narrow(const char* low, const char* high,
4347                            char /*dfault*/, char* to) const;</pre>
4348 <pre>        Returns: do_narrow(low, high, to).</pre>
4349 <p>to:</p>
4350 <pre>        char        narrow(char c, char dfault) const;
4351         const char* narrow(const char* low, const char* high,
4352                            char dfault, char* to) const;</pre>
4353 <pre>        Returns: do_narrow(c, dfault) or
4354                  do_narrow(low, high, dfault, to), respectively.</pre>
4355
4356 <p><i>[Kona: 1) the problem occurs in additional places, 2) a user
4357 defined version could be different.]</i></p>
4358
4359 <p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
4360 the LWG. He could find no other places the problem occurred. He
4361 asks for clarification of the Kona "a user defined
4362 version..." comment above.  Perhaps it was a circuitous way of
4363 saying "dfault" needed to be uncommented?]</i></p>
4364
4365 <p><i>[Post-Toronto: the issues list maintainer has merged in the
4366 proposed resolution from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a>, which addresses the
4367 same paragraphs.]</i></p>
4368 <hr>
4369 <a name="154"><h3>154.&nbsp;Missing <tt>double</tt> specifier for <tt>do_get()</tt>
4370 </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>
4371 <p>The table in paragraph 7 for the length modifier does not list the length
4372 modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
4373 standard asks the implementation to do undefined things when using <tt>scanf()</tt>
4374 (the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
4375 is actually a problem I found quite often in production code, too).</p>
4376 <p><b>Proposed resolution:</b></p>
4377 <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
4378 Modifier table to say that for <tt>double</tt> a length modifier
4379 <tt>l</tt> is to be used.</p>
4380 <p><b>Rationale:</b></p>
4381 <p>The standard makes an embarrassing beginner's mistake.</p>
4382 <hr>
4383 <a name="155"><h3>155.&nbsp;Typo in naming the class defining the class <tt>Init</tt>
4384 </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>
4385 <p>There are conflicting statements about where the class
4386 <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
4387 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>
4388 <p><b>Proposed resolution:</b></p>
4389 <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
4390 "<tt>basic_ios::Init"</tt> to
4391 "<tt>ios_base::Init"</tt>.</p>
4392 <p><b>Rationale:</b></p>
4393 <p>Although not strictly wrong, the standard was misleading enough to warrant
4394 the change.</p>
4395 <hr>
4396 <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>
4397 <p>There is a small discrepancy between the declarations of
4398 <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
4399 <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
4400 is passed as <tt>locale const</tt> (wrong).</p>
4401 <p><b>Proposed resolution:</b></p>
4402 <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
4403 from "<tt>locale const" to "locale
4404 const&amp;".</tt></p>
4405 <hr>
4406 <a name="158"><h3>158.&nbsp;Underspecified semantics for <tt>setbuf()</tt>
4407 </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>
4408 <p>The default behavior of <tt>setbuf()</tt> is described only for the
4409 situation that <tt>gptr() != 0 &amp;&amp; gptr() != egptr()</tt>:
4410 namely to do nothing.  What has to be done in other situations&nbsp;
4411 is not described although there is actually only one reasonable
4412 approach, namely to do nothing, too.</p>
4413
4414 <p>Since changing the buffer would almost certainly mess up most
4415 buffer management of derived classes unless these classes do it
4416 themselves, the default behavior of <tt>setbuf()</tt> should always be
4417 to do nothing.</p>
4418 <p><b>Proposed resolution:</b></p>
4419 <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,
4420 to: "Default behavior: Does nothing. Returns this."</p>
4421 <hr>
4422 <a name="159"><h3>159.&nbsp;Strange use of <tt>underflow()</tt>
4423 </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>
4424 <p>The description of the meaning of the result of
4425 <tt>showmanyc()</tt> seems to be rather strange: It uses calls to
4426 <tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
4427 this function only reads the current character but does not extract
4428 it, <tt>uflow()</tt> would extract the current character. This should
4429 be fixed to use <tt>sbumpc()</tt> instead.</p>
4430 <p><b>Proposed resolution:</b></p>
4431 <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,
4432 <tt>showmanyc()</tt>returns clause, by replacing the word
4433 "supplied" with the words "extracted from the
4434 stream".</p>
4435 <hr>
4436 <a name="160"><h3>160.&nbsp;Typo: Use of non-existing function <tt>exception()</tt>
4437 </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>
4438 <p>The paragraph 4 refers to the function <tt>exception()</tt> which
4439 is not defined. Probably, the referred function is
4440 <tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>
4441 <p><b>Proposed resolution:</b></p>
4442 <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,
4443 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>,
4444 paragraph 1, change "<tt>exception()" to
4445 "exceptions()"</tt>.</p>
4446
4447 <p><i>[Note to Editor: "exceptions" with an "s"
4448 is the correct spelling.]</i></p>
4449 <hr>
4450 <a name="161"><h3>161.&nbsp;Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt>
4451 </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>
4452 <p>The note in the second paragraph pretends that the first argument
4453 is an object of type <tt>istream_iterator</tt>. This is wrong: It is
4454 an object of type <tt>istreambuf_iterator</tt>.</p>
4455 <p><b>Proposed resolution:</b></p>
4456 <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>
4457 <blockquote>
4458   <p>The first argument provides an object of the istream_iterator class...</p>
4459 </blockquote>
4460 <p>to</p>
4461 <blockquote>
4462   <p>The first argument provides an object of the istreambuf_iterator class...</p>
4463 </blockquote>
4464 <hr>
4465 <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>
4466 <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
4467 as taking a fill character as an argument, but the description of the
4468 function does not say whether the character is used at all and, if so,
4469 in which way. The same holds for any format control parameters that
4470 are accessible through the ios_base&amp; argument, such as the
4471 adjustment or the field width. Is strftime() supposed to use the fill
4472 character in any way? In any case, the specification of
4473 time_put.do_put() looks inconsistent to me.<br> <br> Is the
4474 signature of do_put() wrong, or is the effects clause incomplete?</p>
4475 <p><b>Proposed resolution:</b></p>
4476 <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>
4477 paragraph 2:</p>
4478 <blockquote>
4479   <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
4480   for this argument. --end Note]</p>
4481 </blockquote>
4482 <p><b>Rationale:</b></p>
4483 <p>The LWG felt that while the normative text was correct,
4484 users need some guidance on what to pass for the <tt>fill</tt>
4485 argument since the standard doesn't say how it's used.</p>
4486 <hr>
4487 <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>
4488 <p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
4489 functions falling into one of the groups "formatted output functions"
4490 and "unformatted output functions" calls any stream buffer function
4491 which might call a virtual function other than <tt>overflow()</tt>. Basically
4492 this is fine but this implies that <tt>sputn()</tt> (this function would call
4493 the virtual function <tt>xsputn()</tt>) is never called by any of the standard
4494 output functions. Is this really intended? At minimum it would be convenient to
4495 call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
4496 is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
4497 with the definition of <tt>flush()</tt> which calls <tt>rdbuf()-&gt;pubsync()</tt>
4498 and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
4499 under "unformatted output functions").</p>
4500 <p>In addition, I guess that the sentence starting with "They may use other
4501 public members of <tt>basic_ostream</tt> ..." probably was intended to
4502 start with "They may use other public members of <tt>basic_streamuf</tt>..."
4503 although the problem with the virtual members exists in both cases.</p>
4504 <p>I see two obvious resolutions:</p>
4505 <ol>
4506   <li>state in a footnote that this means that <tt>xsputn()</tt> will never be
4507     called by any ostream member and that this is intended.</li>
4508   <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
4509     Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
4510 </ol>
4511 <p><b>Proposed resolution:</b></p>
4512 <p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
4513 <blockquote>
4514   <p>They may use other public members of basic_ostream except that they do not
4515   invoke any virtual members of rdbuf() except overflow().</p>
4516 </blockquote>
4517 <p>to:</p>
4518 <blockquote>
4519   <p>They may use other public members of basic_ostream except that they shall
4520   not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
4521   sync().</p>
4522 </blockquote>
4523
4524 <p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
4525 PJP why the standard is written this way.]</i></p>
4526
4527 <p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
4528 LWG. He comments: The rules can be made a little bit more specific if
4529 necessary be explicitly spelling out what virtuals are allowed to be
4530 called from what functions and eg to state specifically that flush()
4531 is allowed to call sync() while other functions are not.]</i></p>
4532 <hr>
4533 <a name="167"><h3>167.&nbsp;Improper use of <tt>traits_type::length()</tt>
4534 </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>
4535 <p>Paragraph 4 states that the length is determined using
4536 <tt>traits::length(s)</tt>.  Unfortunately, this function is not
4537 defined for example if the character type is <tt>wchar_t</tt> and the
4538 type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
4539 the character type is <tt>char</tt> and the type of <tt>s</tt> is
4540 either <tt>signed char const*</tt> or <tt>unsigned char
4541 const*</tt>.</p>
4542 <p><b>Proposed resolution:</b></p>
4543 <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>
4544 <blockquote>
4545   <p>Effects: Behaves like an formatted inserter (as described in
4546   lib.ostream.formatted.reqmts) of out. After a sentry object is
4547   constructed it inserts characters. The number of characters starting
4548   at s to be inserted is traits::length(s). Padding is determined as
4549   described in lib.facet.num.put.virtuals. The traits::length(s)
4550   characters starting at s are widened using out.widen
4551   (lib.basic.ios.members). The widened characters and any required
4552   padding are inserted into out. Calls width(0).</p>
4553 </blockquote>
4554 <p>to:</p>
4555 <blockquote>
4556   <p>Effects: Behaves like a formatted inserter (as described in
4557   lib.ostream.formatted.reqmts) of out. After a sentry object is
4558   constructed it inserts <i>n</i> characters starting at <i>s</i>,
4559   where <i>n</i> is the number that would be computed as if by:</p>
4560   <ul>
4561   <li>traits::length(s) for the overload where the first argument is of
4562     type basic_ostream&lt;charT, traits&gt;&amp; and the second is
4563     of type const charT*, and also for the overload where the first
4564     argument is of type basic_ostream&lt;char, traits&gt;&amp; and
4565     the second is of type const char*.</li>
4566   <li>std::char_traits&lt;char&gt;::length(s)
4567     for the overload where the first argument is of type
4568     basic_ostream&lt;charT, traits&gt;&amp; and the second is of type
4569     const char*.</li>
4570   <li>traits::length(reinterpret_cast&lt;const char*&gt;(s))
4571     for the other two overloads.</li>
4572   </ul>
4573   <p>Padding is determined as described in
4574   lib.facet.num.put.virtuals. The <i>n</i> characters starting at
4575   <i>s</i> are widened using out.widen (lib.basic.ios.members).  The
4576   widened characters and any required padding are inserted into
4577   out. Calls width(0).</p>
4578 </blockquote>
4579
4580 <p><i>[Santa Cruz: Matt supplied new wording]</i></p>
4581
4582 <p><i>[Kona: changed "where <i>n</i> is" to " where <i>n</i> is the
4583   number that would be computed as if by"]</i></p>
4584
4585 <p><b>Rationale:</b></p>
4586 <p>We have five separate cases.  In two of them we can use the
4587 user-supplied traits class without any fuss.  In the other three we
4588 try to use something as close to that user-supplied class as possible.
4589 In two cases we've got a traits class that's appropriate for
4590 char and what we've got is a const signed char* or a const
4591 unsigned char*; that's close enough so we can just use a reinterpret
4592 cast, and continue to use the user-supplied traits class.  Finally,
4593 there's one case where we just have to give up: where we've got a
4594 traits class for some arbitrary charT type, and we somehow have to
4595 deal with a const char*.  There's nothing better to do but fall back
4596 to char_traits&lt;char&gt;</p>
4597 <hr>
4598 <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>
4599 <p>The first paragraph begins with a descriptions what has to be done
4600 in <i>formatted</i> output functions. Probably this is a typo and the
4601 paragraph really want to describe unformatted output functions...</p>
4602 <p><b>Proposed resolution:</b></p>
4603 <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
4604 sentences, change the word "formatted" to
4605 "unformatted":</p>
4606 <blockquote>
4607   <p>"Each <b>unformatted </b> output function begins ..."<br>
4608   "... value specified for the <b>unformatted </b>  output
4609   function."</p>
4610 </blockquote>
4611 <hr>
4612 <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>
4613 <p>Paragraph 8, Notes, of this section seems to mandate an extremely
4614 inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
4615 especially in view of the restriction that <tt>basic_ostream</tt>
4616 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
4617 is to be created.</p>
4618 <p>Of course, the resolution below requires some handling of
4619 simultaneous input and output since it is no longer possible to update
4620 <tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
4621 solution is to handle this in <tt>underflow()</tt>.</p>
4622 <p><b>Proposed resolution:</b></p>
4623 <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
4624 "at least" as in the following:</p>
4625 <blockquote>
4626   <p>To make a write position available, the function reallocates (or initially
4627   allocates) an array object with a sufficient number of elements to hold the
4628   current array object (if any), plus <b>at least</b> one additional write
4629   position.</p>
4630 </blockquote>
4631 <hr>
4632 <a name="170"><h3>170.&nbsp;Inconsistent definition of <tt>traits_type</tt>
4633 </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>
4634 <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>),
4635 <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
4636 <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
4637 in their definition of the type <tt>traits_type</tt>: For
4638 <tt>istringstream</tt>, this type is defined, for the other two it is
4639 not. This should be consistent.</p>
4640 <p><b>Proposed resolution:</b></p>
4641 <p><b>Proposed resolution:</b></p> <p>To the declarations of
4642 <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
4643 <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>
4644 <blockquote>
4645 <pre>typedef traits traits_type;</pre>
4646 </blockquote>
4647 <hr>
4648 <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>
4649 <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
4650 output position is maintained by <tt>basic_filebuf</tt>. Still, the
4651 description of <tt>seekpos()</tt> seems to talk about different file
4652 positions. In particular, it is unclear (at least to me) what is
4653 supposed to happen to the output buffer (if there is one) if only the
4654 input position is changed. The standard seems to mandate that the
4655 output buffer is kept and processed as if there was no positioning of
4656 the output position (by changing the input position). Of course, this
4657 can be exactly what you want if the flag <tt>ios_base::ate</tt> is
4658 set. However, I think, the standard should say something like
4659 this:</p>
4660 <ul>
4661   <li>If <tt>(which &amp; mode) == 0</tt> neither read nor write position is
4662     changed and the call fails. Otherwise, the joint read and write position is
4663     altered to correspond to <tt>sp</tt>.</li>
4664   <li>If there is an output buffer, the output sequences is updated and any
4665     unshift sequence is written before the position is altered.</li>
4666   <li>If there is an input buffer, the input sequence is updated after the
4667     position is altered.</li>
4668 </ul>
4669 <p>Plus the appropriate error handling, that is...</p>
4670 <p><b>Proposed resolution:</b></p>
4671 <p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
4672 paragraph 14 from:</p>
4673 <blockquote>
4674   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
4675   ios_base::out);</p>
4676   <p>Alters the file position, if possible, to correspond to the position stored
4677   in sp (as described below).</p>
4678   <p>- if (which&amp;ios_base::in)!=0, set the file position to sp, then update
4679   the input sequence</p>
4680   <p>- if (which&amp;ios_base::out)!=0, then update the output sequence, write
4681   any unshift sequence, and set the file position to sp.</p>
4682 </blockquote>
4683 <p>to:</p>
4684 <blockquote>
4685   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
4686   ios_base::out);</p>
4687   <p>Alters the file position, if possible, to correspond to the position stored
4688   in sp (as described below). Altering the file position performs as follows:</p>
4689   <p>1. if (om &amp; ios_base::out)!=0, then update the output sequence and
4690   write any unshift sequence;</p>
4691   <p>2. set the file position to sp;</p>
4692   <p>3. if (om &amp; ios_base::in)!=0, then update the input sequence;</p>
4693   <p>where om is the open mode passed to the last call to open(). The operation
4694   fails if is_open() returns false.</p>
4695 </blockquote>
4696
4697 <p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
4698 <p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
4699 <hr>
4700 <a name="172"><h3>172.&nbsp;Inconsistent types for <tt>basic_istream::ignore()</tt>
4701 </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>
4702 <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
4703 <tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
4704 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>
4705 paragraph 23 the first argument is of type <tt>int.</tt></p>
4706
4707 <p>As far as I can see this is not really a contradiction because
4708 everything is consistent if <tt>streamsize</tt> is typedef to be
4709 <tt>int</tt>. However, this is almost certainly not what was
4710 intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
4711 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>.</p>
4712
4713 <p>Darin Adler also
4714 submitted this issue, commenting: Either 27.6.1.1 should be modified
4715 to show a first parameter of type int, or 27.6.1.3 should be modified
4716 to show a first parameter of type streamsize and use
4717 numeric_limits&lt;streamsize&gt;::max.</p>
4718 <p><b>Proposed resolution:</b></p>
4719 <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
4720 of <tt>int</tt> in the description of <tt>ignore()</tt> to
4721 <tt>streamsize</tt>.</p>
4722 <hr>
4723 <a name="173"><h3>173.&nbsp;Inconsistent types for <tt>basic_filebuf::setbuf()</tt>
4724 </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>
4725
4726 <p>
4727 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
4728 object of type <tt>streamsize</tt> as second argument. However, in
4729 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
4730 <tt>int</tt>.
4731 </p>
4732
4733 <p>
4734 As far as I can see this is not really a contradiction because
4735 everything is consistent if <tt>streamsize</tt> is typedef to be
4736 <tt>int</tt>. However, this is almost certainly not what was
4737 intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
4738 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>.
4739 </p>
4740
4741 <p><b>Proposed resolution:</b></p>
4742 <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
4743 <tt>int</tt> in the description of <tt>setbuf()</tt> to
4744 <tt>streamsize</tt>.</p>
4745 <hr>
4746 <a name="174"><h3>174.&nbsp;Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt>
4747 </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>
4748 <p>According to paragraph 1 of this section, <tt>streampos</tt> is the
4749 type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
4750 paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt></p>
4751 <p><b>Proposed resolution:</b></p>
4752 <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
4753 OFF_T streampos;</tt>" to "<tt>typedef POS_T
4754 streampos;</tt>"</p>
4755 <hr>
4756 <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>
4757 <p>According to paragraph 8 of this section, the methods
4758 <tt>basic_streambuf::pubseekpos()</tt>,
4759 <tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
4760 "may" be overloaded by a version of this function taking the
4761 type <tt>ios_base::open_mode</tt> as last argument argument instead of
4762 <tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
4763 in this section to be an alias for one of the integral types). The
4764 clause specifies, that the last argument has a default argument in
4765 three cases.  However, this generates an ambiguity with the overloaded
4766 version because now the arguments are absolutely identical if the last
4767 argument is not specified.</p>
4768 <p><b>Proposed resolution:</b></p>
4769 <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
4770 <tt>basic_streambuf::pubseekpos()</tt>,
4771 <tt>basic_ifstream::open()</tt>, and
4772 <tt>basic_ofstream::open().</tt></p>
4773 <hr>
4774 <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>
4775 <p>The "overload" for the function <tt>exceptions()</tt> in
4776 paragraph 8 gives the impression that there is another function of
4777 this function defined in class <tt>ios_base</tt>. However, this is not
4778 the case. Thus, it is hard to tell how the semantics (paragraph 9) can
4779 be implemented: "Call the corresponding member function specified
4780 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>
4781 <p><b>Proposed resolution:</b></p>
4782 <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
4783 function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
4784 <hr>
4785 <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>
4786 <p>Currently the following will not compile on two well-known standard
4787 library implementations:</p>
4788
4789 <blockquote>
4790   <pre>#include &lt;set&gt;
4791 using namespace std;
4792
4793 void f(const set&lt;int&gt; &amp;s)
4794 {
4795   set&lt;int&gt;::iterator i;
4796   if (i==s.end()); // s.end() returns a const_iterator
4797 }</pre>
4798 </blockquote>
4799
4800 <p>
4801 The reason this doesn't compile is because operator== was implemented
4802 as a member function of the nested classes set:iterator and
4803 set::const_iterator, and there is no conversion from const_iterator to
4804 iterator. Surprisingly, (s.end() == i) does work, though, because of
4805 the conversion from iterator to const_iterator.
4806 </p>
4807
4808 <p>
4809 I don't see a requirement anywhere in the standard that this must
4810 work. Should there be one?  If so, I think the requirement would need
4811 to be added to the tables in section 24.1.1. I'm not sure about the
4812 wording.  If this requirement existed in the standard, I would think
4813 that implementors would have to make the comparison operators
4814 non-member functions.</p>
4815
4816 <p>This issues was also raised on comp.std.c++ by Darin
4817 Adler.&nbsp; The example given was:</p>
4818
4819 <blockquote>
4820   <pre>bool check_equal(std::deque&lt;int&gt;::iterator i,
4821 std::deque&lt;int&gt;::const_iterator ci)
4822 {
4823 return i == ci;
4824 }</pre>
4825 </blockquote>
4826
4827 <p>Comment from John Potter:</p>
4828 <blockquote>
4829     <p>
4830     In case nobody has noticed, accepting it will break reverse_iterator.
4831     </p>
4832
4833     <p>
4834     The fix is to make the comparison operators templated on two types.
4835     </p>
4836
4837     <pre>    template &lt;class Iterator1, class Iterator2&gt;
4838     bool operator== (reverse_iterator&lt;Iterator1&gt; const&amp; x,
4839                      reverse_iterator&lt;Iterator2&gt; const&amp; y);
4840     </pre>
4841
4842     <p>
4843     Obviously:  return x.base() == y.base();
4844     </p>
4845
4846     <p>
4847     Currently, no reverse_iterator to const_reverse_iterator compares are
4848     valid.
4849     </p>
4850
4851     <p>
4852     BTW, I think the issue is in support of bad code.  Compares should be
4853     between two iterators of the same type.  All std::algorithms require
4854     the begin and end iterators to be of the same type.
4855     </p>
4856 </blockquote>
4857 <p><b>Proposed resolution:</b></p>
4858 <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>
4859 <blockquote>
4860   <p>In the expressions</p>
4861   <pre>    i == j
4862     i != j
4863     i &lt; j
4864     i &lt;= j
4865     i &gt;= j
4866     i &gt; j
4867     i - j
4868   </pre>
4869   <p>Where i and j denote objects of a container's iterator type,
4870   either or both may be replaced by an object of the container's
4871   const_iterator type referring to the same element with no
4872   change in semantics.</p>
4873 </blockquote>
4874
4875 <p><i>[post-Toronto: Judy supplied a proposed resolution saying that
4876 <tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
4877 iterator comparison and difference operations.]</i></p>
4878
4879 <p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
4880 explicitly listed expressions; there was concern that the previous
4881 proposed resolution was too informal.]</i></p>
4882 <p><b>Rationale:</b></p>
4883 <p>
4884 The LWG believes it is clear that the above wording applies only to
4885 the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
4886 where <tt>X</tt> is a container.  There is no requirement that
4887 <tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
4888 can be mixed.  If mixing them is considered important, that's a
4889 separate issue.  (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>.)
4890 </p>
4891 <hr>
4892 <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>
4893 <p>The claim has surfaced in Usenet that expressions such as<br>
4894 <br>
4895 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>make_pair("abc", 3)</tt><br>
4896 <br>
4897 are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
4898 parameter to <tt> const char (&amp;)[4]</tt>, which type is uncopyable.<br>
4899 <br>
4900 I doubt anyone intended that behavior...
4901 </p>
4902 <p><b>Proposed resolution:</b></p>
4903 <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
4904 declaration of make_pair():</p>
4905 <blockquote>
4906   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(const T1&amp;, const T2&amp;);</pre>
4907 </blockquote>
4908 <p>to:</p>
4909 <blockquote>
4910   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(T1, T2);</pre>
4911 </blockquote>
4912 <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>
4913 <blockquote>
4914 <pre>template &lt;class T1, class T2&gt;
4915 pair&lt;T1, T2&gt; make_pair(const T1&amp; x, const T2&amp; y);</pre>
4916 </blockquote>
4917 <p>to:</p>
4918 <blockquote>
4919 <pre>template &lt;class T1, class T2&gt;
4920 pair&lt;T1, T2&gt; make_pair(T1 x, T2 y);</pre>
4921 </blockquote>
4922 <p>and add the following footnote to the effects clause:</p>
4923 <blockquote>
4924   <p> According to 12.8 [class.copy], an implementation is permitted
4925   to not perform a copy of an argument, thus avoiding unnecessary
4926   copies.</p>
4927 </blockquote>
4928 <p><b>Rationale:</b></p>
4929 <p>Two potential fixes were suggested by Matt Austern and Dietmar
4930 Kühl, respectively, 1) overloading with array arguments, and 2) use of
4931 a reference_traits class with a specialization for arrays.  Andy
4932 Koenig suggested changing to pass by value. In discussion, it appeared
4933 that this was a much smaller change to the standard that the other two
4934 suggestions, and any efficiency concerns were more than offset by the
4935 advantages of the solution. Two implementors reported that the
4936 proposed resolution passed their test suites.</p>
4937 <hr>
4938 <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>
4939 <p>Many references to <tt> size_t</tt> throughout the document
4940 omit the <tt> std::</tt> namespace qualification.</p> <p>For
4941 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>
4942 <blockquote>
4943 <pre>&#8212; operator new(size_t)
4944 &#8212; operator new(size_t, const std::nothrow_t&amp;)
4945 &#8212; operator new[](size_t)
4946 &#8212; operator new[](size_t, const std::nothrow_t&amp;)</pre>
4947 </blockquote>
4948 <p><b>Proposed resolution:</b></p>
4949 <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>
4950 <blockquote>
4951 <p><tt>     - operator new(size_t)<br>
4952      - operator new(size_t, const std::nothrow_t&amp;)<br>
4953      - operator new[](size_t)<br>
4954      - operator new[](size_t, const std::nothrow_t&amp;)</tt></p>
4955 </blockquote>
4956 <p>    by:</p>
4957 <blockquote>
4958 <pre>- operator new(std::size_t)
4959 - operator new(std::size_t, const std::nothrow_t&amp;)
4960 - operator new[](std::size_t)
4961 - operator new[](std::size_t, const std::nothrow_t&amp;)</pre>
4962 </blockquote>
4963 <p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
4964 <blockquote>
4965   <p>The typedef members pointer, const_pointer, size_type, and difference_type
4966   are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
4967 </blockquote>
4968 <p>&nbsp;by:</p>
4969 <blockquote>
4970   <p>The typedef members pointer, const_pointer, size_type, and difference_type
4971   are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
4972   respectively.</p>
4973 </blockquote>
4974 <p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
4975 <blockquote>
4976   <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
4977   <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
4978   is unspecified when or how often this function is called. The use of hint is
4979   unspecified, but intended as an aid to locality if an implementation so
4980   desires.</p>
4981 </blockquote>
4982 <p>by:</p>
4983 <blockquote>
4984   <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
4985   <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
4986   it is unspecified when or how often this function is called. The use of hint
4987   is unspecified, but intended as an aid to locality if an implementation so
4988   desires.</p>
4989 </blockquote>
4990 <p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
4991 <blockquote>
4992   <p>In Table 37, X denotes a Traits class defining types and functions for the
4993   character container type CharT; c and d denote values of type CharT; p and q
4994   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
4995   j denote values of type size_t; e and f denote values of type X::int_type; pos
4996   denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
4997 </blockquote>
4998 <p>by:</p>
4999 <blockquote>
5000   <p>In Table 37, X denotes a Traits class defining types and functions for the
5001   character container type CharT; c and d denote values of type CharT; p and q
5002   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
5003   j denote values of type std::size_t; e and f denote values of type X::int_type;
5004   pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
5005 </blockquote>
5006 <p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
5007 X::length(p): "size_t" by "std::size_t".</p>
5008 <p>   In [lib.std.iterator.tags] 24.3.3, paragraph 2:    replace:<br>
5009 &nbsp;&nbsp;&nbsp; typedef ptrdiff_t difference_type;<br>
5010     by:<br>
5011 &nbsp;&nbsp;&nbsp; typedef std::ptrdiff_t difference_type;</p>
5012 <p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the
5013 declaration of template &lt;class charT&gt; class ctype.<br>
5014 <br>
5015    In [lib.iterator.traits] 24.3.1, paragraph 2    put namespace std { ...} around the declaration of:<br>
5016 <br>
5017 &nbsp;&nbsp;&nbsp; template&lt;class Iterator&gt; struct iterator_traits<br>
5018 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;T*&gt;<br>
5019 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;const T*&gt;</p>
5020 <p><b>Rationale:</b></p>
5021 <p>The LWG believes correcting names like <tt>size_t</tt> and
5022 <tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
5023 to be essentially editorial.  There there can't be another size_t or
5024 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>
5025
5026 <blockquote>
5027 For each type T from the Standard C library, the types ::T and std::T
5028 are reserved to the implementation and, when defined, ::T shall be
5029 identical to std::T.
5030 </blockquote>
5031
5032 <p>The issue is treated as a Defect Report to make explicit the Project
5033 Editor's authority to make this change.</p>
5034
5035 <p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
5036 request of the LWG.]</i></p>
5037
5038 <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
5039 address use of the name <tt>size_t</tt> in contexts outside of
5040 namespace std, such as in the description of <tt>::operator new</tt>.
5041 The proposed changes should be reviewed to make sure they are
5042 correct.]</i></p>
5043
5044 <p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
5045 them to be correct.]</i></p>
5046
5047 <hr>
5048 <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>
5049 <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
5050 exposition):</p>
5051 <blockquote>
5052 <p>Returns: An object s of unspecified type such that if [1] out is an (instance
5053 of) basic_ostream then the expression out&lt;&lt;s behaves as if f(s) were
5054 called, and if [2] in is an (instance of) basic_istream then the expression
5055 in&gt;&gt;s behaves as if f(s) were called. Where f can be defined as: ios_base&amp;
5056 f(ios_base&amp; str, ios_base::fmtflags mask) { // reset specified flags
5057 str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
5058 out&lt;&lt;s has type ostream&amp; and value out. [4] The expression in&gt;&gt;s
5059 has type istream&amp; and value in.</p>
5060 </blockquote>
5061 <p>Given the definitions [1] and [2] for out and in, surely [3] should read:
5062 "The expression out &lt;&lt; s has type basic_ostream&amp; ..." and
5063 [4] should read: "The expression in &gt;&gt; s has type basic_istream&amp;
5064 ..."</p>
5065 <p>If the wording in the standard is correct, I can see no way of implementing
5066 any of the manipulators so that they will work with wide character streams.</p>
5067 <p>e.g. wcout &lt;&lt; setbase( 16 );</p>
5068 <p>Must have value 'wcout' (which makes sense) and type 'ostream&amp;' (which
5069 doesn't).</p>
5070 <p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
5071 8. In addition, Para 6 [setfill] has a similar error, but relates only to
5072 ostreams.</p>
5073 <p>I'd be happier if there was a better way of saying this, to make it clear
5074 that the value of the expression is "the same specialization of
5075 basic_ostream as out"&amp;</p>
5076 <p><b>Proposed resolution:</b></p>
5077 <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
5078 following:</p>
5079 <blockquote>
5080 <p>2- The type designated smanip in each of the following function
5081 descriptions is implementation-specified and may be different for each
5082 function.<br>
5083 <br>
5084 <tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
5085 <br>
5086 -3- Returns: An object s of unspecified type such that if out is an
5087 instance of basic_ostream&lt;charT,traits&gt; then the expression
5088 out&lt;&lt;s behaves
5089 as if f(s, mask) were called, or if in is an instance of
5090 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5091 behaves as if
5092 f(s, mask) were called. The function f can be defined as:*<br>
5093 <br>
5094 [Footnote: The expression cin &gt;&gt; resetiosflags(ios_base::skipws)
5095 clears ios_base::skipws in the format flags stored in the
5096 basic_istream&lt;charT,traits&gt; object cin (the same as cin &gt;&gt;
5097 noskipws), and the expression cout &lt;&lt;
5098 resetiosflags(ios_base::showbase) clears
5099 ios_base::showbase in the format flags stored in the
5100 basic_ostream&lt;charT,traits&gt; object cout (the same as cout
5101 &lt;&lt;
5102 noshowbase). --- end footnote]<br>
5103 <br>
5104 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
5105 &nbsp;&nbsp; {<br>
5106 &nbsp;&nbsp; //  reset specified flags<br>
5107 &nbsp;&nbsp; str.setf(ios_base::fmtflags(0), mask);<br>
5108 &nbsp;&nbsp; return str;<br>
5109 &nbsp;&nbsp; }<br>
5110 </tt><br>
5111 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5112 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5113 <br>
5114 &nbsp;<tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
5115 <br>
5116 -4- Returns: An object s of unspecified type such that if out is an
5117 instance of basic_ostream&lt;charT,traits&gt; then the expression
5118 out&lt;&lt;s behaves
5119 as if f(s, mask) were called, or if in is an instance of
5120 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5121 behaves as if f(s,
5122 mask) were called. The function f can be defined as:<br>
5123 <br>
5124 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
5125 &nbsp;&nbsp; {<br>
5126 &nbsp;&nbsp; //  set specified flags<br>
5127 &nbsp;&nbsp; str.setf(mask);<br>
5128 &nbsp;&nbsp; return str;<br>
5129 &nbsp;&nbsp; }<br>
5130 </tt><br>
5131 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5132 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5133 <br>
5134 <tt>smanip setbase(int base);</tt><br>
5135 <br>
5136 -5- Returns: An object s of unspecified type such that if out is an
5137 instance of basic_ostream&lt;charT,traits&gt; then the expression
5138 out&lt;&lt;s behaves
5139 as if f(s, base) were called, or if in is an instance of
5140 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5141 behaves as if f(s,
5142 base) were called. The function f can be defined as:<br>
5143 <br>
5144 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int base)<br>
5145 &nbsp;&nbsp; {<br>
5146 &nbsp;&nbsp; //  set  basefield<br>
5147 &nbsp;&nbsp; str.setf(base ==  8 ? ios_base::oct :<br>
5148 &nbsp;&nbsp; base == 10 ? ios_base::dec :<br>
5149 &nbsp;&nbsp; base == 16 ? ios_base::hex :<br>
5150 &nbsp;&nbsp; ios_base::fmtflags(0), ios_base::basefield);<br>
5151 &nbsp;&nbsp; return str;<br>
5152 &nbsp;&nbsp; }<br>
5153 </tt><br>
5154 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5155 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5156 <br>
5157 <tt>smanip setfill(char_type c);<br>
5158 </tt><br>
5159 -6- Returns: An object s of unspecified type such that if out is (or is
5160 derived from) basic_ostream&lt;charT,traits&gt; and c has type charT
5161 then the
5162 expression out&lt;&lt;s behaves as if f(s, c) were called. The function
5163 f can be
5164 defined as:<br>
5165 <br>
5166 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>template&lt;class charT, class traits&gt;<br>
5167 &nbsp;&nbsp; basic_ios&lt;charT,traits&gt;&amp; f(basic_ios&lt;charT,traits&gt;&amp; str, charT c)<br>
5168 &nbsp;&nbsp; {<br>
5169 &nbsp;&nbsp; //  set fill character<br>
5170 &nbsp;&nbsp; str.fill(c);<br>
5171 &nbsp;&nbsp; return str;<br>
5172 &nbsp;&nbsp; }<br>
5173 </tt><br>
5174 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.<br>
5175 <br>
5176 <tt>smanip setprecision(int n);</tt><br>
5177 <br>
5178 -7- Returns: An object s of unspecified type such that if out is an
5179 instance of basic_ostream&lt;charT,traits&gt; then the expression
5180 out&lt;&lt;s behaves
5181 as if f(s, n) were called, or if in is an instance of
5182 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5183 behaves as if f(s, n)
5184 were called. The function f can be defined as:<br>
5185 <br>
5186 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
5187 &nbsp;&nbsp; {<br>
5188 &nbsp;&nbsp; //  set precision<br>
5189 &nbsp;&nbsp; str.precision(n);<br>
5190 &nbsp;&nbsp; return str;<br>
5191 &nbsp;&nbsp; }<br>
5192 </tt><br>
5193 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5194 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in<br>
5195 .<br>
5196 <tt>smanip setw(int n);<br>
5197 </tt><br>
5198 -8- Returns: An object s of unspecified type such that if out is an
5199 instance of basic_ostream&lt;charT,traits&gt; then the expression
5200 out&lt;&lt;s behaves
5201 as if f(s, n) were called, or if in is an instance of
5202 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5203 behaves as if f(s, n)
5204 were called. The function f can be defined as:<br>
5205 <br>
5206 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
5207 &nbsp;&nbsp; {<br>
5208 &nbsp;&nbsp; //  set width<br>
5209 &nbsp;&nbsp; str.width(n);<br>
5210 &nbsp;&nbsp; return str;<br>
5211 &nbsp;&nbsp; }<br>
5212 </tt><br>
5213 The expression out&lt;&lt;s has type
5214 basic_ostream&lt;charT,traits&gt;&amp; and value out.  The expression
5215 in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value
5216 in.
5217 </p>
5218 </blockquote>
5219
5220 <p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
5221 the proposed resolution.]</i></p>
5222
5223 <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
5224 the same paragraphs.]</i></p>
5225
5226 <p><i>[Post-Tokyo: The issues list maintainer combined the proposed
5227 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
5228 intertwined that dealing with them separately appear fraught with
5229 error.  The full text was supplied by Bill Plauger; it was cross
5230 checked against changes supplied by Andy Sawyer. It should be further
5231 checked by the LWG.]</i></p>
5232 <hr>
5233 <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>
5234 <p>bools are defined by the standard to be of integer types, as per
5235 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"
5236 seems to have a special meaning for the author of 18.2. The net effect
5237 is an unclear and confusing specification for
5238 numeric_limits&lt;bool&gt; as evidenced below.</p>
5239
5240 <p>18.2.1.2/7 says numeric_limits&lt;&gt;::digits is, for built-in integer
5241 types, the number of non-sign bits in the representation.</p>
5242
5243 <p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
5244 arithmetical value converts to true.</p>
5245
5246 <p>I don't think it makes sense at all to require
5247 numeric_limits&lt;bool&gt;::digits and numeric_limits&lt;bool&gt;::digits10 to
5248 be meaningful.</p>
5249
5250 <p>The standard defines what constitutes a signed (resp. unsigned) integer
5251 types. It doesn't categorize bool as being signed or unsigned. And the set of
5252 values of bool type has only two elements.</p>
5253
5254 <p>I don't think it makes sense to require numeric_limits&lt;bool&gt;::is_signed
5255 to be meaningful.</p>
5256
5257 <p>18.2.1.2/18 for numeric_limits&lt;integer_type&gt;::radix&nbsp; says:</p>
5258 <blockquote>
5259   <p>For integer types, specifies the base of the representation.186)</p>
5260 </blockquote>
5261
5262 <p>This disposition is at best misleading and confusing for the standard
5263 requires a "pure binary numeration system" for integer types as per
5264 3.9.1/7</p>
5265
5266 <p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
5267 BCD)."&nbsp; This also erroneous as the standard never defines any integer
5268 types with base representation other than 2.</p>
5269
5270 <p>Furthermore, numeric_limits&lt;bool&gt;::is_modulo and
5271 numeric_limits&lt;bool&gt;::is_signed have similar problems.</p>
5272 <p><b>Proposed resolution:</b></p>
5273 <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>
5274 <blockquote>
5275   <p>The specialization for bool shall be provided as follows:</p>
5276   <pre>    namespace std {
5277        template&lt;&gt; class numeric_limits&lt;bool&gt; {
5278        public:
5279          static const bool is_specialized = true;
5280          static bool min() throw() { return false; }
5281          static bool max() throw() { return true; }
5282
5283          static const int  digits = 1;
5284          static const int  digits10 = 0;
5285          static const bool is_signed = false;
5286          static const bool is_integer = true;
5287          static const bool is_exact = true;
5288          static const int  radix = 2;
5289          static bool epsilon() throw() { return 0; }
5290          static bool round_error() throw() { return 0; }
5291
5292          static const int  min_exponent = 0;
5293          static const int  min_exponent10 = 0;
5294          static const int  max_exponent = 0;
5295          static const int  max_exponent10 = 0;
5296
5297          static const bool has_infinity = false;
5298          static const bool has_quiet_NaN = false;
5299          static const bool has_signaling_NaN = false;
5300          static const float_denorm_style has_denorm = denorm_absent;
5301          static const bool has_denorm_loss = false;
5302          static bool infinity() throw() { return 0; }
5303          static bool quiet_NaN() throw() { return 0; }
5304          static bool signaling_NaN() throw() { return 0; }
5305          static bool denorm_min() throw() { return 0; }
5306
5307          static const bool is_iec559 = false;
5308          static const bool is_bounded = true;
5309          static const bool is_modulo = false;
5310
5311          static const bool traps = false;
5312          static const bool tinyness_before = false;
5313          static const float_round_style round_style = round_toward_zero;
5314        };
5315      }</pre>
5316 </blockquote>
5317
5318 <p><i>[Tokyo:&nbsp; The LWG desires wording that specifies exact values
5319 rather than more general wording in the original proposed
5320 resolution.]</i></p>
5321
5322 <p><i>[Post-Tokyo:&nbsp; At the request of the LWG in Tokyo, Nico
5323 Josuttis provided the above wording.]</i></p>
5324 <hr>
5325 <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.function.objects"> [lib.function.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;UK Panel&nbsp; <b>Date:</b>&nbsp;26 Jul 1999</p>
5326 <p>Paragraph 4 of 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> says:</p>
5327 <blockquote>
5328   <p>&nbsp;[Example: To negate every element of a: transform(a.begin(), a.end(),
5329   a.begin(), negate&lt;double&gt;()); The corresponding functions will inline
5330   the addition and the negation. end example]</p>
5331 </blockquote>
5332 <p>(Note: The "addition" referred to in the above is in para 3) we can
5333 find no other wording, except this (non-normative) example which suggests that
5334 any "inlining" will take place in this case.</p>
5335 <p>Indeed both:</p>
5336 <blockquote>
5337   <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
5338   unspecified whether any global functions in the C++ Standard Library
5339   are defined as inline (7.1.2).</p>
5340 </blockquote>
5341 <p>and</p>
5342 <blockquote>
5343   <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
5344   unspecified whether any member functions in the C++ Standard Library
5345   are defined as inline (7.1.2).</p>
5346 </blockquote>
5347 <p>take care to state that this may indeed NOT be the case.</p>
5348 <p>Thus the example "mandates" behavior that is explicitly
5349 not required elsewhere.</p>
5350 <p><b>Proposed resolution:</b></p>
5351 <p>In 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 1, remove the sentence:</p>
5352 <blockquote>
5353 <p>They are important for the effective use of the library.</p>
5354 </blockquote>
5355 <p>Remove 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 2, which reads:</p>
5356 <blockquote>
5357   <p> Using function objects together with function templates
5358   increases the expressive power of the library as well as making the
5359   resulting code much more efficient.</p>
5360 </blockquote>
5361 <p>In 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 4, remove the sentence:</p>
5362 <blockquote>
5363   <p>The corresponding functions will inline the addition and the
5364   negation.</p>
5365 </blockquote>
5366
5367 <p><i>[Kona: The LWG agreed there was a defect.]</i></p>
5368 <p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
5369 <hr>
5370 <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>
5371 <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
5372 bitset::set operation to take a second parameter of type int. The
5373 function tests whether this value is non-zero to determine whether to
5374 set the bit to true or false. The type of this second parameter should
5375 be bool. For one thing, the intent is to specify a Boolean value. For
5376 another, the result type from test() is bool. In addition, it's
5377 possible to slice an integer that's larger than an int. This can't
5378 happen with bool, since conversion to bool has the semantic of
5379 translating 0 to false and any non-zero value to true.</p>
5380 <p><b>Proposed resolution:</b></p>
5381 <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>
5382 <blockquote>
5383 <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = true ); </pre>
5384 </blockquote>
5385 <p>With:</p>
5386 <blockquote>
5387   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
5388 </blockquote>
5389 <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>
5390 <blockquote>
5391   <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = 1 );</pre>
5392 </blockquote>
5393 <p>With:</p>
5394 <blockquote>
5395   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
5396 </blockquote>
5397
5398 <p><i>[Kona: The LWG agrees with the description.&nbsp; Andy Sawyer will work
5399 on better P/R wording.]</i></p>
5400 <p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
5401 <p><b>Rationale:</b></p>
5402 <p><tt>bool</tt> is a better choice.  It is believed that binary
5403 compatibility is not an issue, because this member function is
5404 usually implemented as <tt>inline</tt>, and because it is already
5405 the case that users cannot rely on the type of a pointer to a
5406 nonvirtual member of a standard library class.</p>
5407 <hr>
5408 <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>
5409 <p>The description of iter_swap in 25.2.2 paragraph 7,says that it
5410 ``exchanges the values'' of the objects to which two iterators
5411 refer.<br> <br> What it doesn't say is whether it does so using swap
5412 or using the assignment operator and copy constructor.<br> <br> This
5413 question is an important one to answer, because swap is specialized to
5414 work efficiently for standard containers.<br> For example:</p>
5415 <blockquote>
5416 <pre>vector&lt;int&gt; v1, v2;
5417 iter_swap(&amp;v1, &amp;v2);</pre>
5418 </blockquote>
5419 <p>Is this call to iter_swap equivalent to calling swap(v1, v2)?&nbsp;
5420 Or is it equivalent to</p>
5421 <blockquote>
5422 <pre>{
5423 vector&lt;int&gt; temp = v1;
5424 v1 = v2;
5425 v2 = temp;
5426 }</pre>
5427 </blockquote>
5428 <p>The first alternative is O(1); the second is O(n).</p>
5429 <p>A LWG member, Dave Abrahams, comments:</p>
5430 <blockquote>
5431 <p>Not an objection necessarily, but I want to point out the cost of
5432 that requirement:</p>
5433   <blockquote>
5434 <p><tt>iter_swap(list&lt;T&gt;::iterator, list&lt;T&gt;::iterator)</tt></p>
5435   </blockquote>
5436 <p>can currently be specialized to be more efficient than
5437 iter_swap(T*,T*) for many T (by using splicing). Your proposal would
5438 make that optimization illegal.&nbsp;</p>
5439 </blockquote>
5440
5441 <p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
5442 which are no longer permitted.]</i></p>
5443 <p><b>Proposed resolution:</b></p>
5444 <p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
5445 <blockquote>
5446 <p>Exchanges the values pointed to by the two iterators a and b.</p>
5447 </blockquote>
5448 <p>to</p>
5449 <blockquote>
5450 <p><tt>swap(*a, *b)</tt>.</p>
5451 </blockquote>
5452
5453 <p><b>Rationale:</b></p>
5454 <p>It's useful to say just what <tt>iter_swap</tt> does.  There may be
5455   some iterators for which we want to specialize <tt>iter_swap</tt>,
5456   but the fully general version should have a general specification.</p>
5457
5458 <p>Note that in the specific case of <tt>list&lt;T&gt;::iterator</tt>,
5459 iter_swap should not be specialized as suggested above.  That would do
5460 much more than exchanging the two iterators' values: it would change
5461 predecessor/successor relationships, possibly moving the iterator from
5462 one list to another.  That would surely be inappropriate.</p>
5463 <hr>
5464 <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>
5465 <p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
5466 and includes a parenthetical note saying that it is the number of
5467 digits after the decimal point.<br>
5468 <br>
5469 This claim is not strictly correct.  For example, in the default
5470 floating-point output format, setprecision sets the number of
5471 significant digits printed, not the number of digits after the decimal
5472 point.<br>
5473 <br>
5474 I would like the committee to look at the definition carefully and
5475 correct the statement in 27.4.2.2</p>
5476 <p><b>Proposed resolution:</b></p>
5477 <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
5478 "(number of digits after the decimal point)".</p>
5479 <hr>
5480 <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>
5481 <p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
5482 is<br>
5483 <br>
5484 &nbsp;&nbsp;&nbsp; `"(1) *a is the largest element"<br>
5485 <br>
5486 I think this is incorrect and should be changed to the wording in the proposed
5487 resolution.</p>
5488 <p>Actually there are two independent changes:</p>
5489 <blockquote>
5490   <p>A-"part of largest equivalence class" instead of "largest", cause 25.3
5491   [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
5492   <p>B-Take
5493 'an oldest' from that equivalence class, otherwise the heap functions
5494 could not be used for a priority queue as explained in 23.2.3.2.2
5495 [lib.priqueue.members] (where I assume that a "priority queue" respects
5496 priority AND time).</p>
5497 </blockquote>
5498 <p><b>Proposed resolution:</b></p>
5499 <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>
5500 <blockquote>
5501   <p>(1) *a is the largest element</p>
5502 </blockquote>
5503 <p>to:</p>
5504 <blockquote>
5505   <p>(1) There is no element greater than <tt>*a</tt></p>
5506 </blockquote>
5507 <hr>
5508 <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>
5509 <p>Suppose that <tt>is.flags() &amp; ios_base::skipws</tt> is nonzero.
5510 What should <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor do if it
5511 reaches eof while skipping whitespace?  27.6.1.1.2/5 suggests it
5512 should set failbit. Should it set eofbit as well?  The standard
5513 doesn't seem to answer that question.</p>
5514
5515 <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
5516 <tt>basic_istream&lt;&gt;::sentry</tt> should ever set eofbit.  On the
5517 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
5518 extraction from a <tt>streambuf</tt> "returns
5519 <tt>traits::eof()</tt>, then the input function, except as explicitly
5520 noted otherwise, completes its actions and does
5521 <tt>setstate(eofbit)"</tt>.  So the question comes down to
5522 whether <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor is an
5523 input function.</p>
5524
5525 <p>Comments from Jerry Schwarz:</p>
5526 <blockquote>
5527 <p>It was always my intention that eofbit should be set any time that a
5528 virtual returned something to indicate eof, no matter what reason
5529 iostream code had for calling the virtual.</p>
5530 <p>
5531 The motivation for this is that I did not want to require streambufs
5532 to behave consistently if their virtuals are called after they have
5533 signaled eof.</p>
5534 <p>
5535 The classic case is a streambuf reading from a UNIX file.  EOF isn't
5536 really a state for UNIX file descriptors.  The convention is that a
5537 read on UNIX returns 0 bytes to indicate "EOF", but the file
5538 descriptor isn't shut down in any way and future reads do not
5539 necessarily also return 0 bytes.  In particular, you can read from
5540 tty's on UNIX even after they have signaled "EOF".  (It
5541 isn't always understood that a ^D on UNIX is not an EOF indicator, but
5542 an EOL indicator.  By typing a "line" consisting solely of
5543 ^D you cause a read to return 0 bytes, and by convention this is
5544 interpreted as end of file.)</p>
5545 </blockquote>
5546 <p><b>Proposed resolution:</b></p>
5547 <p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
5548 <blockquote>
5549 <p>If <tt>is.rdbuf()-&gt;sbumpc()</tt> or <tt>is.rdbuf()-&gt;sgetc()</tt>
5550 returns <tt>traits::eof()</tt>, the function calls
5551 <tt>setstate(failbit | eofbit)</tt> (which may throw
5552 <tt>ios_base::failure</tt>).
5553 </p>
5554 </blockquote>
5555 <hr>
5556 <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>
5557 <p>
5558 Is a pointer or reference obtained from an iterator still valid after
5559 destruction of the iterator?
5560 </p>
5561 <p>
5562 Is a pointer or reference obtained from an iterator still valid after the value
5563 of the iterator changes?
5564 </p>
5565 <blockquote>
5566 <pre>#include &lt;iostream&gt;
5567 #include &lt;vector&gt;
5568 #include &lt;iterator&gt;
5569
5570 int main()
5571 {
5572     typedef std::vector&lt;int&gt; vec_t;
5573     vec_t v;
5574     v.push_back( 1 );
5575
5576     // Is a pointer or reference obtained from an iterator still
5577     // valid after destruction of the iterator?
5578     int * p = &amp;*v.begin();
5579     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
5580
5581     // Is a pointer or reference obtained from an iterator still
5582     // valid after the value of the iterator changes?
5583     vec_t::iterator iter( v.begin() );
5584     p = &amp;*iter++;
5585     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
5586
5587     return 0;
5588 }
5589 </pre>
5590 </blockquote>
5591
5592 <p>The standard doesn't appear to directly address these
5593 questions. The standard needs to be clarified. At least two real-world
5594 cases have been reported where library implementors wasted
5595 considerable effort because of the lack of clarity in the
5596 standard. The question is important because requiring pointers and
5597 references to remain valid has the effect for practical purposes of
5598 prohibiting iterators from pointing to cached rather than actual
5599 elements of containers.</p>
5600
5601 <p>The standard itself assumes that pointers and references obtained
5602 from an iterator are still valid after iterator destruction or
5603 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.op.star"> [lib.reverse.iter.op.star]</a>, which returns a reference, defines
5604 effects:</p>
5605
5606 <blockquote>
5607   <pre>Iterator tmp = current;
5608 return *--tmp;</pre>
5609 </blockquote>
5610 <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.opref"> [lib.reverse.iter.opref]</a>, which returns a pointer, defines effects:</p>
5611 <blockquote>
5612   <pre>return &amp;(operator*());</pre>
5613 </blockquote>
5614
5615 <p>Because the standard itself assumes pointers and references remain
5616 valid after iterator destruction or change, the standard should say so
5617 explicitly. This will also reduce the chance of user code breaking
5618 unexpectedly when porting to a different standard library
5619 implementation.</p>
5620 <p><b>Proposed resolution:</b></p>
5621 <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>
5622 <blockquote>
5623 Destruction of an iterator may invalidate pointers and references
5624 previously obtained from that iterator.
5625 </blockquote>
5626
5627 <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.op.star"> [lib.reverse.iter.op.star]</a> with:</p>
5628
5629 <blockquote>
5630 <p><b>Effects:</b></p>
5631 <pre>  this-&gt;tmp = current;
5632   --this-&gt;tmp;
5633   return *this-&gt;tmp;
5634 </pre>
5635
5636 <p>
5637 [<i>Note:</i> This operation must use an auxiliary member variable,
5638 rather than a temporary variable, to avoid returning a reference that
5639 persists beyond the lifetime of its associated iterator.  (See
5640 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
5641 exposition only.  <i>--end note</i>]
5642 </p>
5643 </blockquote>
5644
5645 <p><i>[Post-Tokyo: The issue has been reformulated purely
5646 in terms of iterators.]</i></p>
5647
5648 <p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
5649 assumption by reverse_iterator. The issue and proposed resolution was
5650 reformulated yet again to reflect this reality.]</i></p>
5651
5652 <p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
5653 assumes its underlying iterator has persistent pointers and
5654 references.  Andy Koenig pointed out that it is possible to rewrite
5655 reverse_iterator so that it no longer makes such an assupmption.
5656 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
5657 decide it is intentional that <tt>p[n]</tt> may return by value
5658 instead of reference when <tt>p</tt> is a Random Access Iterator,
5659 other changes in reverse_iterator will be necessary.]</i></p>
5660 <p><b>Rationale:</b></p>
5661 <p>This issue has been discussed extensively.  Note that it is
5662 <i>not</i> an issue about the behavior of predefined iterators.  It is
5663 asking whether or not user-defined iterators are permitted to have
5664 transient pointers and references.  Several people presented examples
5665 of useful user-defined iterators that have such a property; examples
5666 include a B-tree iterator, and an "iota iterator" that doesn't point
5667 to memory.  Library implementors already seem to be able to cope with
5668 such iterators: they take pains to avoid forming references to memory
5669 that gets iterated past.  The only place where this is a problem is
5670 <tt>reverse_iterator</tt>, so this issue changes
5671 <tt>reverse_iterator</tt> to make it work.</p>
5672
5673 <p>This resolution does not weaken any guarantees provided by
5674 predefined iterators like <tt>list&lt;int&gt;::iterator</tt>.
5675 Clause 23 should be reviewed to make sure that guarantees for
5676 predefined iterators are as strong as users expect.</p>
5677
5678 <hr>
5679 <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.allocator.requirements"> [lib.allocator.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;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Nov 1999</p>
5680 <p>
5681 Suppose that <tt>A</tt> is a class that conforms to the
5682 Allocator requirements of Table 32, and <tt>a</tt> is an
5683 object of class <tt>A</tt>  What should be the return
5684 value of <tt>a.allocate(0)</tt>?  Three reasonable
5685 possibilities: forbid the argument <tt>0</tt>, return
5686 a null pointer, or require that the return value be a
5687 unique non-null pointer.
5688 </p>
5689 <p><b>Proposed resolution:</b></p>
5690 <p>
5691 Add a note to the <tt>allocate</tt> row of Table 32:
5692 "[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
5693 <p><b>Rationale:</b></p>
5694 <p>A key to understanding this issue is that the ultimate use of
5695 allocate() is to construct an iterator, and that iterator for zero
5696 length sequences must be the container's past-the-end
5697 representation.  Since this already implies special case code, it
5698 would be over-specification to mandate the return value.
5699 </p>
5700 <hr>
5701 <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>
5702 <p>
5703 In table 74, the return type of the expression <tt>*a</tt> is given
5704 as <tt>T&amp;</tt>, where <tt>T</tt> is the iterator's value type.
5705 For constant iterators, however, this is wrong.  ("Value type"
5706 is never defined very precisely, but it is clear that the value type
5707 of, say, <tt>std::list&lt;int&gt;::const_iterator</tt> is supposed to be
5708 <tt>int</tt>, not <tt>const int</tt>.)
5709 </p>
5710 <p><b>Proposed resolution:</b></p>
5711 <p>
5712 In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
5713 return type from "<tt>T&amp;</tt>" to "<tt>T&amp;</tt>
5714 if <tt>X</tt> is mutable, otherwise <tt>const T&amp;</tt>".
5715 In the <tt>a-&gt;m</tt> row, change the return type from
5716 "<tt>U&amp;</tt>" to "<tt>U&amp;</tt> if <tt>X</tt> is mutable,
5717 otherwise <tt>const U&amp;</tt>".
5718 </p>
5719
5720 <p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
5721 there are multiple const problems with the STL portion of the library
5722 and that these should be addressed as a single package.&nbsp; Note
5723 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
5724 that very reason.]</i></p>
5725
5726 <p><i>[Redmond: the LWG thinks this is separable from other constness
5727 issues.  This issue is just cleanup; it clarifies language that was
5728 written before we had iterator_traits.  Proposed resolution was
5729 modified: the original version only discussed *a.  It was pointed out
5730 that we also need to worry about *r++ and a-&gt;m.]</i></p>
5731
5732 <hr>
5733 <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>
5734 <p>
5735 What should unique() do if you give it a predicate that is not an
5736 equivalence relation?  There are at least two plausible answers:
5737 </p>
5738
5739 <blockquote>
5740
5741 <p>
5742    1. You can't, because 25.2.8 says that it it "eliminates all but
5743    the first element from every consecutive group of equal
5744    elements..." and it wouldn't make sense to interpret "equal" as
5745    meaning anything but an equivalence relation.  [It also doesn't
5746    make sense to interpret "equal" as meaning ==, because then there
5747    would never be any sense in giving a predicate as an argument at
5748    all.]
5749 </p>
5750
5751 <p>
5752    2. The word "equal" should be interpreted to mean whatever the
5753    predicate says, even if it is not an equivalence relation
5754    (and in particular, even if it is not transitive).
5755 </p>
5756
5757 </blockquote>
5758
5759 <p>
5760 The example that raised this question is from Usenet:
5761 </p>
5762
5763 <blockquote>
5764
5765 <pre>int f[] = { 1, 3, 7, 1, 2 };
5766 int* z = unique(f, f+5, greater&lt;int&gt;());</pre>
5767
5768 </blockquote>
5769
5770 <p>
5771 If one blindly applies the definition using the predicate
5772 greater&lt;int&gt;, and ignore the word "equal", you get:
5773 </p>
5774
5775 <blockquote>
5776
5777 <p>
5778     Eliminates all but the first element from every consecutive group
5779     of elements referred to by the iterator i in the range [first, last)
5780     for which *i &gt; *(i - 1).
5781 </p>
5782
5783 </blockquote>
5784
5785 <p>
5786 The first surprise is the order of the comparison.  If we wanted to
5787 allow for the predicate not being an equivalence relation, then we
5788 should surely compare elements the other way: pred(*(i - 1), *i).  If
5789 we do that, then the description would seem to say: "Break the
5790 sequence into subsequences whose elements are in strictly increasing
5791 order, and keep only the first element of each subsequence".  So the
5792 result would be 1, 1, 2.  If we take the description at its word, it
5793 would seem to call for strictly DEcreasing order, in which case the
5794 result should be 1, 3, 7, 2.<br>
5795 <br>
5796 In fact, the SGI implementation of unique() does neither: It yields 1,
5797 3, 7.
5798 </p>
5799 <p><b>Proposed resolution:</b></p>
5800 <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>
5801 <blockquote>
5802 For a nonempty range, eliminates all but the first element from every
5803 consecutive group of equivalent elements referred to by the iterator
5804 <tt>i</tt> in the range [first+1, last) for which the following
5805 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
5806 false</tt>.
5807 </blockquote>
5808
5809 <p>
5810 Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
5811 comparison function must be an equivalence relation."
5812 </p>
5813
5814 <p><i>[Redmond: discussed arguments for and against requiring the
5815 comparison function to be an equivalence relation.  Straw poll:
5816 14-2-5.  First number is to require that it be an equivalence
5817 relation, second number is to explicitly not require that it be an
5818 equivalence relation, third number is people who believe they need
5819 more time to consider the issue.  A separate issue: Andy Sawyer
5820 pointed out that "i-1" is incorrect, since "i" can refer to the first
5821 iterator in the range.  Matt provided wording to address this
5822 problem.]</i></p>
5823
5824 <p><i>[Curaçao: The LWG changed "... the range (first,
5825 last)..." to "...  the range [first+1, last)..." for
5826 clarity. They considered this change close enough to editorial to not
5827 require another round of review.]</i></p>
5828
5829 <p><b>Rationale:</b></p>
5830 <p>The LWG also considered an alternative resolution: change
5831 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>
5832
5833 <blockquote>
5834 For a nonempty range, eliminates all but the first element from every
5835 consecutive group of elements referred to by the iterator
5836 <tt>i</tt> in the range (first, last) for which the following
5837 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
5838 false</tt>.
5839 </blockquote>
5840
5841 <p>
5842 Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
5843 comparison function need not be an equivalence relation."
5844 </p>
5845
5846
5847 <p>Informally: the proposed resolution imposes an explicit requirement
5848 that the comparison function be an equivalence relation.  The
5849 alternative resolution does not, and it gives enough information so
5850 that the behavior of unique() for a non-equivalence relation is
5851 specified.  Both resolutions are consistent with the behavior of
5852 existing implementations.</p>
5853 <hr>
5854 <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>
5855 <p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
5856 past-the-end values are always non-singular."</p>
5857 <p>This places an unnecessary restriction on past-the-end iterators for
5858 containers with forward iterators (for example, a singly-linked list). If the
5859 past-the-end value on such a container was a well-known singular value, it would
5860 still satisfy all forward iterator requirements.</p>
5861 <p>Removing this restriction would allow, for example, a singly-linked list
5862 without a "footer" node.</p>
5863 <p>This would have an impact on existing code that expects past-the-end
5864 iterators obtained from different (generic) containers being not equal.</p>
5865 <p><b>Proposed resolution:</b></p>
5866 <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>
5867 <blockquote>
5868 <p>Dereferenceable and past-the-end values are always non-singular.</p>
5869 </blockquote>
5870 <p>to:</p>
5871 <blockquote>
5872 <p>Dereferenceable values are always non-singular.&nbsp;</p>
5873 </blockquote>
5874 <p><b>Rationale:</b></p>
5875 <p>For some kinds of containers, including singly linked lists and
5876 zero-length vectors, null pointers are perfectly reasonable past-the-end
5877 iterators.  Null pointers are singular.
5878 </p>
5879 <hr>
5880 <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>
5881 <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
5882 declarations use a consistent style except for the following functions:</p>
5883 <blockquote>
5884   <pre>void push_back(const charT);
5885 basic_string&amp; assign(const basic_string&amp;);
5886 void swap(basic_string&lt;charT,traits,Allocator&gt;&amp;);</pre>
5887 </blockquote>
5888 <p>- push_back, assign, swap: missing argument name&nbsp;<br>
5889 - push_back: use of const with charT (i.e. POD type passed by value
5890 not by reference - should be charT or const charT&amp; )<br>
5891 - swap: redundant use of template parameters in argument
5892 basic_string&lt;charT,traits,Allocator&gt;&amp;</p>
5893 <p><b>Proposed resolution:</b></p>
5894 <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
5895 function declarations push_back, assign, and swap to:</p>
5896 <blockquote>
5897   <pre>void push_back(charT c);
5898
5899 basic_string&amp; assign(const basic_string&amp; str);
5900 void swap(basic_string&amp; str);</pre>
5901 </blockquote>
5902 <p><b>Rationale:</b></p>
5903 <p>Although the standard is in general not consistent in declaration
5904 style, the basic_string declarations are consistent other than the
5905 above.  The LWG felt that this was sufficient reason to merit the
5906 change.
5907 </p>
5908 <hr>
5909 <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>
5910 <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>
5911 <blockquote>
5912   <p>      In the description of the algorithms operators + and - are used
5913            for some of the iterator categories for which they do not have to
5914            be defined. In these cases the semantics of [...] a-b is the same
5915            as of<br>
5916   <br>
5917   &nbsp;&nbsp;&nbsp;&nbsp; <tt>return distance(a, b);</tt></p>
5918 </blockquote>
5919 <p><b>Proposed resolution:</b></p>
5920 <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
5921 <tt>"a-b"</tt> to <tt>"b-a".</tt></p>
5922 <p><b>Rationale:</b></p>
5923 <p>There are two ways to fix the defect; change the description to b-a
5924 or change the return to distance(b,a).  The LWG preferred the
5925 former for consistency.</p>
5926 <hr>
5927 <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>
5928 <p>The description of the stream extraction operator for std::string (section
5929 21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
5930 the case that the operator fails to extract any characters from the input
5931 stream.</p>
5932 <p>This implies that the typical construction</p>
5933 <blockquote>
5934   <pre>std::istream is;
5935 std::string str;
5936 ...
5937 while (is &gt;&gt; str) ... ;</pre>
5938 </blockquote>
5939 <p>(which tests failbit) is not required to terminate at EOF.</p>
5940 <p>Furthermore, this is inconsistent with other extraction operators,
5941 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
5942 requirement is present, either explicitly or implicitly, for the
5943 extraction operators. It is also present explicitly in the description
5944 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>
5945 <p><b>Proposed resolution:</b></p>
5946 <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>
5947 <blockquote>
5948
5949 <p>If the function extracts no characters, it calls
5950 is.setstate(ios::failbit) which may throw ios_base::failure
5951 (27.4.4.3).</p>
5952 </blockquote>
5953 <hr>
5954 <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>
5955 <p>The standard doesn't specify what min_element() and max_element() shall
5956 return if the range is empty (first equals last). The usual implementations
5957 return last. This problem seems also apply to partition(), stable_partition(),
5958 next_permutation(), and prev_permutation().</p>
5959 <p><b>Proposed resolution:</b></p>
5960 <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
5961 9, append: Returns last if first==last.</p>
5962 <p><b>Rationale:</b></p>
5963 <p>The LWG looked in some detail at all of the above mentioned
5964 algorithms, but believes that except for min_element() and
5965 max_element() it is already clear that last is returned if first ==
5966 last.</p>
5967 <hr>
5968 <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>
5969 <p>The specification for the associative container requirements in
5970 Table 69 state that the find member function should "return
5971 iterator; const_iterator for constant a". The map and multimap
5972 container descriptions have two overloaded versions of find, but set
5973 and multiset do not, all they have is:</p>
5974 <blockquote>
5975   <pre>iterator find(const key_type &amp; x) const;</pre>
5976 </blockquote>
5977 <p><b>Proposed resolution:</b></p>
5978 <p>Change the prototypes for find(), lower_bound(), upper_bound(), and
5979 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>
5980 <blockquote>
5981   <pre>iterator find(const key_type &amp; x);
5982 const_iterator find(const key_type &amp; x) const;</pre>
5983   <pre>iterator lower_bound(const key_type &amp; x);
5984 const_iterator lower_bound(const key_type &amp; x) const;</pre>
5985   <pre>iterator upper_bound(const key_type &amp; x);
5986 const_iterator upper_bound(const key_type &amp; x) const;</pre>
5987   <pre>pair&lt;iterator, iterator&gt; equal_range(const key_type &amp; x);
5988 pair&lt;const_iterator, const_iterator&gt; equal_range(const key_type &amp; x) const;</pre>
5989 </blockquote>
5990
5991 <p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
5992 extending the proposed resolution to lower_bound, upper_bound, and
5993 equal_range.]</i></p>
5994 <hr>
5995 <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>
5996 <p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
5997 <p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
5998 must be const in order for it to be callable on a const object (a reference to
5999 which which is what std::use_facet&lt;&gt;() returns).</p>
6000 <p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
6001 name of the namespace `My'.</p>
6002 <p>3) In the definition of `loc' and subsequently in the call to use_facet&lt;&gt;()
6003 in main(), the name of the facet is misspelled: it should read `My::JCtype'
6004 rather than `My::JCType'.</p>
6005 <p><b>Proposed resolution:</b></p>
6006 <p>Replace the "Classifying Japanese characters" example in 22.2.8,
6007 paragraph 11 with the following:</p>
6008 <pre>#include &lt;locale&gt;</pre>
6009 <pre>namespace My {
6010     using namespace std;
6011     class JCtype : public locale::facet {
6012     public:
6013         static locale::id id;     //  required for use as a new locale facet
6014         bool is_kanji (wchar_t c) const;
6015         JCtype() {}
6016     protected:
6017         ~JCtype() {}
6018     };
6019 }</pre>
6020 <pre>//  file:  filt.C
6021 #include &lt;iostream&gt;
6022 #include &lt;locale&gt;
6023 #include "jctype"                 //  above
6024 std::locale::id My::JCtype::id;   //  the static  JCtype  member
6025 declared above.</pre>
6026 <pre>int main()
6027 {
6028     using namespace std;
6029     typedef ctype&lt;wchar_t&gt; wctype;
6030     locale loc(locale(""),              //  the user's preferred locale...
6031                new My::JCtype);         //  and a new feature ...
6032     wchar_t c = use_facet&lt;wctype&gt;(loc).widen('!');
6033     if (!use_facet&lt;My::JCtype&gt;(loc).is_kanji(c))
6034         cout &lt;&lt; "no it isn't!" &lt;&lt; endl;
6035     return 0;
6036 }</pre>
6037 <hr>
6038 <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>
6039 <p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
6040 paragraph 2:</p>
6041 <blockquote>
6042   <p>Effects: Destroys an object of class ios_base. Calls each registered
6043   callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
6044   time that any ios_base member function called from within fn has well defined
6045   results.</p>
6046 </blockquote>
6047 <p>But what is not clear is: If no callback functions were ever registered, does
6048 it matter whether the ios_base members were ever initialized?</p>
6049 <p>For instance, does this program have defined behavior:</p>
6050 <blockquote>
6051   <pre>#include &lt;ios&gt;</pre>
6052   <pre>class D : public std::ios_base { };</pre>
6053   <pre>int main() { D d; }</pre>
6054 </blockquote>
6055 <p>It seems that registration of a callback function would surely affect the
6056 state of an ios_base. That is, when you register a callback function with an
6057 ios_base, the ios_base must record that fact somehow.</p>
6058 <p>But if after construction the ios_base is in an indeterminate state, and that
6059 state is not made determinate before the destructor is called, then how would
6060 the destructor know if any callbacks had indeed been registered? And if the
6061 number of callbacks that had been registered is indeterminate, then is not the
6062 behavior of the destructor undefined?</p>
6063 <p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
6064 it explicit that destruction before initialization results in undefined
6065 behavior.</p>
6066 <p><b>Proposed resolution:</b></p>
6067 <p>Modify 27.4.2.7 paragraph 1 from</p>
6068 <blockquote>
6069   <p>Effects: Each ios_base member has an indeterminate value after
6070   construction.</p>
6071 </blockquote>
6072 <p>to</p>
6073 <blockquote>
6074   <p>Effects: Each ios_base member has an indeterminate
6075 value after construction. These members must be initialized by calling
6076 basic_ios::init. If an ios_base object is destroyed before these
6077 initializations have taken place, the behavior is undefined.</p>
6078 </blockquote>
6079 <hr>
6080 <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>
6081 <p>Stage 2 processing of numeric conversion is broken.</p>
6082
6083 <p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
6084 conversion specifier is %i. A %i specifier determines a number's base
6085 by its prefix (0 for octal, 0x for hex), so the intention is clearly
6086 that a 0x prefix is allowed.  Paragraph 8 in the same section,
6087 however, describes very precisely how characters are processed. (It
6088 must be done "as if" by a specified code fragment.) That
6089 description does not allow a 0x prefix to be recognized.</p>
6090
6091 <p>Very roughly, stage 2 processing reads a char_type ct. It converts
6092 ct to a char, not by using narrow but by looking it up in a
6093 translation table that was created by widening the string literal
6094 "0123456789abcdefABCDEF+-". The character "x" is
6095 not found in that table, so it can't be recognized by stage 2
6096 processing.</p>
6097 <p><b>Proposed resolution:</b></p>
6098 <p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
6099 <blockquote>
6100   <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
6101 </blockquote>
6102 <p>with the line:</p>
6103 <blockquote>
6104   <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
6105 </blockquote>
6106 <p><b>Rationale:</b></p>
6107 <p>If we're using the technique of widening a string literal, the
6108 string literal must contain every character we wish to recognize.
6109 This technique has the consequence that alternate representations
6110 of digits will not be recognized.  This design decision was made
6111 deliberately, with full knowledge of that limitation.</p>
6112 <hr>
6113 <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>
6114 <p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
6115 <blockquote>
6116   <pre>21.3.6.8 - basic_string::compare [lib.string::compare]
6117
6118 int compare(size_type pos1, size_type n1,
6119                 const basic_string&lt;charT,traits,Allocator&gt;&amp;  str ,
6120                 size_type  pos2 , size_type  n2 ) const;
6121
6122 -4- Returns:
6123
6124     basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
6125                  basic_string&lt;charT,traits,Allocator&gt;(str,pos2,n2)) .</pre>
6126 </blockquote>
6127 <p>and the constructor that's implicitly called by the above is
6128 defined to throw an out-of-range exception if pos &gt; str.size(). See
6129 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>
6130
6131 <p>On the other hand, the compare function descriptions themselves don't have
6132 "Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
6133 that do not apply to a function are omitted.</p>
6134 <p>So it seems there is an inconsistency in the standard -- are the
6135 "Effects" clauses correct, or are the "Throws" clauses
6136 missing?</p>
6137 <p><b>Proposed resolution:</b></p>
6138 <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
6139 the sentence "Descriptions of function semantics contain the
6140 following elements (as appropriate):", insert the word
6141 "further" so that the foot note reads:</p>
6142 <blockquote>
6143   <p>To save space, items that do not apply to a function are
6144   omitted. For example, if a function does not specify any further
6145   preconditions, there will be no "Requires" paragraph.</p>
6146 </blockquote>
6147 <p><b>Rationale:</b></p>
6148 <p>The standard is somewhat inconsistent, but a failure to note a
6149 throw condition in a throws clause does not grant permission not to
6150 throw.  The inconsistent wording is in a footnote, and thus
6151 non-normative. The proposed resolution from the LWG clarifies the
6152 footnote.</p>
6153 <hr>
6154 <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>
6155 <p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
6156 <p><b>Proposed resolution:</b></p>
6157 <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>
6158   <blockquote>
6159   Effects: For each non-negative integer i &lt;= (last - first)/2,
6160   applies swap to all pairs of iterators first + i, (last - i) - 1.
6161   </blockquote>
6162 <p>with:</p>
6163   <blockquote>
6164   Effects: For each non-negative integer i &lt;= (last - first)/2,
6165   applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
6166   </blockquote>
6167 <hr>
6168 <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>
6169 <p>In the associative container requirements table in 23.1.2 paragraph 7,
6170 a.clear() has complexity "log(size()) + N". However, the meaning of N
6171 is not defined.</p>
6172 <p><b>Proposed resolution:</b></p>
6173 <p>In the associative container requirements table in 23.1.2 paragraph
6174 7, the complexity of a.clear(), change "log(size()) + N" to
6175 "linear in <tt>size()</tt>".</p>
6176 <p><b>Rationale:</b></p>
6177 <p>It's the "log(size())", not the "N", that is in
6178 error: there's no difference between <i>O(N)</i> and <i>O(N +
6179 log(N))</i>.  The text in the standard is probably an incorrect
6180 cut-and-paste from the range version of <tt>erase</tt>.</p>
6181 <hr>
6182 <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>
6183 <p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
6184 user namespaces might be found through Koenig lookup?</p>
6185 <p>For example, a popular standard library implementation includes this
6186 implementation of std::unique:</p>
6187 <blockquote>
6188 <pre>namespace std {
6189     template &lt;class _ForwardIter&gt;
6190     _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
6191       __first = adjacent_find(__first, __last);
6192       return unique_copy(__first, __last, __first);
6193     }
6194     }</pre>
6195 </blockquote>
6196 <p>Imagine two users on opposite sides of town, each using unique on his own
6197 sequences bounded by my_iterators . User1 looks at his standard library
6198 implementation and says, "I know how to implement a more efficient
6199 unique_copy for my_iterators", and writes:</p>
6200 <blockquote>
6201 <pre>namespace user1 {
6202     class my_iterator;
6203     // faster version for my_iterator
6204     my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
6205     }</pre>
6206 </blockquote>
6207 <p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
6208 <p>User2 has other needs, and writes:</p>
6209 <blockquote>
6210 <pre>namespace user2 {
6211     class my_iterator;
6212     // Returns true iff *c is a unique copy of *a and *b.
6213     bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
6214     }</pre>
6215 </blockquote>
6216 <p>User2 is shocked to find later that his fully-qualified use of
6217 std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
6218 compile (if he's lucky). Looking in the standard, he sees the following Effects
6219 clause for unique():</p>
6220 <blockquote>
6221   <p>Effects: Eliminates all but the first element from every consecutive group
6222   of equal elements referred to by the iterator i in the range [first, last) for
6223   which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
6224   *(i - 1)) != false</p>
6225 </blockquote>
6226 <p>The standard gives user2 absolutely no reason to think he can interfere with
6227 std::unique by defining names in namespace user2. His standard library has been
6228 built with the template export feature, so he is unable to inspect the
6229 implementation. User1 eventually compiles his code with another compiler, and
6230 his version of unique_copy silently stops being called. Eventually, he realizes
6231 that he was depending on an implementation detail of his library and had no
6232 right to expect his unique_copy() to be called portably.</p>
6233 <p>On the face of it, and given above scenario, it may seem obvious that the
6234 implementation of unique() shown is non-conforming because it uses unique_copy()
6235 rather than ::std::unique_copy(). Most standard library implementations,
6236 however, seem to disagree with this notion.</p>
6237 <p> <i>[Tokyo:&nbsp; Steve Adamczyk from
6238 the core working group indicates that "std::" is sufficient;&nbsp;
6239 leading "::" qualification is not required because any namespace
6240 qualification is sufficient to suppress Koenig lookup.]</i></p>
6241 <p><b>Proposed resolution:</b></p>
6242 <p>Add a paragraph and a note at the end of
6243 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>
6244 <blockquote>
6245
6246 <p>Unless otherwise specified, no global or non-member function in the
6247 standard library shall use a function from another namespace which is
6248 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>
6249
6250 <p>[Note: the phrase "unless otherwise specified" is intended to
6251 allow Koenig lookup in cases like that of ostream_iterators:<br>
6252
6253 <br>
6254   Effects:</p>
6255   <blockquote>
6256 <p>*out_stream &lt;&lt; value;<br>
6257       if(delim != 0) *out_stream &lt;&lt; delim;<br>
6258       return (*this);</p>
6259     <p>--end note]</p>
6260   </blockquote>
6261 </blockquote>
6262
6263 <p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
6264 is as yet unsure if the proposed resolution is the best
6265 solution. Furthermore, the LWG believes that the same problem of
6266 unqualified library names applies to wording in the standard itself,
6267 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
6268 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
6269 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>.]</i></p>
6270
6271 <p><i>[Toronto: The LWG is not sure if this is a defect in the
6272 standard.  Most LWG members believe that an implementation of
6273 <tt>std::unique</tt> like the one quoted in this issue is already
6274 illegal, since, under certain circumstances, its semantics are not
6275 those specified in the standard.  The standard's description of
6276 <tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
6277 should have any effect.]</i></p>
6278
6279 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
6280 225, 226, and 229.  Their conclusion was that the issues should be
6281 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6282 EWG portion (Dave will write a proposal). The LWG and EWG had
6283 (separate) discussions of this plan the next day.  The proposed
6284 resolution for this issue is in accordance with Howard's paper.]</i></p>
6285
6286 <p><b>Rationale:</b></p>
6287 <p>It could be argued that this proposed isn't strictly necessary,
6288   that the Standard doesn't grant implementors license to write a
6289   standard function that behaves differently than specified in the
6290   Standard just because of an unrelated user-defined name in some
6291   other namespace.  However, this is at worst a clarification.  It is
6292   surely right that algorithsm shouldn't pick up random names, that
6293   user-defined names should have no effect unless otherwise specified.
6294   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
6295   appropriate for the standard to explicitly specify otherwise.</p>
6296 <hr>
6297 <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>
6298 <p>The issues are:&nbsp;</p>
6299 <p>1. How can a 3rd party library implementor (lib1) write a version of a standard
6300 algorithm which is specialized to work with his own class template?&nbsp;</p>
6301 <p>2. How can another library implementor (lib2) write a generic algorithm which
6302 will take advantage of the specialized algorithm in lib1?</p>
6303 <p>This appears to be the only viable answer under current language rules:</p>
6304 <blockquote>
6305   <pre>namespace lib1
6306 {
6307     // arbitrary-precision numbers using T as a basic unit
6308     template &lt;class T&gt;
6309     class big_num { //...
6310     };
6311     </pre>
6312   <pre>    // defining this in namespace std is illegal (it would be an
6313     // overload), so we hope users will rely on Koenig lookup
6314     template &lt;class T&gt;
6315     void swap(big_int&lt;T&gt;&amp;, big_int&lt;T&gt;&amp;);
6316 }</pre>
6317   <pre>#include &lt;algorithm&gt;
6318 namespace lib2
6319 {
6320     template &lt;class T&gt;
6321     void generic_sort(T* start, T* end)
6322     {
6323             ...
6324         // using-declaration required so we can work on built-in types
6325         using std::swap;
6326         // use Koenig lookup to find specialized algorithm if available
6327         swap(*x, *y);
6328     }
6329 }</pre>
6330 </blockquote>
6331 <p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
6332 and somewhat slippery. The implementor needs to remember to write the
6333 using-declaration, or generic_sort will fail to compile when T is a built-in
6334 type. The second drawback is that the use of this style in lib2 effectively
6335 "reserves" names in any namespace which defines types which may
6336 eventually be used with lib2. This may seem innocuous at first when applied to
6337 names like swap, but consider more ambiguous names like unique_copy() instead.
6338 It is easy to imagine the user wanting to define these names differently in his
6339 own namespace. A definition with semantics incompatible with the standard
6340 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>
6341 <p>Why, you may ask, can't we just partially specialize std::swap()? It's
6342 because the language doesn't allow for partial specialization of function
6343 templates. If you write:</p>
6344 <blockquote>
6345   <pre>namespace std
6346 {
6347     template &lt;class T&gt;
6348     void swap(lib1::big_int&lt;T&gt;&amp;, lib1::big_int&lt;T&gt;&amp;);
6349 }</pre>
6350 </blockquote>
6351 <p>You have just overloaded std::swap, which is illegal under the current
6352 language rules. On the other hand, the following full specialization is legal:</p>
6353 <blockquote>
6354   <pre>namespace std
6355 {
6356     template &lt;&gt;
6357     void swap(lib1::other_type&amp;, lib1::other_type&amp;);
6358 }</pre>
6359 </blockquote>
6360
6361 <p>This issue reflects concerns raised by the "Namespace issue
6362 with specialized swap" thread on comp.lang.c++.moderated. A
6363 similar set of concerns was earlier raised on the boost.org mailing
6364 list and the ACCU-general mailing list.  Also see library reflector
6365 message c++std-lib-7354.</p>
6366
6367 <p>
6368 J. C. van Winkel points out (in c++std-lib-9565) another unexpected
6369 fact: it's impossible to output a container of std::pair's using copy
6370 and an ostream_iterator, as long as both pair-members are built-in or
6371 std:: types.  That's because a user-defined operator&lt;&lt; for (for
6372 example) std::pair&lt;const std::string, int&gt; will not be found:
6373 lookup for operator&lt;&lt; will be performed only in namespace std.
6374 Opinions differed on whether or not this was a defect, and, if so,
6375 whether the defect is that something is wrong with user-defined
6376 functionality and std, or whether it's that the standard library does
6377 not provide an operator&lt;&lt; for std::pair&lt;&gt;.
6378 </p>
6379
6380 <p><b>Proposed resolution:</b></p>
6381
6382 <p>Adopt the wording proposed in Howard Hinnant's paper
6383   N1523=03-0106, "Proposed Resolution To LWG issues 225, 226, 229".</p>
6384
6385
6386 <p><i>[Tokyo: Summary, "There is no conforming way to extend
6387 std::swap for user defined templates."&nbsp; The LWG agrees that
6388 there is a problem.  Would like more information before
6389 proceeding. This may be a core issue.  Core issue 229 has been opened
6390 to discuss the core aspects of this problem. It was also noted that
6391 submissions regarding this issue have been received from several
6392 sources, but too late to be integrated into the issues list.
6393 ]</i></p>
6394
6395 <p><i>[Post-Tokyo: A paper with several proposed resolutions,
6396 J16/00-0029==WG21/N1252, "Shades of namespace std functions
6397 " by Alan Griffiths, is in the Post-Tokyo mailing. It
6398 should be considered a part of this issue.]</i></p>
6399
6400 <p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
6401 resolution that involves core changes: it would add partial
6402 specialization of function template.  The Core Working Group is
6403 reluctant to add partial specialization of function templates.  It is
6404 viewed as a large change, CWG believes that proposal presented leaves
6405 some syntactic issues unanswered; if the CWG does add partial
6406 specialization of function templates, it wishes to develop its own
6407 proposal.  The LWG continues to believe that there is a serious
6408 problem: there is no good way for users to force the library to use
6409 user specializations of generic standard library functions, and in
6410 certain cases (e.g. transcendental functions called by
6411 <tt>valarray</tt> and <tt>complex</tt>) this is important.  Koenig
6412 lookup isn't adequate, since names within the library must be
6413 qualified with <tt>std</tt> (see issue 225), specialization doesn't
6414 work (we don't have partial specialization of function templates), and
6415 users aren't permitted to add overloads within namespace std.
6416 ]</i></p>
6417
6418 <p><i>[Copenhagen: Discussed at length, with no consensus.  Relevant
6419 papers in the pre-Copenhagen mailing: N1289, N1295, N1296.  Discussion
6420 focused on four options. (1) Relax restrictions on overloads within
6421 namespace std. (2) Mandate that the standard library use unqualified
6422 calls for <tt>swap</tt> and possibly other functions.  (3) Introduce
6423 helper class templates for <tt>swap</tt> and possibly other functions.
6424 (4) Introduce partial specialization of function templates.  Every
6425 option had both support and opposition.  Straw poll (first number is
6426 support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
6427 (4) 4, 4.]</i></p>
6428
6429 <p><i>[Redmond: Discussed, again no consensus.  Herb presented an
6430 argument that a user who is defining a type <tt>T</tt> with an
6431 associated <tt>swap</tt> should not be expected to put that
6432 <tt>swap</tt> in namespace std, either by overloading or by partial
6433 specialization.  The argument is that <tt>swap</tt> is part of
6434 <tt>T</tt>'s interface, and thus should to in the same namespace as
6435 <tt>T</tt> and only in that namespace.  If we accept this argument,
6436 the consequence is that standard library functions should use
6437 unqualified call of <tt>swap</tt>.  (And which other functions? Any?)
6438 A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
6439 try to put together a proposal before the next meeting.]</i></p>
6440
6441 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
6442 225, 226, and 229.  Their conclusion was that the issues should be
6443 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6444 EWG portion (Dave will write a proposal). The LWG and EWG had
6445 (separate) discussions of this plan the next day.  The proposed
6446 resolution is the one proposed by Howard.]</i></p>
6447
6448 <p><i>[Santa Cruz: the LWG agreed with the general direction of
6449   Howard's paper, N1387.  (Roughly: Koenig lookup is disabled unless
6450   we say otherwise; this issue is about when we do say otherwise.)
6451   However, there were concerns about wording.  Howard will provide new
6452   wording.  Bill and Jeremy will review it.]</i></p>
6453
6454 <p><i>[Kona: Howard proposed the new wording.  The LWG accepted his
6455   proposed resolution.]</i></p>
6456
6457 <p><b>Rationale:</b></p>
6458 <p>Informally: introduce a Swappable concept, and specify that the
6459   value types of the iterators passed to certain standard algorithms
6460   (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
6461   to that concept.  The Swappable concept will make it clear that
6462   these algorithms use unqualified lookup for the calls
6463   to <tt>swap</tt>.  Also, in 26.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.transcend"> [lib.valarray.transcend]</a> paragraph 1,
6464   state that the valarray transcendentals use unqualified lookup.</p>
6465 <hr>
6466 <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>
6467 <p>25.2.2 reads:</p>
6468 <blockquote>
6469   <p><tt>  template&lt;class T&gt; void swap(T&amp; a, T&amp; b);</tt><br>
6470   <br>
6471   Requires:    Type T is Assignable (_lib.container.requirements_).<br>
6472   Effects:    Exchanges values stored in two locations.</p>
6473 </blockquote>
6474 <p>The only reasonable** generic implementation of swap requires construction of a
6475    new temporary copy of one of its arguments:</p>
6476 <blockquote>
6477 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
6478   {
6479       T tmp(a);
6480       a = b;
6481       b = tmp;
6482   }</pre>
6483 </blockquote>
6484 <p>But a type which is only Assignable cannot be swapped by this implementation.</p>
6485 <p>**Yes, there's also an unreasonable implementation which would require T to be
6486    DefaultConstructible instead of CopyConstructible. I don't think this is worthy
6487    of consideration:</p>
6488 <blockquote>
6489 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
6490 {
6491     T tmp;
6492     tmp = a;
6493     a = b;
6494     b = tmp;
6495 }</pre>
6496 </blockquote>
6497 <p><b>Proposed resolution:</b></p>
6498 <p>Change 25.2.2 paragraph 1 from:</p>
6499 <blockquote>
6500 <p>  Requires: Type T is Assignable (23.1).</p>
6501 </blockquote>
6502 <p>to:</p>
6503 <blockquote>
6504 <p>  Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
6505 </blockquote>
6506 <hr>
6507 <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>
6508 <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.ctype.byname.special"> [lib.locale.ctype.byname.special]</a>,
6509 22.2.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>, 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
6510 definitions of the "..._byname" classes by listing a bunch
6511 of virtual functions. At the same time, no semantics of these
6512 functions are defined. Real implementations do not define these
6513 functions because the functional part of the facets is actually
6514 implemented in the corresponding base classes and the constructor of
6515 the "..._byname" version just provides suitable date used by
6516 these implementations. For example, the 'numpunct' methods just return
6517 values from a struct. The base class uses a statically initialized
6518 struct while the derived version reads the contents of this struct
6519 from a table.  However, no virtual function is defined in
6520 'numpunct_byname'.</p>
6521
6522 <p>For most classes this does not impose a problem but specifically
6523 for 'ctype' it does: The specialization for 'ctype_byname&lt;char&gt;'
6524 is required because otherwise the semantics would change due to the
6525 virtual functions defined in the general version for 'ctype_byname':
6526 In 'ctype&lt;char&gt;' the method 'do_is()' is not virtual but it is
6527 made virtual in both 'ctype&lt;cT&gt;' and 'ctype_byname&lt;cT&gt;'.
6528 Thus, a class derived from 'ctype_byname&lt;char&gt;' can tell whether
6529 this class is specialized or not under the current specification:
6530 Without the specialization, 'do_is()' is virtual while with
6531 specialization it is not virtual.</p>
6532 <p><b>Proposed resolution:</b></p>
6533 <p>&nbsp; Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
6534 <pre>     namespace std {
6535        template &lt;class charT&gt;
6536        class ctype_byname : public ctype&lt;charT&gt; {
6537        public:
6538          typedef ctype&lt;charT&gt;::mask mask;
6539          explicit ctype_byname(const char*, size_t refs = 0);
6540        protected:
6541         ~ctype_byname();             //  virtual
6542        };
6543      }</pre>
6544 <p>&nbsp; Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
6545 <pre>    namespace std {
6546       template &lt;class internT, class externT, class stateT&gt;
6547       class codecvt_byname : public codecvt&lt;internT, externT, stateT&gt; {
6548       public:
6549        explicit codecvt_byname(const char*, size_t refs = 0);
6550       protected:
6551       ~codecvt_byname();             //  virtual
6552        };
6553      }
6554 </pre>
6555 <p>&nbsp; Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
6556 <pre>     namespace std {
6557        template &lt;class charT&gt;
6558        class numpunct_byname : public numpunct&lt;charT&gt; {
6559      //  this class is specialized for  char  and  wchar_t.
6560        public:
6561          typedef charT                char_type;
6562          typedef basic_string&lt;charT&gt;  string_type;
6563          explicit numpunct_byname(const char*, size_t refs = 0);
6564        protected:
6565         ~numpunct_byname();          //  virtual
6566        };
6567      }</pre>
6568 <p>&nbsp; Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
6569 <pre>     namespace std {
6570        template &lt;class charT&gt;
6571        class collate_byname : public collate&lt;charT&gt; {
6572        public:
6573          typedef basic_string&lt;charT&gt; string_type;
6574          explicit collate_byname(const char*, size_t refs = 0);
6575        protected:
6576         ~collate_byname();           //  virtual
6577        };
6578      }</pre>
6579 <p>&nbsp; Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
6580 <pre>     namespace std {
6581        template &lt;class charT, class InputIterator = istreambuf_iterator&lt;charT&gt; &gt;
6582        class time_get_byname : public time_get&lt;charT, InputIterator&gt; {
6583        public:
6584          typedef time_base::dateorder dateorder;
6585          typedef InputIterator        iter_type</pre>
6586 <pre>         explicit time_get_byname(const char*, size_t refs = 0);
6587        protected:
6588         ~time_get_byname();          //  virtual
6589        };
6590      }</pre>
6591 <p>&nbsp; Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
6592 <pre>     namespace std {
6593        template &lt;class charT, class OutputIterator = ostreambuf_iterator&lt;charT&gt; &gt;
6594        class time_put_byname : public time_put&lt;charT, OutputIterator&gt;
6595        {
6596        public:
6597          typedef charT          char_type;
6598          typedef OutputIterator iter_type;</pre>
6599 <pre>         explicit time_put_byname(const char*, size_t refs = 0);
6600        protected:
6601         ~time_put_byname();          //  virtual
6602        };
6603      }"</pre>
6604 <p>&nbsp; Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
6605 <pre>     namespace std {
6606        template &lt;class charT, bool Intl = false&gt;
6607        class moneypunct_byname : public moneypunct&lt;charT, Intl&gt; {
6608        public:
6609          typedef money_base::pattern pattern;
6610          typedef basic_string&lt;charT&gt; string_type;</pre>
6611 <pre>         explicit moneypunct_byname(const char*, size_t refs = 0);
6612        protected:
6613         ~moneypunct_byname();        //  virtual
6614        };
6615      }</pre>
6616 <p>&nbsp; Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
6617 <pre>     namespace std {
6618        template &lt;class charT&gt;
6619        class messages_byname : public messages&lt;charT&gt; {
6620        public:
6621          typedef messages_base::catalog catalog;
6622          typedef basic_string&lt;charT&gt;    string_type;</pre>
6623 <pre>         explicit messages_byname(const char*, size_t refs = 0);
6624        protected:
6625         ~messages_byname();          //  virtual
6626        };
6627      }</pre>
6628 <p>Remove section 22.2.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a> completely (because in
6629 this case only those members are defined to be virtual which are
6630 defined to be virtual in 'ctype&lt;cT&gt;'.)</p>
6631
6632 <p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of
6633 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>
6634
6635 <p><i>[Copenhagen: proposed resolution was revised slightly, to remove
6636 three last virtual functions from <tt>messages_byname</tt>.]</i></p>
6637
6638 <hr>
6639 <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>
6640 <p>Throughout the library chapters, the descriptions of library entities refer
6641 to other library entities without necessarily qualifying the names.</p>
6642
6643 <p>For example, section 25.2.2 "Swap" describes the effect of
6644 swap_ranges in terms of the unqualified name "swap". This section
6645 could reasonably be interpreted to mean that the library must be implemented so
6646 as to do a lookup of the unqualified name "swap", allowing users to
6647 override any ::std::swap function when Koenig lookup applies.</p>
6648
6649 <p>Although it would have been best to use explicit qualification with
6650 "::std::" throughout, too many lines in the standard would have to be
6651 adjusted to make that change in a Technical Corrigendum.</p>
6652
6653 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, which addresses qualification of
6654 <tt>size_t</tt>, is a special case of this.
6655 </p>
6656 <p><b>Proposed resolution:</b></p>
6657 <p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p>
6658 <blockquote>
6659   <p>Whenever a name x defined in the standard library is mentioned, the name x
6660   is assumed to be fully qualified as ::std::x, unless explicitly described
6661   otherwise. For example, if the Effects section for library function F is
6662   described as calling library function G, the function ::std::G is meant.</p>
6663 </blockquote>
6664
6665 <p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
6666 the LWG to solve a problem in the standard itself similar to the
6667 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
6668 coordinated with the resolution of this issue.]</i></p>
6669
6670 <p><i>[post-Toronto: Howard is undecided about whether it is
6671 appropriate for all standard library function names referred to in
6672 other standard library functions to be explicitly qualified by
6673 <tt>std</tt>: it is common advice that users should define global
6674 functions that operate on their class in the same namespace as the
6675 class, and this requires argument-dependent lookup if those functions
6676 are intended to be called by library code.  Several LWG members are
6677 concerned that valarray appears to require argument-dependent lookup,
6678 but that the wording may not be clear enough to fall under
6679 "unless explicitly described otherwise".]</i></p>
6680
6681 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
6682 225, 226, and 229.  Their conclusion was that the issues should be
6683 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6684 EWG portion (Dave will write a proposal). The LWG and EWG had
6685 (separate) discussions of this plan the next day.  This paper resolves
6686 issues 225 and 226.  In light of that resolution, the proposed
6687 resolution for the current issue makes sense.]</i></p>
6688
6689 <hr>
6690 <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>
6691 <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
6692 Assignable was specified without also specifying
6693 CopyConstructible. The LWG asked that the standard be searched to
6694 determine if the same defect existed elsewhere.</p>
6695
6696 <p>There are a number of places (see proposed resolution below) where
6697 Assignable is specified without also specifying
6698 CopyConstructible. There are also several cases where both are
6699 specified. For example, 26.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p>
6700 <p><b>Proposed resolution:</b></p>
6701 <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:
6702 change "T is Assignable" to "T is CopyConstructible and
6703 Assignable"
6704 </p>
6705
6706 <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
6707 "Key is Assignable" to "Key is
6708 CopyConstructible and Assignable"<br>
6709 </p>
6710
6711 <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:
6712 </p>
6713 <blockquote>
6714 <p> A class or a built-in type X satisfies the requirements of an
6715 output iterator if X is an Assignable type (23.1) and also the
6716 following expressions are valid, as shown in Table 73:
6717 </p>
6718 </blockquote>
6719 <p>to:
6720 </p>
6721 <blockquote>
6722 <p> A class or a built-in type X satisfies the requirements of an
6723 output iterator if X is a CopyConstructible (20.1.3) and Assignable
6724 type (23.1) and also the following expressions are valid, as shown in
6725 Table 73:
6726 </p>
6727 </blockquote>
6728
6729 <p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
6730 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
6731 CopyConstructible is really a requirement and may be
6732 overspecification.]</i></p>
6733
6734 <p><i>[Portions of the resolution for issue 230 have been superceded by
6735 the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.]</i></p>
6736
6737 <p><b>Rationale:</b></p>
6738 <p>The original proposed resolution also included changes to input
6739 iterator, fill, and replace.  The LWG believes that those changes are
6740 not necessary.  The LWG considered some blanket statement, where an
6741 Assignable type was also required to be Copy Constructible, but
6742 decided against this because fill and replace really don't require the
6743 Copy Constructible property.</p>
6744 <hr>
6745 <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>
6746 <p>What is the following program supposed to output?</p>
6747 <pre>#include &lt;iostream&gt;
6748
6749     int
6750     main()
6751     {
6752         std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
6753         std::cout.precision( 0 ) ;
6754         std::cout &lt;&lt; 1.00 &lt;&lt; '\n' ;
6755         return 0 ;
6756     }</pre>
6757 <p>From my C experience, I would expect "1e+00"; this is what
6758 <tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs
6759 "1.000000e+00".</p>
6760
6761 <p>The only indication I can find in the standard is 22.2.2.2.2/11,
6762 where it says "For conversion from a floating-point type, if
6763 (flags &amp; fixed) != 0 or if str.precision() &gt; 0, then
6764 str.precision() is specified in the conversion specification."
6765 This is an obvious error, however, fixed is not a mask for a field,
6766 but a value that a multi-bit field may take -- the results of and'ing
6767 fmtflags with ios::fixed are not defined, at least not if
6768 ios::scientific has been set. G++'s behavior corresponds to what might
6769 happen if you do use (flags &amp; fixed) != 0 with a typical
6770 implementation (floatfield == 3 &lt;&lt; something, fixed == 1
6771 &lt;&lt; something, and scientific == 2 &lt;&lt; something).</p>
6772
6773 <p>Presumably, the intent is either (flags &amp; floatfield) != 0, or
6774 (flags &amp; floatfield) == fixed; the first gives something more or
6775 less like the effect of precision in a printf floating point
6776 conversion. Only more or less, of course. In order to implement printf
6777 formatting correctly, you must know whether the precision was
6778 explicitly set or not. Say by initializing it to -1, instead of 6, and
6779 stating that for floating point conversions, if precision &lt; -1, 6
6780 will be used, for fixed point, if precision &lt; -1, 1 will be used,
6781 etc. Plus, of course, if precision == 0 and flags &amp; floatfield ==
6782 0, 1 should be = used. But it probably isn't necessary to emulate all
6783 of the anomalies of printf:-).</p>
6784 <p><b>Proposed resolution:</b></p>
6785 <p>
6786 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
6787 sentence:
6788 </p>
6789 <blockquote>
6790 For conversion from a floating-point type,
6791 <tt><i>str</i>.precision()</tt> is specified in the conversion
6792 specification.
6793 </blockquote>
6794 <p><b>Rationale:</b></p>
6795 <p>The floatfield determines whether numbers are formatted as if
6796 with %f, %e, or %g.  If the <tt>fixed</tt> bit is set, it's %f,
6797 if <tt>scientific</tt> it's %e, and if both bits are set, or
6798 neither, it's %g.</p>
6799 <p>Turning to the C standard, a precision of 0 is meaningful
6800 for %f and %e.  For %g, precision 0 is taken to be the same as
6801 precision 1.</p>
6802 <p>The proposed resolution has the effect that if neither
6803 <tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
6804 specifying a precision of 0, which will be internally
6805 turned into 1.  There's no need to call it out as a special
6806 case.</p>
6807 <p>The output of the above program will be "1e+00".</p>
6808
6809 <p><i>[Post-Curaçao: Howard provided improved wording covering the case
6810 where precision is 0 and mode is %g.]</i></p>
6811
6812 <hr>
6813 <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>
6814 <p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
6815 specializations of standard templates to those that "depend on a
6816 user-defined name of external linkage."</p>
6817 <p>This term, however, is not adequately defined, making it possible to
6818 construct a specialization that is, I believe, technically legal according to
6819 17.4.3.1/1, but that specializes a standard template for a built-in type such as
6820 'int'.</p>
6821 <p>The following code demonstrates the problem:</p>
6822 <blockquote>
6823   <pre>#include &lt;algorithm&gt;</pre>
6824   <pre>template&lt;class T&gt; struct X
6825 {
6826  typedef T type;
6827 };</pre>
6828   <pre>namespace std
6829 {
6830  template&lt;&gt; void swap(::X&lt;int&gt;::type&amp; i, ::X&lt;int&gt;::type&amp; j);
6831 }</pre>
6832 </blockquote>
6833 <p><b>Proposed resolution:</b></p>
6834 <p>Change "user-defined name" to "user-defined
6835 type".</p>
6836 <p><b>Rationale:</b></p>
6837 <p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
6838 Programming Language</i>.  It disallows the example in the issue,
6839 since the underlying type itself is not user-defined.  The only
6840 possible problem I can see is for non-type templates, but there's no
6841 possible way for a user to come up with a specialization for bitset,
6842 for example, that might not have already been specialized by the
6843 implementor?</p>
6844
6845 <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>
6846
6847 <p><i>[post-Toronto: Judy provided the above proposed resolution and
6848 rationale.]</i></p>
6849 <hr>
6850 <a name="234"><h3>234.&nbsp;Typos in allocator definition</h3></a><p><b>Section:</b>&nbsp;20.4.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>
6851 <p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
6852 <tt>destruct()</tt> are described as returns but the functions actually
6853 return <tt>void</tt>.</p>
6854 <p><b>Proposed resolution:</b></p>
6855 <p>Substitute "Returns" by "Effect".</p>
6856 <hr>
6857 <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>
6858 <p>The declaration of <tt>reverse_iterator</tt> lists a default
6859 constructor.  However, no specification is given what this constructor
6860 should do.</p>
6861 <p><b>Proposed resolution:</b></p>
6862   <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
6863   paragraph:</p>
6864       <blockquote>
6865       <p><tt>reverse_iterator()</tt></p>
6866
6867       <p>Default initializes <tt>current</tt>. Iterator operations
6868       applied to the resulting iterator have defined behavior if and
6869       only if the corresponding operations are defined on a default
6870       constructed iterator of type <tt>Iterator</tt>.</p>
6871       </blockquote>
6872   <p><i>[pre-Copenhagen: Dietmar provide wording for proposed
6873   resolution.]</i></p>
6874 <hr>
6875 <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.list.cons"> [lib.list.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>
6876 <p>The complexity specification in paragraph 6 says that the complexity
6877 is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
6878 defined on iterators this term is in general undefined because it
6879 would have to be <tt>last - first</tt>.</p>
6880 <p><b>Proposed resolution:</b></p>
6881   <p>Change paragraph 6 from</p>
6882      <blockquote>Linear in <i>first - last</i>.</blockquote>
6883   <p>to become</p>
6884      <blockquote>Linear in <i>distance(first, last)</i>.</blockquote>
6885 <hr>
6886 <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>
6887 <p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
6888 'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
6889 that far but consider this code:</p>
6890
6891 <pre>  std::basic_stringbuf&lt;char&gt; sbuf("hello, world", std::ios_base::openmode(0));
6892   std::cout &lt;&lt; "'" &lt;&lt; sbuf.str() &lt;&lt; "'\n";
6893 </pre>
6894
6895 <p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
6896 the output sequence nor the input sequence is initialized and
6897 paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
6898 returns the input or the output sequence. None of them is initialized,
6899 ie. both are empty, in which case the return from <tt>str()</tt> is
6900 defined to be <tt>basic_string&lt;cT&gt;()</tt>.</p>
6901
6902 <p>However, probably only test cases in some testsuites will detect this
6903 "problem"...</p>
6904 <p><b>Proposed resolution:</b></p>
6905 <p>Remove 27.7.1.1 paragraph 4.</p>
6906 <p><b>Rationale:</b></p>
6907 <p>We could fix 27.7.1.1 paragraph 4, but there would be no point.  If
6908 we fixed it, it would say just the same thing as text that's already
6909 in the standard.</p>
6910 <hr>
6911 <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>
6912 <p>The complexity of unique and unique_copy are inconsistent with each
6913 other and inconsistent with the implementations.&nbsp; The standard
6914 specifies:</p>
6915
6916 <p>for unique():</p>
6917
6918 <blockquote>-3- Complexity: If the range (last - first) is not empty, exactly
6919 (last - first) - 1 applications of the corresponding predicate, otherwise
6920 no applications of the predicate.</blockquote>
6921
6922 <p>for unique_copy():</p>
6923
6924 <blockquote>-7- Complexity: Exactly last - first applications of the corresponding
6925 predicate.</blockquote>
6926
6927 <p>
6928 The implementations do it the other way round: unique() applies the
6929 predicate last-first times and unique_copy() applies it last-first-1
6930 times.</p>
6931
6932 <p>As both algorithms use the predicate for pair-wise comparison of
6933 sequence elements I don't see a justification for unique_copy()
6934 applying the predicate last-first times, especially since it is not
6935 specified to which pair in the sequence the predicate is applied
6936 twice.</p>
6937 <p><b>Proposed resolution:</b></p>
6938 <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>
6939
6940 <blockquote>Complexity: For nonempty ranges, exactly last - first - 1
6941 applications of the corresponding predicate.</blockquote>
6942
6943 <hr>
6944 <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>
6945 <p>The complexity section of adjacent_find is defective:</p>
6946
6947 <blockquote>
6948 <pre>template &lt;class ForwardIterator&gt;
6949 ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
6950                               BinaryPredicate pred);
6951 </pre>
6952
6953 <p>-1- Returns: The first iterator i such that both i and i + 1 are in
6954 the range [first, last) for which the following corresponding
6955 conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
6956 last if no such iterator is found.</p>
6957
6958 <p>-2- Complexity: Exactly find(first, last, value) - first applications
6959 of the corresponding predicate.
6960 </p>
6961 </blockquote>
6962
6963 <p>In the Complexity section, it is not defined what "value"
6964 is supposed to mean. My best guess is that "value" means an
6965 object for which one of the conditions pred(*i,value) or
6966 pred(value,*i) is true, where i is the iterator defined in the Returns
6967 section. However, the value type of the input sequence need not be
6968 equality-comparable and for this reason the term find(first, last,
6969 value) - first is meaningless.</p>
6970
6971 <p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
6972 find_if(first, last, bind1st(pred,*i)) - first might come closer to
6973 the intended specification.  Binders can only be applied to function
6974 objects that have the function call operator declared const, which is
6975 not required of predicates because they can have non-const data
6976 members. For this reason, a specification using a binder could only be
6977 an "as-if" specification.</p>
6978 <p><b>Proposed resolution:</b></p>
6979 <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>
6980 <blockquote>
6981 For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
6982 (<i>last</i> - <i>first</i>) - 1)</tt> applications of the
6983 corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
6984 return value.
6985 </blockquote>
6986
6987 <p><i>[Copenhagen: the original resolution specified an upper
6988 bound.  The LWG preferred an exact count.]</i></p>
6989
6990 <hr>
6991 <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>
6992
6993 <p>Some popular implementations of unique_copy() create temporary
6994 copies of values in the input sequence, at least if the input iterator
6995 is a pointer.  Such an implementation is built on the assumption that
6996 the value type is CopyConstructible and Assignable.</p>
6997
6998 <p>It is common practice in the standard that algorithms explicitly
6999 specify any additional requirements that they impose on any of the
7000 types used by the algorithm. An example of an algorithm that creates
7001 temporary copies and correctly specifies the additional requirements
7002 is accumulate(), 26.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p>
7003
7004 <p>Since the specifications of unique() and unique_copy() do not
7005 require CopyConstructible and Assignable of the InputIterator's value
7006 type the above mentioned implementations are not standard-compliant. I
7007 cannot judge whether this is a defect in the standard or a defect in
7008 the implementations.</p>
7009 <p><b>Proposed resolution:</b></p>
7010 <p>In 25.2.8 change:</p>
7011
7012 <blockquote>
7013 -4- Requires: The ranges [first, last) and [result, result+(last-first))
7014 shall not overlap.
7015 </blockquote>
7016
7017 <p>to:</p>
7018
7019 <blockquote>
7020   <p>-4- Requires: The ranges [first, last) and [result,
7021   result+(last-first)) shall not overlap. The expression *result =
7022   *first must be valid. If neither InputIterator nor OutputIterator
7023   meets the requirements of forward iterator then the value type of
7024   InputIterator must be copy constructible. Otherwise copy
7025   constructible is not required. </p>
7026 </blockquote>
7027
7028 <p><i>[Redmond: the original proposed resolution didn't impose an
7029 explicit requirement that the iterator's value type must be copy
7030 constructible, on the grounds that an input iterator's value type must
7031 always be copy constructible.  Not everyone in the LWG thought that
7032 this requirement was clear from table 72.  It has been suggested that
7033 it might be possible to implement <tt>unique_copy</tt> without
7034 requiring assignability, although current implementations do impose
7035 that requirement.  Howard provided new wording.]</i></p>
7036
7037 <p><i>[
7038 Curaçao: The LWG changed the PR editorially to specify
7039 "neither...nor...meet..." as clearer than
7040 "both...and...do not meet...". Change believed to be so
7041 minor as not to require re-review.
7042 ]</i></p>
7043
7044 <hr>
7045 <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.numeric.ops"> [lib.numeric.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;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
7046 <p>The algorithms transform(), accumulate(), inner_product(),
7047 partial_sum(), and adjacent_difference() require that the function
7048 object supplied to them shall not have any side effects.</p>
7049
7050 <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>
7051 <blockquote>-7- Accessing an object designated by a volatile lvalue (basic.lval),
7052 modifying an object, calling a library I/O function, or calling a function
7053 that does any of those operations are all side effects, which are changes
7054 in the state of the execution environment.</blockquote>
7055
7056 <p>As a consequence, the function call operator of a function object supplied
7057 to any of the algorithms listed above cannot modify data members, cannot
7058 invoke any function that has a side effect, and cannot even create and
7059 modify temporary objects.&nbsp; It is difficult to imagine a function object
7060 that is still useful under these severe limitations. For instance, any
7061 non-trivial transformator supplied to transform() might involve creation
7062 and modification of temporaries, which is prohibited according to the current
7063 wording of the standard.</p>
7064
7065 <p>On the other hand, popular implementations of these algorithms exhibit
7066 uniform and predictable behavior when invoked with a side-effect-producing
7067 function objects. It looks like the strong requirement is not needed for
7068 efficient implementation of these algorithms.</p>
7069
7070 <p>The requirement of&nbsp; side-effect-free function objects could be
7071 replaced by a more relaxed basic requirement (which would hold for all
7072 function objects supplied to any algorithm in the standard library):</p>
7073 <blockquote>A function objects supplied to an algorithm shall not invalidate
7074 any iterator or sequence that is used by the algorithm. Invalidation of
7075 the sequence includes destruction of the sorting order if the algorithm
7076 relies on the sorting order (see section 25.3 - Sorting and related operations
7077 [lib.alg.sorting]).</blockquote>
7078
7079 <p>I can't judge whether it is intended that the function objects supplied
7080 to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
7081 shall not modify sequence elements through dereferenced iterators.</p>
7082
7083 <p>It is debatable whether this issue is a defect or a change request.
7084 Since the consequences for user-supplied function objects are drastic and
7085 limit the usefulness of the algorithms significantly I would consider it
7086 a defect.</p>
7087 <p><b>Proposed resolution:</b></p>
7088
7089 <p><i>Things to notice about these changes:</i></p>
7090
7091 <ol>
7092 <li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
7093      are intentional. we want to prevent side-effects from
7094      invalidating the end iterators.</i>
7095 </li>
7096
7097 <li> <i>That has the unintentional side-effect of prohibiting
7098      modification of the end element as a side-effect. This could
7099      conceivably be significant in some cases.</i>
7100 </li>
7101
7102 <li> <i>The wording also prevents side-effects from modifying elements
7103      of the output sequence. I can't imagine why anyone would want
7104      to do this, but it is arguably a restriction that implementors
7105      don't need to place on users.</i>
7106 </li>
7107
7108 <li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
7109      and simple, but would require more verbiage.</i>
7110 </li>
7111 </ol>
7112
7113 <p>Change 25.2.3/2 from:</p>
7114
7115 <blockquote>
7116    -2- Requires: op and binary_op shall not have any side effects.
7117 </blockquote>
7118
7119 <p>to:</p>
7120
7121 <blockquote>
7122   -2- Requires: in the ranges [first1, last1], [first2, first2 +
7123   (last1 - first1)] and [result, result + (last1- first1)], op and
7124   binary_op shall neither modify elements nor invalidate iterators or
7125   subranges.
7126   [Footnote: The use of fully closed ranges is intentional --end footnote]
7127 </blockquote>
7128
7129
7130 <p>Change 25.2.3/2 from:</p>
7131
7132 <blockquote>
7133    -2- Requires: op and binary_op shall not have any side effects.
7134 </blockquote>
7135
7136 <p>to:</p>
7137
7138 <blockquote>
7139   -2- Requires: op and binary_op shall not invalidate iterators or
7140    subranges, or modify elements in the ranges [first1, last1],
7141    [first2, first2 + (last1 - first1)], and [result, result + (last1
7142    - first1)].
7143   [Footnote: The use of fully closed ranges is intentional --end footnote]
7144 </blockquote>
7145
7146
7147 <p>Change 26.4.1/2 from:</p>
7148
7149 <blockquote>
7150   -2- Requires: T must meet the requirements of CopyConstructible
7151    (lib.copyconstructible) and Assignable (lib.container.requirements)
7152    types. binary_op shall not cause side effects.
7153 </blockquote>
7154
7155 <p>to:</p>
7156
7157 <blockquote>
7158   -2- Requires: T must meet the requirements of CopyConstructible
7159    (lib.copyconstructible) and Assignable
7160    (lib.container.requirements) types. In the range [first, last],
7161    binary_op shall neither modify elements nor invalidate iterators
7162    or subranges.
7163   [Footnote: The use of a fully closed range is intentional --end footnote]
7164 </blockquote>
7165
7166 <p>Change 26.4.2/2 from:</p>
7167
7168 <blockquote>
7169   -2- Requires: T must meet the requirements of CopyConstructible
7170    (lib.copyconstructible) and Assignable (lib.container.requirements)
7171    types. binary_op1 and binary_op2 shall not cause side effects.
7172 </blockquote>
7173
7174 <p>to:</p>
7175
7176 <blockquote>
7177   -2- Requires: T must meet the requirements of CopyConstructible
7178    (lib.copyconstructible) and Assignable (lib.container.requirements)
7179    types. In the ranges [first, last] and [first2, first2 + (last -
7180    first)], binary_op1 and binary_op2 shall neither modify elements
7181    nor invalidate iterators or subranges.
7182   [Footnote: The use of fully closed ranges is intentional --end footnote]
7183 </blockquote>
7184
7185
7186 <p>Change 26.4.3/4 from:</p>
7187
7188 <blockquote>
7189   -4- Requires: binary_op is expected not to have any side effects.
7190 </blockquote>
7191
7192 <p>to:</p>
7193
7194 <blockquote>
7195   -4- Requires: In the ranges [first, last] and [result, result +
7196    (last - first)], binary_op shall neither modify elements nor
7197    invalidate iterators or subranges.
7198   [Footnote: The use of fully closed ranges is intentional --end footnote]
7199 </blockquote>
7200
7201 <p>Change 26.4.4/2 from:</p>
7202
7203 <blockquote>
7204   -2- Requires: binary_op shall not have any side effects.
7205 </blockquote>
7206
7207 <p>to:</p>
7208
7209 <blockquote>
7210   -2- Requires: In the ranges [first, last] and [result, result +
7211    (last - first)], binary_op shall neither modify elements nor
7212    invalidate iterators or subranges.
7213   [Footnote: The use of fully closed ranges is intentional --end footnote]
7214 </blockquote>
7215
7216 <p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
7217
7218 <p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
7219 added footnotes pointing out that the use of closed ranges was
7220 intentional.]</i></p>
7221
7222 <hr>
7223 <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>
7224 <p>basic_istream&lt;&gt;::get(), and basic_istream&lt;&gt;::getline(),
7225 are unclear with respect to the behavior and side-effects of the named
7226 functions in case of an error.</p>
7227
7228 <p>27.6.1.3, p1 states that "... If the sentry object returns
7229 true, when converted to a value of type bool, the function endeavors
7230 to obtain the requested input..." It is not clear from this (or
7231 the rest of the paragraph) what precisely the behavior should be when
7232 the sentry ctor exits by throwing an exception or when the sentry
7233 object returns false.  In particular, what is the number of characters
7234 extracted that gcount() returns supposed to be?</p>
7235
7236 <p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
7237 "...  In any case, it then stores a null character (using
7238 charT()) into the next successive location of the array." Is not
7239 clear whether this sentence applies if either of the conditions above
7240 holds (i.e., when sentry fails).</p>
7241 <p><b>Proposed resolution:</b></p>
7242 <p>Add to 27.6.1.3, p1 after the sentence</p>
7243
7244 <blockquote>
7245 "... If the sentry object returns true, when converted to a value of
7246 type bool, the function endeavors to obtain the requested input."
7247 </blockquote>
7248
7249 <p>the following</p>
7250
7251
7252 <blockquote>
7253 "Otherwise, if the sentry constructor exits by throwing an exception or
7254 if the sentry object returns false, when converted to a value of type
7255 bool, the function returns without attempting to obtain any input. In
7256 either case the number of extracted characters is set to 0; unformatted
7257 input functions taking a character array of non-zero size as an argument
7258 shall also store a null character (using charT()) in the first location
7259 of the array."
7260 </blockquote>
7261 <p><b>Rationale:</b></p>
7262 <p>Although the general philosophy of the input functions is that the
7263 argument should not be modified upon failure, <tt>getline</tt>
7264 historically added a terminating null unconditionally.  Most
7265 implementations still do that.  Earlier versions of the draft standard
7266 had language that made this an unambiguous requirement; those words
7267 were moved to a place where their context made them less clear.  See
7268 Jerry Schwarz's message c++std-lib-7618.</p>
7269 <hr>
7270 <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>
7271 <p>There is no requirement that any of time_get member functions set
7272 ios::eofbit when they reach the end iterator while parsing their input.
7273 Since members of both the num_get and money_get facets are required to
7274 do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
7275 should follow the same requirement for consistency.</p>
7276 <p><b>Proposed resolution:</b></p>
7277 <p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
7278
7279 <blockquote>
7280 If the end iterator is reached during parsing by any of the get()
7281 member functions, the member sets ios_base::eofbit in err.
7282 </blockquote>
7283 <p><b>Rationale:</b></p>
7284 <p>Two alternative resolutions were proposed.  The LWG chose this one
7285 because it was more consistent with the way eof is described for other
7286 input facets.</p>
7287 <hr>
7288 <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.list.ops"> [lib.list.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;Brian Parker &nbsp; <b>Date:</b>&nbsp;14 Jul 2000</p>
7289 <p>
7290 Section 23.2.2.4 [lib.list.ops] states that
7291 </p>
7292 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
7293 </pre>
7294 <p>
7295 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
7296 </p>
7297
7298 <p>
7299 This is unnecessary and defeats an important feature of splice. In
7300 fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
7301 after <tt>splice</tt>.
7302 </p>
7303 <p><b>Proposed resolution:</b></p>
7304
7305 <p>Add a footnote to 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, paragraph 1:</p>
7306 <blockquote>
7307 [<i>Footnote:</i> As specified in 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, paragraphs
7308 4-5, the semantics described in this clause applies only to the case
7309 where allocators compare equal.  --end footnote]
7310 </blockquote>
7311
7312 <p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 4 with:</p>
7313 <blockquote>
7314 Effects: Inserts the contents of x before position and x becomes
7315 empty.  Pointers and references to the moved elements of x now refer to
7316 those same elements but as members of *this.  Iterators referring to the
7317 moved elements will continue to refer to their elements, but they now
7318 behave as iterators into *this, not into x.
7319 </blockquote>
7320
7321 <p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 7 with:</p>
7322 <blockquote>
7323 Effects: Inserts an element pointed to by i from list x before
7324 position and removes the element from x. The result is unchanged if
7325 position == i or position == ++i.  Pointers and references to *i continue
7326 to refer to this same element but as a member of *this.  Iterators to *i
7327 (including i itself) continue to refer to the same element, but now
7328 behave as iterators into *this, not into x.
7329 </blockquote>
7330
7331 <p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 12 with:</p>
7332 <blockquote>
7333 Requires: [first, last) is a valid range in x. The result is
7334 undefined if position is an iterator in the range [first, last).
7335 Pointers and references to the moved elements of x now refer to those
7336 same elements but as members of *this.  Iterators referring to the moved
7337 elements will continue to refer to their elements, but they now behave as
7338 iterators into *this, not into x.
7339 </blockquote>
7340
7341 <p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
7342 <p><b>Rationale:</b></p>
7343 <p>The original proposed resolution said that iterators and references
7344 would remain "valid".  The new proposed resolution clarifies what that
7345 means.  Note that this only applies to the case of equal allocators.
7346 From 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> paragraph 4, the behavior of list when
7347 allocators compare nonequal is outside the scope of the standard.</p>
7348 <hr>
7349 <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>
7350 <p>The synopsis for the template class <tt>basic_stringbuf</tt>
7351 doesn't list a typedef for the template parameter
7352 <tt>Allocator</tt>. This makes it impossible to determine the type of
7353 the allocator at compile time. It's also inconsistent with all other
7354 template classes in the library that do provide a typedef for the
7355 <tt>Allocator</tt> parameter.</p>
7356 <p><b>Proposed resolution:</b></p>
7357 <p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
7358 basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and
7359 basic_stringstream (27.7.4) the typedef:</p>
7360 <pre>  typedef Allocator allocator_type;
7361 </pre>
7362 <hr>
7363 <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>
7364 <p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
7365 const_cast&lt;&gt; in the Returns clause for basic_istringstream&lt;&gt;::rdbuf().
7366 The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
7367 D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
7368 the cast altogether.</p>
7369
7370 <p>C-style casts have not been deprecated, so the first part of this
7371 issue is stylistic rather than a matter of correctness.</p>
7372 <p><b>Proposed resolution:</b></p>
7373 <p>In 27.7.2.2, p1 replace </p>
7374 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
7375
7376 <p>with</p>
7377 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
7378
7379
7380 <p>In 27.7.3.2, p1 replace</p>
7381 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
7382
7383 <p>with</p>
7384 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
7385
7386 <p>In 27.7.6, p1, replace</p>
7387 <pre>  -1- Returns: &amp;sb</pre>
7388
7389 <p>with</p>
7390 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
7391
7392 <p>In D.7.2.2, p1 replace</p>
7393 <pre>  -2- Returns: &amp;sb. </pre>
7394
7395 <p>with</p>
7396 <pre>  -2- Returns: const_cast&lt;strstreambuf*&gt;(&amp;sb).</pre>
7397 <hr>
7398 <a name="253"><h3>253.&nbsp;valarray helper functions are almost entirely useless</h3></a><p><b>Section:</b>&nbsp;26.3.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.cons"> [lib.valarray.cons]</a>, 26.3.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>
7399 <p>This discussion is adapted from message c++std-lib-7056 posted
7400 November 11, 1999.  I don't think that anyone can reasonably claim
7401 that the problem described below is NAD.</p>
7402
7403 <p>These valarray constructors can never be called:</p>
7404
7405 <pre>   template &lt;class T&gt;
7406          valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
7407    template &lt;class T&gt;
7408          valarray&lt;T&gt;::valarray(const gslice_array&lt;T&gt; &amp;);
7409    template &lt;class T&gt;
7410          valarray&lt;T&gt;::valarray(const mask_array&lt;T&gt; &amp;);
7411    template &lt;class T&gt;
7412          valarray&lt;T&gt;::valarray(const indirect_array&lt;T&gt; &amp;);
7413 </pre>
7414
7415 <p>Similarly, these valarray assignment operators cannot be
7416 called:</p>
7417
7418 <pre>     template &lt;class T&gt;
7419      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const slice_array&lt;T&gt; &amp;);
7420      template &lt;class T&gt;
7421      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const gslice_array&lt;T&gt; &amp;);
7422      template &lt;class T&gt;
7423      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const mask_array&lt;T&gt; &amp;);
7424      template &lt;class T&gt;
7425      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const indirect_array&lt;T&gt; &amp;);
7426 </pre>
7427
7428 <p>Please consider the following example:</p>
7429
7430 <pre>   #include &lt;valarray&gt;
7431    using namespace std;
7432
7433    int main()
7434    {
7435        valarray&lt;double&gt; va1(12);
7436        valarray&lt;double&gt; va2(va1[slice(1,4,3)]); // line 1
7437    }
7438 </pre>
7439
7440
7441 <p>Since the valarray va1 is non-const, the result of the sub-expression
7442 va1[slice(1,4,3)] at line 1 is an rvalue of type const
7443 std::slice_array&lt;double&gt;.  This slice_array rvalue is then used to
7444 construct va2.  The constructor that is used to construct va2 is
7445 declared like this:</p>
7446
7447 <pre>     template &lt;class T&gt;
7448      valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
7449 </pre>
7450
7451 <p>Notice the constructor's const reference parameter.  When the
7452 constructor is called, a slice_array must be bound to this reference.
7453 The rules for binding an rvalue to a const reference are in 8.5.3,
7454 paragraph 5 (see also 13.3.3.1.4).  Specifically, paragraph 5
7455 indicates that a second slice_array rvalue is constructed (in this
7456 case copy-constructed) from the first one; it is this second rvalue
7457 that is bound to the reference parameter.  Paragraph 5 also requires
7458 that the constructor that is used for this purpose be callable,
7459 regardless of whether the second rvalue is elided.  The
7460 copy-constructor in this case is not callable, however, because it is
7461 private.  Therefore, the compiler should report an error.</p>
7462
7463 <p>Since slice_arrays are always rvalues, the valarray constructor that has a
7464 parameter of type const slice_array&lt;T&gt; &amp; can never be called.  The
7465 same reasoning applies to the three other constructors and the four
7466 assignment operators that are listed at the beginning of this post.
7467 Furthermore, since these functions cannot be called, the valarray helper
7468 classes are almost entirely useless.</p>
7469 <p><b>Proposed resolution:</b></p>
7470 <p>slice_array:</p>
7471 <ul>
7472 <li> Make the copy constructor and copy-assignment operator declarations
7473      public in the slice_array class template definition in 26.3.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>
7474 <li> remove paragraph 3 of 26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>
7475 </li>
7476 <li> remove the copy constructor declaration from 26.3.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>
7477 </li>
7478 <li> change paragraph 1 of 26.3.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
7479     to be private.  This constructor need not be defined."</li>
7480 <li> remove the first sentence of paragraph 1 of 26.3.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>
7481 </li>
7482 <li> Change the first three words of the second sentence of paragraph 1 of
7483     26.3.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>
7484 </ul>
7485
7486 <p>gslice_array:</p>
7487 <ul>
7488 <li> Make the copy constructor and copy-assignment operator declarations
7489     public in the gslice_array class template definition in 26.3.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>
7490 <li> remove the note in paragraph 3 of 26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a>
7491 </li>
7492 <li> remove the copy constructor declaration from 26.3.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>
7493 </li>
7494 <li> change paragraph 1 of 26.3.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
7495     to be private.  This constructor need not be defined."</li>
7496 <li> remove the first sentence of paragraph 1 of 26.3.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>
7497 </li>
7498 <li> Change the first three words of the second sentence of paragraph 1 of
7499     26.3.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>
7500 </ul>
7501
7502 <p>mask_array:</p>
7503 <ul>
7504 <li> Make the copy constructor and copy-assignment operator declarations
7505     public in the mask_array class template definition in 26.3.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>
7506 <li> remove the note in paragraph 2 of 26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a>
7507 </li>
7508 <li> remove the copy constructor declaration from 26.3.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>
7509 </li>
7510 <li> change paragraph 1 of 26.3.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
7511     to be private.  This constructor need not be defined."</li>
7512 <li> remove the first sentence of paragraph 1 of 26.3.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>
7513 </li>
7514 <li> Change the first three words of the second sentence of paragraph 1 of
7515     26.3.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>
7516 </ul>
7517
7518 <p>indirect_array:</p>
7519 <ul>
7520 <li>Make the copy constructor and copy-assignment operator declarations
7521     public in the indirect_array class definition in 26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
7522 </li>
7523 <li> remove the note in paragraph 2 of 26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
7524 </li>
7525 <li> remove the copy constructor declaration from 26.3.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>
7526 </li>
7527 <li> change the descriptive text in 26.3.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
7528     declared to be private.  This constructor need not be defined."</li>
7529 <li> remove the first sentence of paragraph 1 of 26.3.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>
7530 </li>
7531 <li> Change the first three words of the second sentence of paragraph 1 of
7532     26.3.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>
7533 </ul>
7534 <p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
7535 copy constructor and copy assignment operators public, instead of
7536 removing them.]</i></p>
7537 <p><b>Rationale:</b></p>
7538 <p>Keeping the valarray constructors private is untenable.  Merely
7539 making valarray a friend of the helper classes isn't good enough,
7540 because access to the copy constructor is checked in the user's
7541 environment.</p>
7542
7543 <p>Making the assignment operator public is not strictly necessary to
7544 solve this problem.  A majority of the LWG <i>(straw poll: 13-4)</i>
7545 believed we should make the assignment operators public, in addition
7546 to the copy constructors, for reasons of symmetry and user
7547 expectation.</p>
7548 <hr>
7549 <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>
7550 <p>
7551 27.4.4.2, p17 says
7552 </p>
7553
7554 <blockquote>
7555 -17- Before copying any parts of rhs, calls each registered callback
7556 pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
7557 exceptions() have been replaced, calls each callback pair that was
7558 copied from rhs as (*fn)(copy_event,*this,index).
7559 </blockquote>
7560
7561 <p>
7562 The name copy_event isn't defined anywhere. The intended name was
7563 copyfmt_event.
7564 </p>
7565 <p><b>Proposed resolution:</b></p>
7566 <p>Replace copy_event with copyfmt_event in the named paragraph.</p>
7567 <hr>
7568 <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>
7569 <p>
7570 <i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
7571 </p>
7572
7573 <p>
7574 The standard's description of <tt>basic_string&lt;&gt;::operator[]</tt>
7575 seems to violate const correctness.
7576 </p>
7577
7578 <p>
7579 The standard (21.3.4/1) says that "If <tt>pos &lt; size()</tt>,
7580 returns <tt>data()[pos]</tt>." The types don't work.  The
7581 return value of <tt>data()</tt> is <tt>const charT*</tt>, but
7582 <tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
7583 </p>
7584 <p><b>Proposed resolution:</b></p>
7585 <p>
7586 In section 21.3.4, paragraph 1, change
7587 "<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
7588 <i>pos</i>)</tt>".
7589 </p>
7590 <hr>
7591 <a name="260"><h3>260.&nbsp;Inconsistent return type of <tt>istream_iterator::operator++(int)</tt>
7592 </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>
7593 <p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
7594 it as returning the iterator by value. 24.5.1.2, p5 shows the same
7595 operator as returning the iterator by reference. That's incorrect
7596 given the Effects clause below (since a temporary is returned). The
7597 `&amp;' is probably just a typo.</p>
7598 <p><b>Proposed resolution:</b></p>
7599 <p>Change the declaration in 24.5.1.2, p5 from</p>
7600  <pre> istream_iterator&lt;T,charT,traits,Distance&gt;&amp; operator++(int);
7601  </pre>
7602 <p>to</p>
7603  <pre> istream_iterator&lt;T,charT,traits,Distance&gt; operator++(int);
7604  </pre>
7605 <p>(that is, remove the `&amp;').</p>
7606 <hr>
7607 <a name="261"><h3>261.&nbsp;Missing description of <tt>istream_iterator::operator!=</tt>
7608 </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>
7609 <p>
7610 24.5.1, p3 lists the synopsis for
7611 </p>
7612
7613 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
7614         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
7615                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
7616 </pre>
7617
7618 <p>
7619 but there is no description of what the operator does (i.e., no Effects
7620 or Returns clause) in 24.5.1.2.
7621 </p>
7622 <p><b>Proposed resolution:</b></p>
7623 <p>
7624 Add paragraph 7 to the end of section 24.5.1.2 with the following text:
7625 </p>
7626
7627 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
7628         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
7629                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
7630 </pre>
7631
7632 <p>-7- Returns: !(x == y).</p>
7633 <hr>
7634 <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>
7635 <p>
7636 The ~ operation should be applied after the cast to int_type.
7637 </p>
7638 <p><b>Proposed resolution:</b></p>
7639 <p>
7640 Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
7641 </p>
7642
7643 <pre>   bitmask operator~ ( bitmask X )
7644      { return static_cast&lt; bitmask&gt;(static_cast&lt;int_type&gt;(~ X)); }
7645 </pre>
7646
7647 <p>
7648 to:
7649 </p>
7650
7651 <pre>   bitmask operator~ ( bitmask X )
7652      { return static_cast&lt; bitmask&gt;(~static_cast&lt;int_type&gt;(X)); }
7653 </pre>
7654 <hr>
7655 <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>
7656 <p>
7657 The note in paragraph 6 suggests that the invalidation rules for
7658 references, pointers, and iterators in paragraph 5 permit a reference-
7659 counted implementation (actually, according to paragraph 6, they permit
7660 a "reference counted implementation", but this is a minor editorial fix).
7661 </p>
7662
7663 <p>
7664 However, the last sub-bullet is so worded as to make a reference-counted
7665 implementation unviable. In the following example none of the
7666 conditions for iterator invalidation are satisfied:
7667 </p>
7668
7669 <pre>    // first example: "*******************" should be printed twice
7670     string original = "some arbitrary text", copy = original;
7671     const string &amp; alias = original;
7672
7673     string::const_iterator i = alias.begin(), e = alias.end();
7674     for(string::iterator j = original.begin(); j != original.end(); ++j)
7675         *j = '*';
7676     while(i != e)
7677         cout &lt;&lt; *i++;
7678     cout &lt;&lt; endl;
7679     cout &lt;&lt; original &lt;&lt; endl;
7680 </pre>
7681
7682 <p>
7683 Similarly, in the following example:
7684 </p>
7685
7686 <pre>    // second example: "some arbitrary text" should be printed out
7687     string original = "some arbitrary text", copy = original;
7688     const string &amp; alias = original;
7689
7690     string::const_iterator i = alias.begin();
7691     original.begin();
7692     while(i != alias.end())
7693         cout &lt;&lt; *i++;
7694 </pre>
7695
7696 <p>
7697 I have tested this on three string implementations, two of which were
7698 reference counted. The reference-counted implementations gave
7699 "surprising behavior" because they invalidated iterators on
7700 the first call to non-const begin since construction. The current
7701 wording does not permit such invalidation because it does not take
7702 into account the first call since construction, only the first call
7703 since various member and non-member function calls.
7704 </p>
7705 <p><b>Proposed resolution:</b></p>
7706 <p>
7707 Change the following sentence in 21.3 paragraph 5 from
7708 </p>
7709
7710 <blockquote>
7711     Subsequent to any of the above uses except the forms of insert() and
7712     erase() which return iterators, the first call to non-const member
7713     functions operator[](), at(), begin(), rbegin(), end(), or rend().
7714 </blockquote>
7715
7716 <p>to</p>
7717
7718 <blockquote>
7719     Following construction or any of the above uses, except the forms of
7720     insert() and erase() that return iterators, the first call to non-
7721     const member functions operator[](), at(), begin(), rbegin(), end(),
7722     or rend().
7723 </blockquote>
7724 <hr>
7725 <a name="264"><h3>264.&nbsp;Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;John Potter&nbsp; <b>Date:</b>&nbsp;07 Sep 2000</p>
7726 <p>
7727 Table 69 requires linear time if [i, j) is sorted.  Sorted is necessary but not sufficient.
7728 Consider inserting a sorted range of even integers into a set&lt;int&gt; containing the odd
7729 integers in the same range.
7730 </p>
7731
7732 <p><i>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></i></p>
7733 <p><b>Proposed resolution:</b></p>
7734 <p>
7735 In Table 69, in section 23.1.2, change the complexity clause for
7736 insertion of a range from "N log(size() + N) (N is the distance
7737 from i to j) in general; linear if [i, j) is sorted according to
7738 value_comp()" to "N log(size() + N), where N is the distance
7739 from i to j".
7740 </p>
7741
7742 <p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
7743 parens in the revised wording.]</i></p>
7744
7745 <p><b>Rationale:</b></p>
7746 <p>
7747 Testing for valid insertions could be less efficient than simply
7748 inserting the elements when the range is not both sorted and between
7749 two adjacent existing elements; this could be a QOI issue.
7750 </p>
7751
7752 <p>
7753 The LWG considered two other options: (a) specifying that the
7754 complexity was linear if [i, j) is sorted according to value_comp()
7755 and between two adjacent existing elements; or (b) changing to
7756 Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
7757 number of elements which do not insert immediately after the previous
7758 element from [i, j) including the first).  The LWG felt that, since
7759 we can't guarantee linear time complexity whenever the range to be
7760 inserted is sorted, it's more trouble than it's worth to say that it's
7761 linear in some special cases.
7762 </p>
7763 <hr>
7764 <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>
7765 <p>
7766 I don't see any requirements on the types of the elements of the
7767 std::pair container in 20.2.2. From the descriptions of the member
7768 functions it appears that they must at least satisfy the requirements of
7769 20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
7770 the case of the [in]equality operators also the requirements of 20.1.1
7771 [lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
7772 </p>
7773
7774 <p>
7775 I believe that the the CopyConstructible requirement is unnecessary in
7776 the case of 20.2.2, p2.
7777 </p>
7778 <p><b>Proposed resolution:</b></p>
7779 <p>Change the Effects clause in 20.2.2, p2 from</p>
7780
7781 <blockquote>
7782 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
7783 first(T1()), second(T2()) {} </tt>
7784 </blockquote>
7785
7786 <p>to</p>
7787
7788 <blockquote>
7789 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
7790 first(), second() {} </tt>
7791 </blockquote>
7792 <p><b>Rationale:</b></p>
7793 <p>The existing specification of pair's constructor appears to be a
7794 historical artifact: there was concern that pair's members be properly
7795 zero-initialized when they are built-in types.  At one time there was
7796 uncertainty about whether they would be zero-initialized if the
7797 default constructor was written the obvious way.  This has been
7798 clarified by core issue 178, and there is no longer any doubt that
7799 the straightforward implementation is correct.</p>
7800 <hr>
7801 <a name="266"><h3>266.&nbsp;bad_exception::~bad_exception() missing Effects clause</h3></a><p><b>Section:</b>&nbsp;18.6.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>
7802 <p>
7803 The synopsis for std::bad_exception lists the function ~bad_exception()
7804 but there is no description of what the function does (the Effects
7805 clause is missing).
7806 </p>
7807 <p><b>Proposed resolution:</b></p>
7808 <p>
7809 Remove the destructor from the class synopses of
7810 <tt>bad_alloc</tt> (18.4.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.alloc"> [lib.bad.alloc]</a>),
7811 <tt>bad_cast</tt> (18.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.cast"> [lib.bad.cast]</a>),
7812 <tt>bad_typeid</tt> (18.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.typeid"> [lib.bad.typeid]</a>),
7813 and <tt>bad_exception</tt> (18.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.exception"> [lib.bad.exception]</a>).
7814 </p>
7815 <p><b>Rationale:</b></p>
7816 <p>
7817 This is a general problem with the exception classes in clause 18.
7818 The proposed resolution is to remove the destructors from the class
7819 synopses, rather than to document the destructors' behavior, because
7820 removing them is more consistent with how exception classes are
7821 described in clause 19.
7822 </p>
7823 <hr>
7824 <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>
7825 <p>The synopsis of the class std::locale in 22.1.1 contains two typos:
7826 the semicolons after the declarations of the default ctor
7827 locale::locale() and the copy ctor locale::locale(const locale&amp;)
7828 are missing.</p>
7829 <p><b>Proposed resolution:</b></p>
7830 <p>Add the missing semicolons, i.e., change</p>
7831
7832 <pre>    //  construct/copy/destroy:
7833         locale() throw()
7834         locale(const locale&amp; other) throw()
7835 </pre>
7836
7837 <p>in the synopsis in 22.1.1 to</p>
7838
7839 <pre>    //  construct/copy/destroy:
7840         locale() throw();
7841         locale(const locale&amp; other) throw();
7842 </pre>
7843 <hr>
7844 <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>
7845 <p>
7846 Each of the four binary search algorithms (lower_bound, upper_bound,
7847 equal_range, binary_search) has a form that allows the user to pass a
7848 comparison function object.  According to 25.3, paragraph 2, that
7849 comparison function object has to be a strict weak ordering.
7850 </p>
7851
7852 <p>
7853 This requirement is slightly too strict.  Suppose we are searching
7854 through a sequence containing objects of type X, where X is some
7855 large record with an integer key.  We might reasonably want to look
7856 up a record by key, in which case we would want to write something
7857 like this:
7858 </p>
7859 <pre>    struct key_comp {
7860       bool operator()(const X&amp; x, int n) const {
7861         return x.key() &lt; n;
7862       }
7863     }
7864
7865     std::lower_bound(first, last, 47, key_comp());
7866 </pre>
7867
7868 <p>
7869 key_comp is not a strict weak ordering, but there is no reason to
7870 prohibit its use in lower_bound.
7871 </p>
7872
7873 <p>
7874 There's no difficulty in implementing lower_bound so that it allows
7875 the use of something like key_comp.  (It will probably work unless an
7876 implementor takes special pains to forbid it.)  What's difficult is
7877 formulating language in the standard to specify what kind of
7878 comparison function is acceptable.  We need a notion that's slightly
7879 more general than that of a strict weak ordering, one that can encompass
7880 a comparison function that involves different types.  Expressing that
7881 notion may be complicated.
7882 </p>
7883
7884 <p><i>Additional questions raised at the Toronto meeting:</i></p>
7885 <ul>
7886 <li> Do we really want to specify what ordering the implementor must
7887      use when calling the function object?  The standard gives
7888      specific expressions when describing these algorithms, but it also
7889      says that other expressions (with different argument order) are
7890      equivalent.</li>
7891 <li> If we are specifying ordering, note that the standard uses both
7892      orderings when describing <tt>equal_range</tt>.</li>
7893 <li> Are we talking about requiring these algorithms to work properly
7894      when passed a binary function object whose two argument types
7895      are not the same, or are we talking about requirements when
7896      they are passed a binary function object with several overloaded
7897      versions of <tt>operator()</tt>?</li>
7898 <li> The definition of a strict weak ordering does not appear to give
7899      any guidance on issues of overloading; it only discusses expressions,
7900      and all of the values in these expressions are of the same type.
7901      Some clarification would seem to be in order.</li>
7902 </ul>
7903
7904 <p><i>Additional discussion from Copenhagen:</i></p>
7905 <ul>
7906 <li>It was generally agreed that there is a real defect here: if
7907 the predicate is merely required to be a Strict Weak Ordering, then
7908 it's possible to pass in a function object with an overloaded
7909 operator(), where the version that's actually called does something
7910 completely inappropriate.  (Such as returning a random value.)</li>
7911
7912 <li>An alternative formulation was presented in a paper distributed by
7913 David Abrahams at the meeting, "Binary Search with Heterogeneous
7914 Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
7915 predicate as a Strict Weak Ordering acting on a sorted sequence, view
7916 the predicate/value pair as something that partitions a sequence.
7917 This is almost equivalent to saying that we should view binary search
7918 as if we are given a unary predicate and a sequence, such that f(*p)
7919 is true for all p below a specific point and false for all p above it.
7920 The proposed resolution is based on that alternative formulation.</li>
7921 </ul>
7922 <p><b>Proposed resolution:</b></p>
7923
7924 <p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
7925
7926 <blockquote>
7927   3 For all algorithms that take Compare, there is a version that uses
7928   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i &lt;
7929   *j != false. For the algorithms to work correctly, comp has to
7930   induce a strict weak ordering on the values.
7931 </blockquote>
7932
7933 <p>to:</p>
7934
7935 <blockquote>
7936   3 For all algorithms that take Compare, there is a version that uses
7937   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i
7938   &lt; *j != false. For algorithms other than those described in
7939   lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
7940   a strict weak ordering on the values.
7941 </blockquote>
7942
7943 <p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
7944
7945 <blockquote>
7946   -6- A sequence [start, finish) is partitioned with respect to an
7947   expression f(e) if there exists an integer n such that
7948   for all 0 &lt;= i &lt; distance(start, finish), f(*(begin+i)) is true if
7949   and only if i &lt; n.
7950 </blockquote>
7951
7952 <p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
7953
7954 <blockquote>
7955   -1- All of the algorithms in this section are versions of binary
7956    search and assume that the sequence being searched is in order
7957    according to the implied or explicit comparison function. They work
7958    on non-random access iterators minimizing the number of
7959    comparisons, which will be logarithmic for all types of
7960    iterators. They are especially appropriate for random access
7961    iterators, because these algorithms do a logarithmic number of
7962    steps through the data structure. For non-random access iterators
7963    they execute a linear number of steps.
7964 </blockquote>
7965
7966 <p>to:</p>
7967
7968 <blockquote>
7969    -1- All of the algorithms in this section are versions of binary
7970     search and assume that the sequence being searched is partitioned
7971     with respect to an expression formed by binding the search key to
7972     an argument of the implied or explicit comparison function. They
7973     work on non-random access iterators minimizing the number of
7974     comparisons, which will be logarithmic for all types of
7975     iterators. They are especially appropriate for random access
7976     iterators, because these algorithms do a logarithmic number of
7977     steps through the data structure. For non-random access iterators
7978     they execute a linear number of steps.
7979 </blockquote>
7980
7981 <p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
7982
7983 <blockquote>
7984    -1- Requires: Type T is LessThanComparable
7985     (lib.lessthancomparable).
7986 </blockquote>
7987
7988 <p>to:</p>
7989
7990 <blockquote>
7991    -1- Requires: The elements e of [first, last) are partitioned with
7992    respect to the expression e &lt; value or comp(e, value)
7993 </blockquote>
7994
7995
7996 <p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
7997
7998 <blockquote>
7999    -2- Effects: Finds the first position into which value can be
8000     inserted without violating the ordering.
8001 </blockquote>
8002
8003 <p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
8004
8005 <blockquote>
8006   -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
8007 </blockquote>
8008
8009 <p>to:</p>
8010
8011 <blockquote>
8012    -1- Requires: The elements e of [first, last) are partitioned with
8013    respect to the expression !(value &lt; e) or !comp(value, e)
8014 </blockquote>
8015
8016 <p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
8017
8018 <blockquote>
8019    -2- Effects: Finds the furthermost position into which value can be
8020     inserted without violating the ordering.
8021 </blockquote>
8022
8023 <p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
8024
8025 <blockquote>
8026    -1- Requires: Type T is LessThanComparable
8027     (lib.lessthancomparable).
8028 </blockquote>
8029
8030 <p>to:</p>
8031
8032 <blockquote>
8033    -1- Requires: The elements e of [first, last) are partitioned with
8034    respect to the expressions e &lt; value and !(value &lt; e) or
8035    comp(e, value) and !comp(value, e).  Also, for all elements e of
8036    [first, last), e &lt; value implies !(value &lt; e) or comp(e,
8037    value) implies !comp(value, e)
8038 </blockquote>
8039
8040 <p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
8041
8042 <blockquote>
8043    -2- Effects: Finds the largest subrange [i, j) such that the value
8044     can be inserted at any iterator k in it without violating the
8045     ordering. k satisfies the corresponding conditions: !(*k &lt; value)
8046     &amp;&amp; !(value &lt; *k) or comp(*k, value) == false &amp;&amp; comp(value, *k) ==
8047     false.
8048 </blockquote>
8049
8050 <p>to:</p>
8051
8052 <pre>   -2- Returns:
8053          make_pair(lower_bound(first, last, value),
8054                    upper_bound(first, last, value))
8055        or
8056          make_pair(lower_bound(first, last, value, comp),
8057                    upper_bound(first, last, value, comp))
8058 </pre>
8059
8060 <p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
8061
8062 <blockquote>
8063    -1- Requires: Type T is LessThanComparable
8064     (lib.lessthancomparable).
8065 </blockquote>
8066
8067 <p>to:</p>
8068
8069 <blockquote>
8070    -1- Requires: The elements e of [first, last) are partitioned with
8071    respect to the expressions e &lt; value and !(value &lt; e) or comp(e,
8072    value) and !comp(value, e). Also, for all elements e of [first,
8073    last), e &lt; value implies !(value &lt; e) or comp(e, value) implies
8074    !comp(value, e)
8075 </blockquote>
8076
8077 <p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
8078
8079 <p><i>[Redmond: Minor changes in wording.  (Removed "non-negative", and
8080 changed the "other than those described in" wording.) Also, the LWG
8081 decided to accept the "optional" part.]</i></p>
8082
8083 <p><b>Rationale:</b></p>
8084 <p>The proposed resolution reinterprets binary search. Instead of
8085 thinking about searching for a value in a sorted range, we view that
8086 as an important special case of a more general algorithm: searching
8087 for the partition point in a partitioned range.</p>
8088
8089 <p>We also add a guarantee that the old wording did not: we ensure
8090 that the upper bound is no earlier than the lower bound, that
8091 the pair returned by equal_range is a valid range, and that the first
8092 part of that pair is the lower bound.</p>
8093 <hr>
8094 <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>
8095 <p>
8096 Class template basic_iostream has no typedefs.  The typedefs it
8097 inherits from its base classes can't be used, since (for example)
8098 basic_iostream&lt;T&gt;::traits_type is ambiguous.
8099 </p>
8100 <p><b>Proposed resolution:</b></p>
8101
8102 <p>Add the following to basic_iostream's class synopsis in
8103 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>
8104
8105 <pre>  // types:
8106   typedef charT                     char_type;
8107   typedef typename traits::int_type int_type;
8108   typedef typename traits::pos_type pos_type;
8109   typedef typename traits::off_type off_type;
8110   typedef traits                    traits_type;
8111 </pre>
8112 <hr>
8113 <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>
8114 <p>
8115 27.4.4.3, p4 says about the postcondition of the function: If
8116 rdbuf()!=0 then state == rdstate(); otherwise
8117 rdstate()==state|ios_base::badbit.
8118 </p>
8119
8120 <p>
8121 The expression on the right-hand-side of the operator==() needs to be
8122 parenthesized in order for the whole expression to ever evaluate to
8123 anything but non-zero.
8124 </p>
8125 <p><b>Proposed resolution:</b></p>
8126 <p>
8127 Add parentheses like so: rdstate()==(state|ios_base::badbit).
8128 </p>
8129 <hr>
8130 <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>
8131 <p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
8132 27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
8133 That's incorrect since the names are members of a dependent base
8134 class (14.6.2 [temp.dep]) and thus not visible.</p>
8135 <p><b>Proposed resolution:</b></p>
8136 <p>Qualify the names with the name of the class of which they are
8137 members, i.e., ios_base.</p>
8138 <hr>
8139 <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.allocator.requirements"> [lib.allocator.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;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
8140 <p>
8141 I see that table 31 in 20.1.5, p3 allows T in std::allocator&lt;T&gt; to be of
8142 any type. But the synopsis in 20.4.1 calls for allocator&lt;&gt;::address() to
8143 be overloaded on reference and const_reference, which is ill-formed for
8144 all T = const U. In other words, this won't work:
8145 </p>
8146
8147 <p>
8148 template class std::allocator&lt;const int&gt;;
8149 </p>
8150
8151 <p>
8152 The obvious solution is to disallow specializations of allocators on
8153 const types. However, while containers' elements are required to be
8154 assignable (which rules out specializations on const T's), I think that
8155 allocators might perhaps be potentially useful for const values in other
8156 contexts. So if allocators are to allow const types a partial
8157 specialization of std::allocator&lt;const T&gt; would probably have to be
8158 provided.
8159 </p>
8160 <p><b>Proposed resolution:</b></p>
8161 <p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
8162
8163     <blockquote>
8164     any type
8165     </blockquote>
8166
8167 <p>to</p>
8168     <blockquote>
8169     any non-const, non-reference type
8170     </blockquote>
8171
8172 <p><i>[Redmond: previous proposed resolution was "any non-const,
8173 non-volatile, non-reference type".  Got rid of the "non-volatile".]</i></p>
8174
8175 <p><b>Rationale:</b></p>
8176 <p>
8177 Two resolutions were originally proposed: one that partially
8178 specialized std::allocator for const types, and one that said an
8179 allocator's value type may not be const.  The LWG chose the second.
8180 The first wouldn't be appropriate, because allocators are intended for
8181 use by containers, and const value types don't work in containers.
8182 Encouraging the use of allocators with const value types would only
8183 lead to unsafe code.
8184 </p>
8185 <p>
8186 The original text for proposed resolution 2 was modified so that it
8187 also forbids volatile types and reference types.
8188 </p>
8189
8190 <p><i>[Curaçao: LWG double checked and believes volatile is correctly
8191 excluded from the PR.]</i></p>
8192
8193 <hr>
8194 <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>
8195 <p>
8196 In 22.2.2.1.1, we have a list of overloads for num_get&lt;&gt;::get().
8197 There are eight overloads, all of which are identical except for the
8198 last parameter.  The overloads are:
8199 </p>
8200 <ul>
8201 <li> long&amp; </li>
8202 <li> unsigned short&amp; </li>
8203 <li> unsigned int&amp; </li>
8204 <li> unsigned long&amp; </li>
8205 <li> short&amp; </li>
8206 <li> double&amp; </li>
8207 <li> long double&amp; </li>
8208 <li> void*&amp; </li>
8209 </ul>
8210
8211 <p>
8212 There is a similar list, in 22.2.2.1.2, of overloads for
8213 num_get&lt;&gt;::do_get().  In this list, the last parameter has
8214 the types:
8215 </p>
8216 <ul>
8217 <li> long&amp; </li>
8218 <li> unsigned short&amp; </li>
8219 <li> unsigned int&amp; </li>
8220 <li> unsigned long&amp; </li>
8221 <li> float&amp; </li>
8222 <li> double&amp; </li>
8223 <li> long double&amp; </li>
8224 <li> void*&amp; </li>
8225 </ul>
8226
8227 <p>
8228 These two lists are not identical.  They should be, since
8229 <tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
8230 the arguments it was given.
8231 </p>
8232 <p><b>Proposed resolution:</b></p>
8233 <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>
8234 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
8235                 ios_base::iostate&amp; err, short&amp; val) const;
8236 </pre>
8237 <p>to</p>
8238 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
8239                 ios_base::iostate&amp; err, float&amp; val) const;
8240 </pre>
8241 <hr>
8242 <a name="276"><h3>276.&nbsp;Assignable requirement for container value type overly strict</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;07 Nov 2000</p>
8243 <p>
8244 23.1/3 states that the objects stored in a container must be
8245 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,
8246 states that map satisfies all requirements for a container, while in
8247 the same time defining value_type as pair&lt;const Key, T&gt; - a type
8248 that is not Assignable.
8249 </p>
8250
8251 <p>
8252 It should be noted that there exists a valid and non-contradictory
8253 interpretation of the current text. The wording in 23.1/3 avoids
8254 mentioning value_type, referring instead to "objects stored in a
8255 container." One might argue that map does not store objects of
8256 type map::value_type, but of map::mapped_type instead, and that the
8257 Assignable requirement applies to map::mapped_type, not
8258 map::value_type.
8259 </p>
8260
8261 <p>
8262 However, this makes map a special case (other containers store objects of
8263 type value_type) and the Assignable requirement is needlessly restrictive in
8264 general.
8265 </p>
8266
8267 <p>
8268 For example, the proposed resolution of active library issue
8269 <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
8270 means that no set operations can exploit the fact that the stored
8271 objects are Assignable.
8272 </p>
8273
8274 <p>
8275 This is related to, but slightly broader than, closed issue
8276 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>.
8277 </p>
8278 <p><b>Proposed resolution:</b></p>
8279 <p>23.1/3: Strike the trailing part of the sentence:</p>
8280     <blockquote>
8281     , and the additional requirements of Assignable types from 23.1/3
8282     </blockquote>
8283 <p>so that it reads:</p>
8284     <blockquote>
8285     -3- The type of objects stored in these components must meet the
8286     requirements of CopyConstructible types (lib.copyconstructible).
8287     </blockquote>
8288
8289 <p>23.1/4: Modify to make clear that this requirement is not for all
8290 containers.  Change to:</p>
8291
8292 <blockquote>
8293 -4- Table 64 defines the Assignable requirement.  Some containers
8294 require this property of the types to be stored in the container.  T is
8295 the type used to instantiate the container. t is a value of T, and u is
8296 a value of (possibly const) T.
8297 </blockquote>
8298
8299 <p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
8300 CopyConstructible".</p>
8301
8302 <p>23.2.1/2: Add sentence for Assignable requirement.  Change to:</p>
8303
8304 <blockquote>
8305 -2- A deque satisfies all of the requirements of a container and of a
8306 reversible container (given in tables in lib.container.requirements) and
8307 of a sequence, including the optional sequence requirements
8308 (lib.sequence.reqmts).  In addition to the requirements on the stored
8309 object described in 23.1[lib.container.requirements], the stored object
8310 must also meet the requirements of Assignable.  Descriptions are
8311 provided here only for operations on deque that are not described in one
8312 of these tables or for operations where there is additional semantic
8313 information.
8314 </blockquote>
8315
8316 <p>23.2.2/2:  Add Assignable requirement to specific methods of list.
8317 Change to:</p>
8318
8319 <blockquote>
8320 <p>-2- A list satisfies all of the requirements of a container and of a
8321 reversible container (given in two tables in lib.container.requirements)
8322 and of a sequence, including most of the the optional sequence
8323 requirements (lib.sequence.reqmts). The exceptions are the operator[]
8324 and at member functions, which are not provided.
8325
8326 [Footnote: These member functions are only provided by containers whose
8327 iterators are random access iterators. --- end foonote]
8328 </p>
8329
8330 <p>list does not require the stored type T to be Assignable unless the
8331 following methods are instantiated:
8332
8333 [Footnote: Implementors are permitted but not required to take advantage
8334 of T's Assignable properties for these methods. -- end foonote]
8335 </p>
8336 <pre>     list&lt;T,Allocator&gt;&amp; operator=(const list&lt;T,Allocator&gt;&amp;  x );
8337      template &lt;class InputIterator&gt;
8338        void assign(InputIterator first, InputIterator last);
8339      void assign(size_type n, const T&amp; t);
8340 </pre>
8341
8342
8343 <p>Descriptions are provided here only for operations on list that are not
8344 described in one of these tables or for operations where there is
8345 additional semantic information.</p>
8346 </blockquote>
8347
8348 <p>23.2.4/2:   Add sentence for Assignable requirement.  Change to:</p>
8349
8350 <blockquote>
8351 -2- A vector satisfies all of the requirements of a container and of a
8352 reversible container (given in two tables in lib.container.requirements)
8353 and of a sequence, including most of the optional sequence requirements
8354 (lib.sequence.reqmts). The exceptions are the push_front and pop_front
8355 member functions, which are not provided.  In addition to the
8356 requirements on the stored object described in
8357 23.1[lib.container.requirements], the stored object must also meet the
8358 requirements of Assignable.  Descriptions are provided here only for
8359 operations on vector that are not described in one of these tables or
8360 for operations where there is additional semantic information.
8361 </blockquote>
8362 <p><b>Rationale:</b></p>
8363 <p>list, set, multiset, map, multimap are able to store non-Assignables.
8364 However, there is some concern about <tt>list&lt;T&gt;</tt>:
8365 although in general there's no reason for T to be Assignable, some
8366 implementations of the member functions <tt>operator=</tt> and
8367 <tt>assign</tt> do rely on that requirement.  The LWG does not want
8368 to forbid such implementations.</p>
8369
8370 <p>Note that the type stored in a standard container must still satisfy
8371 the requirements of the container's allocator; this rules out, for
8372 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>
8373 for more details.
8374 </p>
8375
8376 <p>In principle we could also relax the "Assignable" requirement for
8377 individual <tt>vector</tt> member functions, such as
8378 <tt>push_back</tt>.  However, the LWG did not see great value in such
8379 selective relaxation.  Doing so would remove implementors' freedom to
8380 implement <tt>vector::push_back</tt> in terms of
8381 <tt>vector::insert</tt>.</p>
8382
8383 <hr>
8384 <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.list.ops"> [lib.list.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;P.J. Plauger&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
8385 <p>
8386 Section 23.2.2.4 [lib.list.ops] states that
8387 </p>
8388 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
8389 </pre>
8390 <p>
8391 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
8392 </p>
8393
8394 <p>
8395 But what does the C++ Standard mean by "invalidate"?  You
8396 can still dereference the iterator to a spliced list element, but
8397 you'd better not use it to delimit a range within the original
8398 list. For the latter operation, it has definitely lost some of its
8399 validity.
8400 </p>
8401
8402 <p>
8403 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>,
8404 then we'd better clarify that a "valid" iterator need no
8405 longer designate an element within the same container as it once did.
8406 We then have to clarify what we mean by invalidating a past-the-end
8407 iterator, as when a vector or string grows by reallocation. Clearly,
8408 such an iterator has a different kind of validity. Perhaps we should
8409 introduce separate terms for the two kinds of "validity."
8410 </p>
8411 <p><b>Proposed resolution:</b></p>
8412 <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>,
8413 after paragraph 5:</p>
8414 <blockquote>
8415 An <i>invalid</i> iterator is an iterator that may be
8416 singular. [Footnote: This definition applies to pointers, since
8417 pointers are iterators. The effect of dereferencing an iterator that
8418 has been invalidated is undefined.]
8419 </blockquote>
8420
8421 <p><i>[post-Copenhagen: Matt provided wording.]</i></p>
8422
8423 <p><i>[Redmond: General agreement with the intent, some objections to
8424 the wording.  Dave provided new wording.]</i></p>
8425 <p><b>Rationale:</b></p>
8426 <p>This resolution simply defines a term that the Standard uses but
8427   never defines, "invalid", in terms of a term that is defined,
8428   "singular".</p>
8429
8430 <p>Why do we say "may be singular", instead of "is singular"?  That's
8431   becuase a valid iterator is one that is known to be nonsingular.
8432   Invalidating an iterator means changing it in such a way that it's
8433   no longer known to be nonsingular.  An example: inserting an
8434   element into the middle of a vector is correctly said to invalidate
8435   all iterators pointing into the vector.  That doesn't necessarily
8436   mean they all become singular.</p>
8437 <hr>
8438 <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>
8439 <p>
8440 This came from an email from Steve Cleary to Fergus in reference to
8441 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
8442 this in Toronto and believed it should be a separate issue.  There was
8443 also some reservations about whether this was a worthwhile problem to
8444 fix.
8445 </p>
8446
8447 <p>
8448 Steve said: "Fixing reverse_iterator. std::reverse_iterator can
8449 (and should) be changed to preserve these additional
8450 requirements." He also said in email that it can be done without
8451 breaking user's code: "If you take a look at my suggested
8452 solution, reverse_iterator doesn't have to take two parameters; there
8453 is no danger of breaking existing code, except someone taking the
8454 address of one of the reverse_iterator global operator functions, and
8455 I have to doubt if anyone has ever done that. . .  <i>But</i>, just in
8456 case they have, you can leave the old global functions in as well --
8457 they won't interfere with the two-template-argument functions.  With
8458 that, I don't see how <i>any</i> user code could break."
8459 </p>
8460 <p><b>Proposed resolution:</b></p>
8461 <p>
8462 <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>
8463 add/change the following declarations:</p>
8464 <pre>  A) Add a templated assignment operator, after the same manner
8465         as the templated copy constructor, i.e.:
8466
8467   template &lt; class U &gt;
8468   reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
8469
8470   B) Make all global functions (except the operator+) have
8471   two template parameters instead of one, that is, for
8472   operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
8473
8474        template &lt; class Iterator &gt;
8475        typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
8476                  const reverse_iterator&lt; Iterator &gt;&amp; x,
8477                  const reverse_iterator&lt; Iterator &gt;&amp; y);
8478
8479   with:
8480
8481       template &lt; class Iterator1, class Iterator2 &gt;
8482       typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
8483                  const reverse_iterator &lt; Iterator1 &gt; &amp; x,
8484                  const reverse_iterator &lt; Iterator2 &gt; &amp; y);
8485 </pre>
8486 <p>
8487 Also make the addition/changes for these signatures in
8488 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>.
8489 </p>
8490
8491 <p><i>[
8492 Copenhagen: The LWG is concerned that the proposed resolution
8493 introduces new overloads.  Experience shows that introducing
8494 overloads is always risky, and that it would be inappropriate to
8495 make this change without implementation experience.  It may be
8496 desirable to provide this feature in a different way.
8497 ]</i></p>
8498
8499 <p><i>[
8500 Lillehammer: We now have implementation experience, and agree that
8501 this solution is safe and correct.
8502 ]</i></p>
8503
8504 <hr>
8505 <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>
8506 <p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
8507 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>)
8508 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>).
8509 Since the functions take and return their arguments and result by
8510 const reference, I believe the <tt>CopyConstructible</tt> requirement
8511 is unnecessary.
8512 </p>
8513 <p><b>Proposed resolution:</b></p>
8514 <p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
8515 25.3.7, p1 with</p>
8516 <p><b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt>
8517 (20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
8518 </p>
8519 <p>and replace 25.3.7, p4 with</p>
8520 <p><b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt>
8521 (20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
8522 </p>
8523 <hr>
8524 <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>
8525 <p>
8526 Paragraph 16 mistakenly singles out integral types for inserting
8527 thousands_sep() characters.  This conflicts with the syntax for floating
8528 point numbers described under 22.2.3.1/2.
8529 </p>
8530 <p><b>Proposed resolution:</b></p>
8531 <p>Change paragraph 16 from:</p>
8532
8533 <blockquote>
8534 For integral types, punct.thousands_sep() characters are inserted into
8535 the sequence as determined by the value returned by punct.do_grouping()
8536 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>.
8537 </blockquote>
8538
8539 <p>To:</p>
8540
8541 <blockquote>
8542 For arithmetic types, punct.thousands_sep() characters are inserted into
8543 the sequence as determined by the value returned by punct.do_grouping()
8544 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>.
8545 </blockquote>
8546
8547 <p><i>[
8548 Copenhagen: Opinions were divided about whether this is actually an
8549 inconsistency, but at best it seems to have been unintentional.  This
8550 is only an issue for floating-point output: The standard is
8551 unambiguous that implementations must parse thousands_sep characters
8552 when performing floating-point.  The standard is also unambiguous that
8553 this requirement does not apply to the "C" locale.
8554 ]</i></p>
8555
8556 <p><i>[
8557 A survey of existing practice is needed; it is believed that some
8558 implementations do insert thousands_sep characters for floating-point
8559 output and others fail to insert thousands_sep characters for
8560 floating-point input even though this is unambiguously required by the
8561 standard.
8562 ]</i></p>
8563
8564 <p><i>[Post-Curaçao: the above proposed resolution is the consensus of
8565 Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
8566
8567 <hr>
8568 <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>
8569 <p>
8570 (revision of the further discussion)
8571 There are a number of problems with the requires clauses for the
8572 algorithms in 25.1 and 25.2. The requires clause of each algorithm
8573 should describe the necessary and sufficient requirements on the inputs
8574 to the algorithm such that the algorithm compiles and runs properly.
8575 Many of the requires clauses fail to do this. Here is a summary of the kinds
8576 of mistakes:
8577 </p>
8578
8579 <ol>
8580 <li>
8581 Use of EqualityComparable, which only puts requirements on a single
8582 type, when in fact an equality operator is required between two
8583 different types, typically either T and the iterator's value type
8584 or between the value types of two different iterators.
8585 </li>
8586 <li>
8587 Use of Assignable for T when in fact what was needed is Assignable
8588 for the value_type of the iterator, and convertability from T to the
8589 value_type of the iterator. Or for output iterators, the requirement
8590 should be that T is writable to the iterator (output iterators do
8591 not have value types).
8592 </li>
8593 </ol>
8594
8595 <p>
8596 Here is the list of algorithms that contain mistakes:
8597 </p>
8598
8599 <ul>
8600 <li>25.1.2 std::find</li>
8601 <li>25.1.6 std::count</li>
8602 <li>25.1.8 std::equal</li>
8603 <li>25.1.9 std::search, std::search_n</li>
8604 <li>25.2.4 std::replace, std::replace_copy</li>
8605 <li>25.2.5 std::fill</li>
8606 <li>25.2.7 std::remove, std::remove_copy</li>
8607 </ul>
8608
8609 <p>
8610 Also, in the requirements for EqualityComparable, the requirement that
8611 the operator be defined for const objects is lacking.
8612 </p>
8613
8614 <p><b>Proposed resolution:</b></p>
8615
8616 <p>20.1.1 Change p1 from</p>
8617
8618 <p>In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
8619 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
8620 values of type <tt>T</tt>.
8621 </p>
8622
8623 <p>to</p>
8624
8625 <p>
8626 In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
8627 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
8628 values of type <tt>const T</tt>.
8629 </p>
8630
8631 <p>25 Between p8 and p9</p>
8632
8633 <p>Add the following sentence:</p>
8634
8635 <p>When the description of an algorithm gives an expression such as
8636 <tt>*first == value</tt> for a condition, it is required that the expression
8637 evaluate to either true or false in boolean contexts.</p>
8638
8639 <p>25.1.2 Change p1 by deleting the requires clause.</p>
8640
8641 <p>25.1.6 Change p1 by deleting the requires clause.</p>
8642
8643 <p>25.1.9</p>
8644
8645 <p>Change p4 from</p>
8646
8647 <p>-4- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt>
8648 (20.1.1), type Size is convertible to integral type (4.7.12.3).
8649 </p>
8650
8651 <p>to</p>
8652
8653 <p>-4- Requires: The type <tt>Size</tt> is convertible to integral
8654 type (4.7.12.3).</p>
8655
8656 <p>25.2.4 Change p1 from</p>
8657
8658 <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>
8659
8660 <p>to</p>
8661
8662 <p>-1- Requires: The expression <tt>*first = new_value</tt> must be valid.</p>
8663
8664 <p>and change p4 from</p>
8665
8666 <p>-4- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1) (and,
8667 for <tt>replace_copy()</tt>, <tt>EqualityComparable</tt>
8668 (20.1.1)). The ranges <tt>[first, last)</tt> and <tt>[result, result +
8669 (last - first))</tt> shall not overlap.</p>
8670
8671 <p>to</p>
8672
8673 <p>-4- Requires: The results of the expressions <tt>*first</tt> and
8674 <tt>new_value</tt> must be writable to the result output iterator. The
8675 ranges <tt>[first, last)</tt> and <tt>[result, result + (last -
8676 first))</tt> shall not overlap.</p>
8677
8678
8679 <p>25.2.5 Change p1 from</p>
8680
8681 <p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1). The
8682 type <tt>Size</tt> is convertible to an integral type (4.7.12.3).</p>
8683
8684 <p>to</p>
8685
8686 <p>-1- Requires: The expression <tt>value</tt> must be is writable to
8687 the output iterator. The type <tt>Size</tt> is convertible to an
8688 integral type (4.7.12.3).</p>
8689
8690 <p>25.2.7 Change p1 from</p>
8691
8692 <p>-1- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> (20.1.1).</p>
8693
8694 <p>to</p>
8695
8696 <p>
8697 -1- Requires: The value type of the iterator must be
8698 <tt>Assignable</tt> (23.1).
8699 </p>
8700
8701 <p><b>Rationale:</b></p>
8702 <p>
8703 The general idea of the proposed solution is to remove the faulty
8704 requires clauses and let the returns and effects clauses speak for
8705 themselves. That is, the returns clauses contain expressions that must
8706 be valid, and therefore already imply the correct requirements. In
8707 addition, a sentence is added at the beginning of chapter 25 saying
8708 that expressions given as conditions must evaluate to true or false in
8709 a boolean context. An alternative would be to say that the type of
8710 these condition expressions must be literally bool, but that would be
8711 imposing a greater restriction that what the standard currently says
8712 (which is convertible to bool).
8713 </p>
8714 <hr>
8715 <a name="284"><h3>284.&nbsp;unportable example in 20.3.7, p6</h3></a><p><b>Section:</b>&nbsp;20.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</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>
8716 <p>The example in 20.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a>, p6 shows how to use the C
8717 library function <tt>strcmp()</tt> with the function pointer adapter
8718 <tt>ptr_fun()</tt>. But since it's unspecified whether the C library
8719 functions have <tt>extern "C"</tt> or <tt>extern
8720 "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
8721 function pointers with different the language linkage specifications
8722 (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
8723 well-formed is unspecified.
8724 </p>
8725 <p><b>Proposed resolution:</b></p>
8726 <p>Change 20.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a> paragraph 6 from:</p>
8727 <blockquote>
8728   <p>[<i>Example:</i></p>
8729   <pre>    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
8730   </pre>
8731   <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
8732 </blockquote>
8733
8734
8735 <p>to:</p>
8736 <blockquote>
8737   <p>[<i>Example:</i></p>
8738   <pre>    int compare(const char*, const char*);
8739     replace_if(v.begin(), v.end(),
8740                not1(bind2nd(ptr_fun(compare), "abc")), "def");
8741   </pre>
8742   <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
8743 </blockquote>
8744
8745 <p>Also, remove footnote 215 in that same paragraph.</p>
8746
8747 <p><i>[Copenhagen: Minor change in the proposed resolution.  Since this
8748 issue deals in part with C and C++ linkage, it was believed to be too
8749 confusing for the strings in the example to be "C" and "C++".
8750 ]</i></p>
8751
8752 <p><i>[Redmond: More minor changes.  Got rid of the footnote (which
8753 seems to make a sweeping normative requirement, even though footnotes
8754 aren't normative), and changed the sentence after the footnote so that
8755 it corresponds to the new code fragment.]</i></p>
8756
8757 <hr>
8758 <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>
8759 <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
8760 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:
8761 </p>
8762
8763 <p>... If that function returns a null pointer, calls
8764 <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
8765 </p>
8766
8767 <p>The parenthetical note doesn't apply since the ctors cannot throw an
8768 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
8769 that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
8770 </p>
8771 <p><b>Proposed resolution:</b></p>
8772 <p>
8773 Strike the parenthetical note from the Effects clause in each of the
8774 paragraphs mentioned above.
8775 </p>
8776 <hr>
8777 <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>
8778 <p>
8779 The &lt;cstdlib&gt; header file contains prototypes for bsearch and
8780 qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
8781 prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
8782 require the typedef size_t. Yet size_t is not listed in the
8783 &lt;cstdlib&gt; synopsis table 78 in section 25.4.
8784 </p>
8785 <p><b>Proposed resolution:</b></p>
8786 <p>
8787 Add the type size_t to Table 78 (section 25.4) and add
8788 the type size_t &lt;cstdlib&gt; to Table 97 (section C.2).
8789 </p>
8790 <p><b>Rationale:</b></p>
8791 <p>Since size_t is in &lt;stdlib.h&gt;, it must also be in &lt;cstdlib&gt;.</p>
8792 <hr>
8793 <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>
8794 <p>
8795 ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
8796 of macros defined in &lt;errno.h&gt; is adjusted to include a new
8797 macro, EILSEQ"
8798 </p>
8799
8800 <p>
8801 ISO/IEC 14882:1998(E) section 19.3 does not refer
8802 to the above amendment.
8803 </p>
8804
8805 <p><b>Proposed resolution:</b></p>
8806 <p>
8807 Update Table 26 (section 19.3) "Header  &lt;cerrno&gt; synopsis"
8808 and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
8809 </p>
8810 <hr>
8811 <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>
8812 <p>
8813 The standard library contains four algorithms that compute set
8814 operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
8815 <tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>.  Each
8816 of these algorithms takes two sorted ranges as inputs, and writes the
8817 output of the appropriate set operation to an output range.  The elements
8818 in the output range are sorted.
8819 </p>
8820
8821 <p>
8822 The ordinary mathematical definitions are generalized so that they
8823 apply to ranges containing multiple copies of a given element.  Two
8824 elements are considered to be "the same" if, according to an
8825 ordering relation provided by the user, neither one is less than the
8826 other.  So, for example, if one input range contains five copies of an
8827 element and another contains three, the output range of <tt>set_union</tt>
8828 will contain five copies, the output range of
8829 <tt>set_intersection</tt> will contain three, the output range of
8830 <tt>set_difference</tt> will contain two, and the output range of
8831 <tt>set_symmetric_difference</tt> will contain two.
8832 </p>
8833
8834 <p>
8835 Because two elements can be "the same" for the purposes
8836 of these set algorithms, without being identical in other respects
8837 (consider, for example, strings under case-insensitive comparison),
8838 this raises a number of unanswered questions:
8839 </p>
8840
8841 <ul>
8842 <li>If we're copying an element that's present in both of the
8843 input ranges, which one do we copy it from?</li>
8844 <li>If there are <i>n</i> copies of an element in the relevant
8845 input range, and the output range will contain fewer copies (say
8846 <i>m</i>) which ones do we choose?  The first <i>m</i>, or the last
8847 <i>m</i>, or something else?</li>
8848 <li>Are these operations stable?  That is, does a run of equivalent
8849 elements appear in the output range in the same order as as it
8850 appeared in the input range(s)?</li>
8851 </ul>
8852
8853 <p>
8854 The standard should either answer these questions, or explicitly
8855 say that the answers are unspecified.  I prefer the former option,
8856 since, as far as I know, all existing implementations behave the
8857 same way.
8858 </p>
8859
8860 <p><b>Proposed resolution:</b></p>
8861
8862 <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>
8863 <blockquote>
8864 If [first1, last1) contains <i>m</i> elements that are equivalent to
8865 each other and [first2, last2) contains <i>n</i> elements that are
8866 equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
8867 will be copied to the output range: all <i>m</i> of these elements
8868 from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
8869 [first2, last2), in that order.
8870 </blockquote>
8871
8872 <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>
8873 <blockquote>
8874 If [first1, last1) contains <i>m</i> elements that are equivalent to each
8875 other and [first2, last2) contains <i>n</i> elements that are
8876 equivalent to them, the first min(<i>m</i>, <i>n</i>) of those
8877 elements from [first1, last1) are copied to the output range.
8878 </blockquote>
8879
8880 <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>
8881 paragraph 4:</p>
8882 <blockquote>
8883 If [first1, last1) contains <i>m</i> elements that are equivalent to each
8884 other and [first2, last2) contains <i>n</i> elements that are
8885 equivalent to them, the last max(<i>m-n</i>, 0) elements from
8886 [first1, last1) are copied to the output range.
8887 </blockquote>
8888
8889 <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>
8890 paragraph 4:</p>
8891 <blockquote>
8892 If [first1, last1) contains <i>m</i> elements that are equivalent to
8893 each other and [first2, last2) contains <i>n</i> elements that are
8894 equivalent to them, then |<i>m - n</i>| of those elements will be
8895 copied to the output range: the last <i>m - n</i> of these elements
8896 from [first1, last1) if <i>m</i> &gt; <i>n</i>, and the last <i>n -
8897 m</i> of these elements from [first2, last2) if <i>m</i> &lt; <i>n</i>.
8898 </blockquote>
8899
8900 <p><i>[Santa Cruz: it's believed that this language is clearer than
8901   what's in the Standard.  However, it's also believed that the
8902   Standard may already make these guarantees (although not quite in
8903   these words).  Bill and Howard will check and see whether they think
8904   that some or all of these changes may be redundant.  If so, we may
8905   close this issue as NAD.]</i></p>
8906
8907 <p><b>Rationale:</b></p>
8908 <p>For simple cases, these descriptions are equivalent to what's
8909   already in the Standard.  For more complicated cases, they describe
8910   the behavior of existing implementations.</p>
8911 <hr>
8912 <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>
8913 <p>The Effects clause of the member function <tt>copyfmt()</tt> in
8914 27.4.4.2, p15 doesn't consider the case where the left-hand side
8915 argument is identical to the argument on the right-hand side, that is
8916 <tt>(this == &amp;rhs)</tt>.  If the two arguments are identical there
8917 is no need to copy any of the data members or call any callbacks
8918 registered with <tt>register_callback()</tt>.  Also, as Howard Hinnant
8919 points out in message c++std-lib-8149 it appears to be incorrect to
8920 allow the object to fire <tt>erase_event</tt> followed by
8921 <tt>copyfmt_event</tt> since the callback handling the latter event
8922 may inadvertently attempt to access memory freed by the former.
8923 </p>
8924 <p><b>Proposed resolution:</b></p>
8925 <p>Change the Effects clause in 27.4.4.2, p15 from</p>
8926
8927 <blockquote>
8928 <b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
8929 the corresponding member objects of <tt>rhs</tt>, except that...
8930 </blockquote>
8931
8932 <p>to</p>
8933
8934 <blockquote>
8935 <b>-15- Effects:</b>If <tt>(this == &amp;rhs)</tt> does nothing. Otherwise
8936 assigns to the member objects of <tt>*this</tt> the corresponding member
8937 objects of <tt>rhs</tt>, except that...
8938 </blockquote>
8939 <hr>
8940 <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.c.math"> [lib.c.math]</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>
8941 <p>
8942 Table 80 lists the contents of the &lt;cmath&gt; header.  It does not
8943 list <tt>abs()</tt>.  However, 26.5, paragraph 6, which lists added
8944 signatures present in &lt;cmath&gt;, does say that several overloads
8945 of <tt>abs()</tt> should be defined in &lt;cmath&gt;.
8946 </p>
8947 <p><b>Proposed resolution:</b></p>
8948 <p>
8949 Add <tt>abs</tt> to Table 80.  Also, remove the parenthetical list
8950 of functions "(abs(), div(), rand(), srand())" from 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a>,
8951 paragraph 1.
8952 </p>
8953
8954 <p><i>[Copenhagen: Modified proposed resolution so that it also gets
8955 rid of that vestigial list of functions in paragraph 1.]</i></p>
8956
8957 <p><b>Rationale:</b></p>
8958 <p>All this DR does is fix a typo; it's uncontroversial.  A
8959 separate question is whether we're doing the right thing in
8960 putting some overloads in &lt;cmath&gt; that we aren't also
8961 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>
8962 <hr>
8963 <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.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.member.pointer.adaptors"> [lib.member.pointer.adaptors]</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>
8964 <p>The class templates <tt>const_mem_fun_t</tt> in 20.3.8, p8 and
8965 <tt>const_mem_fun1_t</tt>
8966 in 20.3.8, p9 derive from <tt>unary_function&lt;T*, S&gt;</tt>, and
8967 <tt>binary_function&lt;T*,
8968 A, S&gt;</tt>, respectively. Consequently, their <tt>argument_type</tt>, and
8969 <tt>first_argument_type</tt>
8970 members, respectively, are both defined to be <tt>T*</tt> (non-const).
8971 However, their function call member operator takes a <tt>const T*</tt>
8972 argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
8973 T*</tt> instead, so that one can easily refer to it in generic code. The
8974 example below derived from existing code fails to compile due to the
8975 discrepancy:
8976 </p>
8977
8978 <p><tt>template &lt;class T&gt;</tt>
8979 <br><tt>void foo (typename T::argument_type arg)&nbsp;&nbsp; // #1</tt>
8980 <br><tt>{</tt>
8981 <br><tt>&nbsp;&nbsp;&nbsp; typename T::result_type (T::*pf) (typename
8982 T::argument_type)
8983 const =&nbsp;&nbsp; // #2</tt>
8984 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;T::operator();</tt>
8985 <br><tt>}</tt>
8986 </p>
8987
8988 <p><tt>struct X { /* ... */ };</tt></p>
8989
8990 <p><tt>int main ()</tt>
8991 <br><tt>{</tt>
8992 <br><tt>&nbsp;&nbsp;&nbsp; const X x;</tt>
8993 <br><tt>&nbsp;&nbsp;&nbsp; foo&lt;std::const_mem_fun_t&lt;void, X&gt;
8994 &gt;(&amp;x);&nbsp;&nbsp;
8995 // #3</tt>
8996 <br><tt>}</tt>
8997 </p>
8998
8999 <p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
9000 <br>#2 the type of the pointer is incompatible with the type of the member
9001 function
9002 <br>#3 the address of a constant being passed to a function taking a non-const
9003 <tt>X*</tt>
9004 </p>
9005 <p><b>Proposed resolution:</b></p>
9006 <p>Replace the top portion of the definition of the class template
9007 const_mem_fun_t in 20.3.8, p8
9008 </p>
9009 <p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
9010 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9011 unary_function&lt;T*, S&gt; {</tt>
9012 </p>
9013 <p>with</p>
9014 <p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
9015 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9016 unary_function&lt;<b>const</b> T*, S&gt; {</tt>
9017 </p>
9018 <p>Also replace the top portion of the definition of the class template
9019 const_mem_fun1_t in 20.3.8, p9</p>
9020 <p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
9021 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9022 binary_function&lt;T*, A, S&gt; {</tt>
9023 </p>
9024 <p>with</p>
9025 <p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
9026 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9027 binary_function&lt;<b>const</b> T*, A, S&gt; {</tt>
9028 </p>
9029 <p><b>Rationale:</b></p>
9030 <p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
9031 and the argument type itself, are not the same.</p>
9032 <hr>
9033 <a name="298"><h3>298.&nbsp;::operator delete[] requirement incorrect/insufficient</h3></a><p><b>Section:</b>&nbsp;18.4.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>
9034 <p>
9035 The default behavior of <tt>operator delete[]</tt> described in 18.4.1.2, p12 -
9036 namely that for non-null value of <i>ptr</i>, the operator reclaims storage
9037 allocated by the earlier call to the default <tt>operator new[]</tt> - is not
9038 correct in all cases. Since the specified <tt>operator new[]</tt> default
9039 behavior is to call <tt>operator new</tt> (18.4.1.2, p4, p8), which can be
9040 replaced, along with <tt>operator delete</tt>, by the user, to implement their
9041 own memory management, the specified default behavior of<tt> operator
9042 delete[]</tt> must be to call <tt>operator delete</tt>.
9043 </p>
9044 <p><b>Proposed resolution:</b></p>
9045 <p>Change 18.4.1.2, p12 from</p>
9046 <blockquote>
9047 <b>-12-</b> <b>Default behavior:</b>
9048 <ul>
9049 <li>
9050 For a null value of <i><tt>ptr</tt></i> , does nothing.
9051 </li>
9052 <li>
9053 Any other value of <i><tt>ptr</tt></i> shall be a value returned
9054 earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
9055 [Footnote: The value must not have been invalidated by an intervening
9056 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>).
9057 --- end footnote]
9058 For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
9059 allocated by the earlier call to the default <tt>operator new[]</tt>.
9060 </li>
9061 </ul>
9062 </blockquote>
9063
9064 <p>to</p>
9065
9066 <blockquote>
9067 <b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
9068 delete(</tt><i>ptr</i>)
9069 or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
9070 </blockquote>
9071 <p>and expunge paragraph 13.</p>
9072 <hr>
9073 <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.list.ops"> [lib.list.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;John Pedretti&nbsp; <b>Date:</b>&nbsp;23 Jan 2001</p>
9074 <p>
9075 The "Effects" clause for list::merge() (23.2.2.4, p23)
9076 appears to be incomplete: it doesn't cover the case where the argument
9077 list is identical to *this (i.e., this == &amp;x). The requirement in the
9078 note in p24 (below) is that x be empty after the merge which is surely
9079 unintended in this case.
9080 </p>
9081 <p><b>Proposed resolution:</b></p>
9082 <p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraps 23-25 with:</p>
9083 <blockquote>
9084 <p>
9085 23 Effects: if (&amp;x == this) does nothing; otherwise, merges the two
9086 sorted ranges [begin(), end()) and [x.begin(), x.end()).  The result
9087 is a range in which the elements will be sorted in non-decreasing
9088 order according to the ordering defined by comp; that is, for every
9089 iterator i in the range other than the first, the condition comp(*i,
9090 *(i - 1)) will be false.
9091 </p>
9092
9093 <p>
9094 24 Notes: Stable: if (&amp;x != this), then for equivalent elements in the
9095 two original ranges, the elements from the original range [begin(),
9096 end()) always precede the elements from the original range [x.begin(),
9097 x.end()).  If (&amp;x != this) the range [x.begin(), x.end()) is empty
9098 after the merge.
9099 </p>
9100
9101 <p>
9102 25 Complexity: At most size() + x.size() - 1 applications of comp if
9103 (&amp;x !  = this); otherwise, no applications of comp are performed.  If
9104 an exception is thrown other than by a comparison there are no
9105 effects.
9106 </p>
9107
9108 </blockquote>
9109
9110 <p><i>[Copenhagen: The original proposed resolution did not fix all of
9111 the problems in 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, p22-25.  Three different
9112 paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
9113 Changing p23, without changing the other two, appears to introduce
9114 contradictions.  Additionally, "merges the argument list into the
9115 list" is excessively vague.]</i></p>
9116
9117 <p><i>[Post-Curaçao: Robert Klarer provided new wording.]</i></p>
9118
9119 <hr>
9120 <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>
9121 <p>
9122 The effects clause for the basic_string template ctor in 21.3.1, p15
9123 leaves out the third argument of type Allocator. I believe this to be
9124 a mistake.
9125 </p>
9126 <p><b>Proposed resolution:</b></p>
9127 <p>Replace</p>
9128
9129 <blockquote>
9130     <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
9131     type, equivalent to</p>
9132
9133     <blockquote><tt>basic_string(static_cast&lt;size_type&gt;(begin),
9134     static_cast&lt;value_type&gt;(end))</tt></blockquote>
9135 </blockquote>
9136
9137 <p>with</p>
9138
9139 <blockquote>
9140     <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
9141     type, equivalent to</p>
9142
9143     <blockquote><tt>basic_string(static_cast&lt;size_type&gt;(begin),
9144     static_cast&lt;value_type&gt;(end), <b>a</b>)</tt></blockquote>
9145 </blockquote>
9146 <hr>
9147 <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>
9148 <p>
9149 In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
9150 "Extracts up to <i>N</i> (single-byte) characters from
9151 <i>is</i>.", where <i>is</i> is a stream of type
9152 <tt>basic_istream&lt;charT, traits&gt;</tt>.
9153 </p>
9154
9155 <p>
9156 The standard does not say what it means to extract single byte
9157 characters from a stream whose character type, <tt>charT</tt>, is in
9158 general not a single-byte character type.  Existing implementations
9159 differ.
9160 </p>
9161
9162 <p>
9163 A reasonable solution will probably involve <tt>widen()</tt> and/or
9164 <tt>narrow()</tt>, since they are the supplied mechanism for
9165 converting a single character between <tt>char</tt> and
9166 arbitrary <tt>charT</tt>.
9167 </p>
9168
9169 <p>Narrowing the input characters is not the same as widening the
9170 literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
9171 locales in which more than one wide character maps to the narrow
9172 character <tt>'0'</tt>.  Narrowing means that alternate
9173 representations may be used for bitset input, widening means that
9174 they may not be.</p>
9175
9176 <p>Note that for numeric input, <tt>num_get&lt;&gt;</tt>
9177 (22.2.2.1.2/8) compares input characters to widened version of narrow
9178 character literals.</p>
9179
9180 <p>From Pete Becker, in c++std-lib-8224:</p>
9181 <blockquote>
9182 <p>
9183 Different writing systems can have different representations for the
9184 digits that represent 0 and 1. For example, in the Unicode representation
9185 of the Devanagari script (used in many of the Indic languages) the digit 0
9186 is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
9187 into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
9188 0x0031 for for the Latin representations of '0' and '1', as well as code
9189 points for the same numeric values in several other scripts (Tamil has no
9190 character for 0, but does have the digits 1-9), and any of these values
9191 would also be narrowed to '0' and '1'.
9192 </p>
9193
9194 <p>...</p>
9195
9196 <p>
9197 It's fairly common to intermix both native and Latin
9198 representations of numbers in a document. So I think the rule has to be
9199 that if a wide character represents a digit whose value is 0 then the bit
9200 should be cleared; if it represents a digit whose value is 1 then the bit
9201 should be set; otherwise throw an exception. So in a Devanagari locale,
9202 both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
9203 would set it. Widen can't do that. It would pick one of those two values,
9204 and exclude the other one.
9205 </p>
9206
9207 </blockquote>
9208
9209 <p>From Jens Maurer, in c++std-lib-8233:</p>
9210
9211 <blockquote>
9212 <p>
9213 Whatever we decide, I would find it most surprising if
9214 bitset conversion worked differently from int conversion
9215 with regard to alternate local representations of
9216 numbers.
9217 </p>
9218
9219 <p>Thus, I think the options are:</p>
9220 <ul>
9221  <li> Have a new defect issue for 22.2.2.1.2/8 so that it will
9222 require the use of narrow().</li>
9223
9224  <li> Have a defect issue for bitset() which describes clearly
9225 that widen() is to be used.</li>
9226 </ul>
9227 </blockquote>
9228 <p><b>Proposed resolution:</b></p>
9229
9230     <p>Replace the first two sentences of paragraph 5 with:</p>
9231
9232     <blockquote>
9233     Extracts up to <i>N</i> characters from <i>is</i>. Stores these
9234     characters in a temporary object <i>str</i> of type
9235     <tt>basic_string&lt;charT, traits&gt;</tt>, then evaluates the
9236     expression <tt><i>x</i> = bitset&lt;N&gt;(<i>str</i>)</tt>.
9237     </blockquote>
9238
9239     <p>Replace the third bullet item in paragraph 5 with:</p>
9240     <ul><li>
9241     the next input character is neither <tt><i>is</i>.widen(0)</tt>
9242     nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
9243     is not extracted).
9244     </li></ul>
9245
9246 <p><b>Rationale:</b></p>
9247 <p>Input for <tt>bitset</tt> should work the same way as numeric
9248 input.  Using <tt>widen</tt> does mean that alternative digit
9249 representations will not be recognized, but this was a known
9250 consequence of the design choice.</p>
9251 <hr>
9252 <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.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.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;24 Jan 2001</p>
9253 <p>22.2.1.5/3 introduces codecvt in part with:</p>
9254
9255 <blockquote>
9256   codecvt&lt;wchar_t,char,mbstate_t&gt; converts between the native
9257   character sets for tiny and wide characters. Instantiations on
9258   mbstate_t perform conversion between encodings known to the library
9259   implementor.
9260 </blockquote>
9261
9262 <p>But 22.2.1.5.2/10 describes do_length in part with:</p>
9263
9264 <blockquote>
9265   ... codecvt&lt;wchar_t, char, mbstate_t&gt; ... return(s) the lesser of max and
9266   (from_end-from).
9267 </blockquote>
9268
9269 <p>
9270 The semantics of do_in and do_length are linked.  What one does must
9271 be consistent with what the other does.  22.2.1.5/3 leads me to
9272 believe that the vendor is allowed to choose the algorithm that
9273 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in performs so that it makes
9274 his customers happy on a given platform.  But 22.2.1.5.2/10 explicitly
9275 says what codecvt&lt;wchar_t,char,mbstate_t&gt;::do_length must
9276 return.  And thus indirectly specifies the algorithm that
9277 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in must perform.  I believe
9278 that this is not what was intended and is a defect.
9279 </p>
9280
9281 <p>Discussion from the -lib reflector:
9282
9283 <br>This proposal would have the effect of making the semantics of
9284 all of the virtual functions in <tt>codecvt&lt;wchar_t, char,
9285 mbstate_t&gt;</tt> implementation specified.  Is that what we want, or
9286 do we want to mandate specific behavior for the base class virtuals
9287 and leave the implementation specified behavior for the codecvt_byname
9288 derived class?  The tradeoff is that former allows implementors to
9289 write a base class that actually does something useful, while the
9290 latter gives users a way to get known and specified---albeit
9291 useless---behavior, and is consistent with the way the standard
9292 handles other facets.  It is not clear what the original intention
9293 was.</p>
9294
9295 <p>
9296 Nathan has suggest a compromise: a character that is a widened version
9297 of the characters in the basic execution character set must be
9298 converted to a one-byte sequence, but there is no such requirement
9299 for characters that are not part of the basic execution character set.
9300 </p>
9301 <p><b>Proposed resolution:</b></p>
9302 <p>
9303 Change 22.2.1.5.2/5 from:
9304 </p>
9305 <p>
9306 The instantiations required in Table 51 (lib.locale.category), namely
9307 codecvt&lt;wchar_t,char,mbstate_t&gt; and
9308 codecvt&lt;char,char,mbstate_t&gt;, store no characters. Stores no more
9309 than (to_limit-to) destination elements. It always leaves the to_next
9310 pointer pointing one beyond the last element successfully stored.
9311 </p>
9312 <p>
9313 to:
9314 </p>
9315 <p>
9316 Stores no more than (to_limit-to) destination elements, and leaves the
9317 to_next pointer pointing one beyond the last element successfully
9318 stored.  codecvt&lt;char,char,mbstate_t&gt; stores no characters.
9319 </p>
9320
9321 <p>Change 22.2.1.5.2/10 from:</p>
9322
9323 <blockquote>
9324 -10- Returns: (from_next-from) where from_next is the largest value in
9325 the range [from,from_end] such that the sequence of values in the
9326 range [from,from_next) represents max or fewer valid complete
9327 characters of type internT. The instantiations required in Table 51
9328 (21.1.1.1.1), namely codecvt&lt;wchar_t, char, mbstate_t&gt; and
9329 codecvt&lt;char, char, mbstate_t&gt;, return the lesser of max and
9330 (from_end-from).
9331 </blockquote>
9332
9333 <p>to:</p>
9334
9335 <blockquote>
9336 -10- Returns: (from_next-from) where from_next is the largest value in
9337 the range [from,from_end] such that the sequence of values in the range
9338 [from,from_next) represents max or fewer valid complete characters of
9339 type internT. The instantiation codecvt&lt;char, char, mbstate_t&gt; returns
9340 the lesser of max and (from_end-from).
9341 </blockquote>
9342
9343 <p><i>[Redmond: Nathan suggested an alternative resolution: same as
9344 above, but require that, in the default encoding, a character from the
9345 basic execution character set would map to a single external
9346 character.  The straw poll was 8-1 in favor of the proposed
9347 resolution.]</i></p>
9348
9349 <p><b>Rationale:</b></p>
9350 <p>The default encoding should be whatever users of a given platform
9351 would expect to be the most natural.  This varies from platform to
9352 platform.  In many cases there is a preexisting C library, and users
9353 would expect the default encoding to be whatever C uses in the default
9354 "C" locale.  We could impose a guarantee like the one Nathan suggested
9355 (a character from the basic execution character set must map to a
9356 single external character), but this would rule out important
9357 encodings that are in common use: it would rule out JIS, for
9358 example, and it would rule out a fixed-width encoding of UCS-4.</p>
9359
9360 <p><i>[Curaçao: fixed rationale typo at the request of Ichiro Koshida;
9361 "shift-JIS" changed to "JIS".]</i></p>
9362
9363 <hr>
9364 <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>
9365 <p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
9366
9367 <p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
9368 accepts a restricted set of <i>type</i> arguments in this
9369 International Standard. <i>type</i> shall be a POD structure or a POD
9370 union (clause 9). The result of applying the offsetof macro to a field
9371 that is a static data member or a function member is
9372 undefined."</p>
9373
9374 <p>For the POD requirement, it doesn't say "no diagnostic
9375 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.
9376 It's not clear whether this requirement was intended.  While it's
9377 possible to provide such a diagnostic, the extra complication doesn't
9378 seem to add any value.
9379 </p>
9380 <p><b>Proposed resolution:</b></p>
9381 <p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
9382 structure or a POD union the results are undefined."</p>
9383
9384 <p><i>[Copenhagen: straw poll was 7-4 in favor.  It was generally
9385 agreed that requiring a diagnostic was inadvertent, but some LWG
9386 members thought that diagnostics should be required whenever
9387 possible.]</i></p>
9388
9389 <hr>
9390 <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.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#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;13 Mar 2001</p>
9391
9392 <p>From reflector message c++std-lib-8330.  See also lib-8317.</p>
9393
9394 <p>
9395 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.priority.queue"> [lib.priority.queue]</a>
9396 paragraph 1 and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> paragraph 1.
9397 23.2.3.3/1, for example, says:
9398 </p>
9399
9400 <blockquote>
9401 -1- Any sequence supporting operations back(), push_back() and pop_back()
9402 can be used to instantiate stack. In particular, vector (lib.vector), list
9403 (lib.list) and deque (lib.deque) can be used.
9404 </blockquote>
9405
9406 <p>But this is false: vector&lt;bool&gt; can not be used, because the
9407 container adaptors return a T&amp; rather than using the underlying
9408 container's reference type.</p>
9409
9410 <p>This is a contradiction that can be fixed by:</p>
9411
9412 <ol>
9413 <li>Modifying these paragraphs to say that vector&lt;bool&gt;
9414     is an exception.</li>
9415 <li>Removing the vector&lt;bool&gt; specialization.</li>
9416 <li>Changing the return types of stack and priority_queue to use
9417     reference typedef's.</li>
9418 </ol>
9419
9420 <p>
9421 I propose 3.  This does not preclude option 2 if we choose to do it
9422 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
9423 3 offers a small step towards support for proxied containers.  This
9424 small step fixes a current contradiction, is easy for vendors to
9425 implement, is already implemented in at least one popular lib, and
9426 does not break any code.
9427 </p>
9428
9429 <p><b>Proposed resolution:</b></p>
9430 <p>Summary: Add reference and const_reference typedefs to queue,
9431 priority_queue and stack.  Change return types of "value_type&amp;" to
9432 "reference".  Change return types of "const value_type&amp;" to
9433 "const_reference".  Details:</p>
9434
9435 <p>Change 23.2.3.1/1 from:</p>
9436
9437 <pre>  namespace std {
9438     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9439     class queue {
9440     public:
9441       typedef typename Container::value_type            value_type;
9442       typedef typename Container::size_type             size_type;
9443       typedef          Container                        container_type;
9444     protected:
9445       Container c;
9446
9447     public:
9448       explicit queue(const Container&amp; = Container());
9449
9450       bool      empty() const             { return c.empty(); }
9451       size_type size()  const             { return c.size(); }
9452       value_type&amp;       front()           { return c.front(); }
9453       const value_type&amp; front() const     { return c.front(); }
9454       value_type&amp;       back()            { return c.back(); }
9455       const value_type&amp; back() const      { return c.back(); }
9456       void push(const value_type&amp; x)      { c.push_back(x); }
9457       void pop()                          { c.pop_front(); }
9458     };
9459 </pre>
9460
9461 <p>to:</p>
9462
9463 <pre>  namespace std {
9464     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9465     class queue {
9466     public:
9467       typedef typename Container::value_type            value_type;
9468       typedef typename Container::reference             reference;
9469       typedef typename Container::const_reference       const_reference;
9470       typedef typename Container::value_type            value_type;
9471       typedef typename Container::size_type             size_type;
9472       typedef          Container                        container_type;
9473     protected:
9474       Container c;
9475
9476     public:
9477       explicit queue(const Container&amp; = Container());
9478
9479       bool      empty() const             { return c.empty(); }
9480       size_type size()  const             { return c.size(); }
9481       reference         front()           { return c.front(); }
9482       const_reference   front() const     { return c.front(); }
9483       reference         back()            { return c.back(); }
9484       const_reference   back() const      { return c.back(); }
9485       void push(const value_type&amp; x)      { c.push_back(x); }
9486       void pop()                          { c.pop_front(); }
9487     };
9488 </pre>
9489
9490 <p>Change 23.2.3.2/1 from:</p>
9491
9492 <pre>  namespace std {
9493     template &lt;class T, class Container = vector&lt;T&gt;,
9494               class Compare = less&lt;typename Container::value_type&gt; &gt;
9495     class priority_queue {
9496     public:
9497       typedef typename Container::value_type            value_type;
9498       typedef typename Container::size_type             size_type;
9499       typedef          Container                        container_type;
9500     protected:
9501       Container c;
9502       Compare comp;
9503
9504     public:
9505       explicit priority_queue(const Compare&amp; x = Compare(),
9506                               const Container&amp; = Container());
9507       template &lt;class InputIterator&gt;
9508         priority_queue(InputIterator first, InputIterator last,
9509                        const Compare&amp; x = Compare(),
9510                        const Container&amp; = Container());
9511
9512       bool      empty() const       { return c.empty(); }
9513       size_type size()  const       { return c.size(); }
9514       const value_type&amp; top() const { return c.front(); }
9515       void push(const value_type&amp; x);
9516       void pop();
9517     };
9518                                   //  no equality is provided
9519   }
9520 </pre>
9521
9522 <p>to:</p>
9523
9524 <pre>  namespace std {
9525     template &lt;class T, class Container = vector&lt;T&gt;,
9526               class Compare = less&lt;typename Container::value_type&gt; &gt;
9527     class priority_queue {
9528     public:
9529       typedef typename Container::value_type            value_type;
9530       typedef typename Container::reference             reference;
9531       typedef typename Container::const_reference       const_reference;
9532       typedef typename Container::size_type             size_type;
9533       typedef          Container                        container_type;
9534     protected:
9535       Container c;
9536       Compare comp;
9537
9538     public:
9539       explicit priority_queue(const Compare&amp; x = Compare(),
9540                               const Container&amp; = Container());
9541       template &lt;class InputIterator&gt;
9542         priority_queue(InputIterator first, InputIterator last,
9543                        const Compare&amp; x = Compare(),
9544                        const Container&amp; = Container());
9545
9546       bool      empty() const       { return c.empty(); }
9547       size_type size()  const       { return c.size(); }
9548       const_reference   top() const { return c.front(); }
9549       void push(const value_type&amp; x);
9550       void pop();
9551     };
9552                                   //  no equality is provided
9553   }
9554 </pre>
9555
9556 <p>And change 23.2.3.3/1 from:</p>
9557
9558 <pre>  namespace std {
9559     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9560     class stack {
9561     public:
9562       typedef typename Container::value_type            value_type;
9563       typedef typename Container::size_type             size_type;
9564       typedef          Container                        container_type;
9565     protected:
9566       Container c;
9567
9568     public:
9569       explicit stack(const Container&amp; = Container());
9570
9571       bool      empty() const             { return c.empty(); }
9572       size_type size()  const             { return c.size(); }
9573       value_type&amp;       top()             { return c.back(); }
9574       const value_type&amp; top() const       { return c.back(); }
9575       void push(const value_type&amp; x)      { c.push_back(x); }
9576       void pop()                          { c.pop_back(); }
9577     };
9578
9579     template &lt;class T, class Container&gt;
9580       bool operator==(const stack&lt;T, Container&gt;&amp; x,
9581                       const stack&lt;T, Container&gt;&amp; y);
9582     template &lt;class T, class Container&gt;
9583       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
9584                       const stack&lt;T, Container&gt;&amp; y);
9585     template &lt;class T, class Container&gt;
9586       bool operator!=(const stack&lt;T, Container&gt;&amp; x,
9587                       const stack&lt;T, Container&gt;&amp; y);
9588     template &lt;class T, class Container&gt;
9589       bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
9590                       const stack&lt;T, Container&gt;&amp; y);
9591     template &lt;class T, class Container&gt;
9592       bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
9593                       const stack&lt;T, Container&gt;&amp; y);
9594     template &lt;class T, class Container&gt;
9595       bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
9596                       const stack&lt;T, Container&gt;&amp; y);
9597   }
9598 </pre>
9599
9600 <p>to:</p>
9601
9602 <pre>  namespace std {
9603     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9604     class stack {
9605     public:
9606       typedef typename Container::value_type            value_type;
9607       typedef typename Container::reference             reference;
9608       typedef typename Container::const_reference       const_reference;
9609       typedef typename Container::size_type             size_type;
9610       typedef          Container                        container_type;
9611     protected:
9612       Container c;
9613
9614     public:
9615       explicit stack(const Container&amp; = Container());
9616
9617       bool      empty() const             { return c.empty(); }
9618       size_type size()  const             { return c.size(); }
9619       reference         top()             { return c.back(); }
9620       const_reference   top() const       { return c.back(); }
9621       void push(const value_type&amp; x)      { c.push_back(x); }
9622       void pop()                          { c.pop_back(); }
9623     };
9624
9625     template &lt;class T, class Container&gt;
9626       bool operator==(const stack&lt;T, Container&gt;&amp; x,
9627                       const stack&lt;T, Container&gt;&amp; y);
9628     template &lt;class T, class Container&gt;
9629       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
9630                       const stack&lt;T, Container&gt;&amp; y);
9631     template &lt;class T, class Container&gt;
9632       bool operator!=(const stack&lt;T, Container&gt;&amp; x,
9633                       const stack&lt;T, Container&gt;&amp; y);
9634     template &lt;class T, class Container&gt;
9635       bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
9636                       const stack&lt;T, Container&gt;&amp; y);
9637     template &lt;class T, class Container&gt;
9638       bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
9639                       const stack&lt;T, Container&gt;&amp; y);
9640     template &lt;class T, class Container&gt;
9641       bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
9642                       const stack&lt;T, Container&gt;&amp; y);
9643   }
9644 </pre>
9645
9646 <p><i>[Copenhagen: This change was discussed before the IS was released
9647 and it was deliberately not adopted.  Nevertheless, the LWG believes
9648 (straw poll: 10-2) that it is a genuine defect.]</i></p>
9649
9650 <hr>
9651 <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>
9652 <p>
9653 Table 82 in section 27 mentions the header &lt;cstdlib&gt; for String
9654 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
9655 &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
9656 why these headers are mentioned in this context since they do not
9657 define any of the library entities described by the
9658 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
9659 are to be listed in the summary.
9660 </p>
9661 <p><b>Proposed resolution:</b></p>
9662 <p>Remove &lt;cstdlib&gt; and &lt;cwchar&gt; from
9663 Table 82.</p>
9664
9665 <p><i>[Copenhagen: changed the proposed resolution slightly.  The
9666 original proposed resolution also said to remove &lt;cstdio&gt; from
9667 Table 82.  However, &lt;cstdio&gt; is mentioned several times within
9668 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>
9669
9670 <hr>
9671 <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>
9672   <p>
9673   Exactly how should errno be declared in a conforming C++ header?
9674   </p>
9675
9676   <p>
9677   The C standard says in 7.1.4 that it is unspecified whether errno is a
9678   macro or an identifier with external linkage.  In some implementations
9679   it can be either, depending on compile-time options.  (E.g., on
9680   Solaris in multi-threading mode, errno is a macro that expands to a
9681   function call, but is an extern int otherwise.  "Unspecified" allows
9682   such variability.)
9683   </p>
9684
9685   <p>The C++ standard:</p>
9686   <ul>
9687   <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
9688   <li>17.4.3.1.3 footnote 166 says errno is reserved as an external
9689       name (true), and implies that it is an identifier.</li>
9690   <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
9691       on to say that the contents of of C++ &lt;errno.h&gt; are the
9692       same as in C, begging the question.</li>
9693   <li>C.2, table 95 lists errno as a macro, without comment.</li>
9694   </ul>
9695
9696   <p>I find no other references to errno.</p>
9697
9698   <p>We should either explicitly say that errno must be a macro, even
9699   though it need not be a macro in C, or else explicitly leave it
9700   unspecified.  We also need to say something about namespace std.
9701   A user who includes &lt;cerrno&gt; needs to know whether to write
9702   <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
9703   else &lt;cerrno&gt; is useless.</p>
9704
9705   <p>Two acceptable fixes:</p>
9706   <ul>
9707     <li><p>errno must be a macro. This is trivially satisfied by adding<br>
9708         &nbsp;&nbsp;#define errno (::std::errno)<br>
9709         to the headers if errno is not already a macro. You then always
9710         write errno without any scope qualification, and it always expands
9711         to a correct reference. Since it is always a macro, you know to
9712         avoid using errno as a local identifer.</p></li>
9713     <li><p>errno is in the global namespace. This fix is inferior, because
9714         ::errno is not guaranteed to be well-formed.</p></li>
9715   </ul>
9716
9717   <p><i>[
9718     This issue was first raised in 1999, but it slipped through
9719     the cracks.
9720   ]</i></p>
9721 <p><b>Proposed resolution:</b></p>
9722   <p>Change the Note in section 17.4.1.2p5 from</p>
9723
9724     <blockquote>
9725     Note: the names defined as macros in C include the following:
9726     assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
9727     </blockquote>
9728
9729   <p>to</p>
9730
9731     <blockquote>
9732     Note: the names defined as macros in C include the following:
9733     assert, offsetof, setjmp, va_arg, va_end, and va_start.
9734     </blockquote>
9735
9736   <p>In section 19.3, change paragraph 2 from</p>
9737
9738     <blockquote>
9739     The contents are the same as the Standard C library header
9740     &lt;errno.h&gt;.
9741     </blockquote>
9742
9743   <p>to</p>
9744
9745     <blockquote>
9746     The contents are the same as the Standard C library header
9747     &lt;errno.h&gt;, except that errno shall be defined as a macro.
9748     </blockquote>
9749 <p><b>Rationale:</b></p>
9750 <p>C++ must not leave it up to the implementation to decide whether or
9751 not a name is a macro; it must explicitly specify exactly which names
9752 are required to be macros.  The only one that really works is for it
9753 to be a macro.</p>
9754
9755 <p><i>[Curaçao: additional rationale added.]</i></p>
9756
9757 <hr>
9758 <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>
9759
9760 <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>
9761
9762 <pre>  // partial specializationss
9763   template&lt;class traits&gt;
9764     basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;( basic_ostream&lt;char,traits&gt;&amp;,
9765                                             const char * );
9766 </pre>
9767
9768 <p>Problems:</p>
9769 <ul>
9770 <li>Too many 's's at the end of "specializationss" </li>
9771 <li>This is an overload, not a partial specialization</li>
9772 </ul>
9773
9774 <p><b>Proposed resolution:</b></p>
9775 <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
9776 <i>// partial specializationss</i> comment.  Also remove the same
9777 comment (correctly spelled, but still incorrect) from the synopsis in
9778 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>.
9779 </p>
9780
9781 <p><i>[
9782 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
9783 comment in c++std-lib-8939.
9784 ]</i></p>
9785
9786 <hr>
9787 <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>
9788 <p>Table 27 in section 20 lists the header &lt;memory&gt; (only) for
9789 Memory (lib.memory) but neglects to mention the headers
9790 &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.c.malloc"> [lib.c.malloc]</a>.</p>
9791 <p><b>Proposed resolution:</b></p>
9792 <p>Add &lt;cstdlib&gt; and &lt;cstring&gt; to Table 27, in the same row
9793 as &lt;memory&gt;.</p>
9794 <hr>
9795 <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.list.ops"> [lib.list.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;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;1 May 2001</p>
9796 <p>
9797 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, Para 21 describes the complexity of
9798 list::unique as: "If the range (last - first) is not empty, exactly
9799 (last - first) -1 applications of the corresponding predicate,
9800 otherwise no applications of the predicate)".
9801 </p>
9802
9803 <p>
9804 "(last - first)" is not a range.
9805 </p>
9806 <p><b>Proposed resolution:</b></p>
9807 <p>
9808 Change the "range" from (last - first) to [first, last).
9809 </p>
9810 <hr>
9811 <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>
9812 <p>Table 69 says this about a_uniq.insert(t):</p>
9813
9814 <blockquote>
9815 inserts t if and only if there is no element in the container with key
9816 equivalent to the key of t. The bool component of the returned pair
9817 indicates whether the insertion takes place and the iterator component of the
9818 pair points to the element with key equivalent to the key of t.
9819 </blockquote>
9820
9821 <p>The description should be more specific about exactly how the bool component
9822 indicates whether the insertion takes place.</p>
9823 <p><b>Proposed resolution:</b></p>
9824 <p>Change the text in question to</p>
9825
9826 <blockquote>
9827 ...The bool component of the returned pair is true if and only if the insertion
9828 takes place...
9829 </blockquote>
9830 <hr>
9831 <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>
9832 <p>
9833 The localization section of the standard refers to specializations of
9834 the facet templates as instantiations even though the required facets
9835 are typically specialized rather than explicitly (or implicitly)
9836 instantiated. In the case of ctype&lt;char&gt; and
9837 ctype_byname&lt;char&gt; (and the wchar_t versions), these facets are
9838 actually required to be specialized. The terminology should be
9839 corrected to make it clear that the standard doesn't mandate explicit
9840 instantiation (the term specialization encompasses both explicit
9841 instantiations and specializations).
9842 </p>
9843 <p><b>Proposed resolution:</b></p>
9844 <p>
9845 In the following paragraphs, replace all occurrences of the word
9846 instantiation or instantiations with specialization or specializations,
9847 respectively:
9848 </p>
9849
9850 <blockquote>
9851 22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
9852 22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3,
9853 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
9854 Footnote 242.
9855 </blockquote>
9856
9857 <p>And change the text in 22.1.1.1.1, p4 from</p>
9858
9859 <blockquote>
9860     An implementation is required to provide those instantiations
9861     for facet templates identified as members of a category, and
9862     for those shown in Table 52:
9863 </blockquote>
9864
9865 <p>to</p>
9866
9867 <blockquote>
9868     An implementation is required to provide those specializations...
9869 </blockquote>
9870
9871 <p><i>[Nathan will review these changes, and will look for places where
9872 explicit specialization is necessary.]</i></p>
9873
9874 <p><b>Rationale:</b></p>
9875 <p>This is a simple matter of outdated language.  The language to
9876 describe templates was clarified during the standardization process,
9877 but the wording in clause 22 was never updated to reflect that
9878 change.</p>
9879 <hr>
9880 <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>
9881 <p>The definition of the numpunct_byname template contains the following
9882 comment:</p>
9883
9884 <pre>    namespace std {
9885         template &lt;class charT&gt;
9886         class numpunct_byname : public numpunct&lt;charT&gt; {
9887     // this class is specialized for char and wchar_t.
9888         ...
9889 </pre>
9890
9891 <p>There is no documentation of the specializations and it seems
9892 conceivable that an implementation will not explicitly specialize the
9893 template at all, but simply provide the primary template.</p>
9894 <p><b>Proposed resolution:</b></p>
9895 <p>Remove the comment from the text in 22.2.3.2 and from the proposed
9896 resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
9897 <hr>
9898 <a name="319"><h3>319.&nbsp;Storage allocation wording confuses "Required behavior", "Requires"</h3></a><p><b>Section:</b>&nbsp;18.4.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.4.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>
9899 <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
9900 behavior" elements describe "the semantics of a function definition
9901 provided by either the implementation or a C++ program."</p>
9902
9903 <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"
9904 elements describe "the preconditions for calling the function."</p>
9905
9906 <p>In the sections noted below, the current wording specifies
9907 "Required Behavior" for what are actually preconditions, and thus
9908 should be specified as "Requires".</p>
9909
9910 <p><b>Proposed resolution:</b></p>
9911
9912 <p>In 18.4.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>
9913 <blockquote>
9914   <p>Required behavior: accept a value of ptr that is null or that was
9915   returned by an earlier call ...</p>
9916 </blockquote>
9917 <p>to:</p>
9918 <blockquote>
9919   <p>Requires: the value of ptr is null or the value returned by an
9920   earlier call ...</p>
9921 </blockquote>
9922
9923 <p>In 18.4.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>
9924 <blockquote>
9925   <p>Required behavior: accept a value of ptr that is null or that was
9926   returned by an earlier call ...</p>
9927 </blockquote>
9928 <p>to:</p>
9929 <blockquote>
9930   <p>Requires: the value of ptr is null or the value returned by an
9931   earlier call ...</p>
9932 </blockquote>
9933
9934 <hr>
9935 <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.list.cons"> [lib.list.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>
9936 <p>
9937 Section 23.2.2.1, paragraphs 6-8 specify that list assign (both forms) have
9938 the "effects" of a call to erase followed by a call to insert.
9939 </p>
9940
9941 <p>
9942 I would like to document that implementers have the freedom to implement
9943 assign by other methods, as long as the end result is the same and the
9944 exception guarantee is as good or better than the basic guarantee.
9945 </p>
9946
9947 <p>
9948 The motivation for this is to use T's assignment operator to recycle
9949 existing nodes in the list instead of erasing them and reallocating
9950 them with new values.  It is also worth noting that, with careful
9951 coding, most common cases of assign (everything but assignment with
9952 true input iterators) can elevate the exception safety to strong if
9953 T's assignment has a nothrow guarantee (with no extra memory cost).
9954 Metrowerks does this.  However I do not propose that this subtlety be
9955 standardized.  It is a QoI issue.  </p>
9956
9957 <p>Existing practise:
9958 Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
9959 </p>
9960 <p><b>Proposed resolution:</b></p>
9961 <p>Change 23.2.2.1/7 from:</p>
9962
9963 <blockquote>
9964 <p>Effects:</p>
9965
9966 <pre>   erase(begin(), end());
9967    insert(begin(), first, last);
9968 </pre>
9969 </blockquote>
9970
9971 <p>to:</p>
9972
9973 <blockquote>
9974 <p>Effects: Replaces the contents of the list with the range [first, last).</p>
9975 </blockquote>
9976
9977 <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),
9978 add two new rows:</p>
9979 <pre>      a.assign(i,j)     void      pre: i,j are not iterators into a.
9980                                   Replaces elements in a with a copy
9981                                   of [i, j).
9982
9983       a.assign(n,t)     void      pre: t is not a reference into a.
9984                                   Replaces elements in a with n copies
9985                                   of t.
9986 </pre>
9987
9988 <p>Change 23.2.2.1/8 from:</p>
9989
9990 <blockquote>
9991 <p>Effects:</p>
9992 <pre>   erase(begin(), end());
9993    insert(begin(), n, t);
9994 </pre>
9995 </blockquote>
9996 <p>to:</p>
9997
9998 <blockquote>
9999 <p>Effects: Replaces the contents of the list with n copies of t.</p>
10000 </blockquote>
10001
10002 <p><i>[Redmond: Proposed resolution was changed slightly.  Previous
10003 version made explicit statement about exception safety, which wasn't
10004 consistent with the way exception safety is expressed elsewhere.
10005 Also, the change in the sequence requirements is new.  Without that
10006 change, the proposed resolution would have required that assignment of
10007 a subrange would have to work.  That too would have been
10008 overspecification; it would effectively mandate that assignment use a
10009 temporary.  Howard provided wording.
10010 ]</i></p>
10011
10012 <p><i>[Curaçao: Made editorial improvement in wording; changed
10013 "Replaces elements in a with copies of elements in [i, j)."
10014 with "Replaces the elements of a with a copy of [i, j)."
10015 Changes not deemed serious enough to requre rereview.]</i></p>
10016
10017 <hr>
10018 <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>
10019 <p>
10020 Section 22.2.2.1.2 at p7 states that "A length specifier is added to
10021 the conversion function, if needed, as indicated in Table 56."
10022 However, Table 56 uses the term "length modifier", not "length
10023 specifier".
10024 </p>
10025 <p><b>Proposed resolution:</b></p>
10026 <p>
10027 In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
10028 to be "A length modifier is added ..."
10029 </p>
10030 <p><b>Rationale:</b></p>
10031 <p>C uses the term "length modifier".  We should be consistent.</p>
10032 <hr>
10033 <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>
10034 <p>
10035 It's widely assumed that, if X is a container,
10036 iterator_traits&lt;X::iterator&gt;::value_type and
10037 iterator_traits&lt;X::const_iterator&gt;::value_type should both be
10038 X::value_type.  However, this is nowhere stated.  The language in
10039 Table 65 is not precise about the iterators' value types (it predates
10040 iterator_traits), and could even be interpreted as saying that
10041 iterator_traits&lt;X::const_iterator&gt;::value_type should be "const
10042 X::value_type".
10043 </p>
10044
10045 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a>.</p>
10046 <p><b>Proposed resolution:</b></p>
10047 <p>In Table 65 ("Container Requirements"), change the return type for
10048 X::iterator to "iterator type whose value type is T".  Change the
10049 return type for X::const_iterator to "constant iterator type whose
10050 value type is T".</p>
10051 <p><b>Rationale:</b></p>
10052 <p>
10053 This belongs as a container requirement, rather than an iterator
10054 requirement, because the whole notion of iterator/const_iterator
10055 pairs is specific to containers' iterator.
10056 </p>
10057 <p>
10058 It is existing practice that (for example)
10059 iterator_traits&lt;list&lt;int&gt;::const_iterator&gt;::value_type
10060 is "int", rather than "const int".  This is consistent with
10061 the way that const pointers are handled: the standard already
10062 requires that iterator_traits&lt;const int*&gt;::value_type is int.
10063 </p>
10064 <hr>
10065 <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>
10066
10067 <p>Table 73 suggests that output iterators have value types.  It
10068 requires the expression "*a = t".  Additionally, although Table 73
10069 never lists "a = t" or "X(a) = t" in the "expressions" column, it
10070 contains a note saying that "a = t" and "X(a) = t" have equivalent
10071 (but nowhere specified!) semantics.</p>
10072
10073 <p>According to 24.1/9, t is supposed to be "a value of value type
10074 T":</p>
10075
10076     <blockquote>
10077     In the following sections, a and b denote values of X, n denotes a
10078     value of the difference type Distance, u, tmp, and m denote
10079     identifiers, r denotes a value of X&amp;, t denotes a value of
10080     value type T.
10081     </blockquote>
10082
10083 <p>Two other parts of the standard that are relevant to whether
10084 output iterators have value types:</p>
10085
10086 <ul>
10087     <li>24.1/1 says "All iterators i support the expression *i,
10088     resulting in a value of some class, enumeration, or built-in type
10089     T, called the value type of the iterator".</li>
10090
10091     <li>
10092     24.3.1/1, which says "In the case of an output iterator, the types
10093     iterator_traits&lt;Iterator&gt;::difference_type
10094     iterator_traits&lt;Iterator&gt;::value_type are both defined as void."
10095     </li>
10096 </ul>
10097
10098 <p>The first of these passages suggests that "*i" is supposed to
10099 return a useful value, which contradicts the note in 24.1.2/2 saying
10100 that the only valid use of "*i" for output iterators is in an
10101 expression of the form "*i = t".  The second of these passages appears
10102 to contradict Table 73, because it suggests that "*i"'s return value
10103 should be void.  The second passage is also broken in the case of a an
10104 iterator type, like non-const pointers, that satisfies both the output
10105 iterator requirements and the forward iterator requirements.</p>
10106
10107 <p>What should the standard say about <tt>*i</tt>'s return value when
10108 i is an output iterator, and what should it say about that t is in the
10109 expression "*i = t"?  Finally, should the standard say anything about
10110 output iterators' pointer and reference types?</p>
10111
10112 <p><b>Proposed resolution:</b></p>
10113 <p>24.1 p1, change</p>
10114
10115 <blockquote>
10116 <p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
10117 in a value of some class, enumeration, or built-in type <tt>T</tt>,
10118 called the value type of the iterator.</p>
10119 </blockquote>
10120
10121 <p>to</p>
10122
10123 <blockquote>
10124 <p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
10125 resulting in a value of some class, enumeration, or built-in type
10126 <tt>T</tt>, called the value type of the iterator. All output
10127 iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
10128 value of some type that is in the set of types that are <i>writable</i> to
10129 the particular iterator type of <tt>i</tt>.
10130 </p>
10131 </blockquote>
10132
10133 <p>24.1 p9, add</p>
10134
10135 <blockquote>
10136 <p><tt>o</tt> denotes a value of some type that is writable to the
10137 output iterator.
10138 </p>
10139 </blockquote>
10140
10141 <p>Table 73, change</p>
10142
10143 <blockquote>
10144 <pre>*a = t
10145 </pre>
10146 </blockquote>
10147
10148 <p>to</p>
10149
10150 <blockquote>
10151 <pre>*r = o
10152 </pre>
10153 </blockquote>
10154
10155 <p>and change</p>
10156
10157 <blockquote>
10158 <pre>*r++ = t
10159 </pre>
10160 </blockquote>
10161
10162 <p>to</p>
10163
10164 <blockquote>
10165 <pre>*r++ = o
10166 </pre>
10167 </blockquote>
10168
10169 <p><i>[post-Redmond: Jeremy provided wording]</i></p>
10170
10171 <p><b>Rationale:</b></p>
10172 <p>The LWG considered two options: change all of the language that
10173 seems to imply that output iterators have value types, thus making it
10174 clear that output iterators have no value types, or else define value
10175 types for output iterator consistently.  The LWG chose the former
10176 option, because it seems clear that output iterators were never
10177 intended to have value types.  This was a deliberate design decision,
10178 and any language suggesting otherwise is simply a mistake.</p>
10179
10180 <p>A future revision of the standard may wish to revisit this design
10181 decision.</p>
10182 <hr>
10183 <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>
10184 <p>The Returns clause in 22.2.6.3.2, p3 says about
10185 moneypunct&lt;charT&gt;::do_grouping()
10186 </p>
10187
10188 <blockquote>
10189     Returns: A pattern defined identically as the result of
10190     numpunct&lt;charT&gt;::do_grouping().241)
10191 </blockquote>
10192
10193 <p>Footnote 241 then reads</p>
10194
10195 <blockquote>
10196     This is most commonly the value "\003" (not "3").
10197 </blockquote>
10198
10199 <p>
10200 The returns clause seems to imply that the two member functions must
10201 return an identical value which in reality may or may not be true,
10202 since the facets are usually implemented in terms of struct std::lconv
10203 and return the value of the grouping and mon_grouping, respectively.
10204 The footnote also implies that the member function of the moneypunct
10205 facet (rather than the overridden virtual functions in moneypunct_byname)
10206 most commonly return "\003", which contradicts the C standard which
10207 specifies the value of "" for the (most common) C locale.
10208 </p>
10209
10210 <p><b>Proposed resolution:</b></p>
10211 <p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>
10212
10213 <blockquote>
10214     Returns: A pattern defined identically as, but not necessarily
10215     equal to, the result of numpunct&lt;charT&gt;::do_grouping().241)
10216 </blockquote>
10217
10218 <p>and replace the text in Footnote 241 with the following:</p>
10219
10220 <blockquote>
10221     To specify grouping by 3s the value is "\003", not "3".
10222 </blockquote>
10223 <p><b>Rationale:</b></p>
10224 <p>
10225 The fundamental problem is that the description of the locale facet
10226 virtuals serves two purposes: describing the behavior of the base
10227 class, and describing the meaning of and constraints on the behavior
10228 in arbitrary derived classes.  The new wording makes that separation a
10229 little bit clearer.  The footnote (which is nonnormative) is not
10230 supposed to say what the grouping is in the "C" locale or in any other
10231 locale. It is just a reminder that the values are interpreted as small
10232 integers, not ASCII characters.
10233 </p>
10234 <hr>
10235 <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>
10236 <p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
10237 <tt>time_get_byname</tt> are listed incorrectly in table 52,
10238 required instantiations.  In both cases the second template
10239 parameter is given as OutputIterator.  It should instead be
10240 InputIterator, since these are input facets.</p>
10241 <p><b>Proposed resolution:</b></p>
10242 <p>
10243 In table 52, required instantiations, in
10244 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>
10245 <pre>    time_get&lt;wchar_t, OutputIterator&gt;
10246     time_get_byname&lt;wchar_t, OutputIterator&gt;
10247 </pre>
10248 <p>to</p>
10249 <pre>    time_get&lt;wchar_t, InputIterator&gt;
10250     time_get_byname&lt;wchar_t, InputIterator&gt;
10251 </pre>
10252
10253 <p><i>[Redmond: Very minor change in proposed resolution.  Original had
10254 a typo, wchart instead of wchar_t.]</i></p>
10255
10256 <hr>
10257 <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>
10258 <p>The sprintf format string , "%.01f" (that's the digit one), in the
10259 description of the do_put() member functions of the money_put facet in
10260 22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
10261 for values of type long double, and second, the precision of 01
10262 doesn't seem to make sense. What was most likely intended was
10263 "%.0Lf"., that is a precision of zero followed by the L length
10264 modifier.</p>
10265 <p><b>Proposed resolution:</b></p>
10266 <p>Change the format string to "%.0Lf".</p>
10267 <p><b>Rationale:</b></p>
10268 <p>Fixes an obvious typo</p>
10269 <hr>
10270 <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.vector.capacity"> [lib.vector.capacity]</a>, 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.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;Anthony Williams&nbsp; <b>Date:</b>&nbsp;13 Jul 2001</p>
10271 <p>
10272 There is an apparent contradiction about which circumstances can cause
10273 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.vector.capacity"> [lib.vector.capacity]</a> and
10274 section 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>.
10275 </p>
10276
10277 <p>23.2.4.2p5 says:</p>
10278 <blockquote>
10279 Notes: Reallocation invalidates all the references, pointers, and iterators
10280 referring to the elements in the sequence. It is guaranteed that no
10281 reallocation takes place during insertions that happen after a call to
10282 reserve() until the time when an insertion would make the size of the vector
10283 greater than the size specified in the most recent call to reserve().
10284 </blockquote>
10285
10286 <p>Which implies if I do</p>
10287
10288 <pre>  std::vector&lt;int&gt; vec;
10289   vec.reserve(23);
10290   vec.reserve(0);
10291   vec.insert(vec.end(),1);
10292 </pre>
10293
10294 <p>then the implementation may reallocate the vector for the insert,
10295 as the size specified in the previous call to reserve was zero.</p>
10296
10297 <p>However, the previous paragraphs (23.2.4.2, p1-2) state:</p>
10298 <blockquote>
10299 <p>
10300 (capacity) Returns: The total number of elements the vector
10301 can hold without requiring reallocation
10302 </p>
10303 <p>
10304 ...After reserve(), capacity() is greater or equal to the
10305 argument of reserve if reallocation happens; and equal to the previous value
10306 of capacity() otherwise...
10307 </p>
10308 </blockquote>
10309
10310 <p>
10311 This implies that vec.capacity() is still 23, and so the insert()
10312 should not require a reallocation, as vec.size() is 0. This is backed
10313 up by 23.2.4.3p1:
10314 </p>
10315 <blockquote>
10316 (insert) Notes: Causes reallocation if the new size is greater than the old
10317 capacity.
10318 </blockquote>
10319
10320 <p>
10321 Though this doesn't rule out reallocation if the new size is less
10322 than the old capacity, I think the intent is clear.
10323 </p>
10324
10325 <p><b>Proposed resolution:</b></p>
10326 <p>Change the wording of 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> paragraph 5 to:</p>
10327
10328 <blockquote>
10329 Notes: Reallocation invalidates all the references, pointers, and
10330 iterators referring to the elements in the sequence. It is guaranteed
10331 that no reallocation takes place during insertions that happen after a
10332 call to reserve() until the time when an insertion would make the size
10333 of the vector greater than the value of capacity().
10334 </blockquote>
10335
10336 <p><i>[Redmond: original proposed resolution was modified slightly.  In
10337 the original, the guarantee was that there would be no reallocation
10338 until the size would be greater than the value of capacity() after the
10339 most recent call to reserve().  The LWG did not believe that the
10340 "after the most recent call to reserve()" added any useful
10341 information.]</i></p>
10342
10343 <p><b>Rationale:</b></p>
10344 <p>There was general agreement that, when reserve() is called twice in
10345 succession and the argument to the second invocation is smaller than
10346 the argument to the first, the intent was for the second invocation to
10347 have no effect.  Wording implying that such cases have an effect on
10348 reallocation guarantees was inadvertant.</p>
10349 <hr>
10350 <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>
10351 <p>
10352 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
10353    "An implementation may strengthen the exception-specification for a
10354     non-virtual function by removing listed exceptions."
10355 (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>)
10356 and the following declaration of ~failure() in ios_base::failure
10357 </p>
10358 <pre>    namespace std {
10359        class ios_base::failure : public exception {
10360        public:
10361            ...
10362            virtual ~failure();
10363            ...
10364        };
10365      }
10366 </pre>
10367 <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.exception"> [lib.exception]</a> the destructor of class exception has an empty
10368 exception specification:</p>
10369 <pre>    namespace std {
10370        class exception {
10371        public:
10372          ...
10373          virtual ~exception() throw();
10374          ...
10375        };
10376      }
10377 </pre>
10378 <p><b>Proposed resolution:</b></p>
10379 <p>Remove the declaration of ~failure().</p>
10380 <p><b>Rationale:</b></p>
10381 <p>The proposed resolution is consistent with the way that destructors
10382 of other classes derived from <tt>exception</tt> are handled.</p>
10383 <hr>
10384 <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>
10385 <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>
10386 <blockquote>
10387     [Footnote: The effect of executing cout &lt;&lt; endl is to insert a
10388      newline character in the output sequence controlled by cout, then
10389      synchronize it with any external file with which it might be
10390      associated. --- end foonote]
10391 </blockquote>
10392
10393 <p>
10394 Does the term "file" here refer to the external device?
10395 This leads to some implementation ambiguity on systems with fully
10396 buffered files where a newline does not cause a flush to the device.
10397 </p>
10398
10399 <p>
10400 Choosing to sync with the device leads to significant performance
10401 penalties for each call to endl, while not sync-ing leads to
10402 errors under special circumstances.
10403 </p>
10404
10405 <p>
10406 I could not find any other statement that explicitly defined
10407 the behavior one way or the other.
10408 </p>
10409 <p><b>Proposed resolution:</b></p>
10410 <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>
10411 <p><b>Rationale:</b></p>
10412 <p>We already have normative text saying what <tt>endl</tt> does: it
10413 inserts a newline character and calls <tt>flush</tt>.  This footnote
10414 is at best redundant, at worst (as this issue says) misleading,
10415 because it appears to make promises about what <tt>flush</tt>
10416 does.</p>
10417 <hr>
10418 <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>
10419 <p>
10420 The current standard describes map::operator[] using a
10421 code example. That code example is however quite
10422 inefficient because it requires several useless copies
10423 of both the passed key_type value and of default
10424 constructed mapped_type instances.
10425 My opinion is that was not meant by the comitee to
10426 require all those temporary copies.
10427 </p>
10428
10429 <p>Currently map::operator[] behaviour is specified as: </p>
10430 <pre>  Returns:
10431     (*((insert(make_pair(x, T()))).first)).second.
10432 </pre>
10433
10434 <p>
10435 This specification however uses make_pair that is a
10436 template function of which parameters in this case
10437 will be deduced being of type const key_type&amp; and
10438 const T&amp;. This will create a pair&lt;key_type,T&gt; that
10439 isn't the correct type expected by map::insert so
10440 another copy will be required using the template
10441 conversion constructor available in pair to build
10442 the required pair&lt;const key_type,T&gt; instance.
10443 </p>
10444
10445 <p>If we consider calling of key_type copy constructor
10446 and mapped_type default constructor and copy
10447 constructor as observable behaviour (as I think we
10448 should) then the standard is in this place requiring
10449 two copies of a key_type element plus a default
10450 construction and two copy construction of a mapped_type
10451 (supposing the addressed element is already present
10452 in the map; otherwise at least another copy
10453 construction for each type).
10454 </p>
10455
10456 <p>A simple (half) solution would be replacing the description with:</p>
10457 <pre>  Returns:
10458     (*((insert(value_type(x, T()))).first)).second.
10459 </pre>
10460
10461 <p>This will remove the wrong typed pair construction that
10462 requires one extra copy of both key and value.</p>
10463
10464 <p>However still the using of map::insert requires temporary
10465 objects while the operation, from a logical point of view,
10466 doesn't require any. </p>
10467
10468 <p>I think that a better solution would be leaving free an
10469 implementer to use a different approach than map::insert
10470 that, because of its interface, forces default constructed
10471 temporaries and copies in this case.
10472 The best solution in my opinion would be just requiring
10473 map::operator[] to return a reference to the mapped_type
10474 part of the contained element creating a default element
10475 with the specified key if no such an element is already
10476 present in the container. Also a logarithmic complexity
10477 requirement should be specified for the operation.
10478 </p>
10479
10480 <p>
10481 This would allow library implementers to write alternative
10482 implementations not using map::insert and reaching optimal
10483 performance in both cases of the addressed element being
10484 present or absent from the map (no temporaries at all and
10485 just the creation of a new pair inside the container if
10486 the element isn't present).
10487 Some implementer has already taken this option but I think
10488 that the current wording of the standard rules that as
10489 non-conforming.
10490 </p>
10491
10492 <p><b>Proposed resolution:</b></p>
10493
10494 <p>
10495 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
10496 </p>
10497 <blockquote>
10498 <p>
10499 -1- Effects:  If there is no key equivalent to x in the map, inserts
10500 value_type(x, T()) into the map.
10501 </p>
10502 <p>
10503 -2- Returns: A reference to the mapped_type corresponding to x in *this.
10504 </p>
10505 <p>
10506 -3- Complexity: logarithmic.
10507 </p>
10508 </blockquote>
10509
10510 <p><i>[This is the second option mentioned above.  Howard provided
10511 wording.  We may also wish to have a blanket statement somewhere in
10512 clause 17 saying that we do not intend the semantics of sample code
10513 fragments to be interpreted as specifing exactly how many copies are
10514 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>
10515
10516 <p><b>Rationale:</b></p>
10517 <p>
10518 This is the second solution described above; as noted, it is
10519 consistent with existing practice.
10520 </p>
10521
10522 <p>Note that we now need to specify the complexity explicitly, because
10523 we are no longer defining <tt>operator[]</tt> in terms of
10524 <tt>insert</tt>.</p>
10525 <hr>
10526 <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>
10527 <p>
10528 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
10529 as:
10530 </p>
10531 <pre>  X::assign(c,d)   assigns c = d.
10532 </pre>
10533
10534 <p>And para 1 says:</p>
10535
10536 <blockquote>
10537  [...] c and d denote values of type CharT [...]
10538 </blockquote>
10539
10540 <p>
10541 Naturally, if c and d are <i>values</i>, then the assignment is
10542 (effectively) meaningless. It's clearly intended that (in the case of
10543 assign, at least), 'c' is intended to be a reference type.
10544 </p>
10545
10546 <p>I did a quick survey of the four implementations I happened to have
10547 lying around, and sure enough they all have signatures:</p>
10548 <pre>    assign( charT&amp;, const charT&amp; );
10549 </pre>
10550
10551 <p>(or the equivalent). It's also described this way in Nico's book.
10552 (Not to mention the synopses of char_traits&lt;char&gt; in 21.1.3.1
10553 and char_traits&lt;wchar_t&gt; in 21.1.3.2...)
10554 </p>
10555 <p><b>Proposed resolution:</b></p>
10556 <p>Add the following to 21.1.1 para 1:</p>
10557 <blockquote>
10558  r denotes an lvalue of CharT
10559 </blockquote>
10560
10561 <p>and change the description of assign in the table to:</p>
10562 <pre>  X::assign(r,d)   assigns r = d
10563 </pre>
10564 <hr>
10565 <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>
10566 <p>From c++std-edit-873:</p>
10567
10568 <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
10569 &lt;strstream&gt; is missing.</p>
10570
10571 <p>This shows a general problem: The whole clause 17 refers quite
10572 often to clauses 18 through 27, but D.7 is also a part of the standard
10573 library (though a deprecated one).</p>
10574
10575 <p><b>Proposed resolution:</b></p>
10576
10577 <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
10578 "&lt;strstream&gt;".</p>
10579
10580 <p>In the following places, change "clauses 17 through 27" to "clauses
10581 17 through 27 and Annex D":</p>
10582
10583 <ul>
10584 <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>
10585 <li>1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/intro.html#intro.defs"> [intro.defs]</a> Definitions/1</li>
10586 <li>7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/dcl.html#dcl.dcl"> [dcl.dcl]</a> Library introduction/9</li>
10587 <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>
10588 <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>
10589 <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>
10590 <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>
10591 <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>
10592 <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>
10593 <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>
10594 <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>
10595 <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>
10596 </ul>
10597
10598
10599 <hr>
10600 <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>
10601 <p>From c++std-edit-876:</p>
10602
10603 <p>
10604 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
10605 parameter of template replace_copy_if should be "InputIterator"
10606 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
10607 parameter name conveys real normative meaning.
10608 </p>
10609 <p><b>Proposed resolution:</b></p>
10610 <p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
10611 <hr>
10612 <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>
10613 <p>
10614 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
10615 original text or the text corrected by the proposed resolution of
10616 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
10617 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
10618 format for integer and floating point values, says that whitespace is
10619 optional between a plusminus and a sign.
10620 </p>
10621
10622 <p>
10623 The text needs to be clarified to either consistently allow or
10624 disallow whitespace between a plusminus and a sign. It might be
10625 worthwhile to consider the fact that the C library stdio facility does
10626 not permit whitespace embedded in numbers and neither does the C or
10627 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).
10628 </p>
10629 <p><b>Proposed resolution:</b></p>
10630 <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>
10631 <blockquote>
10632 <p>
10633 The syntax for number formats is as follows, where <tt>digit</tt>
10634 represents the radix set specified by the <tt>fmtflags</tt> argument
10635 value, <tt>whitespace</tt> is as determined by the facet
10636 <tt>ctype&lt;charT&gt;</tt> (22.2.1.1), and <tt>thousands-sep</tt> and
10637 <tt>decimal-point</tt> are the results of corresponding
10638 <tt>numpunct&lt;charT&gt;</tt> members.  Integer values have the
10639 format:
10640 </p>
10641 <pre>  integer   ::= [sign] units
10642   sign      ::= plusminus [whitespace]
10643   plusminus ::= '+' | '-'
10644   units     ::= digits [thousands-sep units]
10645   digits    ::= digit [digits]
10646 </pre>
10647 </blockquote>
10648 <p>to:</p>
10649 <blockquote>
10650 <p>
10651 The syntax for number formats is as follows, where <tt>digit</tt>
10652 represents the radix set specified by the <tt>fmtflags</tt> argument
10653 value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
10654 results of corresponding <tt>numpunct&lt;charT&gt;</tt> members.
10655 Integer values have the format:
10656 </p>
10657 <pre>  integer   ::= [sign] units
10658   sign      ::= plusminus
10659   plusminus ::= '+' | '-'
10660   units     ::= digits [thousands-sep units]
10661   digits    ::= digit [digits]
10662 </pre>
10663 </blockquote>
10664 <p><b>Rationale:</b></p>
10665 <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
10666 standard says how, or whether, it's used.  However, there's no reason
10667 for it to differ gratuitously from the very specific description of
10668 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
10669 resolution removes all mention of "whitespace" from that format.</p>
10670 <hr>
10671 <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>
10672 <p>
10673 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
10674 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
10675 clause 27, making the reference in 22.2.1 somewhat dubious.
10676 </p>
10677 <p><b>Proposed resolution:</b></p>
10678 <p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
10679     <blockquote>
10680     Several types defined in clause 27 are bitmask types. Each bitmask type
10681     can be implemented as an enumerated type that overloads certain operators,
10682     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>).
10683     </blockquote>
10684 <p>to read</p>
10685     <blockquote>
10686     Several types defined in clauses lib.language.support through
10687     lib.input.output and Annex D are bitmask types. Each bitmask type can
10688     be implemented as an enumerated type that overloads certain operators,
10689     as an integer  type, or as a bitset (lib.template.bitset).
10690     </blockquote>
10691
10692 <p>
10693 Additionally, change the definition in 22.2.1 to adopt the same
10694 convention as in clause 27 by replacing the existing text with the
10695 following (note, in particluar, the cross-reference to 17.3.2.1.2 in
10696 22.2.1, p1):
10697 </p>
10698
10699 <blockquote>
10700 <p>22.2.1 The ctype category [lib.category.ctype]</p>
10701 <pre>namespace std {
10702     class ctype_base {
10703     public:
10704         typedef <b><i>T</i></b> mask;
10705
10706         // numeric values are for exposition only.
10707         static const mask space = 1 &lt;&lt; 0;
10708         static const mask print = 1 &lt;&lt; 1;
10709         static const mask cntrl = 1 &lt;&lt; 2;
10710         static const mask upper = 1 &lt;&lt; 3;
10711         static const mask lower = 1 &lt;&lt; 4;
10712         static const mask alpha = 1 &lt;&lt; 5;
10713         static const mask digit = 1 &lt;&lt; 6;
10714         static const mask punct = 1 &lt;&lt; 7;
10715         static const mask xdigit = 1 &lt;&lt; 8;
10716         static const mask alnum = alpha | digit;
10717         static const mask graph = alnum | punct;
10718     };
10719 }
10720 </pre>
10721
10722 <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>
10723 </blockquote>
10724
10725 <p><i>[Curaçao: The LWG notes that T above should be bold-italics to be
10726 consistent with the rest of the standard.]</i></p>
10727
10728 <hr>
10729 <a name="340"><h3>340.&nbsp;interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt>
10730 </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>
10731 <p>
10732 It's unclear whether 22.1.1.1.1, p3 says that
10733 <tt>has_facet&lt;Facet&gt;(loc)</tt> returns true for any <tt>Facet</tt>
10734 from Table 51 or whether it includes Table 52 as well:
10735 </p>
10736
10737 <blockquote>
10738 For any locale <tt>loc</tt> either constructed, or returned by
10739 locale::classic(), and any facet <tt>Facet</tt> that is a member of a
10740 standard category, <tt>has_facet&lt;Facet&gt;(loc)</tt> is true. Each
10741 locale member function which takes a <tt>locale::category</tt>
10742 argument operates on the corresponding set of facets.
10743 </blockquote>
10744
10745 <p>
10746 It seems that it comes down to which facets are considered to be members of a
10747 standard category. Intuitively, I would classify all the facets in Table 52 as
10748 members of their respective standard categories, but there are an unbounded set
10749 of them...
10750 </p>
10751
10752 <p>
10753 The paragraph implies that, for instance, <tt>has_facet&lt;num_put&lt;C,
10754 OutputIterator&gt; &gt;(loc)</tt> must always return true. I don't think that's
10755 possible. If it were, then <tt>use_facet&lt;num_put&lt;C, OutputIterator&gt;
10756 &gt;(loc)</tt> would have to return a reference to a distinct object for each
10757 valid specialization of <tt>num_put&lt;C, OutputIteratory&gt;</tt>, which is
10758 clearly impossible.
10759 </p>
10760
10761 <p>
10762 On the other hand, if none of the facets in Table 52 is a member of a standard
10763 category then none of the locale member functions that operate on entire
10764 categories of facets will work properly.
10765 </p>
10766
10767 <p>
10768 It seems that what p3 should mention that it's required (permitted?)
10769 to hold only for specializations of <tt>Facet</tt> from Table 52 on
10770 <tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
10771 <tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
10772 {
10773 {i,o}<tt>streambuf_iterator</tt>&lt;{<tt>char</tt>,<tt>wchar_t</tt>}<tt>&gt;</tt>
10774 }.
10775 </p>
10776 <p><b>Proposed resolution:</b></p>
10777 <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
10778 "that is a member of a standard category" to "shown in Table 51".</p>
10779 <p><b>Rationale:</b></p>
10780 <p>The facets in Table 52 are an unbounded set.  Locales should not be
10781 required to contain an infinite number of facets.</p>
10782
10783 <p>It's not necessary to talk about which values of InputIterator and
10784 OutputIterator must be supported.  Table 51 already contains a
10785 complete list of the ones we need.</p>
10786 <hr>
10787 <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.vector.capacity"> [lib.vector.capacity]</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>
10788 <p>It is a common idiom to reduce the capacity of a vector by swapping it with
10789 an empty one:</p>
10790 <pre>  std::vector&lt;SomeType&gt; vec;
10791   // fill vec with data
10792   std::vector&lt;SomeType&gt;().swap(vec);
10793   // vec is now empty, with minimal capacity
10794 </pre>
10795
10796 <p>However, the wording of 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>paragraph 5 prevents
10797 the capacity of a vector being reduced, following a call to
10798 reserve(). This invalidates the idiom, as swap() is thus prevented
10799 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
10800 requires the temporary to be expanded to cater for the contents of
10801 vec, and the contents be copied across. This is a linear-time
10802 operation.</p>
10803
10804 <p>However, the container requirements state that swap must have constant
10805 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>
10806
10807 <p>This is an important issue, as reallocation affects the validity of
10808 references and iterators.</p>
10809
10810 <p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
10811 references and iterators remain valid after a call to swap, if they refer to
10812 an element before the new end() of the vector into which they originally
10813 pointed, in which case they refer to the element at the same index position.
10814 Iterators and references that referred to an element whose index position
10815 was beyond the new end of the vector are invalidated.</p>
10816
10817 <p>If the note to table 65 is taken as the desired intent, then there are two
10818 possibilities with regard to iterators and references:</p>
10819
10820 <ol>
10821 <li>All Iterators and references into both vectors are invalidated.</li>
10822 <li>Iterators and references into either vector remain valid, and remain
10823 pointing to the same element. Consequently iterators and references that
10824 referred to one vector now refer to the other, and vice-versa.</li>
10825 </ol>
10826 <p><b>Proposed resolution:</b></p>
10827 <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.vector.capacity"> [lib.vector.capacity]</a> paragraph 5:</p>
10828 <blockquote>
10829 <pre>  void swap(vector&lt;T,Allocator&gt;&amp; x);
10830 </pre>
10831 <p><b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
10832 with that of <tt>x</tt>.</p>
10833 <p><b>Complexity:</b> Constant time.</p>
10834 </blockquote>
10835
10836 <p><i>[This solves the problem reported for this issue.  We may also
10837 have a problem with a circular definition of swap() for other
10838 containers.]</i></p>
10839
10840 <p><b>Rationale:</b></p>
10841 <p>
10842 swap should be constant time.  The clear intent is that it should just
10843 do pointer twiddling, and that it should exchange all properties of
10844 the two vectors, including their reallocation guarantees.
10845 </p>
10846 <hr>
10847 <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>
10848 <p>
10849 C99, and presumably amendment 1 to C90, specify that &lt;wchar.h&gt;
10850 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
10851 &lt;cwchar&gt;. Is this omission intentional or accidental?
10852 </p>
10853 <p><b>Proposed resolution:</b></p>
10854 <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>
10855 <hr>
10856 <a name="346"><h3>346.&nbsp;Some iterator member functions should be const</h3></a><p><b>Section:</b>&nbsp;24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Jeremy Siek&nbsp; <b>Date:</b>&nbsp;20 Oct 2001</p>
10857 <p>Iterator member functions and operators that do not change the state
10858 of the iterator should be defined as const member functions or as
10859 functions that take iterators either by const reference or by
10860 value. The standard does not explicitly state which functions should
10861 be const.  Since this a fairly common mistake, the following changes
10862 are suggested to make this explicit.</p>
10863
10864 <p>The tables almost indicate constness properly through naming: r
10865 for non-const and a,b for const iterators. The following changes
10866 make this more explicit and also fix a couple problems.</p>
10867 <p><b>Proposed resolution:</b></p>
10868 <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
10869 "In the following sections, a and b denote values of X..." to
10870 "In the following sections, a and b denote values of type const X...".</p>
10871
10872 <p>In Table 73, change</p>
10873 <pre>    a-&gt;m   U&amp;         ...
10874 </pre>
10875
10876 <p>to</p>
10877
10878 <pre>    a-&gt;m   const U&amp;   ...
10879     r-&gt;m   U&amp;         ...
10880 </pre>
10881
10882 <p>In Table 73 expression column, change</p>
10883
10884 <pre>    *a = t
10885 </pre>
10886
10887 <p>to</p>
10888
10889 <pre>    *r = t
10890 </pre>
10891
10892 <p><i>[Redmond: The container requirements should be reviewed to see if
10893 the same problem appears there.]</i></p>
10894
10895 <hr>
10896 <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>
10897 <p>
10898 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
10899 are described as bitmask elements.  In fact, the bitmask requirements
10900 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>
10901 and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
10902
10903 <p>In particular, the requirements for <tt>none</tt> interact poorly
10904 with the requirement that the LC_* constants from the C library must
10905 be recognizable as C++ locale category constants.  LC_* values should
10906 not be mixed with these values to make category values.</p>
10907
10908 <p>We have two options for the proposed resolution.  Informally:
10909 option 1 removes the requirement that LC_* values be recognized as
10910 category arguments.  Option 2 changes the category type so that this
10911 requirement is implementable, by allowing <tt>none</tt> to be some
10912 value such as 0x1000 instead of 0.</p>
10913
10914 <p>Nathan writes: "I believe my proposed resolution [Option 2] merely
10915 re-expresses the status quo more clearly, without introducing any
10916 changes beyond resolving the DR.</p>
10917
10918 <p><b>Proposed resolution:</b></p>
10919 <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>
10920 <blockquote>
10921 <pre>    typedef int category;
10922 </pre>
10923
10924 <p>Valid category values include the <tt>locale</tt> member bitmask
10925 elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
10926 <tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
10927 represents a single locale category. In addition, <tt>locale</tt> member
10928 bitmask constant <tt>none</tt> is defined as zero and represents no
10929 category. And locale member bitmask constant <tt>all</tt> is defined such that
10930 the expression</p>
10931 <pre>    (collate | ctype | monetary | numeric | time | messages | all) == all
10932 </pre>
10933 <p>
10934 is <tt>true</tt>, and represents the union of all categories.  Further
10935 the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
10936 represent a single category, represents the union of the two
10937 categories.
10938 </p>
10939
10940 <p>
10941 <tt>locale</tt> member functions expecting a <tt>category</tt>
10942 argument require one of the <tt>category</tt> values defined above, or
10943 the union of two or more such values. Such a <tt>category</tt>
10944 argument identifies a set of locale categories. Each locale category,
10945 in turn, identifies a set of locale facets, including at least those
10946 shown in Table 51:
10947 </p>
10948 </blockquote>
10949 <p><i>[Curaçao: need input from locale experts.]</i></p>
10950
10951 <p><b>Rationale:</b></p>
10952
10953 <p>The LWG considered, and rejected, an alternate proposal (described
10954   as "Option 2" in the discussion).  The main reason for rejecting it
10955   was that library implementors were concerened about implementation
10956   difficult, given that getting a C++ library to work smoothly with a
10957   separately written C library is already a delicate business.  Some
10958   library implementers were also concerned about the issue of adding
10959   extra locale categories.</p>
10960
10961 <blockquote>
10962 <p><b>Option 2:</b> <br>
10963 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>
10964 <blockquote>
10965 <p>
10966 Valid category values include the enumerated values.  In addition, the
10967 result of applying commutative operators | and &amp; to any two valid
10968 values is valid, and results in the setwise union and intersection,
10969 respectively, of the argument categories.  The values <tt>all</tt> and
10970 <tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
10971 expressions <tt>(cat | all == all)</tt>, <tt>(cat &amp; all == cat)</tt>,
10972 <tt>(cat | none == cat)</tt> and <tt>(cat &amp; none == none)</tt> are
10973 true.  For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
10974 remaining enumerated values, <tt>(cat1 &amp; cat2 == none)</tt> is true.
10975 For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
10976 of <tt>(cat1 &amp; ~cat2)</tt> is valid, and equals the setwise union of
10977 those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
10978 [Footnote: it is not required that <tt>all</tt> equal the setwise union
10979 of the other enumerated values; implementations may add extra categories.]
10980 </p>
10981 </blockquote>
10982 </blockquote>
10983 <hr>
10984 <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>
10985 <p>24.5.2 [lib.ostream.iterator] states:</p>
10986 <pre>    [...]
10987
10988     private:
10989     // basic_ostream&lt;charT,traits&gt;* out_stream; exposition only
10990     // const char* delim; exposition only
10991 </pre>
10992
10993 <p>Whilst it's clearly marked "exposition only", I suspect 'delim'
10994 should be of type 'const charT*'.</p>
10995 <p><b>Proposed resolution:</b></p>
10996 <p>
10997 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
10998 <tt>const charT* delim</tt>.
10999 </p>
11000 <hr>
11001 <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>
11002 <p>
11003 <i>(1)</i>
11004 There are no requirements on the <tt>stateT</tt> template parameter of
11005 <tt>fpos</tt> listed in 27.4.3. The interface appears to require that
11006 the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
11007 and I think also DefaultConstructible (to implement the operations in
11008 Table 88).
11009 </p>
11010 <p>
11011 21.1.2, p3, however, only requires that
11012 <tt>char_traits&lt;charT&gt;::state_type</tt> meet the requirements of
11013 CopyConstructible types.
11014 </p>
11015 <p>
11016 <i>(2)</i>
11017 Additionally, the <tt>stateT</tt> template argument has no
11018 corresponding typedef in fpos which might make it difficult to use in
11019 generic code.
11020 </p>
11021 <p><b>Proposed resolution:</b></p>
11022 <p>
11023 Modify 21.1.2, p4 from
11024 </p>
11025 <p>
11026     Requires: <tt>state_type</tt> shall meet the requirements of
11027               CopyConstructible types (20.1.3).
11028 </p>
11029 <p>
11030     Requires: state_type shall meet the requirements of Assignable
11031               (23.1, p4), CopyConstructible (20.1.3), and
11032               DefaultConstructible  (20.1.4) types.
11033 </p>
11034
11035 <p><b>Rationale:</b></p>
11036 <p>The LWG feels this is two issues, as indicated above. The first is
11037 a defect---std::basic_fstream is unimplementable without these
11038 additional requirements---and the proposed resolution fixes it.  The
11039 second is questionable; who would use that typedef?  The class
11040 template fpos is used only in a very few places, all of which know the
11041 state type already.  Unless motivation is provided, the second should
11042 be considered NAD.</p>
11043 <hr>
11044 <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>
11045 <p>
11046 Discussions in the thread "Associative container lower/upper bound
11047 requirements" on comp.std.c++ suggests that there is a defect in the
11048 C++ standard, Table 69 of section 23.1.2, "Associative containers",
11049 [lib.associative.reqmts].  It currently says:</p>
11050
11051 <blockquote>
11052 <p>
11053 a.find(k): returns an iterator pointing to an element with the key equivalent to
11054 k, or a.end() if such an element is not found.
11055 </p>
11056
11057 <p>
11058 a.lower_bound(k): returns an iterator pointing to the first element with
11059 key not less than k.
11060 </p>
11061
11062 <p>
11063 a.upper_bound(k): returns an iterator pointing to the first element with
11064 key greater than k.
11065 </p>
11066 </blockquote>
11067
11068 <p>
11069 We have "or a.end() if such an element is not found" for
11070 <tt>find</tt>, but not for <tt>upper_bound</tt> or
11071 <tt>lower_bound</tt>.  As the text stands, one would be forced to
11072 insert a new element into the container and return an iterator to that
11073 in case the sought iterator does not exist, which does not seem to be
11074 the intention (and not possible with the "const" versions).
11075 </p>
11076 <p><b>Proposed resolution:</b></p>
11077
11078 <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
11079 to:</p>
11080
11081 <blockquote>
11082 <p>
11083 a.lower_bound(k): returns an iterator pointing to the first element with
11084 key not less than k, or a.end() if such an element is not found.
11085 </p>
11086
11087 <p>
11088 a.upper_bound(k): returns an iterator pointing to the first element with
11089 key greater than k, or a.end() if such an element is not found.
11090 </p>
11091 </blockquote>
11092
11093 <p><i>[Curaçao: LWG reviewed PR.]</i></p>
11094
11095 <hr>
11096 <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>
11097
11098 <p>Table 68 "Optional Sequence Operations" in 23.1.1/12
11099 specifies operational semantics for "a.back()" as
11100 "*--a.end()", which may be ill-formed <i>[because calling
11101 operator-- on a temporary (the return) of a built-in type is
11102 ill-formed]</i>, provided a.end() returns a simple pointer rvalue
11103 (this is almost always the case for std::vector::end(), for
11104 example). Thus, the specification is not only incorrect, it
11105 demonstrates a dangerous construct: "--a.end()" may
11106 successfully compile and run as intended, but after changing the type
11107 of the container or the mode of compilation it may produce
11108 compile-time error. </p>
11109
11110 <p><b>Proposed resolution:</b></p>
11111 <p>Change the specification in table 68 "Optional Sequence
11112 Operations" in 23.1.1/12 for "a.back()" from</p>
11113
11114
11115 <blockquote>
11116 *--a.end()
11117 </blockquote>
11118
11119 <p>to</p>
11120
11121 <blockquote>
11122   { iterator tmp = a.end(); --tmp; return *tmp; }
11123 </blockquote>
11124
11125 <p>and the specification for "a.pop_back()" from</p>
11126
11127 <blockquote>
11128 a.erase(--a.end())
11129 </blockquote>
11130
11131 <p>to</p>
11132
11133 <blockquote>
11134   { iterator tmp = a.end(); --tmp; a.erase(tmp); }
11135 </blockquote>
11136
11137 <p><i>[Curaçao: LWG changed PR from "{ X::iterator tmp =
11138 a.end(); return *--tmp; }" to "*a.rbegin()", and from
11139 "{ X::iterator tmp = a.end(); a.erase(--tmp); }" to
11140 "a.erase(rbegin())".]</i></p>
11141
11142 <p><i>[There is a second possible defect; table 68 "Optional
11143 Sequence Operations" in the "Operational Semantics"
11144 column uses operations present only in the "Reversible
11145 Container" requirements, yet there is no stated dependency
11146 between these separate requirements tables. Ask in Santa Cruz if the
11147 LWG would like a new issue opened.]</i></p>
11148
11149 <p><i>[Santa Cruz: the proposed resolution is even worse than what's in
11150   the current standard: erase is undefined for reverse iterator.  If
11151   we're going to make the change, we need to define a temporary and
11152   use operator--.  Additionally, we don't know how prevalent this is:
11153   do we need to make this change in more than one place?  Martin has
11154   volunteered to review the standard and see if this problem occurs
11155   elsewhere.]</i></p>
11156
11157 <p><i>[Oxford: Matt provided new wording to address the concerns raised
11158   in Santa Cruz.  It does not appear that this problem appears
11159   anywhere else in clauses 23 or 24.]</i></p>
11160
11161 <p><i>[Kona: In definition of operational semantics of back(), change
11162 "*tmp" to "return *tmp;"]</i></p>
11163
11164 <hr>
11165 <a name="358"><h3>358.&nbsp;interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt>
11166 </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>
11167 <p>
11168 I don't think <tt>thousands_sep</tt> is being treated correctly after
11169 decimal_point has been seen. Since grouping applies only to the
11170 integral part of the number, the first such occurrence should, IMO,
11171 terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
11172 and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
11173 interpreted in the fractional part of a number.)
11174 </p>
11175
11176 <p>
11177 The easiest change I can think of that resolves this issue would be
11178 something like below.
11179 </p>
11180 <p><b>Proposed resolution:</b></p>
11181 <p>
11182 Change the first sentence of 22.2.2.1.2, p9 from
11183 </p>
11184
11185 <blockquote>
11186     If discard is true then the position of the character is
11187     remembered, but the character is otherwise ignored. If it is not
11188     discarded, then a check is made to determine if c is allowed as
11189     the next character of an input field of the conversion specifier
11190     returned by stage 1. If so it is accumulated.
11191 </blockquote>
11192
11193 <p>to</p>
11194
11195 <blockquote>
11196     If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
11197     accumulated, then the position of the character is remembered, but
11198     the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
11199     already been accumulated, the character is discarded and Stage 2
11200      terminates. ...
11201 </blockquote>
11202
11203 <p><b>Rationale:</b></p>
11204 <p>We believe this reflects the intent of the Standard.  Thousands sep
11205   characters after the decimal point are not useful in any locale.
11206   Some formatting conventions do group digits that follow the decimal
11207   point, but they usually introduce a different grouping character
11208   instead of reusing the thousand sep character.  If we want to add
11209   support for such conventions, we need to do so explicitly.</p>
11210
11211 <hr>
11212 <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>
11213 <p>22.2.2.2.1, p1:</p>
11214
11215     <pre>    iter_type put (iter_type out, ios_base&amp; str, char_type fill,
11216                    bool val) const;
11217     ...
11218
11219     1   Returns: do_put (out, str, fill, val).
11220     </pre>
11221
11222 <p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
11223 however, 22.2.2.2.2, p23:</p>
11224
11225 <blockquote>
11226 <pre>iter_type put (iter_type out, ios_base&amp; str, char_type fill,
11227                bool val) const;
11228 </pre>
11229
11230
11231         Effects: If (str.flags() &amp; ios_base::boolalpha) == 0 then do
11232              out = do_put(out, str, fill, (int)val)
11233            Otherwise do
11234 <pre>             string_type s =
11235                  val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
11236                      : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
11237 </pre>
11238            and then insert the characters of s into out. <i>out</i>.
11239 </blockquote>
11240
11241 <p>
11242 This means that the bool overload of <tt>do_put()</tt> will never be called,
11243 which contradicts the first paragraph. Perhaps the declaration
11244 should read <tt>do_put()</tt>, and not <tt>put()</tt>?
11245 </p>
11246
11247 <p>
11248 Note also that there is no <b>Returns</b> clause for this function, which
11249 should probably be corrected, just as should the second occurrence
11250 of <i>"out."</i> in the text.
11251 </p>
11252
11253 <p>
11254 I think the least invasive change to fix it would be something like
11255 the following:
11256 </p>
11257 <p><b>Proposed resolution:</b></p>
11258 <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
11259   the <tt>bool</tt> overload.</p>
11260
11261 <p>
11262 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
11263 </p>
11264
11265 <blockquote>
11266      Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
11267      of the member function.
11268 </blockquote>
11269
11270 <blockquote>
11271     Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
11272     avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
11273     do_put (..., bool))</tt>
11274     like so:
11275 </blockquote>
11276
11277 <blockquote>
11278     23   <b>Returns</b>: If <tt>(str.flags() &amp;
11279          ios_base::boolalpha) == 0</tt> then
11280          <tt>do_put (out, str, fill, (long)val)</tt>
11281          Otherwise the function obtains a string <tt>s</tt> as if by
11282 <pre>             string_type s =
11283                 val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
11284                     : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
11285 </pre>
11286          and then inserts each character <tt>c</tt> of s into out via
11287            <tt>*out++ = c</tt>
11288          and returns <tt>out</tt>.
11289 </blockquote>
11290
11291 <p><b>Rationale:</b></p>
11292 <p>
11293 This fixes a couple of obvious typos, and also fixes what appears to
11294 be a requirement of gratuitous inefficiency.
11295 </p>
11296 <hr>
11297 <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>
11298 <p>
11299 22.1.1, p7 (copied below) allows iostream formatters and extractors
11300 to make assumptions about the values returned from facet members.
11301 However, such assumptions are apparently not guaranteed to hold
11302 in other cases (e.g., when the facet members are being called directly
11303 rather than as a result of iostream calls, or between successive
11304 calls to the same iostream functions with no interevening calls to
11305 <tt>imbue()</tt>, or even when the facet member functions are called
11306 from other member functions of other facets). This restriction
11307 prevents locale from being implemented efficiently.
11308 </p>
11309 <p><b>Proposed resolution:</b></p>
11310 <p>Change the first sentence in 22.1.1, p7 from</p>
11311 <blockquote>
11312     In successive calls to a locale facet member function during
11313     a call to an iostream inserter or extractor or a streambuf member
11314     function, the returned result shall be identical. [Note: This
11315     implies that such results may safely be reused without calling
11316     the locale facet member function again, and that member functions
11317     of iostream classes cannot safely call <tt>imbue()</tt>
11318     themselves, except as specified elsewhere. --end note]
11319 </blockquote>
11320
11321 <p>to</p>
11322
11323 <blockquote>
11324     In successive calls to a locale facet member function on a facet
11325     object installed in the same locale, the returned result shall be
11326     identical. ...
11327 </blockquote>
11328
11329 <p><b>Rationale:</b></p>
11330 <p>This change is reasonable becuase it clarifies the intent of this
11331   part of the standard.</p>
11332 <hr>
11333 <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>
11334 <p>
11335 The destructor of ios_base::failure should have an empty throw
11336 specification, because the destructor of its base class, exception, is
11337 declared in this way.
11338 </p>
11339 <p><b>Proposed resolution:</b></p>
11340 <p>Change the destructor to</p>
11341 <pre>  virtual ~failure() throw();
11342 </pre>
11343 <p><b>Rationale:</b></p>
11344 <p>Fixes an obvious glitch.  This is almost editorial.</p>
11345 <hr>
11346 <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>
11347 <p>
11348 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
11349 clause for seekoff.
11350 </p>
11351 <p><b>Proposed resolution:</b></p>
11352 <p>
11353 Make this paragraph, the Effects clause for setbuf, consistent in wording
11354 with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
11355 to indicate the purpose of setbuf:
11356 </p>
11357
11358 <p>Original text:</p>
11359
11360 <blockquote>
11361 1 Effects: Performs an operation that is defined separately for each
11362 class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
11363 </blockquote>
11364
11365 <p>Proposed text:</p>
11366
11367 <blockquote>
11368 1 Effects: Influences stream buffering in a way that is defined separately
11369 for each class derived from basic_streambuf in this clause
11370 (27.7.1.3, 27.8.1.4).
11371 </blockquote>
11372
11373 <p><b>Rationale:</b></p>
11374 <p>The LWG doesn't believe there is any normative difference between
11375   the existing wording and what's in the proposed resolution, but the
11376   change may make the intent clearer.</p>
11377 <hr>
11378 <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>
11379 <p>
11380 Some stream and streambuf member functions are declared non-const,
11381 even thought they appear only to report information rather than to
11382 change an object's logical state.  They should be declared const.  See
11383 document N1360 for details and rationale.
11384 </p>
11385
11386 <p>The list of member functions under discussion: <tt>in_avail</tt>,
11387 <tt>showmanyc</tt>, <tt>tellg</tt>, <tt>tellp</tt>, <tt>is_open</tt>.</p>
11388
11389 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a></p>
11390
11391 <p><b>Proposed resolution:</b></p>
11392 <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>
11393 <p>Replace</p>
11394 <pre>  bool is_open();
11395 </pre>
11396 <p>with</p>
11397 <pre>  bool is_open() const;
11398 </pre>
11399 <p><b>Rationale:</b></p>
11400 <p>Of the changes proposed in N1360, the only one that is safe is
11401 changing the filestreams' is_open to const.  The LWG believed that
11402 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
11403 member function, after all,is already const.</p>
11404
11405 <p>The other proposed changes are less safe, because some streambuf
11406 functions that appear merely to report a value do actually perform
11407 mutating operations.  It's not even clear that they should be
11408 considered "logically const", because streambuf has two interfaces, a
11409 public one and a protected one.  These functions may, and often do,
11410 change the state as exposed by the protected interface, even if the
11411 state exposed by the public interface is unchanged.</p>
11412
11413 <p>Note that implementers can make this change in a binary compatible
11414 way by providing both overloads; this would be a conforming extension.</p>
11415
11416 <hr>
11417 <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>
11418 <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
11419 with the following signature:</p>
11420
11421 <pre>  basic_istream&lt;charT,traits&gt;&amp; get(basic_streambuf&lt;char_type,traits&gt;&amp;
11422   sb);
11423 </pre>
11424
11425 <p>is incorrect. It reads</p>
11426
11427 <blockquote>
11428   Effects: Calls get(s,n,widen('\n'))
11429 </blockquote>
11430
11431 <p>which I believe should be:</p>
11432
11433 <blockquote>
11434   Effects: Calls get(sb,widen('\n'))
11435 </blockquote>
11436 <p><b>Proposed resolution:</b></p>
11437 <p>Change the <b>Effects</b> paragraph to:</p>
11438 <blockquote>
11439   Effects: Calls get(sb,this-&gt;widen('\n'))
11440 </blockquote>
11441
11442 <p><i>[Pre-Oxford: Minor correction from Howard: replaced 'widen'
11443       with 'this-&gt;widen'.]</i></p>
11444
11445 <p><b>Rationale:</b></p>
11446 <p>Fixes an obvious typo.</p>
11447 <hr>
11448 <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>
11449
11450 <p>
11451 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>
11452 (exception()&amp;badbit) != 0 is used in testing for rethrow, yet
11453 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.exception"> [lib.exception]</a> that has no return type. Should member function
11454 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?
11455 </p>
11456
11457 <p><b>Proposed resolution:</b></p>
11458 <p>
11459 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
11460 "(exception()&amp;badbit) != 0" to "(exceptions()&amp;badbit) != 0".
11461 </p>
11462 <p><b>Rationale:</b></p>
11463 <p>Fixes an obvious typo.</p>
11464 <hr>
11465 <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>
11466 <p>
11467 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
11468 14 all contain references to "basic_ios::" which should be
11469 "ios_base::".
11470 </p>
11471 <p><b>Proposed resolution:</b></p>
11472 <p>
11473 Change all references to "basic_ios" in Table 90, Table 91, and
11474 paragraph 14 to "ios_base".
11475 </p>
11476 <p><b>Rationale:</b></p>
11477 <p>Fixes an obvious typo.</p>
11478 <hr>
11479 <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>
11480 <p>
11481 The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
11482 </p>
11483 <pre>  charT do_widen (char c) const;
11484
11485   -11- Effects: Applies the simplest reasonable transformation from
11486        a char value or sequence of char values to the corresponding
11487        charT value or values. The only characters for which unique
11488        transformations are required are those in the basic source
11489        character set (2.2). For any named ctype category with a
11490        ctype&lt;charT&gt; facet ctw and valid ctype_base::mask value
11491        M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
11492 </pre>
11493 <p>
11494 Shouldn't the last sentence instead read
11495 </p>
11496 <pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
11497        and valid ctype_base::mask value M
11498        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
11499 </pre>
11500 <p>
11501 I.e., if the narrow character c is not a member of a class of
11502 characters then neither is the widened form of c. (To paraphrase
11503 footnote 224.)
11504 </p>
11505 <p><b>Proposed resolution:</b></p>
11506 <p>
11507 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
11508 following text:
11509 </p>
11510 <pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
11511        and valid ctype_base::mask value M,
11512        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
11513 </pre>
11514
11515 <p><i>[Kona: Minor edit. Added a comma after the <i>M</i> for clarity.]</i></p>
11516
11517 <p><b>Rationale:</b></p>
11518 <p>The LWG believes this is just a typo, and that this is the correct fix.</p>
11519 <hr>
11520 <a name="380"><h3>380.&nbsp;typos in codecvt tables 53 and 54</h3></a><p><b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.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>
11521 <p>
11522 Tables 53 and 54 in 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> are both titled "convert
11523 result values," when surely "do_in/do_out result values" must have
11524 been intended for Table 53 and "do_unshift result values" for Table
11525 54.
11526 </p>
11527 <p>
11528 Table 54, row 3 says that the meaning of partial is "more characters
11529 needed to be supplied to complete termination." The function is not
11530 supplied any characters, it is given a buffer which it fills with
11531 characters or, more precisely, destination elements (i.e., an escape
11532 sequence). So partial means that space for more than (to_limit - to)
11533 destination elements was needed to terminate a sequence given the
11534 value of state.
11535 </p>
11536 <p><b>Proposed resolution:</b></p>
11537 <p>
11538 Change the title of Table 53 to "do_in/do_out result values" and
11539 the title of Table 54 to "do_unshift result values."
11540 </p>
11541 <p>
11542 Change the text in Table 54, row 3 (the <b>partial</b> row), under the
11543 heading Meaning, to "space for more than (to_limit - to) destination
11544 elements was needed to terminate a sequence given the value of state."
11545 </p>
11546 <hr>
11547 <a name="381"><h3>381.&nbsp;detection of invalid mbstate_t in codecvt</h3></a><p><b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.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>
11548 <p>
11549 All but one codecvt member functions that take a state_type argument
11550 list as one of their preconditions that the state_type argument have
11551 a valid value. However, according to 22.2.1.5.2, p6,
11552 codecvt::do_unshift() is the only codecvt member that is supposed to
11553 return error if the state_type object is invalid.
11554 </p>
11555
11556 <p>
11557 It seems to me that the treatment of state_type by all codecvt member
11558 functions should be the same and the current requirements should be
11559 changed. Since the detection of invalid state_type values may be
11560 difficult in general or computationally expensive in some specific
11561 cases, I propose the following:
11562 </p>
11563 <p><b>Proposed resolution:</b></p>
11564 <p>
11565 Add a new paragraph before 22.2.1.5.2, p5, and after the function
11566 declaration below
11567 </p>
11568 <pre>    result do_unshift(stateT&amp; state,
11569     externT* to, externT* to_limit, externT*&amp; to_next) const;
11570 </pre>
11571 <p>
11572 as follows:
11573 </p>
11574 <pre>    Requires: (to &lt;= to_end) well defined and true; state initialized,
11575     if at the beginning of a sequence, or else equal to the result of
11576     converting the preceding characters in the sequence.
11577 </pre>
11578 <p>
11579 and change the text in Table 54, row 4, the <b>error</b> row, under
11580 the heading Meaning, from
11581 </p>
11582 <pre>    state has invalid value
11583 </pre>
11584 <p>
11585 to
11586 </p>
11587 <pre>    an unspecified error has occurred
11588 </pre>
11589 <p><b>Rationale:</b></p>
11590 <p>The intent is that implementations should not be required to detect
11591 invalid state values; such a requirement appears nowhere else.  An
11592 invalid state value is a precondition violation, <i>i.e.</i> undefined
11593 behavior.  Implementations that do choose to detect invalid state
11594 values, or that choose to detect any other kind of error, may return
11595 <b>error</b> as an indication.</p>
11596 <hr>
11597 <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>
11598 <p>
11599 Following a discussion on the boost list regarding end iterators and
11600 the possibility of performing operator--() on them, it seems to me
11601 that there is a typo in the standard.  This typo has nothing to do
11602 with that discussion.
11603 </p>
11604
11605 <p>
11606 I have checked this newsgroup, as well as attempted a search of the
11607 Active/Defect/Closed Issues List on the site for the words "s is
11608 derefer" so I believe this has not been proposed before.  Furthermore,
11609 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
11610 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.
11611 </p>
11612
11613 <p>
11614 The standard makes the following assertion on bidirectional iterators,
11615 in section 24.1.4 [lib.bidirectional.iterators], Table 75:
11616 </p>
11617
11618 <pre>                         operational  assertion/note
11619 expression  return type   semantics    pre/post-condition
11620
11621 --r          X&amp;                        pre: there exists s such
11622                                        that r == ++s.
11623                                        post: s is dereferenceable.
11624                                        --(++r) == r.
11625                                        --r == --s implies r == s.
11626                                        &amp;r == &amp;--r.
11627 </pre>
11628
11629 <p>
11630 (See <a href="http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763">http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763</a>.)
11631 </p>
11632
11633 <p>
11634 In particular, "s is dereferenceable" seems to be in error.  It seems
11635 that the intention was to say "r is dereferenceable".
11636 </p>
11637
11638 <p>
11639 If it were to say "r is dereferenceable" it would
11640 make perfect sense.  Since s must be dereferenceable prior to
11641 operator++, then the natural result of operator-- (to undo operator++)
11642 would be to make r dereferenceable.  Furthermore, without other
11643 assertions, and basing only on precondition and postconditions, we
11644 could not otherwise know this.  So it is also interesting information.
11645 </p>
11646
11647 <p><b>Proposed resolution:</b></p>
11648 <p>
11649 Change the guarantee to "postcondition: r is dereferenceable."
11650 </p>
11651 <p><b>Rationale:</b></p>
11652 <p>Fixes an obvious typo</p>
11653 <hr>
11654 <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.opindex"> [lib.reverse.iter.opindex]</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>
11655 <p>In 24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a>, <tt>reverse_iterator&lt;&gt;::operator[]</tt>
11656 is specified as having a return type of <tt>reverse_iterator::reference</tt>,
11657 which is the same as <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.
11658 (Where <tt>Iterator</tt> is the underlying iterator type.)</p>
11659
11660 <p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't
11661   necessarily have a return type
11662   of <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.   Its
11663   return type is merely required to be convertible
11664   to <tt>Iterator</tt>'s value type.  The return type specified for
11665   reverse_iterator's operator[] would thus appear to be impossible.</p>
11666
11667 <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
11668   <tt>a[n]</tt> will continue to be required (for random access
11669   iterators) to be convertible to the value type, and also <tt>a[n] =
11670   t</tt> will be a valid expression.  Implementations of
11671   <tt>reverse_iterator</tt> will likely need to return a proxy from
11672   <tt>operator[]</tt> to meet these requirements. As mentioned in the
11673   comment from Dave Abrahams, the simplest way to specify that
11674   <tt>reverse_iterator</tt> meet this requirement to just mandate
11675   it and leave the return type of <tt>operator[]</tt> unspecified.</p>
11676
11677 <p><b>Proposed resolution:</b></p>
11678
11679 <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>
11680
11681 <blockquote>
11682 <pre>reference operator[](difference_type n) const;
11683 </pre>
11684 </blockquote>
11685
11686 <p>to:</p>
11687
11688 <blockquote>
11689 <pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see <font color="red">lib.random.access.iterators</font>
11690 </pre>
11691 </blockquote>
11692
11693
11694
11695
11696 <p><i>[
11697 Comments from Dave Abrahams: IMO we should resolve 386 by just saying
11698     that the return type of reverse_iterator's operator[] is
11699     unspecified, allowing the random access iterator requirements to
11700     impose an appropriate return type.  If we accept 299's proposed
11701     resolution (and I think we should), the return type will be
11702     readable and writable, which is about as good as we can do.
11703 ]</i></p>
11704 <hr>
11705 <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.template.valarray"> [lib.template.valarray]</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>
11706 <p>Consider the following program:</p>
11707 <pre>    #include &lt;iostream&gt;
11708     #include &lt;ostream&gt;
11709     #include &lt;vector&gt;
11710     #include &lt;valarray&gt;
11711     #include &lt;algorithm&gt;
11712     #include &lt;iterator&gt;
11713     template&lt;typename Array&gt;
11714     void print(const Array&amp; a)
11715     {
11716     using namespace std;
11717     typedef typename Array::value_type T;
11718     copy(&amp;a[0], &amp;a[0] + a.size(),
11719     ostream_iterator&lt;T&gt;(std::cout, " "));
11720     }
11721     template&lt;typename T, unsigned N&gt;
11722     unsigned size(T(&amp;)[N]) { return N; }
11723     int main()
11724     {
11725     double array[] = { 0.89, 9.3, 7, 6.23 };
11726     std::vector&lt;double&gt; v(array, array + size(array));
11727     std::valarray&lt;double&gt; w(array, size(array));
11728     print(v); // #1
11729     std::cout &lt;&lt; std::endl;
11730     print(w); // #2
11731     std::cout &lt;&lt; std::endl;
11732     }
11733 </pre>
11734
11735 <p>While the call numbered #1 succeeds, the call numbered #2 fails
11736 because the const version of the member function
11737 valarray&lt;T&gt;::operator[](size_t) returns a value instead of a
11738 const-reference. That seems to be so for no apparent reason, no
11739 benefit. Not only does that defeats users' expectation but it also
11740 does hinder existing software (written either in C or Fortran)
11741 integration within programs written in C++.  There is no reason why
11742 subscripting an expression of type valarray&lt;T&gt; that is const-qualified
11743 should not return a const T&amp;.</p>
11744 <p><b>Proposed resolution:</b></p>
11745 <p>In the class synopsis in 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a>, and in
11746 26.3.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a> just above paragraph 1, change</p>
11747 <pre>  T operator[](size_t const);
11748 </pre>
11749 <p>to</p>
11750 <pre>  const T&amp; operator[](size_t const);
11751 </pre>
11752
11753 <p><i>[Kona: fixed a minor typo: put semicolon at the end of the line
11754   wehre it belongs.]</i></p>
11755
11756 <p><b>Rationale:</b></p>
11757 <p>Return by value seems to serve no purpose.  Valaray was explicitly
11758 designed to have a specified layout so that it could easily be
11759 integrated with libraries in other languages, and return by value
11760 defeats that purpose.  It is believed that this change will have no
11761 impact on allowable optimizations.</p>
11762 <hr>
11763 <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>
11764 <p>
11765 The specifications of toupper and tolower both specify the functions as
11766 const, althought they are not member functions, and are not specified as
11767 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>.
11768 </p>
11769 <p><b>Proposed resolution:</b></p>
11770 <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
11771   declarations of std::toupper and std::tolower</p>
11772 <p><b>Rationale:</b></p>
11773 <p>Fixes an obvious typo</p>
11774 <hr>
11775 <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.c.math"> [lib.c.math]</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>
11776 <p>
11777 In 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a>, the C++ standard refers to the C standard for the
11778 definition of rand(); in the C standard, it is written that "The
11779 implementation shall behave as if no library function calls the rand
11780 function."
11781 </p>
11782
11783 <p>
11784 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
11785 how the two parameter version of the function generates its random
11786 value.  I believe that all current implementations in fact call rand()
11787 (in contradiction with the requirement avove); if an implementation does
11788 not call rand(), there is the question of how whatever random generator
11789 it does use is seeded.  Something is missing.
11790 </p>
11791
11792 <p><b>Proposed resolution:</b></p>
11793 <p>
11794 In [lib.c.math], add a paragraph specifying that the C definition of
11795 rand shal be modified to say that "Unless otherwise specified, the
11796 implementation shall behave as if no library function calls the rand
11797 function."
11798 </p>
11799
11800 <p>
11801 In [lib.alg.random.shuffle], add a sentence to the effect that "In
11802 the two argument form of the function, the underlying source of
11803 random numbers is implementation defined. [Note: in particular, an
11804 implementation is permitted to use <tt>rand</tt>.]
11805 </p>
11806 <p><b>Rationale:</b></p>
11807 <p>The original proposed resolution proposed requiring the
11808   two-argument from of <tt>random_shuffle</tt> to
11809   use <tt>rand</tt>. We don't want to do that, because some existing
11810   implementations already use something else: gcc
11811   uses <tt>lrand48</tt>, for example.  Using <tt>rand</tt> presents a
11812   problem if the number of elements in the sequence is greater than
11813   RAND_MAX.</p>
11814 <hr>
11815 <a name="400"><h3>400.&nbsp;redundant type cast in lib.allocator.members</h3></a><p><b>Section:</b>&nbsp;20.4.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>
11816 <p>
11817 20.4.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
11818 the following 3 lines:
11819 </p>
11820
11821 <pre>  12 Returns: new((void *) p) T( val)
11822      void destroy(pointer p);
11823   13 Returns: ((T*) p)-&gt;~T()
11824 </pre>
11825
11826 <p>
11827 The type cast "(T*) p" in the last line is redundant cause
11828 we know that std::allocator&lt;T&gt;::pointer is a typedef for T*.
11829 </p>
11830 <p><b>Proposed resolution:</b></p>
11831 <p>
11832 Replace "((T*) p)" with "p".
11833 </p>
11834 <p><b>Rationale:</b></p>
11835 <p>Just a typo, this is really editorial.</p>
11836 <hr>
11837 <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.allocator.requirements"> [lib.allocator.requirements]</a>, 20.4.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>
11838 <p>
11839 This applies to the new expression that is contained in both par12 of
11840 20.4.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.allocator.requirements"> [lib.allocator.requirements]</a>.
11841 I think this new expression is wrong, involving unintended side
11842 effects.
11843 </p>
11844
11845
11846 <p>20.4.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>
11847
11848 <pre>  11 Returns: the largest value N for which the call allocate(N,0) might succeed.
11849      void construct(pointer p, const_reference val);
11850   12 Returns: new((void *) p) T( val)
11851 </pre>
11852
11853
11854 <p>20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> in table 32 has the following line:</p>
11855 <pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
11856 </pre>
11857
11858 <p>
11859 .... with the prerequisits coming from the preceding two paragraphs,
11860 especially from table 31:
11861 </p>
11862
11863 <pre>  alloc&lt;T&gt;             a     ;// an allocator for T
11864   alloc&lt;T&gt;::pointer    p     ;// random access iterator
11865                               // (may be different from T*)
11866   alloc&lt;T&gt;::reference  r = *p;// T&amp;
11867   T const&amp;             t     ;
11868 </pre>
11869
11870 <p>
11871 Cause of using "new" but not "::new", any existing "T::operator new"
11872 function will hide the global placement new function. When there is no
11873 "T::operator new" with adequate signature,
11874 every_alloc&lt;T&gt;::construct(..) is ill-formed, and most
11875 std::container&lt;T,every_alloc&lt;T&gt;&gt; use it; a workaround
11876 would be adding placement new and delete functions with adequate
11877 signature and semantic to class T, but class T might come from another
11878 party. Maybe even worse is the case when T has placement new and
11879 delete functions with adequate signature but with "unknown" semantic:
11880 I dont like to speculate about it, but whoever implements
11881 any_container&lt;T,any_alloc&gt; and wants to use construct(..)
11882 probably must think about it.
11883 </p>
11884 <p><b>Proposed resolution:</b></p>
11885 <p>
11886 Replace "new" with "::new" in both cases.
11887 </p>
11888 <hr>
11889 <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>
11890
11891 <p>
11892 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
11893 basic_string "conforms to the requirements of a Sequence, as specified
11894 in (23.1.1)." The sequence requirements specified in (23.1.1) to not
11895 include any prohibition on swap members throwing exceptions.
11896 </p>
11897
11898 <p>
11899 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
11900 which exceptions may be thrown, but applies only to "all container
11901 types defined in this clause" and so excludes basic_string::swap
11902 because it is defined elsewhere.
11903 </p>
11904
11905 <p>
11906 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
11907 permits basic_string::swap to invalidates iterators, which is
11908 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
11909 be contradictory if it were read or extended to read as having
11910 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.
11911 </p>
11912
11913 <p>
11914 Yet several LWG members have expressed the belief that the original
11915 intent was that basic_string::swap should not throw exceptions as
11916 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
11917 unclear on this issue. The complexity of basic_string::swap is
11918 specified as "constant time", indicating the intent was to avoid
11919 copying (which could cause a bad_alloc or other exception). An
11920 important use of swap is to ensure that exceptions are not thrown in
11921 exception-safe code.
11922 </p>
11923
11924 <p>
11925 Note: There remains long standing concern over whether or not it is
11926 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
11927 requirements when allocators are unequal. The specification of
11928 basic_string::swap exception requirements is in no way intended to
11929 address, prejudice, or otherwise impact that concern.
11930 </p>
11931
11932
11933
11934
11935
11936 <p><b>Proposed resolution:</b></p>
11937 <p>
11938 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:
11939 </p>
11940
11941 <p>
11942 Throws: Shall not throw exceptions.
11943 </p>
11944 <hr>
11945 <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.4.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>
11946 <p>
11947 The eight basic dynamic memory allocation functions (single-object
11948 and array versions of ::operator new and ::operator delete, in the
11949 ordinary and nothrow forms) are replaceable.  A C++ program may
11950 provide an alternative definition for any of them, which will be used
11951 in preference to the implementation's definition.
11952 </p>
11953
11954 <p>
11955 Three different parts of the standard mention requirements on
11956 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.4.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>
11957 and 18.4.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>.
11958 </p>
11959
11960 <p>None of these three places say whether a replacement function may
11961   be declared inline.  18.4.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
11962   signature for the replacement function, but that's not enough:
11963   the <tt>inline</tt> specifier is not part of a function's signature.
11964   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
11965   requires that "an inline function shall be defined in every
11966   translation unit in which it is used," but this may not be quite
11967   specific enough either.  We should either explicitly allow or
11968   explicitly forbid inline replacement memory allocation
11969   functions.</p>
11970 <p><b>Proposed resolution:</b></p>
11971 <p>
11972 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:
11973 "The program's definitions shall not be specified as <tt>inline</tt>.
11974 No diagnostic is required."
11975 </p>
11976
11977 <p><i>[Kona: added "no diagnostic is required"]</i></p>
11978
11979 <p><b>Rationale:</b></p>
11980 <p>
11981 The fact that <tt>inline</tt> isn't mentioned appears to have been
11982 nothing more than an oversight.  Existing implementations do not
11983 permit inline functions as replacement memory allocation functions.
11984 Providing this functionality would be difficult in some cases, and is
11985 believed to be of limited value.
11986 </p>
11987 <hr>
11988 <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>
11989 <p>
11990 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
11991 standard library. Paragraph 4 does not list any restrictions on qsort,
11992 but it should limit the base parameter to point to POD.  Presumably,
11993 qsort sorts the array by copying bytes, which requires POD.
11994 </p>
11995 <p><b>Proposed resolution:</b></p>
11996 <p>
11997 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
11998 before the nonnormative note, add these words: "both of which have the
11999 same behavior as the original declaration.  The behavior is undefined
12000 unless the objects in the array pointed to by <i>base</i> are of POD
12001 type."
12002 </p>
12003
12004 <p><i>[Something along these lines is clearly necessary.  Matt
12005   provided wording.]</i></p>
12006 <hr>
12007 <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.vector.modifiers"> [lib.vector.modifiers]</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>
12008 <p>
12009 There is a possible defect in the standard: the standard text was
12010 never intended to prevent arbitrary ForwardIterators, whose operations
12011 may throw exceptions, from being passed, and it also wasn't intended
12012 to require a temporary buffer in the case where ForwardIterators were
12013 passed (and I think most implementations don't use one).  As is, the
12014 standard appears to impose requirements that aren't met by any
12015 existing implementation.
12016 </p>
12017 <p><b>Proposed resolution:</b></p>
12018 <p>Replace 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> paragraph 1 with:</p>
12019 <blockquote>
12020   1- Notes: Causes reallocation if the new size is greater than the
12021   old capacity. If no reallocation happens, all the iterators and
12022   references before the insertion point remain valid. If an exception
12023   is thrown other than by the copy constructor or assignment operator
12024   of T or by any InputIterator operation there are no effects.
12025 </blockquote>
12026
12027 <p><i>[We probably need to say something similar for deque.]</i></p>
12028
12029 <hr>
12030 <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>
12031 <p>
12032 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
12033 that is defined for a singular iterator is "an assignment of a
12034 non-singular value to an iterator that holds a singular value".  This
12035 means that destroying a singular iterator (e.g. letting an automatic
12036 variable go out of scope) is technically undefined behavior.  This
12037 seems overly strict, and probably unintentional.
12038 </p>
12039 <p><b>Proposed resolution:</b></p>
12040 <p>
12041 Change the sentence in question to "... the only exceptions are
12042 destroying an iterator that holds a singular value, or the assignment
12043 of a non-singular value to an iterator that holds a singular value."
12044 </p>
12045 <hr>
12046 <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>
12047 <p>
12048 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
12049 closing a basic_[io]fstream does not affect the error bits.  This
12050 means, for example, that if you read through a file up to EOF, and
12051 then close the stream and reopen it at the beginning of the file,
12052 the EOF bit in the stream's error state is still set.  This is
12053 counterintuitive.
12054 </p>
12055 <p>
12056 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>,
12057 and put in a footnote to clarify that the strict reading was indeed
12058 correct.  We did that because we believed the standard was
12059 unambiguous and consistent, and that we should not make architectural
12060 changes in a TC.  Now that we're working on a new revision of the
12061 language, those considerations no longer apply.
12062 </p>
12063 <p><b>Proposed resolution:</b></p>
12064
12065 <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>
12066
12067 <blockquote>
12068 Calls rdbuf()-&gt;open(s,mode|in). If that function returns a null
12069 pointer, calls setstate(failbit) (which may throw ios_base::failure
12070 [Footnote: (lib.iostate.flags)].
12071 </blockquote>
12072
12073 <p>to:</p>
12074
12075 <blockquote>Calls rdbuf()-&gt;open(s,mode|in). If that function returns
12076 a null pointer, calls setstate(failbit) (which may throw
12077 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
12078 </blockquote>
12079
12080 <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>
12081
12082 <blockquote>Calls rdbuf()-&gt;open(s,mode|out). If that function
12083 returns a null pointer, calls setstate(failbit) (which may throw
12084 ios_base::failure [Footnote: (lib.iostate.flags)).
12085 </blockquote>
12086
12087 <p>to:</p>
12088
12089 <blockquote>Calls rdbuf()-&gt;open(s,mode|out). If that function
12090 returns a null pointer, calls setstate(failbit) (which may throw
12091 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
12092 </blockquote>
12093
12094 <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>
12095
12096 <blockquote>Calls rdbuf()-&gt;open(s,mode), If that function returns a
12097 null pointer, calls setstate(failbit), (which may throw
12098 ios_base::failure). (lib.iostate.flags) )
12099 </blockquote>
12100
12101 <p>to:</p>
12102
12103 <blockquote>Calls rdbuf()-&gt;open(s,mode), If that function returns a
12104 null pointer, calls setstate(failbit), (which may throw
12105 ios_base::failure). (lib.iostate.flags) ), else calls clear().
12106 </blockquote>
12107
12108
12109
12110 <p><i>[Kona: the LWG agrees this is a good idea.  Post-Kona: Bill
12111 provided wording.  He suggests having open, not close, clear the error
12112 flags.]</i></p>
12113
12114 <p><i>[Post-Sydney: Howard provided a new proposed resolution.  The
12115   old one didn't make sense because it proposed to fix this at the
12116   level of basic_filebuf, which doesn't have access to the stream's
12117   error state.  Howard's proposed resolution fixes this at the level
12118   of the three fstream class template instead.]</i></p>
12119
12120 <hr>
12121 <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.queue"> [lib.queue]</a>, 23.2.3.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;Hans Bos&nbsp; <b>Date:</b>&nbsp;7 Jun 2003</p>
12122 <p>
12123 Sections 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a> and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> list
12124 comparison operators (==, !=, &lt;, &lt;=, &gt;, =&gt;) for queue and
12125 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.queue"> [lib.queue]</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.queue"> [lib.queue]</a>
12126 par3) are defined.
12127 </p>
12128 <p><b>Proposed resolution:</b></p>
12129
12130 <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.queue"> [lib.queue]</a>
12131   paragraph 3:</p>
12132
12133 <blockquote>
12134
12135 <pre>  operator!=
12136 </pre>
12137 <p>Returns: <tt>x.c != y.c</tt></p>
12138
12139 <pre>  operator&gt;
12140 </pre>
12141 <p>Returns: <tt>x.c &gt; y.c</tt></p>
12142
12143 <pre>  operator&lt;=
12144 </pre>
12145 <p>Returns: <tt>x.c &lt;= y.c</tt></p>
12146
12147 <pre>  operator&gt;=
12148 </pre>
12149 <p>Returns: <tt>x.c &gt;= y.c</tt></p>
12150
12151 </blockquote>
12152
12153 <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.stack"> [lib.stack]</a>:</p>
12154
12155 <blockquote>
12156
12157 <pre>  operator==
12158 </pre>
12159 <p>Returns: <tt>x.c == y.c</tt></p>
12160
12161 <pre>  operator&lt;
12162 </pre>
12163 <p>Returns: <tt>x.c &lt; y.c</tt></p>
12164
12165 <pre>  operator!=
12166 </pre>
12167 <p>Returns: <tt>x.c != y.c</tt></p>
12168
12169 <pre>  operator&gt;
12170 </pre>
12171 <p>Returns: <tt>x.c &gt; y.c</tt></p>
12172
12173 <pre>  operator&lt;=
12174 </pre>
12175 <p>Returns: <tt>x.c &lt;= y.c</tt></p>
12176
12177 <pre>  operator&gt;=
12178 </pre>
12179 <p>Returns: <tt>x.c &gt;= y.c</tt></p>
12180
12181 </blockquote>
12182
12183
12184 <p><i>[Kona: Matt provided wording.]</i></p>
12185
12186 <p><b>Rationale:</b></p>
12187 There isn't any real doubt about what these operators are
12188 supposed to do, but we ought to spell it out.
12189 <hr>
12190 <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>
12191 <p>
12192 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:
12193 "The semantics of the set operations are generalized to multisets in a
12194 standard way by defining union() to contain the maximum number of
12195 occurrences of every element, intersection() to contain the minimum, and
12196 so on."
12197 </p>
12198
12199 <p>
12200 This is wrong.  The name of the functions are set_union() and
12201 set_intersection(), not union() and intersection().
12202 </p>
12203 <p><b>Proposed resolution:</b></p>
12204 <p>Change that sentence to use the correct names.</p>
12205 <hr>
12206 <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>
12207 <p>
12208 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
12209 function only throws if the respective bits are already set prior to
12210 the function call. That's obviously not the intent. The typo ought to
12211 be corrected and the text reworded as: "If (<i>state</i> &amp;
12212 exceptions()) == 0, returns. ..."
12213 </p>
12214 <p><b>Proposed resolution:</b></p>
12215 <p>
12216 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;
12217 exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
12218 &amp; exceptions()) == 0".
12219 </p>
12220
12221 <p><i>[Kona: the original proposed resolution wasn't quite right.  We
12222   really do mean rdstate(); the ambiguity is that the wording in the
12223   standard doesn't make it clear whether we mean rdstate() before
12224   setting the new state, or rdsate() after setting it.  We intend the
12225   latter, of course. Post-Kona: Martin provided wording.]</i></p>
12226
12227 <hr>
12228 <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>
12229 <p>
12230 The second sentence of the proposed resolution says:
12231 </p>
12232
12233 <p>
12234 "If it inserted no characters because it caught an exception thrown
12235 while extracting characters from sb and ..."
12236 </p>
12237
12238 <p>
12239 However, we are not extracting from sb, but extracting from the
12240 basic_istream (*this) and inserting into sb. I can't really tell if
12241 "extracting" or "sb" is a typo.
12242 </p>
12243
12244 <p><i>[
12245 Sydney: Definitely a real issue. We are, indeed, extracting characters
12246 from an istream and not from sb. The problem was there in the FDIS and
12247 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
12248 to have *this instead of sb. We're talking about the exception flag
12249 state of a basic_istream object, and there's only one basic_istream
12250 object in this discussion, so that would be a consistent
12251 interpretation.  (But we need to be careful: the exception policy of
12252 this member function must be consistent with that of other
12253 extractors.)  PJP will provide wording.
12254 ]</i></p>
12255
12256 <p><b>Proposed resolution:</b></p>
12257 <p>Change the sentence from:</p>
12258
12259 <blockquote>
12260 If it inserted no characters because it caught an exception thrown
12261 while extracting characters from sb and failbit is on in exceptions(),
12262 then the caught exception is rethrown.
12263 </blockquote>
12264
12265 <p>to:</p>
12266
12267 <blockquote>
12268 If it inserted no characters because it caught an exception thrown
12269 while extracting characters from *this and failbit is on in exceptions(),
12270 then the caught exception is rethrown.
12271 </blockquote>
12272 <hr>
12273 <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.vector.modifiers"> [lib.vector.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;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Aug 2003</p>
12274 <p>
12275 Consider the following code fragment:
12276 </p>
12277 <blockquote>
12278 <pre>int A[8] = { 1,3,5,7,9,8,4,2 };
12279 std::vector&lt;int&gt; v(A, A+8);
12280
12281 std::vector&lt;int&gt;::iterator i1 = v.begin() + 3;
12282 std::vector&lt;int&gt;::iterator i2 = v.begin() + 4;
12283 v.erase(i1);
12284 </pre>
12285 </blockquote>
12286
12287 <p>
12288 Which iterators are invalidated by <tt>v.erase(i1)</tt>: i1, i2,
12289 both, or neither?
12290 </p>
12291
12292 <p>
12293 On all existing implementations that I know of, the status of i1 and
12294 i2 is the same: both of them will be iterators that point to some
12295 elements of the vector (albeit not the same elements they did
12296 before).  You won't get a crash if you use them.  Depending on
12297 exactly what you mean by "invalidate", you might say that neither one
12298 has been invalidated because they still point to <i>something</i>,
12299 or you might say that both have been invalidated because in both
12300 cases the elements they point to have been changed out from under the
12301 iterator.
12302 </p>
12303
12304 <p>
12305 The standard doesn't say either of those things.  It says that erase
12306 invalidates all iterators and references "after the point of the
12307 erase".  This doesn't include i1, since it's at the point of the
12308 erase instead of after it.  I can't think of any sensible definition
12309 of invalidation by which one can say that i2 is invalidated but i1
12310 isn't.
12311 </p>
12312
12313 <p>
12314 (This issue is important if you try to reason about iterator validity
12315 based only on the guarantees in the standard, rather than reasoning
12316 from typical implementation techniques.  Strict debugging modes,
12317 which some programmers find useful, do not use typical implementation
12318 techniques.)
12319 </p>
12320 <p><b>Proposed resolution:</b></p>
12321 <p>
12322 In 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> paragraph 3, change "Invalidates all the
12323 iterators and references after the point of the erase" to
12324 "Invalidates iterators and references at or after the point of the
12325 erase".
12326 </p>
12327 <p><b>Rationale:</b></p>
12328 <p>I believe this was essentially a typographical error, and that it
12329   was taken for granted that erasing an element invalidates iterators
12330   that point to it.  The effects clause in question treats iterators
12331   and references in parallel, and it would seem counterintuitive to
12332   say that a reference to an erased value remains valid.</p>
12333 <hr>
12334 <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>
12335 <p>
12336 According to 27.6.1.4, the ws() manipulator is not required to construct
12337 the sentry object. The manipulator is also not a member function so the
12338 text in 27.6.1, p1 through 4 that describes the exception policy for
12339 istream member functions does not apply. That seems inconsistent with
12340 the rest of extractors and all the other input functions (i.e., ws will
12341 not cause a tied stream to be flushed before extraction, it doesn't check
12342 the stream's exceptions or catch exceptions thrown during input, and it
12343 doesn't affect the stream's gcount).
12344 </p>
12345 <p><b>Proposed resolution:</b></p>
12346 <p>
12347 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
12348 of paragraph 1, the following text:
12349 </p>
12350
12351     <blockquote>
12352     Behaves as an unformatted input function (as described in
12353     27.6.1.3, paragraph 1), except that it does not count the number
12354     of characters extracted and does not affect the value returned by
12355     subsequent calls to is.gcount(). After constructing a sentry
12356     object...
12357     </blockquote>
12358
12359 <p><i>[Post-Kona: Martin provided wording]</i></p>
12360
12361 <hr>
12362 <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>
12363 <p>
12364 7.19.1, p2, of C99 requires that the FILE type only be declared in
12365 &lt;stdio.h&gt;.  None of the (implementation-defined) members of the
12366 struct is mentioned anywhere for obvious reasons.
12367 </p>
12368
12369 <p>
12370 C++ says in 27.8.1, p2 that FILE is a type that's defined in &lt;cstdio&gt;. Is
12371 it really the intent that FILE be a complete type or is an implementation
12372 allowed to just declare it without providing a full definition?
12373 </p>
12374 <p><b>Proposed resolution:</b></p>
12375 <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
12376   "defined" to "declared".</p>
12377 <p><b>Rationale:</b></p>
12378 <p>We don't want to impose any restrictions beyond what the C standard
12379   already says. We don't want to make anything implementation defined,
12380   because that imposes new requirements in implementations.</p>
12381 <hr>
12382 <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.temporary.buffer"> [lib.temporary.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;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
12383 <p>
12384 The standard is not clear about the requirements on the value returned from
12385 a call to get_temporary_buffer(0). In particular, it fails to specify whether
12386 the call should return a distinct pointer each time it is called (like
12387 operator new), or whether the value is unspecified (as if returned by
12388 malloc). The standard also fails to mention what the required behavior
12389 is when the argument is less than 0.
12390 </p>
12391 <p><b>Proposed resolution:</b></p>
12392 <p>Change 20.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.temporary.buffer"> [lib.temporary.buffer]</a> paragraph 2 from "...or a pair of 0
12393 values if no storage can be obtained" to "...or a pair of 0 values if
12394 no storage can be obtained or if <i>n</i> &lt;= 0."</p>
12395 <p><i>[Kona: Matt provided wording]</i></p>
12396 <hr>
12397 <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>
12398 <p>
12399 The complexity requirements for these function templates are incorrect
12400 (or don't even make sense) for negative n:</p>
12401
12402 <p>25.1.9, p7 (search_n):
12403 <br>
12404 Complexity: At most (last1 - first1) * count applications
12405 of the corresponding predicate.</p>
12406
12407 <p>25.2.5, p3 (fill_n):
12408 <br>
12409 Complexity: Exactly last - first (or n) assignments.</p>
12410 <br>
12411
12412 <p>25.2.6, p3 (generate_n):
12413 <br>
12414 Complexity: Exactly last - first (or n) assignments.</p>
12415
12416 <p>
12417 In addition, the Requirements or the Effects clauses for the latter two
12418 templates don't say anything about the behavior when n is negative.
12419 </p>
12420 <p><b>Proposed resolution:</b></p>
12421 <p>Change 25.1.9, p7 to</p>
12422
12423 <blockquote>
12424 Complexity: At most (last1 - first1) * count applications
12425 of the corresponding predicate if count is positive,
12426 or 0 otherwise.
12427 </blockquote>
12428
12429 <p>Change 25.2.5, p2 to</p>
12430 <blockquote>
12431 Effects: Assigns value through all the iterators in the range [first,
12432 last), or [first, first + n) if n is positive, none otherwise.
12433 </blockquote>
12434
12435 <p>Change 25.2.5, p3 to:</p>
12436 <blockquote>
12437 Complexity: Exactly last - first (or n if n is positive,
12438 or 0 otherwise) assignments.
12439 </blockquote>
12440
12441 <p>
12442 Change 25.2.6, p1
12443 to (notice the correction for the misspelled "through"):
12444 </p>
12445 <blockquote>
12446 Effects: Invokes the function object genand assigns the return
12447 value of gen through all the iterators in the range [first, last),
12448 or [first, first + n) if n is positive, or [first, first)
12449 otherwise.
12450 </blockquote>
12451
12452 <p>Change 25.2.6, p3 to:</p>
12453 <blockquote>
12454 Complexity: Exactly last - first (or n if n is positive,
12455 or 0 otherwise) assignments.
12456 </blockquote>
12457 <p><b>Rationale:</b></p>
12458 <p>Informally, we want to say that whenever we see a negative number
12459   we treat it the same as if it were zero.  We believe the above
12460   changes do that (although they may not be the minimal way of saying
12461   so).  The LWG considered and rejected the alternative of saying that
12462   negative numbers are undefined behavior.</p>
12463 <hr>
12464 <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>
12465 <p>
12466 23.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q)
12467 that q must be a valid dereferenceable iterator into the sequence a.
12468 </p>
12469
12470 <p>
12471 However, 21.3.5.5, p5 describing string::erase(p) only requires that
12472 p be a valid iterator.
12473 </p>
12474
12475 <p>
12476 This may be interepreted as a relaxation of the general requirement,
12477 which is most likely not the intent.
12478 </p>
12479 <p><b>Proposed resolution:</b></p>
12480 <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>
12481 <p><b>Rationale:</b></p>
12482 <p>The LWG considered two options: changing the string requirements to
12483   match the general container requirements, or just removing the
12484   erroneous string requirements altogether.  The LWG chose the latter
12485   option, on the grounds that duplicating text always risks the
12486   possibility that it might be duplicated incorrectly.</p>
12487 <hr>
12488 <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>
12489 <p>27.7.1.3 par 8 says:</p>
12490 <blockquote>
12491 Notes: The function can make a write position available only if
12492     ( mode &amp; ios_base::out) != 0. To make a write position
12493     available, the function reallocates (or initially allocates) an
12494     array object with a sufficient number of elements to hold the
12495     current array object (if any), plus one additional write position.
12496     If ( mode &amp; ios_base::in) != 0, the function alters the read end
12497     pointer egptr() to point just past the new write position (as
12498     does the write end pointer epptr()).
12499 </blockquote>
12500
12501 <p>
12502 The sentences "plus one additional write position." and especially
12503     "(as does the write end pointer epptr())" COULD by interpreted
12504     (and is interpreted by at least my library vendor) as:
12505 </p>
12506
12507 <blockquote>
12508     post-condition: epptr() == pptr()+1
12509 </blockquote>
12510
12511 <p>
12512 This WOULD force sputc() to call the virtual overflow() each time.
12513 </p>
12514
12515 <p>The proposed change also affects Defect Report 169.</p>
12516
12517 <p><b>Proposed resolution:</b></p>
12518 <p>27.7.1.1/2 Change:</p>
12519
12520 <blockquote>
12521 2- Notes: The function allocates no array object.
12522 </blockquote>
12523
12524 <p>
12525 to:
12526 </p>
12527
12528 <blockquote>
12529 2- Postcondition: str() == "".
12530 </blockquote>
12531
12532 <p>
12533 27.7.1.1/3 Change:
12534 </p>
12535
12536 <blockquote>
12537 <p>
12538 -3- Effects: Constructs an object of class basic_stringbuf,
12539 initializing the base class with basic_streambuf()
12540 (lib.streambuf.cons), and initializing mode with which . Then copies
12541 the content of str into the basic_stringbuf underlying character
12542 sequence and initializes the input and output sequences according to
12543 which. If which &amp; ios_base::out is true, initializes the output
12544 sequence with the underlying sequence. If which &amp; ios_base::in is
12545 true, initializes the input sequence with the underlying sequence.
12546 </p>
12547 </blockquote>
12548
12549 <p>to:</p>
12550
12551 <blockquote>
12552 <p>
12553 -3- Effects: Constructs an object of class basic_stringbuf,
12554 initializing the base class with basic_streambuf()
12555 (lib.streambuf.cons), and initializing mode with which. Then copies
12556 the content of str into the basic_stringbuf underlying character
12557 sequence. If which &amp; ios_base::out is true, initializes the output
12558 sequence such that pbase() points to the first underlying character,
12559 epptr() points one past the last underlying character, and if (which &amp;
12560 ios_base::ate) is true, pptr() is set equal to
12561 epptr() else pptr() is set equal to pbase(). If which &amp; ios_base::in
12562 is true, initializes the input sequence such that eback() and gptr()
12563 point to the first underlying character and egptr() points one past
12564 the last underlying character.
12565 </p>
12566 </blockquote>
12567
12568 <p>27.7.1.2/1 Change:</p>
12569
12570 <blockquote>
12571 <p>
12572 -1- Returns: A basic_string object whose content is equal to the
12573 basic_stringbuf underlying character sequence. If the buffer is only
12574 created in input mode, the underlying character sequence is equal to
12575 the input sequence; otherwise, it is equal to the output sequence. In
12576 case of an empty underlying character sequence, the function returns
12577 basic_string&lt;charT,traits,Allocator&gt;().
12578 </p>
12579 </blockquote>
12580
12581 <p>to:</p>
12582
12583 <blockquote>
12584 <p>
12585 -1- Returns: A basic_string object whose content is equal to the
12586 basic_stringbuf underlying character sequence. If the basic_stringbuf
12587 was created only in input mode, the resultant basic_string contains
12588 the character sequence in the range [eback(), egptr()).  If the
12589 basic_stringbuf was created with (which &amp; ios_base::out) being true
12590 then the resultant basic_string contains the character sequence in the
12591 range [pbase(), high_mark) where high_mark represents the position one
12592 past the highest initialized character in the buffer.  Characters can
12593 be initialized either through writing to the stream, or by
12594 constructing the basic_stringbuf with a basic_string, or by calling
12595 the str(basic_string) member function.  In the case of calling the
12596 str(basic_string) member function, all characters initialized prior to
12597 the call are now considered uninitialized (except for those
12598 characters re-initialized by the new basic_string).  Otherwise the
12599 basic_stringbuf has been created in neither input nor output mode and
12600 a zero length basic_string is returned.
12601 </p>
12602 </blockquote>
12603
12604 <p>
12605 27.7.1.2/2 Change:
12606 </p>
12607
12608 <blockquote>
12609 <p>
12610 -2- Effects: If the basic_stringbuf's underlying character sequence is
12611 not empty, deallocates it. Then copies the content of s into the
12612 basic_stringbuf underlying character sequence and initializes the
12613 input and output sequences according to the mode stored when creating
12614 the basic_stringbuf object. If (mode&amp;ios_base::out) is true, then
12615 initializes the output sequence with the underlying sequence. If
12616 (mode&amp;ios_base::in) is true, then initializes the input sequence with
12617 the underlying sequence.
12618 </p>
12619 </blockquote>
12620
12621 <p>to:</p>
12622
12623 <blockquote>
12624 <p>
12625 -2- Effects: Copies the content of s into the basic_stringbuf
12626 underlying character sequence. If mode &amp; ios_base::out is true,
12627 initializes the output sequence such that pbase() points to the first
12628 underlying character, epptr() points one past the last underlying
12629 character, and if (mode &amp; ios_base::ate) is true,
12630 pptr() is set equal to epptr() else pptr() is set equal to pbase(). If
12631 mode &amp; ios_base::in is true, initializes the input sequence such that
12632 eback() and gptr() point to the first underlying character and egptr()
12633 points one past the last underlying character.
12634 </p>
12635 </blockquote>
12636
12637 <p>Remove 27.2.1.2/3.  (Same rationale as issue 238: incorrect and unnecessary.)</p>
12638
12639 <p>27.7.1.3/1 Change:</p>
12640
12641 <blockquote>
12642 <p>
12643 1- Returns: If the input sequence has a read position available,
12644 returns traits::to_int_type(*gptr()).  Otherwise, returns
12645 traits::eof().
12646 </p>
12647 </blockquote>
12648
12649 <p>to:</p>
12650
12651 <blockquote>
12652 <p>
12653 1- Returns: If the input sequence has a read position available,
12654 returns traits::to_int_type(*gptr()).  Otherwise, returns
12655 traits::eof().  Any character in the underlying buffer which has been
12656 initialized is considered to be part of the input sequence.
12657 </p>
12658 </blockquote>
12659
12660 <p>27.7.1.3/9 Change:</p>
12661
12662 <blockquote>
12663 <p>
12664 -9- Notes: The function can make a write position available only if (
12665 mode &amp; ios_base::out) != 0. To make a write position available, the
12666 function reallocates (or initially allocates) an array object with a
12667 sufficient number of elements to hold the current array object (if
12668 any), plus one additional write position. If ( mode &amp; ios_base::in) !=
12669 0, the function alters the read end pointer egptr() to point just past
12670 the new write position (as does the write end pointer epptr()).
12671 </p>
12672 </blockquote>
12673
12674 <p>to:</p>
12675
12676 <blockquote>
12677 <p>
12678 -9- The function can make a write position available only if ( mode &amp;
12679 ios_base::out) != 0. To make a write position available, the function
12680 reallocates (or initially allocates) an array object with a sufficient
12681 number of elements to hold the current array object (if any), plus one
12682 additional write position. If ( mode &amp; ios_base::in) != 0, the
12683 function alters the read end pointer egptr() to point just past the
12684 new write position.
12685 </p>
12686 </blockquote>
12687
12688 <p>27.7.1.3/12 Change:</p>
12689
12690 <blockquote>
12691 <p>
12692 -12- _ If (newoff + off) &lt; 0, or (xend - xbeg) &lt; (newoff + off), the
12693 positioning operation fails. Otherwise, the function assigns xbeg +
12694 newoff + off to the next pointer xnext .
12695 </p>
12696 </blockquote>
12697
12698 <p>to:</p>
12699
12700 <blockquote>
12701 <p>
12702 -12- _ If (newoff + off) &lt; 0, or if (newoff + off) refers to an
12703 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>
12704 paragraph 1), the positioning operation fails. Otherwise, the function
12705 assigns xbeg + newoff + off to the next pointer xnext .
12706 </p>
12707 </blockquote>
12708
12709 <p><i>[post-Kona: Howard provided wording.  At Kona the LWG agreed that
12710   something along these lines was a good idea, but the original
12711   proposed resolution didn't say enough about the effect of various
12712   member functions on the underlying character sequences.]</i></p>
12713
12714 <p><b>Rationale:</b></p>
12715 <p>The current basic_stringbuf description is over-constrained in such
12716 a way as to prohibit vendors from making this the high-performance
12717 in-memory stream it was meant to be.  The fundamental problem is that
12718 the pointers: eback(), gptr(), egptr(), pbase(), pptr(), epptr() are
12719 observable from a derived client, and the current description
12720 restricts the range [pbase(), epptr()) from being grown geometrically.
12721 This change allows, but does not require, geometric growth of this
12722 range.</p>
12723
12724 <p>Backwards compatibility issues: These changes will break code that
12725 derives from basic_stringbuf, observes epptr(), and depends upon
12726 [pbase(), epptr()) growing by one character on each call to overflow()
12727 (i.e. test suites).  Otherwise there are no backwards compatibility
12728 issues.</p>
12729
12730 <p>27.7.1.1/2: The non-normative note is non-binding, and if it were
12731 binding, would be over specification.  The recommended change focuses
12732 on the important observable fact.</p>
12733
12734 <p>27.7.1.1/3: This change does two things: 1.  It describes exactly
12735 what must happen in terms of the sequences.  The terms "input
12736 sequence" and "output sequence" are not well defined.  2.  It
12737 introduces a common extension: open with app or ate mode.  I concur
12738 with issue 238 that paragraph 4 is both wrong and unnecessary.</p>
12739
12740 <p>27.7.1.2/1: This change is the crux of the efficiency issue.  The
12741 resultant basic_string is not dependent upon epptr(), and thus
12742 implementors are free to grow the underlying buffer geometrically
12743 during overflow() *and* place epptr() at the end of that buffer.</p>
12744
12745 <p>27.7.1.2/2:  Made consistent with the proposed 27.7.1.1/3.</p>
12746
12747 <p>27.7.1.3/1: Clarifies that characters written to the stream beyond
12748 the initially specified string are available for reading in an i/o
12749 basic_streambuf.</p>
12750
12751 <p>27.7.1.3/9: Made normative by removing "Notes:", and removed the
12752 trailing parenthetical comment concerning epptr().</p>
12753
12754 <p>27.7.1.3/12: Restricting the positioning to [xbeg, xend) is no
12755 longer allowable since [pbase(), epptr()) may now contain
12756 uninitialized characters.  Positioning is only allowable over the
12757 initialized range.</p>
12758 <hr>
12759 <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>
12760 <p>
12761 It has been pointed out a number of times that the bitset to_string() member
12762 function template is tedious to use since callers must explicitly specify the
12763 entire template argument list (3 arguments). At least two implementations
12764 provide a number of overloads of this template to make it easier to use.
12765 </p>
12766 <p><b>Proposed resolution:</b></p>
12767 <p>In order to allow callers to specify no template arguments at all, just the
12768 first one (charT), or the first 2 (charT and traits), in addition to all
12769 three template arguments, add the following three overloads to both the
12770 interface (declarations only) of the class template bitset as well as to
12771 section 23.3.5.2, immediately after p34, the Returns clause of the existing
12772 to_string() member function template:</p>
12773
12774 <pre>    template &lt;class charT, class traits&gt;
12775     basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
12776     to_string () const;
12777
12778     -34.1- Returns: to_string&lt;charT, traits, allocator&lt;charT&gt; &gt;().
12779
12780     template &lt;class charT&gt;
12781     basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
12782     to_string () const;
12783
12784     -34.2- Returns: to_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;().
12785
12786     basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
12787     to_string () const;
12788
12789     -34.3- Returns: to_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;().
12790 </pre>
12791
12792 <p><i>[Kona: the LWG agrees that this is an improvement over the
12793   status quo.  Dietmar thought about an alternative using a proxy
12794   object but now believes that the proposed resolution above is the
12795   right choice.
12796 ]</i></p>
12797
12798 <hr>
12799 <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>
12800
12801 <p>
12802 It has been pointed out that the proposed resolution in DR 25 may not be
12803 quite up to snuff: <br>
12804 http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html
12805 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#25<br>
12806 </p>
12807
12808 <p>
12809 It looks like Petur is right. The complete corrected text is copied below.
12810 I think we may have have been confused by the reference to 22.2.2.2.2 and
12811 the subsequent description of `n' which actually talks about the second
12812 argument to sputn(), not about the number of fill characters to pad with.
12813 </p>
12814
12815 <p>
12816 So the question is: was the original text correct? If the intent was to
12817 follow classic iostreams then it most likely wasn't, since setting width()
12818 to less than the length of the string doesn't truncate it on output. This
12819 is also the behavior of most implementations (except for SGI's standard
12820 iostreams where the operator does truncate).
12821 </p>
12822 <p><b>Proposed resolution:</b></p>
12823 <p>Change the text in 21.3.7.9, p4 from</p>
12824     <blockquote>
12825     If bool(k) is true, inserts characters as if by calling
12826     os.rdbuf()-&gt;sputn(str.data(), n), padding as described in stage 3
12827     of lib.facet.num.put.virtuals, where n is the larger of os.width()
12828     and str.size();
12829     </blockquote>
12830 <p>to</p>
12831     <blockquote>
12832     If bool(k) is true, determines padding as described in
12833     lib.facet.num.put.virtuals, and then inserts the resulting
12834     sequence of characters <tt>seq</tt> as if by calling
12835     <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where <tt>n</tt> is the larger of
12836     <tt>os.width()</tt> and <tt>str.size()</tt>;
12837      </blockquote>
12838
12839 <p><i>[Kona: it appears that neither the original wording, DR25, nor the
12840   proposed resolution, is quite what we want.  We want to say that
12841   the string will be output, padded to os.width() if necessary.  We
12842   don't want to duplicate the padding rules in clause 22, because
12843   they're complicated, but we need to be careful because they weren't
12844   quite written with quite this case in mind.  We need to say what
12845   the character sequence is, and then defer to clause 22.  Post-Kona:
12846   Benjamin provided wording.]</i></p>
12847
12848 <hr>
12849 <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>
12850 <p>
12851 Is "const std::ctype&lt;char&gt;" a valid template argument to has_facet, use_facet,
12852 and the locale template ctor? And if so, does it designate the same Facet as
12853 the non-const "std::ctype&lt;char&gt;?" What about "volatile std::ctype&lt;char&gt;?"
12854 Different implementations behave differently: some fail to compile, others
12855 accept such types but behave inconsistently.
12856 </p>
12857 <p><b>Proposed resolution:</b></p>
12858 <p>Change 22.1.1.1.2, p1 to read:</p>
12859
12860 <p>Template parameters in this clause which are required to be facets
12861 are those named Facet in declarations. A program that passes a type
12862 that is not a facet, or a type that refers to volatile-qualified
12863 facet, as an (explicit or deduced) template parameter to a locale
12864 function expecting a facet, is ill-formed.  A const-qualified facet is
12865 a valid template argument to any locale function that expects a Facet
12866 template parameter.</p>
12867
12868 <p><i>[Kona: changed the last sentence from a footnote to normative
12869 text.]</i></p>
12870
12871 <hr>
12872 <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>
12873
12874 <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
12875 noticed with statements like:</p>
12876 <pre>vector&lt;int&gt; v(10, 1);
12877 </pre>
12878
12879 <p>The intent of the above statement was to construct with:</p>
12880 <pre>vector(size_type, const value_type&amp;);
12881 </pre>
12882
12883 <p>but early implementations failed to compile as they bound to:</p>
12884 <pre>template &lt;class InputIterator&gt;
12885 vector(InputIterator f, InputIterator l);
12886 </pre>
12887 <p>instead.</p>
12888
12889 <p>Paragraphs 9-11 say that if InputIterator is an integral type, then the
12890 member template constructor will have the same effect as:</p>
12891 <pre>vector&lt;static_cast&lt;size_type&gt;(f), static_cast&lt;value_type&gt;(l));
12892 </pre>
12893 <p>(and similarly for the other member template functions of sequences).</p>
12894
12895 <p>There is also a note that describes one implementation technique:</p>
12896 <blockquote>
12897    One way that sequence implementors can satisfy this requirement is to
12898    specialize the member template for every integral type.
12899 </blockquote>
12900
12901 <p>This might look something like:</p>
12902 <blockquote>
12903 <pre>template &lt;class T&gt;
12904 struct vector
12905 {
12906      typedef unsigned size_type;
12907
12908      explicit vector(size_type) {}
12909      vector(size_type, const T&amp;) {}
12910
12911      template &lt;class I&gt;
12912      vector(I, I);
12913
12914      // ...
12915 };
12916
12917 template &lt;class T&gt;
12918 template &lt;class I&gt;
12919 vector&lt;T&gt;::vector(I, I) { ... }
12920
12921 template &lt;&gt;
12922 template &lt;&gt;
12923 vector&lt;int&gt;::vector(int, int) { ... }
12924
12925 template &lt;&gt;
12926 template &lt;&gt;
12927 vector&lt;int&gt;::vector(unsigned, unsigned) { ... }
12928
12929 //  ...
12930 </pre>
12931 </blockquote>
12932
12933 <p>Label this solution 'A'.</p>
12934
12935 <p>The standard also says:</p>
12936 <blockquote>
12937  Less cumbersome implementation techniques also exist.
12938 </blockquote>
12939 <p>
12940 A popular technique is to not specialize as above, but instead catch
12941 every call with the member template, detect the type of InputIterator,
12942 and then redirect to the correct logic.  Something like:
12943 </p>
12944 <blockquote>
12945 <pre>template &lt;class T&gt;
12946 template &lt;class I&gt;
12947 vector&lt;T&gt;::vector(I f, I l)
12948 {
12949      choose_init(f, l, int2type&lt;is_integral&lt;I&gt;::value&gt;());
12950 }
12951
12952 template &lt;class T&gt;
12953 template &lt;class I&gt;
12954 vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;false&gt;)
12955 {
12956     // construct with iterators
12957 }
12958
12959 template &lt;class T&gt;
12960 template &lt;class I&gt;
12961 vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;true&gt;)
12962 {
12963     size_type sz = static_cast&lt;size_type&gt;(f);
12964     value_type v = static_cast&lt;value_type&gt;(l);
12965     // construct with sz,v
12966 }
12967 </pre>
12968 </blockquote>
12969
12970 <p>Label this solution 'B'.</p>
12971
12972 <p>Both of these solutions solve the case the standard specifically
12973 mentions:</p>
12974 <pre>vector&lt;int&gt; v(10, 1);  // ok, vector size 10, initialized to 1
12975 </pre>
12976
12977 <p>
12978 However, (and here is the problem), the two solutions have different
12979 behavior in some cases where the value_type of the sequence is not an
12980 integral type.  For example consider:
12981 </p>
12982 <blockquote><pre>     pair&lt;char, char&gt;                     p('a', 'b');
12983      vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
12984 </pre></blockquote>
12985 <p>
12986 The second line of this snippet is likely an error.  Solution A catches
12987 the error and refuses to compile.  The reason is that there is no
12988 specialization of the member template constructor that looks like:
12989 </p>
12990 <pre>template &lt;&gt;
12991 template &lt;&gt;
12992 vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;::vector(char, char) { ... }
12993 </pre>
12994
12995 <p>
12996 So the expression binds to the unspecialized member template
12997 constructor, and then fails (compile time) because char is not an
12998 InputIterator.
12999 </p>
13000
13001 <p>
13002 Solution B compiles the above example though.  'a' is casted to an
13003 unsigned integral type and used to size the outer vector.  'b' is
13004 static casted to the inner vector using it's explicit constructor:
13005 </p>
13006
13007 <pre>explicit vector(size_type n);
13008 </pre>
13009
13010 <p>
13011 and so you end up with a static_cast&lt;size_type&gt;('a') by
13012 static_cast&lt;size_type&gt;('b') matrix.
13013 </p>
13014
13015 <p>
13016 It is certainly possible that this is what the coder intended.  But the
13017 explicit qualifier on the inner vector has been thwarted at any rate.
13018 </p>
13019
13020 <p>
13021 The standard is not clear whether the expression:
13022 </p>
13023
13024 <pre>     vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
13025 </pre>
13026
13027 <p>
13028 (and similar expressions) are:
13029 </p>
13030
13031 <ol>
13032 <li>  undefined behavior.</li>
13033 <li>  illegal and must be rejected.</li>
13034 <li>  legal and must be accepted.</li>
13035 </ol>
13036
13037 <p>My preference is listed in the order presented.</p>
13038
13039 <p>There are still other techniques for implementing the requirements of
13040 paragraphs 9-11, namely the "restricted template technique" (e.g.
13041 enable_if).  This technique is the most compact and easy way of coding
13042 the requirements, and has the behavior of #2 (rejects the above
13043 expression).
13044 </p>
13045
13046 <p>
13047 Choosing 1 would allow all implementation techniques I'm aware of.
13048 Choosing 2 would allow only solution 'A' and the enable_if technique.
13049 Choosing 3 would allow only solution 'B'.
13050 </p>
13051
13052 <p>
13053 Possible wording for a future standard if we wanted to actively reject
13054 the expression above would be to change "static_cast" in paragraphs
13055 9-11 to "implicit_cast" where that is defined by:
13056 </p>
13057
13058 <blockquote>
13059 <pre>template &lt;class T, class U&gt;
13060 inline
13061 T implicit_cast(const U&amp; u)
13062 {
13063      return u;
13064 }
13065 </pre>
13066 </blockquote>
13067
13068 <p><b>Proposed resolution:</b></p>
13069
13070 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:
13071
13072 <p>For every sequence defined in this clause and in clause lib.strings:</p>
13073
13074 <ul>
13075   <li>
13076     <p>If the constructor</p>
13077        <pre>       template &lt;class InputIterator&gt;
13078        X(InputIterator f, InputIterator l,
13079          const allocator_type&amp; a = allocator_type())
13080        </pre>
13081     <p>is called with a type InputIterator that does not qualify as
13082     an input iterator, then the constructor will behave as if the
13083     overloaded constructor:</p>
13084        <pre>       X(size_type, const value_type&amp; = value_type(),
13085          const allocator_type&amp; = allocator_type())
13086        </pre>
13087     <p>were called instead, with the arguments static_cast&lt;size_type&gt;(f), l and a, respectively.</p>
13088   </li>
13089
13090   <li>
13091     <p>If the member functions of the forms:</p>
13092        <pre>       template &lt;class InputIterator&gt;          //  such as  insert()
13093        rt fx1(iterator p, InputIterator f, InputIterator l);
13094
13095        template &lt;class InputIterator&gt;          //  such as  append(), assign()
13096        rt fx2(InputIterator f, InputIterator l);
13097
13098        template &lt;class InputIterator&gt;          //  such as  replace()
13099        rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l);
13100        </pre>
13101     <p>are called with a type InputIterator that does not qualify as
13102     an input iterator, then these functions will behave as if the
13103     overloaded member functions:</p>
13104        <pre>       rt fx1(iterator, size_type, const value_type&amp;);
13105
13106        rt fx2(size_type, const value_type&amp;);
13107
13108        rt fx3(iterator, iterator, size_type, const value_type&amp;);
13109        </pre>
13110     <p>were called instead, with the same arguments.</p>
13111   </li>
13112 </ul>
13113
13114 <p>In the previous paragraph the alternative binding will fail if f
13115 is not implicitly convertible to X::size_type or if l is not implicitly
13116 convertible to X::value_type.</p>
13117
13118 <p>
13119 The extent to which an implementation determines that a type cannot be
13120 an input iterator is unspecified, except that as a minimum integral
13121 types shall not qualify as input iterators.
13122 </p>
13123
13124
13125
13126 <p><i>[
13127 Kona: agreed that the current standard requires <tt>v('a', 'b')</tt>
13128 to be accepted, and also agreed that this is surprising behavior.  The
13129 LWG considered several options, including something like
13130 implicit_cast, which doesn't appear to be quite what we want.  We
13131 considered Howards three options: allow acceptance or rejection,
13132 require rejection as a compile time error, and require acceptance.  By
13133 straw poll (1-6-1), we chose to require a compile time error.
13134 Post-Kona: Howard provided wording.
13135 ]</i></p>
13136
13137 <p><i>[
13138 Sydney: The LWG agreed with this general direction, but there was some
13139 discomfort with the wording in the original proposed resolution.
13140 Howard submitted new wording, and we will review this again in
13141 Redmond.
13142 ]</i></p>
13143
13144 <p><i>[Redmond: one very small change in wording: the first argument
13145   is cast to size_t.  This fixes the problem of something like
13146   <tt>vector&lt;vector&lt;int&gt; &gt;(5, 5)</tt>, where int is not
13147   implicitly convertible to the value type.]</i></p>
13148
13149 <p><b>Rationale:</b></p>
13150 <p>The proposed resolution fixes:</p>
13151
13152 <pre>  vector&lt;int&gt; v(10, 1);
13153 </pre>
13154
13155 <p>
13156 since as integral types 10 and 1 must be disqualified as input
13157 iterators and therefore the (size,value) constructor is called (as
13158 if).</p>
13159
13160 <p>The proposed resolution breaks:</p>
13161
13162 <pre>  vector&lt;vector&lt;T&gt; &gt; v(10, 1);
13163 </pre>
13164
13165 <p>
13166 because the integral type 1 is not *implicitly* convertible to
13167 vector&lt;T&gt;.  The wording above requires a diagnostic.</p>
13168
13169 <p>
13170 The proposed resolution leaves the behavior of the following code
13171 unspecified.
13172 </p>
13173
13174 <pre>  struct A
13175   {
13176     operator int () const {return 10;}
13177   };
13178
13179   struct B
13180   {
13181     B(A) {}
13182   };
13183
13184   vector&lt;B&gt; v(A(), A());
13185 </pre>
13186
13187 <p>
13188 The implementation may or may not detect that A is not an input
13189 iterator and employee the (size,value) constructor.  Note though that
13190 in the above example if the B(A) constructor is qualified explicit,
13191 then the implementation must reject the constructor as A is no longer
13192 implicitly convertible to B.
13193 </p>
13194 <hr>
13195 <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>
13196 <p>
13197 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
13198 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.
13199 </p>
13200 <p><b>Proposed resolution:</b></p>
13201 <p>
13202 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
13203 <tt>fpos&lt;stateT&gt;::state()</tt> to const.
13204 </p>
13205 <hr>
13206 <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>
13207 <p>
13208 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
13209 basic_ostream&lt;charT, traits&gt;::sentry::operator bool() is declared
13210 as non const, but in section 27.6.2.3, in synopsis it is declared
13211 const.
13212 </p>
13213 <p><b>Proposed resolution:</b></p>
13214 <p>
13215 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
13216 of <tt>sentry::operator bool()</tt> to const.
13217 </p>
13218 <hr>
13219 <a name="443"></a><h3><a name="443">443.&nbsp;filebuf::close() inconsistent use of EOF</a></h3><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>
13220 <p>
13221 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
13222 basic_filebuf&lt;charT, traits&gt;::close(), overflow(EOF) is used twice;
13223 should be overflow(traits::eof()).
13224 </p>
13225 <p><b>Proposed resolution:</b></p>
13226 <p>
13227 Change overflow(EOF) to overflow(traits::eof()).
13228 </p>
13229 <hr>
13230 <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>
13231 <p>
13232 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
13233 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>.
13234 </p>
13235 <p><b>Proposed resolution:</b></p>
13236
13237 <p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away
13238  constness. The other two places are stylistic: we could change the
13239  C-style casts to const_cast. Post-Sydney: Howard provided wording.
13240 ]</i></p>
13241
13242 <p>Change 27.8.1.7/1 from:</p>
13243 <blockquote>
13244   Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
13245 </blockquote>
13246
13247 <p>to:</p>
13248 <blockquote>
13249   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
13250 </blockquote>
13251
13252 <p>Change 27.8.1.10/1 from:</p>
13253 <blockquote>
13254   Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
13255 </blockquote>
13256
13257 <p>to:</p>
13258 <blockquote>
13259   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
13260 </blockquote>
13261
13262 <p>Change 27.8.1.13/1 from:</p>
13263 <blockquote>
13264   Returns: &amp;sb.
13265 </blockquote>
13266
13267 <p>to:</p>
13268 <blockquote>
13269   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
13270 </blockquote>
13271
13272
13273
13274 <hr>
13275 <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>
13276 <p>
13277 The standard places no restrictions at all on the reference type
13278 of input, output, or forward iterators (for forward iterators it
13279 only specifies that *x must be value_type&amp; and doesn't mention
13280 the reference type).  Bidirectional iterators' reference type is
13281 restricted only by implication, since the base iterator's
13282 reference type is used as the return type of reverse_iterator's
13283 operator*, which must be T&amp; in order to be a conforming forward
13284 iterator.
13285 </p>
13286
13287 <p>
13288 Here's what I think we ought to be able to expect from an input
13289 or forward iterator's reference type R, where a is an iterator
13290 and V is its value_type
13291 </p>
13292
13293 <ul>
13294   <li>
13295       *a is convertible to R
13296   </li>
13297
13298   <li>
13299       R is convertible to V
13300   </li>
13301
13302   <li>
13303       static_cast&lt;V&gt;(static_cast&lt;R&gt;(*a)) is equivalent to
13304       static_cast&lt;V&gt;(*a)
13305   </li>
13306 </ul>
13307
13308 <p>A mutable forward iterator ought to satisfy, for x of type V:</p>
13309   <li>
13310       { R r = *a; r = x; } is equivalent to *a = x;
13311   </li>
13312
13313 <p>
13314 I think these requirements capture existing container iterators
13315 (including vector&lt;bool&gt;'s), but render istream_iterator invalid;
13316 its reference type would have to be changed to a constant
13317 reference.
13318 </p>
13319
13320
13321 <p>
13322 (Jeremy Siek) During the discussion in Sydney, it was felt that a
13323 simpler long term solution for this was needed. The solution proposed
13324 was to require <tt>reference</tt> to be the same type as <tt>*a</tt>
13325 and <tt>pointer</tt> to be the same type as <tt>a-&gt;</tt>.  Most
13326 iterators in the Standard Library already meet this requirement. Some
13327 iterators are output iterators, and do not need to meet the
13328 requirement, and others are only specified through the general
13329 iterator requirements (which will change with this resolution). The
13330 sole case where there is an explicit definition of the reference type
13331 that will need to change is <tt>istreambuf_iterator</tt> which returns
13332 <tt>charT</tt> from <tt>operator*</tt> but has a reference type of
13333 <tt>charT&amp;</tt>. We propose changing the reference type of
13334 <tt>istreambuf_iterator</tt> to <tt>charT</tt>.
13335 </p>
13336
13337 <p>The other option for resolving the issue with <tt>pointer</tt>,
13338   mentioned in the note below, is to remove <tt>pointer</tt>
13339   altogether. I prefer placing requirements on <tt>pointer</tt> to
13340   removing it for two reasons. First, <tt>pointer</tt> will become
13341   useful for implementing iterator adaptors and in particular,
13342   <tt>reverse_iterator</tt> will become more well defined. Second,
13343   removing <tt>pointer</tt> is a rather drastic and publicly-visible
13344   action to take.</p>
13345
13346 <p>The proposed resolution technically enlarges the requirements for
13347 iterators, which means there are existing iterators (such as
13348 <tt>istreambuf_iterator</tt>, and potentially some programmer-defined
13349 iterators) that will no longer meet the requirements. Will this break
13350 existing code? The scenario in which it would is if an algorithm
13351 implementation (say in the Standard Library) is changed to rely on
13352 <tt>iterator_traits::reference</tt>, and then is used with one of the
13353 iterators that do not have an appropriately defined
13354 <tt>iterator_traits::reference</tt>.
13355 </p>
13356
13357
13358 <p>The proposed resolution makes one other subtle change. Previously,
13359 it was required that output iterators have a <tt>difference_type</tt>
13360 and <tt>value_type</tt> of <tt>void</tt>, which means that a forward
13361 iterator could not be an output iterator. This is clearly a mistake,
13362 so I've changed the wording to say that those types may be
13363 <tt>void</tt>.
13364 </p>
13365
13366 <p><b>Proposed resolution:</b></p>
13367
13368 <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>
13369
13370 <blockquote>
13371 be defined as the iterator's difference type, value type and iterator
13372 category, respectively.
13373 </blockquote>
13374
13375 <p>add</p>
13376
13377 <blockquote>
13378 In addition, the types
13379 <pre>iterator_traits&lt;Iterator&gt;::reference
13380 iterator_traits&lt;Iterator&gt;::pointer
13381 </pre>
13382 must be defined as the iterator's reference and pointer types, that
13383 is, the same type as the type of <tt>*a</tt> and <tt>a-&gt;</tt>,
13384 respectively.
13385 </blockquote>
13386
13387 <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>
13388
13389 <blockquote>
13390 In the case of an output iterator, the types
13391 <pre>iterator_traits&lt;Iterator&gt;::difference_type
13392 iterator_traits&lt;Iterator&gt;::value_type
13393 </pre>
13394 are both defined as <tt>void</tt>.
13395 </blockquote>
13396
13397 <p>to:</p>
13398 <blockquote>
13399 In the case of an output iterator, the types
13400 <pre>iterator_traits&lt;Iterator&gt;::difference_type
13401 iterator_traits&lt;Iterator&gt;::value_type
13402 iterator_traits&lt;Iterator&gt;::reference
13403 iterator_traits&lt;Iterator&gt;::pointer
13404 </pre>
13405 may be defined as <tt>void</tt>.
13406 </blockquote>
13407
13408 <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>
13409 <blockquote>
13410 <pre>typename traits::off_type, charT*, charT&amp;&gt;
13411 </pre>
13412 </blockquote>
13413 <p>to:</p>
13414 <blockquote>
13415 <pre>typename traits::off_type, charT*, charT&gt;
13416 </pre>
13417 </blockquote>
13418
13419 <p><i>[
13420 Redmond: there was concern in Sydney that this might not be the only place
13421 where things were underspecified and needed to be changed.  Jeremy
13422 reviewed iterators in the standard and confirmed that nothing else
13423 needed to be changed.
13424 ]</i></p>
13425
13426 <hr>
13427 <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>
13428 <p>
13429 Table 76, the random access iterator requirement table, says that the
13430 return type of a[n] must be "convertible to T".  When an iterator's
13431 value_type T is an abstract class, nothing is convertible to T.
13432 Surely this isn't an intended restriction?
13433 </p>
13434 <p><b>Proposed resolution:</b></p>
13435 <p>
13436 Change the return type to "convertible to T const&amp;".
13437 </p>
13438 <hr>
13439 <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>
13440 <p>Original text:</p>
13441 <blockquote>
13442 The macro offsetof accepts a restricted set of type arguments in this
13443 International Standard. type shall be a POD structure or a POD union
13444 (clause 9). The result of applying the offsetof macro to a field that
13445 is a static data member or a function member is undefined."
13446 </blockquote>
13447
13448 <p>Revised text:</p>
13449 <blockquote>
13450 "If type is not a POD structure or a POD union the results are undefined."
13451 </blockquote>
13452
13453 <p>
13454 Looks to me like the revised text should have replaced only the second
13455 sentence. It doesn't make sense standing alone.
13456 </p>
13457
13458 <p><b>Proposed resolution:</b></p>
13459 <p>Change 18.1, paragraph 5, to:</p>
13460
13461 <blockquote>
13462 The macro offsetof accepts a restricted set of type arguments in this
13463 International Standard.  If type is not a POD structure or a POD union
13464 the results are undefined.  The result of applying the offsetof macro
13465 to a field that is a static data member or a function member is
13466 undefined."
13467 </blockquote>
13468 <hr>
13469 <a name="453"><h3>453.&nbsp;basic_stringbuf::seekoff need not always fail for an empty stream</h3></a><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
13470 <pre>  pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
13471                                     ios_base::openmode);
13472 </pre>
13473 <p>
13474 is obliged to fail if nothing has been inserted into the stream. This
13475 is unnecessary and undesirable. It should be permissible to seek to
13476 an effective offset of zero.</p>
13477
13478 <p><i>[
13479  Sydney: Agreed that this is an annoying problem: seeking to zero should be
13480  legal. Bill will provide wording.
13481 ]</i></p>
13482
13483 <p><b>Proposed resolution:</b></p>
13484 <p>Change the sentence from:</p>
13485 <blockquote>
13486 For a sequence to be positioned, if its next pointer (either
13487 gptr() or pptr()) is a null pointer, the positioning operation
13488 fails.
13489 </blockquote>
13490
13491 <p>to:</p>
13492
13493 <blockquote>
13494 For a sequence to be positioned, if its next pointer (either
13495 gptr() or pptr()) is a null pointer and the new offset newoff
13496 is nonzero, the positioning operation fails.
13497 </blockquote>
13498 <hr>
13499 <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>
13500 <p>
13501 Both cerr::tie() and wcerr::tie() are obliged to be null at program
13502 startup. This is overspecification and overkill. It is both traditional
13503 and useful to tie cerr to cout, to ensure that standard output is drained
13504 whenever an error message is written. This behavior should at least be
13505 permitted if not required. Same for wcerr::tie().
13506 </p>
13507 <p><b>Proposed resolution:</b></p>
13508
13509 <p>Add to the description of cerr:</p>
13510 <blockquote>
13511 After the object cerr is initialized, cerr.tie() returns &amp;cout.
13512 Its state is otherwise the same as required for basic_ios&lt;char&gt;::init
13513 (lib.basic.ios.cons).
13514 </blockquote>
13515
13516 <p>Add to the description of wcerr:</p>
13517
13518 <blockquote>
13519 After the object wcerr is initialized, wcerr.tie() returns &amp;wcout.
13520 Its state is otherwise the same as required for basic_ios&lt;wchar_t&gt;::init
13521 (lib.basic.ios.cons).
13522 </blockquote>
13523
13524 <p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just
13525   permit, cout and cerr to be tied on startup.  Pre-Redmond: Bill will
13526   provide wording.]</i></p>
13527 <hr>
13528 <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>
13529 <p>
13530 The constructor from unsigned long says it initializes "the first M
13531 bit positions to the corresponding bit values in val. M is the smaller
13532 of N and the value CHAR_BIT * sizeof(unsigned long)."
13533 </p>
13534
13535 <p>
13536 Object-representation vs. value-representation strikes again. CHAR_BIT *
13537 sizeof (unsigned long) does not give us the number of bits an unsigned long
13538 uses to hold the value. Thus, the first M bit position above is not
13539 guaranteed to have any corresponding bit values in val.
13540 </p>
13541 <p><b>Proposed resolution:</b></p>
13542 <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
13543   N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
13544   "<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in
13545   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
13546   long</tt>."
13547 </p>
13548 <hr>
13549 <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>
13550 <p>
13551 The second parameters of the non-default constructor and of the open
13552 member function for basic_fstream, named "mode", are optional
13553 according to the class declaration in 27.8.1.11 [lib.fstream].  The
13554 specifications of these members in 27.8.1.12 [lib.fstream.cons] and
13555 27.8.1.13 lib.fstream.members] disagree with this, though the
13556 constructor declaration has the "explicit" function-specifier implying
13557 that it is intended to be callable with one argument.
13558 </p>
13559 <p><b>Proposed resolution:</b></p>
13560 <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>
13561 <pre>  explicit basic_fstream(const char* s, ios_base::openmode mode);
13562 </pre>
13563 <p>to</p>
13564 <pre>  explicit basic_fstream(const char* s,
13565                          ios_base::openmode mode = ios_base::in|ios_base::out);
13566 </pre>
13567 <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>
13568 <pre>  void open(const char*s, ios_base::openmode mode);
13569 </pre>
13570 <p>to</p>
13571   void open(const char*s,
13572             ios_base::openmode mode = ios_base::in|ios_base::out);
13573 <hr>
13574 <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>
13575 <p>
13576 Template time_get currently contains difficult, if not impossible,
13577 requirements for do_date_order, do_get_time, and do_get_date. All require
13578 the implementation to scan a field generated by the %x or %X conversion
13579 specifier in strftime. Yes, do_date_order can always return no_order, but
13580 that doesn't help the other functions. The problem is that %x can be
13581 nearly anything, and it can vary widely with locales. It's horribly
13582 onerous to have to parse "third sunday after Michaelmas in the year of
13583 our Lord two thousand and three," but that's what we currently ask of
13584 do_get_date. More practically, it leads some people to think that if
13585 %x produces 10.2.04, we should know to look for dots as separators. Still
13586 not easy.
13587 </p>
13588
13589 <p>
13590 Note that this is the <i>opposite</i> effect from the intent stated in the
13591 footnote earlier in this subclause:
13592 </p>
13593
13594 <blockquote>
13595 "In other words, user confirmation is required for reliable parsing of
13596 user-entered dates and times, but machine-generated formats can be
13597 parsed reliably. This allows parsers to be aggressive about interpreting
13598 user variations on standard formats."
13599 </blockquote>
13600
13601 <p>
13602 We should give both implementers and users an easier and more reliable
13603 alternative: provide a (short) list of alternative delimiters and say
13604 what the default date order is for no_order. For backward compatibility,
13605 and maximum latitude, we can permit an implementation to parse whatever
13606 %x or %X generates, but we shouldn't require it.
13607 </p>
13608 <p><b>Proposed resolution:</b></p>
13609
13610 <p><b>In the description:</b></p>
13611 <pre>iter_type do_get_time(iter_type s, iter_type end, ios_base&amp; str,
13612         ios_base::iostate&amp; err, tm* t) const;
13613 </pre>
13614
13615 <p>
13616 2 Effects: Reads characters starting at suntil it has extracted those
13617 struct tm members, and remaining format characters, used by
13618 time_put&lt;&gt;::put to produce the format specified by 'X', or until it
13619 encounters an error or end of sequence.
13620 </p>
13621
13622 <p><b>change:</b> 'X'</p>
13623
13624 <p><b>to:</b> "%H:%M:%S"</p>
13625
13626
13627 <p>Change</p>
13628 <pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
13629         ios_base::iostate&amp; err, tm* t) const;
13630
13631 4 Effects: Reads characters starting at s until it has extracted those
13632 struct tm members, and remaining format characters, used by
13633 time_put&lt;&gt;::put to produce the format specified by 'x', or until it
13634 encounters an error.
13635 </pre>
13636
13637 <p>to</p>
13638 iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
13639         ios_base::iostate&amp; err, tm* t) const;
13640
13641 4 Effects: Reads characters starting at s until it has extracted those
13642 struct tm members, and remaining format characters, used by
13643 time_put&lt;&gt;::put to produce one of the following formats, or until it
13644 encounters an error. The format depends on the value returned by
13645 date_order() as follows:
13646
13647         date_order()  format
13648
13649         no_order      "%m/%d/%y"
13650         dmy           "%d/%m/%y"
13651         mdy           "%m/%d/%y"
13652         ymd           "%y/%m/%d"
13653         ydm           "%y/%d/%m"
13654
13655 An implementation may also accept additional implementation-defined formats.
13656 <pre></pre>
13657
13658 <p><i>[Redmond: agreed that this is a real problem.  The solution is
13659   probably to match C99's parsing rules.  Bill provided wording.
13660 ]</i></p>
13661
13662 <hr>
13663 <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.vector"> [lib.vector]</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>
13664
13665 <p>To add slightly more convenience to vector&lt;T&gt; and map&lt;Key,T&gt; we should consider to add</p>
13666 <ol>
13667 <li> add vector&lt;T&gt;::data() member (const and non-const version)
13668 semantics: if( empty() ) return 0; else return buffer_;</li>
13669 <li> add map&lt;Key,T&gt;::at( const Key&amp; k ) member (const and non-const version)
13670 <i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
13671 </ol>
13672
13673 <p>Rationale:</p>
13674
13675 <ul>
13676 <li>To obtain a pointer to the vector's buffer, one must use either
13677 operator[]() (which can give undefined behavior for empty vectors) or
13678 at() (which will then throw if the vector is empty). </li>
13679 <li>tr1::array&lt;T,sz&gt; already has a data() member</li>
13680 <li>e cannot use operator[]() when T is not DefaultDonstructible</li>
13681 <li>Neither when the map is const.</li>
13682 <li>when we want to make sure we don't add an element accidently</li>
13683 <li>when it should be considered an error if a key is not in the map</li>
13684 </ul>
13685
13686 <p><b>Proposed resolution:</b></p>
13687 <p>In 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>, add the following to the <tt>vector</tt>
13688   synopsis after "element access" and before "modifiers":</p>
13689 <pre>  // <i>[lib.vector.data] data access</i>
13690   pointer       data();
13691   const_pointer data() const;
13692 </pre>
13693
13694 <p>Add a new subsection of 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>:</p>
13695 <blockquote>
13696 <p>23.2.4.x <tt>vector</tt> data access</p>
13697 <pre>   pointer       data();
13698    const_pointer data() const;
13699 </pre>
13700 <p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
13701    range.  For a non-empty vector, data() == &amp;front().</p>
13702 <p><b>Complexity:</b> Constant time.</p>
13703 <p><b>Throws:</b> Nothing.</p>
13704 </blockquote>
13705
13706 <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>
13707 synopsis immediately after the line for operator[]:</p>
13708 <pre>  T&amp;       at(const key_type&amp; x);
13709   const T&amp; at(const key_type&amp; x) const;
13710 </pre>
13711
13712 <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>
13713 <blockquote>
13714 <pre>  T&amp;       at(const key_type&amp; x);
13715   const T&amp; at(const key_type&amp; x) const;
13716 </pre>
13717
13718 <p><b>Returns:</b> A reference to the element whose key is equivalent
13719   to x, if such an element is present in the map.</p>
13720 <p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
13721
13722 </blockquote>
13723
13724 <p><b>Rationale:</b></p>
13725 <p>Neither of these additions provides any new functionality but the
13726   LWG agreed that they are convenient, especially for novices.  The
13727   exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
13728   was chosen to match <tt>vector::at</tt>.</p>
13729 <hr>
13730 <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>
13731 <p>C header &lt;iso646.h&gt; defines macros for some operators, such as
13732 not_eq for !=.</p>
13733
13734 <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
13735 clauses 18 through 27, the &lt;cname&gt; C++ header contents are the same
13736 as the C header &lt;name.h&gt;. In particular, table 12 lists
13737 &lt;ciso646&gt; as a C++ header.</p>
13738
13739 <p>I don't find any other mention of &lt;ciso646&gt;, or any mention of
13740 &lt;iso646.h&gt;, in clauses 17 thorough 27. That implies that the
13741 contents of &lt;ciso646&gt; are the same as C header &lt;iso646.h&gt;.</p>
13742
13743 <p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
13744 "Header &lt;iso646.h&gt;" says that the alternative tokens are not
13745 defined as macros in &lt;ciso646&gt;, but does not mention the contents
13746 of &lt;iso646.h&gt;.</p>
13747
13748 <p>I don't find any normative text to support C.2.2.2.</p>
13749
13750 <p><b>Proposed resolution:</b></p>
13751 <p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
13752   paragraph 6 (the one about functions must be functions):</p>
13753
13754 <blockquote>
13755 <p>Identifiers that are keywords or operators in C++ shall not be defined
13756 as macros in C++ standard library headers.
13757 [Footnote:In particular, including the standard header &lt;iso646.h&gt;
13758 or &lt;ciso646&gt; has no effect. </p>
13759 </blockquote>
13760
13761 <p><i>[post-Redmond: Steve provided wording.]</i></p>
13762
13763 <hr>
13764 <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>
13765
13766 <p>
13767 Table 37 describes the requirements on Traits::compare() in terms of
13768 those on Traits::lt(). 21.1.3.1, p6 requires char_traits&lt;char&gt;::lt()
13769 to yield the same result as operator&lt;(char, char).
13770 </p>
13771
13772 <p>
13773 Most, if not all, implementations of char_traits&lt;char&gt;::compare()
13774 call memcmp() for efficiency. However, the C standard requires both
13775 memcmp() and strcmp() to interpret characters under comparison as
13776 unsigned, regardless of the signedness of char. As a result, all
13777 these char_traits implementations fail to meet the requirement
13778 imposed by Table 37 on compare() when char is signed.
13779 </p>
13780
13781
13782 <p>Read email thread starting with c++std-lib-13499 for more. </p>
13783 <p><b>Proposed resolution:</b></p>
13784
13785
13786 <p>Change 21.1.3.1, p6 from</p>
13787 <blockquote>
13788     The two-argument members assign, eq, and lt are defined identically
13789     to the built-in operators =, ==, and &lt; respectively.
13790 </blockquote>
13791 <p>to</p>
13792 <blockquote>
13793   The two-argument member assign is defined identically to
13794   the built-in operator =. The two
13795   argument members eq and lt are defined identically to
13796   the built-in operators == and &lt; for type unsigned char.
13797 </blockquote>
13798
13799 <p><i>[Redmond: The LWG agreed with this general direction, but we
13800   also need to change <tt>eq</tt> to be consistent with this change.
13801   Post-Redmond: Martin provided wording.]</i></p>
13802
13803 <hr>
13804 <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>
13805
13806 <p>The program below is required to compile but when run it typically
13807 produces unexpected results due to the user-defined conversion from
13808 std::cout or any object derived from basic_ios to void*.
13809 </p>
13810
13811 <pre>    #include &lt;cassert&gt;
13812     #include &lt;iostream&gt;
13813
13814     int main ()
13815     {
13816         assert (std::cin.tie () == std::cout);
13817         // calls std::cout.ios::operator void*()
13818     }
13819 </pre>
13820
13821 <p><b>Proposed resolution:</b></p>
13822
13823 <p>
13824 Replace std::basic_ios&lt;charT, traits&gt;::operator void*() with another
13825 conversion operator to some unspecified type that is guaranteed not
13826 to be convertible to any other type except for bool (a pointer-to-member
13827 might be one such suitable type). In addition, make it clear that the
13828 pointer type need not be a pointer to a complete type and when non-null,
13829 the value need not be valid.
13830 </p>
13831
13832 <p>Specifically, change in [lib.ios] the signature of</p>
13833 <pre>    operator void*() const;
13834 </pre>
13835 <p>to</p>
13836 <pre>    operator unspecified-bool-type() const;
13837 </pre>
13838 <p>and change [lib.iostate.flags], p1 from</p>
13839 <pre>    operator void*() const;
13840 </pre>
13841 <p>to</p>
13842 <pre>operator unspecified-bool-type() const;
13843
13844      -1- Returns: if fail() then a value that will evaluate false in a
13845       boolean context; otherwise a value that will evaluate true in a
13846       boolean context. The value type returned shall not be
13847       convertible to int.
13848
13849      -2- [Note: This conversion can be used in contexts where a bool
13850       is expected (e.g., an if condition); however, implicit
13851       conversions (e.g., to int) that can occur with bool are not
13852       allowed, eliminating some sources of user error. One possible
13853       implementation choice for this type is pointer-to-member.  - end
13854       note]
13855 </pre>
13856
13857 <p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
13858 <p><i>[Lillehammer: Doug provided revised wording for
13859   "unspecified-bool-type".]</i></p>
13860
13861 <hr>
13862 <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.bool"> [lib.vector.bool]</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>
13863
13864 <p>
13865 The overloads of relational operators for vector&lt;bool&gt; specified
13866 in [lib.vector.bool] are redundant (they are semantically identical
13867 to those provided for the vector primary template) and may even be
13868 diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation
13869 in c++std-lib-13647).
13870 </p>
13871
13872 <p><b>Proposed resolution:</b></p>
13873 <p>
13874 Remove all overloads of overloads of relational operators for
13875 vector&lt;bool&gt; from [lib.vector.bool].
13876 </p>
13877 <hr>
13878 <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>
13879
13880 <p>
13881 I think Footnote 297 is confused. The paragraph it applies to seems
13882 quite clear in that widen() is only called if the object is not a char
13883 stream (i.e., not basic_ostream&lt;char&gt;), so it's irrelevant what the
13884 value of widen(c) is otherwise.
13885 </p>
13886 <p><b>Proposed resolution:</b></p>
13887 <p>
13888 I propose to strike the Footnote.
13889 </p>
13890 <hr>
13891 <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.bool"> [lib.vector.bool]</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>
13892 <p>
13893 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.bool"> [lib.vector.bool]</a>,
13894 the non-template assign() function has the signature</p>
13895
13896 <pre>  void assign( size_type n, const T&amp; t );
13897 </pre>
13898
13899 <p>The type, T, is not defined in this context.</p>
13900 <p><b>Proposed resolution:</b></p>
13901 <p>Replace "T" with "value_type".</p>
13902 <hr>
13903 <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>
13904 <p>
13905 I'm seeing something that looks like a typo. The Return of <tt>get_deleter</tt>
13906 says:
13907 </p>
13908 <blockquote>
13909 If <tt>*this</tt> <i>owns</i> a deleter <tt>d</tt>...
13910 </blockquote>
13911 <p>
13912 but <tt>get_deleter</tt> is a free function!
13913 </p>
13914 <p><b>Proposed resolution:</b></p>
13915 <p>
13916 Therefore, I think should be:
13917 </p>
13918 <blockquote>
13919 If <tt><del>*this</del> <ins>p</ins></tt> <i>owns</i> a deleter <tt>d</tt>...
13920 </blockquote>
13921 <p>----- End of document -----</p>
13922 </body></html>