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">N1927=05-0187</td>
  12 </tr>
  13 <tr>
  14 <td align="left">Date:</td>
  15 <td align="left">2005-12-16</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 R40)</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>R40:
  49 2005-12-16 mid-term mailing.
  50 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>.
  51 </li>
  52 <li>R39:
  53 2005-10-14 post-Mont Tremblant mailing.
  54 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>.
  55 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.
  56 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.
  57 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.
  58 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.
  59 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
  60 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
  61 </li>
  62 <li>R38:
  63 2005-07-03 pre-Mont Tremblant mailing.
  64 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>.
  65 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>
  66 </li>
  67 <li>R37:
  68 2005-06 mid-term mailing.
  69 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>.
  70 </li>
  71 <li>R36:
  72 2005-04 post-Lillehammer mailing. All issues in "ready" status except
  73 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
  74 previously in "DR" status were moved to "WP".
  75 </li>
  76 <li>R35:
  77 2005-03 pre-Lillehammer mailing.
  78 </li>
  79 <li>R34:
  80 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>.
  81 </li>
  82 <li>R33:
  83 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
  84 </li>
  85 <li>R32:
  86 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
  87 new issues received after the 2004-07 mailing.  Added
  88 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>.
  89 </li>
  90 <li>R31:
  91 2004-07 mid-term mailing: reflects new proposed resolutions and
  92 new issues received after the post-Sydney mailing.  Added
  93 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>.
  94 </li>
  95 <li>R30:
  96 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
  97 Voted all "Ready" issues from R29 into the working paper.
  98 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>.
  99 </li>
 100 <li>R29:
 101 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>.
 102 </li>
 103 <li>R28:
 104 Post-Kona mailing: reflects decisions made at the Kona meeting.
 105 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>.
 106 </li>
 107 <li>R27:
 108 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>.
 109 </li>
 110 <li>R26:
 111 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
 112 All issues in Ready status were voted into DR status.  All issues in
 113 DR status were voted into WP status.
 114 </li>
 115 <li>R25:
 116 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>.
 117 </li>
 118 <li>R24:
 119 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
 120 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
 121 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
 122 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
 123 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
 124 </li>
 125 <li>R23:
 126 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>.
 127 Moved issues in the TC to TC status.
 128 </li>
 129 <li>R22:
 130 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>.
 131 </li>
 132 <li>R21:
 133 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>.
 134 </li>
 135 <li>R20:
 136 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 137 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
 138 <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
 139 not discussed at the meeting.
 140
 141 All Ready issues were moved to DR status, with the exception of issues
 142 <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>.
 143
 144 Noteworthy issues discussed at Redmond include
 145 <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>,
 146 <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>.
 147 </li>
 148 <li>R19:
 149 Pre-Redmond mailing.  Added new issues
 150 <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>.
 151 </li>
 152 <li>R18:
 153 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
 154 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
 155 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>.
 156
 157 Changed status of issues
 158 <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>
 159 <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>
 160 <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>
 161 <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>
 162 <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>
 163 <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>
 164 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
 165 to DR.
 166
 167 Changed status of issues
 168 <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>
 169 <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>
 170 <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>
 171 <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>
 172 <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>
 173 <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>
 174 <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>
 175 <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>
 176 <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>
 177 to Ready.
 178
 179 Closed issues
 180 <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>
 181 <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>
 182 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
 183 as NAD.
 184
 185 </li>
 186 <li>R17:
 187 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 188 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>.
 189 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>.
 190 </li>
 191 <li>R16:
 192 post-Toronto mailing; reflects actions taken in Toronto. Added new
 193 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
 194 <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>,
 195 <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>,
 196 <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>,
 197 <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>,
 198 <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>,
 199 <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>,
 200 <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>,
 201 <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>,
 202 <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>,
 203 <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>,
 204 <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>,
 205 <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>,
 206 <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
 207 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
 208 <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
 209 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
 210 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
 211 the bug in enough places.
 212 </li>
 213 <li>R15:
 214 pre-Toronto mailing. Added issues
 215 <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
 216 changes so that we pass Weblint tests.
 217 </li>
 218 <li>R14:
 219 post-Tokyo II mailing; reflects committee actions taken in
 220 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)
 221 </li>
 222 <li>R13:
 223 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>.
 224 </li>
 225 <li>R12:
 226 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
 227 <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
 228 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
 229 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
 230 </li>
 231 <li>R11:
 232 post-Kona mailing: Updated to reflect LWG and full committee actions
 233 in Kona (99-0048/N1224). Note changed resolution of issues
 234 <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>
 235 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
 236 "closed" documents.  Changed the proposed resolution of issue
 237 <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
 238 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
 239 </li>
 240 <li>R10:
 241 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 242 <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>,
 243 <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
 244 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 245 </li>
 246 <li>R9:
 247 pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
 248 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
 249 "closed" documents. (99-0030/N1206, 25 Aug 99)
 250 </li>
 251 <li>R8:
 252 post-Dublin mailing. Updated to reflect LWG and full committee actions
 253 in Dublin. (99-0016/N1193, 21 Apr 99)
 254 </li>
 255 <li>R7:
 256 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>,
 257 <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>,
 258 <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>,
 259 <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)
 260 </li>
 261 <li>R6:
 262 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>,
 263 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 264 </li>
 265 <li>R5:
 266 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
 267 <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
 268 for making list public. (30 Dec 98)
 269 </li>
 270 <li>R4:
 271 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
 272 <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
 273 issues corrected. (22 Oct 98)
 274 </li>
 275 <li>R3:
 276 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>
 277 added, many issues updated to reflect LWG consensus (12 Oct 98)
 278 </li>
 279 <li>R2:
 280 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,
 281 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
 282 </li>
 283 <li>R1:
 284 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
 285 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
 286 </li>
 287 </ul>
 288 <h2>Defect Reports</h2>
 289 <hr>
 290 <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>
 291 <p>The change specified in the proposed resolution below did not make
 292 it into the Standard. This change was accepted in principle at the
 293 London meeting, and the exact wording below was accepted at the
 294 Morristown meeting.</p>
 295 <p><b>Proposed resolution:</b></p>
 296 <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
 297 from:</p>
 298
 299 <blockquote>
 300   <p>It is unspecified whether a name from the Standard C library
 301   declared with external linkage has either extern "C" or
 302   extern "C++" linkage.</p>
 303 </blockquote>
 304
 305 <p>to:</p>
 306
 307 <blockquote>
 308   <p>Whether a name from the Standard C library declared with external
 309   linkage has extern "C" or extern "C++" linkage
 310   is implementation defined. It is recommended that an implementation
 311   use extern "C++" linkage for this purpose.</p>
 312 </blockquote>
 313 <hr>
 314 <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>
 315 <p>We appear not to have covered all the possibilities of
 316  exit processing with respect to
 317 atexit registration. <br>
 318 <br>
 319 Example 1: (C and C++)</p>
 320
 321 <pre>    #include &lt;stdlib.h&gt;
 322     void f1() { }
 323     void f2() { atexit(f1); }
 324
 325     int main()
 326     {
 327         atexit(f2); // the only use of f2
 328         return 0; // for C compatibility
 329     }</pre>
 330
 331 <p>At program exit, f2 gets called due to its registration in
 332 main. Running f2 causes f1 to be newly registered during the exit
 333 processing. Is this a valid program? If so, what are its
 334 semantics?</p>
 335
 336 <p>
 337 Interestingly, neither the C standard, nor the C++ draft standard nor
 338 the forthcoming C9X Committee Draft says directly whether you can
 339 register a function with atexit during exit processing.</p>
 340
 341 <p>
 342 All 3 standards say that functions are run in reverse order of their
 343 registration. Since f1 is registered last, it ought to be run first,
 344 but by the time it is registered, it is too late to be first.</p>
 345
 346 <p>If the program is valid, the standards are self-contradictory about
 347 its semantics.</p>
 348
 349 <p>Example 2: (C++ only)</p>
 350
 351 <pre>
 352     void F() { static T t; } // type T has a destructor
 353
 354     int main()
 355     {
 356         atexit(F); // the only use of F
 357     }
 358 </pre>
 359
 360 <p>Function F registered with atexit has a local static variable t,
 361 and F is called for the first time during exit processing. A local
 362 static object is initialized the first time control flow passes
 363 through its definition, and all static objects are destroyed during
 364 exit processing. Is the code valid? If so, what are its semantics?</p>
 365
 366 <p>
 367 Section 18.3 "Start and termination" says that if a function
 368 F is registered with atexit before a static object t is initialized, F
 369 will not be called until after t's destructor completes.</p>
 370
 371 <p>
 372 In example 2, function F is registered with atexit before its local
 373 static object O could possibly be initialized. On that basis, it must
 374 not be called by exit processing until after O's destructor
 375 completes. But the destructor cannot be run until after F is called,
 376 since otherwise the object could not be constructed in the first
 377 place.</p>
 378
 379 <p>If the program is valid, the standard is self-contradictory about
 380 its semantics.</p>
 381
 382 <p>I plan to submit Example 1 as a public comment on the C9X CD, with
 383 a recommendation that the results be undefined. (Alternative: make it
 384 unspecified. I don't think it is worthwhile to specify the case where
 385 f1 itself registers additional functions, each of which registers
 386 still more functions.)</p>
 387
 388 <p>I think we should resolve the situation in the whatever way the C
 389 committee decides. </p>
 390
 391 <p>For Example 2, I recommend we declare the results undefined.</p>
 392
 393 <p><i>[See reflector message lib-6500 for further discussion.]</i></p>
 394
 395 <p><b>Proposed resolution:</b></p>
 396 <p>Change section 18.3/8 from:</p>
 397 <blockquote>
 398   First, objects with static storage duration are destroyed and
 399   functions registered by calling atexit are called. Objects with
 400   static storage duration are destroyed in the reverse order of the
 401   completion of their constructor.  (Automatic objects are not
 402   destroyed as a result of calling exit().) Functions registered with
 403   atexit are called in the reverse order of their registration.  A
 404   function registered with atexit before an object obj1 of static
 405   storage duration is initialized will not be called until obj1's
 406   destruction has completed. A function registered with atexit after
 407   an object obj2 of static storage duration is initialized will be
 408   called before obj2's destruction starts.
 409 </blockquote>
 410 <p>to:</p>
 411 <blockquote>
 412   First, objects with static storage duration are destroyed and
 413   functions registered by calling atexit are called. Non-local objects
 414   with static storage duration are destroyed in the reverse order of
 415   the completion of their constructor. (Automatic objects are not
 416   destroyed as a result of calling exit().) Functions registered with
 417   atexit are called in the reverse order of their registration, except
 418   that a function is called after any previously registered functions
 419   that had already been called at the time it was registered. A
 420   function registered with atexit before a non-local object obj1 of
 421   static storage duration is initialized will not be called until
 422   obj1's destruction has completed. A function registered with atexit
 423   after a non-local object obj2 of static storage duration is
 424   initialized will be called before obj2's destruction starts. A local
 425   static object obj3 is destroyed at the same time it would be if a
 426   function calling the obj3 destructor were registered with atexit at
 427   the completion of the obj3 constructor.
 428 </blockquote>
 429 <p><b>Rationale:</b></p>
 430 <p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
 431 supporting to the proposed resolution.</p>
 432 <hr>
 433 <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>
 434 <p>At the very end of the basic_string class definition is the signature: int
 435 compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
 436 following text this is defined as: returns
 437 basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
 438 basic_string&lt;charT,traits,Allocator&gt;(s,n2); </p>
 439
 440 <p>Since the constructor basic_string(const charT* s, size_type n, const Allocator&amp; a
 441 = Allocator()) clearly requires that s != NULL and n &lt; npos and further states that it
 442 throws length_error if n == npos, it appears the compare() signature above should always
 443 throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
 444 null terminated character array. </p>
 445
 446 <p>This appears to be a typo since the obvious intent is to allow either the call above or
 447 something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
 448
 449 <p>This would imply that what was really intended was two signatures int compare(size_type
 450 pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
 451 charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
 452 <p><b>Proposed resolution:</b></p>
 453 <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>
 454 (at the very end of the basic_string synopsis) which reads:</p>
 455
 456 <blockquote>
 457   <p><tt>int compare(size_type pos1, size_type n1,<br>
 458   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
 459   size_type n2 = npos) const;</tt></p>
 460 </blockquote>
 461
 462 <p>with:</p>
 463
 464 <blockquote>
 465   <p><tt>int compare(size_type pos1, size_type n1,<br>
 466   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s) const;<br>
 467   int compare(size_type pos1, size_type n1,<br>
 468   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
 469   size_type n2) const;</tt></p>
 470 </blockquote>
 471
 472 <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>
 473 paragraphs 5 and 6 which read:</p>
 474
 475 <blockquote>
 476   <p><tt>int compare(size_type pos, size_type n1,<br>
 477   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; charT * s, size_type n2
 478   = npos) const;<br>
 479   </tt>Returns:<tt><br>
 480   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 481   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 482   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
 483 </blockquote>
 484
 485 <p>with:</p>
 486
 487 <blockquote>
 488   <p><tt>int compare(size_type pos, size_type n1,<br>
 489   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s) const;<br>
 490   </tt>Returns:<tt><br>
 491   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 492   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 493   basic_string&lt;charT,traits,Allocator&gt;( s ))<br>
 494   <br>
 495   int compare(size_type pos, size_type n1,<br>
 496   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s,
 497   size_type n2) const;<br>
 498   </tt>Returns:<tt><br>
 499   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 500   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 501   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
 502 </blockquote>
 503
 504 <p>Editors please note that in addition to splitting the signature, the third argument
 505 becomes const, matching the existing synopsis.</p>
 506 <p><b>Rationale:</b></p>
 507 <p>While the LWG dislikes adding signatures, this is a clear defect in
 508 the Standard which must be fixed.&nbsp; The same problem was also
 509 identified in issues 7 (item 5) and 87.</p>
 510 <hr>
 511 <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>
 512 <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
 513 &lt;class InputIterator&gt; insert(iterator, InputIterator,
 514 InputIterator) makes no sense. It refers to a member function that
 515 doesn't exist. It also talks about the return value of a void
 516 function. </p>
 517
 518 <p>(2) Several versions of basic_string::replace don't appear in the
 519 class synopsis. </p>
 520
 521 <p>(3) basic_string::push_back appears in the synopsis, but is never
 522 described elsewhere.  In the synopsis its argument is const charT,
 523 which doesn't makes much sense; it should probably be charT, or
 524 possible const charT&amp;. </p>
 525
 526 <p>(4) basic_string::pop_back is missing. </p>
 527
 528 <p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
 529 = npos) make no sense. First, it's const charT* in the synopsis and
 530 charT* in the description. Second, given what it says in RETURNS,
 531 leaving out the final argument will always result in an exception
 532 getting thrown. This is paragraphs 5 and 6 of
 533 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>
 534
 535 <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>,
 536 there's a note for X::move(s, p, n). It says "Copies correctly
 537 even where p is in [s, s+n)". This is correct as far as it goes,
 538 but it doesn't go far enough; it should also guarantee that the copy
 539 is correct even where s in in [p, p+n). These are two orthogonal
 540 guarantees, and neither one follows from the other. Both guarantees
 541 are necessary if X::move is supposed to have the same sort of
 542 semantics as memmove (which was clearly the intent), and both
 543 guarantees are necessary if X::move is actually supposed to be
 544 useful. </p>
 545 <p><b>Proposed resolution:</b></p>
 546 <p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
 547 <br>
 548 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
 549 <br>
 550 ITEM 2:&nbsp; Not a defect; the Standard is clear.. There are ten versions of replace() in
 551 the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
 552 <br>
 553 ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
 554 [lib.basic.string]) from:</p>
 555
 556 <p>&nbsp;&nbsp;&nbsp;&nbsp; void push_back(const charT)<br>
 557 <br>
 558 to<br>
 559 <br>
 560 &nbsp;&nbsp;&nbsp;&nbsp; void push_back(charT)<br>
 561 <br>
 562 Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
 563 <br>
 564 &nbsp;&nbsp;&nbsp; void basic_string::push_back(charT c);<br>
 565 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to append(static_cast&lt;size_type&gt;(1), c);<br>
 566 <br>
 567 ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
 568 <br>
 569 ITEM 5: Duplicate; see issue 5 (and 87).<br>
 570 <br>
 571 ITEM 6: In table 37, Replace:<br>
 572 <br>
 573 &nbsp;&nbsp;&nbsp; "Copies correctly even where p is in [s, s+n)."<br>
 574 <br>
 575 with:<br>
 576 <br>
 577 &nbsp;&nbsp;&nbsp;&nbsp; "Copies correctly even where the ranges [p, p+n) and [s,
 578 s+n) overlap."</p>
 579 <hr>
 580 <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>
 581 <p>It appears there's an important guarantee missing from clause
 582 22. We're told that invoking locale::global(L) sets the C locale if L
 583 has a name. However, we're not told whether or not invoking
 584 setlocale(s) sets the global C++ locale. </p>
 585
 586 <p>The intent, I think, is that it should not, but I can't find any
 587 such words anywhere. </p>
 588 <p><b>Proposed resolution:</b></p>
 589 <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>,
 590 paragraph 2:&nbsp; </p>
 591
 592 <blockquote>
 593   <p>No library function other than <tt>locale::global()</tt> shall affect
 594   the value returned by <tt>locale()</tt>. </p>
 595
 596 </blockquote>
 597 <hr>
 598 <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>
 599 <p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
 600 section 3.7.3.1 of CD2 seems to allow for the possibility that all
 601 calls to operator new(0) yield the same pointer, an implementation
 602 technique specifically prohibited by ARM 5.3.3.Was this prohibition
 603 really lifted? Does the FDIS agree with CD2 in the regard? [Issues
 604 list maintainer's note: the IS is the same.]</p>
 605 <p><b>Proposed resolution:</b></p>
 606 <p>Change the last paragraph of 3.7.3 from:</p>
 607 <blockquote>
 608   <p>Any allocation and/or deallocation functions defined in a C++ program shall
 609   conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
 610 </blockquote>
 611 <p>to:</p>
 612 <blockquote>
 613   <p>Any allocation and/or deallocation functions defined in a C++ program,
 614   including the default versions in the library, shall conform to the semantics
 615   specified in 3.7.3.1 and 3.7.3.2.</p>
 616 </blockquote>
 617 <p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
 618 <blockquote>
 619   <p>If the size of the space requested is zero, the value returned shall not be
 620   a null pointer value (4.10).</p>
 621 </blockquote>
 622 <p>to:</p>
 623 <blockquote>
 624   <p>Even if the size of the space requested is zero, the request can fail. If
 625   the request succeeds, the value returned shall be a non-null pointer value
 626   (4.10) p0 different from any previously returned value p1, unless that value
 627   p1 was since passed to an operator delete.</p>
 628 </blockquote>
 629 <p>5.3.4/7 currently reads:</p>
 630 <blockquote>
 631   <p>When the value of the expression in a direct-new-declarator is zero, the
 632   allocation function is called to allocate an array with no elements. The
 633   pointer returned by the new-expression is non-null. [Note: If the library
 634   allocation function is called, the pointer returned is distinct from the
 635   pointer to any other object.]</p>
 636 </blockquote>
 637 <p>Retain the first sentence, and delete the remainder.</p>
 638 <p>18.4.1 currently has no text. Add the following:</p>
 639 <blockquote>
 640   <p>Except where otherwise specified, the provisions of 3.7.3 apply to the
 641   library versions of operator new and operator delete.</p>
 642 </blockquote>
 643 <p>To 18.4.1.3, add the following text:</p>
 644 <blockquote>
 645   <p>The provisions of 3.7.3 do not apply to these reserved placement forms of
 646   operator new and operator delete.</p>
 647 </blockquote>
 648 <p><b>Rationale:</b></p>
 649 <p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
 650 supporting to the proposed resolution.</p>
 651 <hr>
 652 <a name="11"></a><h3><a name="11">11.&nbsp;Bitset minor problems</a></h3><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>
 653 <p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is
 654 not documented in 23.3.5.2. </p>
 655
 656 <p>(2) The class synopsis only gives a single signature for bitset&lt;&gt;::operator[],
 657 reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
 658 on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
 659
 660 <p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
 661 trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
 662 go in the Effects clause.</p>
 663 <p><b>Proposed resolution:</b></p>
 664 <p>ITEMS 1 AND 2:<br>
 665 <br>
 666 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>),
 667 replace the member function <br>
 668 <br>
 669 <tt>&nbsp;&nbsp;&nbsp; reference operator[](size_t pos);<br>
 670 </tt><br>
 671 with the two member functions<br>
 672 <br>
 673 <tt>&nbsp;&nbsp;&nbsp; bool operator[](size_t pos) const; <br>
 674 &nbsp;&nbsp;&nbsp; reference operator[](size_t pos); <br>
 675 </tt><br>
 676 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>,
 677 immediately after paragraph 45:</p>
 678
 679 <blockquote>
 680   <p><tt>bool operator[](size_t pos) const;</tt><br>
 681   Requires: pos is valid<br>
 682   Throws: nothing<br>
 683   Returns: <tt>test(pos)</tt><br>
 684   <br>
 685   <tt>bitset&lt;N&gt;::reference operator[](size_t pos);</tt> <br>
 686   Requires: pos is valid<br>
 687   Throws: nothing<br>
 688   Returns: An object of type <tt>bitset&lt;N&gt;::reference</tt> such that <tt>(*this)[pos]
 689   == this-&gt;test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this-&gt;set(pos,
 690   val);</tt></p>
 691 </blockquote>
 692 <p><b>Rationale:</b></p>
 693 <p>The LWG believes Item 3 is not a defect. "Formatted
 694 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>.
 695 </p>
 696 <hr>
 697 <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>
 698 <p>In 27.6.1.2.3, there is a reference to "eos", which is
 699 the only one in the whole draft (at least using Acrobat search), so
 700 it's undefined. </p>
 701 <p><b>Proposed resolution:</b></p>
 702 <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
 703 "charT()"</p>
 704 <hr>
 705 <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>
 706 <p>locale::combine is the only member function of locale (other than constructors and
 707 destructor) that is not const. There is no reason for it not to be const, and good reasons
 708 why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
 709 paragraph 6: "An instance of a locale is immutable." </p>
 710
 711 <p>History: this member function originally was a constructor. it happened that the
 712 interface it specified had no corresponding language syntax, so it was changed to a member
 713 function. As constructors are never const, there was no "const" in the interface
 714 which was transformed into member "combine". It should have been added at that
 715 time, but the omission was not noticed. </p>
 716 <p><b>Proposed resolution:</b></p>
 717 <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
 718 "const" to the declaration of member combine: </p>
 719 <blockquote>
 720   <pre>template &lt;class Facet&gt; locale combine(const locale&amp; other) const; </pre>
 721 </blockquote>
 722 <hr>
 723 <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>
 724 <p>locale::name() is described as returning a string that can be passed to a locale
 725 constructor, but there is no matching constructor. </p>
 726 <p><b>Proposed resolution:</b></p>
 727 <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
 728 "<tt>locale(name())</tt>" with
 729 "<tt>locale(name().c_str())</tt>".
 730 </p>
 731 <hr>
 732 <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>
 733 <p>The new virtual members ctype_byname&lt;char&gt;::do_widen and do_narrow did not get
 734 edited in properly. Instead, the member do_widen appears four times, with wrong argument
 735 lists. </p>
 736 <p><b>Proposed resolution:</b></p>
 737 <p>The correct declarations for the overloaded members
 738 <tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
 739 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>
 740 <hr>
 741 <a name="17"></a><h3><a name="17">17.&nbsp;Bad bool parsing</a></h3><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>
 742 <p>This section describes the process of parsing a text boolean value from the input
 743 stream. It does not say it recognizes either of the sequences "true" or
 744 "false" and returns the corresponding bool value; instead, it says it recognizes
 745 only one of those sequences, and chooses which according to the received value of a
 746 reference argument intended for returning the result, and reports an error if the other
 747 sequence is found. (!) Furthermore, it claims to get the names from the ctype&lt;&gt;
 748 facet rather than the numpunct&lt;&gt; facet, and it examines the "boolalpha"
 749 flag wrongly; it doesn't define the value "loc"; and finally, it computes
 750 wrongly whether to use numeric or "alpha" parsing.<br>
 751 <br>
 752 I believe the correct algorithm is "as if": </p>
 753
 754 <pre>  // in, err, val, and str are arguments.
 755   err = 0;
 756   const numpunct&lt;charT&gt;&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(str.getloc());
 757   const string_type t = np.truename(), f = np.falsename();
 758   bool tm = true, fm = true;
 759   size_t pos = 0;
 760   while (tm &amp;&amp; pos &lt; t.size() || fm &amp;&amp; pos &lt; f.size()) {
 761     if (in == end) { err = str.eofbit; }
 762     bool matched = false;
 763     if (tm &amp;&amp; pos &lt; t.size()) {
 764       if (!err &amp;&amp; t[pos] == *in) matched = true;
 765       else tm = false;
 766     }
 767     if (fm &amp;&amp; pos &lt; f.size()) {
 768       if (!err &amp;&amp; f[pos] == *in) matched = true;
 769       else fm = false;
 770     }
 771     if (matched) { ++in; ++pos; }
 772     if (pos &gt; t.size()) tm = false;
 773     if (pos &gt; f.size()) fm = false;
 774   }
 775   if (tm == fm || pos == 0) { err |= str.failbit; }
 776   else                      { val = tm; }
 777   return in;</pre>
 778
 779 <p>Notice this works reasonably when the candidate strings are both empty, or equal, or
 780 when one is a substring of the other. The proposed text below captures the logic of the
 781 code above.</p>
 782 <p><b>Proposed resolution:</b></p>
 783 <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,
 784 change "&amp;&amp;" to "&amp;".</p>
 785
 786 <p>Then, replace paragraphs 15 and 16 as follows:</p>
 787
 788 <blockquote>
 789
 790   <p>Otherwise target sequences are determined "as if" by
 791   calling the members <tt>falsename()</tt> and
 792   <tt>truename()</tt> of the facet obtained by
 793   <tt>use_facet&lt;numpunct&lt;charT&gt;&nbsp;&gt;(str.getloc())</tt>.
 794   Successive characters in the range <tt>[in,end)</tt> (see
 795   [lib.sequence.reqmts]) are obtained and matched against
 796   corresponding positions in the target sequences only as necessary to
 797   identify a unique match. The input iterator <tt>in</tt> is
 798   compared to <tt>end</tt> only when necessary to obtain a
 799   character. If and only if a target sequence is uniquely matched,
 800   <tt>val</tt> is set to the corresponding value.</p>
 801
 802 </blockquote>
 803
 804 <blockquote>
 805   <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
 806   successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
 807   <tt>str.eofbit</tt> if, when seeking another character to match, it is found that
 808   <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
 809   <tt>(str.failbit|str.eofbit)</tt>if
 810   the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
 811   <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
 812   <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
 813   <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
 814   <tt>true</tt>:"1"
 815   and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
 816   and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
 817   <tt>err==str.failbit</tt>. --end example]</p>
 818 </blockquote>
 819 <hr>
 820 <a name="18"></a><h3><a name="18">18.&nbsp;Get(...bool&amp;) omitted</a></h3><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>
 821 <p>In the list of num_get&lt;&gt; non-virtual members on page 22-23, the member
 822 that parses bool values was omitted from the list of definitions of non-virtual
 823 members, though it is listed in the class definition and the corresponding
 824 virtual is listed everywhere appropriate. </p>
 825 <p><b>Proposed resolution:</b></p>
 826 <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>
 827 another get member for bool&amp;, copied from the entry in
 828 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>
 829 <hr>
 830 <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>
 831 <p>
 832 In the definitions of codecvt&lt;&gt;::do_out and do_in, they are
 833 specified to return noconv if "no conversion is
 834 needed". This definition is too vague, and does not say
 835 normatively what is done with the buffers.
 836 </p>
 837 <p><b>Proposed resolution:</b></p>
 838 <p>
 839 Change the entry for noconv in the table under paragraph 4 in section
 840 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:
 841 </p>
 842 <blockquote>
 843   <p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
 844   and input sequence is identical to converted sequence.</p>
 845 </blockquote>
 846 <p>Change the Note in paragraph 2 to normative text as follows:</p>
 847 <blockquote>
 848   <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
 849   same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
 850   <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
 851   unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
 852 </blockquote>
 853 <hr>
 854 <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>
 855 <p>The synopsis for numpunct&lt;&gt;::do_thousands_sep, and the
 856 definition of numpunct&lt;&gt;::thousands_sep which calls it, specify
 857 that it returns a value of type char_type. Here it is erroneously
 858 described as returning a "string_type". </p>
 859 <p><b>Proposed resolution:</b></p>
 860 <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
 861 "string_type" to "char_type". </p>
 862 <hr>
 863 <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>
 864 <p>In the second table in the section, captioned "Required
 865 instantiations", the instantiations for codecvt_byname&lt;&gt;
 866 have been omitted. These are necessary to allow users to construct a
 867 locale by name from facets. </p>
 868 <p><b>Proposed resolution:</b></p>
 869 <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
 870 "Required instantiations", in the category "ctype"
 871 the lines </p>
 872
 873 <blockquote>
 874   <pre>codecvt_byname&lt;char,char,mbstate_t&gt;,
 875 codecvt_byname&lt;wchar_t,char,mbstate_t&gt; </pre>
 876 </blockquote>
 877 <hr>
 878 <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>
 879 <p>The description of basic_istream&lt;&gt;::open leaves unanswered questions about how it
 880 responds to or changes flags in the error status for the stream. A strict reading
 881 indicates that it ignores the bits and does not change them, which confuses users who do
 882 not expect eofbit and failbit to remain set after a successful open. There are three
 883 reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
 884 and eofbit on call to open(). </p>
 885 <p><b>Proposed resolution:</b></p>
 886 <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:
 887 </p>
 888
 889 <blockquote>
 890   <p>A successful open does not change the error state.</p>
 891 </blockquote>
 892 <p><b>Rationale:</b></p>
 893 <p>This may seem surprising to some users, but it's just an instance
 894 of a general rule: error flags are never cleared by the
 895 implementation. The only way error flags are are ever cleared is if
 896 the user explicitly clears them by hand.</p>
 897
 898 <p>The LWG believed that preserving this general rule was
 899 important enough so that an exception shouldn't be made just for this
 900 one case.  The resolution of this issue clarifies what the LWG
 901 believes to have been the original intent.</p>
 902
 903 <hr>
 904 <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>
 905 <p>The description of codecvt&lt;&gt;::do_out and do_in mentions a
 906 symbol "do_convert" which is not defined in the
 907 standard. This is a leftover from an edit, and should be "do_in
 908 and do_out". </p>
 909 <p><b>Proposed resolution:</b></p>
 910 <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
 911 "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
 912 or do_out". </p>
 913 <hr>
 914 <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>
 915 <p>In the description of operator&lt;&lt; applied to strings, the standard says that uses
 916 the smaller of os.width() and str.size(), to pad "as described in stage 3"
 917 elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
 918 <p><b>Proposed resolution:</b></p>
 919 <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>
 920 <br>
 921 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
 922 ..."<br>
 923 <br>
 924 to: <br>
 925 <br>
 926 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
 927 ..."</p>
 928 <hr>
 929 <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>
 930 <p>In paragraph 6, the code in the example: </p>
 931
 932 <pre>  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
 933   basic_istream&lt;charT,traits&gt;::sentry(
 934            basic_istream&lt;charT,traits&gt;&amp; is, bool noskipws = false) {
 935       ...
 936       int_type c;
 937       typedef ctype&lt;charT&gt; ctype_type;
 938       const ctype_type&amp; ctype = use_facet&lt;ctype_type&gt;(is.getloc());
 939       while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
 940         if (ctype.is(ctype.space,c)==0) {
 941           is.rdbuf()-&gt;sputbackc (c);
 942           break;
 943         }
 944       }
 945       ...
 946    }</pre>
 947
 948 <p>fails to demonstrate correct use of the facilities described. In
 949 particular, it fails to use traits operators, and specifies incorrect
 950 semantics. (E.g. it specifies skipping over the first character in the
 951 sequence without examining it.) </p>
 952 <p><b>Proposed resolution:</b></p>
 953 <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>
 954 paragraph 6.</p>
 955 <p><b>Rationale:</b></p>
 956 <p>The originally proposed replacement code for the example was not
 957 correct. The LWG tried in Kona and again in Tokyo to correct it
 958 without success. In Tokyo, an implementor reported that actual working
 959 code ran over one page in length and was quite complicated. The LWG
 960 decided that it would be counter-productive to include such a lengthy
 961 example, which might well still contain errors.</p>
 962 <hr>
 963 <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>
 964 <p>The string::erase(iterator first, iterator last) is specified to return an element one
 965 place beyond the next element after the last one erased. E.g. for the string
 966 "abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
 967 while 'd' has not been erased. </p>
 968 <p><b>Proposed resolution:</b></p>
 969 <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>
 970
 971 <blockquote>
 972   <p>Returns: an iterator which points to the element immediately following _last_ prior to
 973   the element being erased. </p>
 974 </blockquote>
 975
 976 <p>to read </p>
 977
 978 <blockquote>
 979   <p>Returns: an iterator which points to the element pointed to by _last_ prior to the
 980   other elements being erased. </p>
 981 </blockquote>
 982 <hr>
 983 <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>
 984 <p>The description of the vector form of ctype&lt;char&gt;::is can be interpreted to mean
 985 something very different from what was intended. Paragraph 4 says </p>
 986
 987 <blockquote>
 988   <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
 989   table()[(unsigned char)*p]. </p>
 990 </blockquote>
 991
 992 <p>This is intended to copy the value indexed from table()[] into the place identified in
 993 vec[]. </p>
 994 <p><b>Proposed resolution:</b></p>
 995 <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>
 996
 997 <blockquote>
 998   <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
 999   the value table()[(unsigned char)*p]. </p>
1000 </blockquote>
1001 <hr>
1002 <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>
1003 <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
1004 a function ios_base::init, which is not defined. Probably they mean
1005 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>,
1006 paragraph 3. </p>
1007 <p><b>Proposed resolution:</b></p>
1008 <p>[R12: modified to include paragraph 5.]</p>
1009
1010 <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>
1011
1012 <blockquote>
1013   <p>ios_base::init </p>
1014 </blockquote>
1015
1016 <p>to </p>
1017
1018 <blockquote>
1019   <p>basic_ios&lt;char&gt;::init </p>
1020 </blockquote>
1021
1022 <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
1023 should read </p>
1024
1025 <blockquote>
1026   <p>basic_ios&lt;wchar_t&gt;::init </p>
1027 </blockquote>
1028 <hr>
1029 <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>
1030 <p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in &lt;cctype&gt;,
1031 where they are in fact defined elsewhere to appear in &lt;clocale&gt;. </p>
1032 <p><b>Proposed resolution:</b></p>
1033 <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
1034 "&lt;cctype&gt;" to read "&lt;clocale&gt;". </p>
1035 <hr>
1036 <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>
1037 <p>Paragraph 6, says "An instance of <tt>locale</tt> is
1038 <i>immutable</i>; once a facet reference is obtained from it,
1039 ...". This has caused some confusion, because locale variables
1040 are manifestly assignable. </p>
1041 <p><b>Proposed resolution:</b></p>
1042 <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>
1043
1044 <blockquote>
1045   <p>An instance of <tt>locale</tt> is immutable; once a facet
1046   reference is obtained from it, that reference remains usable as long
1047   as the locale value itself exists.</p>
1048 </blockquote>
1049
1050 <p>with</p>
1051
1052 <blockquote>
1053   <p>Once a facet reference is obtained from a locale object by
1054   calling use_facet&lt;&gt;, that reference remains usable, and the
1055   results from member functions of it may be cached and re-used, as
1056   long as some locale object refers to that facet.</p>
1057 </blockquote>
1058 <hr>
1059 <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>
1060 <p>The description of the required state before calling virtual member
1061 basic_streambuf&lt;&gt;::pbackfail requirements is inconsistent with the conditions
1062 described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
1063 Specifically, the latter says it calls pbackfail if: </p>
1064
1065 <p>&nbsp;&nbsp;&nbsp; traits::eq(c,gptr()[-1]) is false </p>
1066
1067 <p>where pbackfail claims to require: </p>
1068
1069 <p>&nbsp;&nbsp;&nbsp; traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
1070
1071 <p>It appears that the pbackfail description is wrong. </p>
1072 <p><b>Proposed resolution:</b></p>
1073 <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>
1074
1075 <blockquote>
1076   <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
1077 </blockquote>
1078
1079 <p>to </p>
1080
1081 <blockquote>
1082   <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
1083   </p>
1084 </blockquote>
1085 <p><b>Rationale:</b></p>
1086 <p>Note deliberate reordering of arguments for clarity in addition to the correction of
1087 the argument value.</p>
1088 <hr>
1089 <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>
1090 <p>In the table defining the results from do_out and do_in, the specification for the
1091 result <i>error</i> says </p>
1092
1093 <blockquote>
1094   <p>encountered a from_type character it could not convert </p>
1095 </blockquote>
1096
1097 <p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
1098 an internT for do_out. </p>
1099 <p><b>Proposed resolution:</b></p>
1100 <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
1101 in the table for the case of _error_ with </p>
1102
1103 <blockquote>
1104   <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
1105 </blockquote>
1106 <hr>
1107 <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>
1108 <p>In paragraph 19, Effects:, members truename() and falsename are used from facet
1109 ctype&lt;charT&gt;, but it has no such members. Note that this is also a problem in
1110 22.2.2.1.2, addressed in (4). </p>
1111 <p><b>Proposed resolution:</b></p>
1112 <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:
1113 clause for member put(...., bool), replace the initialization of the
1114 string_type value s as follows: </p>
1115
1116 <blockquote>
1117   <pre>const numpunct&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(loc);
1118 string_type s = val ? np.truename() : np.falsename(); </pre>
1119 </blockquote>
1120 <hr>
1121 <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>
1122 <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
1123 named "unitbuf". Unlike other manipulators, it's not listed
1124 in synopsis. Similarly for "nounitbuf". </p>
1125 <p><b>Proposed resolution:</b></p>
1126 <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
1127 the entry for "nouppercase", the prototypes: </p>
1128
1129 <blockquote>
1130   <pre>ios_base&amp; unitbuf(ios_base&amp; str);
1131 ios_base&amp; nounitbuf(ios_base&amp; str); </pre>
1132 </blockquote>
1133 <hr>
1134 <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>
1135 <p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
1136 specified badly, so that an implementation which only keeps the last value stored appears
1137 to conform. In particular, it says: </p>
1138
1139 <p>The reference returned may become invalid after another call to the object's iword
1140 member with a different index ... </p>
1141
1142 <p>This is not idle speculation; at least one implementation was done this way. </p>
1143 <p><b>Proposed resolution:</b></p>
1144 <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
1145 paragraph 4, replace the sentence: </p>
1146
1147 <blockquote>
1148   <p>The reference returned may become invalid after another call to the object's iword
1149   [pword] member with a different index, after a call to its copyfmt member, or when the
1150   object is destroyed. </p>
1151 </blockquote>
1152
1153 <p>with: </p>
1154
1155 <blockquote>
1156   <p>The reference returned is invalid after any other operations on the object. However,
1157   the value of the storage referred to is retained, so that until the next call to copyfmt,
1158   calling iword [pword] with the same index yields another reference to the same value. </p>
1159 </blockquote>
1160
1161 <p>substituting "iword" or "pword" as appropriate. </p>
1162 <hr>
1163 <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>
1164 <p>In the overview of locale semantics, paragraph 4, is the sentence </p>
1165
1166 <blockquote>
1167   <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
1168   the standard exception bad_cast. </p>
1169 </blockquote>
1170
1171 <p>This is not supported by the definition of use_facet&lt;&gt;, and represents semantics
1172 from an old draft. </p>
1173 <p><b>Proposed resolution:</b></p>
1174 <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
1175 expression </p>
1176
1177 <blockquote>
1178   <p>(or, failing that, in the global locale) </p>
1179 </blockquote>
1180 <hr>
1181 <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>
1182 <p>It has been noticed by Esa Pulkkinen that the definition of
1183 "facet" is incomplete. In particular, a class derived from
1184 another facet, but which does not define a member <i>id</i>, cannot
1185 safely serve as the argument <i>F</i> to use_facet&lt;F&gt;(loc),
1186 because there is no guarantee that a reference to the facet instance
1187 stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
1188 <p><b>Proposed resolution:</b></p>
1189 <p>In the definition of std::use_facet&lt;&gt;(), replace the text in paragraph 1 which
1190 reads: </p>
1191
1192 <blockquote>
1193   <p>Get a reference to a facet of a locale. </p>
1194 </blockquote>
1195
1196 <p>with: </p>
1197
1198 <blockquote>
1199   <p>Requires: <tt>Facet</tt> is a facet class whose definition
1200   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>
1201 </blockquote>
1202
1203 <p><i>[
1204 Kona: strike as overspecification the text "(not inherits)"
1205 from the original resolution, which read "... whose definition
1206 contains (not inherits) the public static member
1207 <tt>id</tt>..."
1208 ]</i></p>
1209
1210 <hr>
1211 <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>
1212 <p>Following the definition of istreambuf_iterator&lt;&gt;::operator++(int) in paragraph
1213 3, the standard contains three lines of garbage text left over from a previous edit. </p>
1214
1215 <blockquote>
1216   <pre>istreambuf_iterator&lt;charT,traits&gt; tmp = *this;
1217 sbuf_-&gt;sbumpc();
1218 return(tmp); </pre>
1219 </blockquote>
1220 <p><b>Proposed resolution:</b></p>
1221 <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
1222 end of paragraph 3. </p>
1223 <hr>
1224 <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>
1225 <p>Paragraph 3 of the locale examples is a description of part of an
1226 implementation technique that has lost its referent, and doesn't mean
1227 anything. </p>
1228 <p><b>Proposed resolution:</b></p>
1229 <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
1230 initialization/identification system depends...", or (at the
1231 editor's option) replace it with a place-holder to keep the paragraph
1232 numbering the same. </p>
1233 <hr>
1234 <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>
1235 <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,
1236 which may throw an exception". However, ios_base offers no
1237 interface to set or to test badbit; those interfaces are defined in
1238 basic_ios&lt;&gt;. </p>
1239 <p><b>Proposed resolution:</b></p>
1240 <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
1241 paragraph 2, and also in paragraph 4, as follows. Replace</p>
1242
1243 <blockquote>
1244   <p>If the function fails it sets badbit, which may throw an exception.</p>
1245 </blockquote>
1246
1247 <p>with</p>
1248
1249 <blockquote>
1250   <p>If the function fails, and <tt>*this</tt> is a base sub-object of
1251   a <tt>basic_ios&lt;&gt;</tt> object or sub-object, the effect is
1252   equivalent to calling <tt>basic_ios&lt;&gt;::setstate(badbit)</tt>
1253   on the derived object (which may throw <tt>failure</tt>).</p>
1254 </blockquote>
1255
1256 <p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
1257 setstate(badbit).]</i></p>
1258
1259 <hr>
1260 <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>
1261 <p>The basic_string&lt;&gt; copy constructor: </p>
1262
1263 <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1264              size_type n = npos, const Allocator&amp; a = Allocator()); </pre>
1265
1266 <p>specifies an Allocator argument default value that is
1267 counter-intuitive. The natural choice for a the allocator to copy from
1268 is str.get_allocator(). Though this cannot be expressed in
1269 default-argument notation, overloading suffices. </p>
1270
1271 <p>Alternatively, the other containers in Clause 23 (deque, list,
1272 vector) do not have this form of constructor, so it is inconsistent,
1273 and an evident source of confusion, for basic_string&lt;&gt; to have
1274 it, so it might better be removed. </p>
1275 <p><b>Proposed resolution:</b></p>
1276 <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
1277 constructor as follows: </p>
1278
1279 <blockquote>
1280   <pre>basic_string(const basic_string&amp; str);
1281 basic_string(const basic_string&amp; str, size_type pos, size_type n = npos,
1282              const Allocator&amp; a = Allocator());</pre>
1283 </blockquote>
1284
1285 <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
1286 as above. Add to paragraph 5, Effects:</p>
1287
1288 <blockquote>
1289   <p>In the first form, the Allocator value used is copied from
1290   <tt>str.get_allocator()</tt>.</p>
1291 </blockquote>
1292 <p><b>Rationale:</b></p>
1293 <p>The LWG believes the constructor is actually broken, rather than
1294 just an unfortunate design choice.</p>
1295
1296 <p>The LWG considered two other possible resolutions:</p>
1297
1298 <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
1299 constructor as follows:</p>
1300
1301 <blockquote>
1302   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1303              size_type n = npos);
1304 basic_string(const basic_string&amp; str, size_type pos,
1305              size_type n, const Allocator&amp; a); </pre>
1306 </blockquote>
1307
1308 <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
1309 as above. Add to paragraph 5, Effects: </p>
1310
1311 <blockquote>
1312   <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
1313   value <tt>str.get_allocator()</tt>. </p>
1314 </blockquote>
1315
1316 <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
1317 the declaration of the copy constructor as follows: </p>
1318
1319 <blockquote>
1320   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1321              size_type n = npos); </pre>
1322 </blockquote>
1323
1324 <p>The proposed resolution reflects the original intent of the LWG. It
1325 was also noted by Pete Becker that this fix "will cause
1326 a small amount of existing code to now work correctly."</p>
1327
1328 <p><i>[
1329 Kona: issue editing snafu fixed - the proposed resolution now correctly
1330 reflects the LWG consensus.
1331 ]</i></p>
1332 <hr>
1333 <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>
1334 <p>Many of the specifications for iostreams specify that character
1335 values or their int_type equivalents are compared using operators ==
1336 or !=, though in other places traits::eq() or traits::eq_int_type is
1337 specified to be used throughout. This is an inconsistency; we should
1338 change uses of == and != to use the traits members instead. </p>
1339 <p><b>Proposed resolution:</b></p>
1340
1341 <p><i>[Pre-Kona: Dietmar supplied wording]</i></p>
1342
1343 <p>List of changes to clause 27:</p>
1344 <ol>
1345 <li>
1346    In lib.basic.ios.members paragraph 13 (postcondition clause for
1347    'fill(cT)') change
1348
1349 <blockquote>
1350      fillch == fill()
1351 </blockquote>
1352
1353    to
1354
1355 <blockquote>
1356      traits::eq(fillch, fill())
1357 </blockquote>
1358
1359
1360 </li>
1361 <li>
1362    In lib.istream.unformatted paragraph 7 (effects clause for
1363    'get(cT,streamsize,cT)'), third bullet, change
1364
1365 <blockquote>
1366      c == delim for the next available input character c
1367 </blockquote>
1368
1369    to
1370
1371 <blockquote>
1372      traits::eq(c, delim) for the next available input character c
1373   </blockquote>
1374
1375 </li>
1376 <li>
1377    In lib.istream.unformatted paragraph 12 (effects clause for
1378    'get(basic_streambuf&lt;cT,Tr&gt;&amp;,cT)'), third bullet, change
1379
1380 <blockquote>
1381      c == delim for the next available input character c
1382 </blockquote>
1383
1384    to
1385
1386 <blockquote>
1387      traits::eq(c, delim) for the next available input character c
1388 </blockquote>
1389
1390 </li>
1391 <li>
1392    In lib.istream.unformatted paragraph 17 (effects clause for
1393    'getline(cT,streamsize,cT)'), second bullet, change
1394
1395 <blockquote>
1396      c == delim for the next available input character c
1397 </blockquote>
1398
1399    to
1400
1401 <blockquote>
1402      traits::eq(c, delim) for the next available input character c
1403   </blockquote>
1404
1405 </li>
1406 <li>
1407    In lib.istream.unformatted paragraph 24 (effects clause for
1408    'ignore(int,int_type)'), second bullet, change
1409
1410 <blockquote>
1411      c == delim for the next available input character c
1412 </blockquote>
1413
1414    to
1415
1416 <blockquote>
1417      traits::eq_int_type(c, delim) for the next available input
1418      character c
1419 </blockquote>
1420
1421 </li>
1422 <li>
1423    In lib.istream.unformatted paragraph 25 (notes clause for
1424    'ignore(int,int_type)'), second bullet, change
1425
1426 <blockquote>
1427      The last condition will never occur if delim == traits::eof()
1428 </blockquote>
1429
1430    to
1431
1432 <blockquote>
1433      The last condition will never occur if
1434      traits::eq_int_type(delim, traits::eof()).
1435 </blockquote>
1436
1437 </li>
1438 <li>
1439    In lib.istream.sentry paragraph 6 (example implementation for the
1440    sentry constructor) change
1441
1442 <blockquote>
1443      while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
1444 </blockquote>
1445
1446    to
1447
1448 <blockquote>
1449      while (!traits::eq_int_type(c = is.rdbuf()-&gt;snextc(), traits::eof())) {
1450 </blockquote>
1451
1452 </li>
1453 </ol>
1454
1455 <p>List of changes to Chapter 21:</p>
1456
1457 <ol>
1458 <li>
1459    In lib.string::find paragraph 1 (effects clause for find()),
1460    second bullet, change
1461
1462 <blockquote>
1463      at(xpos+I) == str.at(I) for all elements ...
1464 </blockquote>
1465
1466    to
1467
1468 <blockquote>
1469      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1470 </blockquote>
1471
1472 </li>
1473 <li>
1474    In lib.string::rfind paragraph 1 (effects clause for rfind()),
1475    second bullet, change
1476
1477 <blockquote>
1478      at(xpos+I) == str.at(I) for all elements ...
1479 </blockquote>
1480
1481    to
1482
1483 <blockquote>
1484      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1485 </blockquote>
1486
1487 </li>
1488 <li>
1489    In lib.string::find.first.of paragraph 1 (effects clause for
1490    find_first_of()), second bullet, change
1491
1492 <blockquote>
1493      at(xpos+I) == str.at(I) for all elements ...
1494 </blockquote>
1495
1496    to
1497
1498 <blockquote>
1499      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1500 </blockquote>
1501
1502 </li>
1503 <li>
1504    In lib.string::find.last.of paragraph 1 (effects clause for
1505    find_last_of()), second bullet, change
1506
1507 <blockquote>
1508      at(xpos+I) == str.at(I) for all elements ...
1509 </blockquote>
1510
1511    to
1512
1513 <blockquote>
1514      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1515 </blockquote>
1516
1517 </li>
1518 <li>
1519    In lib.string::find.first.not.of paragraph 1 (effects clause for
1520    find_first_not_of()), second bullet, change
1521
1522 <blockquote>
1523      at(xpos+I) == str.at(I) for all elements ...
1524 </blockquote>
1525
1526    to
1527
1528 <blockquote>
1529      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1530 </blockquote>
1531 </li>
1532
1533 <li>
1534    In lib.string::find.last.not.of paragraph 1 (effects clause for
1535    find_last_not_of()), second bullet, change
1536
1537 <blockquote>
1538      at(xpos+I) == str.at(I) for all elements ...
1539 </blockquote>
1540
1541    to
1542
1543 <blockquote>
1544      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1545 </blockquote>
1546 </li>
1547
1548 <li>
1549    In lib.string.ios paragraph 5 (effects clause for getline()),
1550    second bullet, change
1551
1552 <blockquote>
1553      c == delim for the next available input character c
1554 </blockquote>
1555
1556    to
1557
1558 <blockquote>
1559      traits::eq(c, delim) for the next available input character c
1560 </blockquote>
1561 </li>
1562
1563 </ol>
1564
1565 <p>Notes:</p>
1566 <ul>
1567 <li>
1568   Fixing this issue highlights another sloppyness in
1569   lib.istream.unformatted paragraph 24: this clause mentions a "character"
1570   which is then compared to an 'int_type' (see item 5. in the list
1571   below). It is not clear whether this requires explicit words and
1572   if so what these words are supposed to be. A similar issue exists,
1573   BTW, for operator*() of istreambuf_iterator which returns the result
1574   of sgetc() as a character type (see lib.istreambuf.iterator::op*
1575   paragraph 1), and for operator++() of istreambuf_iterator which
1576   passes the result of sbumpc() to a constructor taking a char_type
1577   (see lib.istreambuf.iterator::operator++ paragraph 3). Similarily, the
1578   assignment operator ostreambuf_iterator passes a char_type to a function
1579   taking an int_type (see lib.ostreambuf.iter.ops paragraph 1).
1580 </li>
1581 <li>
1582   It is inconsistent to use comparisons using the traits functions in
1583   Chapter 27 while not using them in Chapter 21, especially as some
1584   of the inconsistent uses actually involve streams (eg. getline() on
1585   streams). To avoid leaving this issue open still longer due to this
1586   inconsistency (it is open since 1998), a list of changes to Chapter
1587   21 is below.
1588 </li>
1589 <li>
1590   In Chapter 24 there are several places with statements like "the end
1591   of stream is reached (streambuf_type::sgetc() returns traits::eof())"
1592   (lib.istreambuf.iterator paragraph 1, lib.ostreambuf.iter.ops
1593   paragraph 5). It is unclear whether these should be clarified to use
1594   traits::eq_int_type() for detecting traits::eof().
1595 </li>
1596 </ul>
1597
1598 <hr>
1599 <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>
1600 <p>See lib-6522 and edit-814.</p>
1601 <p><b>Proposed resolution:</b></p>
1602 <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
1603 basic_streambuf&lt;char&gt;) from:</p>
1604
1605 <pre>         virtual streambuf&lt;char&gt;* setbuf(char* s, streamsize n);</pre>
1606
1607 <p>to:</p>
1608
1609 <pre>         virtual streambuf* setbuf(char* s, streamsize n);</pre>
1610
1611 <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
1612 int_type:</p>
1613
1614 <pre>     namespace std {
1615        class strstream
1616          : public basic_iostream&lt;char&gt; {
1617        public:
1618          // Types
1619          typedef char                                char_type;
1620          typedef typename char_traits&lt;char&gt;::int_type int_type
1621          typedef typename char_traits&lt;char&gt;::pos_type pos_type;</pre>
1622 <hr>
1623 <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>
1624 <p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
1625 section has two RETURNS clauses, and they make no sense as
1626 stated. They make perfect sense, though, if you swap them. Am I
1627 correct in thinking that paragraphs 2 and 4 just got mixed up by
1628 accident?</p>
1629 <p><b>Proposed resolution:</b></p>
1630 <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>
1631 <hr>
1632 <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>
1633 <p>27.4.2.1.1, paragraph 2, says that class failure initializes the
1634 base class, exception, with exception(msg). Class exception (see
1635 18.6.1) has no such constructor.</p>
1636 <p><b>Proposed resolution:</b></p>
1637 <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>
1638
1639 <blockquote>
1640   <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
1641 </blockquote>
1642 <hr>
1643 <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>
1644 <p>Two problems</p>
1645
1646 <p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
1647 returns. Does it return f, or does it return the previous
1648 synchronization state? My guess is the latter, but the standard
1649 doesn't say so.</p>
1650
1651 <p>(2) 27.4.2.4 doesn't say what it means for streams to be
1652 synchronized with stdio.  Again, of course, I can make some
1653 guesses. (And I'm unhappy about the performance implications of those
1654 guesses, but that's another matter.)</p>
1655 <p><b>Proposed resolution:</b></p>
1656 <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>
1657 returns clause from:</p>
1658
1659 <blockquote>
1660   <p><tt>true</tt> if the standard iostream objects (27.3) are
1661   synchronized and otherwise returns <tt>false</tt>.</p>
1662 </blockquote>
1663
1664 <p>to:</p>
1665
1666 <blockquote>
1667   <p><tt>true</tt> if the previous state of the standard iostream
1668   objects (27.3) was synchronized and otherwise returns
1669   <tt>false</tt>.</p>
1670 </blockquote>
1671
1672 <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>,
1673 paragraph 2:</p>
1674
1675 <blockquote>
1676 <p>When a standard iostream object str is <i>synchronized</i> with a
1677 standard stdio stream f, the effect of inserting a character c by</p>
1678 <pre>  fputc(f, c);
1679 </pre>
1680
1681 <p>is the same as the effect of</p>
1682 <pre>  str.rdbuf()-&gt;sputc(c);
1683 </pre>
1684
1685 <p>for any sequence of characters; the effect of extracting a
1686 character c by</p>
1687 <pre>  c = fgetc(f);
1688 </pre>
1689
1690 <p>is the same as the effect of:</p>
1691 <pre>  c = str.rdbuf()-&gt;sbumpc(c);
1692 </pre>
1693
1694 <p>for any sequences of characters; and the effect of pushing
1695 back a character c by</p>
1696 <pre>  ungetc(c, f);
1697 </pre>
1698
1699 <p>is the same as the effect of</p>
1700 <pre>  str.rdbuf()-&gt;sputbackc(c);
1701 </pre>
1702
1703 <p>for any sequence of characters.  [<i>Footnote</i>: This implies
1704 that operations on a standard iostream object can be mixed arbitrarily
1705 with operations on the corresponding stdio stream.  In practical
1706 terms, synchronization usually means that a standard iostream object
1707 and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
1708 </blockquote>
1709
1710 <p><i>[pre-Copenhagen: PJP and Matt contributed the definition
1711 of "synchronization"]</i></p>
1712
1713 <p><i>[post-Copenhagen: proposed resolution was revised slightly:
1714 text was added in the non-normative footnote to say that operations
1715 on the two streams can be mixed arbitrarily.]</i></p>
1716 <hr>
1717 <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>
1718 <p>As written, ios_base has a copy constructor and an assignment
1719 operator. (Nothing in the standard says it doesn't have one, and all
1720 classes have copy constructors and assignment operators unless you
1721 take specific steps to avoid them.) However, nothing in 27.4.2 says
1722 what the copy constructor and assignment operator do. </p>
1723
1724 <p>My guess is that this was an oversight, that ios_base is, like
1725 basic_ios, not supposed to have a copy constructor or an assignment
1726 operator.</p>
1727
1728 <p>
1729 Jerry Schwarz comments: Yes, its an oversight, but in the opposite
1730 sense to what you're suggesting. At one point there was a definite
1731 intention that you could copy ios_base. It's an easy way to save the
1732 entire state of a stream for future use. As you note, to carry out
1733 that intention would have required a explicit description of the
1734 semantics (e.g. what happens to the iarray and parray stuff).
1735 </p>
1736 <p><b>Proposed resolution:</b></p>
1737 <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
1738 constructor and operator= members as being private.</p>
1739 <p><b>Rationale:</b></p>
1740 <p>The LWG believes the difficulty of specifying correct semantics
1741 outweighs any benefit of allowing ios_base objects to be copyable.</p>
1742 <hr>
1743 <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>
1744 <p>The std::sort algorithm can in general only sort a given sequence
1745 by moving around values. The list&lt;&gt;::sort() member on the other
1746 hand could move around values or just update internal pointers. Either
1747 method can leave iterators into the list&lt;&gt; dereferencable, but
1748 they would point to different things. </p>
1749
1750 <p>Does the FDIS mandate anywhere which method should be used for
1751 list&lt;&gt;::sort()?</p>
1752
1753 <p>Matt Austern comments:</p>
1754
1755 <p>I think you've found an omission in the standard. </p>
1756
1757 <p>The library working group discussed this point, and there was
1758 supposed to be a general requirement saying that list, set, map,
1759 multiset, and multimap may not invalidate iterators, or change the
1760 values that iterators point to, except when an operation does it
1761 explicitly. So, for example, insert() doesn't invalidate any iterators
1762 and erase() and remove() only invalidate iterators pointing to the
1763 elements that are being erased. </p>
1764
1765 <p>I looked for that general requirement in the FDIS, and, while I
1766 found a limited form of it for the sorted associative containers, I
1767 didn't find it for list. It looks like it just got omitted. </p>
1768
1769 <p>The intention, though, is that list&lt;&gt;::sort does not
1770 invalidate any iterators and does not change the values that any
1771 iterator points to. There would be no reason to have the member
1772 function otherwise.</p>
1773 <p><b>Proposed resolution:</b></p>
1774 <p>Add a new paragraph at the end of 23.1:</p>
1775
1776 <blockquote>
1777   <p>Unless otherwise specified (either explicitly or by defining a function in terms of
1778   other functions), invoking a container member function or passing a container as an
1779   argument to a library function shall not invalidate iterators to, or change the values of,
1780   objects within that container. </p>
1781 </blockquote>
1782 <p><b>Rationale:</b></p>
1783 <p>This was US issue CD2-23-011; it was accepted in London but the
1784 change was not made due to an editing oversight. The wording in the
1785 proposed resolution below is somewhat updated from CD2-23-011,
1786 particularly the addition of the phrase "or change the values
1787 of"</p>
1788 <hr>
1789 <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>
1790 <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:
1791 it should be titled "basic_ios&lt;&gt;() effects", not
1792 "ios_base() effects". </p>
1793
1794 <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
1795 resolution.]</p>
1796
1797 <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
1798 different things wrong with it, some of which I've already discussed
1799 with Jerry, but the most obvious mechanical sort of error is that it
1800 uses expressions like P(i) and p(i), without ever defining what sort
1801 of thing "i" is.
1802 </p>
1803
1804 <p>(The other problem is that it requires support for streampos
1805 arithmetic. This is impossible on some systems, i.e. ones where file
1806 position is a complicated structure rather than just a number. Jerry
1807 tells me that the intention was to require syntactic support for
1808 streampos arithmetic, but that it wasn't actually supposed to do
1809 anything meaningful except on platforms, like Unix, where genuine
1810 arithmetic is possible.) </p>
1811 <p><b>Proposed resolution:</b></p>
1812 <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
1813 "ios_base() effects" to "basic_ios&lt;&gt;()
1814 effects". </p>
1815 <hr>
1816 <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>
1817 <p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
1818 The important question is whether basic_ios::~basic_ios() destroys
1819 rdbuf().</p>
1820 <p><b>Proposed resolution:</b></p>
1821 <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>
1822
1823 <blockquote>
1824   <p><tt>virtual ~basic_ios();</tt></p>
1825   <p><b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
1826 </blockquote>
1827 <p><b>Rationale:</b></p>
1828 <p>The LWG reviewed the additional question of whether or not
1829 <tt>rdbuf(0)</tt> may set <tt>badbit</tt>.  The answer is
1830 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
1831 by the LWG, which removed from the original proposed resolution a
1832 footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
1833 <tt>badbit</tt>".</p>
1834 <hr>
1835 <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>
1836 <p>The class synopsis for basic_streambuf shows a (virtual)
1837 destructor, but the standard doesn't say what that destructor does. My
1838 assumption is that it does nothing, but the standard should say so
1839 explicitly. </p>
1840 <p><b>Proposed resolution:</b></p>
1841 <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>
1842
1843 <blockquote>
1844   <p><tt>virtual&nbsp; ~basic_streambuf();</tt></p>
1845   <p><b>Effects</b>: None.</p>
1846 </blockquote>
1847 <hr>
1848 <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>
1849 <p>Several member functions in clause 27 are defined in certain
1850 circumstances to return an "invalid stream position", a term
1851 that is defined nowhere in the standard. Two places (27.5.2.4.2,
1852 paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
1853 a definition in _lib.iostreams.definitions_, a nonexistent
1854 section. </p>
1855
1856 <p>I suspect that the invalid stream position is just supposed to be
1857 pos_type(-1).  Probably best to say explicitly in (for example)
1858 27.5.2.4.2 that the return value is pos_type(-1), rather than to use
1859 the term "invalid stream position", define that term
1860 somewhere, and then put in a cross-reference. </p>
1861
1862 <p>The phrase "invalid stream position" appears ten times in
1863 the C++ Standard.  In seven places it refers to a return value, and it
1864 should be changed. In three places it refers to an argument, and it
1865 should not be changed. Here are the three places where "invalid
1866 stream position" should not be changed:</p>
1867
1868 <blockquote>
1869   <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>
1870   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>
1871   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
1872   </p>
1873 </blockquote>
1874 <p><b>Proposed resolution:</b></p>
1875 <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
1876 object of class pos_type that stores an invalid stream position
1877 (_lib.iostreams.definitions_)" to "Returns
1878 <tt>pos_type(off_type(-1))</tt>".
1879 </p>
1880
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 6, change "Returns
1882 an object of class pos_type that stores an invalid stream
1883 position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
1884
1885 <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
1886 stores an invalid stream position" to "the return value is
1887 <tt>pos_type(off_type(-1))</tt>". </p>
1888
1889 <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
1890 invalid stream position (27.4.3)" to "returns
1891 <tt>pos_type(off_type(-1))</tt>" </p>
1892
1893 <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
1894 returns an invalid stream position (_lib.iostreams.definitions_)"
1895 to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
1896 </p>
1897
1898 <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
1899 stores an invalid stream position" to "the return value is
1900 <tt>pos_type(off_type(-1))</tt>" </p>
1901
1902 <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
1903 stores an invalid stream position" to "the return value is
1904 <tt>pos_type(off_type(-1))</tt>"</p>
1905 <hr>
1906 <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>
1907 <p>The class summary for basic_streambuf&lt;&gt;, in 27.5.2, says that
1908 showmanyc has return type int. However, 27.5.2.4.3 says that its
1909 return type is streamsize. </p>
1910 <p><b>Proposed resolution:</b></p>
1911 <p>Change <tt>showmanyc</tt>'s return type in the
1912 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>
1913 <hr>
1914 <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>
1915 <p>21.1.3.2, paragraph 3, says "The types streampos and
1916 wstreampos may be different if the implementation supports no shift
1917 encoding in narrow-oriented iostreams but supports one or more shift
1918 encodings in wide-oriented streams". </p>
1919
1920 <p>That's wrong: the two are the same type. The &lt;iosfwd&gt; summary
1921 in 27.2 says that streampos and wstreampos are, respectively, synonyms
1922 for fpos&lt;char_traits&lt;char&gt;::state_type&gt; and
1923 fpos&lt;char_traits&lt;wchar_t&gt;::state_type&gt;, and, flipping back
1924 to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
1925 char_traits&lt;char&gt;::state_type and
1926 char_traits&lt;wchar_t&gt;::state_type must both be mbstate_t. </p>
1927 <p><b>Proposed resolution:</b></p>
1928 <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
1929 begins "The types streampos and wstreampos may be
1930 different..." . </p>
1931 <hr>
1932 <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>
1933 <p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
1934 next pointer for the input sequence by n." </p>
1935
1936 <p>The straightforward interpretation is that it is just gptr() +=
1937 n. An alternative interpretation, though, is that it behaves as if it
1938 calls sbumpc n times. (The issue, of course, is whether it might ever
1939 call underflow.) There is a similar ambiguity in the case of
1940 pbump. </p>
1941
1942 <p>(The "classic" AT&amp;T implementation used the
1943 former interpretation.)</p>
1944 <p><b>Proposed resolution:</b></p>
1945 <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>
1946
1947 <blockquote>
1948   <p>Effects: Advances the next pointer for the input sequence by n.</p>
1949 </blockquote>
1950
1951 <p>to:</p>
1952
1953 <blockquote>
1954   <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
1955 </blockquote>
1956
1957 <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
1958 effects.</p>
1959 <hr>
1960 <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>
1961 <p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
1962 formatted input functions. Some of the functions defined in section
1963 27.6.1.2 explicitly say that those requirements apply ("Behaves
1964 like a formatted input member (as described in 27.6.1.2.1)"), but
1965 others don't. The question: is 27.6.1.2.1 supposed to apply to
1966 everything in 27.6.1.2, or only to those member functions that
1967 explicitly say "behaves like a formatted input member"? Or
1968 to put it differently: are we to assume that everything that appears
1969 in a section called "Formatted input functions" really is a
1970 formatted input function? I assume that 27.6.1.2.1 is intended to
1971 apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
1972 is not intended to apply to extractors like </p>
1973
1974 <pre>    basic_istream&amp; operator&gt;&gt;(basic_istream&amp; (*pf)(basic_istream&amp;));</pre>
1975
1976 <p>and </p>
1977
1978 <pre>    basic_istream&amp; operator&gt;&gt;(basic_streammbuf*);</pre>
1979
1980 <p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
1981 output. </p>
1982
1983 <p>Comments from Judy Ward: It seems like the problem is that the
1984 basic_istream and basic_ostream operator &lt;&lt;()'s that are used
1985 for the manipulators and streambuf* are in the wrong section and
1986 should have their own separate section or be modified to make it clear
1987 that the "Common requirements" listed in section 27.6.1.2.1
1988 (for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
1989 apply to them. </p>
1990
1991 <p>Additional comments from Dietmar Kühl: It appears to be somewhat
1992 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
1993 function" but since these functions are defined in a section
1994 labeled "Formatted input functions" it is unclear to me
1995 whether these operators are considered formatted input functions which
1996 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
1997 just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
1998 set (... but setting <tt>noskipws</tt> using the manipulator syntax
1999 would also skip whitespace :-)</p> <p>It is not clear which functions
2000 are to be considered unformatted input functions. As written, it seems
2001 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
2002 functions. However, it does not really make much sense to construct a
2003 sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
2004 unclear what happens to the <tt>gcount()</tt> if
2005 eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
2006 <tt>sync()</tt> is called: These functions don't extract characters,
2007 some of them even "unextract" a character. Should this still
2008 be reflected in <tt>gcount()</tt>? Of course, it could be read as if
2009 after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
2010 (the last unformatted input function, <tt>gcount()</tt>, didn't
2011 extract any character) and after a call to <tt>putback()</tt>
2012 <tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
2013 function <tt>putback()</tt> did "extract" back into the
2014 stream). Correspondingly for <tt>unget()</tt>. Is this what is
2015 intended?  If so, this should be clarified. Otherwise, a corresponding
2016 clarification should be used.</p>
2017 <p><b>Proposed resolution:</b></p>
2018 <p>
2019 In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
2020 Change the beginning of the second sentence from "The conversion
2021 occurs" to "These extractors behave as formatted input functions (as
2022 described in 27.6.1.2.1).  After a sentry object is constructed,
2023 the conversion occurs"
2024 </p>
2025
2026 <p>
2027 In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
2028 Add an effects clause.  "Effects: None.  This extractor does
2029 not behave as a formatted input function (as described in
2030 27.6.1.2.1).
2031 </p>
2032
2033 <p>
2034 In 27.6.1.2.3, [lib.istream::extractors], paragraph 2.  Change the
2035 effects clause to "Effects: Calls pf(*this).  This extractor does not
2036 behave as a formatted input function (as described in 27.6.1.2.1).
2037 </p>
2038
2039 <p>
2040 In 27.6.1.2.3, [lib.istream::extractors], paragraph 4.  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 12.  Change the
2047 first two sentences from "If sb is null, calls setstate(failbit),
2048 which may throw ios_base::failure (27.4.4.3).  Extracts characters
2049 from *this..." to "Behaves as a formatted input function (as described
2050 in 27.6.1.2.1).  If sb is null, calls setstate(failbit), which may
2051 throw ios_base::failure (27.4.4.3).  After a sentry object is
2052 constructed, extracts characters from *this...".
2053 </p>
2054
2055 <p>
2056 In 27.6.1.3, [lib.istream.unformatted], before paragraph 2.  Add an
2057 effects clause.  "Effects: none. This member function does not behave
2058 as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
2059 </p>
2060
2061 <p>
2062 In 27.6.1.3, [lib.istream.unformatted], paragraph 3.  Change the
2063 beginning of the first sentence of the effects clause from "Extracts a
2064 character" to "Behaves as an unformatted input function (as described
2065 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
2066 character"
2067 </p>
2068
2069 <p>
2070 In 27.6.1.3, [lib.istream.unformatted], paragraph 5.  Change the
2071 beginning of the first sentence of the effects clause from "Extracts a
2072 character" to "Behaves as an unformatted input function (as described
2073 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
2074 character"
2075 </p>
2076
2077 <p>
2078 In 27.6.1.3, [lib.istream.unformatted], paragraph 7.  Change the
2079 beginning of the first sentence of the effects clause from "Extracts
2080 characters" to "Behaves as an unformatted input function (as described
2081 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2082 characters"
2083 </p>
2084
2085 <p>
2086 [No change needed in paragraph 10, because it refers to paragraph 7.]
2087 </p>
2088
2089 <p>
2090 In 27.6.1.3, [lib.istream.unformatted], paragraph 12.  Change the
2091 beginning of the first sentence of the effects clause from "Extracts
2092 characters" to "Behaves as an unformatted input function (as described
2093 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2094 characters"
2095 </p>
2096
2097 <p>
2098 [No change needed in paragraph 15.]
2099 </p>
2100
2101 <p>
2102 In 27.6.1.3, [lib.istream.unformatted], paragraph 17.  Change the
2103 beginning of the first sentence of the effects clause from "Extracts
2104 characters" to "Behaves as an unformatted input function (as described
2105 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2106 characters"
2107 </p>
2108
2109 <p>
2110 [No change needed in paragraph 23.]
2111 </p>
2112
2113 <p>
2114 In 27.6.1.3, [lib.istream.unformatted], paragraph 24.  Change the
2115 beginning of the first sentence of the effects clause from "Extracts
2116 characters" to "Behaves as an unformatted input function (as described
2117 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2118 characters"
2119 </p>
2120
2121 <p>
2122 In 27.6.1.3, [lib.istream.unformatted], before paragraph 27.  Add an
2123 Effects clause: "Effects: Behaves as an unformatted input function (as
2124 described in 27.6.1.3, paragraph 1).  After constructing a sentry
2125 object, reads but does not extract the current input character."
2126 </p>
2127
2128 <p>
2129 In 27.6.1.3, [lib.istream.unformatted], paragraph 28.  Change the
2130 first sentence of the Effects clause from "If !good() calls" to
2131 Behaves as an unformatted input function (as described in 27.6.1.3,
2132 paragraph 1).  After constructing a sentry object, if !good() calls"
2133 </p>
2134
2135 <p>
2136 In 27.6.1.3, [lib.istream.unformatted], paragraph 30.  Change the
2137 first sentence of the Effects clause from "If !good() calls" to
2138 "Behaves as an unformatted input function (as described in 27.6.1.3,
2139 paragraph 1).  After constructing a sentry object, if !good() calls"
2140 </p>
2141
2142 <p>
2143 In 27.6.1.3, [lib.istream.unformatted], paragraph 32.  Change the
2144 first sentence of the Effects clause from "If !good() calls..." to
2145 "Behaves as an unformatted input function (as described in 27.6.1.3,
2146 paragraph 1).  After constructing a sentry object, if !good()
2147 calls..."  Add a new sentence to the end of the Effects clause:
2148 "[Note: this function extracts no characters, so the value returned
2149 by the next call to gcount() is 0.]"
2150 </p>
2151
2152 <p>
2153 In 27.6.1.3, [lib.istream.unformatted], paragraph 34.  Change the
2154 first sentence of the Effects clause from "If !good() calls" to
2155 "Behaves as an unformatted input function (as described in 27.6.1.3,
2156 paragraph 1).  After constructing a sentry object, if !good() calls".
2157 Add a new sentence to the end of the Effects clause: "[Note: this
2158 function extracts no characters, so the value returned by the next
2159 call to gcount() is 0.]"
2160 </p>
2161
2162 <p>
2163 In 27.6.1.3, [lib.istream.unformatted], paragraph 36.  Change the
2164 first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
2165 as an unformatted input function (as described in 27.6.1.3, paragraph
2166 1), except that it does not count the number of characters extracted
2167 and does not affect the value returned by subsequent calls to
2168 gcount().  After constructing a sentry object, if rdbuf() is"
2169 </p>
2170
2171 <p>
2172 In 27.6.1.3, [lib.istream.unformatted], before paragraph 37.  Add an
2173 Effects clause: "Effects: Behaves as an unformatted input function (as
2174 described in 27.6.1.3, paragraph 1), except that it does not count the
2175 number of characters extracted and does not affect the value returned
2176 by subsequent calls to gcount()."  Change the first sentence of
2177 paragraph 37 from "if fail()" to "after constructing a sentry object,
2178 if fail()".
2179 </p>
2180
2181 <p>
2182 In 27.6.1.3, [lib.istream.unformatted], paragraph 38.  Change the
2183 first sentence of the Effects clause from "If fail()" to "Behaves
2184 as an unformatted input function (as described in 27.6.1.3, paragraph
2185 1), except that it does not count the number of characters extracted
2186 and does not affect the value returned by subsequent calls to
2187 gcount().  After constructing a sentry object, if fail()
2188 </p>
2189
2190 <p>
2191 In 27.6.1.3, [lib.istream.unformatted], paragraph 40.  Change the
2192 first sentence of the Effects clause from "If fail()" to "Behaves
2193 as an unformatted input function (as described in 27.6.1.3, paragraph
2194 1), except that it does not count the number of characters extracted
2195 and does not affect the value returned by subsequent calls to
2196 gcount().  After constructing a sentry object, if fail()
2197 </p>
2198
2199 <p>
2200 In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1.  Change
2201 the beginning of the third sentence from "The formatting conversion"
2202 to "These extractors behave as formatted output functions (as
2203 described in 27.6.2.5.1).  After the sentry object is constructed, the
2204 conversion occurs".
2205 </p>
2206
2207 <p>
2208 In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1.  Add an
2209 effects clause: "Effects: None. Does not behave as a formatted output
2210 function (as described in 27.6.2.5.1).".
2211 </p>
2212
2213 <p>
2214 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2.  Change the
2215 effects clause to "Effects: calls pf(*this).  This extractor does not
2216 behave as a formatted output 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 4.  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 6.  Change the first
2227 sentence from "If sb" to "Behaves as a formatted output function (as
2228 described in 27.6.2.5.1).  After the sentry object is constructed, if
2229 sb".
2230 </p>
2231
2232 <p>
2233 In 27.6.2.6 [lib.ostream.unformatted], paragraph 2.  Change the first
2234 sentence from "Inserts the character" to "Behaves as an unformatted
2235 output function (as described in 27.6.2.6, paragraph 1).  After
2236 constructing a sentry object, inserts the character".
2237 </p>
2238
2239 <p>
2240 In 27.6.2.6 [lib.ostream.unformatted], paragraph 5.  Change the first
2241 sentence from "Obtains characters" to "Behaves as an unformatted
2242 output function (as described in 27.6.2.6, paragraph 1).  After
2243 constructing a sentry object, obtains characters".
2244 </p>
2245
2246 <p>
2247 In 27.6.2.6 [lib.ostream.unformatted], paragraph 7.  Add a new
2248 sentence at the end of the paragraph: "Does not behave as an
2249 unformatted output function (as described in 27.6.2.6, paragraph 1)."
2250 </p>
2251 <p><b>Rationale:</b></p>
2252 <p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
2253 by Judy Ward and Matt Austern.  This proposed resolution is section
2254 VI of that paper.</p>
2255 <hr>
2256 <a name="61"></a><h3><a name="61">61.&nbsp;Ambiguity in iostreams exception policy</a></h3><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
2257 <p>The introduction to the section on unformatted input (27.6.1.3)
2258 says that every unformatted input function catches all exceptions that
2259 were thrown during input, sets badbit, and then conditionally rethrows
2260 the exception. That seems clear enough. Several of the specific
2261 functions, however, such as get() and read(), are documented in some
2262 circumstances as setting eofbit and/or failbit. (The standard notes,
2263 correctly, that setting eofbit or failbit can sometimes result in an
2264 exception being thrown.) The question: if one of these functions
2265 throws an exception triggered by setting failbit, is this an exception
2266 "thrown during input" and hence covered by 27.6.1.3, or does
2267 27.6.1.3 only refer to a limited class of exceptions? Just to make
2268 this concrete, suppose you have the following snippet. </p>
2269
2270 <pre>
2271   char buffer[N];
2272   istream is;
2273   ...
2274   is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
2275   is.read(buffer, N);</pre>
2276
2277 <p>Now suppose we reach EOF before we've read N characters. What
2278 iostate bits can we expect to be set, and what exception (if any) will
2279 be thrown? </p>
2280 <p><b>Proposed resolution:</b></p>
2281 <p>
2282 In 27.6.1.3, paragraph 1, after the sentence that begins
2283 "If an exception is thrown...", add the following
2284 parenthetical comment: "(Exceptions thrown from
2285 <tt>basic_ios&lt;&gt;::clear()</tt> are not caught or rethrown.)"
2286 </p>
2287 <p><b>Rationale:</b></p>
2288 <p>The LWG looked to two alternative wordings, and choose the proposed
2289 resolution as better standardese.</p>
2290 <hr>
2291 <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>
2292 <p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
2293 "calls rdbuf()-&gt;pubsync() and, if that function returns -1
2294 ... returns traits::eof()." </p>
2295
2296 <p>That looks suspicious, because traits::eof() is of type
2297 traits::int_type while the return type of sync() is int. </p>
2298 <p><b>Proposed resolution:</b></p>
2299 <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
2300 <tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
2301 </p>
2302 <hr>
2303 <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>
2304 <p>Clause 27 details an exception-handling policy for formatted input,
2305 unformatted input, and formatted output. It says nothing for
2306 unformatted output (27.6.2.6). 27.6.2.6 should either include the same
2307 kind of exception-handling policy as in the other three places, or
2308 else it should have a footnote saying that the omission is
2309 deliberate. </p>
2310 <p><b>Proposed resolution:</b></p>
2311 <p>
2312 In 27.6.2.6, paragraph 1, replace the last sentence ("In any
2313 case, the unformatted output function ends by destroying the sentry
2314 object, then returning the value specified for the formatted output
2315 function.") with the following text:
2316 </p>
2317 <blockquote>
2318 If an exception is thrown during output, then <tt>ios::badbit</tt> is
2319 turned on [Footnote: without causing an <tt>ios::failure</tt> to be
2320 thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &amp;
2321 badbit) != 0</tt> then the exception is rethrown.  In any case, the
2322 unformatted output function ends by destroying the sentry object,
2323 then, if no exception was thrown, returning the value specified for
2324 the formatted output function.
2325 </blockquote>
2326 <p><b>Rationale:</b></p>
2327 <p>
2328 This exception-handling policy is consistent with that of formatted
2329 input, unformatted input, and formatted output.
2330 </p>
2331 <hr>
2332 <a name="64"><h3>64.&nbsp;Exception handling in <tt>basic_istream::operator&gt;&gt;(basic_streambuf*)</tt>
2333 </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>
2334 <p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
2335 different ways, depending on whether the second sentence is read as an
2336 elaboration of the first. </p>
2337 <p><b>Proposed resolution:</b></p>
2338 <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
2339 "If the function inserts no characters ..." with:</p>
2340
2341 <blockquote>
2342   <p>If the function inserts no characters, it calls
2343   <tt>setstate(failbit)</tt>, which may throw
2344   <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
2345   because it caught an exception thrown while extracting characters
2346   from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
2347   (27.4.4.3), then the caught exception is rethrown. </p>
2348 </blockquote>
2349 <hr>
2350 <a name="66"></a><h3><a name="66">66.&nbsp;Strstreambuf::setbuf</a></h3><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>
2351 <p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
2352 "Performs an operation that is defined separately for each class
2353 derived from strstreambuf". This is obviously an incorrect
2354 cut-and-paste from basic_streambuf. There are no classes derived from
2355 strstreambuf. </p>
2356 <p><b>Proposed resolution:</b></p>
2357 <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
2358 clause which currently says "Performs an operation that is
2359 defined separately for each class derived from strstreambuf"
2360 with:</p>
2361
2362 <blockquote>
2363   <p><b>Effects</b>: implementation defined, except that
2364   <tt>setbuf(0,0)</tt> has no effect.</p>
2365 </blockquote>
2366 <hr>
2367 <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>
2368 <p>Extractors for char* (27.6.1.2.3) do not store a null character
2369 after the extracted character sequence whereas the unformatted
2370 functions like get() do. Why is this?</p>
2371
2372 <p>Comment from Jerry Schwarz: There is apparently an editing
2373 glitch. You'll notice that the last item of the list of what stops
2374 extraction doesn't make any sense. It was supposed to be the line that
2375 said a null is stored.</p>
2376 <p><b>Proposed resolution:</b></p>
2377 <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
2378 item from:</p>
2379
2380 <blockquote>
2381   A null byte (<tt>charT()</tt>) in the next position, which may be
2382   the first position if no characters were extracted.
2383 </blockquote>
2384
2385 <p>to become a new paragraph which reads:</p>
2386
2387 <blockquote>
2388   Operator&gt;&gt; then stores a null byte (<tt>charT()</tt>) in the
2389   next position, which may be the first position if no characters were
2390   extracted.
2391 </blockquote>
2392 <hr>
2393 <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>
2394 <p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
2395
2396 <p>(Please note that this is entirely separate from the question of
2397 whether a vector iterator is required to be a pointer; the answer to
2398 that question is clearly "no," as it would rule out
2399 debugging implementations)</p>
2400 <p><b>Proposed resolution:</b></p>
2401 <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>,
2402 paragraph 1. </p>
2403
2404 <blockquote>
2405   <p>The elements of a vector are stored contiguously, meaning that if
2406   v is a <tt>vector&lt;T, Allocator&gt;</tt> where T is some type
2407   other than <tt>bool</tt>, then it obeys the identity <tt>&amp;v[n]
2408   == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt; v.size()</tt>.</p>
2409 </blockquote>
2410 <p><b>Rationale:</b></p>
2411 <p>The LWG feels that as a practical matter the answer is clearly
2412 "yes".  There was considerable discussion as to the best way
2413 to express the concept of "contiguous", which is not
2414 directly defined in the standard.  Discussion included:</p>
2415
2416 <ul>
2417   <li>An operational definition similar to the above proposed resolution is
2418     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>
2419   <li>There is no need to explicitly consider a user-defined operator&amp;
2420     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)
2421     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
2422     requirements for operator&amp;.</li>
2423   <li>There is no issue of one-past-the-end because of language rules.</li>
2424 </ul>
2425 <hr>
2426 <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>
2427 <p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
2428
2429 <p>uncaught_exception() doesn't have a throw specification.</p>
2430
2431 <p>It is intentional ? Does it means that one should be prepared to
2432 handle exceptions thrown from uncaught_exception() ?</p>
2433
2434 <p>uncaught_exception() is called in exception handling contexts where
2435 exception safety is very important.</p>
2436 <p><b>Proposed resolution:</b></p>
2437 <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>
2438 <hr>
2439 <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>
2440 <p>The locale facet member <tt>time_get&lt;&gt;::do_get_monthname</tt>
2441 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,
2442 consistent with do_get_weekday and with its specified use by member
2443 get_monthname. However, in the synopsis, it is specified instead with
2444 four arguments. The missing argument is the "end" iterator
2445 value.</p>
2446 <p><b>Proposed resolution:</b></p>
2447 <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
2448 the declaration of member do_monthname as follows:</p>
2449
2450 <pre>  virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&amp;,
2451                                      ios_base::iostate&amp; err, tm* t) const;</pre>
2452 <hr>
2453 <a name="74"><h3>74.&nbsp;Garbled text for <tt>codecvt::do_max_length</tt>
2454 </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>
2455 <p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
2456 clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
2457 parentheses and a spurious <b>n</b>.</p>
2458 <p><b>Proposed resolution:</b></p>
2459 <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
2460 following:</p>
2461
2462 <blockquote>
2463   <b>Returns</b>: The maximum value that
2464   <tt>do_length(state, from, from_end, 1)</tt> can return for any
2465   valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
2466   <tt>state</tt>. The specialization <tt>codecvt&lt;char, char,
2467   mbstate_t&gt;::do_max_length()</tt> returns 1.
2468 </blockquote>
2469 <hr>
2470 <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
2471 Austern&nbsp; <b>Date:</b>&nbsp; 18 Sep 1998</p>
2472 <p>The class synopses for classes <tt>codecvt&lt;&gt;</tt> (22.2.1.5)
2473 and <tt>codecvt_byname&lt;&gt;</tt> (22.2.1.6) say that the first
2474 parameter of the member functions <tt>length</tt> and
2475 <tt>do_length</tt> is of type <tt>const stateT&amp;</tt>. The member
2476 function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
2477 paragraph 9) say that the type is <tt>stateT&amp;</tt>.  Either the
2478 synopsis or the summary must be changed. </p>
2479
2480 <p>If (as I believe) the member function descriptions are correct,
2481 then we must also add text saying how <tt>do_length</tt> changes its
2482 <tt>stateT</tt> argument. </p>
2483 <p><b>Proposed resolution:</b></p>
2484 <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>,
2485 change the <tt>stateT</tt> argument type on both member
2486 <tt>length()</tt> and member <tt>do_length()</tt> from </p>
2487
2488 <blockquote>
2489   <p><tt>const stateT&amp;</tt></p>
2490 </blockquote>
2491
2492 <p>to</p>
2493
2494 <blockquote>
2495   <p><tt>stateT&amp;</tt></p>
2496 </blockquote>
2497
2498 <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
2499 <tt>do_length</tt> a paragraph:</p>
2500
2501 <blockquote>
2502   <p>Effects: The effect on the <tt>state</tt> argument is ``as if''
2503   it called <tt>do_in(state, from, from_end, from, to, to+max,
2504   to)</tt> for <tt>to</tt> pointing to a buffer of at least
2505   <tt>max</tt> elements.</p>
2506 </blockquote>
2507 <hr>
2508 <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>
2509 <p>This issue concerns the requirements on classes derived from
2510 <tt>codecvt</tt>, including user-defined classes. What are the
2511 restrictions on the conversion from external characters
2512 (e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
2513 Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
2514 the I/O library make? </p>
2515
2516 <p>The question is whether it's possible to convert from internal
2517 characters to external characters one internal character at a time,
2518 and whether, given a valid sequence of external characters, it's
2519 possible to pick off internal characters one at a time. Or, to put it
2520 differently: given a sequence of external characters and the
2521 corresponding sequence of internal characters, does a position in the
2522 internal sequence correspond to some position in the external
2523 sequence? </p>
2524
2525 <p>To make this concrete, suppose that <tt>[first, last)</tt> is a
2526 sequence of <i>M</i> external characters and that <tt>[ifirst,
2527 ilast)</tt> is the corresponding sequence of <i>N</i> internal
2528 characters, where <i>N &gt; 1</i>. That is, <tt>my_encoding.in()</tt>,
2529 applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
2530 ilast)</tt>. Now the question: does there necessarily exist a
2531 subsequence of external characters, <tt>[first, last_1)</tt>, such
2532 that the corresponding sequence of internal characters is the single
2533 character <tt>*ifirst</tt>?
2534 </p>
2535
2536 <p>(What a "no" answer would mean is that
2537 <tt>my_encoding</tt> translates sequences only as blocks. There's a
2538 sequence of <i>M</i> external characters that maps to a sequence of
2539 <i>N</i> internal characters, but that external sequence has no
2540 subsequence that maps to <i>N-1</i> internal characters.) </p>
2541
2542 <p>Some of the wording in the standard, such as the description of
2543 <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>,
2544 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
2545 possible to pick off internal characters one at a time from a sequence
2546 of external characters. However, this is never explicitly stated one
2547 way or the other. </p>
2548
2549 <p>This issue seems (and is) quite technical, but it is important if
2550 we expect users to provide their own encoding facets. This is an area
2551 where the standard library calls user-supplied code, so a well-defined
2552 set of requirements for the user-supplied code is crucial. Users must
2553 be aware of the assumptions that the library makes. This issue affects
2554 positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
2555 and several of <tt>codecvt</tt>'s member functions. </p>
2556 <p><b>Proposed resolution:</b></p>
2557 <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>
2558
2559 <blockquote>
2560 <p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
2561 (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>
2562 <pre>    do_out(state, from, from_end, from_next, to, to_lim, to_next)
2563 </pre>
2564 would return <tt>ok</tt>, where <tt>from != from_end</tt>, then
2565 <pre>    do_out(state, from, from + 1, from_next, to, to_end, to_next)
2566 </pre>
2567 must also return <tt>ok</tt>, and that if
2568 <pre>    do_in(state, from, from_end, from_next, to, to_lim, to_next)
2569 </pre>
2570 would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then
2571 <pre>    do_in(state, from, from_end, from_next, to, to + 1, to_next)
2572 </pre>
2573 <p>must also return <tt>ok</tt>.  [<i>Footnote:</i> Informally, this
2574 means that <tt>basic_filebuf</tt> assumes that the mapping from
2575 internal to external characters is 1 to N: a <tt>codecvt</tt> that is
2576 used by <tt>basic_filebuf</tt> must be able to translate characters
2577 one internal character at a time.  <i>--End Footnote</i>]</p>
2578 </blockquote>
2579
2580 <p><i>[Redmond: Minor change in proposed resolution.  Original
2581 proposed resolution talked about "success", with a parenthetical
2582 comment that success meant returning <tt>ok</tt>.  New wording
2583 removes all talk about "success", and just talks about the
2584 return value.]</i></p>
2585
2586 <p><b>Rationale:</b></p>
2587
2588   <p>The proposed resoluion says that conversions can be performed one
2589   internal character at a time.  This rules out some encodings that
2590   would otherwise be legal.  The alternative answer would mean there
2591   would be some internal positions that do not correspond to any
2592   external file position.</p>
2593   <p>
2594   An example of an encoding that this rules out is one where the
2595   <tt>internT</tt> and <tt>externT</tt> are of the same type, and
2596   where the internal sequence <tt>c1 c2</tt> corresponds to the
2597   external sequence <tt>c2 c1</tt>.
2598   </p>
2599   <p>It was generally agreed that <tt>basic_filebuf</tt> relies
2600   on this property: it was designed under the assumption that
2601   the external-to-internal mapping is N-to-1, and it is not clear
2602   that <tt>basic_filebuf</tt> is implementable without that
2603   restriction.
2604   </p>
2605   <p>
2606   The proposed resolution is expressed as a restriction on
2607   <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
2608   than a blanket restriction on all <tt>codecvt</tt> facets,
2609   because <tt>basic_filebuf</tt> is the only other part of the
2610   library that uses <tt>codecvt</tt>.  If a user wants to define
2611   a <tt>codecvt</tt> facet that implements a more general N-to-M
2612   mapping, there is no reason to prohibit it, so long as the user
2613   does not expect <tt>basic_filebuf</tt> to be able to use it.
2614   </p>
2615 <hr>
2616 <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>
2617 <p>typo: event_call_back should be event_callback &nbsp; </p>
2618 <p><b>Proposed resolution:</b></p>
2619 <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
2620 "event_call_back" to "event_callback". </p>
2621 <hr>
2622 <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>
2623 <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>
2624 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;); </pre>
2625
2626 <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>
2627 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
2628
2629 <p>Thus whether the second parameter is optional is not clear. </p>
2630 <p><b>Proposed resolution:</b></p>
2631 <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>
2632 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;);</pre>
2633
2634 <p>to:</p>
2635 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
2636 <hr>
2637 <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>
2638 <p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
2639 class complex. This redundancy should be removed.</p>
2640 <p><b>Proposed resolution:</b></p>
2641 <p>Reduce redundancy according to the general style of the standard. </p>
2642 <hr>
2643 <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>
2644 <p>Many string member functions throw if size is getting or exceeding
2645 npos. However, I wonder why they don't throw if size is getting or
2646 exceeding max_size() instead of npos.  May be npos is known at compile
2647 time, while max_size() is known at runtime. However, what happens if
2648 size exceeds max_size() but not npos, then? It seems the standard
2649 lacks some clarifications here.</p>
2650 <p><b>Proposed resolution:</b></p>
2651 <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
2652 described in this clause...") add a new paragraph:</p>
2653
2654 <blockquote>
2655   <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
2656   <tt> max_size()</tt> then
2657   the operation throws <tt>length_error</tt>.</p>
2658 </blockquote>
2659 <p><b>Rationale:</b></p>
2660 <p>The LWG believes length_error is the correct exception to throw.</p>
2661 <hr>
2662 <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>
2663 <p>The constructor from a range:</p>
2664
2665 <pre>template&lt;class InputIterator&gt;
2666          basic_string(InputIterator begin, InputIterator end,
2667                       const Allocator&amp; a = Allocator());</pre>
2668
2669 <p>lacks a throws clause. However, I would expect that it throws
2670 according to the other constructors if the numbers of characters in
2671 the range equals npos (or exceeds max_size(), see above). </p>
2672 <p><b>Proposed resolution:</b></p>
2673 <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
2674 constructors which say "Throws: length_error if n ==
2675 npos."</p>
2676 <p><b>Rationale:</b></p>
2677 <p>Throws clauses for length_error if n == npos are no longer needed
2678 because they are subsumed by the general wording added by the
2679 resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
2680 <hr>
2681 <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>
2682 <p>The effect of operator &gt;&gt; for strings contain the following item:</p>
2683
2684 <p>&nbsp;&nbsp;&nbsp; <tt>isspace(c,getloc())</tt> is true for the next available input
2685 character c.</p>
2686
2687 <p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
2688 <p><b>Proposed resolution:</b></p>
2689 <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>
2690
2691 <blockquote>
2692   <p><tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
2693 </blockquote>
2694
2695 <p>with:</p>
2696
2697 <blockquote>
2698   <p><tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
2699 </blockquote>
2700 <hr>
2701 <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>
2702 <p>Operator &gt;&gt; and getline() for strings read until eof()
2703 in the input stream is true. However, this might never happen, if the
2704 stream can't read anymore without reaching EOF. So shouldn't it be
2705 changed into that it reads until !good() ? </p>
2706 <p><b>Proposed resolution:</b></p>
2707 <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>
2708 <blockquote>
2709 Effects: Begins by constructing a sentry object k as if k were
2710 constructed by typename basic_istream&lt;charT,traits&gt;::sentry k( is). If
2711 bool( k) is true, it calls str.erase() and then extracts characters
2712 from is and appends them to str as if by calling str.append(1, c). If
2713 is.width() is greater than zero, the maximum number n of characters
2714 appended is is.width(); otherwise n is str.max_size(). Characters are
2715 extracted and appended until any of the following occurs:
2716 </blockquote>
2717 <p>with:</p>
2718 <blockquote>
2719 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
2720 sentry converts to true, calls str.erase() and then extracts
2721 characters from is and appends them to str as if by calling
2722 str.append(1,c). If is.width() is greater than zero, the maximum
2723 number n of characters appended is is.width(); otherwise n is
2724 str.max_size(). Characters are extracted and appended until any of the
2725 following occurs:
2726 </blockquote>
2727
2728 <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>
2729 <blockquote>
2730 Effects: Begins by constructing a sentry object k as if by typename
2731 basic_istream&lt;charT,traits&gt;::sentry k( is, true). If bool( k) is true,
2732 it calls str.erase() and then extracts characters from is and appends
2733 them to str as if by calling str.append(1, c) until any of the
2734 following occurs:
2735 </blockquote>
2736 <p>with:</p>
2737 <blockquote>
2738 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
2739 by subsequent calls to basic_istream&lt;&gt;::gcount().  After
2740 constructing a sentry object, if the sentry converts to true, calls
2741 str.erase() and then extracts characters from is and appends them to
2742 str as if by calling str.append(1,c) until any of the following
2743 occurs:
2744 </blockquote>
2745
2746 <p><i>[Redmond: Made changes in proposed resolution.  <tt>operator&gt;&gt;</tt>
2747 should be a formatted input function, not an unformatted input function.
2748 <tt>getline</tt> should not be required to set <tt>gcount</tt>, since
2749 there is no mechanism for <tt>gcount</tt> to be set except by one of
2750 <tt>basic_istream</tt>'s member functions.]</i></p>
2751
2752 <p><i>[Curaçao: Nico agrees with proposed resolution.]</i></p>
2753
2754 <p><b>Rationale:</b></p>
2755 <p>The real issue here is whether or not these string input functions
2756 get their characters from a streambuf, rather than by calling an
2757 istream's member functions, a streambuf signals failure either by
2758 returning eof or by throwing an exception; there are no other
2759 possibilities.  The proposed resolution makes it clear that these two
2760 functions do get characters from a streambuf.</p>
2761 <hr>
2762 <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>
2763 <p>The standard does not state, how often a function object is copied,
2764 called, or the order of calls inside an algorithm. This may lead to
2765 surprising/buggy behavior. Consider the following example: </p>
2766
2767 <pre>class Nth {    // function object that returns true for the nth element
2768   private:
2769     int nth;     // element to return true for
2770     int count;   // element counter
2771   public:
2772     Nth (int n) : nth(n), count(0) {
2773     }
2774     bool operator() (int) {
2775         return ++count == nth;
2776     }
2777 };
2778 ....
2779 // remove third element
2780     list&lt;int&gt;::iterator pos;
2781     pos = remove_if(coll.begin(),coll.end(),  // range
2782                     Nth(3)),                  // remove criterion
2783     coll.erase(pos,coll.end()); </pre>
2784
2785 <p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
2786 happens because the usual implementation of the algorithm copies the
2787 function object internally: </p>
2788
2789 <pre>template &lt;class ForwIter, class Predicate&gt;
2790 ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op)
2791 {
2792     beg = find_if(beg, end, op);
2793     if (beg == end) {
2794         return beg;
2795     }
2796     else {
2797         ForwIter next = beg;
2798         return remove_copy_if(++next, end, beg, op);
2799     }
2800 } </pre>
2801
2802 <p>The algorithm uses find_if() to find the first element that should
2803 be removed. However, it then uses a copy of the passed function object
2804 to process the resulting elements (if any). Here, Nth is used again
2805 and removes also the sixth element. This behavior compromises the
2806 advantage of function objects being able to have a state. Without any
2807 cost it could be avoided (just implement it directly instead of
2808 calling find_if()). </p>
2809 <p><b>Proposed resolution:</b></p>
2810
2811 <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>
2812 <blockquote>
2813 [Note: Unless otherwise specified, algorithms that take function
2814 objects as arguments are permitted to copy those function objects
2815 freely.  Programmers for whom object identity is important should
2816 consider using a wrapper class that points to a noncopied
2817 implementation object, or some equivalent solution.]
2818 </blockquote>
2819
2820 <p><i>[Dublin: Pete Becker felt that this may not be a defect,
2821 but rather something that programmers need to be educated about.
2822 There was discussion of adding wording to the effect that the number
2823 and order of calls to function objects, including predicates, not
2824 affect the behavior of the function object.]</i></p>
2825
2826 <p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
2827 have a clear statement of "predicate" in the
2828 standard. People including me seemed to think "a function
2829 returning a Boolean value and being able to be called by an STL
2830 algorithm or be used as sorting criterion or ... is a
2831 predicate". But a predicate has more requirements: It should
2832 never change its behavior due to a call or being copied. IMHO we have
2833 to state this in the standard. If you like, see section 8.1.4 of my
2834 library book for a detailed discussion.]</i></p>
2835
2836 <p><i>[Kona: Nico will provide wording to the effect that "unless
2837 otherwise specified, the number of copies of and calls to function
2838 objects by algorithms is unspecified".&nbsp; Consider placing in
2839 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>
2840
2841 <p><i>[Santa Cruz: The standard doesn't currently guarantee that
2842   functions object won't be copied, and what isn't forbidden is
2843   allowed.  It is believed (especially since implementations that were
2844   written in concert with the standard do make copies of function
2845   objects) that this was intentional.  Thus, no normative change is
2846   needed.  What we should put in is a non-normative note suggesting to
2847   programmers that if they want to guarantee the lack of copying they
2848   should use something like the <tt>ref</tt> wrapper.]</i></p>
2849
2850 <p><i>[Oxford: Matt provided wording.]</i></p>
2851
2852
2853 <hr>
2854 <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>
2855 <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
2856 <tt>*r++</tt> of:</p>
2857
2858 <p>&nbsp;&nbsp; <tt>{ T tmp = *r; ++r; return tmp; }</tt></p>
2859
2860 <p>There are two problems with this.  First, the return type is
2861 specified to be "T", as opposed to something like "convertible to T".
2862 This is too specific: we want to allow *r++ to return an lvalue.</p>
2863
2864 <p>Second, writing the semantics in terms of code misleadingly
2865 suggests that the effects *r++ should precisely replicate the behavior
2866 of this code, including side effects.  (Does this mean that *r++
2867 should invoke the copy constructor exactly as many times as the sample
2868 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
2869 problem.</p>
2870
2871 <p><b>Proposed resolution:</b></p>
2872 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
2873 for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".
2874 <p><b>Rationale:</b></p>
2875 <p>This issue has two parts: the return type, and the number of times
2876   the copy constructor is invoked.</p>
2877
2878 <p>The LWG believes the the first part is a real issue.  It's
2879   inappropriate for the return type to be specified so much more
2880   precisely for *r++ than it is for *r.  In particular, if r is of
2881   (say) type <tt>int*</tt>, then *r++ isn't <tt>int</tt>,
2882   but <tt>int&amp;</tt>.</p>
2883
2884 <p>The LWG does not believe that the number of times the copy
2885   constructor is invoked is a real issue.  This can vary in any case,
2886   because of language rules on copy constructor elision.  That's too
2887   much to read into these semantics clauses.</p>
2888
2889 <p>Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since
2890    we're told (24.1/3) that forward iterators satisfy all the requirements
2891    of input iterators, we can't impose any requirements in the Input
2892    Iterator requirements table that forward iterators don't satisfy.</p>
2893 <hr>
2894 <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>
2895 <p>Set::iterator is described as implementation-defined with a
2896 reference to the container requirement; the container requirement says
2897 that const_iterator is an iterator pointing to const T and iterator an
2898 iterator pointing to T.</p>
2899
2900 <p>23.1.2 paragraph 2 implies that the keys should not be modified to
2901 break the ordering of elements. But that is not clearly
2902 specified. Especially considering that the current standard requires
2903 that iterator for associative containers be different from
2904 const_iterator. Set, for example, has the following: </p>
2905
2906 <p><tt>typedef implementation defined iterator;<br>
2907 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // See _lib.container.requirements_</tt></p>
2908
2909 <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
2910 to T (table 65). Disallowing user modification of keys by changing the
2911 standard to require an iterator for associative container to be the
2912 same as const_iterator would be overkill since that will unnecessarily
2913 significantly restrict the usage of associative container. A class to
2914 be used as elements of set, for example, can no longer be modified
2915 easily without either redesigning the class (using mutable on fields
2916 that have nothing to do with ordering), or using const_cast, which
2917 defeats requiring iterator to be const_iterator. The proposed solution
2918 goes in line with trusting user knows what he is doing. </p>
2919
2920 <p><b>Other Options Evaluated:</b> </p>
2921
2922 <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
2923 first sentence, and before "In addition,...", add one line:
2924 </p>
2925
2926 <blockquote>
2927   <p>Modification of keys shall not change their strict weak ordering. </p>
2928 </blockquote>
2929
2930 <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>
2931
2932 <blockquote>
2933   <p>At the end of paragraph 5: "Keys in an associative container
2934   are immutable." At the end of paragraph 6: "For
2935   associative containers where the value type is the same as the key
2936   type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
2937   constant iterators. It is unspecified whether or not
2938   <tt>iterator</tt> and <tt>const_iterator</tt> are the same
2939   type."</p>
2940 </blockquote>
2941
2942 <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
2943 currently reads:</p>
2944
2945 <blockquote>
2946   <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
2947   comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
2948   container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
2949   == false &amp;&amp; comp(k2, k1) == false.</p>
2950 </blockquote>
2951
2952 <p>&nbsp; add the following:</p>
2953
2954 <blockquote>
2955   <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
2956   value whenever it is evaluated. [Note: If k2 is removed from the container and later
2957   reinserted, comp(k1, k2) must still return a consistent value but this value may be
2958   different than it was the first time k1 and k2 were in the same container. This is
2959   intended to allow usage like a string key that contains a filename, where comp compares
2960   file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
2961   reinserted, comp(k1, k2) must again return a consistent value but this value may be
2962   different than it was the previous time k2 was in the container.]</p>
2963 </blockquote>
2964 <p><b>Proposed resolution:</b></p>
2965 <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
2966 the indicated location:</p>
2967
2968 <blockquote>
2969   <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
2970   calling comp(k1, k2) shall always return the same
2971   value."</p>
2972   <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
2973   <p>At the end of paragraph 6: "For associative containers where the value type is the
2974   same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
2975   iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
2976   are the same type."</p>
2977 </blockquote>
2978 <p><b>Rationale:</b></p>
2979 <p>Several arguments were advanced for and against allowing set elements to be
2980 mutable as long as the ordering was not effected. The argument which swayed the
2981 LWG was one of safety; if elements were mutable, there would be no compile-time
2982 way to detect of a simple user oversight which caused ordering to be
2983 modified.  There was a report that this had actually happened in practice,
2984 and had been painful to diagnose.  If users need to modify elements,
2985 it is possible to use mutable members or const_cast.</p>
2986
2987 <p>Simply requiring that keys be immutable is not sufficient, because the comparison
2988 object may indirectly (via pointers) operate on values outside of the keys.</p>
2989
2990 <p>
2991 The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
2992 to be different types to allow for potential future work in which some
2993 member functions might be overloaded between the two types.  No such
2994 member functions exist now, and the LWG believes that user functionality
2995 will not be impaired by permitting the two types to be the same.  A
2996 function that operates on both iterator types can be defined for
2997 <tt>const_iterator</tt> alone, and can rely on the automatic
2998 conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
2999 </p>
3000
3001 <p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
3002 <hr>
3003 <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>
3004 <p>This is the only place in the whole standard where the implementation has to document
3005 something private.</p>
3006 <p><b>Proposed resolution:</b></p>
3007 <p>
3008 Remove the comment which says "// remainder implementation defined" from:
3009 </p>
3010
3011 <ul>
3012   <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>
3013 </li>
3014   <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>
3015 </li>
3016   <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>
3017 </li>
3018   <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>
3019 </li>
3020 </ul>
3021 <hr>
3022 <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>
3023 <p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
3024 exception::what() is left unspecified. This issue has implications
3025 with exception safety of exception handling: some exceptions should
3026 not throw bad_alloc.</p>
3027 <p><b>Proposed resolution:</b></p>
3028 <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
3029 clause) the sentence:</p>
3030
3031 <blockquote>
3032   <p>The return value remains valid until the exception object from which it is obtained is
3033   destroyed or a non-const member function of the exception object is called.</p>
3034 </blockquote>
3035 <p><b>Rationale:</b></p>
3036 <p>If an exception object has non-const members, they may be used
3037 to set internal state that should affect the contents of the string
3038 returned by <tt>what()</tt>.
3039 </p>
3040 <hr>
3041 <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>
3042
3043 <p>There are no versions of binders that apply to non-const elements
3044 of a sequence. This makes examples like for_each() using bind2nd() on
3045 page 521 of "The C++ Programming Language (3rd)"
3046 non-conforming. Suitable versions of the binders need to be added.</p>
3047
3048 <p>Further discussion from Nico:</p>
3049
3050 <p>What is probably meant here is shown in the following example:</p>
3051
3052 <pre>class Elem {
3053   public:
3054     void print (int i) const { }
3055     void modify (int i) { }
3056 }; </pre>
3057 <pre>int main()
3058 {
3059     vector&lt;Elem&gt; coll(2);
3060     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::print),42));    // OK
3061     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::modify),42));   // ERROR
3062 }</pre>
3063
3064 <p>The error results from the fact that bind2nd() passes its first
3065 argument (the argument of the sequence) as constant reference. See the
3066 following typical implementation:</p>
3067
3068 <blockquote>
3069   <pre>template &lt;class Operation&gt;
3070 class binder2nd
3071   : public unary_function&lt;typename Operation::first_argument_type,
3072                           typename Operation::result_type&gt; {
3073 protected:
3074   Operation op;
3075   typename Operation::second_argument_type value;
3076 public:
3077   binder2nd(const Operation&amp; o,
3078             const typename Operation::second_argument_type&amp; v)
3079       : op(o), value(v) {} </pre>
3080   <pre> typename Operation::result_type
3081   operator()(const typename Operation::first_argument_type&amp; x) const {
3082     return op(x, value);
3083   }
3084 };</pre>
3085 </blockquote>
3086
3087 <p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
3088
3089 <blockquote>
3090   <pre>template &lt;class Operation&gt;
3091 class binder2nd
3092   : public unary_function&lt;typename Operation::first_argument_type,
3093                           typename Operation::result_type&gt; {
3094 protected:
3095   Operation op;
3096   typename Operation::second_argument_type value;
3097 public:
3098   binder2nd(const Operation&amp; o,
3099             const typename Operation::second_argument_type&amp; v)
3100       : op(o), value(v) {} </pre>
3101   <pre> typename Operation::result_type
3102   operator()(const typename Operation::first_argument_type&amp; x) const {
3103     return op(x, value);
3104   }
3105   typename Operation::result_type
3106   operator()(typename Operation::first_argument_type&amp; x) const {
3107     return op(x, value);
3108   }
3109 };</pre>
3110 </blockquote>
3111 <p><b>Proposed resolution:</b></p>
3112
3113 <p><b>Howard believes there is a flaw</b> in this resolution.
3114 See c++std-lib-9127.  We may need to reopen this issue.</p>
3115
3116 <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>
3117 <blockquote>
3118   <p><tt>typename Operation::result_type<br>
3119   &nbsp;operator()(const typename Operation::second_argument_type&amp; x) const;</tt></p>
3120 </blockquote>
3121 <p>insert:</p>
3122 <blockquote>
3123   <p><tt>typename Operation::result_type<br>
3124   &nbsp;operator()(typename Operation::second_argument_type&amp; x) const;</tt></p>
3125 </blockquote>
3126 <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>
3127 <blockquote>
3128   <p><tt>typename Operation::result_type<br>
3129   &nbsp;operator()(const typename Operation::first_argument_type&amp; x) const;</tt></p>
3130 </blockquote>
3131 <p>insert:</p>
3132 <blockquote>
3133   <p><tt>typename Operation::result_type<br>
3134   &nbsp;operator()(typename Operation::first_argument_type&amp; x) const;</tt></p>
3135 </blockquote>
3136
3137 <p><i>[Kona: The LWG discussed this at some length.It was agreed that
3138 this is a mistake in the design, but there was no consensus on whether
3139 it was a defect in the Standard.  Straw vote: NAD - 5.  Accept
3140 proposed resolution - 3.  Leave open - 6.]</i></p>
3141
3142 <p><i>[Copenhagen: It was generally agreed that this was a defect.
3143 Strap poll: NAD - 0.  Accept proposed resolution - 10.
3144 Leave open - 1.]</i></p>
3145
3146 <hr>
3147 <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>
3148 <p>Member istreambuf_iterator&lt;&gt;::equal is not declared
3149 "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==,
3150 which is const, calls it. This is contradictory. </p>
3151 <p><b>Proposed resolution:</b></p>
3152 <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>,
3153 replace:</p>
3154
3155 <blockquote>
3156   <pre>bool equal(istreambuf_iterator&amp; b);</pre>
3157 </blockquote>
3158
3159 <p>with:</p>
3160
3161 <blockquote>
3162   <pre>bool equal(const istreambuf_iterator&amp; b) const;</pre>
3163 </blockquote>
3164 <hr>
3165 <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>
3166 <p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
3167 constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
3168 reads "<i>s</i> is not null". However, <i>s</i> is a
3169 reference, and references can't be null. </p>
3170 <p><b>Proposed resolution:</b></p>
3171 <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>
3172
3173 <p>Move the current paragraph 1, which reads "Requires: s is not
3174 null.", from the first constructor to the second constructor.</p>
3175
3176 <p>Insert a new paragraph 1 Requires clause for the first constructor
3177 reading:</p>
3178
3179 <blockquote>
3180   <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
3181 </blockquote>
3182 <hr>
3183 <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>
3184 <p>Section 18.4.1.3 contains the following example: </p>
3185
3186 <pre>[Example: This can be useful for constructing an object at a known address:
3187         char place[sizeof(Something)];
3188         Something* p = new (place) Something();
3189  -end example]</pre>
3190
3191 <p>First code line: "place" need not have any special alignment, and the
3192 following constructor could fail due to misaligned data.</p>
3193
3194 <p>Second code line: Aren't the parens on Something() incorrect?&nbsp; [Dublin: the LWG
3195 believes the () are correct.]</p>
3196
3197 <p>Examples are not normative, but nevertheless should not show code that is invalid or
3198 likely to fail.</p>
3199 <p><b>Proposed resolution:</b></p>
3200 <p>Replace the <u> first line of code</u> in the example in
3201 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:
3202 </p>
3203
3204 <blockquote>
3205   <pre>void* place = operator new(sizeof(Something));</pre>
3206 </blockquote>
3207 <hr>
3208 <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>
3209 <p>D.7.4.1 strstream constructors paragraph 2 says: </p>
3210
3211 <blockquote>
3212   <p>Effects: Constructs an object of class strstream, initializing the base class with
3213   iostream(&amp; sb) and initializing sb with one of the two constructors: </p>
3214   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
3215   elements. The constructor is strstreambuf(s, n, s). </p>
3216   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
3217   elements that contains an NTBS whose first element is designated by s. The constructor is
3218   strstreambuf(s, n, s+std::strlen(s)).</p>
3219 </blockquote>
3220
3221 <p>Notice the second condition is the same as the first. I think the second condition
3222 should be "If mode&amp;app==app", or "mode&amp;app!=0", meaning that
3223 the append bit is set.</p>
3224 <p><b>Proposed resolution:</b></p>
3225 <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>
3226 paragraph 2, change the first condition to <tt>(mode&amp;app)==0</tt>
3227 and the second condition to <tt>(mode&amp;app)!=0</tt>.</p>
3228 <hr>
3229 <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>
3230 <p>The <b>effects</b> clause for numeric inserters says that
3231 insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
3232 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
3233 int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
3234 <tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
3235 delegated to <tt>num_put</tt>, and that insertion is performed as if
3236 through the following code fragment: </p>
3237
3238 <pre>bool failed = use_facet&lt;
3239    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3240    &gt;(getloc()).put(*this, *this, fill(), val). failed();</pre>
3241
3242 <p>This doesn't work, because <tt>num_put&lt;&gt;</tt>::put is only
3243 overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
3244 long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
3245 void*</tt>. That is, the code fragment in the standard is incorrect
3246 (it is diagnosed as ambiguous at compile time) for the types
3247 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
3248 int</tt>, and <tt>float</tt>. </p>
3249
3250 <p>We must either add new member functions to <tt>num_put</tt>, or
3251 else change the description in <tt>ostream</tt> so that it only calls
3252 functions that are actually there. I prefer the latter. </p>
3253 <p><b>Proposed resolution:</b></p>
3254 <p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
3255
3256 <blockquote>
3257 <p>
3258 The classes num_get&lt;&gt; and num_put&lt;&gt; handle localedependent numeric
3259 formatting and parsing.  These inserter functions use the imbued
3260 locale value to perform numeric formatting.  When val is of type bool,
3261 long, unsigned long, double, long double, or const void*, the
3262 formatting conversion occurs as if it performed the following code
3263 fragment:
3264 </p>
3265
3266 <pre>bool failed = use_facet&lt;
3267    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3268    &gt;(getloc()).put(*this, *this, fill(), val). failed();
3269 </pre>
3270
3271 <p>
3272 When val is of type short the formatting conversion occurs as if it
3273 performed the following code fragment:
3274 </p>
3275
3276 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
3277 bool failed = use_facet&lt;
3278    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3279    &gt;(getloc()).put(*this, *this, fill(),
3280       baseflags == ios_base::oct || baseflags == ios_base::hex
3281          ? static_cast&lt;long&gt;(static_cast&lt;unsigned short&gt;(val))
3282          : static_cast&lt;long&gt;(val)). failed();
3283 </pre>
3284
3285 <p>
3286 When val is of type int the formatting conversion occurs as if it performed
3287 the following code fragment:
3288 </p>
3289
3290 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
3291 bool failed = use_facet&lt;
3292    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3293    &gt;(getloc()).put(*this, *this, fill(),
3294       baseflags == ios_base::oct || baseflags == ios_base::hex
3295          ? static_cast&lt;long&gt;(static_cast&lt;unsigned int&gt;(val))
3296          : static_cast&lt;long&gt;(val)). failed();
3297 </pre>
3298
3299 <p>
3300 When val is of type unsigned short or unsigned int the formatting conversion
3301 occurs as if it performed the following code fragment:
3302 </p>
3303
3304 <pre>bool failed = use_facet&lt;
3305    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3306    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;unsigned long&gt;(val)).
3307 failed();
3308 </pre>
3309
3310 <p>
3311 When val is of type float the formatting conversion occurs as if it
3312 performed the following code fragment:
3313 </p>
3314
3315 <pre>bool failed = use_facet&lt;
3316    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3317    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;double&gt;(val)).
3318 failed();
3319 </pre>
3320
3321 </blockquote>
3322
3323 <p><i>[post-Toronto: This differs from the previous proposed
3324 resolution; PJP provided the new wording.  The differences are in
3325 signed short and int output.]</i></p>
3326 <p><b>Rationale:</b></p>
3327 <p>The original proposed resolution was to cast int and short to long,
3328 unsigned int and unsigned short to unsigned long, and float to double,
3329 thus ensuring that we don't try to use nonexistent num_put&lt;&gt;
3330 member functions.  The current proposed resolution is more
3331 complicated, but gives more expected results for hex and octal output
3332 of signed short and signed int.  (On a system with 16-bit short, for
3333 example, printing short(-1) in hex format should yield 0xffff.)</p>
3334 <hr>
3335 <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>
3336 <p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
3337 <tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
3338 <tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
3339 formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
3340
3341 <pre>typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3342 iostate err = 0;
3343 use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, val);
3344 setstate(err);</pre>
3345
3346 <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,
3347 <tt>num_get&lt;&gt;::get()</tt> is only overloaded for the types
3348 <tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
3349 int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
3350 <tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
3351 <tt>void*</tt>. Comparing the lists from the two sections, we find
3352 that 27.6.1.2.2 is using a nonexistent function for types
3353 <tt>short</tt> and <tt>int</tt>. </p>
3354 <p><b>Proposed resolution:</b></p>
3355 <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
3356 two lines (1st and 3rd) which read:</p>
3357 <blockquote>
3358   <pre>operator&gt;&gt;(short&amp; val);
3359 ...
3360 operator&gt;&gt;(int&amp; val);</pre>
3361 </blockquote>
3362
3363 <p>And add the following at the end of that section (27.6.1.2.2) :</p>
3364
3365 <blockquote>
3366   <pre>operator&gt;&gt;(short&amp; val);</pre>
3367   <p>The conversion occurs as if performed by the following code fragment (using
3368   the same notation as for the preceding code fragment):</p>
3369   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3370   iostate err = 0;
3371   long lval;
3372   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
3373         if (err == 0
3374                 &amp;&amp; (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval))
3375                 err = ios_base::failbit;
3376   setstate(err);</pre>
3377   <pre>operator&gt;&gt;(int&amp; val);</pre>
3378   <p>The conversion occurs as if performed by the following code fragment (using
3379   the same notation as for the preceding code fragment):</p>
3380   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3381   iostate err = 0;
3382   long lval;
3383   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
3384         if (err == 0
3385                 &amp;&amp; (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval))
3386                 err = ios_base::failbit;
3387   setstate(err);</pre>
3388 </blockquote>
3389
3390 <p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
3391 <hr>
3392 <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>
3393 <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>
3394
3395 <p>"An implementation may strengthen the exception-specification
3396 for a function by removing listed exceptions." </p>
3397
3398 <p>The problem is that if an implementation is allowed to do this for
3399 virtual functions, then a library user cannot write a class that
3400 portably derives from that class. </p>
3401
3402 <p>For example, this would not compile if ios_base::failure::~failure
3403 had an empty exception specification: </p>
3404
3405 <pre>#include &lt;ios&gt;
3406 #include &lt;string&gt;
3407
3408 class D : public std::ios_base::failure {
3409 public:
3410         D(const std::string&amp;);
3411         ~D(); // error - exception specification must be compatible with
3412               // overridden virtual function ios_base::failure::~failure()
3413 };</pre>
3414 <p><b>Proposed resolution:</b></p>
3415 <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>
3416
3417 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
3418 exception-specification for a function"</p>
3419
3420 <p>to:</p>
3421
3422 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
3423 exception-specification for a non-virtual function". </p>
3424 <hr>
3425 <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>
3426
3427 <p>The original issue asked whether a library implementor could
3428 specialize standard library templates for built-in types.  (This was
3429 an issue because users are permitted to explicitly instantiate
3430 standard library templates.)</p>
3431
3432 <p>Specializations are no longer a problem, because of the resolution
3433 to core issue 259.  Under the proposed resolution, it will be legal
3434 for a translation unit to contain both a specialization and an
3435 explicit instantiation of the same template, provided that the
3436 specialization comes first.  In such a case, the explicit
3437 instantiation will be ignored.  Further discussion of library issue
3438 120 assumes that the core 259 resolution will be adopted.</p>
3439
3440 <p>However, as noted in lib-7047, one piece of this issue still
3441 remains: what happens if a standard library implementor explicitly
3442 instantiates a standard library templates?  It's illegal for a program
3443 to contain two different explicit instantiations of the same template
3444 for the same type in two different translation units (ODR violation),
3445 and the core working group doesn't believe it is practical to relax
3446 that restriction.</p>
3447
3448 <p>The issue, then, is: are users allowed to explicitly instantiate
3449 standard library templates for non-user defined types?  The status quo
3450 answer is 'yes'.  Changing it to 'no' would give library implementors
3451 more freedom.</p>
3452
3453 <p>This is an issue because, for performance reasons, library
3454 implementors often need to explicitly instantiate standard library
3455 templates.  (for example, std::basic_string&lt;char&gt;)  Does giving
3456 users freedom to explicitly instantiate standard library templates for
3457 non-user defined types make it impossible or painfully difficult for
3458 library implementors to do this?</p>
3459
3460 <p>John Spicer suggests, in lib-8957, that library implementors have a
3461 mechanism they can use for explicit instantiations that doesn't
3462 prevent users from performing their own explicit instantiations: put
3463 each explicit instantiation in its own object file.  (Different
3464 solutions might be necessary for Unix DSOs or MS-Windows DLLs.)  On
3465 some platforms, library implementors might not need to do anything
3466 special: the "undefined behavior" that results from having two
3467 different explicit instantiations might be harmless.</p>
3468
3469 <p><b>Proposed resolution:</b></p>
3470   <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>
3471   <blockquote>
3472     A program may explicitly instantiate any templates in the standard
3473     library only if the declaration depends on the name of a user-defined
3474     type of external linkage and the instantiation meets the standard library
3475     requirements for the original template.
3476   </blockquote>
3477
3478 <p><i>[Kona: changed the wording from "a user-defined name" to "the name of
3479   a user-defined type"]</i></p>
3480
3481 <p><b>Rationale:</b></p>
3482 <p>The LWG considered another possible resolution:</p>
3483 <blockquote>
3484   <p>In light of the resolution to core issue 259, no normative changes
3485   in the library clauses are necessary.  Add the following non-normative
3486   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>
3487   <blockquote>
3488     [<i>Note:</i> A program may explicitly instantiate standard library
3489     templates, even when an explicit instantiation does not depend on
3490     a user-defined name. <i>--end note</i>]
3491   </blockquote>
3492 </blockquote>
3493
3494 <p>The LWG rejected this because it was believed that it would make
3495   it unnecessarily difficult for library implementors to write
3496   high-quality implementations.  A program may not include an
3497   explicit instantiation of the same template, for the same template
3498   arguments, in two different translation units.  If users are
3499   allowed to provide explicit instantiations of Standard Library
3500   templates for built-in types, then library implementors aren't,
3501   at least not without nonportable tricks.</p>
3502
3503 <p>The most serious problem is a class template that has writeable
3504   static member variables.  Unfortunately, such class templates are
3505   important and, in existing Standard Library implementations, are
3506   often explicitly specialized by library implementors: locale facets,
3507   which have a writeable static member variable <tt>id</tt>.  If a
3508   user's explicit instantiation collided with the implementations
3509   explicit instantiation, iostream initialization could cause locales
3510   to be constructed in an inconsistent state.</p>
3511
3512 <p>One proposed implementation technique was for Standard Library
3513   implementors to provide explicit instantiations in separate object
3514   files, so that they would not be picked up by the linker when the
3515   user also provides an explicit instantiation.  However, this
3516   technique only applies for Standard Library implementations that
3517   are packaged as static archives.  Most Standard Library
3518   implementations nowadays are packaged as dynamic libraries, so this
3519   technique would not apply.</p>
3520
3521 <p>The Committee is now considering standardization of dynamic
3522   linking.  If there are such changes in the future, it may be
3523   appropriate to revisit this issue later.</p>
3524 <hr>
3525 <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>
3526 <p>Section 27.5.2 describes the streambuf classes this way: </p>
3527
3528 <blockquote>
3529
3530 <p>The class streambuf is a specialization of the template class basic_streambuf
3531 specialized for the type char. </p>
3532
3533 <p>The class wstreambuf is a specialization of the template class basic_streambuf
3534 specialized for the type wchar_t. </p>
3535
3536 </blockquote>
3537
3538 <p>This implies that these classes must be template specializations, not typedefs. </p>
3539
3540 <p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
3541 <p><b>Proposed resolution:</b></p>
3542 <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
3543 sentences). </p>
3544 <p><b>Rationale:</b></p>
3545 <p>The <tt>streambuf</tt>  synopsis already has a declaration for the
3546 typedefs and that is sufficient. </p>
3547 <hr>
3548 <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>
3549 <p>One of the operator= in the valarray helper arrays is const and one
3550 is not. For example, look at slice_array. This operator= in Section
3551 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>
3552
3553 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const valarray&lt;T&gt;&amp;) const;</tt> </p>
3554
3555 <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>
3556
3557 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const T&amp;); </tt></p>
3558
3559 <p>The description of the semantics for these two functions is similar. </p>
3560 <p><b>Proposed resolution:</b></p>
3561
3562 <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>
3563 <blockquote>
3564
3565    <p>In the class template definition for slice_array, replace the member
3566    function declaration</p>
3567     <pre>      void operator=(const T&amp;);
3568     </pre>
3569    <p>with</p>
3570     <pre>      void operator=(const T&amp;) const;
3571     </pre>
3572 </blockquote>
3573
3574 <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>
3575 <blockquote>
3576
3577    <p>Change the function declaration</p>
3578     <pre>      void operator=(const T&amp;);
3579     </pre>
3580    <p>to</p>
3581     <pre>      void operator=(const T&amp;) const;
3582     </pre>
3583 </blockquote>
3584
3585 <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>
3586 <blockquote>
3587
3588    <p>In the class template definition for gslice_array, replace the member
3589    function declaration</p>
3590     <pre>      void operator=(const T&amp;);
3591     </pre>
3592    <p>with</p>
3593     <pre>      void operator=(const T&amp;) const;
3594     </pre>
3595 </blockquote>
3596
3597 <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>
3598 <blockquote>
3599
3600    <p>Change the function declaration</p>
3601     <pre>      void operator=(const T&amp;);
3602     </pre>
3603    <p>to</p>
3604     <pre>      void operator=(const T&amp;) const;
3605     </pre>
3606 </blockquote>
3607
3608 <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>
3609 <blockquote>
3610
3611    <p>In the class template definition for mask_array, replace the member
3612    function declaration</p>
3613     <pre>      void operator=(const T&amp;);
3614     </pre>
3615    <p>with</p>
3616     <pre>      void operator=(const T&amp;) const;
3617     </pre>
3618 </blockquote>
3619
3620 <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>
3621 <blockquote>
3622
3623    <p>Change the function declaration</p>
3624     <pre>      void operator=(const T&amp;);
3625     </pre>
3626    <p>to</p>
3627     <pre>      void operator=(const T&amp;) const;
3628     </pre>
3629 </blockquote>
3630
3631 <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>
3632 <blockquote>
3633
3634    <p>In the class template definition for indirect_array, replace the member
3635    function declaration</p>
3636     <pre>      void operator=(const T&amp;);
3637     </pre>
3638    <p>with</p>
3639     <pre>      void operator=(const T&amp;) const;
3640     </pre>
3641 </blockquote>
3642
3643 <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>
3644 <blockquote>
3645
3646    <p>Change the function declaration</p>
3647     <pre>      void operator=(const T&amp;);
3648     </pre>
3649    <p>to</p>
3650     <pre>      void operator=(const T&amp;) const;
3651     </pre>
3652 </blockquote>
3653
3654
3655 <p><i>[Redmond: Robert provided wording.]</i></p>
3656
3657 <p><b>Rationale:</b></p>
3658 <p>There's no good reason for one version of operator= being const and
3659 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
3660 matters: these functions are now callable in more circumstances.  In
3661 many existing implementations, both versions are already const.</p>
3662 <hr>
3663 <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>
3664 <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>
3665 ctype_byname&lt;charT&gt;::do_scan_is() and do_scan_not() are declared
3666 to return a const char* not a const charT*. </p>
3667 <p><b>Proposed resolution:</b></p>
3668 <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
3669 <tt>do_scan_not()</tt> to return a <tt> const
3670 charT*</tt>. </p>
3671 <hr>
3672 <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>
3673 <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
3674 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
3675 latter appears to be correct. </p>
3676 <p><b>Proposed resolution:</b></p>
3677 <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
3678 <tt>operator!()</tt> so that the return type is
3679 <tt>valarray&lt;bool&gt;</tt>. </p>
3680 <hr>
3681 <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>
3682 <p>Typos in 22.2.1.1.2 need to be fixed.</p>
3683 <p><b>Proposed resolution:</b></p>
3684 <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>
3685
3686 <pre>   do_widen(do_narrow(c),0) == c</pre>
3687
3688 <p>to:</p>
3689
3690 <pre>   do_widen(do_narrow(c,0)) == c</pre>
3691
3692 <p>and change:</p>
3693
3694 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
3695
3696 <p>to:</p>
3697
3698 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
3699 <hr>
3700 <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>
3701 <p>There are two problems with the current <tt>auto_ptr</tt> wording
3702 in the standard: </p>
3703
3704 <p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
3705 because <tt>auto_ptr&lt;Derived&gt;::auto_ptr_ref</tt> is unrelated to
3706 <tt>auto_ptr&lt;Base&gt;::auto_ptr_ref</tt>.  <i>Also submitted by
3707 Nathan Myers, with the same proposed resolution.</i></p>
3708
3709 <p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
3710 <tt>auto_ptr_ref</tt> argument. </p>
3711
3712 <p>I have discussed these problems with my proposal coauthor, Bill
3713 Gibbons, and with some compiler and library implementors, and we
3714 believe that these problems are not desired or desirable implications
3715 of the standard. </p>
3716
3717 <p>25 Aug 1999: The proposed resolution now reflects changes suggested
3718 by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
3719 "assignment operator" to "public assignment
3720 operator", 2) changed effects to specify use of release(), 3)
3721 made the conversion to auto_ptr_ref const. </p>
3722
3723 <p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
3724 states that the conversion from auto_ptr to auto_ptr_ref should
3725 be const.  This is not acceptable, because it would allow
3726 initialization and assignment from _any_ const auto_ptr!  It also
3727 introduces an implementation difficulty in writing this conversion
3728 function -- namely, somewhere along the line, a const_cast will be
3729 necessary to remove that const so that release() may be called.  This
3730 may result in undefined behavior [7.1.5.1/4]. The conversion
3731 operator does not have to be const, because a non-const implicit
3732 object parameter may be bound to an rvalue [13.3.3.1.4/3]
3733 [13.3.1/5]. </p>
3734
3735   <p>Tokyo: The LWG removed the following from the proposed resolution:</p>
3736
3737   <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>,
3738   paragraph 2, make the conversion to auto_ptr_ref const:</p>
3739   <blockquote>
3740     <pre>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() const throw();</pre>
3741   </blockquote>
3742 <p><b>Proposed resolution:</b></p>
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, move
3744 the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
3745
3746 <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
3747 a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
3748
3749 <blockquote>
3750   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</pre>
3751 </blockquote>
3752
3753 <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>
3754
3755 <blockquote>
3756   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw()</pre>
3757
3758   <b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
3759   p</tt> that <tt>r</tt> holds a reference to.<br>
3760   <b>Returns: </b><tt>*this</tt>.
3761
3762 </blockquote>
3763 <hr>
3764 <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>
3765 <p>Currently, the standard does not specify how seekg() and seekp()
3766 indicate failure. They are not required to set failbit, and they can't
3767 return an error indication because they must return *this, i.e. the
3768 stream. Hence, it is undefined what happens if they fail. And they
3769 <i>can</i> fail, for instance, when a file stream is disconnected from the
3770 underlying file (is_open()==false) or when a wide character file
3771 stream must perform a state-dependent code conversion, etc. </p>
3772
3773 <p>The stream functions seekg() and seekp() should set failbit in the
3774 stream state in case of failure.</p>
3775 <p><b>Proposed resolution:</b></p>
3776 <p>Add to the Effects: clause of&nbsp; seekg() in
3777 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
3778 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>
3779
3780 <blockquote>
3781   <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
3782   </p>
3783 </blockquote>
3784 <p><b>Rationale:</b></p>
3785 <p>Setting failbit is the usual error reporting mechanism for streams</p>
3786 <hr>
3787 <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>
3788 <p>Table 67 (23.1.1) says that container::erase(iterator) returns an
3789 iterator. Table 69 (23.1.2) says that in addition to this requirement,
3790 associative containers also say that container::erase(iterator)
3791 returns void.  That's not an addition; it's a change to the
3792 requirements, which has the effect of making associative containers
3793 fail to meet the requirements for containers.</p>
3794 <p><b>Proposed resolution:</b></p>
3795
3796 <p>
3797 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
3798 requirements, change the return type of <tt>a.erase(q)</tt> from
3799 <tt>void</tt> to <tt>iterator</tt>.  Change the
3800 assertion/not/pre/post-condition from "erases the element pointed to
3801 by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>.
3802 Returns an iterator pointing to the element immediately following q
3803 prior to the element being erased. If no such element exists, a.end()
3804 is returned."
3805 </p>
3806
3807 <p>
3808 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
3809 requirements, change the return type of <tt>a.erase(q1, q2)</tt>
3810 from <tt>void</tt> to <tt>iterator</tt>.  Change the
3811 assertion/not/pre/post-condition from "erases the elements in the
3812 range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1,
3813 q2)</tt>.  Returns q2."
3814 </p>
3815
3816 <p>
3817 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
3818 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
3819 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
3820 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:
3821 change the signature of the first <tt>erase</tt> overload to
3822 </p>
3823 <pre>   iterator erase(iterator position);
3824 </pre>
3825 <p>and change the signature of the third <tt>erase</tt> overload to</p>
3826 <pre>  iterator erase(iterator first, iterator last);
3827 </pre>
3828
3829
3830 <p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p>
3831
3832 <p><i>[Post-Kona: the LWG agrees the return type should be
3833 <tt>iterator</tt>, not <tt>void</tt>.  (Alex Stepanov agrees too.)
3834 Matt provided wording.]</i></p>
3835
3836 <p><i>[
3837  Sydney: the proposed wording went in the right direction, but it
3838  wasn't good enough. We want to return an iterator from the range form
3839  of erase as well as the single-iterator form. Also, the wording is
3840  slightly different from the wording we have for sequences; there's no
3841  good reason for having a difference.  Matt provided new wording,
3842  which we will review at the next meeting.
3843 ]</i></p>
3844
3845 <hr>
3846 <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>
3847 <p>The description reads:</p>
3848
3849 <p>-1- Effects:</p>
3850
3851 <pre>         if (sz &gt; size())
3852            insert(end(), sz-size(), c);
3853          else if (sz &lt; size())
3854            erase(begin()+sz, end());
3855          else
3856            ;                           //  do nothing</pre>
3857
3858 <p>Obviously list::resize should not be specified in terms of random access iterators.</p>
3859 <p><b>Proposed resolution:</b></p>
3860 <p>Change 23.2.2.2 paragraph 1 to:</p>
3861
3862 <p>Effects:</p>
3863
3864 <pre>         if (sz &gt; size())
3865            insert(end(), sz-size(), c);
3866          else if (sz &lt; size())
3867          {
3868            iterator i = begin();
3869            advance(i, sz);
3870            erase(i, end());
3871          }</pre>
3872
3873 <p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
3874 with David Abrahams. They had a discussion and believe there is
3875 no issue of exception safety with the proposed resolution.]</i></p>
3876 <hr>
3877 <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>
3878 <p>The title says it all.</p>
3879 <p><b>Proposed resolution:</b></p>
3880 <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,
3881 after operator= in the map declaration:</p>
3882
3883 <pre>    allocator_type get_allocator() const;</pre>
3884 <hr>
3885 <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>
3886 <p>The complexity description says: "It does at most 2N calls to the copy constructor
3887 of T and logN reallocations if they are just input iterators ...".</p>
3888
3889 <p>This appears to be overly restrictive, dictating the precise memory/performance
3890 tradeoff for the implementor.</p>
3891 <p><b>Proposed resolution:</b></p>
3892 <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>
3893
3894 <p>-1- Complexity: The constructor template &lt;class
3895 InputIterator&gt; vector(InputIterator first, InputIterator last)
3896 makes only N calls to the copy constructor of T (where N is the
3897 distance between first and last) and no reallocations if iterators
3898 first and last are of forward, bidirectional, or random access
3899 categories. It makes order N calls to the copy constructor of T and
3900 order logN reallocations if they are just input iterators.
3901 </p>
3902 <p><b>Rationale:</b></p>
3903 <p>"at most 2N calls" is correct only if the growth factor
3904 is greater than or equal to 2.
3905 </p>
3906 <hr>
3907 <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>
3908 <p>I may be misunderstanding the intent, but should not seekg set only
3909 the input stream and seekp set only the output stream? The description
3910 seems to say that each should set both input and output streams. If
3911 that's really the intent, I withdraw this proposal.</p>
3912 <p><b>Proposed resolution:</b></p>
3913 <p>In section 27.6.1.3 change:</p>
3914
3915 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
3916 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
3917
3918 <p>To:</p>
3919
3920 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
3921 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::in). </pre>
3922
3923 <p>In section 27.6.1.3 change:</p>
3924
3925 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
3926 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
3927
3928 <p>To:</p>
3929
3930 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
3931 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::in). </pre>
3932
3933 <p>In section 27.6.2.4, paragraph 2 change:</p>
3934
3935 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
3936
3937 <p>To:</p>
3938
3939 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::out). </pre>
3940
3941 <p>In section 27.6.2.4, paragraph 4 change:</p>
3942
3943 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
3944
3945 <p>To:</p>
3946
3947 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::out). </pre>
3948
3949 <p><i>[Dublin: Dietmar Kühl thinks this is probably correct, but would
3950 like the opinion of more iostream experts before taking action.]</i></p>
3951
3952 <p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
3953 incorrect, his implementation already implements the Proposed
3954 Resolution.]</i></p>
3955
3956 <p><i>[Post-Tokyo: Matt Austern comments:<br>
3957 Is it a problem with basic_istream and basic_ostream, or is it a problem
3958 with basic_stringbuf?
3959 We could resolve the issue either by changing basic_istream and
3960 basic_ostream, or by changing basic_stringbuf. I prefer the latter
3961 change (or maybe both changes): I don't see any reason for the standard to
3962 require that std::stringbuf s(std::string("foo"), std::ios_base::in);
3963 s.pubseekoff(0, std::ios_base::beg); must fail.<br>
3964 This requirement is a bit weird. There's no similar requirement
3965 for basic_streambuf&lt;&gt;::seekpos, or for basic_filebuf&lt;&gt;::seekoff or
3966 basic_filebuf&lt;&gt;::seekpos.]</i></p>
3967 <hr>
3968 <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>
3969 <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>
3970
3971 <p>-4- In the call to use_facet&lt;Facet&gt;(loc), the type argument
3972 chooses a facet, making available all members of the named type. If
3973 Facet is not present in a locale (or, failing that, in the global
3974 locale), it throws the standard exception bad_cast. A C++ program can
3975 check if a locale implements a particular facet with the template
3976 function has_facet&lt;Facet&gt;(). </p>
3977
3978 <p>This contradicts the specification given in section
3979 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>:
3980 <br><br>
3981 template &lt;class&nbsp; Facet&gt; const&nbsp; Facet&amp; use_facet(const
3982 locale&amp;&nbsp; loc); <br>
3983 <br>
3984 -1- Get a reference to a facet of a locale. <br>
3985 -2- Returns: a reference to the corresponding facet of loc, if present. <br>
3986 -3- Throws: bad_cast if has_facet&lt;Facet&gt;(loc) is false. <br>
3987 -4- Notes: The reference returned remains valid at least as long as any copy of loc exists
3988 </p>
3989 <p><b>Proposed resolution:</b></p>
3990 <p>Remove the phrase "(or, failing that, in the global locale)"
3991 from section 22.1.1. </p>
3992 <p><b>Rationale:</b></p>
3993 <p>Needed for consistency with the way locales are handled elsewhere
3994 in the standard.</p>
3995 <hr>
3996 <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>
3997 <p>The sentence introducing the Optional sequence operation table
3998 (23.1.1 paragraph 12) has two problems:</p>
3999
4000 <p>A. It says ``The operations in table 68 are provided only for the containers for which
4001 they take constant time.''<br>
4002 <br>
4003 That could be interpreted in two ways, one of them being ``Even though table 68 shows
4004 particular operations as being provided, implementations are free to omit them if they
4005 cannot implement them in constant time.''<br>
4006 <br>
4007 B. That paragraph says nothing about amortized constant time, and it should.&nbsp;</p>
4008 <p><b>Proposed resolution:</b></p>
4009 <p>Replace the wording in 23.1.1 paragraph 12&nbsp; which begins ``The operations in table 68 are provided only..."
4010 with:</p>
4011
4012 <blockquote>
4013   <p>Table 68 lists sequence operations that are provided for some types of sequential
4014   containers but not others. An implementation shall provide these operations for all
4015   container types shown in the ``container'' column, and shall implement them so as to take
4016   amortized constant time.</p>
4017 </blockquote>
4018 <hr>
4019 <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>
4020 <p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
4021 say:<br>
4022 <br>
4023 &#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();</tt></p>
4024
4025 <p>Surely the document meant to say ``<tt>xpos &lt; size()</tt>'' in both places.</p>
4026
4027 <p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
4028 proposed resolution.]</i></p>
4029 <p><b>Proposed resolution:</b></p>
4030 <p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
4031 <br>
4032 &#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();<br>
4033 <br>
4034 </tt>to:<br>
4035 <tt><br>
4036 </tt>&#8212; <tt>xpos &lt;= pos</tt> and <tt>xpos &lt; size();</tt></p>
4037 <hr>
4038 <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>
4039 <p>The lexicographical_compare complexity is specified as:<br>
4040 <br>
4041 &nbsp;&nbsp;&nbsp;&nbsp; "At most min((last1 - first1), (last2 - first2))
4042 applications of the corresponding comparison."<br>
4043 <br>
4044 The best I can do is twice that expensive.</p>
4045
4046 <p>Nicolai Josuttis comments in lib-6862: You mean, to check for
4047 equality you have to check both &lt; and &gt;? Yes, IMO you are
4048 right! (and Matt states this complexity in his book)</p>
4049
4050 <p><b>Proposed resolution:</b></p>
4051 <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>
4052     <blockquote>
4053     At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
4054     applications of the corresponding comparison.
4055     </blockquote>
4056
4057 <p>Change the example at the end of paragraph 3 to read:</p>
4058     <blockquote>
4059     [Example:<br>
4060     <br>
4061     &nbsp;&nbsp;&nbsp; for ( ; first1 != last1 &amp;&amp; first2 != last2 ;
4062     ++first1, ++first2) {<br>
4063     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first1 &lt; *first2) return true;<br>
4064     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first2 &lt; *first1) return false;<br>
4065     &nbsp;&nbsp;&nbsp; }<br>
4066     &nbsp;&nbsp;&nbsp; return first1 == last1 &amp;&amp; first2 != last2;<br>
4067     &nbsp;&nbsp;&nbsp;<br>
4068     --end example]
4069     </blockquote>
4070 <hr>
4071 <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>
4072 <p>In 23.2.1.1 paragraph 6, the deque ctor that takes an iterator range appears
4073 to have complexity requirements which are incorrect, and which contradict the
4074 complexity requirements for insert(). I suspect that the text in question,
4075 below, was taken from vector:</p>
4076 <blockquote>
4077   <p>Complexity: If the iterators first and last are forward iterators,
4078   bidirectional iterators, or random access iterators the constructor makes only
4079   N calls to the copy constructor, and performs no reallocations, where N is
4080   last - first.</p>
4081 </blockquote>
4082 <p>The word "reallocations" does not really apply to deque. Further,
4083 all of the following appears to be spurious:</p>
4084 <blockquote>
4085   <p>It makes at most 2N calls to the copy constructor of T and log N
4086   reallocations if they are input iterators.1)</p>
4087   <p>1) The complexity is greater in the case of input iterators because each
4088   element must be added individually: it is impossible to determine the distance
4089   between first abd last before doing the copying.</p>
4090 </blockquote>
4091 <p>This makes perfect sense for vector, but not for deque. Why should deque gain
4092 an efficiency advantage from knowing in advance the number of elements to
4093 insert?</p>
4094 <p><b>Proposed resolution:</b></p>
4095 <p>In 23.2.1.1 paragraph 6, replace the Complexity description, including the
4096 footnote, with the following text (which also corrects the "abd"
4097 typo):</p>
4098 <blockquote>
4099   <p>Complexity: Makes last - first calls to the copy constructor of T.</p>
4100 </blockquote>
4101 <hr>
4102 <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>
4103 <p>The <u> extractor</u> for complex numbers is specified as:&nbsp;</p>
4104
4105 <blockquote>
4106
4107 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4108      basic_istream&lt;charT, traits&gt;&amp;&nbsp;<br>
4109      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;  is, complex&lt;T&gt;&amp;  x);<br>
4110 &nbsp;<br>
4111 Effects: Extracts a complex number x of the form: u, (u), or (u,v),
4112 where u is the real part and v is the imaginary part
4113 (lib.istream.formatted).&nbsp;<br>
4114 Requires: The input values be convertible to T. If bad input is
4115 encountered, calls is.setstate(ios::failbit) (which may throw
4116 ios::failure (lib.iostate.flags).&nbsp;<br>
4117 Returns: is .</p>
4118
4119 </blockquote>
4120 <p>Is it intended that the extractor for complex numbers does not skip
4121 whitespace, unlike all other extractors in the standard library do?
4122 Shouldn't a sentry be used?&nbsp;<br>
4123 <br>
4124 The <u>inserter</u> for complex numbers is specified as:</p>
4125
4126 <blockquote>
4127
4128 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4129      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
4130      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;  o, const complex&lt;T&gt;&amp;  x);<br>
4131 <br>
4132 Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
4133 <br>
4134      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)&nbsp;<br>
4137      {&nbsp;<br>
4138              basic_ostringstream&lt;charT, traits&gt; s;&nbsp;<br>
4139              s.flags(o.flags());&nbsp;<br>
4140              s.imbue(o.getloc());&nbsp;<br>
4141              s.precision(o.precision());&nbsp;<br>
4142              s &lt;&lt; '(' &lt;&lt; x.real() &lt;&lt; "," &lt;&lt; x.imag() &lt;&lt; ')';&nbsp;<br>
4143              return o &lt;&lt; s.str();&nbsp;<br>
4144      }</p>
4145
4146 </blockquote>
4147
4148 <p>Is it intended that the inserter for complex numbers ignores the
4149 field width and does not do any padding? If, with the suggested
4150 implementation above, the field width were set in the stream then the
4151 opening parentheses would be adjusted, but the rest not, because the
4152 field width is reset to zero after each insertion.</p>
4153
4154 <p>I think that both operations should use sentries, for sake of
4155 consistency with the other inserters and extractors in the
4156 library. Regarding the issue of padding in the inserter, I don't know
4157 what the intent was.&nbsp;</p>
4158 <p><b>Proposed resolution:</b></p>
4159 <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
4160 Notes clause:</p>
4161
4162 <blockquote>
4163
4164 <p>Notes: This extraction is performed as a series of simpler
4165 extractions. Therefore, the skipping of whitespace is specified to be the
4166 same for each of the simpler extractions.</p>
4167
4168 </blockquote>
4169 <p><b>Rationale:</b></p>
4170 <p>For extractors, the note is added to make it clear that skipping whitespace
4171 follows an "all-or-none" rule.</p>
4172
4173 <p>For inserters, the LWG believes there is no defect; the standard is correct
4174 as written.</p>
4175 <hr>
4176 <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>
4177 <p>The library had many global functions until 17.4.1.1 [lib.contents]
4178 paragraph 2 was added: </p>
4179
4180 <blockquote>
4181
4182 <p>All library entities except macros, operator new and operator
4183 delete are defined within the namespace std or namespaces nested
4184 within namespace std. </p>
4185
4186 </blockquote>
4187
4188 <p>It appears "global function" was never updated in the following: </p>
4189
4190 <blockquote>
4191
4192 <p>17.4.4.3 - Global functions [lib.global.functions]<br>
4193 <br>
4194 -1- It is unspecified whether any global functions in the C++ Standard
4195 Library are defined as inline (dcl.fct.spec).<br>
4196 <br>
4197 -2- A call to a global function signature described in Clauses
4198 lib.language.support through lib.input.output behaves the same as if
4199 the implementation declares no additional global function
4200 signatures.*<br>
4201 <br>
4202     [Footnote: A valid C++ program always calls the expected library
4203     global function. An implementation may also define additional
4204     global functions that would otherwise not be called by a valid C++
4205     program. --- end footnote]<br>
4206 <br>
4207 -3- A global function cannot be declared by the implementation as
4208 taking additional default arguments.&nbsp;<br>
4209 <br>
4210 17.4.4.4 - Member functions [lib.member.functions]<br>
4211 <br>
4212 -2- An implementation can declare additional non-virtual member
4213 function signatures within a class: </p>
4214
4215   <blockquote>
4216
4217 <p>-- by adding arguments with default values to a member function
4218 signature; The same latitude does not extend to the implementation of
4219 virtual or global functions, however. </p>
4220
4221   </blockquote>
4222 </blockquote>
4223 <p><b>Proposed resolution:</b></p>
4224 <p>     Change "global" to "global or non-member" in:</p>
4225 <blockquote>
4226   <p>17.4.4.3 [lib.global.functions] section title,<br>
4227   17.4.4.3 [lib.global.functions] para 1,<br>
4228   17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2
4229            places in the footnote,<br>
4230   17.4.4.3 [lib.global.functions] para 3,<br>
4231   17.4.4.4 [lib.member.functions] para 2</p>
4232 </blockquote>
4233 <p><b>Rationale:</b></p>
4234 <p>
4235 Because operator new and delete are global, the proposed resolution
4236 was changed from "non-member" to "global or non-member.
4237 </p>
4238 <hr>
4239 <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>
4240 <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
4241 do_falsename() functions in the example facet BoolNames should be
4242 const. The functions they are overriding in
4243 numpunct_byname&lt;char&gt; are const. </p>
4244 <p><b>Proposed resolution:</b></p>
4245 <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
4246 two places:</p>
4247 <blockquote>
4248   <p><tt>string do_truename() const { return "Oui Oui!"; }<br>
4249   string do_falsename() const { return "Mais Non!"; }</tt></p>
4250 </blockquote>
4251 <hr>
4252 <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>
4253 <p><b>Proposed resolution:</b></p>
4254 <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>
4255
4256 <blockquote>
4257 <p>Returns: The first iterator i in the range [first1, last1) such
4258 that for some <u>integer</u> j in the range [first2, last2) ...</p>
4259 </blockquote>
4260
4261 <p>to:</p>
4262
4263 <blockquote>
4264 <p>Returns: The first iterator i in the range [first1, last1) such
4265 that for some iterator j in the range [first2, last2) ...</p>
4266 </blockquote>
4267 <hr>
4268 <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>
4269 <p>For both sequences and associative containers, a.clear() has the
4270 semantics of erase(a.begin(),a.end()), which is undefined for an empty
4271 container since erase(q1,q2) requires that q1 be dereferenceable
4272 (23.1.1,3 and 23.1.2,7).  When the container is empty, a.begin() is
4273 not dereferenceable.<br>
4274 <br>
4275 The requirement that q1 be unconditionally dereferenceable causes many
4276 operations to be intuitively undefined, of which clearing an empty
4277 container is probably the most dire.<br>
4278 <br>
4279 Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
4280 q2) is required to be a valid range, stating that q1 and q2 must be
4281 iterators or certain kinds of iterators is unnecessary.
4282 </p>
4283 <p><b>Proposed resolution:</b></p>
4284 <p>In 23.1.1, paragraph 3, change:</p>
4285 <blockquote>
4286   <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>
4287 </blockquote>
4288 <p>to:</p>
4289 <blockquote>
4290   <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range<u>
4291   in a</u></p>
4292 </blockquote>
4293 <p>In 23.1.2, paragraph 7, change:</p>
4294 <blockquote>
4295   <p>p and q2 are valid iterators to a, q <u> and q1</u> are valid dereferenceable
4296   iterators to a, [q1, q2) is a valid range</p>
4297 </blockquote>
4298 <p>to</p>
4299 <blockquote>
4300   <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
4301   <u>into a</u></p>
4302 </blockquote>
4303 <hr>
4304 <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>
4305 <p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
4306 because there is no function <tt>is()</tt> which only takes a character as
4307 argument. Also, in the effects clause (paragraph 3), the semantic is also kept
4308 vague.</p>
4309 <p><b>Proposed resolution:</b></p>
4310 <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
4311 clause from:</p>
4312 <blockquote>
4313   <p>"... such that <tt>is(*p)</tt>
4314 would..."</p>
4315 </blockquote>
4316 <p>to:&nbsp; "... such that <tt>is(m, *p)</tt>
4317  would...."</p>
4318 <hr>
4319 <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>
4320 <p>The description of the array version of <tt>narrow()</tt> (in
4321 paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
4322 takes only three arguments because in addition to the range a default
4323 character is needed.</p>
4324
4325 <p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
4326 two signatures followed by a <b>Returns</b> clause that only addresses
4327 one of them.</p>
4328
4329 <p><b>Proposed resolution:</b></p>
4330 <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>
4331 paragraph 10 from:</p>
4332 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
4333
4334 <p>to:</p>
4335 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to),
4336 respectively.</p>
4337
4338 <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>
4339 <pre>        char        narrow(char c, char /*dfault*/) const;
4340         const char* narrow(const char* low, const char* high,
4341                            char /*dfault*/, char* to) const;</pre>
4342 <pre>        Returns: do_narrow(low, high, to).</pre>
4343 <p>to:</p>
4344 <pre>        char        narrow(char c, char dfault) const;
4345         const char* narrow(const char* low, const char* high,
4346                            char dfault, char* to) const;</pre>
4347 <pre>        Returns: do_narrow(c, dfault) or
4348                  do_narrow(low, high, dfault, to), respectively.</pre>
4349
4350 <p><i>[Kona: 1) the problem occurs in additional places, 2) a user
4351 defined version could be different.]</i></p>
4352
4353 <p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
4354 the LWG. He could find no other places the problem occurred. He
4355 asks for clarification of the Kona "a user defined
4356 version..." comment above.  Perhaps it was a circuitous way of
4357 saying "dfault" needed to be uncommented?]</i></p>
4358
4359 <p><i>[Post-Toronto: the issues list maintainer has merged in the
4360 proposed resolution from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a>, which addresses the
4361 same paragraphs.]</i></p>
4362 <hr>
4363 <a name="154"><h3>154.&nbsp;Missing <tt>double</tt> specifier for <tt>do_get()</tt>
4364 </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>
4365 <p>The table in paragraph 7 for the length modifier does not list the length
4366 modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
4367 standard asks the implementation to do undefined things when using <tt>scanf()</tt>
4368 (the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
4369 is actually a problem I found quite often in production code, too).</p>
4370 <p><b>Proposed resolution:</b></p>
4371 <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
4372 Modifier table to say that for <tt>double</tt> a length modifier
4373 <tt>l</tt> is to be used.</p>
4374 <p><b>Rationale:</b></p>
4375 <p>The standard makes an embarrassing beginner's mistake.</p>
4376 <hr>
4377 <a name="155"><h3>155.&nbsp;Typo in naming the class defining the class <tt>Init</tt>
4378 </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>
4379 <p>There are conflicting statements about where the class
4380 <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
4381 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>
4382 <p><b>Proposed resolution:</b></p>
4383 <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
4384 "<tt>basic_ios::Init"</tt> to
4385 "<tt>ios_base::Init"</tt>.</p>
4386 <p><b>Rationale:</b></p>
4387 <p>Although not strictly wrong, the standard was misleading enough to warrant
4388 the change.</p>
4389 <hr>
4390 <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>
4391 <p>There is a small discrepancy between the declarations of
4392 <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
4393 <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
4394 is passed as <tt>locale const</tt> (wrong).</p>
4395 <p><b>Proposed resolution:</b></p>
4396 <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
4397 from "<tt>locale const" to "locale
4398 const&amp;".</tt></p>
4399 <hr>
4400 <a name="158"><h3>158.&nbsp;Underspecified semantics for <tt>setbuf()</tt>
4401 </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>
4402 <p>The default behavior of <tt>setbuf()</tt> is described only for the
4403 situation that <tt>gptr() != 0 &amp;&amp; gptr() != egptr()</tt>:
4404 namely to do nothing.  What has to be done in other situations&nbsp;
4405 is not described although there is actually only one reasonable
4406 approach, namely to do nothing, too.</p>
4407
4408 <p>Since changing the buffer would almost certainly mess up most
4409 buffer management of derived classes unless these classes do it
4410 themselves, the default behavior of <tt>setbuf()</tt> should always be
4411 to do nothing.</p>
4412 <p><b>Proposed resolution:</b></p>
4413 <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,
4414 to: "Default behavior: Does nothing. Returns this."</p>
4415 <hr>
4416 <a name="159"><h3>159.&nbsp;Strange use of <tt>underflow()</tt>
4417 </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>
4418 <p>The description of the meaning of the result of
4419 <tt>showmanyc()</tt> seems to be rather strange: It uses calls to
4420 <tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
4421 this function only reads the current character but does not extract
4422 it, <tt>uflow()</tt> would extract the current character. This should
4423 be fixed to use <tt>sbumpc()</tt> instead.</p>
4424 <p><b>Proposed resolution:</b></p>
4425 <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,
4426 <tt>showmanyc()</tt>returns clause, by replacing the word
4427 "supplied" with the words "extracted from the
4428 stream".</p>
4429 <hr>
4430 <a name="160"><h3>160.&nbsp;Typo: Use of non-existing function <tt>exception()</tt>
4431 </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>
4432 <p>The paragraph 4 refers to the function <tt>exception()</tt> which
4433 is not defined. Probably, the referred function is
4434 <tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>
4435 <p><b>Proposed resolution:</b></p>
4436 <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,
4437 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>,
4438 paragraph 1, change "<tt>exception()" to
4439 "exceptions()"</tt>.</p>
4440
4441 <p><i>[Note to Editor: "exceptions" with an "s"
4442 is the correct spelling.]</i></p>
4443 <hr>
4444 <a name="161"><h3>161.&nbsp;Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt>
4445 </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>
4446 <p>The note in the second paragraph pretends that the first argument
4447 is an object of type <tt>istream_iterator</tt>. This is wrong: It is
4448 an object of type <tt>istreambuf_iterator</tt>.</p>
4449 <p><b>Proposed resolution:</b></p>
4450 <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>
4451 <blockquote>
4452   <p>The first argument provides an object of the istream_iterator class...</p>
4453 </blockquote>
4454 <p>to</p>
4455 <blockquote>
4456   <p>The first argument provides an object of the istreambuf_iterator class...</p>
4457 </blockquote>
4458 <hr>
4459 <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>
4460 <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
4461 as taking a fill character as an argument, but the description of the
4462 function does not say whether the character is used at all and, if so,
4463 in which way. The same holds for any format control parameters that
4464 are accessible through the ios_base&amp; argument, such as the
4465 adjustment or the field width. Is strftime() supposed to use the fill
4466 character in any way? In any case, the specification of
4467 time_put.do_put() looks inconsistent to me.<br> <br> Is the
4468 signature of do_put() wrong, or is the effects clause incomplete?</p>
4469 <p><b>Proposed resolution:</b></p>
4470 <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>
4471 paragraph 2:</p>
4472 <blockquote>
4473   <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
4474   for this argument. --end Note]</p>
4475 </blockquote>
4476 <p><b>Rationale:</b></p>
4477 <p>The LWG felt that while the normative text was correct,
4478 users need some guidance on what to pass for the <tt>fill</tt>
4479 argument since the standard doesn't say how it's used.</p>
4480 <hr>
4481 <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>
4482 <p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
4483 functions falling into one of the groups "formatted output functions"
4484 and "unformatted output functions" calls any stream buffer function
4485 which might call a virtual function other than <tt>overflow()</tt>. Basically
4486 this is fine but this implies that <tt>sputn()</tt> (this function would call
4487 the virtual function <tt>xsputn()</tt>) is never called by any of the standard
4488 output functions. Is this really intended? At minimum it would be convenient to
4489 call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
4490 is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
4491 with the definition of <tt>flush()</tt> which calls <tt>rdbuf()-&gt;pubsync()</tt>
4492 and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
4493 under "unformatted output functions").</p>
4494 <p>In addition, I guess that the sentence starting with "They may use other
4495 public members of <tt>basic_ostream</tt> ..." probably was intended to
4496 start with "They may use other public members of <tt>basic_streamuf</tt>..."
4497 although the problem with the virtual members exists in both cases.</p>
4498 <p>I see two obvious resolutions:</p>
4499 <ol>
4500   <li>state in a footnote that this means that <tt>xsputn()</tt> will never be
4501     called by any ostream member and that this is intended.</li>
4502   <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
4503     Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
4504 </ol>
4505 <p><b>Proposed resolution:</b></p>
4506 <p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
4507 <blockquote>
4508   <p>They may use other public members of basic_ostream except that they do not
4509   invoke any virtual members of rdbuf() except overflow().</p>
4510 </blockquote>
4511 <p>to:</p>
4512 <blockquote>
4513   <p>They may use other public members of basic_ostream except that they shall
4514   not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
4515   sync().</p>
4516 </blockquote>
4517
4518 <p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
4519 PJP why the standard is written this way.]</i></p>
4520
4521 <p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
4522 LWG. He comments: The rules can be made a little bit more specific if
4523 necessary be explicitly spelling out what virtuals are allowed to be
4524 called from what functions and eg to state specifically that flush()
4525 is allowed to call sync() while other functions are not.]</i></p>
4526 <hr>
4527 <a name="167"><h3>167.&nbsp;Improper use of <tt>traits_type::length()</tt>
4528 </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>
4529 <p>Paragraph 4 states that the length is determined using
4530 <tt>traits::length(s)</tt>.  Unfortunately, this function is not
4531 defined for example if the character type is <tt>wchar_t</tt> and the
4532 type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
4533 the character type is <tt>char</tt> and the type of <tt>s</tt> is
4534 either <tt>signed char const*</tt> or <tt>unsigned char
4535 const*</tt>.</p>
4536 <p><b>Proposed resolution:</b></p>
4537 <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>
4538 <blockquote>
4539   <p>Effects: Behaves like an formatted inserter (as described in
4540   lib.ostream.formatted.reqmts) of out. After a sentry object is
4541   constructed it inserts characters. The number of characters starting
4542   at s to be inserted is traits::length(s). Padding is determined as
4543   described in lib.facet.num.put.virtuals. The traits::length(s)
4544   characters starting at s are widened using out.widen
4545   (lib.basic.ios.members). The widened characters and any required
4546   padding are inserted into out. Calls width(0).</p>
4547 </blockquote>
4548 <p>to:</p>
4549 <blockquote>
4550   <p>Effects: Behaves like a formatted inserter (as described in
4551   lib.ostream.formatted.reqmts) of out. After a sentry object is
4552   constructed it inserts <i>n</i> characters starting at <i>s</i>,
4553   where <i>n</i> is the number that would be computed as if by:</p>
4554   <ul>
4555   <li>traits::length(s) for the overload where the first argument is of
4556     type basic_ostream&lt;charT, traits&gt;&amp; and the second is
4557     of type const charT*, and also for the overload where the first
4558     argument is of type basic_ostream&lt;char, traits&gt;&amp; and
4559     the second is of type const char*.</li>
4560   <li>std::char_traits&lt;char&gt;::length(s)
4561     for the overload where the first argument is of type
4562     basic_ostream&lt;charT, traits&gt;&amp; and the second is of type
4563     const char*.</li>
4564   <li>traits::length(reinterpret_cast&lt;const char*&gt;(s))
4565     for the other two overloads.</li>
4566   </ul>
4567   <p>Padding is determined as described in
4568   lib.facet.num.put.virtuals. The <i>n</i> characters starting at
4569   <i>s</i> are widened using out.widen (lib.basic.ios.members).  The
4570   widened characters and any required padding are inserted into
4571   out. Calls width(0).</p>
4572 </blockquote>
4573
4574 <p><i>[Santa Cruz: Matt supplied new wording]</i></p>
4575
4576 <p><i>[Kona: changed "where <i>n</i> is" to " where <i>n</i> is the
4577   number that would be computed as if by"]</i></p>
4578
4579 <p><b>Rationale:</b></p>
4580 <p>We have five separate cases.  In two of them we can use the
4581 user-supplied traits class without any fuss.  In the other three we
4582 try to use something as close to that user-supplied class as possible.
4583 In two cases we've got a traits class that's appropriate for
4584 char and what we've got is a const signed char* or a const
4585 unsigned char*; that's close enough so we can just use a reinterpret
4586 cast, and continue to use the user-supplied traits class.  Finally,
4587 there's one case where we just have to give up: where we've got a
4588 traits class for some arbitrary charT type, and we somehow have to
4589 deal with a const char*.  There's nothing better to do but fall back
4590 to char_traits&lt;char&gt;</p>
4591 <hr>
4592 <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>
4593 <p>The first paragraph begins with a descriptions what has to be done
4594 in <i>formatted</i> output functions. Probably this is a typo and the
4595 paragraph really want to describe unformatted output functions...</p>
4596 <p><b>Proposed resolution:</b></p>
4597 <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
4598 sentences, change the word "formatted" to
4599 "unformatted":</p>
4600 <blockquote>
4601   <p>"Each <b>unformatted </b> output function begins ..."<br>
4602   "... value specified for the <b>unformatted </b>  output
4603   function."</p>
4604 </blockquote>
4605 <hr>
4606 <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>
4607 <p>Paragraph 8, Notes, of this section seems to mandate an extremely
4608 inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
4609 especially in view of the restriction that <tt>basic_ostream</tt>
4610 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
4611 is to be created.</p>
4612 <p>Of course, the resolution below requires some handling of
4613 simultaneous input and output since it is no longer possible to update
4614 <tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
4615 solution is to handle this in <tt>underflow()</tt>.</p>
4616 <p><b>Proposed resolution:</b></p>
4617 <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
4618 "at least" as in the following:</p>
4619 <blockquote>
4620   <p>To make a write position available, the function reallocates (or initially
4621   allocates) an array object with a sufficient number of elements to hold the
4622   current array object (if any), plus <b>at least</b> one additional write
4623   position.</p>
4624 </blockquote>
4625 <hr>
4626 <a name="170"><h3>170.&nbsp;Inconsistent definition of <tt>traits_type</tt>
4627 </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>
4628 <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>),
4629 <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
4630 <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
4631 in their definition of the type <tt>traits_type</tt>: For
4632 <tt>istringstream</tt>, this type is defined, for the other two it is
4633 not. This should be consistent.</p>
4634 <p><b>Proposed resolution:</b></p>
4635 <p><b>Proposed resolution:</b></p> <p>To the declarations of
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>) and
4637 <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>
4638 <blockquote>
4639 <pre>typedef traits traits_type;</pre>
4640 </blockquote>
4641 <hr>
4642 <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>
4643 <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
4644 output position is maintained by <tt>basic_filebuf</tt>. Still, the
4645 description of <tt>seekpos()</tt> seems to talk about different file
4646 positions. In particular, it is unclear (at least to me) what is
4647 supposed to happen to the output buffer (if there is one) if only the
4648 input position is changed. The standard seems to mandate that the
4649 output buffer is kept and processed as if there was no positioning of
4650 the output position (by changing the input position). Of course, this
4651 can be exactly what you want if the flag <tt>ios_base::ate</tt> is
4652 set. However, I think, the standard should say something like
4653 this:</p>
4654 <ul>
4655   <li>If <tt>(which &amp; mode) == 0</tt> neither read nor write position is
4656     changed and the call fails. Otherwise, the joint read and write position is
4657     altered to correspond to <tt>sp</tt>.</li>
4658   <li>If there is an output buffer, the output sequences is updated and any
4659     unshift sequence is written before the position is altered.</li>
4660   <li>If there is an input buffer, the input sequence is updated after the
4661     position is altered.</li>
4662 </ul>
4663 <p>Plus the appropriate error handling, that is...</p>
4664 <p><b>Proposed resolution:</b></p>
4665 <p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
4666 paragraph 14 from:</p>
4667 <blockquote>
4668   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
4669   ios_base::out);</p>
4670   <p>Alters the file position, if possible, to correspond to the position stored
4671   in sp (as described below).</p>
4672   <p>- if (which&amp;ios_base::in)!=0, set the file position to sp, then update
4673   the input sequence</p>
4674   <p>- if (which&amp;ios_base::out)!=0, then update the output sequence, write
4675   any unshift sequence, and set the file position to sp.</p>
4676 </blockquote>
4677 <p>to:</p>
4678 <blockquote>
4679   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
4680   ios_base::out);</p>
4681   <p>Alters the file position, if possible, to correspond to the position stored
4682   in sp (as described below). Altering the file position performs as follows:</p>
4683   <p>1. if (om &amp; ios_base::out)!=0, then update the output sequence and
4684   write any unshift sequence;</p>
4685   <p>2. set the file position to sp;</p>
4686   <p>3. if (om &amp; ios_base::in)!=0, then update the input sequence;</p>
4687   <p>where om is the open mode passed to the last call to open(). The operation
4688   fails if is_open() returns false.</p>
4689 </blockquote>
4690
4691 <p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
4692 <p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
4693 <hr>
4694 <a name="172"><h3>172.&nbsp;Inconsistent types for <tt>basic_istream::ignore()</tt>
4695 </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>
4696 <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
4697 <tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
4698 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>
4699 paragraph 23 the first argument is of type <tt>int.</tt></p>
4700
4701 <p>As far as I can see this is not really a contradiction because
4702 everything is consistent if <tt>streamsize</tt> is typedef to be
4703 <tt>int</tt>. However, this is almost certainly not what was
4704 intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
4705 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>.</p>
4706
4707 <p>Darin Adler also
4708 submitted this issue, commenting: Either 27.6.1.1 should be modified
4709 to show a first parameter of type int, or 27.6.1.3 should be modified
4710 to show a first parameter of type streamsize and use
4711 numeric_limits&lt;streamsize&gt;::max.</p>
4712 <p><b>Proposed resolution:</b></p>
4713 <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
4714 of <tt>int</tt> in the description of <tt>ignore()</tt> to
4715 <tt>streamsize</tt>.</p>
4716 <hr>
4717 <a name="173"><h3>173.&nbsp;Inconsistent types for <tt>basic_filebuf::setbuf()</tt>
4718 </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>
4719
4720 <p>
4721 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
4722 object of type <tt>streamsize</tt> as second argument. However, in
4723 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
4724 <tt>int</tt>.
4725 </p>
4726
4727 <p>
4728 As far as I can see this is not really a contradiction because
4729 everything is consistent if <tt>streamsize</tt> is typedef to be
4730 <tt>int</tt>. However, this is almost certainly not what was
4731 intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
4732 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>.
4733 </p>
4734
4735 <p><b>Proposed resolution:</b></p>
4736 <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
4737 <tt>int</tt> in the description of <tt>setbuf()</tt> to
4738 <tt>streamsize</tt>.</p>
4739 <hr>
4740 <a name="174"><h3>174.&nbsp;Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt>
4741 </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>
4742 <p>According to paragraph 1 of this section, <tt>streampos</tt> is the
4743 type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
4744 paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt></p>
4745 <p><b>Proposed resolution:</b></p>
4746 <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
4747 OFF_T streampos;</tt>" to "<tt>typedef POS_T
4748 streampos;</tt>"</p>
4749 <hr>
4750 <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>
4751 <p>According to paragraph 8 of this section, the methods
4752 <tt>basic_streambuf::pubseekpos()</tt>,
4753 <tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
4754 "may" be overloaded by a version of this function taking the
4755 type <tt>ios_base::open_mode</tt> as last argument argument instead of
4756 <tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
4757 in this section to be an alias for one of the integral types). The
4758 clause specifies, that the last argument has a default argument in
4759 three cases.  However, this generates an ambiguity with the overloaded
4760 version because now the arguments are absolutely identical if the last
4761 argument is not specified.</p>
4762 <p><b>Proposed resolution:</b></p>
4763 <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
4764 <tt>basic_streambuf::pubseekpos()</tt>,
4765 <tt>basic_ifstream::open()</tt>, and
4766 <tt>basic_ofstream::open().</tt></p>
4767 <hr>
4768 <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>
4769 <p>The "overload" for the function <tt>exceptions()</tt> in
4770 paragraph 8 gives the impression that there is another function of
4771 this function defined in class <tt>ios_base</tt>. However, this is not
4772 the case. Thus, it is hard to tell how the semantics (paragraph 9) can
4773 be implemented: "Call the corresponding member function specified
4774 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>
4775 <p><b>Proposed resolution:</b></p>
4776 <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
4777 function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
4778 <hr>
4779 <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>
4780 <p>Currently the following will not compile on two well-known standard
4781 library implementations:</p>
4782
4783 <blockquote>
4784   <pre>#include &lt;set&gt;
4785 using namespace std;
4786
4787 void f(const set&lt;int&gt; &amp;s)
4788 {
4789   set&lt;int&gt;::iterator i;
4790   if (i==s.end()); // s.end() returns a const_iterator
4791 }</pre>
4792 </blockquote>
4793
4794 <p>
4795 The reason this doesn't compile is because operator== was implemented
4796 as a member function of the nested classes set:iterator and
4797 set::const_iterator, and there is no conversion from const_iterator to
4798 iterator. Surprisingly, (s.end() == i) does work, though, because of
4799 the conversion from iterator to const_iterator.
4800 </p>
4801
4802 <p>
4803 I don't see a requirement anywhere in the standard that this must
4804 work. Should there be one?  If so, I think the requirement would need
4805 to be added to the tables in section 24.1.1. I'm not sure about the
4806 wording.  If this requirement existed in the standard, I would think
4807 that implementors would have to make the comparison operators
4808 non-member functions.</p>
4809
4810 <p>This issues was also raised on comp.std.c++ by Darin
4811 Adler.&nbsp; The example given was:</p>
4812
4813 <blockquote>
4814   <pre>bool check_equal(std::deque&lt;int&gt;::iterator i,
4815 std::deque&lt;int&gt;::const_iterator ci)
4816 {
4817 return i == ci;
4818 }</pre>
4819 </blockquote>
4820
4821 <p>Comment from John Potter:</p>
4822 <blockquote>
4823     <p>
4824     In case nobody has noticed, accepting it will break reverse_iterator.
4825     </p>
4826
4827     <p>
4828     The fix is to make the comparison operators templated on two types.
4829     </p>
4830
4831     <pre>    template &lt;class Iterator1, class Iterator2&gt;
4832     bool operator== (reverse_iterator&lt;Iterator1&gt; const&amp; x,
4833                      reverse_iterator&lt;Iterator2&gt; const&amp; y);
4834     </pre>
4835
4836     <p>
4837     Obviously:  return x.base() == y.base();
4838     </p>
4839
4840     <p>
4841     Currently, no reverse_iterator to const_reverse_iterator compares are
4842     valid.
4843     </p>
4844
4845     <p>
4846     BTW, I think the issue is in support of bad code.  Compares should be
4847     between two iterators of the same type.  All std::algorithms require
4848     the begin and end iterators to be of the same type.
4849     </p>
4850 </blockquote>
4851 <p><b>Proposed resolution:</b></p>
4852 <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>
4853 <blockquote>
4854   <p>In the expressions</p>
4855   <pre>    i == j
4856     i != j
4857     i &lt; j
4858     i &lt;= j
4859     i &gt;= j
4860     i &gt; j
4861     i - j
4862   </pre>
4863   <p>Where i and j denote objects of a container's iterator type,
4864   either or both may be replaced by an object of the container's
4865   const_iterator type referring to the same element with no
4866   change in semantics.</p>
4867 </blockquote>
4868
4869 <p><i>[post-Toronto: Judy supplied a proposed resolution saying that
4870 <tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
4871 iterator comparison and difference operations.]</i></p>
4872
4873 <p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
4874 explicitly listed expressions; there was concern that the previous
4875 proposed resolution was too informal.]</i></p>
4876 <p><b>Rationale:</b></p>
4877 <p>
4878 The LWG believes it is clear that the above wording applies only to
4879 the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
4880 where <tt>X</tt> is a container.  There is no requirement that
4881 <tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
4882 can be mixed.  If mixing them is considered important, that's a
4883 separate issue.  (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>.)
4884 </p>
4885 <hr>
4886 <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>
4887 <p>The claim has surfaced in Usenet that expressions such as<br>
4888 <br>
4889 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>make_pair("abc", 3)</tt><br>
4890 <br>
4891 are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
4892 parameter to <tt> const char (&amp;)[4]</tt>, which type is uncopyable.<br>
4893 <br>
4894 I doubt anyone intended that behavior...
4895 </p>
4896 <p><b>Proposed resolution:</b></p>
4897 <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
4898 declaration of make_pair():</p>
4899 <blockquote>
4900   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(const T1&amp;, const T2&amp;);</pre>
4901 </blockquote>
4902 <p>to:</p>
4903 <blockquote>
4904   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(T1, T2);</pre>
4905 </blockquote>
4906 <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>
4907 <blockquote>
4908 <pre>template &lt;class T1, class T2&gt;
4909 pair&lt;T1, T2&gt; make_pair(const T1&amp; x, const T2&amp; y);</pre>
4910 </blockquote>
4911 <p>to:</p>
4912 <blockquote>
4913 <pre>template &lt;class T1, class T2&gt;
4914 pair&lt;T1, T2&gt; make_pair(T1 x, T2 y);</pre>
4915 </blockquote>
4916 <p>and add the following footnote to the effects clause:</p>
4917 <blockquote>
4918   <p> According to 12.8 [class.copy], an implementation is permitted
4919   to not perform a copy of an argument, thus avoiding unnecessary
4920   copies.</p>
4921 </blockquote>
4922 <p><b>Rationale:</b></p>
4923 <p>Two potential fixes were suggested by Matt Austern and Dietmar
4924 Kühl, respectively, 1) overloading with array arguments, and 2) use of
4925 a reference_traits class with a specialization for arrays.  Andy
4926 Koenig suggested changing to pass by value. In discussion, it appeared
4927 that this was a much smaller change to the standard that the other two
4928 suggestions, and any efficiency concerns were more than offset by the
4929 advantages of the solution. Two implementors reported that the
4930 proposed resolution passed their test suites.</p>
4931 <hr>
4932 <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>
4933 <p>Many references to <tt> size_t</tt> throughout the document
4934 omit the <tt> std::</tt> namespace qualification.</p> <p>For
4935 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>
4936 <blockquote>
4937 <pre>&#8212; operator new(size_t)
4938 &#8212; operator new(size_t, const std::nothrow_t&amp;)
4939 &#8212; operator new[](size_t)
4940 &#8212; operator new[](size_t, const std::nothrow_t&amp;)</pre>
4941 </blockquote>
4942 <p><b>Proposed resolution:</b></p>
4943 <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>
4944 <blockquote>
4945 <p><tt>     - operator new(size_t)<br>
4946      - operator new(size_t, const std::nothrow_t&amp;)<br>
4947      - operator new[](size_t)<br>
4948      - operator new[](size_t, const std::nothrow_t&amp;)</tt></p>
4949 </blockquote>
4950 <p>    by:</p>
4951 <blockquote>
4952 <pre>- operator new(std::size_t)
4953 - operator new(std::size_t, const std::nothrow_t&amp;)
4954 - operator new[](std::size_t)
4955 - operator new[](std::size_t, const std::nothrow_t&amp;)</pre>
4956 </blockquote>
4957 <p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
4958 <blockquote>
4959   <p>The typedef members pointer, const_pointer, size_type, and difference_type
4960   are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
4961 </blockquote>
4962 <p>&nbsp;by:</p>
4963 <blockquote>
4964   <p>The typedef members pointer, const_pointer, size_type, and difference_type
4965   are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
4966   respectively.</p>
4967 </blockquote>
4968 <p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
4969 <blockquote>
4970   <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
4971   <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
4972   is unspecified when or how often this function is called. The use of hint is
4973   unspecified, but intended as an aid to locality if an implementation so
4974   desires.</p>
4975 </blockquote>
4976 <p>by:</p>
4977 <blockquote>
4978   <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
4979   <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
4980   it is unspecified when or how often this function is called. The use of hint
4981   is unspecified, but intended as an aid to locality if an implementation so
4982   desires.</p>
4983 </blockquote>
4984 <p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
4985 <blockquote>
4986   <p>In Table 37, X denotes a Traits class defining types and functions for the
4987   character container type CharT; c and d denote values of type CharT; p and q
4988   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
4989   j denote values of type size_t; e and f denote values of type X::int_type; pos
4990   denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
4991 </blockquote>
4992 <p>by:</p>
4993 <blockquote>
4994   <p>In Table 37, X denotes a Traits class defining types and functions for the
4995   character container type CharT; c and d denote values of type CharT; p and q
4996   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
4997   j denote values of type std::size_t; e and f denote values of type X::int_type;
4998   pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
4999 </blockquote>
5000 <p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
5001 X::length(p): "size_t" by "std::size_t".</p>
5002 <p>   In [lib.std.iterator.tags] 24.3.3, paragraph 2:    replace:<br>
5003 &nbsp;&nbsp;&nbsp; typedef ptrdiff_t difference_type;<br>
5004     by:<br>
5005 &nbsp;&nbsp;&nbsp; typedef std::ptrdiff_t difference_type;</p>
5006 <p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the
5007 declaration of template &lt;class charT&gt; class ctype.<br>
5008 <br>
5009    In [lib.iterator.traits] 24.3.1, paragraph 2    put namespace std { ...} around the declaration of:<br>
5010 <br>
5011 &nbsp;&nbsp;&nbsp; template&lt;class Iterator&gt; struct iterator_traits<br>
5012 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;T*&gt;<br>
5013 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;const T*&gt;</p>
5014 <p><b>Rationale:</b></p>
5015 <p>The LWG believes correcting names like <tt>size_t</tt> and
5016 <tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
5017 to be essentially editorial.  There there can't be another size_t or
5018 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>
5019
5020 <blockquote>
5021 For each type T from the Standard C library, the types ::T and std::T
5022 are reserved to the implementation and, when defined, ::T shall be
5023 identical to std::T.
5024 </blockquote>
5025
5026 <p>The issue is treated as a Defect Report to make explicit the Project
5027 Editor's authority to make this change.</p>
5028
5029 <p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
5030 request of the LWG.]</i></p>
5031
5032 <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
5033 address use of the name <tt>size_t</tt> in contexts outside of
5034 namespace std, such as in the description of <tt>::operator new</tt>.
5035 The proposed changes should be reviewed to make sure they are
5036 correct.]</i></p>
5037
5038 <p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
5039 them to be correct.]</i></p>
5040
5041 <hr>
5042 <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>
5043 <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
5044 exposition):</p>
5045 <blockquote>
5046 <p>Returns: An object s of unspecified type such that if [1] out is an (instance
5047 of) basic_ostream then the expression out&lt;&lt;s behaves as if f(s) were
5048 called, and if [2] in is an (instance of) basic_istream then the expression
5049 in&gt;&gt;s behaves as if f(s) were called. Where f can be defined as: ios_base&amp;
5050 f(ios_base&amp; str, ios_base::fmtflags mask) { // reset specified flags
5051 str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
5052 out&lt;&lt;s has type ostream&amp; and value out. [4] The expression in&gt;&gt;s
5053 has type istream&amp; and value in.</p>
5054 </blockquote>
5055 <p>Given the definitions [1] and [2] for out and in, surely [3] should read:
5056 "The expression out &lt;&lt; s has type basic_ostream&amp; ..." and
5057 [4] should read: "The expression in &gt;&gt; s has type basic_istream&amp;
5058 ..."</p>
5059 <p>If the wording in the standard is correct, I can see no way of implementing
5060 any of the manipulators so that they will work with wide character streams.</p>
5061 <p>e.g. wcout &lt;&lt; setbase( 16 );</p>
5062 <p>Must have value 'wcout' (which makes sense) and type 'ostream&amp;' (which
5063 doesn't).</p>
5064 <p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
5065 8. In addition, Para 6 [setfill] has a similar error, but relates only to
5066 ostreams.</p>
5067 <p>I'd be happier if there was a better way of saying this, to make it clear
5068 that the value of the expression is "the same specialization of
5069 basic_ostream as out"&amp;</p>
5070 <p><b>Proposed resolution:</b></p>
5071 <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
5072 following:</p>
5073 <blockquote>
5074 <p>2- The type designated smanip in each of the following function
5075 descriptions is implementation-specified and may be different for each
5076 function.<br>
5077 <br>
5078 <tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
5079 <br>
5080 -3- Returns: An object s of unspecified type such that if out is an
5081 instance of basic_ostream&lt;charT,traits&gt; then the expression
5082 out&lt;&lt;s behaves
5083 as if f(s, mask) were called, or if in is an instance of
5084 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5085 behaves as if
5086 f(s, mask) were called. The function f can be defined as:*<br>
5087 <br>
5088 [Footnote: The expression cin &gt;&gt; resetiosflags(ios_base::skipws)
5089 clears ios_base::skipws in the format flags stored in the
5090 basic_istream&lt;charT,traits&gt; object cin (the same as cin &gt;&gt;
5091 noskipws), and the expression cout &lt;&lt;
5092 resetiosflags(ios_base::showbase) clears
5093 ios_base::showbase in the format flags stored in the
5094 basic_ostream&lt;charT,traits&gt; object cout (the same as cout
5095 &lt;&lt;
5096 noshowbase). --- end footnote]<br>
5097 <br>
5098 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
5099 &nbsp;&nbsp; {<br>
5100 &nbsp;&nbsp; //  reset specified flags<br>
5101 &nbsp;&nbsp; str.setf(ios_base::fmtflags(0), mask);<br>
5102 &nbsp;&nbsp; return str;<br>
5103 &nbsp;&nbsp; }<br>
5104 </tt><br>
5105 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5106 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5107 <br>
5108 &nbsp;<tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
5109 <br>
5110 -4- Returns: An object s of unspecified type such that if out is an
5111 instance of basic_ostream&lt;charT,traits&gt; then the expression
5112 out&lt;&lt;s behaves
5113 as if f(s, mask) were called, or if in is an instance of
5114 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5115 behaves as if f(s,
5116 mask) were called. The function f can be defined as:<br>
5117 <br>
5118 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
5119 &nbsp;&nbsp; {<br>
5120 &nbsp;&nbsp; //  set specified flags<br>
5121 &nbsp;&nbsp; str.setf(mask);<br>
5122 &nbsp;&nbsp; return str;<br>
5123 &nbsp;&nbsp; }<br>
5124 </tt><br>
5125 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5126 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5127 <br>
5128 <tt>smanip setbase(int base);</tt><br>
5129 <br>
5130 -5- Returns: An object s of unspecified type such that if out is an
5131 instance of basic_ostream&lt;charT,traits&gt; then the expression
5132 out&lt;&lt;s behaves
5133 as if f(s, base) were called, or if in is an instance of
5134 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5135 behaves as if f(s,
5136 base) were called. The function f can be defined as:<br>
5137 <br>
5138 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int base)<br>
5139 &nbsp;&nbsp; {<br>
5140 &nbsp;&nbsp; //  set  basefield<br>
5141 &nbsp;&nbsp; str.setf(base ==  8 ? ios_base::oct :<br>
5142 &nbsp;&nbsp; base == 10 ? ios_base::dec :<br>
5143 &nbsp;&nbsp; base == 16 ? ios_base::hex :<br>
5144 &nbsp;&nbsp; ios_base::fmtflags(0), ios_base::basefield);<br>
5145 &nbsp;&nbsp; return str;<br>
5146 &nbsp;&nbsp; }<br>
5147 </tt><br>
5148 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5149 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5150 <br>
5151 <tt>smanip setfill(char_type c);<br>
5152 </tt><br>
5153 -6- Returns: An object s of unspecified type such that if out is (or is
5154 derived from) basic_ostream&lt;charT,traits&gt; and c has type charT
5155 then the
5156 expression out&lt;&lt;s behaves as if f(s, c) were called. The function
5157 f can be
5158 defined as:<br>
5159 <br>
5160 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>template&lt;class charT, class traits&gt;<br>
5161 &nbsp;&nbsp; basic_ios&lt;charT,traits&gt;&amp; f(basic_ios&lt;charT,traits&gt;&amp; str, charT c)<br>
5162 &nbsp;&nbsp; {<br>
5163 &nbsp;&nbsp; //  set fill character<br>
5164 &nbsp;&nbsp; str.fill(c);<br>
5165 &nbsp;&nbsp; return str;<br>
5166 &nbsp;&nbsp; }<br>
5167 </tt><br>
5168 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.<br>
5169 <br>
5170 <tt>smanip setprecision(int n);</tt><br>
5171 <br>
5172 -7- Returns: An object s of unspecified type such that if out is an
5173 instance of basic_ostream&lt;charT,traits&gt; then the expression
5174 out&lt;&lt;s behaves
5175 as if f(s, n) were called, or if in is an instance of
5176 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5177 behaves as if f(s, n)
5178 were called. The function f can be defined as:<br>
5179 <br>
5180 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
5181 &nbsp;&nbsp; {<br>
5182 &nbsp;&nbsp; //  set precision<br>
5183 &nbsp;&nbsp; str.precision(n);<br>
5184 &nbsp;&nbsp; return str;<br>
5185 &nbsp;&nbsp; }<br>
5186 </tt><br>
5187 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5188 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in<br>
5189 .<br>
5190 <tt>smanip setw(int n);<br>
5191 </tt><br>
5192 -8- Returns: An object s of unspecified type such that if out is an
5193 instance of basic_ostream&lt;charT,traits&gt; then the expression
5194 out&lt;&lt;s behaves
5195 as if f(s, n) were called, or if in is an instance of
5196 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5197 behaves as if f(s, n)
5198 were called. The function f can be defined as:<br>
5199 <br>
5200 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
5201 &nbsp;&nbsp; {<br>
5202 &nbsp;&nbsp; //  set width<br>
5203 &nbsp;&nbsp; str.width(n);<br>
5204 &nbsp;&nbsp; return str;<br>
5205 &nbsp;&nbsp; }<br>
5206 </tt><br>
5207 The expression out&lt;&lt;s has type
5208 basic_ostream&lt;charT,traits&gt;&amp; and value out.  The expression
5209 in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value
5210 in.
5211 </p>
5212 </blockquote>
5213
5214 <p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
5215 the proposed resolution.]</i></p>
5216
5217 <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
5218 the same paragraphs.]</i></p>
5219
5220 <p><i>[Post-Tokyo: The issues list maintainer combined the proposed
5221 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
5222 intertwined that dealing with them separately appear fraught with
5223 error.  The full text was supplied by Bill Plauger; it was cross
5224 checked against changes supplied by Andy Sawyer. It should be further
5225 checked by the LWG.]</i></p>
5226 <hr>
5227 <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>
5228 <p>bools are defined by the standard to be of integer types, as per
5229 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"
5230 seems to have a special meaning for the author of 18.2. The net effect
5231 is an unclear and confusing specification for
5232 numeric_limits&lt;bool&gt; as evidenced below.</p>
5233
5234 <p>18.2.1.2/7 says numeric_limits&lt;&gt;::digits is, for built-in integer
5235 types, the number of non-sign bits in the representation.</p>
5236
5237 <p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
5238 arithmetical value converts to true.</p>
5239
5240 <p>I don't think it makes sense at all to require
5241 numeric_limits&lt;bool&gt;::digits and numeric_limits&lt;bool&gt;::digits10 to
5242 be meaningful.</p>
5243
5244 <p>The standard defines what constitutes a signed (resp. unsigned) integer
5245 types. It doesn't categorize bool as being signed or unsigned. And the set of
5246 values of bool type has only two elements.</p>
5247
5248 <p>I don't think it makes sense to require numeric_limits&lt;bool&gt;::is_signed
5249 to be meaningful.</p>
5250
5251 <p>18.2.1.2/18 for numeric_limits&lt;integer_type&gt;::radix&nbsp; says:</p>
5252 <blockquote>
5253   <p>For integer types, specifies the base of the representation.186)</p>
5254 </blockquote>
5255
5256 <p>This disposition is at best misleading and confusing for the standard
5257 requires a "pure binary numeration system" for integer types as per
5258 3.9.1/7</p>
5259
5260 <p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
5261 BCD)."&nbsp; This also erroneous as the standard never defines any integer
5262 types with base representation other than 2.</p>
5263
5264 <p>Furthermore, numeric_limits&lt;bool&gt;::is_modulo and
5265 numeric_limits&lt;bool&gt;::is_signed have similar problems.</p>
5266 <p><b>Proposed resolution:</b></p>
5267 <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>
5268 <blockquote>
5269   <p>The specialization for bool shall be provided as follows:</p>
5270   <pre>    namespace std {
5271        template&lt;&gt; class numeric_limits&lt;bool&gt; {
5272        public:
5273          static const bool is_specialized = true;
5274          static bool min() throw() { return false; }
5275          static bool max() throw() { return true; }
5276
5277          static const int  digits = 1;
5278          static const int  digits10 = 0;
5279          static const bool is_signed = false;
5280          static const bool is_integer = true;
5281          static const bool is_exact = true;
5282          static const int  radix = 2;
5283          static bool epsilon() throw() { return 0; }
5284          static bool round_error() throw() { return 0; }
5285
5286          static const int  min_exponent = 0;
5287          static const int  min_exponent10 = 0;
5288          static const int  max_exponent = 0;
5289          static const int  max_exponent10 = 0;
5290
5291          static const bool has_infinity = false;
5292          static const bool has_quiet_NaN = false;
5293          static const bool has_signaling_NaN = false;
5294          static const float_denorm_style has_denorm = denorm_absent;
5295          static const bool has_denorm_loss = false;
5296          static bool infinity() throw() { return 0; }
5297          static bool quiet_NaN() throw() { return 0; }
5298          static bool signaling_NaN() throw() { return 0; }
5299          static bool denorm_min() throw() { return 0; }
5300
5301          static const bool is_iec559 = false;
5302          static const bool is_bounded = true;
5303          static const bool is_modulo = false;
5304
5305          static const bool traps = false;
5306          static const bool tinyness_before = false;
5307          static const float_round_style round_style = round_toward_zero;
5308        };
5309      }</pre>
5310 </blockquote>
5311
5312 <p><i>[Tokyo:&nbsp; The LWG desires wording that specifies exact values
5313 rather than more general wording in the original proposed
5314 resolution.]</i></p>
5315
5316 <p><i>[Post-Tokyo:&nbsp; At the request of the LWG in Tokyo, Nico
5317 Josuttis provided the above wording.]</i></p>
5318 <hr>
5319 <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>
5320 <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>
5321 <blockquote>
5322   <p>&nbsp;[Example: To negate every element of a: transform(a.begin(), a.end(),
5323   a.begin(), negate&lt;double&gt;()); The corresponding functions will inline
5324   the addition and the negation. end example]</p>
5325 </blockquote>
5326 <p>(Note: The "addition" referred to in the above is in para 3) we can
5327 find no other wording, except this (non-normative) example which suggests that
5328 any "inlining" will take place in this case.</p>
5329 <p>Indeed both:</p>
5330 <blockquote>
5331   <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
5332   unspecified whether any global functions in the C++ Standard Library
5333   are defined as inline (7.1.2).</p>
5334 </blockquote>
5335 <p>and</p>
5336 <blockquote>
5337   <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
5338   unspecified whether any member functions in the C++ Standard Library
5339   are defined as inline (7.1.2).</p>
5340 </blockquote>
5341 <p>take care to state that this may indeed NOT be the case.</p>
5342 <p>Thus the example "mandates" behavior that is explicitly
5343 not required elsewhere.</p>
5344 <p><b>Proposed resolution:</b></p>
5345 <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>
5346 <blockquote>
5347 <p>They are important for the effective use of the library.</p>
5348 </blockquote>
5349 <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>
5350 <blockquote>
5351   <p> Using function objects together with function templates
5352   increases the expressive power of the library as well as making the
5353   resulting code much more efficient.</p>
5354 </blockquote>
5355 <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>
5356 <blockquote>
5357   <p>The corresponding functions will inline the addition and the
5358   negation.</p>
5359 </blockquote>
5360
5361 <p><i>[Kona: The LWG agreed there was a defect.]</i></p>
5362 <p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
5363 <hr>
5364 <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>
5365 <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
5366 bitset::set operation to take a second parameter of type int. The
5367 function tests whether this value is non-zero to determine whether to
5368 set the bit to true or false. The type of this second parameter should
5369 be bool. For one thing, the intent is to specify a Boolean value. For
5370 another, the result type from test() is bool. In addition, it's
5371 possible to slice an integer that's larger than an int. This can't
5372 happen with bool, since conversion to bool has the semantic of
5373 translating 0 to false and any non-zero value to true.</p>
5374 <p><b>Proposed resolution:</b></p>
5375 <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>
5376 <blockquote>
5377 <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = true ); </pre>
5378 </blockquote>
5379 <p>With:</p>
5380 <blockquote>
5381   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
5382 </blockquote>
5383 <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>
5384 <blockquote>
5385   <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = 1 );</pre>
5386 </blockquote>
5387 <p>With:</p>
5388 <blockquote>
5389   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
5390 </blockquote>
5391
5392 <p><i>[Kona: The LWG agrees with the description.&nbsp; Andy Sawyer will work
5393 on better P/R wording.]</i></p>
5394 <p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
5395 <p><b>Rationale:</b></p>
5396 <p><tt>bool</tt> is a better choice.  It is believed that binary
5397 compatibility is not an issue, because this member function is
5398 usually implemented as <tt>inline</tt>, and because it is already
5399 the case that users cannot rely on the type of a pointer to a
5400 nonvirtual member of a standard library class.</p>
5401 <hr>
5402 <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>
5403 <p>The description of iter_swap in 25.2.2 paragraph 7,says that it
5404 ``exchanges the values'' of the objects to which two iterators
5405 refer.<br> <br> What it doesn't say is whether it does so using swap
5406 or using the assignment operator and copy constructor.<br> <br> This
5407 question is an important one to answer, because swap is specialized to
5408 work efficiently for standard containers.<br> For example:</p>
5409 <blockquote>
5410 <pre>vector&lt;int&gt; v1, v2;
5411 iter_swap(&amp;v1, &amp;v2);</pre>
5412 </blockquote>
5413 <p>Is this call to iter_swap equivalent to calling swap(v1, v2)?&nbsp;
5414 Or is it equivalent to</p>
5415 <blockquote>
5416 <pre>{
5417 vector&lt;int&gt; temp = v1;
5418 v1 = v2;
5419 v2 = temp;
5420 }</pre>
5421 </blockquote>
5422 <p>The first alternative is O(1); the second is O(n).</p>
5423 <p>A LWG member, Dave Abrahams, comments:</p>
5424 <blockquote>
5425 <p>Not an objection necessarily, but I want to point out the cost of
5426 that requirement:</p>
5427   <blockquote>
5428 <p><tt>iter_swap(list&lt;T&gt;::iterator, list&lt;T&gt;::iterator)</tt></p>
5429   </blockquote>
5430 <p>can currently be specialized to be more efficient than
5431 iter_swap(T*,T*) for many T (by using splicing). Your proposal would
5432 make that optimization illegal.&nbsp;</p>
5433 </blockquote>
5434
5435 <p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
5436 which are no longer permitted.]</i></p>
5437 <p><b>Proposed resolution:</b></p>
5438 <p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
5439 <blockquote>
5440 <p>Exchanges the values pointed to by the two iterators a and b.</p>
5441 </blockquote>
5442 <p>to</p>
5443 <blockquote>
5444 <p><tt>swap(*a, *b)</tt>.</p>
5445 </blockquote>
5446
5447 <p><b>Rationale:</b></p>
5448 <p>It's useful to say just what <tt>iter_swap</tt> does.  There may be
5449   some iterators for which we want to specialize <tt>iter_swap</tt>,
5450   but the fully general version should have a general specification.</p>
5451
5452 <p>Note that in the specific case of <tt>list&lt;T&gt;::iterator</tt>,
5453 iter_swap should not be specialized as suggested above.  That would do
5454 much more than exchanging the two iterators' values: it would change
5455 predecessor/successor relationships, possibly moving the iterator from
5456 one list to another.  That would surely be inappropriate.</p>
5457 <hr>
5458 <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>
5459 <p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
5460 and includes a parenthetical note saying that it is the number of
5461 digits after the decimal point.<br>
5462 <br>
5463 This claim is not strictly correct.  For example, in the default
5464 floating-point output format, setprecision sets the number of
5465 significant digits printed, not the number of digits after the decimal
5466 point.<br>
5467 <br>
5468 I would like the committee to look at the definition carefully and
5469 correct the statement in 27.4.2.2</p>
5470 <p><b>Proposed resolution:</b></p>
5471 <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
5472 "(number of digits after the decimal point)".</p>
5473 <hr>
5474 <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>
5475 <p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
5476 is<br>
5477 <br>
5478 &nbsp;&nbsp;&nbsp; `"(1) *a is the largest element"<br>
5479 <br>
5480 I think this is incorrect and should be changed to the wording in the proposed
5481 resolution.</p>
5482 <p>Actually there are two independent changes:</p>
5483 <blockquote>
5484   <p>A-"part of largest equivalence class" instead of "largest", cause 25.3
5485   [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
5486   <p>B-Take
5487 'an oldest' from that equivalence class, otherwise the heap functions
5488 could not be used for a priority queue as explained in 23.2.3.2.2
5489 [lib.priqueue.members] (where I assume that a "priority queue" respects
5490 priority AND time).</p>
5491 </blockquote>
5492 <p><b>Proposed resolution:</b></p>
5493 <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>
5494 <blockquote>
5495   <p>(1) *a is the largest element</p>
5496 </blockquote>
5497 <p>to:</p>
5498 <blockquote>
5499   <p>(1) There is no element greater than <tt>*a</tt></p>
5500 </blockquote>
5501 <hr>
5502 <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>
5503 <p>Suppose that <tt>is.flags() &amp; ios_base::skipws</tt> is nonzero.
5504 What should <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor do if it
5505 reaches eof while skipping whitespace?  27.6.1.1.2/5 suggests it
5506 should set failbit. Should it set eofbit as well?  The standard
5507 doesn't seem to answer that question.</p>
5508
5509 <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
5510 <tt>basic_istream&lt;&gt;::sentry</tt> should ever set eofbit.  On the
5511 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
5512 extraction from a <tt>streambuf</tt> "returns
5513 <tt>traits::eof()</tt>, then the input function, except as explicitly
5514 noted otherwise, completes its actions and does
5515 <tt>setstate(eofbit)"</tt>.  So the question comes down to
5516 whether <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor is an
5517 input function.</p>
5518
5519 <p>Comments from Jerry Schwarz:</p>
5520 <blockquote>
5521 <p>It was always my intention that eofbit should be set any time that a
5522 virtual returned something to indicate eof, no matter what reason
5523 iostream code had for calling the virtual.</p>
5524 <p>
5525 The motivation for this is that I did not want to require streambufs
5526 to behave consistently if their virtuals are called after they have
5527 signaled eof.</p>
5528 <p>
5529 The classic case is a streambuf reading from a UNIX file.  EOF isn't
5530 really a state for UNIX file descriptors.  The convention is that a
5531 read on UNIX returns 0 bytes to indicate "EOF", but the file
5532 descriptor isn't shut down in any way and future reads do not
5533 necessarily also return 0 bytes.  In particular, you can read from
5534 tty's on UNIX even after they have signaled "EOF".  (It
5535 isn't always understood that a ^D on UNIX is not an EOF indicator, but
5536 an EOL indicator.  By typing a "line" consisting solely of
5537 ^D you cause a read to return 0 bytes, and by convention this is
5538 interpreted as end of file.)</p>
5539 </blockquote>
5540 <p><b>Proposed resolution:</b></p>
5541 <p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
5542 <blockquote>
5543 <p>If <tt>is.rdbuf()-&gt;sbumpc()</tt> or <tt>is.rdbuf()-&gt;sgetc()</tt>
5544 returns <tt>traits::eof()</tt>, the function calls
5545 <tt>setstate(failbit | eofbit)</tt> (which may throw
5546 <tt>ios_base::failure</tt>).
5547 </p>
5548 </blockquote>
5549 <hr>
5550 <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>
5551 <p>
5552 Is a pointer or reference obtained from an iterator still valid after
5553 destruction of the iterator?
5554 </p>
5555 <p>
5556 Is a pointer or reference obtained from an iterator still valid after the value
5557 of the iterator changes?
5558 </p>
5559 <blockquote>
5560 <pre>#include &lt;iostream&gt;
5561 #include &lt;vector&gt;
5562 #include &lt;iterator&gt;
5563
5564 int main()
5565 {
5566     typedef std::vector&lt;int&gt; vec_t;
5567     vec_t v;
5568     v.push_back( 1 );
5569
5570     // Is a pointer or reference obtained from an iterator still
5571     // valid after destruction of the iterator?
5572     int * p = &amp;*v.begin();
5573     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
5574
5575     // Is a pointer or reference obtained from an iterator still
5576     // valid after the value of the iterator changes?
5577     vec_t::iterator iter( v.begin() );
5578     p = &amp;*iter++;
5579     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
5580
5581     return 0;
5582 }
5583 </pre>
5584 </blockquote>
5585
5586 <p>The standard doesn't appear to directly address these
5587 questions. The standard needs to be clarified. At least two real-world
5588 cases have been reported where library implementors wasted
5589 considerable effort because of the lack of clarity in the
5590 standard. The question is important because requiring pointers and
5591 references to remain valid has the effect for practical purposes of
5592 prohibiting iterators from pointing to cached rather than actual
5593 elements of containers.</p>
5594
5595 <p>The standard itself assumes that pointers and references obtained
5596 from an iterator are still valid after iterator destruction or
5597 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
5598 effects:</p>
5599
5600 <blockquote>
5601   <pre>Iterator tmp = current;
5602 return *--tmp;</pre>
5603 </blockquote>
5604 <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>
5605 <blockquote>
5606   <pre>return &amp;(operator*());</pre>
5607 </blockquote>
5608
5609 <p>Because the standard itself assumes pointers and references remain
5610 valid after iterator destruction or change, the standard should say so
5611 explicitly. This will also reduce the chance of user code breaking
5612 unexpectedly when porting to a different standard library
5613 implementation.</p>
5614 <p><b>Proposed resolution:</b></p>
5615 <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>
5616 <blockquote>
5617 Destruction of an iterator may invalidate pointers and references
5618 previously obtained from that iterator.
5619 </blockquote>
5620
5621 <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>
5622
5623 <blockquote>
5624 <p><b>Effects:</b></p>
5625 <pre>  this-&gt;tmp = current;
5626   --this-&gt;tmp;
5627   return *this-&gt;tmp;
5628 </pre>
5629
5630 <p>
5631 [<i>Note:</i> This operation must use an auxiliary member variable,
5632 rather than a temporary variable, to avoid returning a reference that
5633 persists beyond the lifetime of its associated iterator.  (See
5634 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
5635 exposition only.  <i>--end note</i>]
5636 </p>
5637 </blockquote>
5638
5639 <p><i>[Post-Tokyo: The issue has been reformulated purely
5640 in terms of iterators.]</i></p>
5641
5642 <p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
5643 assumption by reverse_iterator. The issue and proposed resolution was
5644 reformulated yet again to reflect this reality.]</i></p>
5645
5646 <p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
5647 assumes its underlying iterator has persistent pointers and
5648 references.  Andy Koenig pointed out that it is possible to rewrite
5649 reverse_iterator so that it no longer makes such an assupmption.
5650 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
5651 decide it is intentional that <tt>p[n]</tt> may return by value
5652 instead of reference when <tt>p</tt> is a Random Access Iterator,
5653 other changes in reverse_iterator will be necessary.]</i></p>
5654 <p><b>Rationale:</b></p>
5655 <p>This issue has been discussed extensively.  Note that it is
5656 <i>not</i> an issue about the behavior of predefined iterators.  It is
5657 asking whether or not user-defined iterators are permitted to have
5658 transient pointers and references.  Several people presented examples
5659 of useful user-defined iterators that have such a property; examples
5660 include a B-tree iterator, and an "iota iterator" that doesn't point
5661 to memory.  Library implementors already seem to be able to cope with
5662 such iterators: they take pains to avoid forming references to memory
5663 that gets iterated past.  The only place where this is a problem is
5664 <tt>reverse_iterator</tt>, so this issue changes
5665 <tt>reverse_iterator</tt> to make it work.</p>
5666
5667 <p>This resolution does not weaken any guarantees provided by
5668 predefined iterators like <tt>list&lt;int&gt;::iterator</tt>.
5669 Clause 23 should be reviewed to make sure that guarantees for
5670 predefined iterators are as strong as users expect.</p>
5671
5672 <hr>
5673 <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>
5674 <p>
5675 Suppose that <tt>A</tt> is a class that conforms to the
5676 Allocator requirements of Table 32, and <tt>a</tt> is an
5677 object of class <tt>A</tt>  What should be the return
5678 value of <tt>a.allocate(0)</tt>?  Three reasonable
5679 possibilities: forbid the argument <tt>0</tt>, return
5680 a null pointer, or require that the return value be a
5681 unique non-null pointer.
5682 </p>
5683 <p><b>Proposed resolution:</b></p>
5684 <p>
5685 Add a note to the <tt>allocate</tt> row of Table 32:
5686 "[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
5687 <p><b>Rationale:</b></p>
5688 <p>A key to understanding this issue is that the ultimate use of
5689 allocate() is to construct an iterator, and that iterator for zero
5690 length sequences must be the container's past-the-end
5691 representation.  Since this already implies special case code, it
5692 would be over-specification to mandate the return value.
5693 </p>
5694 <hr>
5695 <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>
5696 <p>
5697 In table 74, the return type of the expression <tt>*a</tt> is given
5698 as <tt>T&amp;</tt>, where <tt>T</tt> is the iterator's value type.
5699 For constant iterators, however, this is wrong.  ("Value type"
5700 is never defined very precisely, but it is clear that the value type
5701 of, say, <tt>std::list&lt;int&gt;::const_iterator</tt> is supposed to be
5702 <tt>int</tt>, not <tt>const int</tt>.)
5703 </p>
5704 <p><b>Proposed resolution:</b></p>
5705 <p>
5706 In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
5707 return type from "<tt>T&amp;</tt>" to "<tt>T&amp;</tt>
5708 if <tt>X</tt> is mutable, otherwise <tt>const T&amp;</tt>".
5709 In the <tt>a-&gt;m</tt> row, change the return type from
5710 "<tt>U&amp;</tt>" to "<tt>U&amp;</tt> if <tt>X</tt> is mutable,
5711 otherwise <tt>const U&amp;</tt>".
5712 </p>
5713
5714 <p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
5715 there are multiple const problems with the STL portion of the library
5716 and that these should be addressed as a single package.&nbsp; Note
5717 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
5718 that very reason.]</i></p>
5719
5720 <p><i>[Redmond: the LWG thinks this is separable from other constness
5721 issues.  This issue is just cleanup; it clarifies language that was
5722 written before we had iterator_traits.  Proposed resolution was
5723 modified: the original version only discussed *a.  It was pointed out
5724 that we also need to worry about *r++ and a-&gt;m.]</i></p>
5725
5726 <hr>
5727 <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>
5728 <p>
5729 What should unique() do if you give it a predicate that is not an
5730 equivalence relation?  There are at least two plausible answers:
5731 </p>
5732
5733 <blockquote>
5734
5735 <p>
5736    1. You can't, because 25.2.8 says that it it "eliminates all but
5737    the first element from every consecutive group of equal
5738    elements..." and it wouldn't make sense to interpret "equal" as
5739    meaning anything but an equivalence relation.  [It also doesn't
5740    make sense to interpret "equal" as meaning ==, because then there
5741    would never be any sense in giving a predicate as an argument at
5742    all.]
5743 </p>
5744
5745 <p>
5746    2. The word "equal" should be interpreted to mean whatever the
5747    predicate says, even if it is not an equivalence relation
5748    (and in particular, even if it is not transitive).
5749 </p>
5750
5751 </blockquote>
5752
5753 <p>
5754 The example that raised this question is from Usenet:
5755 </p>
5756
5757 <blockquote>
5758
5759 <pre>int f[] = { 1, 3, 7, 1, 2 };
5760 int* z = unique(f, f+5, greater&lt;int&gt;());</pre>
5761
5762 </blockquote>
5763
5764 <p>
5765 If one blindly applies the definition using the predicate
5766 greater&lt;int&gt;, and ignore the word "equal", you get:
5767 </p>
5768
5769 <blockquote>
5770
5771 <p>
5772     Eliminates all but the first element from every consecutive group
5773     of elements referred to by the iterator i in the range [first, last)
5774     for which *i &gt; *(i - 1).
5775 </p>
5776
5777 </blockquote>
5778
5779 <p>
5780 The first surprise is the order of the comparison.  If we wanted to
5781 allow for the predicate not being an equivalence relation, then we
5782 should surely compare elements the other way: pred(*(i - 1), *i).  If
5783 we do that, then the description would seem to say: "Break the
5784 sequence into subsequences whose elements are in strictly increasing
5785 order, and keep only the first element of each subsequence".  So the
5786 result would be 1, 1, 2.  If we take the description at its word, it
5787 would seem to call for strictly DEcreasing order, in which case the
5788 result should be 1, 3, 7, 2.<br>
5789 <br>
5790 In fact, the SGI implementation of unique() does neither: It yields 1,
5791 3, 7.
5792 </p>
5793 <p><b>Proposed resolution:</b></p>
5794 <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>
5795 <blockquote>
5796 For a nonempty range, eliminates all but the first element from every
5797 consecutive group of equivalent elements referred to by the iterator
5798 <tt>i</tt> in the range [first+1, last) for which the following
5799 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
5800 false</tt>.
5801 </blockquote>
5802
5803 <p>
5804 Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
5805 comparison function must be an equivalence relation."
5806 </p>
5807
5808 <p><i>[Redmond: discussed arguments for and against requiring the
5809 comparison function to be an equivalence relation.  Straw poll:
5810 14-2-5.  First number is to require that it be an equivalence
5811 relation, second number is to explicitly not require that it be an
5812 equivalence relation, third number is people who believe they need
5813 more time to consider the issue.  A separate issue: Andy Sawyer
5814 pointed out that "i-1" is incorrect, since "i" can refer to the first
5815 iterator in the range.  Matt provided wording to address this
5816 problem.]</i></p>
5817
5818 <p><i>[Curaçao: The LWG changed "... the range (first,
5819 last)..." to "...  the range [first+1, last)..." for
5820 clarity. They considered this change close enough to editorial to not
5821 require another round of review.]</i></p>
5822
5823 <p><b>Rationale:</b></p>
5824 <p>The LWG also considered an alternative resolution: change
5825 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>
5826
5827 <blockquote>
5828 For a nonempty range, eliminates all but the first element from every
5829 consecutive group of elements referred to by the iterator
5830 <tt>i</tt> in the range (first, last) for which the following
5831 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
5832 false</tt>.
5833 </blockquote>
5834
5835 <p>
5836 Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
5837 comparison function need not be an equivalence relation."
5838 </p>
5839
5840
5841 <p>Informally: the proposed resolution imposes an explicit requirement
5842 that the comparison function be an equivalence relation.  The
5843 alternative resolution does not, and it gives enough information so
5844 that the behavior of unique() for a non-equivalence relation is
5845 specified.  Both resolutions are consistent with the behavior of
5846 existing implementations.</p>
5847 <hr>
5848 <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>
5849 <p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
5850 past-the-end values are always non-singular."</p>
5851 <p>This places an unnecessary restriction on past-the-end iterators for
5852 containers with forward iterators (for example, a singly-linked list). If the
5853 past-the-end value on such a container was a well-known singular value, it would
5854 still satisfy all forward iterator requirements.</p>
5855 <p>Removing this restriction would allow, for example, a singly-linked list
5856 without a "footer" node.</p>
5857 <p>This would have an impact on existing code that expects past-the-end
5858 iterators obtained from different (generic) containers being not equal.</p>
5859 <p><b>Proposed resolution:</b></p>
5860 <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>
5861 <blockquote>
5862 <p>Dereferenceable and past-the-end values are always non-singular.</p>
5863 </blockquote>
5864 <p>to:</p>
5865 <blockquote>
5866 <p>Dereferenceable values are always non-singular.&nbsp;</p>
5867 </blockquote>
5868 <p><b>Rationale:</b></p>
5869 <p>For some kinds of containers, including singly linked lists and
5870 zero-length vectors, null pointers are perfectly reasonable past-the-end
5871 iterators.  Null pointers are singular.
5872 </p>
5873 <hr>
5874 <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>
5875 <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
5876 declarations use a consistent style except for the following functions:</p>
5877 <blockquote>
5878   <pre>void push_back(const charT);
5879 basic_string&amp; assign(const basic_string&amp;);
5880 void swap(basic_string&lt;charT,traits,Allocator&gt;&amp;);</pre>
5881 </blockquote>
5882 <p>- push_back, assign, swap: missing argument name&nbsp;<br>
5883 - push_back: use of const with charT (i.e. POD type passed by value
5884 not by reference - should be charT or const charT&amp; )<br>
5885 - swap: redundant use of template parameters in argument
5886 basic_string&lt;charT,traits,Allocator&gt;&amp;</p>
5887 <p><b>Proposed resolution:</b></p>
5888 <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
5889 function declarations push_back, assign, and swap to:</p>
5890 <blockquote>
5891   <pre>void push_back(charT c);
5892
5893 basic_string&amp; assign(const basic_string&amp; str);
5894 void swap(basic_string&amp; str);</pre>
5895 </blockquote>
5896 <p><b>Rationale:</b></p>
5897 <p>Although the standard is in general not consistent in declaration
5898 style, the basic_string declarations are consistent other than the
5899 above.  The LWG felt that this was sufficient reason to merit the
5900 change.
5901 </p>
5902 <hr>
5903 <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>
5904 <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>
5905 <blockquote>
5906   <p>      In the description of the algorithms operators + and - are used
5907            for some of the iterator categories for which they do not have to
5908            be defined. In these cases the semantics of [...] a-b is the same
5909            as of<br>
5910   <br>
5911   &nbsp;&nbsp;&nbsp;&nbsp; <tt>return distance(a, b);</tt></p>
5912 </blockquote>
5913 <p><b>Proposed resolution:</b></p>
5914 <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
5915 <tt>"a-b"</tt> to <tt>"b-a".</tt></p>
5916 <p><b>Rationale:</b></p>
5917 <p>There are two ways to fix the defect; change the description to b-a
5918 or change the return to distance(b,a).  The LWG preferred the
5919 former for consistency.</p>
5920 <hr>
5921 <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>
5922 <p>The description of the stream extraction operator for std::string (section
5923 21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
5924 the case that the operator fails to extract any characters from the input
5925 stream.</p>
5926 <p>This implies that the typical construction</p>
5927 <blockquote>
5928   <pre>std::istream is;
5929 std::string str;
5930 ...
5931 while (is &gt;&gt; str) ... ;</pre>
5932 </blockquote>
5933 <p>(which tests failbit) is not required to terminate at EOF.</p>
5934 <p>Furthermore, this is inconsistent with other extraction operators,
5935 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
5936 requirement is present, either explicitly or implicitly, for the
5937 extraction operators. It is also present explicitly in the description
5938 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>
5939 <p><b>Proposed resolution:</b></p>
5940 <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>
5941 <blockquote>
5942
5943 <p>If the function extracts no characters, it calls
5944 is.setstate(ios::failbit) which may throw ios_base::failure
5945 (27.4.4.3).</p>
5946 </blockquote>
5947 <hr>
5948 <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>
5949 <p>The standard doesn't specify what min_element() and max_element() shall
5950 return if the range is empty (first equals last). The usual implementations
5951 return last. This problem seems also apply to partition(), stable_partition(),
5952 next_permutation(), and prev_permutation().</p>
5953 <p><b>Proposed resolution:</b></p>
5954 <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
5955 9, append: Returns last if first==last.</p>
5956 <p><b>Rationale:</b></p>
5957 <p>The LWG looked in some detail at all of the above mentioned
5958 algorithms, but believes that except for min_element() and
5959 max_element() it is already clear that last is returned if first ==
5960 last.</p>
5961 <hr>
5962 <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>
5963 <p>The specification for the associative container requirements in
5964 Table 69 state that the find member function should "return
5965 iterator; const_iterator for constant a". The map and multimap
5966 container descriptions have two overloaded versions of find, but set
5967 and multiset do not, all they have is:</p>
5968 <blockquote>
5969   <pre>iterator find(const key_type &amp; x) const;</pre>
5970 </blockquote>
5971 <p><b>Proposed resolution:</b></p>
5972 <p>Change the prototypes for find(), lower_bound(), upper_bound(), and
5973 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>
5974 <blockquote>
5975   <pre>iterator find(const key_type &amp; x);
5976 const_iterator find(const key_type &amp; x) const;</pre>
5977   <pre>iterator lower_bound(const key_type &amp; x);
5978 const_iterator lower_bound(const key_type &amp; x) const;</pre>
5979   <pre>iterator upper_bound(const key_type &amp; x);
5980 const_iterator upper_bound(const key_type &amp; x) const;</pre>
5981   <pre>pair&lt;iterator, iterator&gt; equal_range(const key_type &amp; x);
5982 pair&lt;const_iterator, const_iterator&gt; equal_range(const key_type &amp; x) const;</pre>
5983 </blockquote>
5984
5985 <p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
5986 extending the proposed resolution to lower_bound, upper_bound, and
5987 equal_range.]</i></p>
5988 <hr>
5989 <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>
5990 <p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
5991 <p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
5992 must be const in order for it to be callable on a const object (a reference to
5993 which which is what std::use_facet&lt;&gt;() returns).</p>
5994 <p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
5995 name of the namespace `My'.</p>
5996 <p>3) In the definition of `loc' and subsequently in the call to use_facet&lt;&gt;()
5997 in main(), the name of the facet is misspelled: it should read `My::JCtype'
5998 rather than `My::JCType'.</p>
5999 <p><b>Proposed resolution:</b></p>
6000 <p>Replace the "Classifying Japanese characters" example in 22.2.8,
6001 paragraph 11 with the following:</p>
6002 <pre>#include &lt;locale&gt;</pre>
6003 <pre>namespace My {
6004     using namespace std;
6005     class JCtype : public locale::facet {
6006     public:
6007         static locale::id id;     //  required for use as a new locale facet
6008         bool is_kanji (wchar_t c) const;
6009         JCtype() {}
6010     protected:
6011         ~JCtype() {}
6012     };
6013 }</pre>
6014 <pre>//  file:  filt.C
6015 #include &lt;iostream&gt;
6016 #include &lt;locale&gt;
6017 #include "jctype"                 //  above
6018 std::locale::id My::JCtype::id;   //  the static  JCtype  member
6019 declared above.</pre>
6020 <pre>int main()
6021 {
6022     using namespace std;
6023     typedef ctype&lt;wchar_t&gt; wctype;
6024     locale loc(locale(""),              //  the user's preferred locale...
6025                new My::JCtype);         //  and a new feature ...
6026     wchar_t c = use_facet&lt;wctype&gt;(loc).widen('!');
6027     if (!use_facet&lt;My::JCtype&gt;(loc).is_kanji(c))
6028         cout &lt;&lt; "no it isn't!" &lt;&lt; endl;
6029     return 0;
6030 }</pre>
6031 <hr>
6032 <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>
6033 <p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
6034 paragraph 2:</p>
6035 <blockquote>
6036   <p>Effects: Destroys an object of class ios_base. Calls each registered
6037   callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
6038   time that any ios_base member function called from within fn has well defined
6039   results.</p>
6040 </blockquote>
6041 <p>But what is not clear is: If no callback functions were ever registered, does
6042 it matter whether the ios_base members were ever initialized?</p>
6043 <p>For instance, does this program have defined behavior:</p>
6044 <blockquote>
6045   <pre>#include &lt;ios&gt;</pre>
6046   <pre>class D : public std::ios_base { };</pre>
6047   <pre>int main() { D d; }</pre>
6048 </blockquote>
6049 <p>It seems that registration of a callback function would surely affect the
6050 state of an ios_base. That is, when you register a callback function with an
6051 ios_base, the ios_base must record that fact somehow.</p>
6052 <p>But if after construction the ios_base is in an indeterminate state, and that
6053 state is not made determinate before the destructor is called, then how would
6054 the destructor know if any callbacks had indeed been registered? And if the
6055 number of callbacks that had been registered is indeterminate, then is not the
6056 behavior of the destructor undefined?</p>
6057 <p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
6058 it explicit that destruction before initialization results in undefined
6059 behavior.</p>
6060 <p><b>Proposed resolution:</b></p>
6061 <p>Modify 27.4.2.7 paragraph 1 from</p>
6062 <blockquote>
6063   <p>Effects: Each ios_base member has an indeterminate value after
6064   construction.</p>
6065 </blockquote>
6066 <p>to</p>
6067 <blockquote>
6068   <p>Effects: Each ios_base member has an indeterminate
6069 value after construction. These members must be initialized by calling
6070 basic_ios::init. If an ios_base object is destroyed before these
6071 initializations have taken place, the behavior is undefined.</p>
6072 </blockquote>
6073 <hr>
6074 <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>
6075 <p>Stage 2 processing of numeric conversion is broken.</p>
6076
6077 <p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
6078 conversion specifier is %i. A %i specifier determines a number's base
6079 by its prefix (0 for octal, 0x for hex), so the intention is clearly
6080 that a 0x prefix is allowed.  Paragraph 8 in the same section,
6081 however, describes very precisely how characters are processed. (It
6082 must be done "as if" by a specified code fragment.) That
6083 description does not allow a 0x prefix to be recognized.</p>
6084
6085 <p>Very roughly, stage 2 processing reads a char_type ct. It converts
6086 ct to a char, not by using narrow but by looking it up in a
6087 translation table that was created by widening the string literal
6088 "0123456789abcdefABCDEF+-". The character "x" is
6089 not found in that table, so it can't be recognized by stage 2
6090 processing.</p>
6091 <p><b>Proposed resolution:</b></p>
6092 <p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
6093 <blockquote>
6094   <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
6095 </blockquote>
6096 <p>with the line:</p>
6097 <blockquote>
6098   <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
6099 </blockquote>
6100 <p><b>Rationale:</b></p>
6101 <p>If we're using the technique of widening a string literal, the
6102 string literal must contain every character we wish to recognize.
6103 This technique has the consequence that alternate representations
6104 of digits will not be recognized.  This design decision was made
6105 deliberately, with full knowledge of that limitation.</p>
6106 <hr>
6107 <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>
6108 <p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
6109 <blockquote>
6110   <pre>21.3.6.8 - basic_string::compare [lib.string::compare]
6111
6112 int compare(size_type pos1, size_type n1,
6113                 const basic_string&lt;charT,traits,Allocator&gt;&amp;  str ,
6114                 size_type  pos2 , size_type  n2 ) const;
6115
6116 -4- Returns:
6117
6118     basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
6119                  basic_string&lt;charT,traits,Allocator&gt;(str,pos2,n2)) .</pre>
6120 </blockquote>
6121 <p>and the constructor that's implicitly called by the above is
6122 defined to throw an out-of-range exception if pos &gt; str.size(). See
6123 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>
6124
6125 <p>On the other hand, the compare function descriptions themselves don't have
6126 "Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
6127 that do not apply to a function are omitted.</p>
6128 <p>So it seems there is an inconsistency in the standard -- are the
6129 "Effects" clauses correct, or are the "Throws" clauses
6130 missing?</p>
6131 <p><b>Proposed resolution:</b></p>
6132 <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
6133 the sentence "Descriptions of function semantics contain the
6134 following elements (as appropriate):", insert the word
6135 "further" so that the foot note reads:</p>
6136 <blockquote>
6137   <p>To save space, items that do not apply to a function are
6138   omitted. For example, if a function does not specify any further
6139   preconditions, there will be no "Requires" paragraph.</p>
6140 </blockquote>
6141 <p><b>Rationale:</b></p>
6142 <p>The standard is somewhat inconsistent, but a failure to note a
6143 throw condition in a throws clause does not grant permission not to
6144 throw.  The inconsistent wording is in a footnote, and thus
6145 non-normative. The proposed resolution from the LWG clarifies the
6146 footnote.</p>
6147 <hr>
6148 <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>
6149 <p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
6150 <p><b>Proposed resolution:</b></p>
6151 <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>
6152   <blockquote>
6153   Effects: For each non-negative integer i &lt;= (last - first)/2,
6154   applies swap to all pairs of iterators first + i, (last - i) - 1.
6155   </blockquote>
6156 <p>with:</p>
6157   <blockquote>
6158   Effects: For each non-negative integer i &lt;= (last - first)/2,
6159   applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
6160   </blockquote>
6161 <hr>
6162 <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>
6163 <p>In the associative container requirements table in 23.1.2 paragraph 7,
6164 a.clear() has complexity "log(size()) + N". However, the meaning of N
6165 is not defined.</p>
6166 <p><b>Proposed resolution:</b></p>
6167 <p>In the associative container requirements table in 23.1.2 paragraph
6168 7, the complexity of a.clear(), change "log(size()) + N" to
6169 "linear in <tt>size()</tt>".</p>
6170 <p><b>Rationale:</b></p>
6171 <p>It's the "log(size())", not the "N", that is in
6172 error: there's no difference between <i>O(N)</i> and <i>O(N +
6173 log(N))</i>.  The text in the standard is probably an incorrect
6174 cut-and-paste from the range version of <tt>erase</tt>.</p>
6175 <hr>
6176 <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>
6177 <p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
6178 user namespaces might be found through Koenig lookup?</p>
6179 <p>For example, a popular standard library implementation includes this
6180 implementation of std::unique:</p>
6181 <blockquote>
6182 <pre>namespace std {
6183     template &lt;class _ForwardIter&gt;
6184     _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
6185       __first = adjacent_find(__first, __last);
6186       return unique_copy(__first, __last, __first);
6187     }
6188     }</pre>
6189 </blockquote>
6190 <p>Imagine two users on opposite sides of town, each using unique on his own
6191 sequences bounded by my_iterators . User1 looks at his standard library
6192 implementation and says, "I know how to implement a more efficient
6193 unique_copy for my_iterators", and writes:</p>
6194 <blockquote>
6195 <pre>namespace user1 {
6196     class my_iterator;
6197     // faster version for my_iterator
6198     my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
6199     }</pre>
6200 </blockquote>
6201 <p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
6202 <p>User2 has other needs, and writes:</p>
6203 <blockquote>
6204 <pre>namespace user2 {
6205     class my_iterator;
6206     // Returns true iff *c is a unique copy of *a and *b.
6207     bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
6208     }</pre>
6209 </blockquote>
6210 <p>User2 is shocked to find later that his fully-qualified use of
6211 std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
6212 compile (if he's lucky). Looking in the standard, he sees the following Effects
6213 clause for unique():</p>
6214 <blockquote>
6215   <p>Effects: Eliminates all but the first element from every consecutive group
6216   of equal elements referred to by the iterator i in the range [first, last) for
6217   which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
6218   *(i - 1)) != false</p>
6219 </blockquote>
6220 <p>The standard gives user2 absolutely no reason to think he can interfere with
6221 std::unique by defining names in namespace user2. His standard library has been
6222 built with the template export feature, so he is unable to inspect the
6223 implementation. User1 eventually compiles his code with another compiler, and
6224 his version of unique_copy silently stops being called. Eventually, he realizes
6225 that he was depending on an implementation detail of his library and had no
6226 right to expect his unique_copy() to be called portably.</p>
6227 <p>On the face of it, and given above scenario, it may seem obvious that the
6228 implementation of unique() shown is non-conforming because it uses unique_copy()
6229 rather than ::std::unique_copy(). Most standard library implementations,
6230 however, seem to disagree with this notion.</p>
6231 <p> <i>[Tokyo:&nbsp; Steve Adamczyk from
6232 the core working group indicates that "std::" is sufficient;&nbsp;
6233 leading "::" qualification is not required because any namespace
6234 qualification is sufficient to suppress Koenig lookup.]</i></p>
6235 <p><b>Proposed resolution:</b></p>
6236 <p>Add a paragraph and a note at the end of
6237 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>
6238 <blockquote>
6239
6240 <p>Unless otherwise specified, no global or non-member function in the
6241 standard library shall use a function from another namespace which is
6242 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>
6243
6244 <p>[Note: the phrase "unless otherwise specified" is intended to
6245 allow Koenig lookup in cases like that of ostream_iterators:<br>
6246
6247 <br>
6248   Effects:</p>
6249   <blockquote>
6250 <p>*out_stream &lt;&lt; value;<br>
6251       if(delim != 0) *out_stream &lt;&lt; delim;<br>
6252       return (*this);</p>
6253     <p>--end note]</p>
6254   </blockquote>
6255 </blockquote>
6256
6257 <p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
6258 is as yet unsure if the proposed resolution is the best
6259 solution. Furthermore, the LWG believes that the same problem of
6260 unqualified library names applies to wording in the standard itself,
6261 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
6262 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
6263 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>.]</i></p>
6264
6265 <p><i>[Toronto: The LWG is not sure if this is a defect in the
6266 standard.  Most LWG members believe that an implementation of
6267 <tt>std::unique</tt> like the one quoted in this issue is already
6268 illegal, since, under certain circumstances, its semantics are not
6269 those specified in the standard.  The standard's description of
6270 <tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
6271 should have any effect.]</i></p>
6272
6273 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
6274 225, 226, and 229.  Their conclusion was that the issues should be
6275 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6276 EWG portion (Dave will write a proposal). The LWG and EWG had
6277 (separate) discussions of this plan the next day.  The proposed
6278 resolution for this issue is in accordance with Howard's paper.]</i></p>
6279
6280 <p><b>Rationale:</b></p>
6281 <p>It could be argued that this proposed isn't strictly necessary,
6282   that the Standard doesn't grant implementors license to write a
6283   standard function that behaves differently than specified in the
6284   Standard just because of an unrelated user-defined name in some
6285   other namespace.  However, this is at worst a clarification.  It is
6286   surely right that algorithsm shouldn't pick up random names, that
6287   user-defined names should have no effect unless otherwise specified.
6288   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
6289   appropriate for the standard to explicitly specify otherwise.</p>
6290 <hr>
6291 <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>
6292 <p>The issues are:&nbsp;</p>
6293 <p>1. How can a 3rd party library implementor (lib1) write a version of a standard
6294 algorithm which is specialized to work with his own class template?&nbsp;</p>
6295 <p>2. How can another library implementor (lib2) write a generic algorithm which
6296 will take advantage of the specialized algorithm in lib1?</p>
6297 <p>This appears to be the only viable answer under current language rules:</p>
6298 <blockquote>
6299   <pre>namespace lib1
6300 {
6301     // arbitrary-precision numbers using T as a basic unit
6302     template &lt;class T&gt;
6303     class big_num { //...
6304     };
6305     </pre>
6306   <pre>    // defining this in namespace std is illegal (it would be an
6307     // overload), so we hope users will rely on Koenig lookup
6308     template &lt;class T&gt;
6309     void swap(big_int&lt;T&gt;&amp;, big_int&lt;T&gt;&amp;);
6310 }</pre>
6311   <pre>#include &lt;algorithm&gt;
6312 namespace lib2
6313 {
6314     template &lt;class T&gt;
6315     void generic_sort(T* start, T* end)
6316     {
6317             ...
6318         // using-declaration required so we can work on built-in types
6319         using std::swap;
6320         // use Koenig lookup to find specialized algorithm if available
6321         swap(*x, *y);
6322     }
6323 }</pre>
6324 </blockquote>
6325 <p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
6326 and somewhat slippery. The implementor needs to remember to write the
6327 using-declaration, or generic_sort will fail to compile when T is a built-in
6328 type. The second drawback is that the use of this style in lib2 effectively
6329 "reserves" names in any namespace which defines types which may
6330 eventually be used with lib2. This may seem innocuous at first when applied to
6331 names like swap, but consider more ambiguous names like unique_copy() instead.
6332 It is easy to imagine the user wanting to define these names differently in his
6333 own namespace. A definition with semantics incompatible with the standard
6334 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>
6335 <p>Why, you may ask, can't we just partially specialize std::swap()? It's
6336 because the language doesn't allow for partial specialization of function
6337 templates. If you write:</p>
6338 <blockquote>
6339   <pre>namespace std
6340 {
6341     template &lt;class T&gt;
6342     void swap(lib1::big_int&lt;T&gt;&amp;, lib1::big_int&lt;T&gt;&amp;);
6343 }</pre>
6344 </blockquote>
6345 <p>You have just overloaded std::swap, which is illegal under the current
6346 language rules. On the other hand, the following full specialization is legal:</p>
6347 <blockquote>
6348   <pre>namespace std
6349 {
6350     template &lt;&gt;
6351     void swap(lib1::other_type&amp;, lib1::other_type&amp;);
6352 }</pre>
6353 </blockquote>
6354
6355 <p>This issue reflects concerns raised by the "Namespace issue
6356 with specialized swap" thread on comp.lang.c++.moderated. A
6357 similar set of concerns was earlier raised on the boost.org mailing
6358 list and the ACCU-general mailing list.  Also see library reflector
6359 message c++std-lib-7354.</p>
6360
6361 <p>
6362 J. C. van Winkel points out (in c++std-lib-9565) another unexpected
6363 fact: it's impossible to output a container of std::pair's using copy
6364 and an ostream_iterator, as long as both pair-members are built-in or
6365 std:: types.  That's because a user-defined operator&lt;&lt; for (for
6366 example) std::pair&lt;const std::string, int&gt; will not be found:
6367 lookup for operator&lt;&lt; will be performed only in namespace std.
6368 Opinions differed on whether or not this was a defect, and, if so,
6369 whether the defect is that something is wrong with user-defined
6370 functionality and std, or whether it's that the standard library does
6371 not provide an operator&lt;&lt; for std::pair&lt;&gt;.
6372 </p>
6373
6374 <p><b>Proposed resolution:</b></p>
6375
6376 <p>Adopt the wording proposed in Howard Hinnant's paper
6377   N1523=03-0106, "Proposed Resolution To LWG issues 225, 226, 229".</p>
6378
6379
6380 <p><i>[Tokyo: Summary, "There is no conforming way to extend
6381 std::swap for user defined templates."&nbsp; The LWG agrees that
6382 there is a problem.  Would like more information before
6383 proceeding. This may be a core issue.  Core issue 229 has been opened
6384 to discuss the core aspects of this problem. It was also noted that
6385 submissions regarding this issue have been received from several
6386 sources, but too late to be integrated into the issues list.
6387 ]</i></p>
6388
6389 <p><i>[Post-Tokyo: A paper with several proposed resolutions,
6390 J16/00-0029==WG21/N1252, "Shades of namespace std functions
6391 " by Alan Griffiths, is in the Post-Tokyo mailing. It
6392 should be considered a part of this issue.]</i></p>
6393
6394 <p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
6395 resolution that involves core changes: it would add partial
6396 specialization of function template.  The Core Working Group is
6397 reluctant to add partial specialization of function templates.  It is
6398 viewed as a large change, CWG believes that proposal presented leaves
6399 some syntactic issues unanswered; if the CWG does add partial
6400 specialization of function templates, it wishes to develop its own
6401 proposal.  The LWG continues to believe that there is a serious
6402 problem: there is no good way for users to force the library to use
6403 user specializations of generic standard library functions, and in
6404 certain cases (e.g. transcendental functions called by
6405 <tt>valarray</tt> and <tt>complex</tt>) this is important.  Koenig
6406 lookup isn't adequate, since names within the library must be
6407 qualified with <tt>std</tt> (see issue 225), specialization doesn't
6408 work (we don't have partial specialization of function templates), and
6409 users aren't permitted to add overloads within namespace std.
6410 ]</i></p>
6411
6412 <p><i>[Copenhagen: Discussed at length, with no consensus.  Relevant
6413 papers in the pre-Copenhagen mailing: N1289, N1295, N1296.  Discussion
6414 focused on four options. (1) Relax restrictions on overloads within
6415 namespace std. (2) Mandate that the standard library use unqualified
6416 calls for <tt>swap</tt> and possibly other functions.  (3) Introduce
6417 helper class templates for <tt>swap</tt> and possibly other functions.
6418 (4) Introduce partial specialization of function templates.  Every
6419 option had both support and opposition.  Straw poll (first number is
6420 support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
6421 (4) 4, 4.]</i></p>
6422
6423 <p><i>[Redmond: Discussed, again no consensus.  Herb presented an
6424 argument that a user who is defining a type <tt>T</tt> with an
6425 associated <tt>swap</tt> should not be expected to put that
6426 <tt>swap</tt> in namespace std, either by overloading or by partial
6427 specialization.  The argument is that <tt>swap</tt> is part of
6428 <tt>T</tt>'s interface, and thus should to in the same namespace as
6429 <tt>T</tt> and only in that namespace.  If we accept this argument,
6430 the consequence is that standard library functions should use
6431 unqualified call of <tt>swap</tt>.  (And which other functions? Any?)
6432 A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
6433 try to put together a proposal before the next meeting.]</i></p>
6434
6435 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
6436 225, 226, and 229.  Their conclusion was that the issues should be
6437 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6438 EWG portion (Dave will write a proposal). The LWG and EWG had
6439 (separate) discussions of this plan the next day.  The proposed
6440 resolution is the one proposed by Howard.]</i></p>
6441
6442 <p><i>[Santa Cruz: the LWG agreed with the general direction of
6443   Howard's paper, N1387.  (Roughly: Koenig lookup is disabled unless
6444   we say otherwise; this issue is about when we do say otherwise.)
6445   However, there were concerns about wording.  Howard will provide new
6446   wording.  Bill and Jeremy will review it.]</i></p>
6447
6448 <p><i>[Kona: Howard proposed the new wording.  The LWG accepted his
6449   proposed resolution.]</i></p>
6450
6451 <p><b>Rationale:</b></p>
6452 <p>Informally: introduce a Swappable concept, and specify that the
6453   value types of the iterators passed to certain standard algorithms
6454   (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
6455   to that concept.  The Swappable concept will make it clear that
6456   these algorithms use unqualified lookup for the calls
6457   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,
6458   state that the valarray transcendentals use unqualified lookup.</p>
6459 <hr>
6460 <a name="227"></a><h3><a name="227">227.&nbsp;std::swap() should require CopyConstructible or DefaultConstructible arguments</a></h3><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>
6461 <p>25.2.2 reads:</p>
6462 <blockquote>
6463   <p><tt>  template&lt;class T&gt; void swap(T&amp; a, T&amp; b);</tt><br>
6464   <br>
6465   Requires:    Type T is Assignable (_lib.container.requirements_).<br>
6466   Effects:    Exchanges values stored in two locations.</p>
6467 </blockquote>
6468 <p>The only reasonable** generic implementation of swap requires construction of a
6469    new temporary copy of one of its arguments:</p>
6470 <blockquote>
6471 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
6472   {
6473       T tmp(a);
6474       a = b;
6475       b = tmp;
6476   }</pre>
6477 </blockquote>
6478 <p>But a type which is only Assignable cannot be swapped by this implementation.</p>
6479 <p>**Yes, there's also an unreasonable implementation which would require T to be
6480    DefaultConstructible instead of CopyConstructible. I don't think this is worthy
6481    of consideration:</p>
6482 <blockquote>
6483 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
6484 {
6485     T tmp;
6486     tmp = a;
6487     a = b;
6488     b = tmp;
6489 }</pre>
6490 </blockquote>
6491 <p><b>Proposed resolution:</b></p>
6492 <p>Change 25.2.2 paragraph 1 from:</p>
6493 <blockquote>
6494 <p>  Requires: Type T is Assignable (23.1).</p>
6495 </blockquote>
6496 <p>to:</p>
6497 <blockquote>
6498 <p>  Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
6499 </blockquote>
6500 <hr>
6501 <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>
6502 <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>,
6503 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
6504 definitions of the "..._byname" classes by listing a bunch
6505 of virtual functions. At the same time, no semantics of these
6506 functions are defined. Real implementations do not define these
6507 functions because the functional part of the facets is actually
6508 implemented in the corresponding base classes and the constructor of
6509 the "..._byname" version just provides suitable date used by
6510 these implementations. For example, the 'numpunct' methods just return
6511 values from a struct. The base class uses a statically initialized
6512 struct while the derived version reads the contents of this struct
6513 from a table.  However, no virtual function is defined in
6514 'numpunct_byname'.</p>
6515
6516 <p>For most classes this does not impose a problem but specifically
6517 for 'ctype' it does: The specialization for 'ctype_byname&lt;char&gt;'
6518 is required because otherwise the semantics would change due to the
6519 virtual functions defined in the general version for 'ctype_byname':
6520 In 'ctype&lt;char&gt;' the method 'do_is()' is not virtual but it is
6521 made virtual in both 'ctype&lt;cT&gt;' and 'ctype_byname&lt;cT&gt;'.
6522 Thus, a class derived from 'ctype_byname&lt;char&gt;' can tell whether
6523 this class is specialized or not under the current specification:
6524 Without the specialization, 'do_is()' is virtual while with
6525 specialization it is not virtual.</p>
6526 <p><b>Proposed resolution:</b></p>
6527 <p>&nbsp; Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
6528 <pre>     namespace std {
6529        template &lt;class charT&gt;
6530        class ctype_byname : public ctype&lt;charT&gt; {
6531        public:
6532          typedef ctype&lt;charT&gt;::mask mask;
6533          explicit ctype_byname(const char*, size_t refs = 0);
6534        protected:
6535         ~ctype_byname();             //  virtual
6536        };
6537      }</pre>
6538 <p>&nbsp; Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
6539 <pre>    namespace std {
6540       template &lt;class internT, class externT, class stateT&gt;
6541       class codecvt_byname : public codecvt&lt;internT, externT, stateT&gt; {
6542       public:
6543        explicit codecvt_byname(const char*, size_t refs = 0);
6544       protected:
6545       ~codecvt_byname();             //  virtual
6546        };
6547      }
6548 </pre>
6549 <p>&nbsp; Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
6550 <pre>     namespace std {
6551        template &lt;class charT&gt;
6552        class numpunct_byname : public numpunct&lt;charT&gt; {
6553      //  this class is specialized for  char  and  wchar_t.
6554        public:
6555          typedef charT                char_type;
6556          typedef basic_string&lt;charT&gt;  string_type;
6557          explicit numpunct_byname(const char*, size_t refs = 0);
6558        protected:
6559         ~numpunct_byname();          //  virtual
6560        };
6561      }</pre>
6562 <p>&nbsp; Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
6563 <pre>     namespace std {
6564        template &lt;class charT&gt;
6565        class collate_byname : public collate&lt;charT&gt; {
6566        public:
6567          typedef basic_string&lt;charT&gt; string_type;
6568          explicit collate_byname(const char*, size_t refs = 0);
6569        protected:
6570         ~collate_byname();           //  virtual
6571        };
6572      }</pre>
6573 <p>&nbsp; Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
6574 <pre>     namespace std {
6575        template &lt;class charT, class InputIterator = istreambuf_iterator&lt;charT&gt; &gt;
6576        class time_get_byname : public time_get&lt;charT, InputIterator&gt; {
6577        public:
6578          typedef time_base::dateorder dateorder;
6579          typedef InputIterator        iter_type</pre>
6580 <pre>         explicit time_get_byname(const char*, size_t refs = 0);
6581        protected:
6582         ~time_get_byname();          //  virtual
6583        };
6584      }</pre>
6585 <p>&nbsp; Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
6586 <pre>     namespace std {
6587        template &lt;class charT, class OutputIterator = ostreambuf_iterator&lt;charT&gt; &gt;
6588        class time_put_byname : public time_put&lt;charT, OutputIterator&gt;
6589        {
6590        public:
6591          typedef charT          char_type;
6592          typedef OutputIterator iter_type;</pre>
6593 <pre>         explicit time_put_byname(const char*, size_t refs = 0);
6594        protected:
6595         ~time_put_byname();          //  virtual
6596        };
6597      }"</pre>
6598 <p>&nbsp; Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
6599 <pre>     namespace std {
6600        template &lt;class charT, bool Intl = false&gt;
6601        class moneypunct_byname : public moneypunct&lt;charT, Intl&gt; {
6602        public:
6603          typedef money_base::pattern pattern;
6604          typedef basic_string&lt;charT&gt; string_type;</pre>
6605 <pre>         explicit moneypunct_byname(const char*, size_t refs = 0);
6606        protected:
6607         ~moneypunct_byname();        //  virtual
6608        };
6609      }</pre>
6610 <p>&nbsp; Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
6611 <pre>     namespace std {
6612        template &lt;class charT&gt;
6613        class messages_byname : public messages&lt;charT&gt; {
6614        public:
6615          typedef messages_base::catalog catalog;
6616          typedef basic_string&lt;charT&gt;    string_type;</pre>
6617 <pre>         explicit messages_byname(const char*, size_t refs = 0);
6618        protected:
6619         ~messages_byname();          //  virtual
6620        };
6621      }</pre>
6622 <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
6623 this case only those members are defined to be virtual which are
6624 defined to be virtual in 'ctype&lt;cT&gt;'.)</p>
6625
6626 <p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of
6627 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>
6628
6629 <p><i>[Copenhagen: proposed resolution was revised slightly, to remove
6630 three last virtual functions from <tt>messages_byname</tt>.]</i></p>
6631
6632 <hr>
6633 <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>
6634 <p>Throughout the library chapters, the descriptions of library entities refer
6635 to other library entities without necessarily qualifying the names.</p>
6636
6637 <p>For example, section 25.2.2 "Swap" describes the effect of
6638 swap_ranges in terms of the unqualified name "swap". This section
6639 could reasonably be interpreted to mean that the library must be implemented so
6640 as to do a lookup of the unqualified name "swap", allowing users to
6641 override any ::std::swap function when Koenig lookup applies.</p>
6642
6643 <p>Although it would have been best to use explicit qualification with
6644 "::std::" throughout, too many lines in the standard would have to be
6645 adjusted to make that change in a Technical Corrigendum.</p>
6646
6647 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, which addresses qualification of
6648 <tt>size_t</tt>, is a special case of this.
6649 </p>
6650 <p><b>Proposed resolution:</b></p>
6651 <p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p>
6652 <blockquote>
6653   <p>Whenever a name x defined in the standard library is mentioned, the name x
6654   is assumed to be fully qualified as ::std::x, unless explicitly described
6655   otherwise. For example, if the Effects section for library function F is
6656   described as calling library function G, the function ::std::G is meant.</p>
6657 </blockquote>
6658
6659 <p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
6660 the LWG to solve a problem in the standard itself similar to the
6661 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
6662 coordinated with the resolution of this issue.]</i></p>
6663
6664 <p><i>[post-Toronto: Howard is undecided about whether it is
6665 appropriate for all standard library function names referred to in
6666 other standard library functions to be explicitly qualified by
6667 <tt>std</tt>: it is common advice that users should define global
6668 functions that operate on their class in the same namespace as the
6669 class, and this requires argument-dependent lookup if those functions
6670 are intended to be called by library code.  Several LWG members are
6671 concerned that valarray appears to require argument-dependent lookup,
6672 but that the wording may not be clear enough to fall under
6673 "unless explicitly described otherwise".]</i></p>
6674
6675 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
6676 225, 226, and 229.  Their conclusion was that the issues should be
6677 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6678 EWG portion (Dave will write a proposal). The LWG and EWG had
6679 (separate) discussions of this plan the next day.  This paper resolves
6680 issues 225 and 226.  In light of that resolution, the proposed
6681 resolution for the current issue makes sense.]</i></p>
6682
6683 <hr>
6684 <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>
6685 <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
6686 Assignable was specified without also specifying
6687 CopyConstructible. The LWG asked that the standard be searched to
6688 determine if the same defect existed elsewhere.</p>
6689
6690 <p>There are a number of places (see proposed resolution below) where
6691 Assignable is specified without also specifying
6692 CopyConstructible. There are also several cases where both are
6693 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>
6694 <p><b>Proposed resolution:</b></p>
6695 <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:
6696 change "T is Assignable" to "T is CopyConstructible and
6697 Assignable"
6698 </p>
6699
6700 <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
6701 "Key is Assignable" to "Key is
6702 CopyConstructible and Assignable"<br>
6703 </p>
6704
6705 <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:
6706 </p>
6707 <blockquote>
6708 <p> A class or a built-in type X satisfies the requirements of an
6709 output iterator if X is an Assignable type (23.1) and also the
6710 following expressions are valid, as shown in Table 73:
6711 </p>
6712 </blockquote>
6713 <p>to:
6714 </p>
6715 <blockquote>
6716 <p> A class or a built-in type X satisfies the requirements of an
6717 output iterator if X is a CopyConstructible (20.1.3) and Assignable
6718 type (23.1) and also the following expressions are valid, as shown in
6719 Table 73:
6720 </p>
6721 </blockquote>
6722
6723 <p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
6724 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
6725 CopyConstructible is really a requirement and may be
6726 overspecification.]</i></p>
6727
6728 <p><i>[Portions of the resolution for issue 230 have been superceded by
6729 the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.]</i></p>
6730
6731 <p><b>Rationale:</b></p>
6732 <p>The original proposed resolution also included changes to input
6733 iterator, fill, and replace.  The LWG believes that those changes are
6734 not necessary.  The LWG considered some blanket statement, where an
6735 Assignable type was also required to be Copy Constructible, but
6736 decided against this because fill and replace really don't require the
6737 Copy Constructible property.</p>
6738 <hr>
6739 <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>
6740 <p>What is the following program supposed to output?</p>
6741 <pre>#include &lt;iostream&gt;
6742
6743     int
6744     main()
6745     {
6746         std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
6747         std::cout.precision( 0 ) ;
6748         std::cout &lt;&lt; 1.00 &lt;&lt; '\n' ;
6749         return 0 ;
6750     }</pre>
6751 <p>From my C experience, I would expect "1e+00"; this is what
6752 <tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs
6753 "1.000000e+00".</p>
6754
6755 <p>The only indication I can find in the standard is 22.2.2.2.2/11,
6756 where it says "For conversion from a floating-point type, if
6757 (flags &amp; fixed) != 0 or if str.precision() &gt; 0, then
6758 str.precision() is specified in the conversion specification."
6759 This is an obvious error, however, fixed is not a mask for a field,
6760 but a value that a multi-bit field may take -- the results of and'ing
6761 fmtflags with ios::fixed are not defined, at least not if
6762 ios::scientific has been set. G++'s behavior corresponds to what might
6763 happen if you do use (flags &amp; fixed) != 0 with a typical
6764 implementation (floatfield == 3 &lt;&lt; something, fixed == 1
6765 &lt;&lt; something, and scientific == 2 &lt;&lt; something).</p>
6766
6767 <p>Presumably, the intent is either (flags &amp; floatfield) != 0, or
6768 (flags &amp; floatfield) == fixed; the first gives something more or
6769 less like the effect of precision in a printf floating point
6770 conversion. Only more or less, of course. In order to implement printf
6771 formatting correctly, you must know whether the precision was
6772 explicitly set or not. Say by initializing it to -1, instead of 6, and
6773 stating that for floating point conversions, if precision &lt; -1, 6
6774 will be used, for fixed point, if precision &lt; -1, 1 will be used,
6775 etc. Plus, of course, if precision == 0 and flags &amp; floatfield ==
6776 0, 1 should be = used. But it probably isn't necessary to emulate all
6777 of the anomalies of printf:-).</p>
6778 <p><b>Proposed resolution:</b></p>
6779 <p>
6780 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
6781 sentence:
6782 </p>
6783 <blockquote>
6784 For conversion from a floating-point type,
6785 <tt><i>str</i>.precision()</tt> is specified in the conversion
6786 specification.
6787 </blockquote>
6788 <p><b>Rationale:</b></p>
6789 <p>The floatfield determines whether numbers are formatted as if
6790 with %f, %e, or %g.  If the <tt>fixed</tt> bit is set, it's %f,
6791 if <tt>scientific</tt> it's %e, and if both bits are set, or
6792 neither, it's %g.</p>
6793 <p>Turning to the C standard, a precision of 0 is meaningful
6794 for %f and %e.  For %g, precision 0 is taken to be the same as
6795 precision 1.</p>
6796 <p>The proposed resolution has the effect that if neither
6797 <tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
6798 specifying a precision of 0, which will be internally
6799 turned into 1.  There's no need to call it out as a special
6800 case.</p>
6801 <p>The output of the above program will be "1e+00".</p>
6802
6803 <p><i>[Post-Curaçao: Howard provided improved wording covering the case
6804 where precision is 0 and mode is %g.]</i></p>
6805
6806 <hr>
6807 <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>
6808 <p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
6809 specializations of standard templates to those that "depend on a
6810 user-defined name of external linkage."</p>
6811 <p>This term, however, is not adequately defined, making it possible to
6812 construct a specialization that is, I believe, technically legal according to
6813 17.4.3.1/1, but that specializes a standard template for a built-in type such as
6814 'int'.</p>
6815 <p>The following code demonstrates the problem:</p>
6816 <blockquote>
6817   <pre>#include &lt;algorithm&gt;</pre>
6818   <pre>template&lt;class T&gt; struct X
6819 {
6820  typedef T type;
6821 };</pre>
6822   <pre>namespace std
6823 {
6824  template&lt;&gt; void swap(::X&lt;int&gt;::type&amp; i, ::X&lt;int&gt;::type&amp; j);
6825 }</pre>
6826 </blockquote>
6827 <p><b>Proposed resolution:</b></p>
6828 <p>Change "user-defined name" to "user-defined
6829 type".</p>
6830 <p><b>Rationale:</b></p>
6831 <p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
6832 Programming Language</i>.  It disallows the example in the issue,
6833 since the underlying type itself is not user-defined.  The only
6834 possible problem I can see is for non-type templates, but there's no
6835 possible way for a user to come up with a specialization for bitset,
6836 for example, that might not have already been specialized by the
6837 implementor?</p>
6838
6839 <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>
6840
6841 <p><i>[post-Toronto: Judy provided the above proposed resolution and
6842 rationale.]</i></p>
6843 <hr>
6844 <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>
6845 <p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
6846 <tt>destruct()</tt> are described as returns but the functions actually
6847 return <tt>void</tt>.</p>
6848 <p><b>Proposed resolution:</b></p>
6849 <p>Substitute "Returns" by "Effect".</p>
6850 <hr>
6851 <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>
6852 <p>The declaration of <tt>reverse_iterator</tt> lists a default
6853 constructor.  However, no specification is given what this constructor
6854 should do.</p>
6855 <p><b>Proposed resolution:</b></p>
6856   <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
6857   paragraph:</p>
6858       <blockquote>
6859       <p><tt>reverse_iterator()</tt></p>
6860
6861       <p>Default initializes <tt>current</tt>. Iterator operations
6862       applied to the resulting iterator have defined behavior if and
6863       only if the corresponding operations are defined on a default
6864       constructed iterator of type <tt>Iterator</tt>.</p>
6865       </blockquote>
6866   <p><i>[pre-Copenhagen: Dietmar provide wording for proposed
6867   resolution.]</i></p>
6868 <hr>
6869 <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>
6870 <p>The complexity specification in paragraph 6 says that the complexity
6871 is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
6872 defined on iterators this term is in general undefined because it
6873 would have to be <tt>last - first</tt>.</p>
6874 <p><b>Proposed resolution:</b></p>
6875   <p>Change paragraph 6 from</p>
6876      <blockquote>Linear in <i>first - last</i>.</blockquote>
6877   <p>to become</p>
6878      <blockquote>Linear in <i>distance(first, last)</i>.</blockquote>
6879 <hr>
6880 <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>
6881 <p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
6882 'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
6883 that far but consider this code:</p>
6884
6885 <pre>  std::basic_stringbuf&lt;char&gt; sbuf("hello, world", std::ios_base::openmode(0));
6886   std::cout &lt;&lt; "'" &lt;&lt; sbuf.str() &lt;&lt; "'\n";
6887 </pre>
6888
6889 <p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
6890 the output sequence nor the input sequence is initialized and
6891 paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
6892 returns the input or the output sequence. None of them is initialized,
6893 ie. both are empty, in which case the return from <tt>str()</tt> is
6894 defined to be <tt>basic_string&lt;cT&gt;()</tt>.</p>
6895
6896 <p>However, probably only test cases in some testsuites will detect this
6897 "problem"...</p>
6898 <p><b>Proposed resolution:</b></p>
6899 <p>Remove 27.7.1.1 paragraph 4.</p>
6900 <p><b>Rationale:</b></p>
6901 <p>We could fix 27.7.1.1 paragraph 4, but there would be no point.  If
6902 we fixed it, it would say just the same thing as text that's already
6903 in the standard.</p>
6904 <hr>
6905 <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>
6906 <p>The complexity of unique and unique_copy are inconsistent with each
6907 other and inconsistent with the implementations.&nbsp; The standard
6908 specifies:</p>
6909
6910 <p>for unique():</p>
6911
6912 <blockquote>-3- Complexity: If the range (last - first) is not empty, exactly
6913 (last - first) - 1 applications of the corresponding predicate, otherwise
6914 no applications of the predicate.</blockquote>
6915
6916 <p>for unique_copy():</p>
6917
6918 <blockquote>-7- Complexity: Exactly last - first applications of the corresponding
6919 predicate.</blockquote>
6920
6921 <p>
6922 The implementations do it the other way round: unique() applies the
6923 predicate last-first times and unique_copy() applies it last-first-1
6924 times.</p>
6925
6926 <p>As both algorithms use the predicate for pair-wise comparison of
6927 sequence elements I don't see a justification for unique_copy()
6928 applying the predicate last-first times, especially since it is not
6929 specified to which pair in the sequence the predicate is applied
6930 twice.</p>
6931 <p><b>Proposed resolution:</b></p>
6932 <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>
6933
6934 <blockquote>Complexity: For nonempty ranges, exactly last - first - 1
6935 applications of the corresponding predicate.</blockquote>
6936
6937 <hr>
6938 <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>
6939 <p>The complexity section of adjacent_find is defective:</p>
6940
6941 <blockquote>
6942 <pre>template &lt;class ForwardIterator&gt;
6943 ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
6944                               BinaryPredicate pred);
6945 </pre>
6946
6947 <p>-1- Returns: The first iterator i such that both i and i + 1 are in
6948 the range [first, last) for which the following corresponding
6949 conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
6950 last if no such iterator is found.</p>
6951
6952 <p>-2- Complexity: Exactly find(first, last, value) - first applications
6953 of the corresponding predicate.
6954 </p>
6955 </blockquote>
6956
6957 <p>In the Complexity section, it is not defined what "value"
6958 is supposed to mean. My best guess is that "value" means an
6959 object for which one of the conditions pred(*i,value) or
6960 pred(value,*i) is true, where i is the iterator defined in the Returns
6961 section. However, the value type of the input sequence need not be
6962 equality-comparable and for this reason the term find(first, last,
6963 value) - first is meaningless.</p>
6964
6965 <p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
6966 find_if(first, last, bind1st(pred,*i)) - first might come closer to
6967 the intended specification.  Binders can only be applied to function
6968 objects that have the function call operator declared const, which is
6969 not required of predicates because they can have non-const data
6970 members. For this reason, a specification using a binder could only be
6971 an "as-if" specification.</p>
6972 <p><b>Proposed resolution:</b></p>
6973 <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>
6974 <blockquote>
6975 For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
6976 (<i>last</i> - <i>first</i>) - 1)</tt> applications of the
6977 corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
6978 return value.
6979 </blockquote>
6980
6981 <p><i>[Copenhagen: the original resolution specified an upper
6982 bound.  The LWG preferred an exact count.]</i></p>
6983
6984 <hr>
6985 <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>
6986
6987 <p>Some popular implementations of unique_copy() create temporary
6988 copies of values in the input sequence, at least if the input iterator
6989 is a pointer.  Such an implementation is built on the assumption that
6990 the value type is CopyConstructible and Assignable.</p>
6991
6992 <p>It is common practice in the standard that algorithms explicitly
6993 specify any additional requirements that they impose on any of the
6994 types used by the algorithm. An example of an algorithm that creates
6995 temporary copies and correctly specifies the additional requirements
6996 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>
6997
6998 <p>Since the specifications of unique() and unique_copy() do not
6999 require CopyConstructible and Assignable of the InputIterator's value
7000 type the above mentioned implementations are not standard-compliant. I
7001 cannot judge whether this is a defect in the standard or a defect in
7002 the implementations.</p>
7003 <p><b>Proposed resolution:</b></p>
7004 <p>In 25.2.8 change:</p>
7005
7006 <blockquote>
7007 -4- Requires: The ranges [first, last) and [result, result+(last-first))
7008 shall not overlap.
7009 </blockquote>
7010
7011 <p>to:</p>
7012
7013 <blockquote>
7014   <p>-4- Requires: The ranges [first, last) and [result,
7015   result+(last-first)) shall not overlap. The expression *result =
7016   *first must be valid. If neither InputIterator nor OutputIterator
7017   meets the requirements of forward iterator then the value type of
7018   InputIterator must be copy constructible. Otherwise copy
7019   constructible is not required. </p>
7020 </blockquote>
7021
7022 <p><i>[Redmond: the original proposed resolution didn't impose an
7023 explicit requirement that the iterator's value type must be copy
7024 constructible, on the grounds that an input iterator's value type must
7025 always be copy constructible.  Not everyone in the LWG thought that
7026 this requirement was clear from table 72.  It has been suggested that
7027 it might be possible to implement <tt>unique_copy</tt> without
7028 requiring assignability, although current implementations do impose
7029 that requirement.  Howard provided new wording.]</i></p>
7030
7031 <p><i>[
7032 Curaçao: The LWG changed the PR editorially to specify
7033 "neither...nor...meet..." as clearer than
7034 "both...and...do not meet...". Change believed to be so
7035 minor as not to require re-review.
7036 ]</i></p>
7037
7038 <hr>
7039 <a name="242"></a><h3><a name="242">242.&nbsp;Side effects of function objects</a></h3><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>
7040 <p>The algorithms transform(), accumulate(), inner_product(),
7041 partial_sum(), and adjacent_difference() require that the function
7042 object supplied to them shall not have any side effects.</p>
7043
7044 <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>
7045 <blockquote>-7- Accessing an object designated by a volatile lvalue (basic.lval),
7046 modifying an object, calling a library I/O function, or calling a function
7047 that does any of those operations are all side effects, which are changes
7048 in the state of the execution environment.</blockquote>
7049
7050 <p>As a consequence, the function call operator of a function object supplied
7051 to any of the algorithms listed above cannot modify data members, cannot
7052 invoke any function that has a side effect, and cannot even create and
7053 modify temporary objects.&nbsp; It is difficult to imagine a function object
7054 that is still useful under these severe limitations. For instance, any
7055 non-trivial transformator supplied to transform() might involve creation
7056 and modification of temporaries, which is prohibited according to the current
7057 wording of the standard.</p>
7058
7059 <p>On the other hand, popular implementations of these algorithms exhibit
7060 uniform and predictable behavior when invoked with a side-effect-producing
7061 function objects. It looks like the strong requirement is not needed for
7062 efficient implementation of these algorithms.</p>
7063
7064 <p>The requirement of&nbsp; side-effect-free function objects could be
7065 replaced by a more relaxed basic requirement (which would hold for all
7066 function objects supplied to any algorithm in the standard library):</p>
7067 <blockquote>A function objects supplied to an algorithm shall not invalidate
7068 any iterator or sequence that is used by the algorithm. Invalidation of
7069 the sequence includes destruction of the sorting order if the algorithm
7070 relies on the sorting order (see section 25.3 - Sorting and related operations
7071 [lib.alg.sorting]).</blockquote>
7072
7073 <p>I can't judge whether it is intended that the function objects supplied
7074 to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
7075 shall not modify sequence elements through dereferenced iterators.</p>
7076
7077 <p>It is debatable whether this issue is a defect or a change request.
7078 Since the consequences for user-supplied function objects are drastic and
7079 limit the usefulness of the algorithms significantly I would consider it
7080 a defect.</p>
7081 <p><b>Proposed resolution:</b></p>
7082
7083 <p><i>Things to notice about these changes:</i></p>
7084
7085 <ol>
7086 <li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
7087      are intentional. we want to prevent side-effects from
7088      invalidating the end iterators.</i>
7089 </li>
7090
7091 <li> <i>That has the unintentional side-effect of prohibiting
7092      modification of the end element as a side-effect. This could
7093      conceivably be significant in some cases.</i>
7094 </li>
7095
7096 <li> <i>The wording also prevents side-effects from modifying elements
7097      of the output sequence. I can't imagine why anyone would want
7098      to do this, but it is arguably a restriction that implementors
7099      don't need to place on users.</i>
7100 </li>
7101
7102 <li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
7103      and simple, but would require more verbiage.</i>
7104 </li>
7105 </ol>
7106
7107 <p>Change 25.2.3/2 from:</p>
7108
7109 <blockquote>
7110    -2- Requires: op and binary_op shall not have any side effects.
7111 </blockquote>
7112
7113 <p>to:</p>
7114
7115 <blockquote>
7116   -2- Requires: in the ranges [first1, last1], [first2, first2 +
7117   (last1 - first1)] and [result, result + (last1- first1)], op and
7118   binary_op shall neither modify elements nor invalidate iterators or
7119   subranges.
7120   [Footnote: The use of fully closed ranges is intentional --end footnote]
7121 </blockquote>
7122
7123
7124 <p>Change 25.2.3/2 from:</p>
7125
7126 <blockquote>
7127    -2- Requires: op and binary_op shall not have any side effects.
7128 </blockquote>
7129
7130 <p>to:</p>
7131
7132 <blockquote>
7133   -2- Requires: op and binary_op shall not invalidate iterators or
7134    subranges, or modify elements in the ranges [first1, last1],
7135    [first2, first2 + (last1 - first1)], and [result, result + (last1
7136    - first1)].
7137   [Footnote: The use of fully closed ranges is intentional --end footnote]
7138 </blockquote>
7139
7140
7141 <p>Change 26.4.1/2 from:</p>
7142
7143 <blockquote>
7144   -2- Requires: T must meet the requirements of CopyConstructible
7145    (lib.copyconstructible) and Assignable (lib.container.requirements)
7146    types. binary_op shall not cause side effects.
7147 </blockquote>
7148
7149 <p>to:</p>
7150
7151 <blockquote>
7152   -2- Requires: T must meet the requirements of CopyConstructible
7153    (lib.copyconstructible) and Assignable
7154    (lib.container.requirements) types. In the range [first, last],
7155    binary_op shall neither modify elements nor invalidate iterators
7156    or subranges.
7157   [Footnote: The use of a fully closed range is intentional --end footnote]
7158 </blockquote>
7159
7160 <p>Change 26.4.2/2 from:</p>
7161
7162 <blockquote>
7163   -2- Requires: T must meet the requirements of CopyConstructible
7164    (lib.copyconstructible) and Assignable (lib.container.requirements)
7165    types. binary_op1 and binary_op2 shall not cause side effects.
7166 </blockquote>
7167
7168 <p>to:</p>
7169
7170 <blockquote>
7171   -2- Requires: T must meet the requirements of CopyConstructible
7172    (lib.copyconstructible) and Assignable (lib.container.requirements)
7173    types. In the ranges [first, last] and [first2, first2 + (last -
7174    first)], binary_op1 and binary_op2 shall neither modify elements
7175    nor invalidate iterators or subranges.
7176   [Footnote: The use of fully closed ranges is intentional --end footnote]
7177 </blockquote>
7178
7179
7180 <p>Change 26.4.3/4 from:</p>
7181
7182 <blockquote>
7183   -4- Requires: binary_op is expected not to have any side effects.
7184 </blockquote>
7185
7186 <p>to:</p>
7187
7188 <blockquote>
7189   -4- Requires: In the ranges [first, last] and [result, result +
7190    (last - first)], binary_op shall neither modify elements nor
7191    invalidate iterators or subranges.
7192   [Footnote: The use of fully closed ranges is intentional --end footnote]
7193 </blockquote>
7194
7195 <p>Change 26.4.4/2 from:</p>
7196
7197 <blockquote>
7198   -2- Requires: binary_op shall not have any side effects.
7199 </blockquote>
7200
7201 <p>to:</p>
7202
7203 <blockquote>
7204   -2- Requires: In the ranges [first, last] and [result, result +
7205    (last - first)], binary_op shall neither modify elements nor
7206    invalidate iterators or subranges.
7207   [Footnote: The use of fully closed ranges is intentional --end footnote]
7208 </blockquote>
7209
7210 <p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
7211
7212 <p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
7213 added footnotes pointing out that the use of closed ranges was
7214 intentional.]</i></p>
7215
7216 <hr>
7217 <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>
7218 <p>basic_istream&lt;&gt;::get(), and basic_istream&lt;&gt;::getline(),
7219 are unclear with respect to the behavior and side-effects of the named
7220 functions in case of an error.</p>
7221
7222 <p>27.6.1.3, p1 states that "... If the sentry object returns
7223 true, when converted to a value of type bool, the function endeavors
7224 to obtain the requested input..." It is not clear from this (or
7225 the rest of the paragraph) what precisely the behavior should be when
7226 the sentry ctor exits by throwing an exception or when the sentry
7227 object returns false.  In particular, what is the number of characters
7228 extracted that gcount() returns supposed to be?</p>
7229
7230 <p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
7231 "...  In any case, it then stores a null character (using
7232 charT()) into the next successive location of the array." Is not
7233 clear whether this sentence applies if either of the conditions above
7234 holds (i.e., when sentry fails).</p>
7235 <p><b>Proposed resolution:</b></p>
7236 <p>Add to 27.6.1.3, p1 after the sentence</p>
7237
7238 <blockquote>
7239 "... If the sentry object returns true, when converted to a value of
7240 type bool, the function endeavors to obtain the requested input."
7241 </blockquote>
7242
7243 <p>the following</p>
7244
7245
7246 <blockquote>
7247 "Otherwise, if the sentry constructor exits by throwing an exception or
7248 if the sentry object returns false, when converted to a value of type
7249 bool, the function returns without attempting to obtain any input. In
7250 either case the number of extracted characters is set to 0; unformatted
7251 input functions taking a character array of non-zero size as an argument
7252 shall also store a null character (using charT()) in the first location
7253 of the array."
7254 </blockquote>
7255 <p><b>Rationale:</b></p>
7256 <p>Although the general philosophy of the input functions is that the
7257 argument should not be modified upon failure, <tt>getline</tt>
7258 historically added a terminating null unconditionally.  Most
7259 implementations still do that.  Earlier versions of the draft standard
7260 had language that made this an unambiguous requirement; those words
7261 were moved to a place where their context made them less clear.  See
7262 Jerry Schwarz's message c++std-lib-7618.</p>
7263 <hr>
7264 <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>
7265 <p>There is no requirement that any of time_get member functions set
7266 ios::eofbit when they reach the end iterator while parsing their input.
7267 Since members of both the num_get and money_get facets are required to
7268 do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
7269 should follow the same requirement for consistency.</p>
7270 <p><b>Proposed resolution:</b></p>
7271 <p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
7272
7273 <blockquote>
7274 If the end iterator is reached during parsing by any of the get()
7275 member functions, the member sets ios_base::eofbit in err.
7276 </blockquote>
7277 <p><b>Rationale:</b></p>
7278 <p>Two alternative resolutions were proposed.  The LWG chose this one
7279 because it was more consistent with the way eof is described for other
7280 input facets.</p>
7281 <hr>
7282 <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>
7283 <p>
7284 Section 23.2.2.4 [lib.list.ops] states that
7285 </p>
7286 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
7287 </pre>
7288 <p>
7289 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
7290 </p>
7291
7292 <p>
7293 This is unnecessary and defeats an important feature of splice. In
7294 fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
7295 after <tt>splice</tt>.
7296 </p>
7297 <p><b>Proposed resolution:</b></p>
7298
7299 <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>
7300 <blockquote>
7301 [<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
7302 4-5, the semantics described in this clause applies only to the case
7303 where allocators compare equal.  --end footnote]
7304 </blockquote>
7305
7306 <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>
7307 <blockquote>
7308 Effects: Inserts the contents of x before position and x becomes
7309 empty.  Pointers and references to the moved elements of x now refer to
7310 those same elements but as members of *this.  Iterators referring to the
7311 moved elements will continue to refer to their elements, but they now
7312 behave as iterators into *this, not into x.
7313 </blockquote>
7314
7315 <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>
7316 <blockquote>
7317 Effects: Inserts an element pointed to by i from list x before
7318 position and removes the element from x. The result is unchanged if
7319 position == i or position == ++i.  Pointers and references to *i continue
7320 to refer to this same element but as a member of *this.  Iterators to *i
7321 (including i itself) continue to refer to the same element, but now
7322 behave as iterators into *this, not into x.
7323 </blockquote>
7324
7325 <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>
7326 <blockquote>
7327 Requires: [first, last) is a valid range in x. The result is
7328 undefined if position is an iterator in the range [first, last).
7329 Pointers and references to the moved elements of x now refer to those
7330 same elements but as members of *this.  Iterators referring to the moved
7331 elements will continue to refer to their elements, but they now behave as
7332 iterators into *this, not into x.
7333 </blockquote>
7334
7335 <p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
7336 <p><b>Rationale:</b></p>
7337 <p>The original proposed resolution said that iterators and references
7338 would remain "valid".  The new proposed resolution clarifies what that
7339 means.  Note that this only applies to the case of equal allocators.
7340 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
7341 allocators compare nonequal is outside the scope of the standard.</p>
7342 <hr>
7343 <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>
7344 <p>The synopsis for the template class <tt>basic_stringbuf</tt>
7345 doesn't list a typedef for the template parameter
7346 <tt>Allocator</tt>. This makes it impossible to determine the type of
7347 the allocator at compile time. It's also inconsistent with all other
7348 template classes in the library that do provide a typedef for the
7349 <tt>Allocator</tt> parameter.</p>
7350 <p><b>Proposed resolution:</b></p>
7351 <p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
7352 basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and
7353 basic_stringstream (27.7.4) the typedef:</p>
7354 <pre>  typedef Allocator allocator_type;
7355 </pre>
7356 <hr>
7357 <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>
7358 <p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
7359 const_cast&lt;&gt; in the Returns clause for basic_istringstream&lt;&gt;::rdbuf().
7360 The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
7361 D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
7362 the cast altogether.</p>
7363
7364 <p>C-style casts have not been deprecated, so the first part of this
7365 issue is stylistic rather than a matter of correctness.</p>
7366 <p><b>Proposed resolution:</b></p>
7367 <p>In 27.7.2.2, p1 replace </p>
7368 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
7369
7370 <p>with</p>
7371 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
7372
7373
7374 <p>In 27.7.3.2, p1 replace</p>
7375 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
7376
7377 <p>with</p>
7378 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
7379
7380 <p>In 27.7.6, p1, replace</p>
7381 <pre>  -1- Returns: &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 D.7.2.2, p1 replace</p>
7387 <pre>  -2- Returns: &amp;sb. </pre>
7388
7389 <p>with</p>
7390 <pre>  -2- Returns: const_cast&lt;strstreambuf*&gt;(&amp;sb).</pre>
7391 <hr>
7392 <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>
7393 <p>This discussion is adapted from message c++std-lib-7056 posted
7394 November 11, 1999.  I don't think that anyone can reasonably claim
7395 that the problem described below is NAD.</p>
7396
7397 <p>These valarray constructors can never be called:</p>
7398
7399 <pre>   template &lt;class T&gt;
7400          valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
7401    template &lt;class T&gt;
7402          valarray&lt;T&gt;::valarray(const gslice_array&lt;T&gt; &amp;);
7403    template &lt;class T&gt;
7404          valarray&lt;T&gt;::valarray(const mask_array&lt;T&gt; &amp;);
7405    template &lt;class T&gt;
7406          valarray&lt;T&gt;::valarray(const indirect_array&lt;T&gt; &amp;);
7407 </pre>
7408
7409 <p>Similarly, these valarray assignment operators cannot be
7410 called:</p>
7411
7412 <pre>     template &lt;class T&gt;
7413      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const slice_array&lt;T&gt; &amp;);
7414      template &lt;class T&gt;
7415      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const gslice_array&lt;T&gt; &amp;);
7416      template &lt;class T&gt;
7417      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const mask_array&lt;T&gt; &amp;);
7418      template &lt;class T&gt;
7419      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const indirect_array&lt;T&gt; &amp;);
7420 </pre>
7421
7422 <p>Please consider the following example:</p>
7423
7424 <pre>   #include &lt;valarray&gt;
7425    using namespace std;
7426
7427    int main()
7428    {
7429        valarray&lt;double&gt; va1(12);
7430        valarray&lt;double&gt; va2(va1[slice(1,4,3)]); // line 1
7431    }
7432 </pre>
7433
7434
7435 <p>Since the valarray va1 is non-const, the result of the sub-expression
7436 va1[slice(1,4,3)] at line 1 is an rvalue of type const
7437 std::slice_array&lt;double&gt;.  This slice_array rvalue is then used to
7438 construct va2.  The constructor that is used to construct va2 is
7439 declared like this:</p>
7440
7441 <pre>     template &lt;class T&gt;
7442      valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
7443 </pre>
7444
7445 <p>Notice the constructor's const reference parameter.  When the
7446 constructor is called, a slice_array must be bound to this reference.
7447 The rules for binding an rvalue to a const reference are in 8.5.3,
7448 paragraph 5 (see also 13.3.3.1.4).  Specifically, paragraph 5
7449 indicates that a second slice_array rvalue is constructed (in this
7450 case copy-constructed) from the first one; it is this second rvalue
7451 that is bound to the reference parameter.  Paragraph 5 also requires
7452 that the constructor that is used for this purpose be callable,
7453 regardless of whether the second rvalue is elided.  The
7454 copy-constructor in this case is not callable, however, because it is
7455 private.  Therefore, the compiler should report an error.</p>
7456
7457 <p>Since slice_arrays are always rvalues, the valarray constructor that has a
7458 parameter of type const slice_array&lt;T&gt; &amp; can never be called.  The
7459 same reasoning applies to the three other constructors and the four
7460 assignment operators that are listed at the beginning of this post.
7461 Furthermore, since these functions cannot be called, the valarray helper
7462 classes are almost entirely useless.</p>
7463 <p><b>Proposed resolution:</b></p>
7464 <p>slice_array:</p>
7465 <ul>
7466 <li> Make the copy constructor and copy-assignment operator declarations
7467      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>
7468 <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>
7469 </li>
7470 <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>
7471 </li>
7472 <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
7473     to be private.  This constructor need not be defined."</li>
7474 <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>
7475 </li>
7476 <li> Change the first three words of the second sentence of paragraph 1 of
7477     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>
7478 </ul>
7479
7480 <p>gslice_array:</p>
7481 <ul>
7482 <li> Make the copy constructor and copy-assignment operator declarations
7483     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>
7484 <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>
7485 </li>
7486 <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>
7487 </li>
7488 <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
7489     to be private.  This constructor need not be defined."</li>
7490 <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>
7491 </li>
7492 <li> Change the first three words of the second sentence of paragraph 1 of
7493     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>
7494 </ul>
7495
7496 <p>mask_array:</p>
7497 <ul>
7498 <li> Make the copy constructor and copy-assignment operator declarations
7499     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>
7500 <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>
7501 </li>
7502 <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>
7503 </li>
7504 <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
7505     to be private.  This constructor need not be defined."</li>
7506 <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>
7507 </li>
7508 <li> Change the first three words of the second sentence of paragraph 1 of
7509     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>
7510 </ul>
7511
7512 <p>indirect_array:</p>
7513 <ul>
7514 <li>Make the copy constructor and copy-assignment operator declarations
7515     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>
7516 </li>
7517 <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>
7518 </li>
7519 <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>
7520 </li>
7521 <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
7522     declared to be private.  This constructor need not be defined."</li>
7523 <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>
7524 </li>
7525 <li> Change the first three words of the second sentence of paragraph 1 of
7526     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>
7527 </ul>
7528 <p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
7529 copy constructor and copy assignment operators public, instead of
7530 removing them.]</i></p>
7531 <p><b>Rationale:</b></p>
7532 <p>Keeping the valarray constructors private is untenable.  Merely
7533 making valarray a friend of the helper classes isn't good enough,
7534 because access to the copy constructor is checked in the user's
7535 environment.</p>
7536
7537 <p>Making the assignment operator public is not strictly necessary to
7538 solve this problem.  A majority of the LWG <i>(straw poll: 13-4)</i>
7539 believed we should make the assignment operators public, in addition
7540 to the copy constructors, for reasons of symmetry and user
7541 expectation.</p>
7542 <hr>
7543 <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>
7544 <p>
7545 27.4.4.2, p17 says
7546 </p>
7547
7548 <blockquote>
7549 -17- Before copying any parts of rhs, calls each registered callback
7550 pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
7551 exceptions() have been replaced, calls each callback pair that was
7552 copied from rhs as (*fn)(copy_event,*this,index).
7553 </blockquote>
7554
7555 <p>
7556 The name copy_event isn't defined anywhere. The intended name was
7557 copyfmt_event.
7558 </p>
7559 <p><b>Proposed resolution:</b></p>
7560 <p>Replace copy_event with copyfmt_event in the named paragraph.</p>
7561 <hr>
7562 <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>
7563 <p>
7564 <i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
7565 </p>
7566
7567 <p>
7568 The standard's description of <tt>basic_string&lt;&gt;::operator[]</tt>
7569 seems to violate const correctness.
7570 </p>
7571
7572 <p>
7573 The standard (21.3.4/1) says that "If <tt>pos &lt; size()</tt>,
7574 returns <tt>data()[pos]</tt>." The types don't work.  The
7575 return value of <tt>data()</tt> is <tt>const charT*</tt>, but
7576 <tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
7577 </p>
7578 <p><b>Proposed resolution:</b></p>
7579 <p>
7580 In section 21.3.4, paragraph 1, change
7581 "<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
7582 <i>pos</i>)</tt>".
7583 </p>
7584 <hr>
7585 <a name="260"><h3>260.&nbsp;Inconsistent return type of <tt>istream_iterator::operator++(int)</tt>
7586 </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>
7587 <p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
7588 it as returning the iterator by value. 24.5.1.2, p5 shows the same
7589 operator as returning the iterator by reference. That's incorrect
7590 given the Effects clause below (since a temporary is returned). The
7591 `&amp;' is probably just a typo.</p>
7592 <p><b>Proposed resolution:</b></p>
7593 <p>Change the declaration in 24.5.1.2, p5 from</p>
7594  <pre> istream_iterator&lt;T,charT,traits,Distance&gt;&amp; operator++(int);
7595  </pre>
7596 <p>to</p>
7597  <pre> istream_iterator&lt;T,charT,traits,Distance&gt; operator++(int);
7598  </pre>
7599 <p>(that is, remove the `&amp;').</p>
7600 <hr>
7601 <a name="261"><h3>261.&nbsp;Missing description of <tt>istream_iterator::operator!=</tt>
7602 </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>
7603 <p>
7604 24.5.1, p3 lists the synopsis for
7605 </p>
7606
7607 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
7608         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
7609                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
7610 </pre>
7611
7612 <p>
7613 but there is no description of what the operator does (i.e., no Effects
7614 or Returns clause) in 24.5.1.2.
7615 </p>
7616 <p><b>Proposed resolution:</b></p>
7617 <p>
7618 Add paragraph 7 to the end of section 24.5.1.2 with the following text:
7619 </p>
7620
7621 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
7622         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
7623                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
7624 </pre>
7625
7626 <p>-7- Returns: !(x == y).</p>
7627 <hr>
7628 <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>
7629 <p>
7630 The ~ operation should be applied after the cast to int_type.
7631 </p>
7632 <p><b>Proposed resolution:</b></p>
7633 <p>
7634 Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
7635 </p>
7636
7637 <pre>   bitmask operator~ ( bitmask X )
7638      { return static_cast&lt; bitmask&gt;(static_cast&lt;int_type&gt;(~ X)); }
7639 </pre>
7640
7641 <p>
7642 to:
7643 </p>
7644
7645 <pre>   bitmask operator~ ( bitmask X )
7646      { return static_cast&lt; bitmask&gt;(~static_cast&lt;int_type&gt;(X)); }
7647 </pre>
7648 <hr>
7649 <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>
7650 <p>
7651 The note in paragraph 6 suggests that the invalidation rules for
7652 references, pointers, and iterators in paragraph 5 permit a reference-
7653 counted implementation (actually, according to paragraph 6, they permit
7654 a "reference counted implementation", but this is a minor editorial fix).
7655 </p>
7656
7657 <p>
7658 However, the last sub-bullet is so worded as to make a reference-counted
7659 implementation unviable. In the following example none of the
7660 conditions for iterator invalidation are satisfied:
7661 </p>
7662
7663 <pre>    // first example: "*******************" should be printed twice
7664     string original = "some arbitrary text", copy = original;
7665     const string &amp; alias = original;
7666
7667     string::const_iterator i = alias.begin(), e = alias.end();
7668     for(string::iterator j = original.begin(); j != original.end(); ++j)
7669         *j = '*';
7670     while(i != e)
7671         cout &lt;&lt; *i++;
7672     cout &lt;&lt; endl;
7673     cout &lt;&lt; original &lt;&lt; endl;
7674 </pre>
7675
7676 <p>
7677 Similarly, in the following example:
7678 </p>
7679
7680 <pre>    // second example: "some arbitrary text" should be printed out
7681     string original = "some arbitrary text", copy = original;
7682     const string &amp; alias = original;
7683
7684     string::const_iterator i = alias.begin();
7685     original.begin();
7686     while(i != alias.end())
7687         cout &lt;&lt; *i++;
7688 </pre>
7689
7690 <p>
7691 I have tested this on three string implementations, two of which were
7692 reference counted. The reference-counted implementations gave
7693 "surprising behavior" because they invalidated iterators on
7694 the first call to non-const begin since construction. The current
7695 wording does not permit such invalidation because it does not take
7696 into account the first call since construction, only the first call
7697 since various member and non-member function calls.
7698 </p>
7699 <p><b>Proposed resolution:</b></p>
7700 <p>
7701 Change the following sentence in 21.3 paragraph 5 from
7702 </p>
7703
7704 <blockquote>
7705     Subsequent to any of the above uses except the forms of insert() and
7706     erase() which return iterators, the first call to non-const member
7707     functions operator[](), at(), begin(), rbegin(), end(), or rend().
7708 </blockquote>
7709
7710 <p>to</p>
7711
7712 <blockquote>
7713     Following construction or any of the above uses, except the forms of
7714     insert() and erase() that return iterators, the first call to non-
7715     const member functions operator[](), at(), begin(), rbegin(), end(),
7716     or rend().
7717 </blockquote>
7718 <hr>
7719 <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>
7720 <p>
7721 Table 69 requires linear time if [i, j) is sorted.  Sorted is necessary but not sufficient.
7722 Consider inserting a sorted range of even integers into a set&lt;int&gt; containing the odd
7723 integers in the same range.
7724 </p>
7725
7726 <p><i>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></i></p>
7727 <p><b>Proposed resolution:</b></p>
7728 <p>
7729 In Table 69, in section 23.1.2, change the complexity clause for
7730 insertion of a range from "N log(size() + N) (N is the distance
7731 from i to j) in general; linear if [i, j) is sorted according to
7732 value_comp()" to "N log(size() + N), where N is the distance
7733 from i to j".
7734 </p>
7735
7736 <p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
7737 parens in the revised wording.]</i></p>
7738
7739 <p><b>Rationale:</b></p>
7740 <p>
7741 Testing for valid insertions could be less efficient than simply
7742 inserting the elements when the range is not both sorted and between
7743 two adjacent existing elements; this could be a QOI issue.
7744 </p>
7745
7746 <p>
7747 The LWG considered two other options: (a) specifying that the
7748 complexity was linear if [i, j) is sorted according to value_comp()
7749 and between two adjacent existing elements; or (b) changing to
7750 Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
7751 number of elements which do not insert immediately after the previous
7752 element from [i, j) including the first).  The LWG felt that, since
7753 we can't guarantee linear time complexity whenever the range to be
7754 inserted is sorted, it's more trouble than it's worth to say that it's
7755 linear in some special cases.
7756 </p>
7757 <hr>
7758 <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>
7759 <p>
7760 I don't see any requirements on the types of the elements of the
7761 std::pair container in 20.2.2. From the descriptions of the member
7762 functions it appears that they must at least satisfy the requirements of
7763 20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
7764 the case of the [in]equality operators also the requirements of 20.1.1
7765 [lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
7766 </p>
7767
7768 <p>
7769 I believe that the the CopyConstructible requirement is unnecessary in
7770 the case of 20.2.2, p2.
7771 </p>
7772 <p><b>Proposed resolution:</b></p>
7773 <p>Change the Effects clause in 20.2.2, p2 from</p>
7774
7775 <blockquote>
7776 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
7777 first(T1()), second(T2()) {} </tt>
7778 </blockquote>
7779
7780 <p>to</p>
7781
7782 <blockquote>
7783 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
7784 first(), second() {} </tt>
7785 </blockquote>
7786 <p><b>Rationale:</b></p>
7787 <p>The existing specification of pair's constructor appears to be a
7788 historical artifact: there was concern that pair's members be properly
7789 zero-initialized when they are built-in types.  At one time there was
7790 uncertainty about whether they would be zero-initialized if the
7791 default constructor was written the obvious way.  This has been
7792 clarified by core issue 178, and there is no longer any doubt that
7793 the straightforward implementation is correct.</p>
7794 <hr>
7795 <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>
7796 <p>
7797 The synopsis for std::bad_exception lists the function ~bad_exception()
7798 but there is no description of what the function does (the Effects
7799 clause is missing).
7800 </p>
7801 <p><b>Proposed resolution:</b></p>
7802 <p>
7803 Remove the destructor from the class synopses of
7804 <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>),
7805 <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>),
7806 <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>),
7807 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>).
7808 </p>
7809 <p><b>Rationale:</b></p>
7810 <p>
7811 This is a general problem with the exception classes in clause 18.
7812 The proposed resolution is to remove the destructors from the class
7813 synopses, rather than to document the destructors' behavior, because
7814 removing them is more consistent with how exception classes are
7815 described in clause 19.
7816 </p>
7817 <hr>
7818 <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>
7819 <p>The synopsis of the class std::locale in 22.1.1 contains two typos:
7820 the semicolons after the declarations of the default ctor
7821 locale::locale() and the copy ctor locale::locale(const locale&amp;)
7822 are missing.</p>
7823 <p><b>Proposed resolution:</b></p>
7824 <p>Add the missing semicolons, i.e., change</p>
7825
7826 <pre>    //  construct/copy/destroy:
7827         locale() throw()
7828         locale(const locale&amp; other) throw()
7829 </pre>
7830
7831 <p>in the synopsis in 22.1.1 to</p>
7832
7833 <pre>    //  construct/copy/destroy:
7834         locale() throw();
7835         locale(const locale&amp; other) throw();
7836 </pre>
7837 <hr>
7838 <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>
7839 <p>
7840 Each of the four binary search algorithms (lower_bound, upper_bound,
7841 equal_range, binary_search) has a form that allows the user to pass a
7842 comparison function object.  According to 25.3, paragraph 2, that
7843 comparison function object has to be a strict weak ordering.
7844 </p>
7845
7846 <p>
7847 This requirement is slightly too strict.  Suppose we are searching
7848 through a sequence containing objects of type X, where X is some
7849 large record with an integer key.  We might reasonably want to look
7850 up a record by key, in which case we would want to write something
7851 like this:
7852 </p>
7853 <pre>    struct key_comp {
7854       bool operator()(const X&amp; x, int n) const {
7855         return x.key() &lt; n;
7856       }
7857     }
7858
7859     std::lower_bound(first, last, 47, key_comp());
7860 </pre>
7861
7862 <p>
7863 key_comp is not a strict weak ordering, but there is no reason to
7864 prohibit its use in lower_bound.
7865 </p>
7866
7867 <p>
7868 There's no difficulty in implementing lower_bound so that it allows
7869 the use of something like key_comp.  (It will probably work unless an
7870 implementor takes special pains to forbid it.)  What's difficult is
7871 formulating language in the standard to specify what kind of
7872 comparison function is acceptable.  We need a notion that's slightly
7873 more general than that of a strict weak ordering, one that can encompass
7874 a comparison function that involves different types.  Expressing that
7875 notion may be complicated.
7876 </p>
7877
7878 <p><i>Additional questions raised at the Toronto meeting:</i></p>
7879 <ul>
7880 <li> Do we really want to specify what ordering the implementor must
7881      use when calling the function object?  The standard gives
7882      specific expressions when describing these algorithms, but it also
7883      says that other expressions (with different argument order) are
7884      equivalent.</li>
7885 <li> If we are specifying ordering, note that the standard uses both
7886      orderings when describing <tt>equal_range</tt>.</li>
7887 <li> Are we talking about requiring these algorithms to work properly
7888      when passed a binary function object whose two argument types
7889      are not the same, or are we talking about requirements when
7890      they are passed a binary function object with several overloaded
7891      versions of <tt>operator()</tt>?</li>
7892 <li> The definition of a strict weak ordering does not appear to give
7893      any guidance on issues of overloading; it only discusses expressions,
7894      and all of the values in these expressions are of the same type.
7895      Some clarification would seem to be in order.</li>
7896 </ul>
7897
7898 <p><i>Additional discussion from Copenhagen:</i></p>
7899 <ul>
7900 <li>It was generally agreed that there is a real defect here: if
7901 the predicate is merely required to be a Strict Weak Ordering, then
7902 it's possible to pass in a function object with an overloaded
7903 operator(), where the version that's actually called does something
7904 completely inappropriate.  (Such as returning a random value.)</li>
7905
7906 <li>An alternative formulation was presented in a paper distributed by
7907 David Abrahams at the meeting, "Binary Search with Heterogeneous
7908 Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
7909 predicate as a Strict Weak Ordering acting on a sorted sequence, view
7910 the predicate/value pair as something that partitions a sequence.
7911 This is almost equivalent to saying that we should view binary search
7912 as if we are given a unary predicate and a sequence, such that f(*p)
7913 is true for all p below a specific point and false for all p above it.
7914 The proposed resolution is based on that alternative formulation.</li>
7915 </ul>
7916 <p><b>Proposed resolution:</b></p>
7917
7918 <p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
7919
7920 <blockquote>
7921   3 For all algorithms that take Compare, there is a version that uses
7922   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i &lt;
7923   *j != false. For the algorithms to work correctly, comp has to
7924   induce a strict weak ordering on the values.
7925 </blockquote>
7926
7927 <p>to:</p>
7928
7929 <blockquote>
7930   3 For all algorithms that take Compare, there is a version that uses
7931   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i
7932   &lt; *j != false. For algorithms other than those described in
7933   lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
7934   a strict weak ordering on the values.
7935 </blockquote>
7936
7937 <p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
7938
7939 <blockquote>
7940   -6- A sequence [start, finish) is partitioned with respect to an
7941   expression f(e) if there exists an integer n such that
7942   for all 0 &lt;= i &lt; distance(start, finish), f(*(begin+i)) is true if
7943   and only if i &lt; n.
7944 </blockquote>
7945
7946 <p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
7947
7948 <blockquote>
7949   -1- All of the algorithms in this section are versions of binary
7950    search and assume that the sequence being searched is in order
7951    according to the implied or explicit comparison function. They work
7952    on non-random access iterators minimizing the number of
7953    comparisons, which will be logarithmic for all types of
7954    iterators. They are especially appropriate for random access
7955    iterators, because these algorithms do a logarithmic number of
7956    steps through the data structure. For non-random access iterators
7957    they execute a linear number of steps.
7958 </blockquote>
7959
7960 <p>to:</p>
7961
7962 <blockquote>
7963    -1- All of the algorithms in this section are versions of binary
7964     search and assume that the sequence being searched is partitioned
7965     with respect to an expression formed by binding the search key to
7966     an argument of the implied or explicit comparison function. They
7967     work on non-random access iterators minimizing the number of
7968     comparisons, which will be logarithmic for all types of
7969     iterators. They are especially appropriate for random access
7970     iterators, because these algorithms do a logarithmic number of
7971     steps through the data structure. For non-random access iterators
7972     they execute a linear number of steps.
7973 </blockquote>
7974
7975 <p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
7976
7977 <blockquote>
7978    -1- Requires: Type T is LessThanComparable
7979     (lib.lessthancomparable).
7980 </blockquote>
7981
7982 <p>to:</p>
7983
7984 <blockquote>
7985    -1- Requires: The elements e of [first, last) are partitioned with
7986    respect to the expression e &lt; value or comp(e, value)
7987 </blockquote>
7988
7989
7990 <p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
7991
7992 <blockquote>
7993    -2- Effects: Finds the first position into which value can be
7994     inserted without violating the ordering.
7995 </blockquote>
7996
7997 <p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
7998
7999 <blockquote>
8000   -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
8001 </blockquote>
8002
8003 <p>to:</p>
8004
8005 <blockquote>
8006    -1- Requires: The elements e of [first, last) are partitioned with
8007    respect to the expression !(value &lt; e) or !comp(value, e)
8008 </blockquote>
8009
8010 <p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
8011
8012 <blockquote>
8013    -2- Effects: Finds the furthermost position into which value can be
8014     inserted without violating the ordering.
8015 </blockquote>
8016
8017 <p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
8018
8019 <blockquote>
8020    -1- Requires: Type T is LessThanComparable
8021     (lib.lessthancomparable).
8022 </blockquote>
8023
8024 <p>to:</p>
8025
8026 <blockquote>
8027    -1- Requires: The elements e of [first, last) are partitioned with
8028    respect to the expressions e &lt; value and !(value &lt; e) or
8029    comp(e, value) and !comp(value, e).  Also, for all elements e of
8030    [first, last), e &lt; value implies !(value &lt; e) or comp(e,
8031    value) implies !comp(value, e)
8032 </blockquote>
8033
8034 <p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
8035
8036 <blockquote>
8037    -2- Effects: Finds the largest subrange [i, j) such that the value
8038     can be inserted at any iterator k in it without violating the
8039     ordering. k satisfies the corresponding conditions: !(*k &lt; value)
8040     &amp;&amp; !(value &lt; *k) or comp(*k, value) == false &amp;&amp; comp(value, *k) ==
8041     false.
8042 </blockquote>
8043
8044 <p>to:</p>
8045
8046 <pre>   -2- Returns:
8047          make_pair(lower_bound(first, last, value),
8048                    upper_bound(first, last, value))
8049        or
8050          make_pair(lower_bound(first, last, value, comp),
8051                    upper_bound(first, last, value, comp))
8052 </pre>
8053
8054 <p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
8055
8056 <blockquote>
8057    -1- Requires: Type T is LessThanComparable
8058     (lib.lessthancomparable).
8059 </blockquote>
8060
8061 <p>to:</p>
8062
8063 <blockquote>
8064    -1- Requires: The elements e of [first, last) are partitioned with
8065    respect to the expressions e &lt; value and !(value &lt; e) or comp(e,
8066    value) and !comp(value, e). Also, for all elements e of [first,
8067    last), e &lt; value implies !(value &lt; e) or comp(e, value) implies
8068    !comp(value, e)
8069 </blockquote>
8070
8071 <p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
8072
8073 <p><i>[Redmond: Minor changes in wording.  (Removed "non-negative", and
8074 changed the "other than those described in" wording.) Also, the LWG
8075 decided to accept the "optional" part.]</i></p>
8076
8077 <p><b>Rationale:</b></p>
8078 <p>The proposed resolution reinterprets binary search. Instead of
8079 thinking about searching for a value in a sorted range, we view that
8080 as an important special case of a more general algorithm: searching
8081 for the partition point in a partitioned range.</p>
8082
8083 <p>We also add a guarantee that the old wording did not: we ensure
8084 that the upper bound is no earlier than the lower bound, that
8085 the pair returned by equal_range is a valid range, and that the first
8086 part of that pair is the lower bound.</p>
8087 <hr>
8088 <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>
8089 <p>
8090 Class template basic_iostream has no typedefs.  The typedefs it
8091 inherits from its base classes can't be used, since (for example)
8092 basic_iostream&lt;T&gt;::traits_type is ambiguous.
8093 </p>
8094 <p><b>Proposed resolution:</b></p>
8095
8096 <p>Add the following to basic_iostream's class synopsis in
8097 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>
8098
8099 <pre>  // types:
8100   typedef charT                     char_type;
8101   typedef typename traits::int_type int_type;
8102   typedef typename traits::pos_type pos_type;
8103   typedef typename traits::off_type off_type;
8104   typedef traits                    traits_type;
8105 </pre>
8106 <hr>
8107 <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>
8108 <p>
8109 27.4.4.3, p4 says about the postcondition of the function: If
8110 rdbuf()!=0 then state == rdstate(); otherwise
8111 rdstate()==state|ios_base::badbit.
8112 </p>
8113
8114 <p>
8115 The expression on the right-hand-side of the operator==() needs to be
8116 parenthesized in order for the whole expression to ever evaluate to
8117 anything but non-zero.
8118 </p>
8119 <p><b>Proposed resolution:</b></p>
8120 <p>
8121 Add parentheses like so: rdstate()==(state|ios_base::badbit).
8122 </p>
8123 <hr>
8124 <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>
8125 <p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
8126 27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
8127 That's incorrect since the names are members of a dependent base
8128 class (14.6.2 [temp.dep]) and thus not visible.</p>
8129 <p><b>Proposed resolution:</b></p>
8130 <p>Qualify the names with the name of the class of which they are
8131 members, i.e., ios_base.</p>
8132 <hr>
8133 <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>
8134 <p>
8135 I see that table 31 in 20.1.5, p3 allows T in std::allocator&lt;T&gt; to be of
8136 any type. But the synopsis in 20.4.1 calls for allocator&lt;&gt;::address() to
8137 be overloaded on reference and const_reference, which is ill-formed for
8138 all T = const U. In other words, this won't work:
8139 </p>
8140
8141 <p>
8142 template class std::allocator&lt;const int&gt;;
8143 </p>
8144
8145 <p>
8146 The obvious solution is to disallow specializations of allocators on
8147 const types. However, while containers' elements are required to be
8148 assignable (which rules out specializations on const T's), I think that
8149 allocators might perhaps be potentially useful for const values in other
8150 contexts. So if allocators are to allow const types a partial
8151 specialization of std::allocator&lt;const T&gt; would probably have to be
8152 provided.
8153 </p>
8154 <p><b>Proposed resolution:</b></p>
8155 <p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
8156
8157     <blockquote>
8158     any type
8159     </blockquote>
8160
8161 <p>to</p>
8162     <blockquote>
8163     any non-const, non-reference type
8164     </blockquote>
8165
8166 <p><i>[Redmond: previous proposed resolution was "any non-const,
8167 non-volatile, non-reference type".  Got rid of the "non-volatile".]</i></p>
8168
8169 <p><b>Rationale:</b></p>
8170 <p>
8171 Two resolutions were originally proposed: one that partially
8172 specialized std::allocator for const types, and one that said an
8173 allocator's value type may not be const.  The LWG chose the second.
8174 The first wouldn't be appropriate, because allocators are intended for
8175 use by containers, and const value types don't work in containers.
8176 Encouraging the use of allocators with const value types would only
8177 lead to unsafe code.
8178 </p>
8179 <p>
8180 The original text for proposed resolution 2 was modified so that it
8181 also forbids volatile types and reference types.
8182 </p>
8183
8184 <p><i>[Curaçao: LWG double checked and believes volatile is correctly
8185 excluded from the PR.]</i></p>
8186
8187 <hr>
8188 <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>
8189 <p>
8190 In 22.2.2.1.1, we have a list of overloads for num_get&lt;&gt;::get().
8191 There are eight overloads, all of which are identical except for the
8192 last parameter.  The overloads are:
8193 </p>
8194 <ul>
8195 <li> long&amp; </li>
8196 <li> unsigned short&amp; </li>
8197 <li> unsigned int&amp; </li>
8198 <li> unsigned long&amp; </li>
8199 <li> short&amp; </li>
8200 <li> double&amp; </li>
8201 <li> long double&amp; </li>
8202 <li> void*&amp; </li>
8203 </ul>
8204
8205 <p>
8206 There is a similar list, in 22.2.2.1.2, of overloads for
8207 num_get&lt;&gt;::do_get().  In this list, the last parameter has
8208 the types:
8209 </p>
8210 <ul>
8211 <li> long&amp; </li>
8212 <li> unsigned short&amp; </li>
8213 <li> unsigned int&amp; </li>
8214 <li> unsigned long&amp; </li>
8215 <li> float&amp; </li>
8216 <li> double&amp; </li>
8217 <li> long double&amp; </li>
8218 <li> void*&amp; </li>
8219 </ul>
8220
8221 <p>
8222 These two lists are not identical.  They should be, since
8223 <tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
8224 the arguments it was given.
8225 </p>
8226 <p><b>Proposed resolution:</b></p>
8227 <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>
8228 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
8229                 ios_base::iostate&amp; err, short&amp; val) const;
8230 </pre>
8231 <p>to</p>
8232 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
8233                 ios_base::iostate&amp; err, float&amp; val) const;
8234 </pre>
8235 <hr>
8236 <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>
8237 <p>
8238 23.1/3 states that the objects stored in a container must be
8239 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,
8240 states that map satisfies all requirements for a container, while in
8241 the same time defining value_type as pair&lt;const Key, T&gt; - a type
8242 that is not Assignable.
8243 </p>
8244
8245 <p>
8246 It should be noted that there exists a valid and non-contradictory
8247 interpretation of the current text. The wording in 23.1/3 avoids
8248 mentioning value_type, referring instead to "objects stored in a
8249 container." One might argue that map does not store objects of
8250 type map::value_type, but of map::mapped_type instead, and that the
8251 Assignable requirement applies to map::mapped_type, not
8252 map::value_type.
8253 </p>
8254
8255 <p>
8256 However, this makes map a special case (other containers store objects of
8257 type value_type) and the Assignable requirement is needlessly restrictive in
8258 general.
8259 </p>
8260
8261 <p>
8262 For example, the proposed resolution of active library issue
8263 <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
8264 means that no set operations can exploit the fact that the stored
8265 objects are Assignable.
8266 </p>
8267
8268 <p>
8269 This is related to, but slightly broader than, closed issue
8270 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>.
8271 </p>
8272 <p><b>Proposed resolution:</b></p>
8273 <p>23.1/3: Strike the trailing part of the sentence:</p>
8274     <blockquote>
8275     , and the additional requirements of Assignable types from 23.1/3
8276     </blockquote>
8277 <p>so that it reads:</p>
8278     <blockquote>
8279     -3- The type of objects stored in these components must meet the
8280     requirements of CopyConstructible types (lib.copyconstructible).
8281     </blockquote>
8282
8283 <p>23.1/4: Modify to make clear that this requirement is not for all
8284 containers.  Change to:</p>
8285
8286 <blockquote>
8287 -4- Table 64 defines the Assignable requirement.  Some containers
8288 require this property of the types to be stored in the container.  T is
8289 the type used to instantiate the container. t is a value of T, and u is
8290 a value of (possibly const) T.
8291 </blockquote>
8292
8293 <p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
8294 CopyConstructible".</p>
8295
8296 <p>23.2.1/2: Add sentence for Assignable requirement.  Change to:</p>
8297
8298 <blockquote>
8299 -2- A deque satisfies all of the requirements of a container and of a
8300 reversible container (given in tables in lib.container.requirements) and
8301 of a sequence, including the optional sequence requirements
8302 (lib.sequence.reqmts).  In addition to the requirements on the stored
8303 object described in 23.1[lib.container.requirements], the stored object
8304 must also meet the requirements of Assignable.  Descriptions are
8305 provided here only for operations on deque that are not described in one
8306 of these tables or for operations where there is additional semantic
8307 information.
8308 </blockquote>
8309
8310 <p>23.2.2/2:  Add Assignable requirement to specific methods of list.
8311 Change to:</p>
8312
8313 <blockquote>
8314 <p>-2- A list satisfies all of the requirements of a container and of a
8315 reversible container (given in two tables in lib.container.requirements)
8316 and of a sequence, including most of the the optional sequence
8317 requirements (lib.sequence.reqmts). The exceptions are the operator[]
8318 and at member functions, which are not provided.
8319
8320 [Footnote: These member functions are only provided by containers whose
8321 iterators are random access iterators. --- end foonote]
8322 </p>
8323
8324 <p>list does not require the stored type T to be Assignable unless the
8325 following methods are instantiated:
8326
8327 [Footnote: Implementors are permitted but not required to take advantage
8328 of T's Assignable properties for these methods. -- end foonote]
8329 </p>
8330 <pre>     list&lt;T,Allocator&gt;&amp; operator=(const list&lt;T,Allocator&gt;&amp;  x );
8331      template &lt;class InputIterator&gt;
8332        void assign(InputIterator first, InputIterator last);
8333      void assign(size_type n, const T&amp; t);
8334 </pre>
8335
8336
8337 <p>Descriptions are provided here only for operations on list that are not
8338 described in one of these tables or for operations where there is
8339 additional semantic information.</p>
8340 </blockquote>
8341
8342 <p>23.2.4/2:   Add sentence for Assignable requirement.  Change to:</p>
8343
8344 <blockquote>
8345 -2- A vector satisfies all of the requirements of a container and of a
8346 reversible container (given in two tables in lib.container.requirements)
8347 and of a sequence, including most of the optional sequence requirements
8348 (lib.sequence.reqmts). The exceptions are the push_front and pop_front
8349 member functions, which are not provided.  In addition to the
8350 requirements on the stored object described in
8351 23.1[lib.container.requirements], the stored object must also meet the
8352 requirements of Assignable.  Descriptions are provided here only for
8353 operations on vector that are not described in one of these tables or
8354 for operations where there is additional semantic information.
8355 </blockquote>
8356 <p><b>Rationale:</b></p>
8357 <p>list, set, multiset, map, multimap are able to store non-Assignables.
8358 However, there is some concern about <tt>list&lt;T&gt;</tt>:
8359 although in general there's no reason for T to be Assignable, some
8360 implementations of the member functions <tt>operator=</tt> and
8361 <tt>assign</tt> do rely on that requirement.  The LWG does not want
8362 to forbid such implementations.</p>
8363
8364 <p>Note that the type stored in a standard container must still satisfy
8365 the requirements of the container's allocator; this rules out, for
8366 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>
8367 for more details.
8368 </p>
8369
8370 <p>In principle we could also relax the "Assignable" requirement for
8371 individual <tt>vector</tt> member functions, such as
8372 <tt>push_back</tt>.  However, the LWG did not see great value in such
8373 selective relaxation.  Doing so would remove implementors' freedom to
8374 implement <tt>vector::push_back</tt> in terms of
8375 <tt>vector::insert</tt>.</p>
8376
8377 <hr>
8378 <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>
8379 <p>
8380 Section 23.2.2.4 [lib.list.ops] states that
8381 </p>
8382 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
8383 </pre>
8384 <p>
8385 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
8386 </p>
8387
8388 <p>
8389 But what does the C++ Standard mean by "invalidate"?  You
8390 can still dereference the iterator to a spliced list element, but
8391 you'd better not use it to delimit a range within the original
8392 list. For the latter operation, it has definitely lost some of its
8393 validity.
8394 </p>
8395
8396 <p>
8397 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>,
8398 then we'd better clarify that a "valid" iterator need no
8399 longer designate an element within the same container as it once did.
8400 We then have to clarify what we mean by invalidating a past-the-end
8401 iterator, as when a vector or string grows by reallocation. Clearly,
8402 such an iterator has a different kind of validity. Perhaps we should
8403 introduce separate terms for the two kinds of "validity."
8404 </p>
8405 <p><b>Proposed resolution:</b></p>
8406 <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>,
8407 after paragraph 5:</p>
8408 <blockquote>
8409 An <i>invalid</i> iterator is an iterator that may be
8410 singular. [Footnote: This definition applies to pointers, since
8411 pointers are iterators. The effect of dereferencing an iterator that
8412 has been invalidated is undefined.]
8413 </blockquote>
8414
8415 <p><i>[post-Copenhagen: Matt provided wording.]</i></p>
8416
8417 <p><i>[Redmond: General agreement with the intent, some objections to
8418 the wording.  Dave provided new wording.]</i></p>
8419 <p><b>Rationale:</b></p>
8420 <p>This resolution simply defines a term that the Standard uses but
8421   never defines, "invalid", in terms of a term that is defined,
8422   "singular".</p>
8423
8424 <p>Why do we say "may be singular", instead of "is singular"?  That's
8425   becuase a valid iterator is one that is known to be nonsingular.
8426   Invalidating an iterator means changing it in such a way that it's
8427   no longer known to be nonsingular.  An example: inserting an
8428   element into the middle of a vector is correctly said to invalidate
8429   all iterators pointing into the vector.  That doesn't necessarily
8430   mean they all become singular.</p>
8431 <hr>
8432 <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>
8433 <p>
8434 This came from an email from Steve Cleary to Fergus in reference to
8435 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
8436 this in Toronto and believed it should be a separate issue.  There was
8437 also some reservations about whether this was a worthwhile problem to
8438 fix.
8439 </p>
8440
8441 <p>
8442 Steve said: "Fixing reverse_iterator. std::reverse_iterator can
8443 (and should) be changed to preserve these additional
8444 requirements." He also said in email that it can be done without
8445 breaking user's code: "If you take a look at my suggested
8446 solution, reverse_iterator doesn't have to take two parameters; there
8447 is no danger of breaking existing code, except someone taking the
8448 address of one of the reverse_iterator global operator functions, and
8449 I have to doubt if anyone has ever done that. . .  <i>But</i>, just in
8450 case they have, you can leave the old global functions in as well --
8451 they won't interfere with the two-template-argument functions.  With
8452 that, I don't see how <i>any</i> user code could break."
8453 </p>
8454 <p><b>Proposed resolution:</b></p>
8455 <p>
8456 <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>
8457 add/change the following declarations:</p>
8458 <pre>  A) Add a templated assignment operator, after the same manner
8459         as the templated copy constructor, i.e.:
8460
8461   template &lt; class U &gt;
8462   reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
8463
8464   B) Make all global functions (except the operator+) have
8465   two template parameters instead of one, that is, for
8466   operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
8467
8468        template &lt; class Iterator &gt;
8469        typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
8470                  const reverse_iterator&lt; Iterator &gt;&amp; x,
8471                  const reverse_iterator&lt; Iterator &gt;&amp; y);
8472
8473   with:
8474
8475       template &lt; class Iterator1, class Iterator2 &gt;
8476       typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
8477                  const reverse_iterator &lt; Iterator1 &gt; &amp; x,
8478                  const reverse_iterator &lt; Iterator2 &gt; &amp; y);
8479 </pre>
8480 <p>
8481 Also make the addition/changes for these signatures in
8482 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>.
8483 </p>
8484
8485 <p><i>[
8486 Copenhagen: The LWG is concerned that the proposed resolution
8487 introduces new overloads.  Experience shows that introducing
8488 overloads is always risky, and that it would be inappropriate to
8489 make this change without implementation experience.  It may be
8490 desirable to provide this feature in a different way.
8491 ]</i></p>
8492
8493 <p><i>[
8494 Lillehammer: We now have implementation experience, and agree that
8495 this solution is safe and correct.
8496 ]</i></p>
8497
8498 <hr>
8499 <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>
8500 <p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
8501 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>)
8502 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>).
8503 Since the functions take and return their arguments and result by
8504 const reference, I believe the <tt>CopyConstructible</tt> requirement
8505 is unnecessary.
8506 </p>
8507 <p><b>Proposed resolution:</b></p>
8508 <p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
8509 25.3.7, p1 with</p>
8510 <p><b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt>
8511 (20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
8512 </p>
8513 <p>and replace 25.3.7, p4 with</p>
8514 <p><b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt>
8515 (20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
8516 </p>
8517 <hr>
8518 <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>
8519 <p>
8520 Paragraph 16 mistakenly singles out integral types for inserting
8521 thousands_sep() characters.  This conflicts with the syntax for floating
8522 point numbers described under 22.2.3.1/2.
8523 </p>
8524 <p><b>Proposed resolution:</b></p>
8525 <p>Change paragraph 16 from:</p>
8526
8527 <blockquote>
8528 For integral types, punct.thousands_sep() characters are inserted into
8529 the sequence as determined by the value returned by punct.do_grouping()
8530 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>.
8531 </blockquote>
8532
8533 <p>To:</p>
8534
8535 <blockquote>
8536 For arithmetic types, punct.thousands_sep() characters are inserted into
8537 the sequence as determined by the value returned by punct.do_grouping()
8538 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>.
8539 </blockquote>
8540
8541 <p><i>[
8542 Copenhagen: Opinions were divided about whether this is actually an
8543 inconsistency, but at best it seems to have been unintentional.  This
8544 is only an issue for floating-point output: The standard is
8545 unambiguous that implementations must parse thousands_sep characters
8546 when performing floating-point.  The standard is also unambiguous that
8547 this requirement does not apply to the "C" locale.
8548 ]</i></p>
8549
8550 <p><i>[
8551 A survey of existing practice is needed; it is believed that some
8552 implementations do insert thousands_sep characters for floating-point
8553 output and others fail to insert thousands_sep characters for
8554 floating-point input even though this is unambiguously required by the
8555 standard.
8556 ]</i></p>
8557
8558 <p><i>[Post-Curaçao: the above proposed resolution is the consensus of
8559 Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
8560
8561 <hr>
8562 <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>
8563 <p>
8564 (revision of the further discussion)
8565 There are a number of problems with the requires clauses for the
8566 algorithms in 25.1 and 25.2. The requires clause of each algorithm
8567 should describe the necessary and sufficient requirements on the inputs
8568 to the algorithm such that the algorithm compiles and runs properly.
8569 Many of the requires clauses fail to do this. Here is a summary of the kinds
8570 of mistakes:
8571 </p>
8572
8573 <ol>
8574 <li>
8575 Use of EqualityComparable, which only puts requirements on a single
8576 type, when in fact an equality operator is required between two
8577 different types, typically either T and the iterator's value type
8578 or between the value types of two different iterators.
8579 </li>
8580 <li>
8581 Use of Assignable for T when in fact what was needed is Assignable
8582 for the value_type of the iterator, and convertability from T to the
8583 value_type of the iterator. Or for output iterators, the requirement
8584 should be that T is writable to the iterator (output iterators do
8585 not have value types).
8586 </li>
8587 </ol>
8588
8589 <p>
8590 Here is the list of algorithms that contain mistakes:
8591 </p>
8592
8593 <ul>
8594 <li>25.1.2 std::find</li>
8595 <li>25.1.6 std::count</li>
8596 <li>25.1.8 std::equal</li>
8597 <li>25.1.9 std::search, std::search_n</li>
8598 <li>25.2.4 std::replace, std::replace_copy</li>
8599 <li>25.2.5 std::fill</li>
8600 <li>25.2.7 std::remove, std::remove_copy</li>
8601 </ul>
8602
8603 <p>
8604 Also, in the requirements for EqualityComparable, the requirement that
8605 the operator be defined for const objects is lacking.
8606 </p>
8607
8608 <p><b>Proposed resolution:</b></p>
8609
8610 <p>20.1.1 Change p1 from</p>
8611
8612 <p>In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
8613 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
8614 values of type <tt>T</tt>.
8615 </p>
8616
8617 <p>to</p>
8618
8619 <p>
8620 In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
8621 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
8622 values of type <tt>const T</tt>.
8623 </p>
8624
8625 <p>25 Between p8 and p9</p>
8626
8627 <p>Add the following sentence:</p>
8628
8629 <p>When the description of an algorithm gives an expression such as
8630 <tt>*first == value</tt> for a condition, it is required that the expression
8631 evaluate to either true or false in boolean contexts.</p>
8632
8633 <p>25.1.2 Change p1 by deleting the requires clause.</p>
8634
8635 <p>25.1.6 Change p1 by deleting the requires clause.</p>
8636
8637 <p>25.1.9</p>
8638
8639 <p>Change p4 from</p>
8640
8641 <p>-4- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt>
8642 (20.1.1), type Size is convertible to integral type (4.7.12.3).
8643 </p>
8644
8645 <p>to</p>
8646
8647 <p>-4- Requires: The type <tt>Size</tt> is convertible to integral
8648 type (4.7.12.3).</p>
8649
8650 <p>25.2.4 Change p1 from</p>
8651
8652 <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>
8653
8654 <p>to</p>
8655
8656 <p>-1- Requires: The expression <tt>*first = new_value</tt> must be valid.</p>
8657
8658 <p>and change p4 from</p>
8659
8660 <p>-4- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1) (and,
8661 for <tt>replace_copy()</tt>, <tt>EqualityComparable</tt>
8662 (20.1.1)). The ranges <tt>[first, last)</tt> and <tt>[result, result +
8663 (last - first))</tt> shall not overlap.</p>
8664
8665 <p>to</p>
8666
8667 <p>-4- Requires: The results of the expressions <tt>*first</tt> and
8668 <tt>new_value</tt> must be writable to the result output iterator. The
8669 ranges <tt>[first, last)</tt> and <tt>[result, result + (last -
8670 first))</tt> shall not overlap.</p>
8671
8672
8673 <p>25.2.5 Change p1 from</p>
8674
8675 <p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1). The
8676 type <tt>Size</tt> is convertible to an integral type (4.7.12.3).</p>
8677
8678 <p>to</p>
8679
8680 <p>-1- Requires: The expression <tt>value</tt> must be is writable to
8681 the output iterator. The type <tt>Size</tt> is convertible to an
8682 integral type (4.7.12.3).</p>
8683
8684 <p>25.2.7 Change p1 from</p>
8685
8686 <p>-1- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> (20.1.1).</p>
8687
8688 <p>to</p>
8689
8690 <p>
8691 -1- Requires: The value type of the iterator must be
8692 <tt>Assignable</tt> (23.1).
8693 </p>
8694
8695 <p><b>Rationale:</b></p>
8696 <p>
8697 The general idea of the proposed solution is to remove the faulty
8698 requires clauses and let the returns and effects clauses speak for
8699 themselves. That is, the returns clauses contain expressions that must
8700 be valid, and therefore already imply the correct requirements. In
8701 addition, a sentence is added at the beginning of chapter 25 saying
8702 that expressions given as conditions must evaluate to true or false in
8703 a boolean context. An alternative would be to say that the type of
8704 these condition expressions must be literally bool, but that would be
8705 imposing a greater restriction that what the standard currently says
8706 (which is convertible to bool).
8707 </p>
8708 <hr>
8709 <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>
8710 <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
8711 library function <tt>strcmp()</tt> with the function pointer adapter
8712 <tt>ptr_fun()</tt>. But since it's unspecified whether the C library
8713 functions have <tt>extern "C"</tt> or <tt>extern
8714 "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
8715 function pointers with different the language linkage specifications
8716 (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
8717 well-formed is unspecified.
8718 </p>
8719 <p><b>Proposed resolution:</b></p>
8720 <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>
8721 <blockquote>
8722   <p>[<i>Example:</i></p>
8723   <pre>    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
8724   </pre>
8725   <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
8726 </blockquote>
8727
8728
8729 <p>to:</p>
8730 <blockquote>
8731   <p>[<i>Example:</i></p>
8732   <pre>    int compare(const char*, const char*);
8733     replace_if(v.begin(), v.end(),
8734                not1(bind2nd(ptr_fun(compare), "abc")), "def");
8735   </pre>
8736   <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
8737 </blockquote>
8738
8739 <p>Also, remove footnote 215 in that same paragraph.</p>
8740
8741 <p><i>[Copenhagen: Minor change in the proposed resolution.  Since this
8742 issue deals in part with C and C++ linkage, it was believed to be too
8743 confusing for the strings in the example to be "C" and "C++".
8744 ]</i></p>
8745
8746 <p><i>[Redmond: More minor changes.  Got rid of the footnote (which
8747 seems to make a sweeping normative requirement, even though footnotes
8748 aren't normative), and changed the sentence after the footnote so that
8749 it corresponds to the new code fragment.]</i></p>
8750
8751 <hr>
8752 <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>
8753 <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
8754 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:
8755 </p>
8756
8757 <p>... If that function returns a null pointer, calls
8758 <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
8759 </p>
8760
8761 <p>The parenthetical note doesn't apply since the ctors cannot throw an
8762 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
8763 that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
8764 </p>
8765 <p><b>Proposed resolution:</b></p>
8766 <p>
8767 Strike the parenthetical note from the Effects clause in each of the
8768 paragraphs mentioned above.
8769 </p>
8770 <hr>
8771 <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>
8772 <p>
8773 The &lt;cstdlib&gt; header file contains prototypes for bsearch and
8774 qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
8775 prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
8776 require the typedef size_t. Yet size_t is not listed in the
8777 &lt;cstdlib&gt; synopsis table 78 in section 25.4.
8778 </p>
8779 <p><b>Proposed resolution:</b></p>
8780 <p>
8781 Add the type size_t to Table 78 (section 25.4) and add
8782 the type size_t &lt;cstdlib&gt; to Table 97 (section C.2).
8783 </p>
8784 <p><b>Rationale:</b></p>
8785 <p>Since size_t is in &lt;stdlib.h&gt;, it must also be in &lt;cstdlib&gt;.</p>
8786 <hr>
8787 <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>
8788 <p>
8789 ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
8790 of macros defined in &lt;errno.h&gt; is adjusted to include a new
8791 macro, EILSEQ"
8792 </p>
8793
8794 <p>
8795 ISO/IEC 14882:1998(E) section 19.3 does not refer
8796 to the above amendment.
8797 </p>
8798
8799 <p><b>Proposed resolution:</b></p>
8800 <p>
8801 Update Table 26 (section 19.3) "Header  &lt;cerrno&gt; synopsis"
8802 and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
8803 </p>
8804 <hr>
8805 <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>
8806 <p>
8807 The standard library contains four algorithms that compute set
8808 operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
8809 <tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>.  Each
8810 of these algorithms takes two sorted ranges as inputs, and writes the
8811 output of the appropriate set operation to an output range.  The elements
8812 in the output range are sorted.
8813 </p>
8814
8815 <p>
8816 The ordinary mathematical definitions are generalized so that they
8817 apply to ranges containing multiple copies of a given element.  Two
8818 elements are considered to be "the same" if, according to an
8819 ordering relation provided by the user, neither one is less than the
8820 other.  So, for example, if one input range contains five copies of an
8821 element and another contains three, the output range of <tt>set_union</tt>
8822 will contain five copies, the output range of
8823 <tt>set_intersection</tt> will contain three, the output range of
8824 <tt>set_difference</tt> will contain two, and the output range of
8825 <tt>set_symmetric_difference</tt> will contain two.
8826 </p>
8827
8828 <p>
8829 Because two elements can be "the same" for the purposes
8830 of these set algorithms, without being identical in other respects
8831 (consider, for example, strings under case-insensitive comparison),
8832 this raises a number of unanswered questions:
8833 </p>
8834
8835 <ul>
8836 <li>If we're copying an element that's present in both of the
8837 input ranges, which one do we copy it from?</li>
8838 <li>If there are <i>n</i> copies of an element in the relevant
8839 input range, and the output range will contain fewer copies (say
8840 <i>m</i>) which ones do we choose?  The first <i>m</i>, or the last
8841 <i>m</i>, or something else?</li>
8842 <li>Are these operations stable?  That is, does a run of equivalent
8843 elements appear in the output range in the same order as as it
8844 appeared in the input range(s)?</li>
8845 </ul>
8846
8847 <p>
8848 The standard should either answer these questions, or explicitly
8849 say that the answers are unspecified.  I prefer the former option,
8850 since, as far as I know, all existing implementations behave the
8851 same way.
8852 </p>
8853
8854 <p><b>Proposed resolution:</b></p>
8855
8856 <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>
8857 <blockquote>
8858 If [first1, last1) contains <i>m</i> elements that are equivalent to
8859 each other and [first2, last2) contains <i>n</i> elements that are
8860 equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
8861 will be copied to the output range: all <i>m</i> of these elements
8862 from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
8863 [first2, last2), in that order.
8864 </blockquote>
8865
8866 <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>
8867 <blockquote>
8868 If [first1, last1) contains <i>m</i> elements that are equivalent to each
8869 other and [first2, last2) contains <i>n</i> elements that are
8870 equivalent to them, the first min(<i>m</i>, <i>n</i>) of those
8871 elements from [first1, last1) are copied to the output range.
8872 </blockquote>
8873
8874 <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>
8875 paragraph 4:</p>
8876 <blockquote>
8877 If [first1, last1) contains <i>m</i> elements that are equivalent to each
8878 other and [first2, last2) contains <i>n</i> elements that are
8879 equivalent to them, the last max(<i>m-n</i>, 0) elements from
8880 [first1, last1) are copied to the output range.
8881 </blockquote>
8882
8883 <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>
8884 paragraph 4:</p>
8885 <blockquote>
8886 If [first1, last1) contains <i>m</i> elements that are equivalent to
8887 each other and [first2, last2) contains <i>n</i> elements that are
8888 equivalent to them, then |<i>m - n</i>| of those elements will be
8889 copied to the output range: the last <i>m - n</i> of these elements
8890 from [first1, last1) if <i>m</i> &gt; <i>n</i>, and the last <i>n -
8891 m</i> of these elements from [first2, last2) if <i>m</i> &lt; <i>n</i>.
8892 </blockquote>
8893
8894 <p><i>[Santa Cruz: it's believed that this language is clearer than
8895   what's in the Standard.  However, it's also believed that the
8896   Standard may already make these guarantees (although not quite in
8897   these words).  Bill and Howard will check and see whether they think
8898   that some or all of these changes may be redundant.  If so, we may
8899   close this issue as NAD.]</i></p>
8900
8901 <p><b>Rationale:</b></p>
8902 <p>For simple cases, these descriptions are equivalent to what's
8903   already in the Standard.  For more complicated cases, they describe
8904   the behavior of existing implementations.</p>
8905 <hr>
8906 <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>
8907 <p>The Effects clause of the member function <tt>copyfmt()</tt> in
8908 27.4.4.2, p15 doesn't consider the case where the left-hand side
8909 argument is identical to the argument on the right-hand side, that is
8910 <tt>(this == &amp;rhs)</tt>.  If the two arguments are identical there
8911 is no need to copy any of the data members or call any callbacks
8912 registered with <tt>register_callback()</tt>.  Also, as Howard Hinnant
8913 points out in message c++std-lib-8149 it appears to be incorrect to
8914 allow the object to fire <tt>erase_event</tt> followed by
8915 <tt>copyfmt_event</tt> since the callback handling the latter event
8916 may inadvertently attempt to access memory freed by the former.
8917 </p>
8918 <p><b>Proposed resolution:</b></p>
8919 <p>Change the Effects clause in 27.4.4.2, p15 from</p>
8920
8921 <blockquote>
8922 <b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
8923 the corresponding member objects of <tt>rhs</tt>, except that...
8924 </blockquote>
8925
8926 <p>to</p>
8927
8928 <blockquote>
8929 <b>-15- Effects:</b>If <tt>(this == &amp;rhs)</tt> does nothing. Otherwise
8930 assigns to the member objects of <tt>*this</tt> the corresponding member
8931 objects of <tt>rhs</tt>, except that...
8932 </blockquote>
8933 <hr>
8934 <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>
8935 <p>
8936 Table 80 lists the contents of the &lt;cmath&gt; header.  It does not
8937 list <tt>abs()</tt>.  However, 26.5, paragraph 6, which lists added
8938 signatures present in &lt;cmath&gt;, does say that several overloads
8939 of <tt>abs()</tt> should be defined in &lt;cmath&gt;.
8940 </p>
8941 <p><b>Proposed resolution:</b></p>
8942 <p>
8943 Add <tt>abs</tt> to Table 80.  Also, remove the parenthetical list
8944 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>,
8945 paragraph 1.
8946 </p>
8947
8948 <p><i>[Copenhagen: Modified proposed resolution so that it also gets
8949 rid of that vestigial list of functions in paragraph 1.]</i></p>
8950
8951 <p><b>Rationale:</b></p>
8952 <p>All this DR does is fix a typo; it's uncontroversial.  A
8953 separate question is whether we're doing the right thing in
8954 putting some overloads in &lt;cmath&gt; that we aren't also
8955 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>
8956 <hr>
8957 <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>
8958 <p>The class templates <tt>const_mem_fun_t</tt> in 20.3.8, p8 and
8959 <tt>const_mem_fun1_t</tt>
8960 in 20.3.8, p9 derive from <tt>unary_function&lt;T*, S&gt;</tt>, and
8961 <tt>binary_function&lt;T*,
8962 A, S&gt;</tt>, respectively. Consequently, their <tt>argument_type</tt>, and
8963 <tt>first_argument_type</tt>
8964 members, respectively, are both defined to be <tt>T*</tt> (non-const).
8965 However, their function call member operator takes a <tt>const T*</tt>
8966 argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
8967 T*</tt> instead, so that one can easily refer to it in generic code. The
8968 example below derived from existing code fails to compile due to the
8969 discrepancy:
8970 </p>
8971
8972 <p><tt>template &lt;class T&gt;</tt>
8973 <br><tt>void foo (typename T::argument_type arg)&nbsp;&nbsp; // #1</tt>
8974 <br><tt>{</tt>
8975 <br><tt>&nbsp;&nbsp;&nbsp; typename T::result_type (T::*pf) (typename
8976 T::argument_type)
8977 const =&nbsp;&nbsp; // #2</tt>
8978 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;T::operator();</tt>
8979 <br><tt>}</tt>
8980 </p>
8981
8982 <p><tt>struct X { /* ... */ };</tt></p>
8983
8984 <p><tt>int main ()</tt>
8985 <br><tt>{</tt>
8986 <br><tt>&nbsp;&nbsp;&nbsp; const X x;</tt>
8987 <br><tt>&nbsp;&nbsp;&nbsp; foo&lt;std::const_mem_fun_t&lt;void, X&gt;
8988 &gt;(&amp;x);&nbsp;&nbsp;
8989 // #3</tt>
8990 <br><tt>}</tt>
8991 </p>
8992
8993 <p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
8994 <br>#2 the type of the pointer is incompatible with the type of the member
8995 function
8996 <br>#3 the address of a constant being passed to a function taking a non-const
8997 <tt>X*</tt>
8998 </p>
8999 <p><b>Proposed resolution:</b></p>
9000 <p>Replace the top portion of the definition of the class template
9001 const_mem_fun_t in 20.3.8, p8
9002 </p>
9003 <p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
9004 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9005 unary_function&lt;T*, S&gt; {</tt>
9006 </p>
9007 <p>with</p>
9008 <p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
9009 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9010 unary_function&lt;<b>const</b> T*, S&gt; {</tt>
9011 </p>
9012 <p>Also replace the top portion of the definition of the class template
9013 const_mem_fun1_t in 20.3.8, p9</p>
9014 <p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
9015 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9016 binary_function&lt;T*, A, S&gt; {</tt>
9017 </p>
9018 <p>with</p>
9019 <p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
9020 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9021 binary_function&lt;<b>const</b> T*, A, S&gt; {</tt>
9022 </p>
9023 <p><b>Rationale:</b></p>
9024 <p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
9025 and the argument type itself, are not the same.</p>
9026 <hr>
9027 <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>
9028 <p>
9029 The default behavior of <tt>operator delete[]</tt> described in 18.4.1.2, p12 -
9030 namely that for non-null value of <i>ptr</i>, the operator reclaims storage
9031 allocated by the earlier call to the default <tt>operator new[]</tt> - is not
9032 correct in all cases. Since the specified <tt>operator new[]</tt> default
9033 behavior is to call <tt>operator new</tt> (18.4.1.2, p4, p8), which can be
9034 replaced, along with <tt>operator delete</tt>, by the user, to implement their
9035 own memory management, the specified default behavior of<tt> operator
9036 delete[]</tt> must be to call <tt>operator delete</tt>.
9037 </p>
9038 <p><b>Proposed resolution:</b></p>
9039 <p>Change 18.4.1.2, p12 from</p>
9040 <blockquote>
9041 <b>-12-</b> <b>Default behavior:</b>
9042 <ul>
9043 <li>
9044 For a null value of <i><tt>ptr</tt></i> , does nothing.
9045 </li>
9046 <li>
9047 Any other value of <i><tt>ptr</tt></i> shall be a value returned
9048 earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
9049 [Footnote: The value must not have been invalidated by an intervening
9050 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>).
9051 --- end footnote]
9052 For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
9053 allocated by the earlier call to the default <tt>operator new[]</tt>.
9054 </li>
9055 </ul>
9056 </blockquote>
9057
9058 <p>to</p>
9059
9060 <blockquote>
9061 <b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
9062 delete(</tt><i>ptr</i>)
9063 or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
9064 </blockquote>
9065 <p>and expunge paragraph 13.</p>
9066 <hr>
9067 <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>
9068 <p>
9069 The "Effects" clause for list::merge() (23.2.2.4, p23)
9070 appears to be incomplete: it doesn't cover the case where the argument
9071 list is identical to *this (i.e., this == &amp;x). The requirement in the
9072 note in p24 (below) is that x be empty after the merge which is surely
9073 unintended in this case.
9074 </p>
9075 <p><b>Proposed resolution:</b></p>
9076 <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>
9077 <blockquote>
9078 <p>
9079 23 Effects: if (&amp;x == this) does nothing; otherwise, merges the two
9080 sorted ranges [begin(), end()) and [x.begin(), x.end()).  The result
9081 is a range in which the elements will be sorted in non-decreasing
9082 order according to the ordering defined by comp; that is, for every
9083 iterator i in the range other than the first, the condition comp(*i,
9084 *(i - 1)) will be false.
9085 </p>
9086
9087 <p>
9088 24 Notes: Stable: if (&amp;x != this), then for equivalent elements in the
9089 two original ranges, the elements from the original range [begin(),
9090 end()) always precede the elements from the original range [x.begin(),
9091 x.end()).  If (&amp;x != this) the range [x.begin(), x.end()) is empty
9092 after the merge.
9093 </p>
9094
9095 <p>
9096 25 Complexity: At most size() + x.size() - 1 applications of comp if
9097 (&amp;x !  = this); otherwise, no applications of comp are performed.  If
9098 an exception is thrown other than by a comparison there are no
9099 effects.
9100 </p>
9101
9102 </blockquote>
9103
9104 <p><i>[Copenhagen: The original proposed resolution did not fix all of
9105 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
9106 paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
9107 Changing p23, without changing the other two, appears to introduce
9108 contradictions.  Additionally, "merges the argument list into the
9109 list" is excessively vague.]</i></p>
9110
9111 <p><i>[Post-Curaçao: Robert Klarer provided new wording.]</i></p>
9112
9113 <hr>
9114 <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>
9115 <p>
9116 The effects clause for the basic_string template ctor in 21.3.1, p15
9117 leaves out the third argument of type Allocator. I believe this to be
9118 a mistake.
9119 </p>
9120 <p><b>Proposed resolution:</b></p>
9121 <p>Replace</p>
9122
9123 <blockquote>
9124     <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
9125     type, equivalent to</p>
9126
9127     <blockquote><tt>basic_string(static_cast&lt;size_type&gt;(begin),
9128     static_cast&lt;value_type&gt;(end))</tt></blockquote>
9129 </blockquote>
9130
9131 <p>with</p>
9132
9133 <blockquote>
9134     <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
9135     type, equivalent to</p>
9136
9137     <blockquote><tt>basic_string(static_cast&lt;size_type&gt;(begin),
9138     static_cast&lt;value_type&gt;(end), <b>a</b>)</tt></blockquote>
9139 </blockquote>
9140 <hr>
9141 <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>
9142 <p>
9143 In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
9144 "Extracts up to <i>N</i> (single-byte) characters from
9145 <i>is</i>.", where <i>is</i> is a stream of type
9146 <tt>basic_istream&lt;charT, traits&gt;</tt>.
9147 </p>
9148
9149 <p>
9150 The standard does not say what it means to extract single byte
9151 characters from a stream whose character type, <tt>charT</tt>, is in
9152 general not a single-byte character type.  Existing implementations
9153 differ.
9154 </p>
9155
9156 <p>
9157 A reasonable solution will probably involve <tt>widen()</tt> and/or
9158 <tt>narrow()</tt>, since they are the supplied mechanism for
9159 converting a single character between <tt>char</tt> and
9160 arbitrary <tt>charT</tt>.
9161 </p>
9162
9163 <p>Narrowing the input characters is not the same as widening the
9164 literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
9165 locales in which more than one wide character maps to the narrow
9166 character <tt>'0'</tt>.  Narrowing means that alternate
9167 representations may be used for bitset input, widening means that
9168 they may not be.</p>
9169
9170 <p>Note that for numeric input, <tt>num_get&lt;&gt;</tt>
9171 (22.2.2.1.2/8) compares input characters to widened version of narrow
9172 character literals.</p>
9173
9174 <p>From Pete Becker, in c++std-lib-8224:</p>
9175 <blockquote>
9176 <p>
9177 Different writing systems can have different representations for the
9178 digits that represent 0 and 1. For example, in the Unicode representation
9179 of the Devanagari script (used in many of the Indic languages) the digit 0
9180 is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
9181 into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
9182 0x0031 for for the Latin representations of '0' and '1', as well as code
9183 points for the same numeric values in several other scripts (Tamil has no
9184 character for 0, but does have the digits 1-9), and any of these values
9185 would also be narrowed to '0' and '1'.
9186 </p>
9187
9188 <p>...</p>
9189
9190 <p>
9191 It's fairly common to intermix both native and Latin
9192 representations of numbers in a document. So I think the rule has to be
9193 that if a wide character represents a digit whose value is 0 then the bit
9194 should be cleared; if it represents a digit whose value is 1 then the bit
9195 should be set; otherwise throw an exception. So in a Devanagari locale,
9196 both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
9197 would set it. Widen can't do that. It would pick one of those two values,
9198 and exclude the other one.
9199 </p>
9200
9201 </blockquote>
9202
9203 <p>From Jens Maurer, in c++std-lib-8233:</p>
9204
9205 <blockquote>
9206 <p>
9207 Whatever we decide, I would find it most surprising if
9208 bitset conversion worked differently from int conversion
9209 with regard to alternate local representations of
9210 numbers.
9211 </p>
9212
9213 <p>Thus, I think the options are:</p>
9214 <ul>
9215  <li> Have a new defect issue for 22.2.2.1.2/8 so that it will
9216 require the use of narrow().</li>
9217
9218  <li> Have a defect issue for bitset() which describes clearly
9219 that widen() is to be used.</li>
9220 </ul>
9221 </blockquote>
9222 <p><b>Proposed resolution:</b></p>
9223
9224     <p>Replace the first two sentences of paragraph 5 with:</p>
9225
9226     <blockquote>
9227     Extracts up to <i>N</i> characters from <i>is</i>. Stores these
9228     characters in a temporary object <i>str</i> of type
9229     <tt>basic_string&lt;charT, traits&gt;</tt>, then evaluates the
9230     expression <tt><i>x</i> = bitset&lt;N&gt;(<i>str</i>)</tt>.
9231     </blockquote>
9232
9233     <p>Replace the third bullet item in paragraph 5 with:</p>
9234     <ul><li>
9235     the next input character is neither <tt><i>is</i>.widen(0)</tt>
9236     nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
9237     is not extracted).
9238     </li></ul>
9239
9240 <p><b>Rationale:</b></p>
9241 <p>Input for <tt>bitset</tt> should work the same way as numeric
9242 input.  Using <tt>widen</tt> does mean that alternative digit
9243 representations will not be recognized, but this was a known
9244 consequence of the design choice.</p>
9245 <hr>
9246 <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>
9247 <p>22.2.1.5/3 introduces codecvt in part with:</p>
9248
9249 <blockquote>
9250   codecvt&lt;wchar_t,char,mbstate_t&gt; converts between the native
9251   character sets for tiny and wide characters. Instantiations on
9252   mbstate_t perform conversion between encodings known to the library
9253   implementor.
9254 </blockquote>
9255
9256 <p>But 22.2.1.5.2/10 describes do_length in part with:</p>
9257
9258 <blockquote>
9259   ... codecvt&lt;wchar_t, char, mbstate_t&gt; ... return(s) the lesser of max and
9260   (from_end-from).
9261 </blockquote>
9262
9263 <p>
9264 The semantics of do_in and do_length are linked.  What one does must
9265 be consistent with what the other does.  22.2.1.5/3 leads me to
9266 believe that the vendor is allowed to choose the algorithm that
9267 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in performs so that it makes
9268 his customers happy on a given platform.  But 22.2.1.5.2/10 explicitly
9269 says what codecvt&lt;wchar_t,char,mbstate_t&gt;::do_length must
9270 return.  And thus indirectly specifies the algorithm that
9271 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in must perform.  I believe
9272 that this is not what was intended and is a defect.
9273 </p>
9274
9275 <p>Discussion from the -lib reflector:
9276
9277 <br>This proposal would have the effect of making the semantics of
9278 all of the virtual functions in <tt>codecvt&lt;wchar_t, char,
9279 mbstate_t&gt;</tt> implementation specified.  Is that what we want, or
9280 do we want to mandate specific behavior for the base class virtuals
9281 and leave the implementation specified behavior for the codecvt_byname
9282 derived class?  The tradeoff is that former allows implementors to
9283 write a base class that actually does something useful, while the
9284 latter gives users a way to get known and specified---albeit
9285 useless---behavior, and is consistent with the way the standard
9286 handles other facets.  It is not clear what the original intention
9287 was.</p>
9288
9289 <p>
9290 Nathan has suggest a compromise: a character that is a widened version
9291 of the characters in the basic execution character set must be
9292 converted to a one-byte sequence, but there is no such requirement
9293 for characters that are not part of the basic execution character set.
9294 </p>
9295 <p><b>Proposed resolution:</b></p>
9296 <p>
9297 Change 22.2.1.5.2/5 from:
9298 </p>
9299 <p>
9300 The instantiations required in Table 51 (lib.locale.category), namely
9301 codecvt&lt;wchar_t,char,mbstate_t&gt; and
9302 codecvt&lt;char,char,mbstate_t&gt;, store no characters. Stores no more
9303 than (to_limit-to) destination elements. It always leaves the to_next
9304 pointer pointing one beyond the last element successfully stored.
9305 </p>
9306 <p>
9307 to:
9308 </p>
9309 <p>
9310 Stores no more than (to_limit-to) destination elements, and leaves the
9311 to_next pointer pointing one beyond the last element successfully
9312 stored.  codecvt&lt;char,char,mbstate_t&gt; stores no characters.
9313 </p>
9314
9315 <p>Change 22.2.1.5.2/10 from:</p>
9316
9317 <blockquote>
9318 -10- Returns: (from_next-from) where from_next is the largest value in
9319 the range [from,from_end] such that the sequence of values in the
9320 range [from,from_next) represents max or fewer valid complete
9321 characters of type internT. The instantiations required in Table 51
9322 (21.1.1.1.1), namely codecvt&lt;wchar_t, char, mbstate_t&gt; and
9323 codecvt&lt;char, char, mbstate_t&gt;, return the lesser of max and
9324 (from_end-from).
9325 </blockquote>
9326
9327 <p>to:</p>
9328
9329 <blockquote>
9330 -10- Returns: (from_next-from) where from_next is the largest value in
9331 the range [from,from_end] such that the sequence of values in the range
9332 [from,from_next) represents max or fewer valid complete characters of
9333 type internT. The instantiation codecvt&lt;char, char, mbstate_t&gt; returns
9334 the lesser of max and (from_end-from).
9335 </blockquote>
9336
9337 <p><i>[Redmond: Nathan suggested an alternative resolution: same as
9338 above, but require that, in the default encoding, a character from the
9339 basic execution character set would map to a single external
9340 character.  The straw poll was 8-1 in favor of the proposed
9341 resolution.]</i></p>
9342
9343 <p><b>Rationale:</b></p>
9344 <p>The default encoding should be whatever users of a given platform
9345 would expect to be the most natural.  This varies from platform to
9346 platform.  In many cases there is a preexisting C library, and users
9347 would expect the default encoding to be whatever C uses in the default
9348 "C" locale.  We could impose a guarantee like the one Nathan suggested
9349 (a character from the basic execution character set must map to a
9350 single external character), but this would rule out important
9351 encodings that are in common use: it would rule out JIS, for
9352 example, and it would rule out a fixed-width encoding of UCS-4.</p>
9353
9354 <p><i>[Curaçao: fixed rationale typo at the request of Ichiro Koshida;
9355 "shift-JIS" changed to "JIS".]</i></p>
9356
9357 <hr>
9358 <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>
9359 <p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
9360
9361 <p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
9362 accepts a restricted set of <i>type</i> arguments in this
9363 International Standard. <i>type</i> shall be a POD structure or a POD
9364 union (clause 9). The result of applying the offsetof macro to a field
9365 that is a static data member or a function member is
9366 undefined."</p>
9367
9368 <p>For the POD requirement, it doesn't say "no diagnostic
9369 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.
9370 It's not clear whether this requirement was intended.  While it's
9371 possible to provide such a diagnostic, the extra complication doesn't
9372 seem to add any value.
9373 </p>
9374 <p><b>Proposed resolution:</b></p>
9375 <p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
9376 structure or a POD union the results are undefined."</p>
9377
9378 <p><i>[Copenhagen: straw poll was 7-4 in favor.  It was generally
9379 agreed that requiring a diagnostic was inadvertent, but some LWG
9380 members thought that diagnostics should be required whenever
9381 possible.]</i></p>
9382
9383 <hr>
9384 <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>
9385
9386 <p>From reflector message c++std-lib-8330.  See also lib-8317.</p>
9387
9388 <p>
9389 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>
9390 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.
9391 23.2.3.3/1, for example, says:
9392 </p>
9393
9394 <blockquote>
9395 -1- Any sequence supporting operations back(), push_back() and pop_back()
9396 can be used to instantiate stack. In particular, vector (lib.vector), list
9397 (lib.list) and deque (lib.deque) can be used.
9398 </blockquote>
9399
9400 <p>But this is false: vector&lt;bool&gt; can not be used, because the
9401 container adaptors return a T&amp; rather than using the underlying
9402 container's reference type.</p>
9403
9404 <p>This is a contradiction that can be fixed by:</p>
9405
9406 <ol>
9407 <li>Modifying these paragraphs to say that vector&lt;bool&gt;
9408     is an exception.</li>
9409 <li>Removing the vector&lt;bool&gt; specialization.</li>
9410 <li>Changing the return types of stack and priority_queue to use
9411     reference typedef's.</li>
9412 </ol>
9413
9414 <p>
9415 I propose 3.  This does not preclude option 2 if we choose to do it
9416 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
9417 3 offers a small step towards support for proxied containers.  This
9418 small step fixes a current contradiction, is easy for vendors to
9419 implement, is already implemented in at least one popular lib, and
9420 does not break any code.
9421 </p>
9422
9423 <p><b>Proposed resolution:</b></p>
9424 <p>Summary: Add reference and const_reference typedefs to queue,
9425 priority_queue and stack.  Change return types of "value_type&amp;" to
9426 "reference".  Change return types of "const value_type&amp;" to
9427 "const_reference".  Details:</p>
9428
9429 <p>Change 23.2.3.1/1 from:</p>
9430
9431 <pre>  namespace std {
9432     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9433     class queue {
9434     public:
9435       typedef typename Container::value_type            value_type;
9436       typedef typename Container::size_type             size_type;
9437       typedef          Container                        container_type;
9438     protected:
9439       Container c;
9440
9441     public:
9442       explicit queue(const Container&amp; = Container());
9443
9444       bool      empty() const             { return c.empty(); }
9445       size_type size()  const             { return c.size(); }
9446       value_type&amp;       front()           { return c.front(); }
9447       const value_type&amp; front() const     { return c.front(); }
9448       value_type&amp;       back()            { return c.back(); }
9449       const value_type&amp; back() const      { return c.back(); }
9450       void push(const value_type&amp; x)      { c.push_back(x); }
9451       void pop()                          { c.pop_front(); }
9452     };
9453 </pre>
9454
9455 <p>to:</p>
9456
9457 <pre>  namespace std {
9458     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9459     class queue {
9460     public:
9461       typedef typename Container::value_type            value_type;
9462       typedef typename Container::reference             reference;
9463       typedef typename Container::const_reference       const_reference;
9464       typedef typename Container::value_type            value_type;
9465       typedef typename Container::size_type             size_type;
9466       typedef          Container                        container_type;
9467     protected:
9468       Container c;
9469
9470     public:
9471       explicit queue(const Container&amp; = Container());
9472
9473       bool      empty() const             { return c.empty(); }
9474       size_type size()  const             { return c.size(); }
9475       reference         front()           { return c.front(); }
9476       const_reference   front() const     { return c.front(); }
9477       reference         back()            { return c.back(); }
9478       const_reference   back() const      { return c.back(); }
9479       void push(const value_type&amp; x)      { c.push_back(x); }
9480       void pop()                          { c.pop_front(); }
9481     };
9482 </pre>
9483
9484 <p>Change 23.2.3.2/1 from:</p>
9485
9486 <pre>  namespace std {
9487     template &lt;class T, class Container = vector&lt;T&gt;,
9488               class Compare = less&lt;typename Container::value_type&gt; &gt;
9489     class priority_queue {
9490     public:
9491       typedef typename Container::value_type            value_type;
9492       typedef typename Container::size_type             size_type;
9493       typedef          Container                        container_type;
9494     protected:
9495       Container c;
9496       Compare comp;
9497
9498     public:
9499       explicit priority_queue(const Compare&amp; x = Compare(),
9500                               const Container&amp; = Container());
9501       template &lt;class InputIterator&gt;
9502         priority_queue(InputIterator first, InputIterator last,
9503                        const Compare&amp; x = Compare(),
9504                        const Container&amp; = Container());
9505
9506       bool      empty() const       { return c.empty(); }
9507       size_type size()  const       { return c.size(); }
9508       const value_type&amp; top() const { return c.front(); }
9509       void push(const value_type&amp; x);
9510       void pop();
9511     };
9512                                   //  no equality is provided
9513   }
9514 </pre>
9515
9516 <p>to:</p>
9517
9518 <pre>  namespace std {
9519     template &lt;class T, class Container = vector&lt;T&gt;,
9520               class Compare = less&lt;typename Container::value_type&gt; &gt;
9521     class priority_queue {
9522     public:
9523       typedef typename Container::value_type            value_type;
9524       typedef typename Container::reference             reference;
9525       typedef typename Container::const_reference       const_reference;
9526       typedef typename Container::size_type             size_type;
9527       typedef          Container                        container_type;
9528     protected:
9529       Container c;
9530       Compare comp;
9531
9532     public:
9533       explicit priority_queue(const Compare&amp; x = Compare(),
9534                               const Container&amp; = Container());
9535       template &lt;class InputIterator&gt;
9536         priority_queue(InputIterator first, InputIterator last,
9537                        const Compare&amp; x = Compare(),
9538                        const Container&amp; = Container());
9539
9540       bool      empty() const       { return c.empty(); }
9541       size_type size()  const       { return c.size(); }
9542       const_reference   top() const { return c.front(); }
9543       void push(const value_type&amp; x);
9544       void pop();
9545     };
9546                                   //  no equality is provided
9547   }
9548 </pre>
9549
9550 <p>And change 23.2.3.3/1 from:</p>
9551
9552 <pre>  namespace std {
9553     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9554     class stack {
9555     public:
9556       typedef typename Container::value_type            value_type;
9557       typedef typename Container::size_type             size_type;
9558       typedef          Container                        container_type;
9559     protected:
9560       Container c;
9561
9562     public:
9563       explicit stack(const Container&amp; = Container());
9564
9565       bool      empty() const             { return c.empty(); }
9566       size_type size()  const             { return c.size(); }
9567       value_type&amp;       top()             { return c.back(); }
9568       const value_type&amp; top() const       { return c.back(); }
9569       void push(const value_type&amp; x)      { c.push_back(x); }
9570       void pop()                          { c.pop_back(); }
9571     };
9572
9573     template &lt;class T, class Container&gt;
9574       bool operator==(const stack&lt;T, Container&gt;&amp; x,
9575                       const stack&lt;T, Container&gt;&amp; y);
9576     template &lt;class T, class Container&gt;
9577       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
9578                       const stack&lt;T, Container&gt;&amp; y);
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&gt; (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&gt;=(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&lt;=(const stack&lt;T, Container&gt;&amp; x,
9590                       const stack&lt;T, Container&gt;&amp; y);
9591   }
9592 </pre>
9593
9594 <p>to:</p>
9595
9596 <pre>  namespace std {
9597     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9598     class stack {
9599     public:
9600       typedef typename Container::value_type            value_type;
9601       typedef typename Container::reference             reference;
9602       typedef typename Container::const_reference       const_reference;
9603       typedef typename Container::size_type             size_type;
9604       typedef          Container                        container_type;
9605     protected:
9606       Container c;
9607
9608     public:
9609       explicit stack(const Container&amp; = Container());
9610
9611       bool      empty() const             { return c.empty(); }
9612       size_type size()  const             { return c.size(); }
9613       reference         top()             { return c.back(); }
9614       const_reference   top() const       { return c.back(); }
9615       void push(const value_type&amp; x)      { c.push_back(x); }
9616       void pop()                          { c.pop_back(); }
9617     };
9618
9619     template &lt;class T, class Container&gt;
9620       bool operator==(const stack&lt;T, Container&gt;&amp; x,
9621                       const stack&lt;T, Container&gt;&amp; y);
9622     template &lt;class T, class Container&gt;
9623       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
9624                       const stack&lt;T, Container&gt;&amp; y);
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&gt; (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&gt;=(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&lt;=(const stack&lt;T, Container&gt;&amp; x,
9636                       const stack&lt;T, Container&gt;&amp; y);
9637   }
9638 </pre>
9639
9640 <p><i>[Copenhagen: This change was discussed before the IS was released
9641 and it was deliberately not adopted.  Nevertheless, the LWG believes
9642 (straw poll: 10-2) that it is a genuine defect.]</i></p>
9643
9644 <hr>
9645 <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>
9646 <p>
9647 Table 82 in section 27 mentions the header &lt;cstdlib&gt; for String
9648 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
9649 &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
9650 why these headers are mentioned in this context since they do not
9651 define any of the library entities described by the
9652 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
9653 are to be listed in the summary.
9654 </p>
9655 <p><b>Proposed resolution:</b></p>
9656 <p>Remove &lt;cstdlib&gt; and &lt;cwchar&gt; from
9657 Table 82.</p>
9658
9659 <p><i>[Copenhagen: changed the proposed resolution slightly.  The
9660 original proposed resolution also said to remove &lt;cstdio&gt; from
9661 Table 82.  However, &lt;cstdio&gt; is mentioned several times within
9662 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>
9663
9664 <hr>
9665 <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>
9666   <p>
9667   Exactly how should errno be declared in a conforming C++ header?
9668   </p>
9669
9670   <p>
9671   The C standard says in 7.1.4 that it is unspecified whether errno is a
9672   macro or an identifier with external linkage.  In some implementations
9673   it can be either, depending on compile-time options.  (E.g., on
9674   Solaris in multi-threading mode, errno is a macro that expands to a
9675   function call, but is an extern int otherwise.  "Unspecified" allows
9676   such variability.)
9677   </p>
9678
9679   <p>The C++ standard:</p>
9680   <ul>
9681   <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
9682   <li>17.4.3.1.3 footnote 166 says errno is reserved as an external
9683       name (true), and implies that it is an identifier.</li>
9684   <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
9685       on to say that the contents of of C++ &lt;errno.h&gt; are the
9686       same as in C, begging the question.</li>
9687   <li>C.2, table 95 lists errno as a macro, without comment.</li>
9688   </ul>
9689
9690   <p>I find no other references to errno.</p>
9691
9692   <p>We should either explicitly say that errno must be a macro, even
9693   though it need not be a macro in C, or else explicitly leave it
9694   unspecified.  We also need to say something about namespace std.
9695   A user who includes &lt;cerrno&gt; needs to know whether to write
9696   <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
9697   else &lt;cerrno&gt; is useless.</p>
9698
9699   <p>Two acceptable fixes:</p>
9700   <ul>
9701     <li><p>errno must be a macro. This is trivially satisfied by adding<br>
9702         &nbsp;&nbsp;#define errno (::std::errno)<br>
9703         to the headers if errno is not already a macro. You then always
9704         write errno without any scope qualification, and it always expands
9705         to a correct reference. Since it is always a macro, you know to
9706         avoid using errno as a local identifer.</p></li>
9707     <li><p>errno is in the global namespace. This fix is inferior, because
9708         ::errno is not guaranteed to be well-formed.</p></li>
9709   </ul>
9710
9711   <p><i>[
9712     This issue was first raised in 1999, but it slipped through
9713     the cracks.
9714   ]</i></p>
9715 <p><b>Proposed resolution:</b></p>
9716   <p>Change the Note in section 17.4.1.2p5 from</p>
9717
9718     <blockquote>
9719     Note: the names defined as macros in C include the following:
9720     assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
9721     </blockquote>
9722
9723   <p>to</p>
9724
9725     <blockquote>
9726     Note: the names defined as macros in C include the following:
9727     assert, offsetof, setjmp, va_arg, va_end, and va_start.
9728     </blockquote>
9729
9730   <p>In section 19.3, change paragraph 2 from</p>
9731
9732     <blockquote>
9733     The contents are the same as the Standard C library header
9734     &lt;errno.h&gt;.
9735     </blockquote>
9736
9737   <p>to</p>
9738
9739     <blockquote>
9740     The contents are the same as the Standard C library header
9741     &lt;errno.h&gt;, except that errno shall be defined as a macro.
9742     </blockquote>
9743 <p><b>Rationale:</b></p>
9744 <p>C++ must not leave it up to the implementation to decide whether or
9745 not a name is a macro; it must explicitly specify exactly which names
9746 are required to be macros.  The only one that really works is for it
9747 to be a macro.</p>
9748
9749 <p><i>[Curaçao: additional rationale added.]</i></p>
9750
9751 <hr>
9752 <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>
9753
9754 <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>
9755
9756 <pre>  // partial specializationss
9757   template&lt;class traits&gt;
9758     basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;( basic_ostream&lt;char,traits&gt;&amp;,
9759                                             const char * );
9760 </pre>
9761
9762 <p>Problems:</p>
9763 <ul>
9764 <li>Too many 's's at the end of "specializationss" </li>
9765 <li>This is an overload, not a partial specialization</li>
9766 </ul>
9767
9768 <p><b>Proposed resolution:</b></p>
9769 <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
9770 <i>// partial specializationss</i> comment.  Also remove the same
9771 comment (correctly spelled, but still incorrect) from the synopsis in
9772 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>.
9773 </p>
9774
9775 <p><i>[
9776 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
9777 comment in c++std-lib-8939.
9778 ]</i></p>
9779
9780 <hr>
9781 <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>
9782 <p>Table 27 in section 20 lists the header &lt;memory&gt; (only) for
9783 Memory (lib.memory) but neglects to mention the headers
9784 &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>
9785 <p><b>Proposed resolution:</b></p>
9786 <p>Add &lt;cstdlib&gt; and &lt;cstring&gt; to Table 27, in the same row
9787 as &lt;memory&gt;.</p>
9788 <hr>
9789 <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>
9790 <p>
9791 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
9792 list::unique as: "If the range (last - first) is not empty, exactly
9793 (last - first) -1 applications of the corresponding predicate,
9794 otherwise no applications of the predicate)".
9795 </p>
9796
9797 <p>
9798 "(last - first)" is not a range.
9799 </p>
9800 <p><b>Proposed resolution:</b></p>
9801 <p>
9802 Change the "range" from (last - first) to [first, last).
9803 </p>
9804 <hr>
9805 <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>
9806 <p>Table 69 says this about a_uniq.insert(t):</p>
9807
9808 <blockquote>
9809 inserts t if and only if there is no element in the container with key
9810 equivalent to the key of t. The bool component of the returned pair
9811 indicates whether the insertion takes place and the iterator component of the
9812 pair points to the element with key equivalent to the key of t.
9813 </blockquote>
9814
9815 <p>The description should be more specific about exactly how the bool component
9816 indicates whether the insertion takes place.</p>
9817 <p><b>Proposed resolution:</b></p>
9818 <p>Change the text in question to</p>
9819
9820 <blockquote>
9821 ...The bool component of the returned pair is true if and only if the insertion
9822 takes place...
9823 </blockquote>
9824 <hr>
9825 <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>
9826 <p>
9827 The localization section of the standard refers to specializations of
9828 the facet templates as instantiations even though the required facets
9829 are typically specialized rather than explicitly (or implicitly)
9830 instantiated. In the case of ctype&lt;char&gt; and
9831 ctype_byname&lt;char&gt; (and the wchar_t versions), these facets are
9832 actually required to be specialized. The terminology should be
9833 corrected to make it clear that the standard doesn't mandate explicit
9834 instantiation (the term specialization encompasses both explicit
9835 instantiations and specializations).
9836 </p>
9837 <p><b>Proposed resolution:</b></p>
9838 <p>
9839 In the following paragraphs, replace all occurrences of the word
9840 instantiation or instantiations with specialization or specializations,
9841 respectively:
9842 </p>
9843
9844 <blockquote>
9845 22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
9846 22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3,
9847 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
9848 Footnote 242.
9849 </blockquote>
9850
9851 <p>And change the text in 22.1.1.1.1, p4 from</p>
9852
9853 <blockquote>
9854     An implementation is required to provide those instantiations
9855     for facet templates identified as members of a category, and
9856     for those shown in Table 52:
9857 </blockquote>
9858
9859 <p>to</p>
9860
9861 <blockquote>
9862     An implementation is required to provide those specializations...
9863 </blockquote>
9864
9865 <p><i>[Nathan will review these changes, and will look for places where
9866 explicit specialization is necessary.]</i></p>
9867
9868 <p><b>Rationale:</b></p>
9869 <p>This is a simple matter of outdated language.  The language to
9870 describe templates was clarified during the standardization process,
9871 but the wording in clause 22 was never updated to reflect that
9872 change.</p>
9873 <hr>
9874 <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>
9875 <p>The definition of the numpunct_byname template contains the following
9876 comment:</p>
9877
9878 <pre>    namespace std {
9879         template &lt;class charT&gt;
9880         class numpunct_byname : public numpunct&lt;charT&gt; {
9881     // this class is specialized for char and wchar_t.
9882         ...
9883 </pre>
9884
9885 <p>There is no documentation of the specializations and it seems
9886 conceivable that an implementation will not explicitly specialize the
9887 template at all, but simply provide the primary template.</p>
9888 <p><b>Proposed resolution:</b></p>
9889 <p>Remove the comment from the text in 22.2.3.2 and from the proposed
9890 resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
9891 <hr>
9892 <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>
9893 <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
9894 behavior" elements describe "the semantics of a function definition
9895 provided by either the implementation or a C++ program."</p>
9896
9897 <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"
9898 elements describe "the preconditions for calling the function."</p>
9899
9900 <p>In the sections noted below, the current wording specifies
9901 "Required Behavior" for what are actually preconditions, and thus
9902 should be specified as "Requires".</p>
9903
9904 <p><b>Proposed resolution:</b></p>
9905
9906 <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>
9907 <blockquote>
9908   <p>Required behavior: accept a value of ptr that is null or that was
9909   returned by an earlier call ...</p>
9910 </blockquote>
9911 <p>to:</p>
9912 <blockquote>
9913   <p>Requires: the value of ptr is null or the value returned by an
9914   earlier call ...</p>
9915 </blockquote>
9916
9917 <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>
9918 <blockquote>
9919   <p>Required behavior: accept a value of ptr that is null or that was
9920   returned by an earlier call ...</p>
9921 </blockquote>
9922 <p>to:</p>
9923 <blockquote>
9924   <p>Requires: the value of ptr is null or the value returned by an
9925   earlier call ...</p>
9926 </blockquote>
9927
9928 <hr>
9929 <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>
9930 <p>
9931 Section 23.2.2.1, paragraphs 6-8 specify that list assign (both forms) have
9932 the "effects" of a call to erase followed by a call to insert.
9933 </p>
9934
9935 <p>
9936 I would like to document that implementers have the freedom to implement
9937 assign by other methods, as long as the end result is the same and the
9938 exception guarantee is as good or better than the basic guarantee.
9939 </p>
9940
9941 <p>
9942 The motivation for this is to use T's assignment operator to recycle
9943 existing nodes in the list instead of erasing them and reallocating
9944 them with new values.  It is also worth noting that, with careful
9945 coding, most common cases of assign (everything but assignment with
9946 true input iterators) can elevate the exception safety to strong if
9947 T's assignment has a nothrow guarantee (with no extra memory cost).
9948 Metrowerks does this.  However I do not propose that this subtlety be
9949 standardized.  It is a QoI issue.  </p>
9950
9951 <p>Existing practise:
9952 Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
9953 </p>
9954 <p><b>Proposed resolution:</b></p>
9955 <p>Change 23.2.2.1/7 from:</p>
9956
9957 <blockquote>
9958 <p>Effects:</p>
9959
9960 <pre>   erase(begin(), end());
9961    insert(begin(), first, last);
9962 </pre>
9963 </blockquote>
9964
9965 <p>to:</p>
9966
9967 <blockquote>
9968 <p>Effects: Replaces the contents of the list with the range [first, last).</p>
9969 </blockquote>
9970
9971 <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),
9972 add two new rows:</p>
9973 <pre>      a.assign(i,j)     void      pre: i,j are not iterators into a.
9974                                   Replaces elements in a with a copy
9975                                   of [i, j).
9976
9977       a.assign(n,t)     void      pre: t is not a reference into a.
9978                                   Replaces elements in a with n copies
9979                                   of t.
9980 </pre>
9981
9982 <p>Change 23.2.2.1/8 from:</p>
9983
9984 <blockquote>
9985 <p>Effects:</p>
9986 <pre>   erase(begin(), end());
9987    insert(begin(), n, t);
9988 </pre>
9989 </blockquote>
9990 <p>to:</p>
9991
9992 <blockquote>
9993 <p>Effects: Replaces the contents of the list with n copies of t.</p>
9994 </blockquote>
9995
9996 <p><i>[Redmond: Proposed resolution was changed slightly.  Previous
9997 version made explicit statement about exception safety, which wasn't
9998 consistent with the way exception safety is expressed elsewhere.
9999 Also, the change in the sequence requirements is new.  Without that
10000 change, the proposed resolution would have required that assignment of
10001 a subrange would have to work.  That too would have been
10002 overspecification; it would effectively mandate that assignment use a
10003 temporary.  Howard provided wording.
10004 ]</i></p>
10005
10006 <p><i>[Curaçao: Made editorial improvement in wording; changed
10007 "Replaces elements in a with copies of elements in [i, j)."
10008 with "Replaces the elements of a with a copy of [i, j)."
10009 Changes not deemed serious enough to requre rereview.]</i></p>
10010
10011 <hr>
10012 <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>
10013 <p>
10014 Section 22.2.2.1.2 at p7 states that "A length specifier is added to
10015 the conversion function, if needed, as indicated in Table 56."
10016 However, Table 56 uses the term "length modifier", not "length
10017 specifier".
10018 </p>
10019 <p><b>Proposed resolution:</b></p>
10020 <p>
10021 In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
10022 to be "A length modifier is added ..."
10023 </p>
10024 <p><b>Rationale:</b></p>
10025 <p>C uses the term "length modifier".  We should be consistent.</p>
10026 <hr>
10027 <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>
10028 <p>
10029 It's widely assumed that, if X is a container,
10030 iterator_traits&lt;X::iterator&gt;::value_type and
10031 iterator_traits&lt;X::const_iterator&gt;::value_type should both be
10032 X::value_type.  However, this is nowhere stated.  The language in
10033 Table 65 is not precise about the iterators' value types (it predates
10034 iterator_traits), and could even be interpreted as saying that
10035 iterator_traits&lt;X::const_iterator&gt;::value_type should be "const
10036 X::value_type".
10037 </p>
10038
10039 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a>.</p>
10040 <p><b>Proposed resolution:</b></p>
10041 <p>In Table 65 ("Container Requirements"), change the return type for
10042 X::iterator to "iterator type whose value type is T".  Change the
10043 return type for X::const_iterator to "constant iterator type whose
10044 value type is T".</p>
10045 <p><b>Rationale:</b></p>
10046 <p>
10047 This belongs as a container requirement, rather than an iterator
10048 requirement, because the whole notion of iterator/const_iterator
10049 pairs is specific to containers' iterator.
10050 </p>
10051 <p>
10052 It is existing practice that (for example)
10053 iterator_traits&lt;list&lt;int&gt;::const_iterator&gt;::value_type
10054 is "int", rather than "const int".  This is consistent with
10055 the way that const pointers are handled: the standard already
10056 requires that iterator_traits&lt;const int*&gt;::value_type is int.
10057 </p>
10058 <hr>
10059 <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>
10060
10061 <p>Table 73 suggests that output iterators have value types.  It
10062 requires the expression "*a = t".  Additionally, although Table 73
10063 never lists "a = t" or "X(a) = t" in the "expressions" column, it
10064 contains a note saying that "a = t" and "X(a) = t" have equivalent
10065 (but nowhere specified!) semantics.</p>
10066
10067 <p>According to 24.1/9, t is supposed to be "a value of value type
10068 T":</p>
10069
10070     <blockquote>
10071     In the following sections, a and b denote values of X, n denotes a
10072     value of the difference type Distance, u, tmp, and m denote
10073     identifiers, r denotes a value of X&amp;, t denotes a value of
10074     value type T.
10075     </blockquote>
10076
10077 <p>Two other parts of the standard that are relevant to whether
10078 output iterators have value types:</p>
10079
10080 <ul>
10081     <li>24.1/1 says "All iterators i support the expression *i,
10082     resulting in a value of some class, enumeration, or built-in type
10083     T, called the value type of the iterator".</li>
10084
10085     <li>
10086     24.3.1/1, which says "In the case of an output iterator, the types
10087     iterator_traits&lt;Iterator&gt;::difference_type
10088     iterator_traits&lt;Iterator&gt;::value_type are both defined as void."
10089     </li>
10090 </ul>
10091
10092 <p>The first of these passages suggests that "*i" is supposed to
10093 return a useful value, which contradicts the note in 24.1.2/2 saying
10094 that the only valid use of "*i" for output iterators is in an
10095 expression of the form "*i = t".  The second of these passages appears
10096 to contradict Table 73, because it suggests that "*i"'s return value
10097 should be void.  The second passage is also broken in the case of a an
10098 iterator type, like non-const pointers, that satisfies both the output
10099 iterator requirements and the forward iterator requirements.</p>
10100
10101 <p>What should the standard say about <tt>*i</tt>'s return value when
10102 i is an output iterator, and what should it say about that t is in the
10103 expression "*i = t"?  Finally, should the standard say anything about
10104 output iterators' pointer and reference types?</p>
10105
10106 <p><b>Proposed resolution:</b></p>
10107 <p>24.1 p1, change</p>
10108
10109 <blockquote>
10110 <p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
10111 in a value of some class, enumeration, or built-in type <tt>T</tt>,
10112 called the value type of the iterator.</p>
10113 </blockquote>
10114
10115 <p>to</p>
10116
10117 <blockquote>
10118 <p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
10119 resulting in a value of some class, enumeration, or built-in type
10120 <tt>T</tt>, called the value type of the iterator. All output
10121 iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
10122 value of some type that is in the set of types that are <i>writable</i> to
10123 the particular iterator type of <tt>i</tt>.
10124 </p>
10125 </blockquote>
10126
10127 <p>24.1 p9, add</p>
10128
10129 <blockquote>
10130 <p><tt>o</tt> denotes a value of some type that is writable to the
10131 output iterator.
10132 </p>
10133 </blockquote>
10134
10135 <p>Table 73, change</p>
10136
10137 <blockquote>
10138 <pre>*a = t
10139 </pre>
10140 </blockquote>
10141
10142 <p>to</p>
10143
10144 <blockquote>
10145 <pre>*r = o
10146 </pre>
10147 </blockquote>
10148
10149 <p>and change</p>
10150
10151 <blockquote>
10152 <pre>*r++ = t
10153 </pre>
10154 </blockquote>
10155
10156 <p>to</p>
10157
10158 <blockquote>
10159 <pre>*r++ = o
10160 </pre>
10161 </blockquote>
10162
10163 <p><i>[post-Redmond: Jeremy provided wording]</i></p>
10164
10165 <p><b>Rationale:</b></p>
10166 <p>The LWG considered two options: change all of the language that
10167 seems to imply that output iterators have value types, thus making it
10168 clear that output iterators have no value types, or else define value
10169 types for output iterator consistently.  The LWG chose the former
10170 option, because it seems clear that output iterators were never
10171 intended to have value types.  This was a deliberate design decision,
10172 and any language suggesting otherwise is simply a mistake.</p>
10173
10174 <p>A future revision of the standard may wish to revisit this design
10175 decision.</p>
10176 <hr>
10177 <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>
10178 <p>The Returns clause in 22.2.6.3.2, p3 says about
10179 moneypunct&lt;charT&gt;::do_grouping()
10180 </p>
10181
10182 <blockquote>
10183     Returns: A pattern defined identically as the result of
10184     numpunct&lt;charT&gt;::do_grouping().241)
10185 </blockquote>
10186
10187 <p>Footnote 241 then reads</p>
10188
10189 <blockquote>
10190     This is most commonly the value "\003" (not "3").
10191 </blockquote>
10192
10193 <p>
10194 The returns clause seems to imply that the two member functions must
10195 return an identical value which in reality may or may not be true,
10196 since the facets are usually implemented in terms of struct std::lconv
10197 and return the value of the grouping and mon_grouping, respectively.
10198 The footnote also implies that the member function of the moneypunct
10199 facet (rather than the overridden virtual functions in moneypunct_byname)
10200 most commonly return "\003", which contradicts the C standard which
10201 specifies the value of "" for the (most common) C locale.
10202 </p>
10203
10204 <p><b>Proposed resolution:</b></p>
10205 <p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>
10206
10207 <blockquote>
10208     Returns: A pattern defined identically as, but not necessarily
10209     equal to, the result of numpunct&lt;charT&gt;::do_grouping().241)
10210 </blockquote>
10211
10212 <p>and replace the text in Footnote 241 with the following:</p>
10213
10214 <blockquote>
10215     To specify grouping by 3s the value is "\003", not "3".
10216 </blockquote>
10217 <p><b>Rationale:</b></p>
10218 <p>
10219 The fundamental problem is that the description of the locale facet
10220 virtuals serves two purposes: describing the behavior of the base
10221 class, and describing the meaning of and constraints on the behavior
10222 in arbitrary derived classes.  The new wording makes that separation a
10223 little bit clearer.  The footnote (which is nonnormative) is not
10224 supposed to say what the grouping is in the "C" locale or in any other
10225 locale. It is just a reminder that the values are interpreted as small
10226 integers, not ASCII characters.
10227 </p>
10228 <hr>
10229 <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>
10230 <p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
10231 <tt>time_get_byname</tt> are listed incorrectly in table 52,
10232 required instantiations.  In both cases the second template
10233 parameter is given as OutputIterator.  It should instead be
10234 InputIterator, since these are input facets.</p>
10235 <p><b>Proposed resolution:</b></p>
10236 <p>
10237 In table 52, required instantiations, in
10238 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>
10239 <pre>    time_get&lt;wchar_t, OutputIterator&gt;
10240     time_get_byname&lt;wchar_t, OutputIterator&gt;
10241 </pre>
10242 <p>to</p>
10243 <pre>    time_get&lt;wchar_t, InputIterator&gt;
10244     time_get_byname&lt;wchar_t, InputIterator&gt;
10245 </pre>
10246
10247 <p><i>[Redmond: Very minor change in proposed resolution.  Original had
10248 a typo, wchart instead of wchar_t.]</i></p>
10249
10250 <hr>
10251 <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>
10252 <p>The sprintf format string , "%.01f" (that's the digit one), in the
10253 description of the do_put() member functions of the money_put facet in
10254 22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
10255 for values of type long double, and second, the precision of 01
10256 doesn't seem to make sense. What was most likely intended was
10257 "%.0Lf"., that is a precision of zero followed by the L length
10258 modifier.</p>
10259 <p><b>Proposed resolution:</b></p>
10260 <p>Change the format string to "%.0Lf".</p>
10261 <p><b>Rationale:</b></p>
10262 <p>Fixes an obvious typo</p>
10263 <hr>
10264 <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>
10265 <p>
10266 There is an apparent contradiction about which circumstances can cause
10267 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
10268 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>.
10269 </p>
10270
10271 <p>23.2.4.2p5 says:</p>
10272 <blockquote>
10273 Notes: Reallocation invalidates all the references, pointers, and iterators
10274 referring to the elements in the sequence. It is guaranteed that no
10275 reallocation takes place during insertions that happen after a call to
10276 reserve() until the time when an insertion would make the size of the vector
10277 greater than the size specified in the most recent call to reserve().
10278 </blockquote>
10279
10280 <p>Which implies if I do</p>
10281
10282 <pre>  std::vector&lt;int&gt; vec;
10283   vec.reserve(23);
10284   vec.reserve(0);
10285   vec.insert(vec.end(),1);
10286 </pre>
10287
10288 <p>then the implementation may reallocate the vector for the insert,
10289 as the size specified in the previous call to reserve was zero.</p>
10290
10291 <p>However, the previous paragraphs (23.2.4.2, p1-2) state:</p>
10292 <blockquote>
10293 <p>
10294 (capacity) Returns: The total number of elements the vector
10295 can hold without requiring reallocation
10296 </p>
10297 <p>
10298 ...After reserve(), capacity() is greater or equal to the
10299 argument of reserve if reallocation happens; and equal to the previous value
10300 of capacity() otherwise...
10301 </p>
10302 </blockquote>
10303
10304 <p>
10305 This implies that vec.capacity() is still 23, and so the insert()
10306 should not require a reallocation, as vec.size() is 0. This is backed
10307 up by 23.2.4.3p1:
10308 </p>
10309 <blockquote>
10310 (insert) Notes: Causes reallocation if the new size is greater than the old
10311 capacity.
10312 </blockquote>
10313
10314 <p>
10315 Though this doesn't rule out reallocation if the new size is less
10316 than the old capacity, I think the intent is clear.
10317 </p>
10318
10319 <p><b>Proposed resolution:</b></p>
10320 <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>
10321
10322 <blockquote>
10323 Notes: Reallocation invalidates all the references, pointers, and
10324 iterators referring to the elements in the sequence. It is guaranteed
10325 that no reallocation takes place during insertions that happen after a
10326 call to reserve() until the time when an insertion would make the size
10327 of the vector greater than the value of capacity().
10328 </blockquote>
10329
10330 <p><i>[Redmond: original proposed resolution was modified slightly.  In
10331 the original, the guarantee was that there would be no reallocation
10332 until the size would be greater than the value of capacity() after the
10333 most recent call to reserve().  The LWG did not believe that the
10334 "after the most recent call to reserve()" added any useful
10335 information.]</i></p>
10336
10337 <p><b>Rationale:</b></p>
10338 <p>There was general agreement that, when reserve() is called twice in
10339 succession and the argument to the second invocation is smaller than
10340 the argument to the first, the intent was for the second invocation to
10341 have no effect.  Wording implying that such cases have an effect on
10342 reallocation guarantees was inadvertant.</p>
10343 <hr>
10344 <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>
10345 <p>
10346 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
10347    "An implementation may strengthen the exception-specification for a
10348     non-virtual function by removing listed exceptions."
10349 (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>)
10350 and the following declaration of ~failure() in ios_base::failure
10351 </p>
10352 <pre>    namespace std {
10353        class ios_base::failure : public exception {
10354        public:
10355            ...
10356            virtual ~failure();
10357            ...
10358        };
10359      }
10360 </pre>
10361 <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
10362 exception specification:</p>
10363 <pre>    namespace std {
10364        class exception {
10365        public:
10366          ...
10367          virtual ~exception() throw();
10368          ...
10369        };
10370      }
10371 </pre>
10372 <p><b>Proposed resolution:</b></p>
10373 <p>Remove the declaration of ~failure().</p>
10374 <p><b>Rationale:</b></p>
10375 <p>The proposed resolution is consistent with the way that destructors
10376 of other classes derived from <tt>exception</tt> are handled.</p>
10377 <hr>
10378 <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>
10379 <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>
10380 <blockquote>
10381     [Footnote: The effect of executing cout &lt;&lt; endl is to insert a
10382      newline character in the output sequence controlled by cout, then
10383      synchronize it with any external file with which it might be
10384      associated. --- end foonote]
10385 </blockquote>
10386
10387 <p>
10388 Does the term "file" here refer to the external device?
10389 This leads to some implementation ambiguity on systems with fully
10390 buffered files where a newline does not cause a flush to the device.
10391 </p>
10392
10393 <p>
10394 Choosing to sync with the device leads to significant performance
10395 penalties for each call to endl, while not sync-ing leads to
10396 errors under special circumstances.
10397 </p>
10398
10399 <p>
10400 I could not find any other statement that explicitly defined
10401 the behavior one way or the other.
10402 </p>
10403 <p><b>Proposed resolution:</b></p>
10404 <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>
10405 <p><b>Rationale:</b></p>
10406 <p>We already have normative text saying what <tt>endl</tt> does: it
10407 inserts a newline character and calls <tt>flush</tt>.  This footnote
10408 is at best redundant, at worst (as this issue says) misleading,
10409 because it appears to make promises about what <tt>flush</tt>
10410 does.</p>
10411 <hr>
10412 <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>
10413 <p>
10414 The current standard describes map::operator[] using a
10415 code example. That code example is however quite
10416 inefficient because it requires several useless copies
10417 of both the passed key_type value and of default
10418 constructed mapped_type instances.
10419 My opinion is that was not meant by the comitee to
10420 require all those temporary copies.
10421 </p>
10422
10423 <p>Currently map::operator[] behaviour is specified as: </p>
10424 <pre>  Returns:
10425     (*((insert(make_pair(x, T()))).first)).second.
10426 </pre>
10427
10428 <p>
10429 This specification however uses make_pair that is a
10430 template function of which parameters in this case
10431 will be deduced being of type const key_type&amp; and
10432 const T&amp;. This will create a pair&lt;key_type,T&gt; that
10433 isn't the correct type expected by map::insert so
10434 another copy will be required using the template
10435 conversion constructor available in pair to build
10436 the required pair&lt;const key_type,T&gt; instance.
10437 </p>
10438
10439 <p>If we consider calling of key_type copy constructor
10440 and mapped_type default constructor and copy
10441 constructor as observable behaviour (as I think we
10442 should) then the standard is in this place requiring
10443 two copies of a key_type element plus a default
10444 construction and two copy construction of a mapped_type
10445 (supposing the addressed element is already present
10446 in the map; otherwise at least another copy
10447 construction for each type).
10448 </p>
10449
10450 <p>A simple (half) solution would be replacing the description with:</p>
10451 <pre>  Returns:
10452     (*((insert(value_type(x, T()))).first)).second.
10453 </pre>
10454
10455 <p>This will remove the wrong typed pair construction that
10456 requires one extra copy of both key and value.</p>
10457
10458 <p>However still the using of map::insert requires temporary
10459 objects while the operation, from a logical point of view,
10460 doesn't require any. </p>
10461
10462 <p>I think that a better solution would be leaving free an
10463 implementer to use a different approach than map::insert
10464 that, because of its interface, forces default constructed
10465 temporaries and copies in this case.
10466 The best solution in my opinion would be just requiring
10467 map::operator[] to return a reference to the mapped_type
10468 part of the contained element creating a default element
10469 with the specified key if no such an element is already
10470 present in the container. Also a logarithmic complexity
10471 requirement should be specified for the operation.
10472 </p>
10473
10474 <p>
10475 This would allow library implementers to write alternative
10476 implementations not using map::insert and reaching optimal
10477 performance in both cases of the addressed element being
10478 present or absent from the map (no temporaries at all and
10479 just the creation of a new pair inside the container if
10480 the element isn't present).
10481 Some implementer has already taken this option but I think
10482 that the current wording of the standard rules that as
10483 non-conforming.
10484 </p>
10485
10486 <p><b>Proposed resolution:</b></p>
10487
10488 <p>
10489 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
10490 </p>
10491 <blockquote>
10492 <p>
10493 -1- Effects:  If there is no key equivalent to x in the map, inserts
10494 value_type(x, T()) into the map.
10495 </p>
10496 <p>
10497 -2- Returns: A reference to the mapped_type corresponding to x in *this.
10498 </p>
10499 <p>
10500 -3- Complexity: logarithmic.
10501 </p>
10502 </blockquote>
10503
10504 <p><i>[This is the second option mentioned above.  Howard provided
10505 wording.  We may also wish to have a blanket statement somewhere in
10506 clause 17 saying that we do not intend the semantics of sample code
10507 fragments to be interpreted as specifing exactly how many copies are
10508 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>
10509
10510 <p><b>Rationale:</b></p>
10511 <p>
10512 This is the second solution described above; as noted, it is
10513 consistent with existing practice.
10514 </p>
10515
10516 <p>Note that we now need to specify the complexity explicitly, because
10517 we are no longer defining <tt>operator[]</tt> in terms of
10518 <tt>insert</tt>.</p>
10519 <hr>
10520 <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>
10521 <p>
10522 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
10523 as:
10524 </p>
10525 <pre>  X::assign(c,d)   assigns c = d.
10526 </pre>
10527
10528 <p>And para 1 says:</p>
10529
10530 <blockquote>
10531  [...] c and d denote values of type CharT [...]
10532 </blockquote>
10533
10534 <p>
10535 Naturally, if c and d are <i>values</i>, then the assignment is
10536 (effectively) meaningless. It's clearly intended that (in the case of
10537 assign, at least), 'c' is intended to be a reference type.
10538 </p>
10539
10540 <p>I did a quick survey of the four implementations I happened to have
10541 lying around, and sure enough they all have signatures:</p>
10542 <pre>    assign( charT&amp;, const charT&amp; );
10543 </pre>
10544
10545 <p>(or the equivalent). It's also described this way in Nico's book.
10546 (Not to mention the synopses of char_traits&lt;char&gt; in 21.1.3.1
10547 and char_traits&lt;wchar_t&gt; in 21.1.3.2...)
10548 </p>
10549 <p><b>Proposed resolution:</b></p>
10550 <p>Add the following to 21.1.1 para 1:</p>
10551 <blockquote>
10552  r denotes an lvalue of CharT
10553 </blockquote>
10554
10555 <p>and change the description of assign in the table to:</p>
10556 <pre>  X::assign(r,d)   assigns r = d
10557 </pre>
10558 <hr>
10559 <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>
10560 <p>From c++std-edit-873:</p>
10561
10562 <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
10563 &lt;strstream&gt; is missing.</p>
10564
10565 <p>This shows a general problem: The whole clause 17 refers quite
10566 often to clauses 18 through 27, but D.7 is also a part of the standard
10567 library (though a deprecated one).</p>
10568
10569 <p><b>Proposed resolution:</b></p>
10570
10571 <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
10572 "&lt;strstream&gt;".</p>
10573
10574 <p>In the following places, change "clauses 17 through 27" to "clauses
10575 17 through 27 and Annex D":</p>
10576
10577 <ul>
10578 <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>
10579 <li>1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/intro.html#intro.defs"> [intro.defs]</a> Definitions/1</li>
10580 <li>7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/dcl.html#dcl.dcl"> [dcl.dcl]</a> Library introduction/9</li>
10581 <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>
10582 <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>
10583 <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>
10584 <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>
10585 <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>
10586 <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>
10587 <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>
10588 <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>
10589 <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>
10590 </ul>
10591
10592
10593 <hr>
10594 <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>
10595 <p>From c++std-edit-876:</p>
10596
10597 <p>
10598 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
10599 parameter of template replace_copy_if should be "InputIterator"
10600 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
10601 parameter name conveys real normative meaning.
10602 </p>
10603 <p><b>Proposed resolution:</b></p>
10604 <p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
10605 <hr>
10606 <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>
10607 <p>
10608 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
10609 original text or the text corrected by the proposed resolution of
10610 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
10611 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
10612 format for integer and floating point values, says that whitespace is
10613 optional between a plusminus and a sign.
10614 </p>
10615
10616 <p>
10617 The text needs to be clarified to either consistently allow or
10618 disallow whitespace between a plusminus and a sign. It might be
10619 worthwhile to consider the fact that the C library stdio facility does
10620 not permit whitespace embedded in numbers and neither does the C or
10621 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).
10622 </p>
10623 <p><b>Proposed resolution:</b></p>
10624 <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>
10625 <blockquote>
10626 <p>
10627 The syntax for number formats is as follows, where <tt>digit</tt>
10628 represents the radix set specified by the <tt>fmtflags</tt> argument
10629 value, <tt>whitespace</tt> is as determined by the facet
10630 <tt>ctype&lt;charT&gt;</tt> (22.2.1.1), and <tt>thousands-sep</tt> and
10631 <tt>decimal-point</tt> are the results of corresponding
10632 <tt>numpunct&lt;charT&gt;</tt> members.  Integer values have the
10633 format:
10634 </p>
10635 <pre>  integer   ::= [sign] units
10636   sign      ::= plusminus [whitespace]
10637   plusminus ::= '+' | '-'
10638   units     ::= digits [thousands-sep units]
10639   digits    ::= digit [digits]
10640 </pre>
10641 </blockquote>
10642 <p>to:</p>
10643 <blockquote>
10644 <p>
10645 The syntax for number formats is as follows, where <tt>digit</tt>
10646 represents the radix set specified by the <tt>fmtflags</tt> argument
10647 value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
10648 results of corresponding <tt>numpunct&lt;charT&gt;</tt> members.
10649 Integer values have the format:
10650 </p>
10651 <pre>  integer   ::= [sign] units
10652   sign      ::= plusminus
10653   plusminus ::= '+' | '-'
10654   units     ::= digits [thousands-sep units]
10655   digits    ::= digit [digits]
10656 </pre>
10657 </blockquote>
10658 <p><b>Rationale:</b></p>
10659 <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
10660 standard says how, or whether, it's used.  However, there's no reason
10661 for it to differ gratuitously from the very specific description of
10662 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
10663 resolution removes all mention of "whitespace" from that format.</p>
10664 <hr>
10665 <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>
10666 <p>
10667 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
10668 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
10669 clause 27, making the reference in 22.2.1 somewhat dubious.
10670 </p>
10671 <p><b>Proposed resolution:</b></p>
10672 <p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
10673     <blockquote>
10674     Several types defined in clause 27 are bitmask types. Each bitmask type
10675     can be implemented as an enumerated type that overloads certain operators,
10676     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>).
10677     </blockquote>
10678 <p>to read</p>
10679     <blockquote>
10680     Several types defined in clauses lib.language.support through
10681     lib.input.output and Annex D are bitmask types. Each bitmask type can
10682     be implemented as an enumerated type that overloads certain operators,
10683     as an integer  type, or as a bitset (lib.template.bitset).
10684     </blockquote>
10685
10686 <p>
10687 Additionally, change the definition in 22.2.1 to adopt the same
10688 convention as in clause 27 by replacing the existing text with the
10689 following (note, in particluar, the cross-reference to 17.3.2.1.2 in
10690 22.2.1, p1):
10691 </p>
10692
10693 <blockquote>
10694 <p>22.2.1 The ctype category [lib.category.ctype]</p>
10695 <pre>namespace std {
10696     class ctype_base {
10697     public:
10698         typedef <b><i>T</i></b> mask;
10699
10700         // numeric values are for exposition only.
10701         static const mask space = 1 &lt;&lt; 0;
10702         static const mask print = 1 &lt;&lt; 1;
10703         static const mask cntrl = 1 &lt;&lt; 2;
10704         static const mask upper = 1 &lt;&lt; 3;
10705         static const mask lower = 1 &lt;&lt; 4;
10706         static const mask alpha = 1 &lt;&lt; 5;
10707         static const mask digit = 1 &lt;&lt; 6;
10708         static const mask punct = 1 &lt;&lt; 7;
10709         static const mask xdigit = 1 &lt;&lt; 8;
10710         static const mask alnum = alpha | digit;
10711         static const mask graph = alnum | punct;
10712     };
10713 }
10714 </pre>
10715
10716 <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>
10717 </blockquote>
10718
10719 <p><i>[Curaçao: The LWG notes that T above should be bold-italics to be
10720 consistent with the rest of the standard.]</i></p>
10721
10722 <hr>
10723 <a name="340"><h3>340.&nbsp;interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt>
10724 </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>
10725 <p>
10726 It's unclear whether 22.1.1.1.1, p3 says that
10727 <tt>has_facet&lt;Facet&gt;(loc)</tt> returns true for any <tt>Facet</tt>
10728 from Table 51 or whether it includes Table 52 as well:
10729 </p>
10730
10731 <blockquote>
10732 For any locale <tt>loc</tt> either constructed, or returned by
10733 locale::classic(), and any facet <tt>Facet</tt> that is a member of a
10734 standard category, <tt>has_facet&lt;Facet&gt;(loc)</tt> is true. Each
10735 locale member function which takes a <tt>locale::category</tt>
10736 argument operates on the corresponding set of facets.
10737 </blockquote>
10738
10739 <p>
10740 It seems that it comes down to which facets are considered to be members of a
10741 standard category. Intuitively, I would classify all the facets in Table 52 as
10742 members of their respective standard categories, but there are an unbounded set
10743 of them...
10744 </p>
10745
10746 <p>
10747 The paragraph implies that, for instance, <tt>has_facet&lt;num_put&lt;C,
10748 OutputIterator&gt; &gt;(loc)</tt> must always return true. I don't think that's
10749 possible. If it were, then <tt>use_facet&lt;num_put&lt;C, OutputIterator&gt;
10750 &gt;(loc)</tt> would have to return a reference to a distinct object for each
10751 valid specialization of <tt>num_put&lt;C, OutputIteratory&gt;</tt>, which is
10752 clearly impossible.
10753 </p>
10754
10755 <p>
10756 On the other hand, if none of the facets in Table 52 is a member of a standard
10757 category then none of the locale member functions that operate on entire
10758 categories of facets will work properly.
10759 </p>
10760
10761 <p>
10762 It seems that what p3 should mention that it's required (permitted?)
10763 to hold only for specializations of <tt>Facet</tt> from Table 52 on
10764 <tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
10765 <tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
10766 {
10767 {i,o}<tt>streambuf_iterator</tt>&lt;{<tt>char</tt>,<tt>wchar_t</tt>}<tt>&gt;</tt>
10768 }.
10769 </p>
10770 <p><b>Proposed resolution:</b></p>
10771 <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
10772 "that is a member of a standard category" to "shown in Table 51".</p>
10773 <p><b>Rationale:</b></p>
10774 <p>The facets in Table 52 are an unbounded set.  Locales should not be
10775 required to contain an infinite number of facets.</p>
10776
10777 <p>It's not necessary to talk about which values of InputIterator and
10778 OutputIterator must be supported.  Table 51 already contains a
10779 complete list of the ones we need.</p>
10780 <hr>
10781 <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>
10782 <p>It is a common idiom to reduce the capacity of a vector by swapping it with
10783 an empty one:</p>
10784 <pre>  std::vector&lt;SomeType&gt; vec;
10785   // fill vec with data
10786   std::vector&lt;SomeType&gt;().swap(vec);
10787   // vec is now empty, with minimal capacity
10788 </pre>
10789
10790 <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
10791 the capacity of a vector being reduced, following a call to
10792 reserve(). This invalidates the idiom, as swap() is thus prevented
10793 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
10794 requires the temporary to be expanded to cater for the contents of
10795 vec, and the contents be copied across. This is a linear-time
10796 operation.</p>
10797
10798 <p>However, the container requirements state that swap must have constant
10799 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>
10800
10801 <p>This is an important issue, as reallocation affects the validity of
10802 references and iterators.</p>
10803
10804 <p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
10805 references and iterators remain valid after a call to swap, if they refer to
10806 an element before the new end() of the vector into which they originally
10807 pointed, in which case they refer to the element at the same index position.
10808 Iterators and references that referred to an element whose index position
10809 was beyond the new end of the vector are invalidated.</p>
10810
10811 <p>If the note to table 65 is taken as the desired intent, then there are two
10812 possibilities with regard to iterators and references:</p>
10813
10814 <ol>
10815 <li>All Iterators and references into both vectors are invalidated.</li>
10816 <li>Iterators and references into either vector remain valid, and remain
10817 pointing to the same element. Consequently iterators and references that
10818 referred to one vector now refer to the other, and vice-versa.</li>
10819 </ol>
10820 <p><b>Proposed resolution:</b></p>
10821 <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>
10822 <blockquote>
10823 <pre>  void swap(vector&lt;T,Allocator&gt;&amp; x);
10824 </pre>
10825 <p><b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
10826 with that of <tt>x</tt>.</p>
10827 <p><b>Complexity:</b> Constant time.</p>
10828 </blockquote>
10829
10830 <p><i>[This solves the problem reported for this issue.  We may also
10831 have a problem with a circular definition of swap() for other
10832 containers.]</i></p>
10833
10834 <p><b>Rationale:</b></p>
10835 <p>
10836 swap should be constant time.  The clear intent is that it should just
10837 do pointer twiddling, and that it should exchange all properties of
10838 the two vectors, including their reallocation guarantees.
10839 </p>
10840 <hr>
10841 <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>
10842 <p>
10843 C99, and presumably amendment 1 to C90, specify that &lt;wchar.h&gt;
10844 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
10845 &lt;cwchar&gt;. Is this omission intentional or accidental?
10846 </p>
10847 <p><b>Proposed resolution:</b></p>
10848 <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>
10849 <hr>
10850 <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>
10851 <p>Iterator member functions and operators that do not change the state
10852 of the iterator should be defined as const member functions or as
10853 functions that take iterators either by const reference or by
10854 value. The standard does not explicitly state which functions should
10855 be const.  Since this a fairly common mistake, the following changes
10856 are suggested to make this explicit.</p>
10857
10858 <p>The tables almost indicate constness properly through naming: r
10859 for non-const and a,b for const iterators. The following changes
10860 make this more explicit and also fix a couple problems.</p>
10861 <p><b>Proposed resolution:</b></p>
10862 <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
10863 "In the following sections, a and b denote values of X..." to
10864 "In the following sections, a and b denote values of type const X...".</p>
10865
10866 <p>In Table 73, change</p>
10867 <pre>    a-&gt;m   U&amp;         ...
10868 </pre>
10869
10870 <p>to</p>
10871
10872 <pre>    a-&gt;m   const U&amp;   ...
10873     r-&gt;m   U&amp;         ...
10874 </pre>
10875
10876 <p>In Table 73 expression column, change</p>
10877
10878 <pre>    *a = t
10879 </pre>
10880
10881 <p>to</p>
10882
10883 <pre>    *r = t
10884 </pre>
10885
10886 <p><i>[Redmond: The container requirements should be reviewed to see if
10887 the same problem appears there.]</i></p>
10888
10889 <hr>
10890 <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>
10891 <p>
10892 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
10893 are described as bitmask elements.  In fact, the bitmask requirements
10894 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>
10895 and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
10896
10897 <p>In particular, the requirements for <tt>none</tt> interact poorly
10898 with the requirement that the LC_* constants from the C library must
10899 be recognizable as C++ locale category constants.  LC_* values should
10900 not be mixed with these values to make category values.</p>
10901
10902 <p>We have two options for the proposed resolution.  Informally:
10903 option 1 removes the requirement that LC_* values be recognized as
10904 category arguments.  Option 2 changes the category type so that this
10905 requirement is implementable, by allowing <tt>none</tt> to be some
10906 value such as 0x1000 instead of 0.</p>
10907
10908 <p>Nathan writes: "I believe my proposed resolution [Option 2] merely
10909 re-expresses the status quo more clearly, without introducing any
10910 changes beyond resolving the DR.</p>
10911
10912 <p><b>Proposed resolution:</b></p>
10913 <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>
10914 <blockquote>
10915 <pre>    typedef int category;
10916 </pre>
10917
10918 <p>Valid category values include the <tt>locale</tt> member bitmask
10919 elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
10920 <tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
10921 represents a single locale category. In addition, <tt>locale</tt> member
10922 bitmask constant <tt>none</tt> is defined as zero and represents no
10923 category. And locale member bitmask constant <tt>all</tt> is defined such that
10924 the expression</p>
10925 <pre>    (collate | ctype | monetary | numeric | time | messages | all) == all
10926 </pre>
10927 <p>
10928 is <tt>true</tt>, and represents the union of all categories.  Further
10929 the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
10930 represent a single category, represents the union of the two
10931 categories.
10932 </p>
10933
10934 <p>
10935 <tt>locale</tt> member functions expecting a <tt>category</tt>
10936 argument require one of the <tt>category</tt> values defined above, or
10937 the union of two or more such values. Such a <tt>category</tt>
10938 argument identifies a set of locale categories. Each locale category,
10939 in turn, identifies a set of locale facets, including at least those
10940 shown in Table 51:
10941 </p>
10942 </blockquote>
10943 <p><i>[Curaçao: need input from locale experts.]</i></p>
10944
10945 <p><b>Rationale:</b></p>
10946
10947 <p>The LWG considered, and rejected, an alternate proposal (described
10948   as "Option 2" in the discussion).  The main reason for rejecting it
10949   was that library implementors were concerened about implementation
10950   difficult, given that getting a C++ library to work smoothly with a
10951   separately written C library is already a delicate business.  Some
10952   library implementers were also concerned about the issue of adding
10953   extra locale categories.</p>
10954
10955 <blockquote>
10956 <p><b>Option 2:</b> <br>
10957 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>
10958 <blockquote>
10959 <p>
10960 Valid category values include the enumerated values.  In addition, the
10961 result of applying commutative operators | and &amp; to any two valid
10962 values is valid, and results in the setwise union and intersection,
10963 respectively, of the argument categories.  The values <tt>all</tt> and
10964 <tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
10965 expressions <tt>(cat | all == all)</tt>, <tt>(cat &amp; all == cat)</tt>,
10966 <tt>(cat | none == cat)</tt> and <tt>(cat &amp; none == none)</tt> are
10967 true.  For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
10968 remaining enumerated values, <tt>(cat1 &amp; cat2 == none)</tt> is true.
10969 For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
10970 of <tt>(cat1 &amp; ~cat2)</tt> is valid, and equals the setwise union of
10971 those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
10972 [Footnote: it is not required that <tt>all</tt> equal the setwise union
10973 of the other enumerated values; implementations may add extra categories.]
10974 </p>
10975 </blockquote>
10976 </blockquote>
10977 <hr>
10978 <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>
10979 <p>24.5.2 [lib.ostream.iterator] states:</p>
10980 <pre>    [...]
10981
10982     private:
10983     // basic_ostream&lt;charT,traits&gt;* out_stream; exposition only
10984     // const char* delim; exposition only
10985 </pre>
10986
10987 <p>Whilst it's clearly marked "exposition only", I suspect 'delim'
10988 should be of type 'const charT*'.</p>
10989 <p><b>Proposed resolution:</b></p>
10990 <p>
10991 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
10992 <tt>const charT* delim</tt>.
10993 </p>
10994 <hr>
10995 <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>
10996 <p>
10997 <i>(1)</i>
10998 There are no requirements on the <tt>stateT</tt> template parameter of
10999 <tt>fpos</tt> listed in 27.4.3. The interface appears to require that
11000 the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
11001 and I think also DefaultConstructible (to implement the operations in
11002 Table 88).
11003 </p>
11004 <p>
11005 21.1.2, p3, however, only requires that
11006 <tt>char_traits&lt;charT&gt;::state_type</tt> meet the requirements of
11007 CopyConstructible types.
11008 </p>
11009 <p>
11010 <i>(2)</i>
11011 Additionally, the <tt>stateT</tt> template argument has no
11012 corresponding typedef in fpos which might make it difficult to use in
11013 generic code.
11014 </p>
11015 <p><b>Proposed resolution:</b></p>
11016 <p>
11017 Modify 21.1.2, p4 from
11018 </p>
11019 <p>
11020     Requires: <tt>state_type</tt> shall meet the requirements of
11021               CopyConstructible types (20.1.3).
11022 </p>
11023 <p>
11024     Requires: state_type shall meet the requirements of Assignable
11025               (23.1, p4), CopyConstructible (20.1.3), and
11026               DefaultConstructible  (20.1.4) types.
11027 </p>
11028
11029 <p><b>Rationale:</b></p>
11030 <p>The LWG feels this is two issues, as indicated above. The first is
11031 a defect---std::basic_fstream is unimplementable without these
11032 additional requirements---and the proposed resolution fixes it.  The
11033 second is questionable; who would use that typedef?  The class
11034 template fpos is used only in a very few places, all of which know the
11035 state type already.  Unless motivation is provided, the second should
11036 be considered NAD.</p>
11037 <hr>
11038 <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>
11039 <p>
11040 Discussions in the thread "Associative container lower/upper bound
11041 requirements" on comp.std.c++ suggests that there is a defect in the
11042 C++ standard, Table 69 of section 23.1.2, "Associative containers",
11043 [lib.associative.reqmts].  It currently says:</p>
11044
11045 <blockquote>
11046 <p>
11047 a.find(k): returns an iterator pointing to an element with the key equivalent to
11048 k, or a.end() if such an element is not found.
11049 </p>
11050
11051 <p>
11052 a.lower_bound(k): returns an iterator pointing to the first element with
11053 key not less than k.
11054 </p>
11055
11056 <p>
11057 a.upper_bound(k): returns an iterator pointing to the first element with
11058 key greater than k.
11059 </p>
11060 </blockquote>
11061
11062 <p>
11063 We have "or a.end() if such an element is not found" for
11064 <tt>find</tt>, but not for <tt>upper_bound</tt> or
11065 <tt>lower_bound</tt>.  As the text stands, one would be forced to
11066 insert a new element into the container and return an iterator to that
11067 in case the sought iterator does not exist, which does not seem to be
11068 the intention (and not possible with the "const" versions).
11069 </p>
11070 <p><b>Proposed resolution:</b></p>
11071
11072 <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
11073 to:</p>
11074
11075 <blockquote>
11076 <p>
11077 a.lower_bound(k): returns an iterator pointing to the first element with
11078 key not less than k, or a.end() if such an element is not found.
11079 </p>
11080
11081 <p>
11082 a.upper_bound(k): returns an iterator pointing to the first element with
11083 key greater than k, or a.end() if such an element is not found.
11084 </p>
11085 </blockquote>
11086
11087 <p><i>[Curaçao: LWG reviewed PR.]</i></p>
11088
11089 <hr>
11090 <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>
11091
11092 <p>Table 68 "Optional Sequence Operations" in 23.1.1/12
11093 specifies operational semantics for "a.back()" as
11094 "*--a.end()", which may be ill-formed <i>[because calling
11095 operator-- on a temporary (the return) of a built-in type is
11096 ill-formed]</i>, provided a.end() returns a simple pointer rvalue
11097 (this is almost always the case for std::vector::end(), for
11098 example). Thus, the specification is not only incorrect, it
11099 demonstrates a dangerous construct: "--a.end()" may
11100 successfully compile and run as intended, but after changing the type
11101 of the container or the mode of compilation it may produce
11102 compile-time error. </p>
11103
11104 <p><b>Proposed resolution:</b></p>
11105 <p>Change the specification in table 68 "Optional Sequence
11106 Operations" in 23.1.1/12 for "a.back()" from</p>
11107
11108
11109 <blockquote>
11110 *--a.end()
11111 </blockquote>
11112
11113 <p>to</p>
11114
11115 <blockquote>
11116   { iterator tmp = a.end(); --tmp; return *tmp; }
11117 </blockquote>
11118
11119 <p>and the specification for "a.pop_back()" from</p>
11120
11121 <blockquote>
11122 a.erase(--a.end())
11123 </blockquote>
11124
11125 <p>to</p>
11126
11127 <blockquote>
11128   { iterator tmp = a.end(); --tmp; a.erase(tmp); }
11129 </blockquote>
11130
11131 <p><i>[Curaçao: LWG changed PR from "{ X::iterator tmp =
11132 a.end(); return *--tmp; }" to "*a.rbegin()", and from
11133 "{ X::iterator tmp = a.end(); a.erase(--tmp); }" to
11134 "a.erase(rbegin())".]</i></p>
11135
11136 <p><i>[There is a second possible defect; table 68 "Optional
11137 Sequence Operations" in the "Operational Semantics"
11138 column uses operations present only in the "Reversible
11139 Container" requirements, yet there is no stated dependency
11140 between these separate requirements tables. Ask in Santa Cruz if the
11141 LWG would like a new issue opened.]</i></p>
11142
11143 <p><i>[Santa Cruz: the proposed resolution is even worse than what's in
11144   the current standard: erase is undefined for reverse iterator.  If
11145   we're going to make the change, we need to define a temporary and
11146   use operator--.  Additionally, we don't know how prevalent this is:
11147   do we need to make this change in more than one place?  Martin has
11148   volunteered to review the standard and see if this problem occurs
11149   elsewhere.]</i></p>
11150
11151 <p><i>[Oxford: Matt provided new wording to address the concerns raised
11152   in Santa Cruz.  It does not appear that this problem appears
11153   anywhere else in clauses 23 or 24.]</i></p>
11154
11155 <p><i>[Kona: In definition of operational semantics of back(), change
11156 "*tmp" to "return *tmp;"]</i></p>
11157
11158 <hr>
11159 <a name="358"><h3>358.&nbsp;interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt>
11160 </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>
11161 <p>
11162 I don't think <tt>thousands_sep</tt> is being treated correctly after
11163 decimal_point has been seen. Since grouping applies only to the
11164 integral part of the number, the first such occurrence should, IMO,
11165 terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
11166 and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
11167 interpreted in the fractional part of a number.)
11168 </p>
11169
11170 <p>
11171 The easiest change I can think of that resolves this issue would be
11172 something like below.
11173 </p>
11174 <p><b>Proposed resolution:</b></p>
11175 <p>
11176 Change the first sentence of 22.2.2.1.2, p9 from
11177 </p>
11178
11179 <blockquote>
11180     If discard is true then the position of the character is
11181     remembered, but the character is otherwise ignored. If it is not
11182     discarded, then a check is made to determine if c is allowed as
11183     the next character of an input field of the conversion specifier
11184     returned by stage 1. If so it is accumulated.
11185 </blockquote>
11186
11187 <p>to</p>
11188
11189 <blockquote>
11190     If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
11191     accumulated, then the position of the character is remembered, but
11192     the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
11193     already been accumulated, the character is discarded and Stage 2
11194      terminates. ...
11195 </blockquote>
11196
11197 <p><b>Rationale:</b></p>
11198 <p>We believe this reflects the intent of the Standard.  Thousands sep
11199   characters after the decimal point are not useful in any locale.
11200   Some formatting conventions do group digits that follow the decimal
11201   point, but they usually introduce a different grouping character
11202   instead of reusing the thousand sep character.  If we want to add
11203   support for such conventions, we need to do so explicitly.</p>
11204
11205 <hr>
11206 <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>
11207 <p>22.2.2.2.1, p1:</p>
11208
11209     <pre>    iter_type put (iter_type out, ios_base&amp; str, char_type fill,
11210                    bool val) const;
11211     ...
11212
11213     1   Returns: do_put (out, str, fill, val).
11214     </pre>
11215
11216 <p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
11217 however, 22.2.2.2.2, p23:</p>
11218
11219 <blockquote>
11220 <pre>iter_type put (iter_type out, ios_base&amp; str, char_type fill,
11221                bool val) const;
11222 </pre>
11223
11224
11225         Effects: If (str.flags() &amp; ios_base::boolalpha) == 0 then do
11226              out = do_put(out, str, fill, (int)val)
11227            Otherwise do
11228 <pre>             string_type s =
11229                  val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
11230                      : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
11231 </pre>
11232            and then insert the characters of s into out. <i>out</i>.
11233 </blockquote>
11234
11235 <p>
11236 This means that the bool overload of <tt>do_put()</tt> will never be called,
11237 which contradicts the first paragraph. Perhaps the declaration
11238 should read <tt>do_put()</tt>, and not <tt>put()</tt>?
11239 </p>
11240
11241 <p>
11242 Note also that there is no <b>Returns</b> clause for this function, which
11243 should probably be corrected, just as should the second occurrence
11244 of <i>"out."</i> in the text.
11245 </p>
11246
11247 <p>
11248 I think the least invasive change to fix it would be something like
11249 the following:
11250 </p>
11251 <p><b>Proposed resolution:</b></p>
11252 <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
11253   the <tt>bool</tt> overload.</p>
11254
11255 <p>
11256 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
11257 </p>
11258
11259 <blockquote>
11260      Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
11261      of the member function.
11262 </blockquote>
11263
11264 <blockquote>
11265     Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
11266     avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
11267     do_put (..., bool))</tt>
11268     like so:
11269 </blockquote>
11270
11271 <blockquote>
11272     23   <b>Returns</b>: If <tt>(str.flags() &amp;
11273          ios_base::boolalpha) == 0</tt> then
11274          <tt>do_put (out, str, fill, (long)val)</tt>
11275          Otherwise the function obtains a string <tt>s</tt> as if by
11276 <pre>             string_type s =
11277                 val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
11278                     : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
11279 </pre>
11280          and then inserts each character <tt>c</tt> of s into out via
11281            <tt>*out++ = c</tt>
11282          and returns <tt>out</tt>.
11283 </blockquote>
11284
11285 <p><b>Rationale:</b></p>
11286 <p>
11287 This fixes a couple of obvious typos, and also fixes what appears to
11288 be a requirement of gratuitous inefficiency.
11289 </p>
11290 <hr>
11291 <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>
11292 <p>
11293 22.1.1, p7 (copied below) allows iostream formatters and extractors
11294 to make assumptions about the values returned from facet members.
11295 However, such assumptions are apparently not guaranteed to hold
11296 in other cases (e.g., when the facet members are being called directly
11297 rather than as a result of iostream calls, or between successive
11298 calls to the same iostream functions with no interevening calls to
11299 <tt>imbue()</tt>, or even when the facet member functions are called
11300 from other member functions of other facets). This restriction
11301 prevents locale from being implemented efficiently.
11302 </p>
11303 <p><b>Proposed resolution:</b></p>
11304 <p>Change the first sentence in 22.1.1, p7 from</p>
11305 <blockquote>
11306     In successive calls to a locale facet member function during
11307     a call to an iostream inserter or extractor or a streambuf member
11308     function, the returned result shall be identical. [Note: This
11309     implies that such results may safely be reused without calling
11310     the locale facet member function again, and that member functions
11311     of iostream classes cannot safely call <tt>imbue()</tt>
11312     themselves, except as specified elsewhere. --end note]
11313 </blockquote>
11314
11315 <p>to</p>
11316
11317 <blockquote>
11318     In successive calls to a locale facet member function on a facet
11319     object installed in the same locale, the returned result shall be
11320     identical. ...
11321 </blockquote>
11322
11323 <p><b>Rationale:</b></p>
11324 <p>This change is reasonable becuase it clarifies the intent of this
11325   part of the standard.</p>
11326 <hr>
11327 <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>
11328 <p>
11329 The destructor of ios_base::failure should have an empty throw
11330 specification, because the destructor of its base class, exception, is
11331 declared in this way.
11332 </p>
11333 <p><b>Proposed resolution:</b></p>
11334 <p>Change the destructor to</p>
11335 <pre>  virtual ~failure() throw();
11336 </pre>
11337 <p><b>Rationale:</b></p>
11338 <p>Fixes an obvious glitch.  This is almost editorial.</p>
11339 <hr>
11340 <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>
11341 <p>
11342 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
11343 clause for seekoff.
11344 </p>
11345 <p><b>Proposed resolution:</b></p>
11346 <p>
11347 Make this paragraph, the Effects clause for setbuf, consistent in wording
11348 with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
11349 to indicate the purpose of setbuf:
11350 </p>
11351
11352 <p>Original text:</p>
11353
11354 <blockquote>
11355 1 Effects: Performs an operation that is defined separately for each
11356 class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
11357 </blockquote>
11358
11359 <p>Proposed text:</p>
11360
11361 <blockquote>
11362 1 Effects: Influences stream buffering in a way that is defined separately
11363 for each class derived from basic_streambuf in this clause
11364 (27.7.1.3, 27.8.1.4).
11365 </blockquote>
11366
11367 <p><b>Rationale:</b></p>
11368 <p>The LWG doesn't believe there is any normative difference between
11369   the existing wording and what's in the proposed resolution, but the
11370   change may make the intent clearer.</p>
11371 <hr>
11372 <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>
11373 <p>
11374 Some stream and streambuf member functions are declared non-const,
11375 even thought they appear only to report information rather than to
11376 change an object's logical state.  They should be declared const.  See
11377 document N1360 for details and rationale.
11378 </p>
11379
11380 <p>The list of member functions under discussion: <tt>in_avail</tt>,
11381 <tt>showmanyc</tt>, <tt>tellg</tt>, <tt>tellp</tt>, <tt>is_open</tt>.</p>
11382
11383 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a></p>
11384
11385 <p><b>Proposed resolution:</b></p>
11386 <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>
11387 <p>Replace</p>
11388 <pre>  bool is_open();
11389 </pre>
11390 <p>with</p>
11391 <pre>  bool is_open() const;
11392 </pre>
11393 <p><b>Rationale:</b></p>
11394 <p>Of the changes proposed in N1360, the only one that is safe is
11395 changing the filestreams' is_open to const.  The LWG believed that
11396 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
11397 member function, after all,is already const.</p>
11398
11399 <p>The other proposed changes are less safe, because some streambuf
11400 functions that appear merely to report a value do actually perform
11401 mutating operations.  It's not even clear that they should be
11402 considered "logically const", because streambuf has two interfaces, a
11403 public one and a protected one.  These functions may, and often do,
11404 change the state as exposed by the protected interface, even if the
11405 state exposed by the public interface is unchanged.</p>
11406
11407 <p>Note that implementers can make this change in a binary compatible
11408 way by providing both overloads; this would be a conforming extension.</p>
11409
11410 <hr>
11411 <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>
11412 <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
11413 with the following signature:</p>
11414
11415 <pre>  basic_istream&lt;charT,traits&gt;&amp; get(basic_streambuf&lt;char_type,traits&gt;&amp;
11416   sb);
11417 </pre>
11418
11419 <p>is incorrect. It reads</p>
11420
11421 <blockquote>
11422   Effects: Calls get(s,n,widen('\n'))
11423 </blockquote>
11424
11425 <p>which I believe should be:</p>
11426
11427 <blockquote>
11428   Effects: Calls get(sb,widen('\n'))
11429 </blockquote>
11430 <p><b>Proposed resolution:</b></p>
11431 <p>Change the <b>Effects</b> paragraph to:</p>
11432 <blockquote>
11433   Effects: Calls get(sb,this-&gt;widen('\n'))
11434 </blockquote>
11435
11436 <p><i>[Pre-Oxford: Minor correction from Howard: replaced 'widen'
11437       with 'this-&gt;widen'.]</i></p>
11438
11439 <p><b>Rationale:</b></p>
11440 <p>Fixes an obvious typo.</p>
11441 <hr>
11442 <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>
11443
11444 <p>
11445 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>
11446 (exception()&amp;badbit) != 0 is used in testing for rethrow, yet
11447 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
11448 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?
11449 </p>
11450
11451 <p><b>Proposed resolution:</b></p>
11452 <p>
11453 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
11454 "(exception()&amp;badbit) != 0" to "(exceptions()&amp;badbit) != 0".
11455 </p>
11456 <p><b>Rationale:</b></p>
11457 <p>Fixes an obvious typo.</p>
11458 <hr>
11459 <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>
11460 <p>
11461 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
11462 14 all contain references to "basic_ios::" which should be
11463 "ios_base::".
11464 </p>
11465 <p><b>Proposed resolution:</b></p>
11466 <p>
11467 Change all references to "basic_ios" in Table 90, Table 91, and
11468 paragraph 14 to "ios_base".
11469 </p>
11470 <p><b>Rationale:</b></p>
11471 <p>Fixes an obvious typo.</p>
11472 <hr>
11473 <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>
11474 <p>
11475 The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
11476 </p>
11477 <pre>  charT do_widen (char c) const;
11478
11479   -11- Effects: Applies the simplest reasonable transformation from
11480        a char value or sequence of char values to the corresponding
11481        charT value or values. The only characters for which unique
11482        transformations are required are those in the basic source
11483        character set (2.2). For any named ctype category with a
11484        ctype&lt;charT&gt; facet ctw and valid ctype_base::mask value
11485        M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
11486 </pre>
11487 <p>
11488 Shouldn't the last sentence instead read
11489 </p>
11490 <pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
11491        and valid ctype_base::mask value M
11492        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
11493 </pre>
11494 <p>
11495 I.e., if the narrow character c is not a member of a class of
11496 characters then neither is the widened form of c. (To paraphrase
11497 footnote 224.)
11498 </p>
11499 <p><b>Proposed resolution:</b></p>
11500 <p>
11501 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
11502 following text:
11503 </p>
11504 <pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
11505        and valid ctype_base::mask value M,
11506        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
11507 </pre>
11508
11509 <p><i>[Kona: Minor edit. Added a comma after the <i>M</i> for clarity.]</i></p>
11510
11511 <p><b>Rationale:</b></p>
11512 <p>The LWG believes this is just a typo, and that this is the correct fix.</p>
11513 <hr>
11514 <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>
11515 <p>
11516 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
11517 result values," when surely "do_in/do_out result values" must have
11518 been intended for Table 53 and "do_unshift result values" for Table
11519 54.
11520 </p>
11521 <p>
11522 Table 54, row 3 says that the meaning of partial is "more characters
11523 needed to be supplied to complete termination." The function is not
11524 supplied any characters, it is given a buffer which it fills with
11525 characters or, more precisely, destination elements (i.e., an escape
11526 sequence). So partial means that space for more than (to_limit - to)
11527 destination elements was needed to terminate a sequence given the
11528 value of state.
11529 </p>
11530 <p><b>Proposed resolution:</b></p>
11531 <p>
11532 Change the title of Table 53 to "do_in/do_out result values" and
11533 the title of Table 54 to "do_unshift result values."
11534 </p>
11535 <p>
11536 Change the text in Table 54, row 3 (the <b>partial</b> row), under the
11537 heading Meaning, to "space for more than (to_limit - to) destination
11538 elements was needed to terminate a sequence given the value of state."
11539 </p>
11540 <hr>
11541 <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>
11542 <p>
11543 All but one codecvt member functions that take a state_type argument
11544 list as one of their preconditions that the state_type argument have
11545 a valid value. However, according to 22.2.1.5.2, p6,
11546 codecvt::do_unshift() is the only codecvt member that is supposed to
11547 return error if the state_type object is invalid.
11548 </p>
11549
11550 <p>
11551 It seems to me that the treatment of state_type by all codecvt member
11552 functions should be the same and the current requirements should be
11553 changed. Since the detection of invalid state_type values may be
11554 difficult in general or computationally expensive in some specific
11555 cases, I propose the following:
11556 </p>
11557 <p><b>Proposed resolution:</b></p>
11558 <p>
11559 Add a new paragraph before 22.2.1.5.2, p5, and after the function
11560 declaration below
11561 </p>
11562 <pre>    result do_unshift(stateT&amp; state,
11563     externT* to, externT* to_limit, externT*&amp; to_next) const;
11564 </pre>
11565 <p>
11566 as follows:
11567 </p>
11568 <pre>    Requires: (to &lt;= to_end) well defined and true; state initialized,
11569     if at the beginning of a sequence, or else equal to the result of
11570     converting the preceding characters in the sequence.
11571 </pre>
11572 <p>
11573 and change the text in Table 54, row 4, the <b>error</b> row, under
11574 the heading Meaning, from
11575 </p>
11576 <pre>    state has invalid value
11577 </pre>
11578 <p>
11579 to
11580 </p>
11581 <pre>    an unspecified error has occurred
11582 </pre>
11583 <p><b>Rationale:</b></p>
11584 <p>The intent is that implementations should not be required to detect
11585 invalid state values; such a requirement appears nowhere else.  An
11586 invalid state value is a precondition violation, <i>i.e.</i> undefined
11587 behavior.  Implementations that do choose to detect invalid state
11588 values, or that choose to detect any other kind of error, may return
11589 <b>error</b> as an indication.</p>
11590 <hr>
11591 <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>
11592 <p>
11593 Following a discussion on the boost list regarding end iterators and
11594 the possibility of performing operator--() on them, it seems to me
11595 that there is a typo in the standard.  This typo has nothing to do
11596 with that discussion.
11597 </p>
11598
11599 <p>
11600 I have checked this newsgroup, as well as attempted a search of the
11601 Active/Defect/Closed Issues List on the site for the words "s is
11602 derefer" so I believe this has not been proposed before.  Furthermore,
11603 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
11604 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.
11605 </p>
11606
11607 <p>
11608 The standard makes the following assertion on bidirectional iterators,
11609 in section 24.1.4 [lib.bidirectional.iterators], Table 75:
11610 </p>
11611
11612 <pre>                         operational  assertion/note
11613 expression  return type   semantics    pre/post-condition
11614
11615 --r          X&amp;                        pre: there exists s such
11616                                        that r == ++s.
11617                                        post: s is dereferenceable.
11618                                        --(++r) == r.
11619                                        --r == --s implies r == s.
11620                                        &amp;r == &amp;--r.
11621 </pre>
11622
11623 <p>
11624 (See <a href="http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763">http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763</a>.)
11625 </p>
11626
11627 <p>
11628 In particular, "s is dereferenceable" seems to be in error.  It seems
11629 that the intention was to say "r is dereferenceable".
11630 </p>
11631
11632 <p>
11633 If it were to say "r is dereferenceable" it would
11634 make perfect sense.  Since s must be dereferenceable prior to
11635 operator++, then the natural result of operator-- (to undo operator++)
11636 would be to make r dereferenceable.  Furthermore, without other
11637 assertions, and basing only on precondition and postconditions, we
11638 could not otherwise know this.  So it is also interesting information.
11639 </p>
11640
11641 <p><b>Proposed resolution:</b></p>
11642 <p>
11643 Change the guarantee to "postcondition: r is dereferenceable."
11644 </p>
11645 <p><b>Rationale:</b></p>
11646 <p>Fixes an obvious typo</p>
11647 <hr>
11648 <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>
11649 <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>
11650 is specified as having a return type of <tt>reverse_iterator::reference</tt>,
11651 which is the same as <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.
11652 (Where <tt>Iterator</tt> is the underlying iterator type.)</p>
11653
11654 <p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't
11655   necessarily have a return type
11656   of <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.   Its
11657   return type is merely required to be convertible
11658   to <tt>Iterator</tt>'s value type.  The return type specified for
11659   reverse_iterator's operator[] would thus appear to be impossible.</p>
11660
11661 <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
11662   <tt>a[n]</tt> will continue to be required (for random access
11663   iterators) to be convertible to the value type, and also <tt>a[n] =
11664   t</tt> will be a valid expression.  Implementations of
11665   <tt>reverse_iterator</tt> will likely need to return a proxy from
11666   <tt>operator[]</tt> to meet these requirements. As mentioned in the
11667   comment from Dave Abrahams, the simplest way to specify that
11668   <tt>reverse_iterator</tt> meet this requirement to just mandate
11669   it and leave the return type of <tt>operator[]</tt> unspecified.</p>
11670
11671 <p><b>Proposed resolution:</b></p>
11672
11673 <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>
11674
11675 <blockquote>
11676 <pre>reference operator[](difference_type n) const;
11677 </pre>
11678 </blockquote>
11679
11680 <p>to:</p>
11681
11682 <blockquote>
11683 <pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see <font color="red">lib.random.access.iterators</font>
11684 </pre>
11685 </blockquote>
11686
11687
11688
11689
11690 <p><i>[
11691 Comments from Dave Abrahams: IMO we should resolve 386 by just saying
11692     that the return type of reverse_iterator's operator[] is
11693     unspecified, allowing the random access iterator requirements to
11694     impose an appropriate return type.  If we accept 299's proposed
11695     resolution (and I think we should), the return type will be
11696     readable and writable, which is about as good as we can do.
11697 ]</i></p>
11698 <hr>
11699 <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>
11700 <p>Consider the following program:</p>
11701 <pre>    #include &lt;iostream&gt;
11702     #include &lt;ostream&gt;
11703     #include &lt;vector&gt;
11704     #include &lt;valarray&gt;
11705     #include &lt;algorithm&gt;
11706     #include &lt;iterator&gt;
11707     template&lt;typename Array&gt;
11708     void print(const Array&amp; a)
11709     {
11710     using namespace std;
11711     typedef typename Array::value_type T;
11712     copy(&amp;a[0], &amp;a[0] + a.size(),
11713     ostream_iterator&lt;T&gt;(std::cout, " "));
11714     }
11715     template&lt;typename T, unsigned N&gt;
11716     unsigned size(T(&amp;)[N]) { return N; }
11717     int main()
11718     {
11719     double array[] = { 0.89, 9.3, 7, 6.23 };
11720     std::vector&lt;double&gt; v(array, array + size(array));
11721     std::valarray&lt;double&gt; w(array, size(array));
11722     print(v); // #1
11723     std::cout &lt;&lt; std::endl;
11724     print(w); // #2
11725     std::cout &lt;&lt; std::endl;
11726     }
11727 </pre>
11728
11729 <p>While the call numbered #1 succeeds, the call numbered #2 fails
11730 because the const version of the member function
11731 valarray&lt;T&gt;::operator[](size_t) returns a value instead of a
11732 const-reference. That seems to be so for no apparent reason, no
11733 benefit. Not only does that defeats users' expectation but it also
11734 does hinder existing software (written either in C or Fortran)
11735 integration within programs written in C++.  There is no reason why
11736 subscripting an expression of type valarray&lt;T&gt; that is const-qualified
11737 should not return a const T&amp;.</p>
11738 <p><b>Proposed resolution:</b></p>
11739 <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
11740 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>
11741 <pre>  T operator[](size_t const);
11742 </pre>
11743 <p>to</p>
11744 <pre>  const T&amp; operator[](size_t const);
11745 </pre>
11746
11747 <p><i>[Kona: fixed a minor typo: put semicolon at the end of the line
11748   wehre it belongs.]</i></p>
11749
11750 <p><b>Rationale:</b></p>
11751 <p>Return by value seems to serve no purpose.  Valaray was explicitly
11752 designed to have a specified layout so that it could easily be
11753 integrated with libraries in other languages, and return by value
11754 defeats that purpose.  It is believed that this change will have no
11755 impact on allowable optimizations.</p>
11756 <hr>
11757 <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>
11758 <p>
11759 The specifications of toupper and tolower both specify the functions as
11760 const, althought they are not member functions, and are not specified as
11761 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>.
11762 </p>
11763 <p><b>Proposed resolution:</b></p>
11764 <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
11765   declarations of std::toupper and std::tolower</p>
11766 <p><b>Rationale:</b></p>
11767 <p>Fixes an obvious typo</p>
11768 <hr>
11769 <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>
11770 <p>
11771 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
11772 definition of rand(); in the C standard, it is written that "The
11773 implementation shall behave as if no library function calls the rand
11774 function."
11775 </p>
11776
11777 <p>
11778 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
11779 how the two parameter version of the function generates its random
11780 value.  I believe that all current implementations in fact call rand()
11781 (in contradiction with the requirement avove); if an implementation does
11782 not call rand(), there is the question of how whatever random generator
11783 it does use is seeded.  Something is missing.
11784 </p>
11785
11786 <p><b>Proposed resolution:</b></p>
11787 <p>
11788 In [lib.c.math], add a paragraph specifying that the C definition of
11789 rand shal be modified to say that "Unless otherwise specified, the
11790 implementation shall behave as if no library function calls the rand
11791 function."
11792 </p>
11793
11794 <p>
11795 In [lib.alg.random.shuffle], add a sentence to the effect that "In
11796 the two argument form of the function, the underlying source of
11797 random numbers is implementation defined. [Note: in particular, an
11798 implementation is permitted to use <tt>rand</tt>.]
11799 </p>
11800 <p><b>Rationale:</b></p>
11801 <p>The original proposed resolution proposed requiring the
11802   two-argument from of <tt>random_shuffle</tt> to
11803   use <tt>rand</tt>. We don't want to do that, because some existing
11804   implementations already use something else: gcc
11805   uses <tt>lrand48</tt>, for example.  Using <tt>rand</tt> presents a
11806   problem if the number of elements in the sequence is greater than
11807   RAND_MAX.</p>
11808 <hr>
11809 <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>
11810 <p>
11811 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
11812 the following 3 lines:
11813 </p>
11814
11815 <pre>  12 Returns: new((void *) p) T( val)
11816      void destroy(pointer p);
11817   13 Returns: ((T*) p)-&gt;~T()
11818 </pre>
11819
11820 <p>
11821 The type cast "(T*) p" in the last line is redundant cause
11822 we know that std::allocator&lt;T&gt;::pointer is a typedef for T*.
11823 </p>
11824 <p><b>Proposed resolution:</b></p>
11825 <p>
11826 Replace "((T*) p)" with "p".
11827 </p>
11828 <p><b>Rationale:</b></p>
11829 <p>Just a typo, this is really editorial.</p>
11830 <hr>
11831 <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>
11832 <p>
11833 This applies to the new expression that is contained in both par12 of
11834 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>.
11835 I think this new expression is wrong, involving unintended side
11836 effects.
11837 </p>
11838
11839
11840 <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>
11841
11842 <pre>  11 Returns: the largest value N for which the call allocate(N,0) might succeed.
11843      void construct(pointer p, const_reference val);
11844   12 Returns: new((void *) p) T( val)
11845 </pre>
11846
11847
11848 <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>
11849 <pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
11850 </pre>
11851
11852 <p>
11853 .... with the prerequisits coming from the preceding two paragraphs,
11854 especially from table 31:
11855 </p>
11856
11857 <pre>  alloc&lt;T&gt;             a     ;// an allocator for T
11858   alloc&lt;T&gt;::pointer    p     ;// random access iterator
11859                               // (may be different from T*)
11860   alloc&lt;T&gt;::reference  r = *p;// T&amp;
11861   T const&amp;             t     ;
11862 </pre>
11863
11864 <p>
11865 Cause of using "new" but not "::new", any existing "T::operator new"
11866 function will hide the global placement new function. When there is no
11867 "T::operator new" with adequate signature,
11868 every_alloc&lt;T&gt;::construct(..) is ill-formed, and most
11869 std::container&lt;T,every_alloc&lt;T&gt;&gt; use it; a workaround
11870 would be adding placement new and delete functions with adequate
11871 signature and semantic to class T, but class T might come from another
11872 party. Maybe even worse is the case when T has placement new and
11873 delete functions with adequate signature but with "unknown" semantic:
11874 I dont like to speculate about it, but whoever implements
11875 any_container&lt;T,any_alloc&gt; and wants to use construct(..)
11876 probably must think about it.
11877 </p>
11878 <p><b>Proposed resolution:</b></p>
11879 <p>
11880 Replace "new" with "::new" in both cases.
11881 </p>
11882 <hr>
11883 <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>
11884
11885 <p>
11886 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
11887 basic_string "conforms to the requirements of a Sequence, as specified
11888 in (23.1.1)." The sequence requirements specified in (23.1.1) to not
11889 include any prohibition on swap members throwing exceptions.
11890 </p>
11891
11892 <p>
11893 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
11894 which exceptions may be thrown, but applies only to "all container
11895 types defined in this clause" and so excludes basic_string::swap
11896 because it is defined elsewhere.
11897 </p>
11898
11899 <p>
11900 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
11901 permits basic_string::swap to invalidates iterators, which is
11902 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
11903 be contradictory if it were read or extended to read as having
11904 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.
11905 </p>
11906
11907 <p>
11908 Yet several LWG members have expressed the belief that the original
11909 intent was that basic_string::swap should not throw exceptions as
11910 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
11911 unclear on this issue. The complexity of basic_string::swap is
11912 specified as "constant time", indicating the intent was to avoid
11913 copying (which could cause a bad_alloc or other exception). An
11914 important use of swap is to ensure that exceptions are not thrown in
11915 exception-safe code.
11916 </p>
11917
11918 <p>
11919 Note: There remains long standing concern over whether or not it is
11920 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
11921 requirements when allocators are unequal. The specification of
11922 basic_string::swap exception requirements is in no way intended to
11923 address, prejudice, or otherwise impact that concern.
11924 </p>
11925
11926
11927
11928
11929
11930 <p><b>Proposed resolution:</b></p>
11931 <p>
11932 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:
11933 </p>
11934
11935 <p>
11936 Throws: Shall not throw exceptions.
11937 </p>
11938 <hr>
11939 <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>
11940 <p>
11941 The eight basic dynamic memory allocation functions (single-object
11942 and array versions of ::operator new and ::operator delete, in the
11943 ordinary and nothrow forms) are replaceable.  A C++ program may
11944 provide an alternative definition for any of them, which will be used
11945 in preference to the implementation's definition.
11946 </p>
11947
11948 <p>
11949 Three different parts of the standard mention requirements on
11950 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>
11951 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>.
11952 </p>
11953
11954 <p>None of these three places say whether a replacement function may
11955   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
11956   signature for the replacement function, but that's not enough:
11957   the <tt>inline</tt> specifier is not part of a function's signature.
11958   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
11959   requires that "an inline function shall be defined in every
11960   translation unit in which it is used," but this may not be quite
11961   specific enough either.  We should either explicitly allow or
11962   explicitly forbid inline replacement memory allocation
11963   functions.</p>
11964 <p><b>Proposed resolution:</b></p>
11965 <p>
11966 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:
11967 "The program's definitions shall not be specified as <tt>inline</tt>.
11968 No diagnostic is required."
11969 </p>
11970
11971 <p><i>[Kona: added "no diagnostic is required"]</i></p>
11972
11973 <p><b>Rationale:</b></p>
11974 <p>
11975 The fact that <tt>inline</tt> isn't mentioned appears to have been
11976 nothing more than an oversight.  Existing implementations do not
11977 permit inline functions as replacement memory allocation functions.
11978 Providing this functionality would be difficult in some cases, and is
11979 believed to be of limited value.
11980 </p>
11981 <hr>
11982 <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>
11983 <p>
11984 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
11985 standard library. Paragraph 4 does not list any restrictions on qsort,
11986 but it should limit the base parameter to point to POD.  Presumably,
11987 qsort sorts the array by copying bytes, which requires POD.
11988 </p>
11989 <p><b>Proposed resolution:</b></p>
11990 <p>
11991 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
11992 before the nonnormative note, add these words: "both of which have the
11993 same behavior as the original declaration.  The behavior is undefined
11994 unless the objects in the array pointed to by <i>base</i> are of POD
11995 type."
11996 </p>
11997
11998 <p><i>[Something along these lines is clearly necessary.  Matt
11999   provided wording.]</i></p>
12000 <hr>
12001 <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>
12002 <p>
12003 There is a possible defect in the standard: the standard text was
12004 never intended to prevent arbitrary ForwardIterators, whose operations
12005 may throw exceptions, from being passed, and it also wasn't intended
12006 to require a temporary buffer in the case where ForwardIterators were
12007 passed (and I think most implementations don't use one).  As is, the
12008 standard appears to impose requirements that aren't met by any
12009 existing implementation.
12010 </p>
12011 <p><b>Proposed resolution:</b></p>
12012 <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>
12013 <blockquote>
12014   1- Notes: Causes reallocation if the new size is greater than the
12015   old capacity. If no reallocation happens, all the iterators and
12016   references before the insertion point remain valid. If an exception
12017   is thrown other than by the copy constructor or assignment operator
12018   of T or by any InputIterator operation there are no effects.
12019 </blockquote>
12020
12021 <p><i>[We probably need to say something similar for deque.]</i></p>
12022
12023 <hr>
12024 <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>
12025 <p>
12026 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
12027 that is defined for a singular iterator is "an assignment of a
12028 non-singular value to an iterator that holds a singular value".  This
12029 means that destroying a singular iterator (e.g. letting an automatic
12030 variable go out of scope) is technically undefined behavior.  This
12031 seems overly strict, and probably unintentional.
12032 </p>
12033 <p><b>Proposed resolution:</b></p>
12034 <p>
12035 Change the sentence in question to "... the only exceptions are
12036 destroying an iterator that holds a singular value, or the assignment
12037 of a non-singular value to an iterator that holds a singular value."
12038 </p>
12039 <hr>
12040 <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>
12041 <p>
12042 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
12043 closing a basic_[io]fstream does not affect the error bits.  This
12044 means, for example, that if you read through a file up to EOF, and
12045 then close the stream and reopen it at the beginning of the file,
12046 the EOF bit in the stream's error state is still set.  This is
12047 counterintuitive.
12048 </p>
12049 <p>
12050 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>,
12051 and put in a footnote to clarify that the strict reading was indeed
12052 correct.  We did that because we believed the standard was
12053 unambiguous and consistent, and that we should not make architectural
12054 changes in a TC.  Now that we're working on a new revision of the
12055 language, those considerations no longer apply.
12056 </p>
12057 <p><b>Proposed resolution:</b></p>
12058
12059 <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>
12060
12061 <blockquote>
12062 Calls rdbuf()-&gt;open(s,mode|in). If that function returns a null
12063 pointer, calls setstate(failbit) (which may throw ios_base::failure
12064 [Footnote: (lib.iostate.flags)].
12065 </blockquote>
12066
12067 <p>to:</p>
12068
12069 <blockquote>Calls rdbuf()-&gt;open(s,mode|in). If that function returns
12070 a null pointer, calls setstate(failbit) (which may throw
12071 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
12072 </blockquote>
12073
12074 <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>
12075
12076 <blockquote>Calls rdbuf()-&gt;open(s,mode|out). If that function
12077 returns a null pointer, calls setstate(failbit) (which may throw
12078 ios_base::failure [Footnote: (lib.iostate.flags)).
12079 </blockquote>
12080
12081 <p>to:</p>
12082
12083 <blockquote>Calls rdbuf()-&gt;open(s,mode|out). If that function
12084 returns a null pointer, calls setstate(failbit) (which may throw
12085 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
12086 </blockquote>
12087
12088 <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>
12089
12090 <blockquote>Calls rdbuf()-&gt;open(s,mode), If that function returns a
12091 null pointer, calls setstate(failbit), (which may throw
12092 ios_base::failure). (lib.iostate.flags) )
12093 </blockquote>
12094
12095 <p>to:</p>
12096
12097 <blockquote>Calls rdbuf()-&gt;open(s,mode), If that function returns a
12098 null pointer, calls setstate(failbit), (which may throw
12099 ios_base::failure). (lib.iostate.flags) ), else calls clear().
12100 </blockquote>
12101
12102
12103
12104 <p><i>[Kona: the LWG agrees this is a good idea.  Post-Kona: Bill
12105 provided wording.  He suggests having open, not close, clear the error
12106 flags.]</i></p>
12107
12108 <p><i>[Post-Sydney: Howard provided a new proposed resolution.  The
12109   old one didn't make sense because it proposed to fix this at the
12110   level of basic_filebuf, which doesn't have access to the stream's
12111   error state.  Howard's proposed resolution fixes this at the level
12112   of the three fstream class template instead.]</i></p>
12113
12114 <hr>
12115 <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>
12116 <p>
12117 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
12118 comparison operators (==, !=, &lt;, &lt;=, &gt;, =&gt;) for queue and
12119 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>
12120 par3) are defined.
12121 </p>
12122 <p><b>Proposed resolution:</b></p>
12123
12124 <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>
12125   paragraph 3:</p>
12126
12127 <blockquote>
12128
12129 <pre>  operator!=
12130 </pre>
12131 <p>Returns: <tt>x.c != y.c</tt></p>
12132
12133 <pre>  operator&gt;
12134 </pre>
12135 <p>Returns: <tt>x.c &gt; y.c</tt></p>
12136
12137 <pre>  operator&lt;=
12138 </pre>
12139 <p>Returns: <tt>x.c &lt;= y.c</tt></p>
12140
12141 <pre>  operator&gt;=
12142 </pre>
12143 <p>Returns: <tt>x.c &gt;= y.c</tt></p>
12144
12145 </blockquote>
12146
12147 <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>
12148
12149 <blockquote>
12150
12151 <pre>  operator==
12152 </pre>
12153 <p>Returns: <tt>x.c == y.c</tt></p>
12154
12155 <pre>  operator&lt;
12156 </pre>
12157 <p>Returns: <tt>x.c &lt; y.c</tt></p>
12158
12159 <pre>  operator!=
12160 </pre>
12161 <p>Returns: <tt>x.c != y.c</tt></p>
12162
12163 <pre>  operator&gt;
12164 </pre>
12165 <p>Returns: <tt>x.c &gt; y.c</tt></p>
12166
12167 <pre>  operator&lt;=
12168 </pre>
12169 <p>Returns: <tt>x.c &lt;= y.c</tt></p>
12170
12171 <pre>  operator&gt;=
12172 </pre>
12173 <p>Returns: <tt>x.c &gt;= y.c</tt></p>
12174
12175 </blockquote>
12176
12177
12178 <p><i>[Kona: Matt provided wording.]</i></p>
12179
12180 <p><b>Rationale:</b></p>
12181 There isn't any real doubt about what these operators are
12182 supposed to do, but we ought to spell it out.
12183 <hr>
12184 <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>
12185 <p>
12186 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:
12187 "The semantics of the set operations are generalized to multisets in a
12188 standard way by defining union() to contain the maximum number of
12189 occurrences of every element, intersection() to contain the minimum, and
12190 so on."
12191 </p>
12192
12193 <p>
12194 This is wrong.  The name of the functions are set_union() and
12195 set_intersection(), not union() and intersection().
12196 </p>
12197 <p><b>Proposed resolution:</b></p>
12198 <p>Change that sentence to use the correct names.</p>
12199 <hr>
12200 <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>
12201 <p>
12202 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
12203 function only throws if the respective bits are already set prior to
12204 the function call. That's obviously not the intent. The typo ought to
12205 be corrected and the text reworded as: "If (<i>state</i> &amp;
12206 exceptions()) == 0, returns. ..."
12207 </p>
12208 <p><b>Proposed resolution:</b></p>
12209 <p>
12210 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;
12211 exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
12212 &amp; exceptions()) == 0".
12213 </p>
12214
12215 <p><i>[Kona: the original proposed resolution wasn't quite right.  We
12216   really do mean rdstate(); the ambiguity is that the wording in the
12217   standard doesn't make it clear whether we mean rdstate() before
12218   setting the new state, or rdsate() after setting it.  We intend the
12219   latter, of course. Post-Kona: Martin provided wording.]</i></p>
12220
12221 <hr>
12222 <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>
12223 <p>
12224 The second sentence of the proposed resolution says:
12225 </p>
12226
12227 <p>
12228 "If it inserted no characters because it caught an exception thrown
12229 while extracting characters from sb and ..."
12230 </p>
12231
12232 <p>
12233 However, we are not extracting from sb, but extracting from the
12234 basic_istream (*this) and inserting into sb. I can't really tell if
12235 "extracting" or "sb" is a typo.
12236 </p>
12237
12238 <p><i>[
12239 Sydney: Definitely a real issue. We are, indeed, extracting characters
12240 from an istream and not from sb. The problem was there in the FDIS and
12241 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
12242 to have *this instead of sb. We're talking about the exception flag
12243 state of a basic_istream object, and there's only one basic_istream
12244 object in this discussion, so that would be a consistent
12245 interpretation.  (But we need to be careful: the exception policy of
12246 this member function must be consistent with that of other
12247 extractors.)  PJP will provide wording.
12248 ]</i></p>
12249
12250 <p><b>Proposed resolution:</b></p>
12251 <p>Change the sentence from:</p>
12252
12253 <blockquote>
12254 If it inserted no characters because it caught an exception thrown
12255 while extracting characters from sb and failbit is on in exceptions(),
12256 then the caught exception is rethrown.
12257 </blockquote>
12258
12259 <p>to:</p>
12260
12261 <blockquote>
12262 If it inserted no characters because it caught an exception thrown
12263 while extracting characters from *this and failbit is on in exceptions(),
12264 then the caught exception is rethrown.
12265 </blockquote>
12266 <hr>
12267 <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>
12268 <p>
12269 Consider the following code fragment:
12270 </p>
12271 <blockquote>
12272 <pre>int A[8] = { 1,3,5,7,9,8,4,2 };
12273 std::vector&lt;int&gt; v(A, A+8);
12274
12275 std::vector&lt;int&gt;::iterator i1 = v.begin() + 3;
12276 std::vector&lt;int&gt;::iterator i2 = v.begin() + 4;
12277 v.erase(i1);
12278 </pre>
12279 </blockquote>
12280
12281 <p>
12282 Which iterators are invalidated by <tt>v.erase(i1)</tt>: i1, i2,
12283 both, or neither?
12284 </p>
12285
12286 <p>
12287 On all existing implementations that I know of, the status of i1 and
12288 i2 is the same: both of them will be iterators that point to some
12289 elements of the vector (albeit not the same elements they did
12290 before).  You won't get a crash if you use them.  Depending on
12291 exactly what you mean by "invalidate", you might say that neither one
12292 has been invalidated because they still point to <i>something</i>,
12293 or you might say that both have been invalidated because in both
12294 cases the elements they point to have been changed out from under the
12295 iterator.
12296 </p>
12297
12298 <p>
12299 The standard doesn't say either of those things.  It says that erase
12300 invalidates all iterators and references "after the point of the
12301 erase".  This doesn't include i1, since it's at the point of the
12302 erase instead of after it.  I can't think of any sensible definition
12303 of invalidation by which one can say that i2 is invalidated but i1
12304 isn't.
12305 </p>
12306
12307 <p>
12308 (This issue is important if you try to reason about iterator validity
12309 based only on the guarantees in the standard, rather than reasoning
12310 from typical implementation techniques.  Strict debugging modes,
12311 which some programmers find useful, do not use typical implementation
12312 techniques.)
12313 </p>
12314 <p><b>Proposed resolution:</b></p>
12315 <p>
12316 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
12317 iterators and references after the point of the erase" to
12318 "Invalidates iterators and references at or after the point of the
12319 erase".
12320 </p>
12321 <p><b>Rationale:</b></p>
12322 <p>I believe this was essentially a typographical error, and that it
12323   was taken for granted that erasing an element invalidates iterators
12324   that point to it.  The effects clause in question treats iterators
12325   and references in parallel, and it would seem counterintuitive to
12326   say that a reference to an erased value remains valid.</p>
12327 <hr>
12328 <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>
12329 <p>
12330 According to 27.6.1.4, the ws() manipulator is not required to construct
12331 the sentry object. The manipulator is also not a member function so the
12332 text in 27.6.1, p1 through 4 that describes the exception policy for
12333 istream member functions does not apply. That seems inconsistent with
12334 the rest of extractors and all the other input functions (i.e., ws will
12335 not cause a tied stream to be flushed before extraction, it doesn't check
12336 the stream's exceptions or catch exceptions thrown during input, and it
12337 doesn't affect the stream's gcount).
12338 </p>
12339 <p><b>Proposed resolution:</b></p>
12340 <p>
12341 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
12342 of paragraph 1, the following text:
12343 </p>
12344
12345     <blockquote>
12346     Behaves as an unformatted input function (as described in
12347     27.6.1.3, paragraph 1), except that it does not count the number
12348     of characters extracted and does not affect the value returned by
12349     subsequent calls to is.gcount(). After constructing a sentry
12350     object...
12351     </blockquote>
12352
12353 <p><i>[Post-Kona: Martin provided wording]</i></p>
12354
12355 <hr>
12356 <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>
12357 <p>
12358 7.19.1, p2, of C99 requires that the FILE type only be declared in
12359 &lt;stdio.h&gt;.  None of the (implementation-defined) members of the
12360 struct is mentioned anywhere for obvious reasons.
12361 </p>
12362
12363 <p>
12364 C++ says in 27.8.1, p2 that FILE is a type that's defined in &lt;cstdio&gt;. Is
12365 it really the intent that FILE be a complete type or is an implementation
12366 allowed to just declare it without providing a full definition?
12367 </p>
12368 <p><b>Proposed resolution:</b></p>
12369 <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
12370   "defined" to "declared".</p>
12371 <p><b>Rationale:</b></p>
12372 <p>We don't want to impose any restrictions beyond what the C standard
12373   already says. We don't want to make anything implementation defined,
12374   because that imposes new requirements in implementations.</p>
12375 <hr>
12376 <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>
12377 <p>
12378 The standard is not clear about the requirements on the value returned from
12379 a call to get_temporary_buffer(0). In particular, it fails to specify whether
12380 the call should return a distinct pointer each time it is called (like
12381 operator new), or whether the value is unspecified (as if returned by
12382 malloc). The standard also fails to mention what the required behavior
12383 is when the argument is less than 0.
12384 </p>
12385 <p><b>Proposed resolution:</b></p>
12386 <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
12387 values if no storage can be obtained" to "...or a pair of 0 values if
12388 no storage can be obtained or if <i>n</i> &lt;= 0."</p>
12389 <p><i>[Kona: Matt provided wording]</i></p>
12390 <hr>
12391 <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>
12392 <p>
12393 The complexity requirements for these function templates are incorrect
12394 (or don't even make sense) for negative n:</p>
12395
12396 <p>25.1.9, p7 (search_n):
12397 <br>
12398 Complexity: At most (last1 - first1) * count applications
12399 of the corresponding predicate.</p>
12400
12401 <p>25.2.5, p3 (fill_n):
12402 <br>
12403 Complexity: Exactly last - first (or n) assignments.</p>
12404 <br>
12405
12406 <p>25.2.6, p3 (generate_n):
12407 <br>
12408 Complexity: Exactly last - first (or n) assignments.</p>
12409
12410 <p>
12411 In addition, the Requirements or the Effects clauses for the latter two
12412 templates don't say anything about the behavior when n is negative.
12413 </p>
12414 <p><b>Proposed resolution:</b></p>
12415 <p>Change 25.1.9, p7 to</p>
12416
12417 <blockquote>
12418 Complexity: At most (last1 - first1) * count applications
12419 of the corresponding predicate if count is positive,
12420 or 0 otherwise.
12421 </blockquote>
12422
12423 <p>Change 25.2.5, p2 to</p>
12424 <blockquote>
12425 Effects: Assigns value through all the iterators in the range [first,
12426 last), or [first, first + n) if n is positive, none otherwise.
12427 </blockquote>
12428
12429 <p>Change 25.2.5, p3 to:</p>
12430 <blockquote>
12431 Complexity: Exactly last - first (or n if n is positive,
12432 or 0 otherwise) assignments.
12433 </blockquote>
12434
12435 <p>
12436 Change 25.2.6, p1
12437 to (notice the correction for the misspelled "through"):
12438 </p>
12439 <blockquote>
12440 Effects: Invokes the function object genand assigns the return
12441 value of gen through all the iterators in the range [first, last),
12442 or [first, first + n) if n is positive, or [first, first)
12443 otherwise.
12444 </blockquote>
12445
12446 <p>Change 25.2.6, p3 to:</p>
12447 <blockquote>
12448 Complexity: Exactly last - first (or n if n is positive,
12449 or 0 otherwise) assignments.
12450 </blockquote>
12451 <p><b>Rationale:</b></p>
12452 <p>Informally, we want to say that whenever we see a negative number
12453   we treat it the same as if it were zero.  We believe the above
12454   changes do that (although they may not be the minimal way of saying
12455   so).  The LWG considered and rejected the alternative of saying that
12456   negative numbers are undefined behavior.</p>
12457 <hr>
12458 <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>
12459 <p>
12460 23.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q)
12461 that q must be a valid dereferenceable iterator into the sequence a.
12462 </p>
12463
12464 <p>
12465 However, 21.3.5.5, p5 describing string::erase(p) only requires that
12466 p be a valid iterator.
12467 </p>
12468
12469 <p>
12470 This may be interepreted as a relaxation of the general requirement,
12471 which is most likely not the intent.
12472 </p>
12473 <p><b>Proposed resolution:</b></p>
12474 <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>
12475 <p><b>Rationale:</b></p>
12476 <p>The LWG considered two options: changing the string requirements to
12477   match the general container requirements, or just removing the
12478   erroneous string requirements altogether.  The LWG chose the latter
12479   option, on the grounds that duplicating text always risks the
12480   possibility that it might be duplicated incorrectly.</p>
12481 <hr>
12482 <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>
12483 <p>27.7.1.3 par 8 says:</p>
12484 <blockquote>
12485 Notes: The function can make a write position available only if
12486     ( mode &amp; ios_base::out) != 0. To make a write position
12487     available, the function reallocates (or initially allocates) an
12488     array object with a sufficient number of elements to hold the
12489     current array object (if any), plus one additional write position.
12490     If ( mode &amp; ios_base::in) != 0, the function alters the read end
12491     pointer egptr() to point just past the new write position (as
12492     does the write end pointer epptr()).
12493 </blockquote>
12494
12495 <p>
12496 The sentences "plus one additional write position." and especially
12497     "(as does the write end pointer epptr())" COULD by interpreted
12498     (and is interpreted by at least my library vendor) as:
12499 </p>
12500
12501 <blockquote>
12502     post-condition: epptr() == pptr()+1
12503 </blockquote>
12504
12505 <p>
12506 This WOULD force sputc() to call the virtual overflow() each time.
12507 </p>
12508
12509 <p>The proposed change also affects Defect Report 169.</p>
12510
12511 <p><b>Proposed resolution:</b></p>
12512 <p>27.7.1.1/2 Change:</p>
12513
12514 <blockquote>
12515 2- Notes: The function allocates no array object.
12516 </blockquote>
12517
12518 <p>
12519 to:
12520 </p>
12521
12522 <blockquote>
12523 2- Postcondition: str() == "".
12524 </blockquote>
12525
12526 <p>
12527 27.7.1.1/3 Change:
12528 </p>
12529
12530 <blockquote>
12531 <p>
12532 -3- Effects: Constructs an object of class basic_stringbuf,
12533 initializing the base class with basic_streambuf()
12534 (lib.streambuf.cons), and initializing mode with which . Then copies
12535 the content of str into the basic_stringbuf underlying character
12536 sequence and initializes the input and output sequences according to
12537 which. If which &amp; ios_base::out is true, initializes the output
12538 sequence with the underlying sequence. If which &amp; ios_base::in is
12539 true, initializes the input sequence with the underlying sequence.
12540 </p>
12541 </blockquote>
12542
12543 <p>to:</p>
12544
12545 <blockquote>
12546 <p>
12547 -3- Effects: Constructs an object of class basic_stringbuf,
12548 initializing the base class with basic_streambuf()
12549 (lib.streambuf.cons), and initializing mode with which. Then copies
12550 the content of str into the basic_stringbuf underlying character
12551 sequence. If which &amp; ios_base::out is true, initializes the output
12552 sequence such that pbase() points to the first underlying character,
12553 epptr() points one past the last underlying character, and if (which &amp;
12554 ios_base::ate) is true, pptr() is set equal to
12555 epptr() else pptr() is set equal to pbase(). If which &amp; ios_base::in
12556 is true, initializes the input sequence such that eback() and gptr()
12557 point to the first underlying character and egptr() points one past
12558 the last underlying character.
12559 </p>
12560 </blockquote>
12561
12562 <p>27.7.1.2/1 Change:</p>
12563
12564 <blockquote>
12565 <p>
12566 -1- Returns: A basic_string object whose content is equal to the
12567 basic_stringbuf underlying character sequence. If the buffer is only
12568 created in input mode, the underlying character sequence is equal to
12569 the input sequence; otherwise, it is equal to the output sequence. In
12570 case of an empty underlying character sequence, the function returns
12571 basic_string&lt;charT,traits,Allocator&gt;().
12572 </p>
12573 </blockquote>
12574
12575 <p>to:</p>
12576
12577 <blockquote>
12578 <p>
12579 -1- Returns: A basic_string object whose content is equal to the
12580 basic_stringbuf underlying character sequence. If the basic_stringbuf
12581 was created only in input mode, the resultant basic_string contains
12582 the character sequence in the range [eback(), egptr()).  If the
12583 basic_stringbuf was created with (which &amp; ios_base::out) being true
12584 then the resultant basic_string contains the character sequence in the
12585 range [pbase(), high_mark) where high_mark represents the position one
12586 past the highest initialized character in the buffer.  Characters can
12587 be initialized either through writing to the stream, or by
12588 constructing the basic_stringbuf with a basic_string, or by calling
12589 the str(basic_string) member function.  In the case of calling the
12590 str(basic_string) member function, all characters initialized prior to
12591 the call are now considered uninitialized (except for those
12592 characters re-initialized by the new basic_string).  Otherwise the
12593 basic_stringbuf has been created in neither input nor output mode and
12594 a zero length basic_string is returned.
12595 </p>
12596 </blockquote>
12597
12598 <p>
12599 27.7.1.2/2 Change:
12600 </p>
12601
12602 <blockquote>
12603 <p>
12604 -2- Effects: If the basic_stringbuf's underlying character sequence is
12605 not empty, deallocates it. Then copies the content of s into the
12606 basic_stringbuf underlying character sequence and initializes the
12607 input and output sequences according to the mode stored when creating
12608 the basic_stringbuf object. If (mode&amp;ios_base::out) is true, then
12609 initializes the output sequence with the underlying sequence. If
12610 (mode&amp;ios_base::in) is true, then initializes the input sequence with
12611 the underlying sequence.
12612 </p>
12613 </blockquote>
12614
12615 <p>to:</p>
12616
12617 <blockquote>
12618 <p>
12619 -2- Effects: Copies the content of s into the basic_stringbuf
12620 underlying character sequence. If mode &amp; ios_base::out is true,
12621 initializes the output sequence such that pbase() points to the first
12622 underlying character, epptr() points one past the last underlying
12623 character, and if (mode &amp; ios_base::ate) is true,
12624 pptr() is set equal to epptr() else pptr() is set equal to pbase(). If
12625 mode &amp; ios_base::in is true, initializes the input sequence such that
12626 eback() and gptr() point to the first underlying character and egptr()
12627 points one past the last underlying character.
12628 </p>
12629 </blockquote>
12630
12631 <p>Remove 27.2.1.2/3.  (Same rationale as issue 238: incorrect and unnecessary.)</p>
12632
12633 <p>27.7.1.3/1 Change:</p>
12634
12635 <blockquote>
12636 <p>
12637 1- Returns: If the input sequence has a read position available,
12638 returns traits::to_int_type(*gptr()).  Otherwise, returns
12639 traits::eof().
12640 </p>
12641 </blockquote>
12642
12643 <p>to:</p>
12644
12645 <blockquote>
12646 <p>
12647 1- Returns: If the input sequence has a read position available,
12648 returns traits::to_int_type(*gptr()).  Otherwise, returns
12649 traits::eof().  Any character in the underlying buffer which has been
12650 initialized is considered to be part of the input sequence.
12651 </p>
12652 </blockquote>
12653
12654 <p>27.7.1.3/9 Change:</p>
12655
12656 <blockquote>
12657 <p>
12658 -9- Notes: The function can make a write position available only if (
12659 mode &amp; ios_base::out) != 0. To make a write position available, the
12660 function reallocates (or initially allocates) an array object with a
12661 sufficient number of elements to hold the current array object (if
12662 any), plus one additional write position. If ( mode &amp; ios_base::in) !=
12663 0, the function alters the read end pointer egptr() to point just past
12664 the new write position (as does the write end pointer epptr()).
12665 </p>
12666 </blockquote>
12667
12668 <p>to:</p>
12669
12670 <blockquote>
12671 <p>
12672 -9- The function can make a write position available only if ( mode &amp;
12673 ios_base::out) != 0. To make a write position available, the function
12674 reallocates (or initially allocates) an array object with a sufficient
12675 number of elements to hold the current array object (if any), plus one
12676 additional write position. If ( mode &amp; ios_base::in) != 0, the
12677 function alters the read end pointer egptr() to point just past the
12678 new write position.
12679 </p>
12680 </blockquote>
12681
12682 <p>27.7.1.3/12 Change:</p>
12683
12684 <blockquote>
12685 <p>
12686 -12- _ If (newoff + off) &lt; 0, or (xend - xbeg) &lt; (newoff + off), the
12687 positioning operation fails. Otherwise, the function assigns xbeg +
12688 newoff + off to the next pointer xnext .
12689 </p>
12690 </blockquote>
12691
12692 <p>to:</p>
12693
12694 <blockquote>
12695 <p>
12696 -12- _ If (newoff + off) &lt; 0, or if (newoff + off) refers to an
12697 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>
12698 paragraph 1), the positioning operation fails. Otherwise, the function
12699 assigns xbeg + newoff + off to the next pointer xnext .
12700 </p>
12701 </blockquote>
12702
12703 <p><i>[post-Kona: Howard provided wording.  At Kona the LWG agreed that
12704   something along these lines was a good idea, but the original
12705   proposed resolution didn't say enough about the effect of various
12706   member functions on the underlying character sequences.]</i></p>
12707
12708 <p><b>Rationale:</b></p>
12709 <p>The current basic_stringbuf description is over-constrained in such
12710 a way as to prohibit vendors from making this the high-performance
12711 in-memory stream it was meant to be.  The fundamental problem is that
12712 the pointers: eback(), gptr(), egptr(), pbase(), pptr(), epptr() are
12713 observable from a derived client, and the current description
12714 restricts the range [pbase(), epptr()) from being grown geometrically.
12715 This change allows, but does not require, geometric growth of this
12716 range.</p>
12717
12718 <p>Backwards compatibility issues: These changes will break code that
12719 derives from basic_stringbuf, observes epptr(), and depends upon
12720 [pbase(), epptr()) growing by one character on each call to overflow()
12721 (i.e. test suites).  Otherwise there are no backwards compatibility
12722 issues.</p>
12723
12724 <p>27.7.1.1/2: The non-normative note is non-binding, and if it were
12725 binding, would be over specification.  The recommended change focuses
12726 on the important observable fact.</p>
12727
12728 <p>27.7.1.1/3: This change does two things: 1.  It describes exactly
12729 what must happen in terms of the sequences.  The terms "input
12730 sequence" and "output sequence" are not well defined.  2.  It
12731 introduces a common extension: open with app or ate mode.  I concur
12732 with issue 238 that paragraph 4 is both wrong and unnecessary.</p>
12733
12734 <p>27.7.1.2/1: This change is the crux of the efficiency issue.  The
12735 resultant basic_string is not dependent upon epptr(), and thus
12736 implementors are free to grow the underlying buffer geometrically
12737 during overflow() *and* place epptr() at the end of that buffer.</p>
12738
12739 <p>27.7.1.2/2:  Made consistent with the proposed 27.7.1.1/3.</p>
12740
12741 <p>27.7.1.3/1: Clarifies that characters written to the stream beyond
12742 the initially specified string are available for reading in an i/o
12743 basic_streambuf.</p>
12744
12745 <p>27.7.1.3/9: Made normative by removing "Notes:", and removed the
12746 trailing parenthetical comment concerning epptr().</p>
12747
12748 <p>27.7.1.3/12: Restricting the positioning to [xbeg, xend) is no
12749 longer allowable since [pbase(), epptr()) may now contain
12750 uninitialized characters.  Positioning is only allowable over the
12751 initialized range.</p>
12752 <hr>
12753 <a name="434"></a><h3><a name="434">434.&nbsp;bitset::to_string() hard to use</a></h3><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>
12754 <p>
12755 It has been pointed out a number of times that the bitset to_string() member
12756 function template is tedious to use since callers must explicitly specify the
12757 entire template argument list (3 arguments). At least two implementations
12758 provide a number of overloads of this template to make it easier to use.
12759 </p>
12760 <p><b>Proposed resolution:</b></p>
12761 <p>In order to allow callers to specify no template arguments at all, just the
12762 first one (charT), or the first 2 (charT and traits), in addition to all
12763 three template arguments, add the following three overloads to both the
12764 interface (declarations only) of the class template bitset as well as to
12765 section 23.3.5.2, immediately after p34, the Returns clause of the existing
12766 to_string() member function template:</p>
12767
12768 <pre>    template &lt;class charT, class traits&gt;
12769     basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
12770     to_string () const;
12771
12772     -34.1- Returns: to_string&lt;charT, traits, allocator&lt;charT&gt; &gt;().
12773
12774     template &lt;class charT&gt;
12775     basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
12776     to_string () const;
12777
12778     -34.2- Returns: to_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;().
12779
12780     basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
12781     to_string () const;
12782
12783     -34.3- Returns: to_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;().
12784 </pre>
12785
12786 <p><i>[Kona: the LWG agrees that this is an improvement over the
12787   status quo.  Dietmar thought about an alternative using a proxy
12788   object but now believes that the proposed resolution above is the
12789   right choice.
12790 ]</i></p>
12791
12792 <hr>
12793 <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>
12794
12795 <p>
12796 It has been pointed out that the proposed resolution in DR 25 may not be
12797 quite up to snuff: <br>
12798 http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html
12799 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#25<br>
12800 </p>
12801
12802 <p>
12803 It looks like Petur is right. The complete corrected text is copied below.
12804 I think we may have have been confused by the reference to 22.2.2.2.2 and
12805 the subsequent description of `n' which actually talks about the second
12806 argument to sputn(), not about the number of fill characters to pad with.
12807 </p>
12808
12809 <p>
12810 So the question is: was the original text correct? If the intent was to
12811 follow classic iostreams then it most likely wasn't, since setting width()
12812 to less than the length of the string doesn't truncate it on output. This
12813 is also the behavior of most implementations (except for SGI's standard
12814 iostreams where the operator does truncate).
12815 </p>
12816 <p><b>Proposed resolution:</b></p>
12817 <p>Change the text in 21.3.7.9, p4 from</p>
12818     <blockquote>
12819     If bool(k) is true, inserts characters as if by calling
12820     os.rdbuf()-&gt;sputn(str.data(), n), padding as described in stage 3
12821     of lib.facet.num.put.virtuals, where n is the larger of os.width()
12822     and str.size();
12823     </blockquote>
12824 <p>to</p>
12825     <blockquote>
12826     If bool(k) is true, determines padding as described in
12827     lib.facet.num.put.virtuals, and then inserts the resulting
12828     sequence of characters <tt>seq</tt> as if by calling
12829     <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where <tt>n</tt> is the larger of
12830     <tt>os.width()</tt> and <tt>str.size()</tt>;
12831      </blockquote>
12832
12833 <p><i>[Kona: it appears that neither the original wording, DR25, nor the
12834   proposed resolution, is quite what we want.  We want to say that
12835   the string will be output, padded to os.width() if necessary.  We
12836   don't want to duplicate the padding rules in clause 22, because
12837   they're complicated, but we need to be careful because they weren't
12838   quite written with quite this case in mind.  We need to say what
12839   the character sequence is, and then defer to clause 22.  Post-Kona:
12840   Benjamin provided wording.]</i></p>
12841
12842 <hr>
12843 <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>
12844 <p>
12845 Is "const std::ctype&lt;char&gt;" a valid template argument to has_facet, use_facet,
12846 and the locale template ctor? And if so, does it designate the same Facet as
12847 the non-const "std::ctype&lt;char&gt;?" What about "volatile std::ctype&lt;char&gt;?"
12848 Different implementations behave differently: some fail to compile, others
12849 accept such types but behave inconsistently.
12850 </p>
12851 <p><b>Proposed resolution:</b></p>
12852 <p>Change 22.1.1.1.2, p1 to read:</p>
12853
12854 <p>Template parameters in this clause which are required to be facets
12855 are those named Facet in declarations. A program that passes a type
12856 that is not a facet, or a type that refers to volatile-qualified
12857 facet, as an (explicit or deduced) template parameter to a locale
12858 function expecting a facet, is ill-formed.  A const-qualified facet is
12859 a valid template argument to any locale function that expects a Facet
12860 template parameter.</p>
12861
12862 <p><i>[Kona: changed the last sentence from a footnote to normative
12863 text.]</i></p>
12864
12865 <hr>
12866 <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>
12867
12868 <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
12869 noticed with statements like:</p>
12870 <pre>vector&lt;int&gt; v(10, 1);
12871 </pre>
12872
12873 <p>The intent of the above statement was to construct with:</p>
12874 <pre>vector(size_type, const value_type&amp;);
12875 </pre>
12876
12877 <p>but early implementations failed to compile as they bound to:</p>
12878 <pre>template &lt;class InputIterator&gt;
12879 vector(InputIterator f, InputIterator l);
12880 </pre>
12881 <p>instead.</p>
12882
12883 <p>Paragraphs 9-11 say that if InputIterator is an integral type, then the
12884 member template constructor will have the same effect as:</p>
12885 <pre>vector&lt;static_cast&lt;size_type&gt;(f), static_cast&lt;value_type&gt;(l));
12886 </pre>
12887 <p>(and similarly for the other member template functions of sequences).</p>
12888
12889 <p>There is also a note that describes one implementation technique:</p>
12890 <blockquote>
12891    One way that sequence implementors can satisfy this requirement is to
12892    specialize the member template for every integral type.
12893 </blockquote>
12894
12895 <p>This might look something like:</p>
12896 <blockquote>
12897 <pre>template &lt;class T&gt;
12898 struct vector
12899 {
12900      typedef unsigned size_type;
12901
12902      explicit vector(size_type) {}
12903      vector(size_type, const T&amp;) {}
12904
12905      template &lt;class I&gt;
12906      vector(I, I);
12907
12908      // ...
12909 };
12910
12911 template &lt;class T&gt;
12912 template &lt;class I&gt;
12913 vector&lt;T&gt;::vector(I, I) { ... }
12914
12915 template &lt;&gt;
12916 template &lt;&gt;
12917 vector&lt;int&gt;::vector(int, int) { ... }
12918
12919 template &lt;&gt;
12920 template &lt;&gt;
12921 vector&lt;int&gt;::vector(unsigned, unsigned) { ... }
12922
12923 //  ...
12924 </pre>
12925 </blockquote>
12926
12927 <p>Label this solution 'A'.</p>
12928
12929 <p>The standard also says:</p>
12930 <blockquote>
12931  Less cumbersome implementation techniques also exist.
12932 </blockquote>
12933 <p>
12934 A popular technique is to not specialize as above, but instead catch
12935 every call with the member template, detect the type of InputIterator,
12936 and then redirect to the correct logic.  Something like:
12937 </p>
12938 <blockquote>
12939 <pre>template &lt;class T&gt;
12940 template &lt;class I&gt;
12941 vector&lt;T&gt;::vector(I f, I l)
12942 {
12943      choose_init(f, l, int2type&lt;is_integral&lt;I&gt;::value&gt;());
12944 }
12945
12946 template &lt;class T&gt;
12947 template &lt;class I&gt;
12948 vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;false&gt;)
12949 {
12950     // construct with iterators
12951 }
12952
12953 template &lt;class T&gt;
12954 template &lt;class I&gt;
12955 vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;true&gt;)
12956 {
12957     size_type sz = static_cast&lt;size_type&gt;(f);
12958     value_type v = static_cast&lt;value_type&gt;(l);
12959     // construct with sz,v
12960 }
12961 </pre>
12962 </blockquote>
12963
12964 <p>Label this solution 'B'.</p>
12965
12966 <p>Both of these solutions solve the case the standard specifically
12967 mentions:</p>
12968 <pre>vector&lt;int&gt; v(10, 1);  // ok, vector size 10, initialized to 1
12969 </pre>
12970
12971 <p>
12972 However, (and here is the problem), the two solutions have different
12973 behavior in some cases where the value_type of the sequence is not an
12974 integral type.  For example consider:
12975 </p>
12976 <blockquote><pre>     pair&lt;char, char&gt;                     p('a', 'b');
12977      vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
12978 </pre></blockquote>
12979 <p>
12980 The second line of this snippet is likely an error.  Solution A catches
12981 the error and refuses to compile.  The reason is that there is no
12982 specialization of the member template constructor that looks like:
12983 </p>
12984 <pre>template &lt;&gt;
12985 template &lt;&gt;
12986 vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;::vector(char, char) { ... }
12987 </pre>
12988
12989 <p>
12990 So the expression binds to the unspecialized member template
12991 constructor, and then fails (compile time) because char is not an
12992 InputIterator.
12993 </p>
12994
12995 <p>
12996 Solution B compiles the above example though.  'a' is casted to an
12997 unsigned integral type and used to size the outer vector.  'b' is
12998 static casted to the inner vector using it's explicit constructor:
12999 </p>
13000
13001 <pre>explicit vector(size_type n);
13002 </pre>
13003
13004 <p>
13005 and so you end up with a static_cast&lt;size_type&gt;('a') by
13006 static_cast&lt;size_type&gt;('b') matrix.
13007 </p>
13008
13009 <p>
13010 It is certainly possible that this is what the coder intended.  But the
13011 explicit qualifier on the inner vector has been thwarted at any rate.
13012 </p>
13013
13014 <p>
13015 The standard is not clear whether the expression:
13016 </p>
13017
13018 <pre>     vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
13019 </pre>
13020
13021 <p>
13022 (and similar expressions) are:
13023 </p>
13024
13025 <ol>
13026 <li>  undefined behavior.</li>
13027 <li>  illegal and must be rejected.</li>
13028 <li>  legal and must be accepted.</li>
13029 </ol>
13030
13031 <p>My preference is listed in the order presented.</p>
13032
13033 <p>There are still other techniques for implementing the requirements of
13034 paragraphs 9-11, namely the "restricted template technique" (e.g.
13035 enable_if).  This technique is the most compact and easy way of coding
13036 the requirements, and has the behavior of #2 (rejects the above
13037 expression).
13038 </p>
13039
13040 <p>
13041 Choosing 1 would allow all implementation techniques I'm aware of.
13042 Choosing 2 would allow only solution 'A' and the enable_if technique.
13043 Choosing 3 would allow only solution 'B'.
13044 </p>
13045
13046 <p>
13047 Possible wording for a future standard if we wanted to actively reject
13048 the expression above would be to change "static_cast" in paragraphs
13049 9-11 to "implicit_cast" where that is defined by:
13050 </p>
13051
13052 <blockquote>
13053 <pre>template &lt;class T, class U&gt;
13054 inline
13055 T implicit_cast(const U&amp; u)
13056 {
13057      return u;
13058 }
13059 </pre>
13060 </blockquote>
13061
13062 <p><b>Proposed resolution:</b></p>
13063
13064 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:
13065
13066 <p>For every sequence defined in this clause and in clause lib.strings:</p>
13067
13068 <ul>
13069   <li>
13070     <p>If the constructor</p>
13071        <pre>       template &lt;class InputIterator&gt;
13072        X(InputIterator f, InputIterator l,
13073          const allocator_type&amp; a = allocator_type())
13074        </pre>
13075     <p>is called with a type InputIterator that does not qualify as
13076     an input iterator, then the constructor will behave as if the
13077     overloaded constructor:</p>
13078        <pre>       X(size_type, const value_type&amp; = value_type(),
13079          const allocator_type&amp; = allocator_type())
13080        </pre>
13081     <p>were called instead, with the arguments static_cast&lt;size_type&gt;(f), l and a, respectively.</p>
13082   </li>
13083
13084   <li>
13085     <p>If the member functions of the forms:</p>
13086        <pre>       template &lt;class InputIterator&gt;          //  such as  insert()
13087        rt fx1(iterator p, InputIterator f, InputIterator l);
13088
13089        template &lt;class InputIterator&gt;          //  such as  append(), assign()
13090        rt fx2(InputIterator f, InputIterator l);
13091
13092        template &lt;class InputIterator&gt;          //  such as  replace()
13093        rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l);
13094        </pre>
13095     <p>are called with a type InputIterator that does not qualify as
13096     an input iterator, then these functions will behave as if the
13097     overloaded member functions:</p>
13098        <pre>       rt fx1(iterator, size_type, const value_type&amp;);
13099
13100        rt fx2(size_type, const value_type&amp;);
13101
13102        rt fx3(iterator, iterator, size_type, const value_type&amp;);
13103        </pre>
13104     <p>were called instead, with the same arguments.</p>
13105   </li>
13106 </ul>
13107
13108 <p>In the previous paragraph the alternative binding will fail if f
13109 is not implicitly convertible to X::size_type or if l is not implicitly
13110 convertible to X::value_type.</p>
13111
13112 <p>
13113 The extent to which an implementation determines that a type cannot be
13114 an input iterator is unspecified, except that as a minimum integral
13115 types shall not qualify as input iterators.
13116 </p>
13117
13118
13119
13120 <p><i>[
13121 Kona: agreed that the current standard requires <tt>v('a', 'b')</tt>
13122 to be accepted, and also agreed that this is surprising behavior.  The
13123 LWG considered several options, including something like
13124 implicit_cast, which doesn't appear to be quite what we want.  We
13125 considered Howards three options: allow acceptance or rejection,
13126 require rejection as a compile time error, and require acceptance.  By
13127 straw poll (1-6-1), we chose to require a compile time error.
13128 Post-Kona: Howard provided wording.
13129 ]</i></p>
13130
13131 <p><i>[
13132 Sydney: The LWG agreed with this general direction, but there was some
13133 discomfort with the wording in the original proposed resolution.
13134 Howard submitted new wording, and we will review this again in
13135 Redmond.
13136 ]</i></p>
13137
13138 <p><i>[Redmond: one very small change in wording: the first argument
13139   is cast to size_t.  This fixes the problem of something like
13140   <tt>vector&lt;vector&lt;int&gt; &gt;(5, 5)</tt>, where int is not
13141   implicitly convertible to the value type.]</i></p>
13142
13143 <p><b>Rationale:</b></p>
13144 <p>The proposed resolution fixes:</p>
13145
13146 <pre>  vector&lt;int&gt; v(10, 1);
13147 </pre>
13148
13149 <p>
13150 since as integral types 10 and 1 must be disqualified as input
13151 iterators and therefore the (size,value) constructor is called (as
13152 if).</p>
13153
13154 <p>The proposed resolution breaks:</p>
13155
13156 <pre>  vector&lt;vector&lt;T&gt; &gt; v(10, 1);
13157 </pre>
13158
13159 <p>
13160 because the integral type 1 is not *implicitly* convertible to
13161 vector&lt;T&gt;.  The wording above requires a diagnostic.</p>
13162
13163 <p>
13164 The proposed resolution leaves the behavior of the following code
13165 unspecified.
13166 </p>
13167
13168 <pre>  struct A
13169   {
13170     operator int () const {return 10;}
13171   };
13172
13173   struct B
13174   {
13175     B(A) {}
13176   };
13177
13178   vector&lt;B&gt; v(A(), A());
13179 </pre>
13180
13181 <p>
13182 The implementation may or may not detect that A is not an input
13183 iterator and employee the (size,value) constructor.  Note though that
13184 in the above example if the B(A) constructor is qualified explicit,
13185 then the implementation must reject the constructor as A is no longer
13186 implicitly convertible to B.
13187 </p>
13188 <hr>
13189 <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>
13190 <p>
13191 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
13192 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.
13193 </p>
13194 <p><b>Proposed resolution:</b></p>
13195 <p>
13196 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
13197 <tt>fpos&lt;stateT&gt;::state()</tt> to const.
13198 </p>
13199 <hr>
13200 <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>
13201 <p>
13202 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
13203 basic_ostream&lt;charT, traits&gt;::sentry::operator bool() is declared
13204 as non const, but in section 27.6.2.3, in synopsis it is declared
13205 const.
13206 </p>
13207 <p><b>Proposed resolution:</b></p>
13208 <p>
13209 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
13210 of <tt>sentry::operator bool()</tt> to const.
13211 </p>
13212 <hr>
13213 <a name="443"><h3>443.&nbsp;filebuf::close() inconsistent use of EOF</h3></a><p><b>Section:</b>&nbsp;27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;20 Nov 2003</p>
13214 <p>
13215 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
13216 basic_filebuf&lt;charT, traits&gt;::close(), overflow(EOF) is used twice;
13217 should be overflow(traits::eof()).
13218 </p>
13219 <p><b>Proposed resolution:</b></p>
13220 <p>
13221 Change overflow(EOF) to overflow(traits::eof()).
13222 </p>
13223 <hr>
13224 <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>
13225 <p>
13226 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
13227 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>.
13228 </p>
13229 <p><b>Proposed resolution:</b></p>
13230
13231 <p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away
13232  constness. The other two places are stylistic: we could change the
13233  C-style casts to const_cast. Post-Sydney: Howard provided wording.
13234 ]</i></p>
13235
13236 <p>Change 27.8.1.7/1 from:</p>
13237 <blockquote>
13238   Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
13239 </blockquote>
13240
13241 <p>to:</p>
13242 <blockquote>
13243   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
13244 </blockquote>
13245
13246 <p>Change 27.8.1.10/1 from:</p>
13247 <blockquote>
13248   Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
13249 </blockquote>
13250
13251 <p>to:</p>
13252 <blockquote>
13253   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
13254 </blockquote>
13255
13256 <p>Change 27.8.1.13/1 from:</p>
13257 <blockquote>
13258   Returns: &amp;sb.
13259 </blockquote>
13260
13261 <p>to:</p>
13262 <blockquote>
13263   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
13264 </blockquote>
13265
13266
13267
13268 <hr>
13269 <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>
13270 <p>
13271 The standard places no restrictions at all on the reference type
13272 of input, output, or forward iterators (for forward iterators it
13273 only specifies that *x must be value_type&amp; and doesn't mention
13274 the reference type).  Bidirectional iterators' reference type is
13275 restricted only by implication, since the base iterator's
13276 reference type is used as the return type of reverse_iterator's
13277 operator*, which must be T&amp; in order to be a conforming forward
13278 iterator.
13279 </p>
13280
13281 <p>
13282 Here's what I think we ought to be able to expect from an input
13283 or forward iterator's reference type R, where a is an iterator
13284 and V is its value_type
13285 </p>
13286
13287 <ul>
13288   <li>
13289       *a is convertible to R
13290   </li>
13291
13292   <li>
13293       R is convertible to V
13294   </li>
13295
13296   <li>
13297       static_cast&lt;V&gt;(static_cast&lt;R&gt;(*a)) is equivalent to
13298       static_cast&lt;V&gt;(*a)
13299   </li>
13300 </ul>
13301
13302 <p>A mutable forward iterator ought to satisfy, for x of type V:</p>
13303   <li>
13304       { R r = *a; r = x; } is equivalent to *a = x;
13305   </li>
13306
13307 <p>
13308 I think these requirements capture existing container iterators
13309 (including vector&lt;bool&gt;'s), but render istream_iterator invalid;
13310 its reference type would have to be changed to a constant
13311 reference.
13312 </p>
13313
13314
13315 <p>
13316 (Jeremy Siek) During the discussion in Sydney, it was felt that a
13317 simpler long term solution for this was needed. The solution proposed
13318 was to require <tt>reference</tt> to be the same type as <tt>*a</tt>
13319 and <tt>pointer</tt> to be the same type as <tt>a-&gt;</tt>.  Most
13320 iterators in the Standard Library already meet this requirement. Some
13321 iterators are output iterators, and do not need to meet the
13322 requirement, and others are only specified through the general
13323 iterator requirements (which will change with this resolution). The
13324 sole case where there is an explicit definition of the reference type
13325 that will need to change is <tt>istreambuf_iterator</tt> which returns
13326 <tt>charT</tt> from <tt>operator*</tt> but has a reference type of
13327 <tt>charT&amp;</tt>. We propose changing the reference type of
13328 <tt>istreambuf_iterator</tt> to <tt>charT</tt>.
13329 </p>
13330
13331 <p>The other option for resolving the issue with <tt>pointer</tt>,
13332   mentioned in the note below, is to remove <tt>pointer</tt>
13333   altogether. I prefer placing requirements on <tt>pointer</tt> to
13334   removing it for two reasons. First, <tt>pointer</tt> will become
13335   useful for implementing iterator adaptors and in particular,
13336   <tt>reverse_iterator</tt> will become more well defined. Second,
13337   removing <tt>pointer</tt> is a rather drastic and publicly-visible
13338   action to take.</p>
13339
13340 <p>The proposed resolution technically enlarges the requirements for
13341 iterators, which means there are existing iterators (such as
13342 <tt>istreambuf_iterator</tt>, and potentially some programmer-defined
13343 iterators) that will no longer meet the requirements. Will this break
13344 existing code? The scenario in which it would is if an algorithm
13345 implementation (say in the Standard Library) is changed to rely on
13346 <tt>iterator_traits::reference</tt>, and then is used with one of the
13347 iterators that do not have an appropriately defined
13348 <tt>iterator_traits::reference</tt>.
13349 </p>
13350
13351
13352 <p>The proposed resolution makes one other subtle change. Previously,
13353 it was required that output iterators have a <tt>difference_type</tt>
13354 and <tt>value_type</tt> of <tt>void</tt>, which means that a forward
13355 iterator could not be an output iterator. This is clearly a mistake,
13356 so I've changed the wording to say that those types may be
13357 <tt>void</tt>.
13358 </p>
13359
13360 <p><b>Proposed resolution:</b></p>
13361
13362 <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>
13363
13364 <blockquote>
13365 be defined as the iterator's difference type, value type and iterator
13366 category, respectively.
13367 </blockquote>
13368
13369 <p>add</p>
13370
13371 <blockquote>
13372 In addition, the types
13373 <pre>iterator_traits&lt;Iterator&gt;::reference
13374 iterator_traits&lt;Iterator&gt;::pointer
13375 </pre>
13376 must be defined as the iterator's reference and pointer types, that
13377 is, the same type as the type of <tt>*a</tt> and <tt>a-&gt;</tt>,
13378 respectively.
13379 </blockquote>
13380
13381 <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>
13382
13383 <blockquote>
13384 In the case of an output iterator, the types
13385 <pre>iterator_traits&lt;Iterator&gt;::difference_type
13386 iterator_traits&lt;Iterator&gt;::value_type
13387 </pre>
13388 are both defined as <tt>void</tt>.
13389 </blockquote>
13390
13391 <p>to:</p>
13392 <blockquote>
13393 In the case of an output iterator, the types
13394 <pre>iterator_traits&lt;Iterator&gt;::difference_type
13395 iterator_traits&lt;Iterator&gt;::value_type
13396 iterator_traits&lt;Iterator&gt;::reference
13397 iterator_traits&lt;Iterator&gt;::pointer
13398 </pre>
13399 may be defined as <tt>void</tt>.
13400 </blockquote>
13401
13402 <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>
13403 <blockquote>
13404 <pre>typename traits::off_type, charT*, charT&amp;&gt;
13405 </pre>
13406 </blockquote>
13407 <p>to:</p>
13408 <blockquote>
13409 <pre>typename traits::off_type, charT*, charT&gt;
13410 </pre>
13411 </blockquote>
13412
13413 <p><i>[
13414 Redmond: there was concern in Sydney that this might not be the only place
13415 where things were underspecified and needed to be changed.  Jeremy
13416 reviewed iterators in the standard and confirmed that nothing else
13417 needed to be changed.
13418 ]</i></p>
13419
13420 <hr>
13421 <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>
13422 <p>
13423 Table 76, the random access iterator requirement table, says that the
13424 return type of a[n] must be "convertible to T".  When an iterator's
13425 value_type T is an abstract class, nothing is convertible to T.
13426 Surely this isn't an intended restriction?
13427 </p>
13428 <p><b>Proposed resolution:</b></p>
13429 <p>
13430 Change the return type to "convertible to T const&amp;".
13431 </p>
13432 <hr>
13433 <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>
13434 <p>Original text:</p>
13435 <blockquote>
13436 The macro offsetof accepts a restricted set of type arguments in this
13437 International Standard. type shall be a POD structure or a POD union
13438 (clause 9). The result of applying the offsetof macro to a field that
13439 is a static data member or a function member is undefined."
13440 </blockquote>
13441
13442 <p>Revised text:</p>
13443 <blockquote>
13444 "If type is not a POD structure or a POD union the results are undefined."
13445 </blockquote>
13446
13447 <p>
13448 Looks to me like the revised text should have replaced only the second
13449 sentence. It doesn't make sense standing alone.
13450 </p>
13451
13452 <p><b>Proposed resolution:</b></p>
13453 <p>Change 18.1, paragraph 5, to:</p>
13454
13455 <blockquote>
13456 The macro offsetof accepts a restricted set of type arguments in this
13457 International Standard.  If type is not a POD structure or a POD union
13458 the results are undefined.  The result of applying the offsetof macro
13459 to a field that is a static data member or a function member is
13460 undefined."
13461 </blockquote>
13462 <hr>
13463 <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>
13464 <pre>  pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
13465                                     ios_base::openmode);
13466 </pre>
13467 <p>
13468 is obliged to fail if nothing has been inserted into the stream. This
13469 is unnecessary and undesirable. It should be permissible to seek to
13470 an effective offset of zero.</p>
13471
13472 <p><i>[
13473  Sydney: Agreed that this is an annoying problem: seeking to zero should be
13474  legal. Bill will provide wording.
13475 ]</i></p>
13476
13477 <p><b>Proposed resolution:</b></p>
13478 <p>Change the sentence from:</p>
13479 <blockquote>
13480 For a sequence to be positioned, if its next pointer (either
13481 gptr() or pptr()) is a null pointer, the positioning operation
13482 fails.
13483 </blockquote>
13484
13485 <p>to:</p>
13486
13487 <blockquote>
13488 For a sequence to be positioned, if its next pointer (either
13489 gptr() or pptr()) is a null pointer and the new offset newoff
13490 is nonzero, the positioning operation fails.
13491 </blockquote>
13492 <hr>
13493 <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>
13494 <p>
13495 Both cerr::tie() and wcerr::tie() are obliged to be null at program
13496 startup. This is overspecification and overkill. It is both traditional
13497 and useful to tie cerr to cout, to ensure that standard output is drained
13498 whenever an error message is written. This behavior should at least be
13499 permitted if not required. Same for wcerr::tie().
13500 </p>
13501 <p><b>Proposed resolution:</b></p>
13502
13503 <p>Add to the description of cerr:</p>
13504 <blockquote>
13505 After the object cerr is initialized, cerr.tie() returns &amp;cout.
13506 Its state is otherwise the same as required for basic_ios&lt;char&gt;::init
13507 (lib.basic.ios.cons).
13508 </blockquote>
13509
13510 <p>Add to the description of wcerr:</p>
13511
13512 <blockquote>
13513 After the object wcerr is initialized, wcerr.tie() returns &amp;wcout.
13514 Its state is otherwise the same as required for basic_ios&lt;wchar_t&gt;::init
13515 (lib.basic.ios.cons).
13516 </blockquote>
13517
13518 <p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just
13519   permit, cout and cerr to be tied on startup.  Pre-Redmond: Bill will
13520   provide wording.]</i></p>
13521 <hr>
13522 <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>
13523 <p>
13524 The constructor from unsigned long says it initializes "the first M
13525 bit positions to the corresponding bit values in val. M is the smaller
13526 of N and the value CHAR_BIT * sizeof(unsigned long)."
13527 </p>
13528
13529 <p>
13530 Object-representation vs. value-representation strikes again. CHAR_BIT *
13531 sizeof (unsigned long) does not give us the number of bits an unsigned long
13532 uses to hold the value. Thus, the first M bit position above is not
13533 guaranteed to have any corresponding bit values in val.
13534 </p>
13535 <p><b>Proposed resolution:</b></p>
13536 <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
13537   N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
13538   "<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in
13539   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
13540   long</tt>."
13541 </p>
13542 <hr>
13543 <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>
13544 <p>
13545 The second parameters of the non-default constructor and of the open
13546 member function for basic_fstream, named "mode", are optional
13547 according to the class declaration in 27.8.1.11 [lib.fstream].  The
13548 specifications of these members in 27.8.1.12 [lib.fstream.cons] and
13549 27.8.1.13 lib.fstream.members] disagree with this, though the
13550 constructor declaration has the "explicit" function-specifier implying
13551 that it is intended to be callable with one argument.
13552 </p>
13553 <p><b>Proposed resolution:</b></p>
13554 <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>
13555 <pre>  explicit basic_fstream(const char* s, ios_base::openmode mode);
13556 </pre>
13557 <p>to</p>
13558 <pre>  explicit basic_fstream(const char* s,
13559                          ios_base::openmode mode = ios_base::in|ios_base::out);
13560 </pre>
13561 <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>
13562 <pre>  void open(const char*s, ios_base::openmode mode);
13563 </pre>
13564 <p>to</p>
13565   void open(const char*s,
13566             ios_base::openmode mode = ios_base::in|ios_base::out);
13567 <hr>
13568 <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>
13569 <p>
13570 Template time_get currently contains difficult, if not impossible,
13571 requirements for do_date_order, do_get_time, and do_get_date. All require
13572 the implementation to scan a field generated by the %x or %X conversion
13573 specifier in strftime. Yes, do_date_order can always return no_order, but
13574 that doesn't help the other functions. The problem is that %x can be
13575 nearly anything, and it can vary widely with locales. It's horribly
13576 onerous to have to parse "third sunday after Michaelmas in the year of
13577 our Lord two thousand and three," but that's what we currently ask of
13578 do_get_date. More practically, it leads some people to think that if
13579 %x produces 10.2.04, we should know to look for dots as separators. Still
13580 not easy.
13581 </p>
13582
13583 <p>
13584 Note that this is the <i>opposite</i> effect from the intent stated in the
13585 footnote earlier in this subclause:
13586 </p>
13587
13588 <blockquote>
13589 "In other words, user confirmation is required for reliable parsing of
13590 user-entered dates and times, but machine-generated formats can be
13591 parsed reliably. This allows parsers to be aggressive about interpreting
13592 user variations on standard formats."
13593 </blockquote>
13594
13595 <p>
13596 We should give both implementers and users an easier and more reliable
13597 alternative: provide a (short) list of alternative delimiters and say
13598 what the default date order is for no_order. For backward compatibility,
13599 and maximum latitude, we can permit an implementation to parse whatever
13600 %x or %X generates, but we shouldn't require it.
13601 </p>
13602 <p><b>Proposed resolution:</b></p>
13603
13604 <p><b>In the description:</b></p>
13605 <pre>iter_type do_get_time(iter_type s, iter_type end, ios_base&amp; str,
13606         ios_base::iostate&amp; err, tm* t) const;
13607 </pre>
13608
13609 <p>
13610 2 Effects: Reads characters starting at suntil it has extracted those
13611 struct tm members, and remaining format characters, used by
13612 time_put&lt;&gt;::put to produce the format specified by 'X', or until it
13613 encounters an error or end of sequence.
13614 </p>
13615
13616 <p><b>change:</b> 'X'</p>
13617
13618 <p><b>to:</b> "%H:%M:%S"</p>
13619
13620
13621 <p>Change</p>
13622 <pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
13623         ios_base::iostate&amp; err, tm* t) const;
13624
13625 4 Effects: Reads characters starting at s until it has extracted those
13626 struct tm members, and remaining format characters, used by
13627 time_put&lt;&gt;::put to produce the format specified by 'x', or until it
13628 encounters an error.
13629 </pre>
13630
13631 <p>to</p>
13632 iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
13633         ios_base::iostate&amp; err, tm* t) const;
13634
13635 4 Effects: Reads characters starting at s until it has extracted those
13636 struct tm members, and remaining format characters, used by
13637 time_put&lt;&gt;::put to produce one of the following formats, or until it
13638 encounters an error. The format depends on the value returned by
13639 date_order() as follows:
13640
13641         date_order()  format
13642
13643         no_order      "%m/%d/%y"
13644         dmy           "%d/%m/%y"
13645         mdy           "%m/%d/%y"
13646         ymd           "%y/%m/%d"
13647         ydm           "%y/%d/%m"
13648
13649 An implementation may also accept additional implementation-defined formats.
13650 <pre></pre>
13651
13652 <p><i>[Redmond: agreed that this is a real problem.  The solution is
13653   probably to match C99's parsing rules.  Bill provided wording.
13654 ]</i></p>
13655
13656 <hr>
13657 <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>
13658
13659 <p>To add slightly more convenience to vector&lt;T&gt; and map&lt;Key,T&gt; we should consider to add</p>
13660 <ol>
13661 <li> add vector&lt;T&gt;::data() member (const and non-const version)
13662 semantics: if( empty() ) return 0; else return buffer_;</li>
13663 <li> add map&lt;Key,T&gt;::at( const Key&amp; k ) member (const and non-const version)
13664 <i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
13665 </ol>
13666
13667 <p>Rationale:</p>
13668
13669 <ul>
13670 <li>To obtain a pointer to the vector's buffer, one must use either
13671 operator[]() (which can give undefined behavior for empty vectors) or
13672 at() (which will then throw if the vector is empty). </li>
13673 <li>tr1::array&lt;T,sz&gt; already has a data() member</li>
13674 <li>e cannot use operator[]() when T is not DefaultDonstructible</li>
13675 <li>Neither when the map is const.</li>
13676 <li>when we want to make sure we don't add an element accidently</li>
13677 <li>when it should be considered an error if a key is not in the map</li>
13678 </ul>
13679
13680 <p><b>Proposed resolution:</b></p>
13681 <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>
13682   synopsis after "element access" and before "modifiers":</p>
13683 <pre>  // <i>[lib.vector.data] data access</i>
13684   pointer       data();
13685   const_pointer data() const;
13686 </pre>
13687
13688 <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>
13689 <blockquote>
13690 <p>23.2.4.x <tt>vector</tt> data access</p>
13691 <pre>   pointer       data();
13692    const_pointer data() const;
13693 </pre>
13694 <p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
13695    range.  For a non-empty vector, data() == &amp;front().</p>
13696 <p><b>Complexity:</b> Constant time.</p>
13697 <p><b>Throws:</b> Nothing.</p>
13698 </blockquote>
13699
13700 <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>
13701 synopsis immediately after the line for operator[]:</p>
13702 <pre>  T&amp;       at(const key_type&amp; x);
13703   const T&amp; at(const key_type&amp; x) const;
13704 </pre>
13705
13706 <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>
13707 <blockquote>
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><b>Returns:</b> A reference to the element whose key is equivalent
13713   to x, if such an element is present in the map.</p>
13714 <p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
13715
13716 </blockquote>
13717
13718 <p><b>Rationale:</b></p>
13719 <p>Neither of these additions provides any new functionality but the
13720   LWG agreed that they are convenient, especially for novices.  The
13721   exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
13722   was chosen to match <tt>vector::at</tt>.</p>
13723 <hr>
13724 <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>
13725 <p>C header &lt;iso646.h&gt; defines macros for some operators, such as
13726 not_eq for !=.</p>
13727
13728 <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
13729 clauses 18 through 27, the &lt;cname&gt; C++ header contents are the same
13730 as the C header &lt;name.h&gt;. In particular, table 12 lists
13731 &lt;ciso646&gt; as a C++ header.</p>
13732
13733 <p>I don't find any other mention of &lt;ciso646&gt;, or any mention of
13734 &lt;iso646.h&gt;, in clauses 17 thorough 27. That implies that the
13735 contents of &lt;ciso646&gt; are the same as C header &lt;iso646.h&gt;.</p>
13736
13737 <p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
13738 "Header &lt;iso646.h&gt;" says that the alternative tokens are not
13739 defined as macros in &lt;ciso646&gt;, but does not mention the contents
13740 of &lt;iso646.h&gt;.</p>
13741
13742 <p>I don't find any normative text to support C.2.2.2.</p>
13743
13744 <p><b>Proposed resolution:</b></p>
13745 <p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
13746   paragraph 6 (the one about functions must be functions):</p>
13747
13748 <blockquote>
13749 <p>Identifiers that are keywords or operators in C++ shall not be defined
13750 as macros in C++ standard library headers.
13751 [Footnote:In particular, including the standard header &lt;iso646.h&gt;
13752 or &lt;ciso646&gt; has no effect. </p>
13753 </blockquote>
13754
13755 <p><i>[post-Redmond: Steve provided wording.]</i></p>
13756
13757 <hr>
13758 <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>
13759
13760 <p>
13761 Table 37 describes the requirements on Traits::compare() in terms of
13762 those on Traits::lt(). 21.1.3.1, p6 requires char_traits&lt;char&gt;::lt()
13763 to yield the same result as operator&lt;(char, char).
13764 </p>
13765
13766 <p>
13767 Most, if not all, implementations of char_traits&lt;char&gt;::compare()
13768 call memcmp() for efficiency. However, the C standard requires both
13769 memcmp() and strcmp() to interpret characters under comparison as
13770 unsigned, regardless of the signedness of char. As a result, all
13771 these char_traits implementations fail to meet the requirement
13772 imposed by Table 37 on compare() when char is signed.
13773 </p>
13774
13775
13776 <p>Read email thread starting with c++std-lib-13499 for more. </p>
13777 <p><b>Proposed resolution:</b></p>
13778
13779
13780 <p>Change 21.1.3.1, p6 from</p>
13781 <blockquote>
13782     The two-argument members assign, eq, and lt are defined identically
13783     to the built-in operators =, ==, and &lt; respectively.
13784 </blockquote>
13785 <p>to</p>
13786 <blockquote>
13787   The two-argument member assign is defined identically to
13788   the built-in operator =. The two
13789   argument members eq and lt are defined identically to
13790   the built-in operators == and &lt; for type unsigned char.
13791 </blockquote>
13792
13793 <p><i>[Redmond: The LWG agreed with this general direction, but we
13794   also need to change <tt>eq</tt> to be consistent with this change.
13795   Post-Redmond: Martin provided wording.]</i></p>
13796
13797 <hr>
13798 <a name="468"></a><h3><a name="468">468.&nbsp;unexpected consequences of ios_base::operator void*()</a></h3><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>
13799
13800 <p>The program below is required to compile but when run it typically
13801 produces unexpected results due to the user-defined conversion from
13802 std::cout or any object derived from basic_ios to void*.
13803 </p>
13804
13805 <pre>    #include &lt;cassert&gt;
13806     #include &lt;iostream&gt;
13807
13808     int main ()
13809     {
13810         assert (std::cin.tie () == std::cout);
13811         // calls std::cout.ios::operator void*()
13812     }
13813 </pre>
13814
13815 <p><b>Proposed resolution:</b></p>
13816
13817 <p>
13818 Replace std::basic_ios&lt;charT, traits&gt;::operator void*() with another
13819 conversion operator to some unspecified type that is guaranteed not
13820 to be convertible to any other type except for bool (a pointer-to-member
13821 might be one such suitable type). In addition, make it clear that the
13822 pointer type need not be a pointer to a complete type and when non-null,
13823 the value need not be valid.
13824 </p>
13825
13826 <p>Specifically, change in [lib.ios] the signature of</p>
13827 <pre>    operator void*() const;
13828 </pre>
13829 <p>to</p>
13830 <pre>    operator unspecified-bool-type() const;
13831 </pre>
13832 <p>and change [lib.iostate.flags], p1 from</p>
13833 <pre>    operator void*() const;
13834 </pre>
13835 <p>to</p>
13836 <pre>operator unspecified-bool-type() const;
13837
13838      -1- Returns: if fail() then a value that will evaluate false in a
13839       boolean context; otherwise a value that will evaluate true in a
13840       boolean context. The value type returned shall not be
13841       convertible to int.
13842
13843      -2- [Note: This conversion can be used in contexts where a bool
13844       is expected (e.g., an if condition); however, implicit
13845       conversions (e.g., to int) that can occur with bool are not
13846       allowed, eliminating some sources of user error. One possible
13847       implementation choice for this type is pointer-to-member.  - end
13848       note]
13849 </pre>
13850
13851 <p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
13852 <p><i>[Lillehammer: Doug provided revised wording for
13853   "unspecified-bool-type".]</i></p>
13854
13855 <hr>
13856 <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>
13857
13858 <p>
13859 The overloads of relational operators for vector&lt;bool&gt; specified
13860 in [lib.vector.bool] are redundant (they are semantically identical
13861 to those provided for the vector primary template) and may even be
13862 diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation
13863 in c++std-lib-13647).
13864 </p>
13865
13866 <p><b>Proposed resolution:</b></p>
13867 <p>
13868 Remove all overloads of overloads of relational operators for
13869 vector&lt;bool&gt; from [lib.vector.bool].
13870 </p>
13871 <hr>
13872 <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>
13873
13874 <p>
13875 I think Footnote 297 is confused. The paragraph it applies to seems
13876 quite clear in that widen() is only called if the object is not a char
13877 stream (i.e., not basic_ostream&lt;char&gt;), so it's irrelevant what the
13878 value of widen(c) is otherwise.
13879 </p>
13880 <p><b>Proposed resolution:</b></p>
13881 <p>
13882 I propose to strike the Footnote.
13883 </p>
13884 <hr>
13885 <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>
13886 <p>
13887 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>,
13888 the non-template assign() function has the signature</p>
13889
13890 <pre>  void assign( size_type n, const T&amp; t );
13891 </pre>
13892
13893 <p>The type, T, is not defined in this context.</p>
13894 <p><b>Proposed resolution:</b></p>
13895 <p>Replace "T" with "value_type".</p>
13896 <p>----- End of document -----</p>
13897 </body></html>