l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.1.0/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></head>
   3
   4 <body bgcolor="#ffffff" text="#000000">
   5 <table>
   6 <tbody><tr>
   7 <td align="left">Doc. no.</td>
   8 <td align="left">N1909=05-0169</td>
   9 </tr>
  10 <tr>
  11 <td align="left">Date:</td>
  12 <td align="left">2005-10-23</td>
  13 </tr>
  14 <tr>
  15 <td align="left">Project:</td>
  16 <td align="left">Programming Language C++</td>
  17 </tr>
  18 <tr>
  19 <td align="left">Reply to:</td>
  20 <td align="left">Howard Hinnant &lt;howard.hinnant@gmail.com&gt;</td>
  21 </tr>
  22 </tbody></table>
  23 <h1>C++ Standard Library Defect Report List (Revision R39)</h1>
  24   <p>Reference ISO/IEC IS 14882:1998(E)</p>
  25   <p>Also see:</p>
  26     <ul>
  27       <li>
  28 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
  29       <li>
  30 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
  31       <li>
  32 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
  33       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li>
  34       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
  35     </ul>
  36   <p>This document contains only library issues which have been closed
  37   by the Library Working Group (LWG) after being found to be defects
  38   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
  39   <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
  40   <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
  41   introductory material in that document also applies to this
  42   document.</p>
  43 <h2>Revision History</h2>
  44 <ul>
  45 <li>R39:
  46 2005-10-14 post-Mont Tremblant mailing.
  47 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>.
  48 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.
  49 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.
  50 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.
  51 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.
  52 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
  53 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
  54 </li>
  55 <li>R38:
  56 2005-07-03 pre-Mont Tremblant mailing.
  57 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>.
  58 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>
  59 </li>
  60 <li>R37:
  61 2005-06 mid-term mailing.
  62 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>.
  63 </li>
  64 <li>R36:
  65 2005-04 post-Lillehammer mailing. All issues in "ready" status except
  66 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
  67 previously in "DR" status were moved to "WP".
  68 </li>
  69 <li>R35:
  70 2005-03 pre-Lillehammer mailing.
  71 </li>
  72 <li>R34:
  73 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>.
  74 </li>
  75 <li>R33:
  76 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
  77 </li>
  78 <li>R32:
  79 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
  80 new issues received after the 2004-07 mailing.  Added
  81 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>.
  82 </li>
  83 <li>R31:
  84 2004-07 mid-term mailing: reflects new proposed resolutions and
  85 new issues received after the post-Sydney mailing.  Added
  86 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>.
  87 </li>
  88 <li>R30:
  89 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
  90 Voted all "Ready" issues from R29 into the working paper.
  91 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>.
  92 </li>
  93 <li>R29:
  94 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>.
  95 </li>
  96 <li>R28:
  97 Post-Kona mailing: reflects decisions made at the Kona meeting.
  98 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>.
  99 </li>
 100 <li>R27:
 101 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>.
 102 </li>
 103 <li>R26:
 104 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
 105 All issues in Ready status were voted into DR status.  All issues in
 106 DR status were voted into WP status.
 107 </li>
 108 <li>R25:
 109 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>.
 110 </li>
 111 <li>R24:
 112 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
 113 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
 114 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
 115 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
 116 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
 117 </li>
 118 <li>R23:
 119 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>.
 120 Moved issues in the TC to TC status.
 121 </li>
 122 <li>R22:
 123 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>.
 124 </li>
 125 <li>R21:
 126 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>.
 127 </li>
 128 <li>R20:
 129 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 130 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
 131 <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
 132 not discussed at the meeting.
 133
 134 All Ready issues were moved to DR status, with the exception of issues
 135 <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>.
 136
 137 Noteworthy issues discussed at Redmond include
 138 <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>,
 139 <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>.
 140 </li>
 141 <li>R19:
 142 Pre-Redmond mailing.  Added new issues
 143 <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>.
 144 </li>
 145 <li>R18:
 146 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
 147 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
 148 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>.
 149
 150 Changed status of issues
 151 <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>
 152 <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>
 153 <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>
 154 <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>
 155 <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>
 156 <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>
 157 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
 158 to DR.
 159
 160 Changed status of issues
 161 <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>
 162 <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>
 163 <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>
 164 <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>
 165 <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>
 166 <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>
 167 <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>
 168 <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>
 169 <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>
 170 to Ready.
 171
 172 Closed issues
 173 <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>
 174 <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>
 175 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
 176 as NAD.
 177
 178 </li>
 179 <li>R17:
 180 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 181 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>.
 182 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>.
 183 </li>
 184 <li>R16:
 185 post-Toronto mailing; reflects actions taken in Toronto. Added new
 186 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
 187 <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>,
 188 <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>,
 189 <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>,
 190 <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>,
 191 <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>,
 192 <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>,
 193 <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>,
 194 <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>,
 195 <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>,
 196 <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>,
 197 <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>,
 198 <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>,
 199 <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
 200 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
 201 <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
 202 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
 203 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
 204 the bug in enough places.
 205 </li>
 206 <li>R15:
 207 pre-Toronto mailing. Added issues
 208 <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
 209 changes so that we pass Weblint tests.
 210 </li>
 211 <li>R14:
 212 post-Tokyo II mailing; reflects committee actions taken in
 213 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)
 214 </li>
 215 <li>R13:
 216 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>.
 217 </li>
 218 <li>R12:
 219 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
 220 <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
 221 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
 222 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
 223 </li>
 224 <li>R11:
 225 post-Kona mailing: Updated to reflect LWG and full committee actions
 226 in Kona (99-0048/N1224). Note changed resolution of issues
 227 <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>
 228 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
 229 "closed" documents.  Changed the proposed resolution of issue
 230 <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
 231 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
 232 </li>
 233 <li>R10:
 234 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 235 <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>,
 236 <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
 237 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 238 </li>
 239 <li>R9:
 240 pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
 241 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
 242 "closed" documents. (99-0030/N1206, 25 Aug 99)
 243 </li>
 244 <li>R8:
 245 post-Dublin mailing. Updated to reflect LWG and full committee actions
 246 in Dublin. (99-0016/N1193, 21 Apr 99)
 247 </li>
 248 <li>R7:
 249 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>,
 250 <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>,
 251 <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>,
 252 <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)
 253 </li>
 254 <li>R6:
 255 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>,
 256 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 257 </li>
 258 <li>R5:
 259 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
 260 <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
 261 for making list public. (30 Dec 98)
 262 </li>
 263 <li>R4:
 264 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
 265 <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
 266 issues corrected. (22 Oct 98)
 267 </li>
 268 <li>R3:
 269 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>
 270 added, many issues updated to reflect LWG consensus (12 Oct 98)
 271 </li>
 272 <li>R2:
 273 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,
 274 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
 275 </li>
 276 <li>R1:
 277 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
 278 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
 279 </li>
 280 </ul>
 281 <h2>Defect Reports</h2>
 282 <hr>
 283 <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>
 284 <p>The change specified in the proposed resolution below did not make
 285 it into the Standard. This change was accepted in principle at the
 286 London meeting, and the exact wording below was accepted at the
 287 Morristown meeting.</p>
 288 <p><b>Proposed resolution:</b></p>
 289 <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
 290 from:</p>
 291
 292 <blockquote>
 293   <p>It is unspecified whether a name from the Standard C library
 294   declared with external linkage has either extern "C" or
 295   extern "C++" linkage.</p>
 296 </blockquote>
 297
 298 <p>to:</p>
 299
 300 <blockquote>
 301   <p>Whether a name from the Standard C library declared with external
 302   linkage has extern "C" or extern "C++" linkage
 303   is implementation defined. It is recommended that an implementation
 304   use extern "C++" linkage for this purpose.</p>
 305 </blockquote>
 306 <hr>
 307 <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>
 308 <p>We appear not to have covered all the possibilities of
 309  exit processing with respect to
 310 atexit registration. <br>
 311 <br>
 312 Example 1: (C and C++)</p>
 313
 314 <pre>    #include &lt;stdlib.h&gt;
 315     void f1() { }
 316     void f2() { atexit(f1); }
 317
 318     int main()
 319     {
 320         atexit(f2); // the only use of f2
 321         return 0; // for C compatibility
 322     }</pre>
 323
 324 <p>At program exit, f2 gets called due to its registration in
 325 main. Running f2 causes f1 to be newly registered during the exit
 326 processing. Is this a valid program? If so, what are its
 327 semantics?</p>
 328
 329 <p>
 330 Interestingly, neither the C standard, nor the C++ draft standard nor
 331 the forthcoming C9X Committee Draft says directly whether you can
 332 register a function with atexit during exit processing.</p>
 333
 334 <p>
 335 All 3 standards say that functions are run in reverse order of their
 336 registration. Since f1 is registered last, it ought to be run first,
 337 but by the time it is registered, it is too late to be first.</p>
 338
 339 <p>If the program is valid, the standards are self-contradictory about
 340 its semantics.</p>
 341
 342 <p>Example 2: (C++ only)</p>
 343
 344 <pre>
 345     void F() { static T t; } // type T has a destructor
 346
 347     int main()
 348     {
 349         atexit(F); // the only use of F
 350     }
 351 </pre>
 352
 353 <p>Function F registered with atexit has a local static variable t,
 354 and F is called for the first time during exit processing. A local
 355 static object is initialized the first time control flow passes
 356 through its definition, and all static objects are destroyed during
 357 exit processing. Is the code valid? If so, what are its semantics?</p>
 358
 359 <p>
 360 Section 18.3 "Start and termination" says that if a function
 361 F is registered with atexit before a static object t is initialized, F
 362 will not be called until after t's destructor completes.</p>
 363
 364 <p>
 365 In example 2, function F is registered with atexit before its local
 366 static object O could possibly be initialized. On that basis, it must
 367 not be called by exit processing until after O's destructor
 368 completes. But the destructor cannot be run until after F is called,
 369 since otherwise the object could not be constructed in the first
 370 place.</p>
 371
 372 <p>If the program is valid, the standard is self-contradictory about
 373 its semantics.</p>
 374
 375 <p>I plan to submit Example 1 as a public comment on the C9X CD, with
 376 a recommendation that the results be undefined. (Alternative: make it
 377 unspecified. I don't think it is worthwhile to specify the case where
 378 f1 itself registers additional functions, each of which registers
 379 still more functions.)</p>
 380
 381 <p>I think we should resolve the situation in the whatever way the C
 382 committee decides. </p>
 383
 384 <p>For Example 2, I recommend we declare the results undefined.</p>
 385
 386 <p><i>[See reflector message lib-6500 for further discussion.]</i></p>
 387
 388 <p><b>Proposed resolution:</b></p>
 389 <p>Change section 18.3/8 from:</p>
 390 <blockquote>
 391   First, objects with static storage duration are destroyed and
 392   functions registered by calling atexit are called. Objects with
 393   static storage duration are destroyed in the reverse order of the
 394   completion of their constructor.  (Automatic objects are not
 395   destroyed as a result of calling exit().) Functions registered with
 396   atexit are called in the reverse order of their registration.  A
 397   function registered with atexit before an object obj1 of static
 398   storage duration is initialized will not be called until obj1's
 399   destruction has completed. A function registered with atexit after
 400   an object obj2 of static storage duration is initialized will be
 401   called before obj2's destruction starts.
 402 </blockquote>
 403 <p>to:</p>
 404 <blockquote>
 405   First, objects with static storage duration are destroyed and
 406   functions registered by calling atexit are called. Non-local objects
 407   with static storage duration are destroyed in the reverse order of
 408   the completion of their constructor. (Automatic objects are not
 409   destroyed as a result of calling exit().) Functions registered with
 410   atexit are called in the reverse order of their registration, except
 411   that a function is called after any previously registered functions
 412   that had already been called at the time it was registered. A
 413   function registered with atexit before a non-local object obj1 of
 414   static storage duration is initialized will not be called until
 415   obj1's destruction has completed. A function registered with atexit
 416   after a non-local object obj2 of static storage duration is
 417   initialized will be called before obj2's destruction starts. A local
 418   static object obj3 is destroyed at the same time it would be if a
 419   function calling the obj3 destructor were registered with atexit at
 420   the completion of the obj3 constructor.
 421 </blockquote>
 422 <p><b>Rationale:</b></p>
 423 <p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
 424 supporting to the proposed resolution.</p>
 425 <hr>
 426 <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>
 427 <p>At the very end of the basic_string class definition is the signature: int
 428 compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
 429 following text this is defined as: returns
 430 basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
 431 basic_string&lt;charT,traits,Allocator&gt;(s,n2); </p>
 432
 433 <p>Since the constructor basic_string(const charT* s, size_type n, const Allocator&amp; a
 434 = Allocator()) clearly requires that s != NULL and n &lt; npos and further states that it
 435 throws length_error if n == npos, it appears the compare() signature above should always
 436 throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
 437 null terminated character array. </p>
 438
 439 <p>This appears to be a typo since the obvious intent is to allow either the call above or
 440 something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
 441
 442 <p>This would imply that what was really intended was two signatures int compare(size_type
 443 pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
 444 charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
 445 <p><b>Proposed resolution:</b></p>
 446 <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>
 447 (at the very end of the basic_string synopsis) which reads:</p>
 448
 449 <blockquote>
 450   <p><tt>int compare(size_type pos1, size_type n1,<br>
 451   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
 452   size_type n2 = npos) const;</tt></p>
 453 </blockquote>
 454
 455 <p>with:</p>
 456
 457 <blockquote>
 458   <p><tt>int compare(size_type pos1, size_type n1,<br>
 459   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s) const;<br>
 460   int compare(size_type pos1, size_type n1,<br>
 461   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
 462   size_type n2) const;</tt></p>
 463 </blockquote>
 464
 465 <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>
 466 paragraphs 5 and 6 which read:</p>
 467
 468 <blockquote>
 469   <p><tt>int compare(size_type pos, size_type n1,<br>
 470   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; charT * s, size_type n2
 471   = npos) const;<br>
 472   </tt>Returns:<tt><br>
 473   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 474   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 475   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
 476 </blockquote>
 477
 478 <p>with:</p>
 479
 480 <blockquote>
 481   <p><tt>int compare(size_type pos, size_type n1,<br>
 482   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s) const;<br>
 483   </tt>Returns:<tt><br>
 484   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 485   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 486   basic_string&lt;charT,traits,Allocator&gt;( s ))<br>
 487   <br>
 488   int compare(size_type pos, size_type n1,<br>
 489   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s,
 490   size_type n2) const;<br>
 491   </tt>Returns:<tt><br>
 492   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 493   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 494   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
 495 </blockquote>
 496
 497 <p>Editors please note that in addition to splitting the signature, the third argument
 498 becomes const, matching the existing synopsis.</p>
 499 <p><b>Rationale:</b></p>
 500 <p>While the LWG dislikes adding signatures, this is a clear defect in
 501 the Standard which must be fixed.&nbsp; The same problem was also
 502 identified in issues 7 (item 5) and 87.</p>
 503 <hr>
 504 <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>
 505 <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
 506 &lt;class InputIterator&gt; insert(iterator, InputIterator,
 507 InputIterator) makes no sense. It refers to a member function that
 508 doesn't exist. It also talks about the return value of a void
 509 function. </p>
 510
 511 <p>(2) Several versions of basic_string::replace don't appear in the
 512 class synopsis. </p>
 513
 514 <p>(3) basic_string::push_back appears in the synopsis, but is never
 515 described elsewhere.  In the synopsis its argument is const charT,
 516 which doesn't makes much sense; it should probably be charT, or
 517 possible const charT&amp;. </p>
 518
 519 <p>(4) basic_string::pop_back is missing. </p>
 520
 521 <p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
 522 = npos) make no sense. First, it's const charT* in the synopsis and
 523 charT* in the description. Second, given what it says in RETURNS,
 524 leaving out the final argument will always result in an exception
 525 getting thrown. This is paragraphs 5 and 6 of
 526 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>
 527
 528 <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>,
 529 there's a note for X::move(s, p, n). It says "Copies correctly
 530 even where p is in [s, s+n)". This is correct as far as it goes,
 531 but it doesn't go far enough; it should also guarantee that the copy
 532 is correct even where s in in [p, p+n). These are two orthogonal
 533 guarantees, and neither one follows from the other. Both guarantees
 534 are necessary if X::move is supposed to have the same sort of
 535 semantics as memmove (which was clearly the intent), and both
 536 guarantees are necessary if X::move is actually supposed to be
 537 useful. </p>
 538 <p><b>Proposed resolution:</b></p>
 539 <p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
 540 <br>
 541 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
 542 <br>
 543 ITEM 2:&nbsp; Not a defect; the Standard is clear.. There are ten versions of replace() in
 544 the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
 545 <br>
 546 ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
 547 [lib.basic.string]) from:</p>
 548
 549 <p>&nbsp;&nbsp;&nbsp;&nbsp; void push_back(const charT)<br>
 550 <br>
 551 to<br>
 552 <br>
 553 &nbsp;&nbsp;&nbsp;&nbsp; void push_back(charT)<br>
 554 <br>
 555 Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
 556 <br>
 557 &nbsp;&nbsp;&nbsp; void basic_string::push_back(charT c);<br>
 558 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to append(static_cast&lt;size_type&gt;(1), c);<br>
 559 <br>
 560 ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
 561 <br>
 562 ITEM 5: Duplicate; see issue 5 (and 87).<br>
 563 <br>
 564 ITEM 6: In table 37, Replace:<br>
 565 <br>
 566 &nbsp;&nbsp;&nbsp; "Copies correctly even where p is in [s, s+n)."<br>
 567 <br>
 568 with:<br>
 569 <br>
 570 &nbsp;&nbsp;&nbsp;&nbsp; "Copies correctly even where the ranges [p, p+n) and [s,
 571 s+n) overlap."</p>
 572 <hr>
 573 <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>
 574 <p>It appears there's an important guarantee missing from clause
 575 22. We're told that invoking locale::global(L) sets the C locale if L
 576 has a name. However, we're not told whether or not invoking
 577 setlocale(s) sets the global C++ locale. </p>
 578
 579 <p>The intent, I think, is that it should not, but I can't find any
 580 such words anywhere. </p>
 581 <p><b>Proposed resolution:</b></p>
 582 <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>,
 583 paragraph 2:&nbsp; </p>
 584
 585 <blockquote>
 586   <p>No library function other than <tt>locale::global()</tt> shall affect
 587   the value returned by <tt>locale()</tt>. </p>
 588
 589 </blockquote>
 590 <hr>
 591 <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>
 592 <p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
 593 section 3.7.3.1 of CD2 seems to allow for the possibility that all
 594 calls to operator new(0) yield the same pointer, an implementation
 595 technique specifically prohibited by ARM 5.3.3.Was this prohibition
 596 really lifted? Does the FDIS agree with CD2 in the regard? [Issues
 597 list maintainer's note: the IS is the same.]</p>
 598 <p><b>Proposed resolution:</b></p>
 599 <p>Change the last paragraph of 3.7.3 from:</p>
 600 <blockquote>
 601   <p>Any allocation and/or deallocation functions defined in a C++ program shall
 602   conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
 603 </blockquote>
 604 <p>to:</p>
 605 <blockquote>
 606   <p>Any allocation and/or deallocation functions defined in a C++ program,
 607   including the default versions in the library, shall conform to the semantics
 608   specified in 3.7.3.1 and 3.7.3.2.</p>
 609 </blockquote>
 610 <p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
 611 <blockquote>
 612   <p>If the size of the space requested is zero, the value returned shall not be
 613   a null pointer value (4.10).</p>
 614 </blockquote>
 615 <p>to:</p>
 616 <blockquote>
 617   <p>Even if the size of the space requested is zero, the request can fail. If
 618   the request succeeds, the value returned shall be a non-null pointer value
 619   (4.10) p0 different from any previously returned value p1, unless that value
 620   p1 was since passed to an operator delete.</p>
 621 </blockquote>
 622 <p>5.3.4/7 currently reads:</p>
 623 <blockquote>
 624   <p>When the value of the expression in a direct-new-declarator is zero, the
 625   allocation function is called to allocate an array with no elements. The
 626   pointer returned by the new-expression is non-null. [Note: If the library
 627   allocation function is called, the pointer returned is distinct from the
 628   pointer to any other object.]</p>
 629 </blockquote>
 630 <p>Retain the first sentence, and delete the remainder.</p>
 631 <p>18.4.1 currently has no text. Add the following:</p>
 632 <blockquote>
 633   <p>Except where otherwise specified, the provisions of 3.7.3 apply to the
 634   library versions of operator new and operator delete.</p>
 635 </blockquote>
 636 <p>To 18.4.1.3, add the following text:</p>
 637 <blockquote>
 638   <p>The provisions of 3.7.3 do not apply to these reserved placement forms of
 639   operator new and operator delete.</p>
 640 </blockquote>
 641 <p><b>Rationale:</b></p>
 642 <p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
 643 supporting to the proposed resolution.</p>
 644 <hr>
 645 <a name="11"><h3>11.&nbsp;Bitset minor problems</h3></a><p><b>Section:</b>&nbsp;23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;22 Jan 1998</p>
 646 <p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is
 647 not documented in 23.3.5.2. </p>
 648
 649 <p>(2) The class synopsis only gives a single signature for bitset&lt;&gt;::operator[],
 650 reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
 651 on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
 652
 653 <p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
 654 trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
 655 go in the Effects clause.</p>
 656 <p><b>Proposed resolution:</b></p>
 657 <p>ITEMS 1 AND 2:<br>
 658 <br>
 659 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>),
 660 replace the member function <br>
 661 <br>
 662 <tt>&nbsp;&nbsp;&nbsp; reference operator[](size_t pos);<br>
 663 </tt><br>
 664 with the two member functions<br>
 665 <br>
 666 <tt>&nbsp;&nbsp;&nbsp; bool operator[](size_t pos) const; <br>
 667 &nbsp;&nbsp;&nbsp; reference operator[](size_t pos); <br>
 668 </tt><br>
 669 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>,
 670 immediately after paragraph 45:</p>
 671
 672 <blockquote>
 673   <p><tt>bool operator[](size_t pos) const;</tt><br>
 674   Requires: pos is valid<br>
 675   Throws: nothing<br>
 676   Returns: <tt>test(pos)</tt><br>
 677   <br>
 678   <tt>bitset&lt;N&gt;::reference operator[](size_t pos);</tt> <br>
 679   Requires: pos is valid<br>
 680   Throws: nothing<br>
 681   Returns: An object of type <tt>bitset&lt;N&gt;::reference</tt> such that <tt>(*this)[pos]
 682   == this-&gt;test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this-&gt;set(pos,
 683   val);</tt></p>
 684 </blockquote>
 685 <p><b>Rationale:</b></p>
 686 <p>The LWG believes Item 3 is not a defect. "Formatted
 687 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>.
 688 </p>
 689 <hr>
 690 <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>
 691 <p>In 27.6.1.2.3, there is a reference to "eos", which is
 692 the only one in the whole draft (at least using Acrobat search), so
 693 it's undefined. </p>
 694 <p><b>Proposed resolution:</b></p>
 695 <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
 696 "charT()"</p>
 697 <hr>
 698 <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>
 699 <p>locale::combine is the only member function of locale (other than constructors and
 700 destructor) that is not const. There is no reason for it not to be const, and good reasons
 701 why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
 702 paragraph 6: "An instance of a locale is immutable." </p>
 703
 704 <p>History: this member function originally was a constructor. it happened that the
 705 interface it specified had no corresponding language syntax, so it was changed to a member
 706 function. As constructors are never const, there was no "const" in the interface
 707 which was transformed into member "combine". It should have been added at that
 708 time, but the omission was not noticed. </p>
 709 <p><b>Proposed resolution:</b></p>
 710 <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
 711 "const" to the declaration of member combine: </p>
 712 <blockquote>
 713   <pre>template &lt;class Facet&gt; locale combine(const locale&amp; other) const; </pre>
 714 </blockquote>
 715 <hr>
 716 <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>
 717 <p>locale::name() is described as returning a string that can be passed to a locale
 718 constructor, but there is no matching constructor. </p>
 719 <p><b>Proposed resolution:</b></p>
 720 <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
 721 "<tt>locale(name())</tt>" with
 722 "<tt>locale(name().c_str())</tt>".
 723 </p>
 724 <hr>
 725 <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>
 726 <p>The new virtual members ctype_byname&lt;char&gt;::do_widen and do_narrow did not get
 727 edited in properly. Instead, the member do_widen appears four times, with wrong argument
 728 lists. </p>
 729 <p><b>Proposed resolution:</b></p>
 730 <p>The correct declarations for the overloaded members
 731 <tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
 732 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>
 733 <hr>
 734 <a name="17"><h3>17.&nbsp;Bad bool parsing</h3></a><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 735 <p>This section describes the process of parsing a text boolean value from the input
 736 stream. It does not say it recognizes either of the sequences "true" or
 737 "false" and returns the corresponding bool value; instead, it says it recognizes
 738 only one of those sequences, and chooses which according to the received value of a
 739 reference argument intended for returning the result, and reports an error if the other
 740 sequence is found. (!) Furthermore, it claims to get the names from the ctype&lt;&gt;
 741 facet rather than the numpunct&lt;&gt; facet, and it examines the "boolalpha"
 742 flag wrongly; it doesn't define the value "loc"; and finally, it computes
 743 wrongly whether to use numeric or "alpha" parsing.<br>
 744 <br>
 745 I believe the correct algorithm is "as if": </p>
 746
 747 <pre>  // in, err, val, and str are arguments.
 748   err = 0;
 749   const numpunct&lt;charT&gt;&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(str.getloc());
 750   const string_type t = np.truename(), f = np.falsename();
 751   bool tm = true, fm = true;
 752   size_t pos = 0;
 753   while (tm &amp;&amp; pos &lt; t.size() || fm &amp;&amp; pos &lt; f.size()) {
 754     if (in == end) { err = str.eofbit; }
 755     bool matched = false;
 756     if (tm &amp;&amp; pos &lt; t.size()) {
 757       if (!err &amp;&amp; t[pos] == *in) matched = true;
 758       else tm = false;
 759     }
 760     if (fm &amp;&amp; pos &lt; f.size()) {
 761       if (!err &amp;&amp; f[pos] == *in) matched = true;
 762       else fm = false;
 763     }
 764     if (matched) { ++in; ++pos; }
 765     if (pos &gt; t.size()) tm = false;
 766     if (pos &gt; f.size()) fm = false;
 767   }
 768   if (tm == fm || pos == 0) { err |= str.failbit; }
 769   else                      { val = tm; }
 770   return in;</pre>
 771
 772 <p>Notice this works reasonably when the candidate strings are both empty, or equal, or
 773 when one is a substring of the other. The proposed text below captures the logic of the
 774 code above.</p>
 775 <p><b>Proposed resolution:</b></p>
 776 <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,
 777 change "&amp;&amp;" to "&amp;".</p>
 778
 779 <p>Then, replace paragraphs 15 and 16 as follows:</p>
 780
 781 <blockquote>
 782
 783   <p>Otherwise target sequences are determined "as if" by
 784   calling the members <tt>falsename()</tt> and
 785   <tt>truename()</tt> of the facet obtained by
 786   <tt>use_facet&lt;numpunct&lt;charT&gt;&nbsp;&gt;(str.getloc())</tt>.
 787   Successive characters in the range <tt>[in,end)</tt> (see
 788   [lib.sequence.reqmts]) are obtained and matched against
 789   corresponding positions in the target sequences only as necessary to
 790   identify a unique match. The input iterator <tt>in</tt> is
 791   compared to <tt>end</tt> only when necessary to obtain a
 792   character. If and only if a target sequence is uniquely matched,
 793   <tt>val</tt> is set to the corresponding value.</p>
 794
 795 </blockquote>
 796
 797 <blockquote>
 798   <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
 799   successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
 800   <tt>str.eofbit</tt> if, when seeking another character to match, it is found that
 801   <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
 802   <tt>(str.failbit|str.eofbit)</tt>if
 803   the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
 804   <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
 805   <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
 806   <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
 807   <tt>true</tt>:"1"
 808   and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
 809   and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
 810   <tt>err==str.failbit</tt>. --end example]</p>
 811 </blockquote>
 812 <hr>
 813 <a name="18"><h3>18.&nbsp;Get(...bool&amp;) omitted</h3></a><p><b>Section:</b>&nbsp;22.2.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 814 <p>In the list of num_get&lt;&gt; non-virtual members on page 22-23, the member
 815 that parses bool values was omitted from the list of definitions of non-virtual
 816 members, though it is listed in the class definition and the corresponding
 817 virtual is listed everywhere appropriate. </p>
 818 <p><b>Proposed resolution:</b></p>
 819 <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>
 820 another get member for bool&amp;, copied from the entry in
 821 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>
 822 <hr>
 823 <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>
 824 <p>
 825 In the definitions of codecvt&lt;&gt;::do_out and do_in, they are
 826 specified to return noconv if "no conversion is
 827 needed". This definition is too vague, and does not say
 828 normatively what is done with the buffers.
 829 </p>
 830 <p><b>Proposed resolution:</b></p>
 831 <p>
 832 Change the entry for noconv in the table under paragraph 4 in section
 833 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:
 834 </p>
 835 <blockquote>
 836   <p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
 837   and input sequence is identical to converted sequence.</p>
 838 </blockquote>
 839 <p>Change the Note in paragraph 2 to normative text as follows:</p>
 840 <blockquote>
 841   <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
 842   same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
 843   <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
 844   unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
 845 </blockquote>
 846 <hr>
 847 <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>
 848 <p>The synopsis for numpunct&lt;&gt;::do_thousands_sep, and the
 849 definition of numpunct&lt;&gt;::thousands_sep which calls it, specify
 850 that it returns a value of type char_type. Here it is erroneously
 851 described as returning a "string_type". </p>
 852 <p><b>Proposed resolution:</b></p>
 853 <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
 854 "string_type" to "char_type". </p>
 855 <hr>
 856 <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>
 857 <p>In the second table in the section, captioned "Required
 858 instantiations", the instantiations for codecvt_byname&lt;&gt;
 859 have been omitted. These are necessary to allow users to construct a
 860 locale by name from facets. </p>
 861 <p><b>Proposed resolution:</b></p>
 862 <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
 863 "Required instantiations", in the category "ctype"
 864 the lines </p>
 865
 866 <blockquote>
 867   <pre>codecvt_byname&lt;char,char,mbstate_t&gt;,
 868 codecvt_byname&lt;wchar_t,char,mbstate_t&gt; </pre>
 869 </blockquote>
 870 <hr>
 871 <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>
 872 <p>The description of basic_istream&lt;&gt;::open leaves unanswered questions about how it
 873 responds to or changes flags in the error status for the stream. A strict reading
 874 indicates that it ignores the bits and does not change them, which confuses users who do
 875 not expect eofbit and failbit to remain set after a successful open. There are three
 876 reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
 877 and eofbit on call to open(). </p>
 878 <p><b>Proposed resolution:</b></p>
 879 <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:
 880 </p>
 881
 882 <blockquote>
 883   <p>A successful open does not change the error state.</p>
 884 </blockquote>
 885 <p><b>Rationale:</b></p>
 886 <p>This may seem surprising to some users, but it's just an instance
 887 of a general rule: error flags are never cleared by the
 888 implementation. The only way error flags are are ever cleared is if
 889 the user explicitly clears them by hand.</p>
 890
 891 <p>The LWG believed that preserving this general rule was
 892 important enough so that an exception shouldn't be made just for this
 893 one case.  The resolution of this issue clarifies what the LWG
 894 believes to have been the original intent.</p>
 895
 896 <hr>
 897 <a name="24"></a><h3><a name="24">24.&nbsp;"do_convert" doesn't exist</a></h3><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>
 898 <p>The description of codecvt&lt;&gt;::do_out and do_in mentions a
 899 symbol "do_convert" which is not defined in the
 900 standard. This is a leftover from an edit, and should be "do_in
 901 and do_out". </p>
 902 <p><b>Proposed resolution:</b></p>
 903 <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
 904 "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
 905 or do_out". </p>
 906 <hr>
 907 <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>
 908 <p>In the description of operator&lt;&lt; applied to strings, the standard says that uses
 909 the smaller of os.width() and str.size(), to pad "as described in stage 3"
 910 elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
 911 <p><b>Proposed resolution:</b></p>
 912 <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>
 913 <br>
 914 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
 915 ..."<br>
 916 <br>
 917 to: <br>
 918 <br>
 919 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
 920 ..."</p>
 921 <hr>
 922 <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>
 923 <p>In paragraph 6, the code in the example: </p>
 924
 925 <pre>  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
 926   basic_istream&lt;charT,traits&gt;::sentry(
 927            basic_istream&lt;charT,traits&gt;&amp; is, bool noskipws = false) {
 928       ...
 929       int_type c;
 930       typedef ctype&lt;charT&gt; ctype_type;
 931       const ctype_type&amp; ctype = use_facet&lt;ctype_type&gt;(is.getloc());
 932       while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
 933         if (ctype.is(ctype.space,c)==0) {
 934           is.rdbuf()-&gt;sputbackc (c);
 935           break;
 936         }
 937       }
 938       ...
 939    }</pre>
 940
 941 <p>fails to demonstrate correct use of the facilities described. In
 942 particular, it fails to use traits operators, and specifies incorrect
 943 semantics. (E.g. it specifies skipping over the first character in the
 944 sequence without examining it.) </p>
 945 <p><b>Proposed resolution:</b></p>
 946 <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>
 947 paragraph 6.</p>
 948 <p><b>Rationale:</b></p>
 949 <p>The originally proposed replacement code for the example was not
 950 correct. The LWG tried in Kona and again in Tokyo to correct it
 951 without success. In Tokyo, an implementor reported that actual working
 952 code ran over one page in length and was quite complicated. The LWG
 953 decided that it would be counter-productive to include such a lengthy
 954 example, which might well still contain errors.</p>
 955 <hr>
 956 <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>
 957 <p>The string::erase(iterator first, iterator last) is specified to return an element one
 958 place beyond the next element after the last one erased. E.g. for the string
 959 "abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
 960 while 'd' has not been erased. </p>
 961 <p><b>Proposed resolution:</b></p>
 962 <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>
 963
 964 <blockquote>
 965   <p>Returns: an iterator which points to the element immediately following _last_ prior to
 966   the element being erased. </p>
 967 </blockquote>
 968
 969 <p>to read </p>
 970
 971 <blockquote>
 972   <p>Returns: an iterator which points to the element pointed to by _last_ prior to the
 973   other elements being erased. </p>
 974 </blockquote>
 975 <hr>
 976 <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>
 977 <p>The description of the vector form of ctype&lt;char&gt;::is can be interpreted to mean
 978 something very different from what was intended. Paragraph 4 says </p>
 979
 980 <blockquote>
 981   <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
 982   table()[(unsigned char)*p]. </p>
 983 </blockquote>
 984
 985 <p>This is intended to copy the value indexed from table()[] into the place identified in
 986 vec[]. </p>
 987 <p><b>Proposed resolution:</b></p>
 988 <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>
 989
 990 <blockquote>
 991   <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
 992   the value table()[(unsigned char)*p]. </p>
 993 </blockquote>
 994 <hr>
 995 <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>
 996 <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
 997 a function ios_base::init, which is not defined. Probably they mean
 998 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>,
 999 paragraph 3. </p>
1000 <p><b>Proposed resolution:</b></p>
1001 <p>[R12: modified to include paragraph 5.]</p>
1002
1003 <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>
1004
1005 <blockquote>
1006   <p>ios_base::init </p>
1007 </blockquote>
1008
1009 <p>to </p>
1010
1011 <blockquote>
1012   <p>basic_ios&lt;char&gt;::init </p>
1013 </blockquote>
1014
1015 <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
1016 should read </p>
1017
1018 <blockquote>
1019   <p>basic_ios&lt;wchar_t&gt;::init </p>
1020 </blockquote>
1021 <hr>
1022 <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>
1023 <p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in &lt;cctype&gt;,
1024 where they are in fact defined elsewhere to appear in &lt;clocale&gt;. </p>
1025 <p><b>Proposed resolution:</b></p>
1026 <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
1027 "&lt;cctype&gt;" to read "&lt;clocale&gt;". </p>
1028 <hr>
1029 <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>
1030 <p>Paragraph 6, says "An instance of <tt>locale</tt> is
1031 <i>immutable</i>; once a facet reference is obtained from it,
1032 ...". This has caused some confusion, because locale variables
1033 are manifestly assignable. </p>
1034 <p><b>Proposed resolution:</b></p>
1035 <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>
1036
1037 <blockquote>
1038   <p>An instance of <tt>locale</tt> is immutable; once a facet
1039   reference is obtained from it, that reference remains usable as long
1040   as the locale value itself exists.</p>
1041 </blockquote>
1042
1043 <p>with</p>
1044
1045 <blockquote>
1046   <p>Once a facet reference is obtained from a locale object by
1047   calling use_facet&lt;&gt;, that reference remains usable, and the
1048   results from member functions of it may be cached and re-used, as
1049   long as some locale object refers to that facet.</p>
1050 </blockquote>
1051 <hr>
1052 <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>
1053 <p>The description of the required state before calling virtual member
1054 basic_streambuf&lt;&gt;::pbackfail requirements is inconsistent with the conditions
1055 described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
1056 Specifically, the latter says it calls pbackfail if: </p>
1057
1058 <p>&nbsp;&nbsp;&nbsp; traits::eq(c,gptr()[-1]) is false </p>
1059
1060 <p>where pbackfail claims to require: </p>
1061
1062 <p>&nbsp;&nbsp;&nbsp; traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
1063
1064 <p>It appears that the pbackfail description is wrong. </p>
1065 <p><b>Proposed resolution:</b></p>
1066 <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>
1067
1068 <blockquote>
1069   <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
1070 </blockquote>
1071
1072 <p>to </p>
1073
1074 <blockquote>
1075   <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
1076   </p>
1077 </blockquote>
1078 <p><b>Rationale:</b></p>
1079 <p>Note deliberate reordering of arguments for clarity in addition to the correction of
1080 the argument value.</p>
1081 <hr>
1082 <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>
1083 <p>In the table defining the results from do_out and do_in, the specification for the
1084 result <i>error</i> says </p>
1085
1086 <blockquote>
1087   <p>encountered a from_type character it could not convert </p>
1088 </blockquote>
1089
1090 <p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
1091 an internT for do_out. </p>
1092 <p><b>Proposed resolution:</b></p>
1093 <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
1094 in the table for the case of _error_ with </p>
1095
1096 <blockquote>
1097   <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
1098 </blockquote>
1099 <hr>
1100 <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>
1101 <p>In paragraph 19, Effects:, members truename() and falsename are used from facet
1102 ctype&lt;charT&gt;, but it has no such members. Note that this is also a problem in
1103 22.2.2.1.2, addressed in (4). </p>
1104 <p><b>Proposed resolution:</b></p>
1105 <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:
1106 clause for member put(...., bool), replace the initialization of the
1107 string_type value s as follows: </p>
1108
1109 <blockquote>
1110   <pre>const numpunct&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(loc);
1111 string_type s = val ? np.truename() : np.falsename(); </pre>
1112 </blockquote>
1113 <hr>
1114 <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>
1115 <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
1116 named "unitbuf". Unlike other manipulators, it's not listed
1117 in synopsis. Similarly for "nounitbuf". </p>
1118 <p><b>Proposed resolution:</b></p>
1119 <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
1120 the entry for "nouppercase", the prototypes: </p>
1121
1122 <blockquote>
1123   <pre>ios_base&amp; unitbuf(ios_base&amp; str);
1124 ios_base&amp; nounitbuf(ios_base&amp; str); </pre>
1125 </blockquote>
1126 <hr>
1127 <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>
1128 <p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
1129 specified badly, so that an implementation which only keeps the last value stored appears
1130 to conform. In particular, it says: </p>
1131
1132 <p>The reference returned may become invalid after another call to the object's iword
1133 member with a different index ... </p>
1134
1135 <p>This is not idle speculation; at least one implementation was done this way. </p>
1136 <p><b>Proposed resolution:</b></p>
1137 <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
1138 paragraph 4, replace the sentence: </p>
1139
1140 <blockquote>
1141   <p>The reference returned may become invalid after another call to the object's iword
1142   [pword] member with a different index, after a call to its copyfmt member, or when the
1143   object is destroyed. </p>
1144 </blockquote>
1145
1146 <p>with: </p>
1147
1148 <blockquote>
1149   <p>The reference returned is invalid after any other operations on the object. However,
1150   the value of the storage referred to is retained, so that until the next call to copyfmt,
1151   calling iword [pword] with the same index yields another reference to the same value. </p>
1152 </blockquote>
1153
1154 <p>substituting "iword" or "pword" as appropriate. </p>
1155 <hr>
1156 <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>
1157 <p>In the overview of locale semantics, paragraph 4, is the sentence </p>
1158
1159 <blockquote>
1160   <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
1161   the standard exception bad_cast. </p>
1162 </blockquote>
1163
1164 <p>This is not supported by the definition of use_facet&lt;&gt;, and represents semantics
1165 from an old draft. </p>
1166 <p><b>Proposed resolution:</b></p>
1167 <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
1168 expression </p>
1169
1170 <blockquote>
1171   <p>(or, failing that, in the global locale) </p>
1172 </blockquote>
1173 <hr>
1174 <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>
1175 <p>It has been noticed by Esa Pulkkinen that the definition of
1176 "facet" is incomplete. In particular, a class derived from
1177 another facet, but which does not define a member <i>id</i>, cannot
1178 safely serve as the argument <i>F</i> to use_facet&lt;F&gt;(loc),
1179 because there is no guarantee that a reference to the facet instance
1180 stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
1181 <p><b>Proposed resolution:</b></p>
1182 <p>In the definition of std::use_facet&lt;&gt;(), replace the text in paragraph 1 which
1183 reads: </p>
1184
1185 <blockquote>
1186   <p>Get a reference to a facet of a locale. </p>
1187 </blockquote>
1188
1189 <p>with: </p>
1190
1191 <blockquote>
1192   <p>Requires: <tt>Facet</tt> is a facet class whose definition
1193   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>
1194 </blockquote>
1195
1196 <p><i>[
1197 Kona: strike as overspecification the text "(not inherits)"
1198 from the original resolution, which read "... whose definition
1199 contains (not inherits) the public static member
1200 <tt>id</tt>..."
1201 ]</i></p>
1202
1203 <hr>
1204 <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>
1205 <p>Following the definition of istreambuf_iterator&lt;&gt;::operator++(int) in paragraph
1206 3, the standard contains three lines of garbage text left over from a previous edit. </p>
1207
1208 <blockquote>
1209   <pre>istreambuf_iterator&lt;charT,traits&gt; tmp = *this;
1210 sbuf_-&gt;sbumpc();
1211 return(tmp); </pre>
1212 </blockquote>
1213 <p><b>Proposed resolution:</b></p>
1214 <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
1215 end of paragraph 3. </p>
1216 <hr>
1217 <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>
1218 <p>Paragraph 3 of the locale examples is a description of part of an
1219 implementation technique that has lost its referent, and doesn't mean
1220 anything. </p>
1221 <p><b>Proposed resolution:</b></p>
1222 <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
1223 initialization/identification system depends...", or (at the
1224 editor's option) replace it with a place-holder to keep the paragraph
1225 numbering the same. </p>
1226 <hr>
1227 <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>
1228 <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,
1229 which may throw an exception". However, ios_base offers no
1230 interface to set or to test badbit; those interfaces are defined in
1231 basic_ios&lt;&gt;. </p>
1232 <p><b>Proposed resolution:</b></p>
1233 <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
1234 paragraph 2, and also in paragraph 4, as follows. Replace</p>
1235
1236 <blockquote>
1237   <p>If the function fails it sets badbit, which may throw an exception.</p>
1238 </blockquote>
1239
1240 <p>with</p>
1241
1242 <blockquote>
1243   <p>If the function fails, and <tt>*this</tt> is a base sub-object of
1244   a <tt>basic_ios&lt;&gt;</tt> object or sub-object, the effect is
1245   equivalent to calling <tt>basic_ios&lt;&gt;::setstate(badbit)</tt>
1246   on the derived object (which may throw <tt>failure</tt>).</p>
1247 </blockquote>
1248
1249 <p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
1250 setstate(badbit).]</i></p>
1251
1252 <hr>
1253 <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>
1254 <p>The basic_string&lt;&gt; copy constructor: </p>
1255
1256 <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1257              size_type n = npos, const Allocator&amp; a = Allocator()); </pre>
1258
1259 <p>specifies an Allocator argument default value that is
1260 counter-intuitive. The natural choice for a the allocator to copy from
1261 is str.get_allocator(). Though this cannot be expressed in
1262 default-argument notation, overloading suffices. </p>
1263
1264 <p>Alternatively, the other containers in Clause 23 (deque, list,
1265 vector) do not have this form of constructor, so it is inconsistent,
1266 and an evident source of confusion, for basic_string&lt;&gt; to have
1267 it, so it might better be removed. </p>
1268 <p><b>Proposed resolution:</b></p>
1269 <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
1270 constructor as follows: </p>
1271
1272 <blockquote>
1273   <pre>basic_string(const basic_string&amp; str);
1274 basic_string(const basic_string&amp; str, size_type pos, size_type n = npos,
1275              const Allocator&amp; a = Allocator());</pre>
1276 </blockquote>
1277
1278 <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
1279 as above. Add to paragraph 5, Effects:</p>
1280
1281 <blockquote>
1282   <p>In the first form, the Allocator value used is copied from
1283   <tt>str.get_allocator()</tt>.</p>
1284 </blockquote>
1285 <p><b>Rationale:</b></p>
1286 <p>The LWG believes the constructor is actually broken, rather than
1287 just an unfortunate design choice.</p>
1288
1289 <p>The LWG considered two other possible resolutions:</p>
1290
1291 <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
1292 constructor as follows:</p>
1293
1294 <blockquote>
1295   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1296              size_type n = npos);
1297 basic_string(const basic_string&amp; str, size_type pos,
1298              size_type n, const Allocator&amp; a); </pre>
1299 </blockquote>
1300
1301 <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
1302 as above. Add to paragraph 5, Effects: </p>
1303
1304 <blockquote>
1305   <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
1306   value <tt>str.get_allocator()</tt>. </p>
1307 </blockquote>
1308
1309 <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
1310 the declaration of the copy constructor as follows: </p>
1311
1312 <blockquote>
1313   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1314              size_type n = npos); </pre>
1315 </blockquote>
1316
1317 <p>The proposed resolution reflects the original intent of the LWG. It
1318 was also noted by Pete Becker that this fix "will cause
1319 a small amount of existing code to now work correctly."</p>
1320
1321 <p><i>[
1322 Kona: issue editing snafu fixed - the proposed resolution now correctly
1323 reflects the LWG consensus.
1324 ]</i></p>
1325 <hr>
1326 <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>
1327 <p>Many of the specifications for iostreams specify that character
1328 values or their int_type equivalents are compared using operators ==
1329 or !=, though in other places traits::eq() or traits::eq_int_type is
1330 specified to be used throughout. This is an inconsistency; we should
1331 change uses of == and != to use the traits members instead. </p>
1332 <p><b>Proposed resolution:</b></p>
1333
1334 <p><i>[Pre-Kona: Dietmar supplied wording]</i></p>
1335
1336 <p>List of changes to clause 27:</p>
1337 <ol>
1338 <li>
1339    In lib.basic.ios.members paragraph 13 (postcondition clause for
1340    'fill(cT)') change
1341
1342 <blockquote>
1343      fillch == fill()
1344 </blockquote>
1345
1346    to
1347
1348 <blockquote>
1349      traits::eq(fillch, fill())
1350 </blockquote>
1351
1352
1353 </li>
1354 <li>
1355    In lib.istream.unformatted paragraph 7 (effects clause for
1356    'get(cT,streamsize,cT)'), third bullet, change
1357
1358 <blockquote>
1359      c == delim for the next available input character c
1360 </blockquote>
1361
1362    to
1363
1364 <blockquote>
1365      traits::eq(c, delim) for the next available input character c
1366   </blockquote>
1367
1368 </li>
1369 <li>
1370    In lib.istream.unformatted paragraph 12 (effects clause for
1371    'get(basic_streambuf&lt;cT,Tr&gt;&amp;,cT)'), third bullet, change
1372
1373 <blockquote>
1374      c == delim for the next available input character c
1375 </blockquote>
1376
1377    to
1378
1379 <blockquote>
1380      traits::eq(c, delim) for the next available input character c
1381 </blockquote>
1382
1383 </li>
1384 <li>
1385    In lib.istream.unformatted paragraph 17 (effects clause for
1386    'getline(cT,streamsize,cT)'), second bullet, change
1387
1388 <blockquote>
1389      c == delim for the next available input character c
1390 </blockquote>
1391
1392    to
1393
1394 <blockquote>
1395      traits::eq(c, delim) for the next available input character c
1396   </blockquote>
1397
1398 </li>
1399 <li>
1400    In lib.istream.unformatted paragraph 24 (effects clause for
1401    'ignore(int,int_type)'), second bullet, change
1402
1403 <blockquote>
1404      c == delim for the next available input character c
1405 </blockquote>
1406
1407    to
1408
1409 <blockquote>
1410      traits::eq_int_type(c, delim) for the next available input
1411      character c
1412 </blockquote>
1413
1414 </li>
1415 <li>
1416    In lib.istream.unformatted paragraph 25 (notes clause for
1417    'ignore(int,int_type)'), second bullet, change
1418
1419 <blockquote>
1420      The last condition will never occur if delim == traits::eof()
1421 </blockquote>
1422
1423    to
1424
1425 <blockquote>
1426      The last condition will never occur if
1427      traits::eq_int_type(delim, traits::eof()).
1428 </blockquote>
1429
1430 </li>
1431 <li>
1432    In lib.istream.sentry paragraph 6 (example implementation for the
1433    sentry constructor) change
1434
1435 <blockquote>
1436      while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
1437 </blockquote>
1438
1439    to
1440
1441 <blockquote>
1442      while (!traits::eq_int_type(c = is.rdbuf()-&gt;snextc(), traits::eof())) {
1443 </blockquote>
1444
1445 </li>
1446 </ol>
1447
1448 <p>List of changes to Chapter 21:</p>
1449
1450 <ol>
1451 <li>
1452    In lib.string::find paragraph 1 (effects clause for find()),
1453    second bullet, change
1454
1455 <blockquote>
1456      at(xpos+I) == str.at(I) for all elements ...
1457 </blockquote>
1458
1459    to
1460
1461 <blockquote>
1462      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1463 </blockquote>
1464
1465 </li>
1466 <li>
1467    In lib.string::rfind paragraph 1 (effects clause for rfind()),
1468    second bullet, change
1469
1470 <blockquote>
1471      at(xpos+I) == str.at(I) for all elements ...
1472 </blockquote>
1473
1474    to
1475
1476 <blockquote>
1477      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1478 </blockquote>
1479
1480 </li>
1481 <li>
1482    In lib.string::find.first.of paragraph 1 (effects clause for
1483    find_first_of()), second bullet, change
1484
1485 <blockquote>
1486      at(xpos+I) == str.at(I) for all elements ...
1487 </blockquote>
1488
1489    to
1490
1491 <blockquote>
1492      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1493 </blockquote>
1494
1495 </li>
1496 <li>
1497    In lib.string::find.last.of paragraph 1 (effects clause for
1498    find_last_of()), second bullet, change
1499
1500 <blockquote>
1501      at(xpos+I) == str.at(I) for all elements ...
1502 </blockquote>
1503
1504    to
1505
1506 <blockquote>
1507      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1508 </blockquote>
1509
1510 </li>
1511 <li>
1512    In lib.string::find.first.not.of paragraph 1 (effects clause for
1513    find_first_not_of()), second bullet, change
1514
1515 <blockquote>
1516      at(xpos+I) == str.at(I) for all elements ...
1517 </blockquote>
1518
1519    to
1520
1521 <blockquote>
1522      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1523 </blockquote>
1524 </li>
1525
1526 <li>
1527    In lib.string::find.last.not.of paragraph 1 (effects clause for
1528    find_last_not_of()), second bullet, change
1529
1530 <blockquote>
1531      at(xpos+I) == str.at(I) for all elements ...
1532 </blockquote>
1533
1534    to
1535
1536 <blockquote>
1537      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1538 </blockquote>
1539 </li>
1540
1541 <li>
1542    In lib.string.ios paragraph 5 (effects clause for getline()),
1543    second bullet, change
1544
1545 <blockquote>
1546      c == delim for the next available input character c
1547 </blockquote>
1548
1549    to
1550
1551 <blockquote>
1552      traits::eq(c, delim) for the next available input character c
1553 </blockquote>
1554 </li>
1555
1556 </ol>
1557
1558 <p>Notes:</p>
1559 <ul>
1560 <li>
1561   Fixing this issue highlights another sloppyness in
1562   lib.istream.unformatted paragraph 24: this clause mentions a "character"
1563   which is then compared to an 'int_type' (see item 5. in the list
1564   below). It is not clear whether this requires explicit words and
1565   if so what these words are supposed to be. A similar issue exists,
1566   BTW, for operator*() of istreambuf_iterator which returns the result
1567   of sgetc() as a character type (see lib.istreambuf.iterator::op*
1568   paragraph 1), and for operator++() of istreambuf_iterator which
1569   passes the result of sbumpc() to a constructor taking a char_type
1570   (see lib.istreambuf.iterator::operator++ paragraph 3). Similarily, the
1571   assignment operator ostreambuf_iterator passes a char_type to a function
1572   taking an int_type (see lib.ostreambuf.iter.ops paragraph 1).
1573 </li>
1574 <li>
1575   It is inconsistent to use comparisons using the traits functions in
1576   Chapter 27 while not using them in Chapter 21, especially as some
1577   of the inconsistent uses actually involve streams (eg. getline() on
1578   streams). To avoid leaving this issue open still longer due to this
1579   inconsistency (it is open since 1998), a list of changes to Chapter
1580   21 is below.
1581 </li>
1582 <li>
1583   In Chapter 24 there are several places with statements like "the end
1584   of stream is reached (streambuf_type::sgetc() returns traits::eof())"
1585   (lib.istreambuf.iterator paragraph 1, lib.ostreambuf.iter.ops
1586   paragraph 5). It is unclear whether these should be clarified to use
1587   traits::eq_int_type() for detecting traits::eof().
1588 </li>
1589 </ul>
1590
1591 <hr>
1592 <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>
1593 <p>See lib-6522 and edit-814.</p>
1594 <p><b>Proposed resolution:</b></p>
1595 <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
1596 basic_streambuf&lt;char&gt;) from:</p>
1597
1598 <pre>         virtual streambuf&lt;char&gt;* setbuf(char* s, streamsize n);</pre>
1599
1600 <p>to:</p>
1601
1602 <pre>         virtual streambuf* setbuf(char* s, streamsize n);</pre>
1603
1604 <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
1605 int_type:</p>
1606
1607 <pre>     namespace std {
1608        class strstream
1609          : public basic_iostream&lt;char&gt; {
1610        public:
1611          // Types
1612          typedef char                                char_type;
1613          typedef typename char_traits&lt;char&gt;::int_type int_type
1614          typedef typename char_traits&lt;char&gt;::pos_type pos_type;</pre>
1615 <hr>
1616 <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>
1617 <p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
1618 section has two RETURNS clauses, and they make no sense as
1619 stated. They make perfect sense, though, if you swap them. Am I
1620 correct in thinking that paragraphs 2 and 4 just got mixed up by
1621 accident?</p>
1622 <p><b>Proposed resolution:</b></p>
1623 <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>
1624 <hr>
1625 <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>
1626 <p>27.4.2.1.1, paragraph 2, says that class failure initializes the
1627 base class, exception, with exception(msg). Class exception (see
1628 18.6.1) has no such constructor.</p>
1629 <p><b>Proposed resolution:</b></p>
1630 <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>
1631
1632 <blockquote>
1633   <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
1634 </blockquote>
1635 <hr>
1636 <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>
1637 <p>Two problems</p>
1638
1639 <p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
1640 returns. Does it return f, or does it return the previous
1641 synchronization state? My guess is the latter, but the standard
1642 doesn't say so.</p>
1643
1644 <p>(2) 27.4.2.4 doesn't say what it means for streams to be
1645 synchronized with stdio.  Again, of course, I can make some
1646 guesses. (And I'm unhappy about the performance implications of those
1647 guesses, but that's another matter.)</p>
1648 <p><b>Proposed resolution:</b></p>
1649 <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>
1650 returns clause from:</p>
1651
1652 <blockquote>
1653   <p><tt>true</tt> if the standard iostream objects (27.3) are
1654   synchronized and otherwise returns <tt>false</tt>.</p>
1655 </blockquote>
1656
1657 <p>to:</p>
1658
1659 <blockquote>
1660   <p><tt>true</tt> if the previous state of the standard iostream
1661   objects (27.3) was synchronized and otherwise returns
1662   <tt>false</tt>.</p>
1663 </blockquote>
1664
1665 <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>,
1666 paragraph 2:</p>
1667
1668 <blockquote>
1669 <p>When a standard iostream object str is <i>synchronized</i> with a
1670 standard stdio stream f, the effect of inserting a character c by</p>
1671 <pre>  fputc(f, c);
1672 </pre>
1673
1674 <p>is the same as the effect of</p>
1675 <pre>  str.rdbuf()-&gt;sputc(c);
1676 </pre>
1677
1678 <p>for any sequence of characters; the effect of extracting a
1679 character c by</p>
1680 <pre>  c = fgetc(f);
1681 </pre>
1682
1683 <p>is the same as the effect of:</p>
1684 <pre>  c = str.rdbuf()-&gt;sbumpc(c);
1685 </pre>
1686
1687 <p>for any sequences of characters; and the effect of pushing
1688 back a character c by</p>
1689 <pre>  ungetc(c, f);
1690 </pre>
1691
1692 <p>is the same as the effect of</p>
1693 <pre>  str.rdbuf()-&gt;sputbackc(c);
1694 </pre>
1695
1696 <p>for any sequence of characters.  [<i>Footnote</i>: This implies
1697 that operations on a standard iostream object can be mixed arbitrarily
1698 with operations on the corresponding stdio stream.  In practical
1699 terms, synchronization usually means that a standard iostream object
1700 and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
1701 </blockquote>
1702
1703 <p><i>[pre-Copenhagen: PJP and Matt contributed the definition
1704 of "synchronization"]</i></p>
1705
1706 <p><i>[post-Copenhagen: proposed resolution was revised slightly:
1707 text was added in the non-normative footnote to say that operations
1708 on the two streams can be mixed arbitrarily.]</i></p>
1709 <hr>
1710 <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>
1711 <p>As written, ios_base has a copy constructor and an assignment
1712 operator. (Nothing in the standard says it doesn't have one, and all
1713 classes have copy constructors and assignment operators unless you
1714 take specific steps to avoid them.) However, nothing in 27.4.2 says
1715 what the copy constructor and assignment operator do. </p>
1716
1717 <p>My guess is that this was an oversight, that ios_base is, like
1718 basic_ios, not supposed to have a copy constructor or an assignment
1719 operator.</p>
1720
1721 <p>
1722 Jerry Schwarz comments: Yes, its an oversight, but in the opposite
1723 sense to what you're suggesting. At one point there was a definite
1724 intention that you could copy ios_base. It's an easy way to save the
1725 entire state of a stream for future use. As you note, to carry out
1726 that intention would have required a explicit description of the
1727 semantics (e.g. what happens to the iarray and parray stuff).
1728 </p>
1729 <p><b>Proposed resolution:</b></p>
1730 <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
1731 constructor and operator= members as being private.</p>
1732 <p><b>Rationale:</b></p>
1733 <p>The LWG believes the difficulty of specifying correct semantics
1734 outweighs any benefit of allowing ios_base objects to be copyable.</p>
1735 <hr>
1736 <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>
1737 <p>The std::sort algorithm can in general only sort a given sequence
1738 by moving around values. The list&lt;&gt;::sort() member on the other
1739 hand could move around values or just update internal pointers. Either
1740 method can leave iterators into the list&lt;&gt; dereferencable, but
1741 they would point to different things. </p>
1742
1743 <p>Does the FDIS mandate anywhere which method should be used for
1744 list&lt;&gt;::sort()?</p>
1745
1746 <p>Matt Austern comments:</p>
1747
1748 <p>I think you've found an omission in the standard. </p>
1749
1750 <p>The library working group discussed this point, and there was
1751 supposed to be a general requirement saying that list, set, map,
1752 multiset, and multimap may not invalidate iterators, or change the
1753 values that iterators point to, except when an operation does it
1754 explicitly. So, for example, insert() doesn't invalidate any iterators
1755 and erase() and remove() only invalidate iterators pointing to the
1756 elements that are being erased. </p>
1757
1758 <p>I looked for that general requirement in the FDIS, and, while I
1759 found a limited form of it for the sorted associative containers, I
1760 didn't find it for list. It looks like it just got omitted. </p>
1761
1762 <p>The intention, though, is that list&lt;&gt;::sort does not
1763 invalidate any iterators and does not change the values that any
1764 iterator points to. There would be no reason to have the member
1765 function otherwise.</p>
1766 <p><b>Proposed resolution:</b></p>
1767 <p>Add a new paragraph at the end of 23.1:</p>
1768
1769 <blockquote>
1770   <p>Unless otherwise specified (either explicitly or by defining a function in terms of
1771   other functions), invoking a container member function or passing a container as an
1772   argument to a library function shall not invalidate iterators to, or change the values of,
1773   objects within that container. </p>
1774 </blockquote>
1775 <p><b>Rationale:</b></p>
1776 <p>This was US issue CD2-23-011; it was accepted in London but the
1777 change was not made due to an editing oversight. The wording in the
1778 proposed resolution below is somewhat updated from CD2-23-011,
1779 particularly the addition of the phrase "or change the values
1780 of"</p>
1781 <hr>
1782 <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>
1783 <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:
1784 it should be titled "basic_ios&lt;&gt;() effects", not
1785 "ios_base() effects". </p>
1786
1787 <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
1788 resolution.]</p>
1789
1790 <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
1791 different things wrong with it, some of which I've already discussed
1792 with Jerry, but the most obvious mechanical sort of error is that it
1793 uses expressions like P(i) and p(i), without ever defining what sort
1794 of thing "i" is.
1795 </p>
1796
1797 <p>(The other problem is that it requires support for streampos
1798 arithmetic. This is impossible on some systems, i.e. ones where file
1799 position is a complicated structure rather than just a number. Jerry
1800 tells me that the intention was to require syntactic support for
1801 streampos arithmetic, but that it wasn't actually supposed to do
1802 anything meaningful except on platforms, like Unix, where genuine
1803 arithmetic is possible.) </p>
1804 <p><b>Proposed resolution:</b></p>
1805 <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
1806 "ios_base() effects" to "basic_ios&lt;&gt;()
1807 effects". </p>
1808 <hr>
1809 <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>
1810 <p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
1811 The important question is whether basic_ios::~basic_ios() destroys
1812 rdbuf().</p>
1813 <p><b>Proposed resolution:</b></p>
1814 <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>
1815
1816 <blockquote>
1817   <p><tt>virtual ~basic_ios();</tt></p>
1818   <p><b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
1819 </blockquote>
1820 <p><b>Rationale:</b></p>
1821 <p>The LWG reviewed the additional question of whether or not
1822 <tt>rdbuf(0)</tt> may set <tt>badbit</tt>.  The answer is
1823 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
1824 by the LWG, which removed from the original proposed resolution a
1825 footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
1826 <tt>badbit</tt>".</p>
1827 <hr>
1828 <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>
1829 <p>The class synopsis for basic_streambuf shows a (virtual)
1830 destructor, but the standard doesn't say what that destructor does. My
1831 assumption is that it does nothing, but the standard should say so
1832 explicitly. </p>
1833 <p><b>Proposed resolution:</b></p>
1834 <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>
1835
1836 <blockquote>
1837   <p><tt>virtual&nbsp; ~basic_streambuf();</tt></p>
1838   <p><b>Effects</b>: None.</p>
1839 </blockquote>
1840 <hr>
1841 <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>
1842 <p>Several member functions in clause 27 are defined in certain
1843 circumstances to return an "invalid stream position", a term
1844 that is defined nowhere in the standard. Two places (27.5.2.4.2,
1845 paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
1846 a definition in _lib.iostreams.definitions_, a nonexistent
1847 section. </p>
1848
1849 <p>I suspect that the invalid stream position is just supposed to be
1850 pos_type(-1).  Probably best to say explicitly in (for example)
1851 27.5.2.4.2 that the return value is pos_type(-1), rather than to use
1852 the term "invalid stream position", define that term
1853 somewhere, and then put in a cross-reference. </p>
1854
1855 <p>The phrase "invalid stream position" appears ten times in
1856 the C++ Standard.  In seven places it refers to a return value, and it
1857 should be changed. In three places it refers to an argument, and it
1858 should not be changed. Here are the three places where "invalid
1859 stream position" should not be changed:</p>
1860
1861 <blockquote>
1862   <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>
1863   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>
1864   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
1865   </p>
1866 </blockquote>
1867 <p><b>Proposed resolution:</b></p>
1868 <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
1869 object of class pos_type that stores an invalid stream position
1870 (_lib.iostreams.definitions_)" to "Returns
1871 <tt>pos_type(off_type(-1))</tt>".
1872 </p>
1873
1874 <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
1875 an object of class pos_type that stores an invalid stream
1876 position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
1877
1878 <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
1879 stores an invalid stream position" to "the return value is
1880 <tt>pos_type(off_type(-1))</tt>". </p>
1881
1882 <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
1883 invalid stream position (27.4.3)" to "returns
1884 <tt>pos_type(off_type(-1))</tt>" </p>
1885
1886 <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
1887 returns an invalid stream position (_lib.iostreams.definitions_)"
1888 to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
1889 </p>
1890
1891 <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
1892 stores an invalid stream position" to "the return value is
1893 <tt>pos_type(off_type(-1))</tt>" </p>
1894
1895 <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
1896 stores an invalid stream position" to "the return value is
1897 <tt>pos_type(off_type(-1))</tt>"</p>
1898 <hr>
1899 <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>
1900 <p>The class summary for basic_streambuf&lt;&gt;, in 27.5.2, says that
1901 showmanyc has return type int. However, 27.5.2.4.3 says that its
1902 return type is streamsize. </p>
1903 <p><b>Proposed resolution:</b></p>
1904 <p>Change <tt>showmanyc</tt>'s return type in the
1905 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>
1906 <hr>
1907 <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>
1908 <p>21.1.3.2, paragraph 3, says "The types streampos and
1909 wstreampos may be different if the implementation supports no shift
1910 encoding in narrow-oriented iostreams but supports one or more shift
1911 encodings in wide-oriented streams". </p>
1912
1913 <p>That's wrong: the two are the same type. The &lt;iosfwd&gt; summary
1914 in 27.2 says that streampos and wstreampos are, respectively, synonyms
1915 for fpos&lt;char_traits&lt;char&gt;::state_type&gt; and
1916 fpos&lt;char_traits&lt;wchar_t&gt;::state_type&gt;, and, flipping back
1917 to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
1918 char_traits&lt;char&gt;::state_type and
1919 char_traits&lt;wchar_t&gt;::state_type must both be mbstate_t. </p>
1920 <p><b>Proposed resolution:</b></p>
1921 <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
1922 begins "The types streampos and wstreampos may be
1923 different..." . </p>
1924 <hr>
1925 <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>
1926 <p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
1927 next pointer for the input sequence by n." </p>
1928
1929 <p>The straightforward interpretation is that it is just gptr() +=
1930 n. An alternative interpretation, though, is that it behaves as if it
1931 calls sbumpc n times. (The issue, of course, is whether it might ever
1932 call underflow.) There is a similar ambiguity in the case of
1933 pbump. </p>
1934
1935 <p>(The "classic" AT&amp;T implementation used the
1936 former interpretation.)</p>
1937 <p><b>Proposed resolution:</b></p>
1938 <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>
1939
1940 <blockquote>
1941   <p>Effects: Advances the next pointer for the input sequence by n.</p>
1942 </blockquote>
1943
1944 <p>to:</p>
1945
1946 <blockquote>
1947   <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
1948 </blockquote>
1949
1950 <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
1951 effects.</p>
1952 <hr>
1953 <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>
1954 <p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
1955 formatted input functions. Some of the functions defined in section
1956 27.6.1.2 explicitly say that those requirements apply ("Behaves
1957 like a formatted input member (as described in 27.6.1.2.1)"), but
1958 others don't. The question: is 27.6.1.2.1 supposed to apply to
1959 everything in 27.6.1.2, or only to those member functions that
1960 explicitly say "behaves like a formatted input member"? Or
1961 to put it differently: are we to assume that everything that appears
1962 in a section called "Formatted input functions" really is a
1963 formatted input function? I assume that 27.6.1.2.1 is intended to
1964 apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
1965 is not intended to apply to extractors like </p>
1966
1967 <pre>    basic_istream&amp; operator&gt;&gt;(basic_istream&amp; (*pf)(basic_istream&amp;));</pre>
1968
1969 <p>and </p>
1970
1971 <pre>    basic_istream&amp; operator&gt;&gt;(basic_streammbuf*);</pre>
1972
1973 <p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
1974 output. </p>
1975
1976 <p>Comments from Judy Ward: It seems like the problem is that the
1977 basic_istream and basic_ostream operator &lt;&lt;()'s that are used
1978 for the manipulators and streambuf* are in the wrong section and
1979 should have their own separate section or be modified to make it clear
1980 that the "Common requirements" listed in section 27.6.1.2.1
1981 (for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
1982 apply to them. </p>
1983
1984 <p>Additional comments from Dietmar Kühl: It appears to be somewhat
1985 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
1986 function" but since these functions are defined in a section
1987 labeled "Formatted input functions" it is unclear to me
1988 whether these operators are considered formatted input functions which
1989 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
1990 just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
1991 set (... but setting <tt>noskipws</tt> using the manipulator syntax
1992 would also skip whitespace :-)</p> <p>It is not clear which functions
1993 are to be considered unformatted input functions. As written, it seems
1994 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
1995 functions. However, it does not really make much sense to construct a
1996 sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
1997 unclear what happens to the <tt>gcount()</tt> if
1998 eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
1999 <tt>sync()</tt> is called: These functions don't extract characters,
2000 some of them even "unextract" a character. Should this still
2001 be reflected in <tt>gcount()</tt>? Of course, it could be read as if
2002 after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
2003 (the last unformatted input function, <tt>gcount()</tt>, didn't
2004 extract any character) and after a call to <tt>putback()</tt>
2005 <tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
2006 function <tt>putback()</tt> did "extract" back into the
2007 stream). Correspondingly for <tt>unget()</tt>. Is this what is
2008 intended?  If so, this should be clarified. Otherwise, a corresponding
2009 clarification should be used.</p>
2010 <p><b>Proposed resolution:</b></p>
2011 <p>
2012 In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
2013 Change the beginning of the second sentence from "The conversion
2014 occurs" to "These extractors behave as formatted input functions (as
2015 described in 27.6.1.2.1).  After a sentry object is constructed,
2016 the conversion occurs"
2017 </p>
2018
2019 <p>
2020 In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
2021 Add an effects clause.  "Effects: None.  This extractor does
2022 not behave as a formatted input function (as described in
2023 27.6.1.2.1).
2024 </p>
2025
2026 <p>
2027 In 27.6.1.2.3, [lib.istream::extractors], paragraph 2.  Change the
2028 effects clause to "Effects: Calls pf(*this).  This extractor does not
2029 behave as a formatted input function (as described in 27.6.1.2.1).
2030 </p>
2031
2032 <p>
2033 In 27.6.1.2.3, [lib.istream::extractors], paragraph 4.  Change the
2034 effects clause to "Effects: Calls pf(*this).  This extractor does not
2035 behave as a formatted input function (as described in 27.6.1.2.1).
2036 </p>
2037
2038 <p>
2039 In 27.6.1.2.3, [lib.istream::extractors], paragraph 12.  Change the
2040 first two sentences from "If sb is null, calls setstate(failbit),
2041 which may throw ios_base::failure (27.4.4.3).  Extracts characters
2042 from *this..." to "Behaves as a formatted input function (as described
2043 in 27.6.1.2.1).  If sb is null, calls setstate(failbit), which may
2044 throw ios_base::failure (27.4.4.3).  After a sentry object is
2045 constructed, extracts characters from *this...".
2046 </p>
2047
2048 <p>
2049 In 27.6.1.3, [lib.istream.unformatted], before paragraph 2.  Add an
2050 effects clause.  "Effects: none. This member function does not behave
2051 as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
2052 </p>
2053
2054 <p>
2055 In 27.6.1.3, [lib.istream.unformatted], paragraph 3.  Change the
2056 beginning of the first sentence of the effects clause from "Extracts a
2057 character" to "Behaves as an unformatted input function (as described
2058 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
2059 character"
2060 </p>
2061
2062 <p>
2063 In 27.6.1.3, [lib.istream.unformatted], paragraph 5.  Change the
2064 beginning of the first sentence of the effects clause from "Extracts a
2065 character" to "Behaves as an unformatted input function (as described
2066 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
2067 character"
2068 </p>
2069
2070 <p>
2071 In 27.6.1.3, [lib.istream.unformatted], paragraph 5.  Change the
2072 beginning of the first sentence of the effects clause from "Extracts
2073 characters" to "Behaves as an unformatted input function (as described
2074 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2075 characters"
2076 </p>
2077
2078 <p>
2079 [No change needed in paragraph 10, because it refers to paragraph 7.]
2080 </p>
2081
2082 <p>
2083 In 27.6.1.3, [lib.istream.unformatted], paragraph 12.  Change the
2084 beginning of the first sentence of the effects clause from "Extracts
2085 characters" to "Behaves as an unformatted input function (as described
2086 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2087 characters"
2088 </p>
2089
2090 <p>
2091 [No change needed in paragraph 15.]
2092 </p>
2093
2094 <p>
2095 In 27.6.1.3, [lib.istream.unformatted], paragraph 17.  Change the
2096 beginning of the first sentence of the effects clause from "Extracts
2097 characters" to "Behaves as an unformatted input function (as described
2098 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2099 characters"
2100 </p>
2101
2102 <p>
2103 [No change needed in paragraph 23.]
2104 </p>
2105
2106 <p>
2107 In 27.6.1.3, [lib.istream.unformatted], paragraph 24.  Change the
2108 beginning of the first sentence of the effects clause from "Extracts
2109 characters" to "Behaves as an unformatted input function (as described
2110 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2111 characters"
2112 </p>
2113
2114 <p>
2115 In 27.6.1.3, [lib.istream.unformatted], before paragraph 27.  Add an
2116 Effects clause: "Effects: Behaves as an unformatted input function (as
2117 described in 27.6.1.3, paragraph 1).  After constructing a sentry
2118 object, reads but does not extract the current input character."
2119 </p>
2120
2121 <p>
2122 In 27.6.1.3, [lib.istream.unformatted], paragraph 28.  Change the
2123 first sentence of the Effects clause from "If !good() calls" to
2124 Behaves as an unformatted input function (as described in 27.6.1.3,
2125 paragraph 1).  After constructing a sentry object, if !good() calls"
2126 </p>
2127
2128 <p>
2129 In 27.6.1.3, [lib.istream.unformatted], paragraph 30.  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 32.  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()
2140 calls..."  Add a new sentence to the end of the Effects clause:
2141 "[Note: this function extracts no characters, so the value returned
2142 by the next call to gcount() is 0.]"
2143 </p>
2144
2145 <p>
2146 In 27.6.1.3, [lib.istream.unformatted], paragraph 34.  Change the
2147 first sentence of the Effects clause from "If !good() calls" to
2148 "Behaves as an unformatted input function (as described in 27.6.1.3,
2149 paragraph 1).  After constructing a sentry object, if !good() calls".
2150 Add a new sentence to the end of the Effects clause: "[Note: this
2151 function extracts no characters, so the value returned by the next
2152 call to gcount() is 0.]"
2153 </p>
2154
2155 <p>
2156 In 27.6.1.3, [lib.istream.unformatted], paragraph 36.  Change the
2157 first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
2158 as an unformatted input function (as described in 27.6.1.3, paragraph
2159 1), except that it does not count the number of characters extracted
2160 and does not affect the value returned by subsequent calls to
2161 gcount().  After constructing a sentry object, if rdbuf() is"
2162 </p>
2163
2164 <p>
2165 In 27.6.1.3, [lib.istream.unformatted], before paragraph 37.  Add an
2166 Effects clause: "Effects: Behaves as an unformatted input function (as
2167 described in 27.6.1.3, paragraph 1), except that it does not count the
2168 number of characters extracted and does not affect the value returned
2169 by subsequent calls to gcount()."  Change the first sentence of
2170 paragraph 37 from "if fail()" to "after constructing a sentry object,
2171 if fail()".
2172 </p>
2173
2174 <p>
2175 In 27.6.1.3, [lib.istream.unformatted], paragraph 38.  Change the
2176 first sentence of the Effects clause from "If fail()" to "Behaves
2177 as an unformatted input function (as described in 27.6.1.3, paragraph
2178 1), except that it does not count the number of characters extracted
2179 and does not affect the value returned by subsequent calls to
2180 gcount().  After constructing a sentry object, if fail()
2181 </p>
2182
2183 <p>
2184 In 27.6.1.3, [lib.istream.unformatted], paragraph 40.  Change the
2185 first sentence of the Effects clause from "If fail()" to "Behaves
2186 as an unformatted input function (as described in 27.6.1.3, paragraph
2187 1), except that it does not count the number of characters extracted
2188 and does not affect the value returned by subsequent calls to
2189 gcount().  After constructing a sentry object, if fail()
2190 </p>
2191
2192 <p>
2193 In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1.  Change
2194 the beginning of the third sentence from "The formatting conversion"
2195 to "These extractors behave as formatted output functions (as
2196 described in 27.6.2.5.1).  After the sentry object is constructed, the
2197 conversion occurs".
2198 </p>
2199
2200 <p>
2201 In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1.  Add an
2202 effects clause: "Effects: None. Does not behave as a formatted output
2203 function (as described in 27.6.2.5.1).".
2204 </p>
2205
2206 <p>
2207 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2.  Change the
2208 effects clause to "Effects: calls pf(*this).  This extractor does not
2209 behave as a formatted output function (as described in 27.6.2.5.1).".
2210 </p>
2211
2212 <p>
2213 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4.  Change the
2214 effects clause to "Effects: calls pf(*this).  This extractor does not
2215 behave as a formatted output function (as described in 27.6.2.5.1).".
2216 </p>
2217
2218 <p>
2219 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6.  Change the first
2220 sentence from "If sb" to "Behaves as a formatted output function (as
2221 described in 27.6.2.5.1).  After the sentry object is constructed, if
2222 sb".
2223 </p>
2224
2225 <p>
2226 In 27.6.2.6 [lib.ostream.unformatted], paragraph 2.  Change the first
2227 sentence from "Inserts the character" to "Behaves as an unformatted
2228 output function (as described in 27.6.2.6, paragraph 1).  After
2229 constructing a sentry object, inserts the character".
2230 </p>
2231
2232 <p>
2233 In 27.6.2.6 [lib.ostream.unformatted], paragraph 5.  Change the first
2234 sentence from "Obtains characters" to "Behaves as an unformatted
2235 output function (as described in 27.6.2.6, paragraph 1).  After
2236 constructing a sentry object, obtains characters".
2237 </p>
2238
2239 <p>
2240 In 27.6.2.6 [lib.ostream.unformatted], paragraph 7.  Add a new
2241 sentence at the end of the paragraph: "Does not behave as an
2242 unformatted output function (as described in 27.6.2.6, paragraph 1)."
2243 </p>
2244 <p><b>Rationale:</b></p>
2245 <p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
2246 by Judy Ward and Matt Austern.  This proposed resolution is section
2247 VI of that paper.</p>
2248 <hr>
2249 <a name="61"><h3>61.&nbsp;Ambiguity in iostreams exception policy</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
2250 <p>The introduction to the section on unformatted input (27.6.1.3)
2251 says that every unformatted input function catches all exceptions that
2252 were thrown during input, sets badbit, and then conditionally rethrows
2253 the exception. That seems clear enough. Several of the specific
2254 functions, however, such as get() and read(), are documented in some
2255 circumstances as setting eofbit and/or failbit. (The standard notes,
2256 correctly, that setting eofbit or failbit can sometimes result in an
2257 exception being thrown.) The question: if one of these functions
2258 throws an exception triggered by setting failbit, is this an exception
2259 "thrown during input" and hence covered by 27.6.1.3, or does
2260 27.6.1.3 only refer to a limited class of exceptions? Just to make
2261 this concrete, suppose you have the following snippet. </p>
2262
2263 <pre>
2264   char buffer[N];
2265   istream is;
2266   ...
2267   is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
2268   is.read(buffer, N);</pre>
2269
2270 <p>Now suppose we reach EOF before we've read N characters. What
2271 iostate bits can we expect to be set, and what exception (if any) will
2272 be thrown? </p>
2273 <p><b>Proposed resolution:</b></p>
2274 <p>
2275 In 27.6.1.3, paragraph 1, after the sentence that begins
2276 "If an exception is thrown...", add the following
2277 parenthetical comment: "(Exceptions thrown from
2278 <tt>basic_ios&lt;&gt;::clear()</tt> are not caught or rethrown.)"
2279 </p>
2280 <p><b>Rationale:</b></p>
2281 <p>The LWG looked to two alternative wordings, and choose the proposed
2282 resolution as better standardese.</p>
2283 <hr>
2284 <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>
2285 <p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
2286 "calls rdbuf()-&gt;pubsync() and, if that function returns -1
2287 ... returns traits::eof()." </p>
2288
2289 <p>That looks suspicious, because traits::eof() is of type
2290 traits::int_type while the return type of sync() is int. </p>
2291 <p><b>Proposed resolution:</b></p>
2292 <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
2293 <tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
2294 </p>
2295 <hr>
2296 <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>
2297 <p>Clause 27 details an exception-handling policy for formatted input,
2298 unformatted input, and formatted output. It says nothing for
2299 unformatted output (27.6.2.6). 27.6.2.6 should either include the same
2300 kind of exception-handling policy as in the other three places, or
2301 else it should have a footnote saying that the omission is
2302 deliberate. </p>
2303 <p><b>Proposed resolution:</b></p>
2304 <p>
2305 In 27.6.2.6, paragraph 1, replace the last sentence ("In any
2306 case, the unformatted output function ends by destroying the sentry
2307 object, then returning the value specified for the formatted output
2308 function.") with the following text:
2309 </p>
2310 <blockquote>
2311 If an exception is thrown during output, then <tt>ios::badbit</tt> is
2312 turned on [Footnote: without causing an <tt>ios::failure</tt> to be
2313 thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &amp;
2314 badbit) != 0</tt> then the exception is rethrown.  In any case, the
2315 unformatted output function ends by destroying the sentry object,
2316 then, if no exception was thrown, returning the value specified for
2317 the formatted output function.
2318 </blockquote>
2319 <p><b>Rationale:</b></p>
2320 <p>
2321 This exception-handling policy is consistent with that of formatted
2322 input, unformatted input, and formatted output.
2323 </p>
2324 <hr>
2325 <a name="64"><h3>64.&nbsp;Exception handling in <tt>basic_istream::operator&gt;&gt;(basic_streambuf*)</tt>
2326 </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>
2327 <p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
2328 different ways, depending on whether the second sentence is read as an
2329 elaboration of the first. </p>
2330 <p><b>Proposed resolution:</b></p>
2331 <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
2332 "If the function inserts no characters ..." with:</p>
2333
2334 <blockquote>
2335   <p>If the function inserts no characters, it calls
2336   <tt>setstate(failbit)</tt>, which may throw
2337   <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
2338   because it caught an exception thrown while extracting characters
2339   from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
2340   (27.4.4.3), then the caught exception is rethrown. </p>
2341 </blockquote>
2342 <hr>
2343 <a name="66"><h3>66.&nbsp;Strstreambuf::setbuf</h3></a><p><b>Section:</b>&nbsp;D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;18 Aug 1998</p>
2344 <p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
2345 "Performs an operation that is defined separately for each class
2346 derived from strstreambuf". This is obviously an incorrect
2347 cut-and-paste from basic_streambuf. There are no classes derived from
2348 strstreambuf. </p>
2349 <p><b>Proposed resolution:</b></p>
2350 <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
2351 clause which currently says "Performs an operation that is
2352 defined separately for each class derived from strstreambuf"
2353 with:</p>
2354
2355 <blockquote>
2356   <p><b>Effects</b>: implementation defined, except that
2357   <tt>setbuf(0,0)</tt> has no effect.</p>
2358 </blockquote>
2359 <hr>
2360 <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>
2361 <p>Extractors for char* (27.6.1.2.3) do not store a null character
2362 after the extracted character sequence whereas the unformatted
2363 functions like get() do. Why is this?</p>
2364
2365 <p>Comment from Jerry Schwarz: There is apparently an editing
2366 glitch. You'll notice that the last item of the list of what stops
2367 extraction doesn't make any sense. It was supposed to be the line that
2368 said a null is stored.</p>
2369 <p><b>Proposed resolution:</b></p>
2370 <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
2371 item from:</p>
2372
2373 <blockquote>
2374   A null byte (<tt>charT()</tt>) in the next position, which may be
2375   the first position if no characters were extracted.
2376 </blockquote>
2377
2378 <p>to become a new paragraph which reads:</p>
2379
2380 <blockquote>
2381   Operator&gt;&gt; then stores a null byte (<tt>charT()</tt>) in the
2382   next position, which may be the first position if no characters were
2383   extracted.
2384 </blockquote>
2385 <hr>
2386 <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>
2387 <p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
2388
2389 <p>(Please note that this is entirely separate from the question of
2390 whether a vector iterator is required to be a pointer; the answer to
2391 that question is clearly "no," as it would rule out
2392 debugging implementations)</p>
2393 <p><b>Proposed resolution:</b></p>
2394 <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>,
2395 paragraph 1. </p>
2396
2397 <blockquote>
2398   <p>The elements of a vector are stored contiguously, meaning that if
2399   v is a <tt>vector&lt;T, Allocator&gt;</tt> where T is some type
2400   other than <tt>bool</tt>, then it obeys the identity <tt>&amp;v[n]
2401   == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt; v.size()</tt>.</p>
2402 </blockquote>
2403 <p><b>Rationale:</b></p>
2404 <p>The LWG feels that as a practical matter the answer is clearly
2405 "yes".  There was considerable discussion as to the best way
2406 to express the concept of "contiguous", which is not
2407 directly defined in the standard.  Discussion included:</p>
2408
2409 <ul>
2410   <li>An operational definition similar to the above proposed resolution is
2411     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>
2412   <li>There is no need to explicitly consider a user-defined operator&amp;
2413     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)
2414     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
2415     requirements for operator&amp;.</li>
2416   <li>There is no issue of one-past-the-end because of language rules.</li>
2417 </ul>
2418 <hr>
2419 <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>
2420 <p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
2421
2422 <p>uncaught_exception() doesn't have a throw specification.</p>
2423
2424 <p>It is intentional ? Does it means that one should be prepared to
2425 handle exceptions thrown from uncaught_exception() ?</p>
2426
2427 <p>uncaught_exception() is called in exception handling contexts where
2428 exception safety is very important.</p>
2429 <p><b>Proposed resolution:</b></p>
2430 <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>
2431 <hr>
2432 <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>
2433 <p>The locale facet member <tt>time_get&lt;&gt;::do_get_monthname</tt>
2434 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,
2435 consistent with do_get_weekday and with its specified use by member
2436 get_monthname. However, in the synopsis, it is specified instead with
2437 four arguments. The missing argument is the "end" iterator
2438 value.</p>
2439 <p><b>Proposed resolution:</b></p>
2440 <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
2441 the declaration of member do_monthname as follows:</p>
2442
2443 <pre>  virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&amp;,
2444                                      ios_base::iostate&amp; err, tm* t) const;</pre>
2445 <hr>
2446 <a name="74"><h3>74.&nbsp;Garbled text for <tt>codecvt::do_max_length</tt>
2447 </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>
2448 <p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
2449 clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
2450 parentheses and a spurious <b>n</b>.</p>
2451 <p><b>Proposed resolution:</b></p>
2452 <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
2453 following:</p>
2454
2455 <blockquote>
2456   <b>Returns</b>: The maximum value that
2457   <tt>do_length(state, from, from_end, 1)</tt> can return for any
2458   valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
2459   <tt>state</tt>. The specialization <tt>codecvt&lt;char, char,
2460   mbstate_t&gt;::do_max_length()</tt> returns 1.
2461 </blockquote>
2462 <hr>
2463 <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
2464 Austern&nbsp; <b>Date:</b>&nbsp; 18 Sep 1998</p>
2465 <p>The class synopses for classes <tt>codecvt&lt;&gt;</tt> (22.2.1.5)
2466 and <tt>codecvt_byname&lt;&gt;</tt> (22.2.1.6) say that the first
2467 parameter of the member functions <tt>length</tt> and
2468 <tt>do_length</tt> is of type <tt>const stateT&amp;</tt>. The member
2469 function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
2470 paragraph 9) say that the type is <tt>stateT&amp;</tt>.  Either the
2471 synopsis or the summary must be changed. </p>
2472
2473 <p>If (as I believe) the member function descriptions are correct,
2474 then we must also add text saying how <tt>do_length</tt> changes its
2475 <tt>stateT</tt> argument. </p>
2476 <p><b>Proposed resolution:</b></p>
2477 <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>,
2478 change the <tt>stateT</tt> argument type on both member
2479 <tt>length()</tt> and member <tt>do_length()</tt> from </p>
2480
2481 <blockquote>
2482   <p><tt>const stateT&amp;</tt></p>
2483 </blockquote>
2484
2485 <p>to</p>
2486
2487 <blockquote>
2488   <p><tt>stateT&amp;</tt></p>
2489 </blockquote>
2490
2491 <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
2492 <tt>do_length</tt> a paragraph:</p>
2493
2494 <blockquote>
2495   <p>Effects: The effect on the <tt>state</tt> argument is ``as if''
2496   it called <tt>do_in(state, from, from_end, from, to, to+max,
2497   to)</tt> for <tt>to</tt> pointing to a buffer of at least
2498   <tt>max</tt> elements.</p>
2499 </blockquote>
2500 <hr>
2501 <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>
2502 <p>This issue concerns the requirements on classes derived from
2503 <tt>codecvt</tt>, including user-defined classes. What are the
2504 restrictions on the conversion from external characters
2505 (e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
2506 Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
2507 the I/O library make? </p>
2508
2509 <p>The question is whether it's possible to convert from internal
2510 characters to external characters one internal character at a time,
2511 and whether, given a valid sequence of external characters, it's
2512 possible to pick off internal characters one at a time. Or, to put it
2513 differently: given a sequence of external characters and the
2514 corresponding sequence of internal characters, does a position in the
2515 internal sequence correspond to some position in the external
2516 sequence? </p>
2517
2518 <p>To make this concrete, suppose that <tt>[first, last)</tt> is a
2519 sequence of <i>M</i> external characters and that <tt>[ifirst,
2520 ilast)</tt> is the corresponding sequence of <i>N</i> internal
2521 characters, where <i>N &gt; 1</i>. That is, <tt>my_encoding.in()</tt>,
2522 applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
2523 ilast)</tt>. Now the question: does there necessarily exist a
2524 subsequence of external characters, <tt>[first, last_1)</tt>, such
2525 that the corresponding sequence of internal characters is the single
2526 character <tt>*ifirst</tt>?
2527 </p>
2528
2529 <p>(What a "no" answer would mean is that
2530 <tt>my_encoding</tt> translates sequences only as blocks. There's a
2531 sequence of <i>M</i> external characters that maps to a sequence of
2532 <i>N</i> internal characters, but that external sequence has no
2533 subsequence that maps to <i>N-1</i> internal characters.) </p>
2534
2535 <p>Some of the wording in the standard, such as the description of
2536 <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>,
2537 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
2538 possible to pick off internal characters one at a time from a sequence
2539 of external characters. However, this is never explicitly stated one
2540 way or the other. </p>
2541
2542 <p>This issue seems (and is) quite technical, but it is important if
2543 we expect users to provide their own encoding facets. This is an area
2544 where the standard library calls user-supplied code, so a well-defined
2545 set of requirements for the user-supplied code is crucial. Users must
2546 be aware of the assumptions that the library makes. This issue affects
2547 positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
2548 and several of <tt>codecvt</tt>'s member functions. </p>
2549 <p><b>Proposed resolution:</b></p>
2550 <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>
2551
2552 <blockquote>
2553 <p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
2554 (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>
2555 <pre>    do_out(state, from, from_end, from_next, to, to_lim, to_next)
2556 </pre>
2557 would return <tt>ok</tt>, where <tt>from != from_end</tt>, then
2558 <pre>    do_out(state, from, from + 1, from_next, to, to_end, to_next)
2559 </pre>
2560 must also return <tt>ok</tt>, and that if
2561 <pre>    do_in(state, from, from_end, from_next, to, to_lim, to_next)
2562 </pre>
2563 would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then
2564 <pre>    do_in(state, from, from_end, from_next, to, to + 1, to_next)
2565 </pre>
2566 <p>must also return <tt>ok</tt>.  [<i>Footnote:</i> Informally, this
2567 means that <tt>basic_filebuf</tt> assumes that the mapping from
2568 internal to external characters is 1 to N: a <tt>codecvt</tt> that is
2569 used by <tt>basic_filebuf</tt> must be able to translate characters
2570 one internal character at a time.  <i>--End Footnote</i>]</p>
2571 </blockquote>
2572
2573 <p><i>[Redmond: Minor change in proposed resolution.  Original
2574 proposed resolution talked about "success", with a parenthetical
2575 comment that success meant returning <tt>ok</tt>.  New wording
2576 removes all talk about "success", and just talks about the
2577 return value.]</i></p>
2578
2579 <p><b>Rationale:</b></p>
2580
2581   <p>The proposed resoluion says that conversions can be performed one
2582   internal character at a time.  This rules out some encodings that
2583   would otherwise be legal.  The alternative answer would mean there
2584   would be some internal positions that do not correspond to any
2585   external file position.</p>
2586   <p>
2587   An example of an encoding that this rules out is one where the
2588   <tt>internT</tt> and <tt>externT</tt> are of the same type, and
2589   where the internal sequence <tt>c1 c2</tt> corresponds to the
2590   external sequence <tt>c2 c1</tt>.
2591   </p>
2592   <p>It was generally agreed that <tt>basic_filebuf</tt> relies
2593   on this property: it was designed under the assumption that
2594   the external-to-internal mapping is N-to-1, and it is not clear
2595   that <tt>basic_filebuf</tt> is implementable without that
2596   restriction.
2597   </p>
2598   <p>
2599   The proposed resolution is expressed as a restriction on
2600   <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
2601   than a blanket restriction on all <tt>codecvt</tt> facets,
2602   because <tt>basic_filebuf</tt> is the only other part of the
2603   library that uses <tt>codecvt</tt>.  If a user wants to define
2604   a <tt>codecvt</tt> facet that implements a more general N-to-M
2605   mapping, there is no reason to prohibit it, so long as the user
2606   does not expect <tt>basic_filebuf</tt> to be able to use it.
2607   </p>
2608 <hr>
2609 <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>
2610 <p>typo: event_call_back should be event_callback &nbsp; </p>
2611 <p><b>Proposed resolution:</b></p>
2612 <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
2613 "event_call_back" to "event_callback". </p>
2614 <hr>
2615 <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>
2616 <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>
2617 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;); </pre>
2618
2619 <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>
2620 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
2621
2622 <p>Thus whether the second parameter is optional is not clear. </p>
2623 <p><b>Proposed resolution:</b></p>
2624 <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>
2625 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;);</pre>
2626
2627 <p>to:</p>
2628 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
2629 <hr>
2630 <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>
2631 <p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
2632 class complex. This redundancy should be removed.</p>
2633 <p><b>Proposed resolution:</b></p>
2634 <p>Reduce redundancy according to the general style of the standard. </p>
2635 <hr>
2636 <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>
2637 <p>Many string member functions throw if size is getting or exceeding
2638 npos. However, I wonder why they don't throw if size is getting or
2639 exceeding max_size() instead of npos.  May be npos is known at compile
2640 time, while max_size() is known at runtime. However, what happens if
2641 size exceeds max_size() but not npos, then? It seems the standard
2642 lacks some clarifications here.</p>
2643 <p><b>Proposed resolution:</b></p>
2644 <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
2645 described in this clause...") add a new paragraph:</p>
2646
2647 <blockquote>
2648   <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
2649   <tt> max_size()</tt> then
2650   the operation throws <tt>length_error</tt>.</p>
2651 </blockquote>
2652 <p><b>Rationale:</b></p>
2653 <p>The LWG believes length_error is the correct exception to throw.</p>
2654 <hr>
2655 <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>
2656 <p>The constructor from a range:</p>
2657
2658 <pre>template&lt;class InputIterator&gt;
2659          basic_string(InputIterator begin, InputIterator end,
2660                       const Allocator&amp; a = Allocator());</pre>
2661
2662 <p>lacks a throws clause. However, I would expect that it throws
2663 according to the other constructors if the numbers of characters in
2664 the range equals npos (or exceeds max_size(), see above). </p>
2665 <p><b>Proposed resolution:</b></p>
2666 <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
2667 constructors which say "Throws: length_error if n ==
2668 npos."</p>
2669 <p><b>Rationale:</b></p>
2670 <p>Throws clauses for length_error if n == npos are no longer needed
2671 because they are subsumed by the general wording added by the
2672 resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
2673 <hr>
2674 <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>
2675 <p>The effect of operator &gt;&gt; for strings contain the following item:</p>
2676
2677 <p>&nbsp;&nbsp;&nbsp; <tt>isspace(c,getloc())</tt> is true for the next available input
2678 character c.</p>
2679
2680 <p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
2681 <p><b>Proposed resolution:</b></p>
2682 <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>
2683
2684 <blockquote>
2685   <p><tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
2686 </blockquote>
2687
2688 <p>with:</p>
2689
2690 <blockquote>
2691   <p><tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
2692 </blockquote>
2693 <hr>
2694 <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>
2695 <p>Operator &gt;&gt; and getline() for strings read until eof()
2696 in the input stream is true. However, this might never happen, if the
2697 stream can't read anymore without reaching EOF. So shouldn't it be
2698 changed into that it reads until !good() ? </p>
2699 <p><b>Proposed resolution:</b></p>
2700 <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>
2701 <blockquote>
2702 Effects: Begins by constructing a sentry object k as if k were
2703 constructed by typename basic_istream&lt;charT,traits&gt;::sentry k( is). If
2704 bool( k) is true, it calls str.erase() and then extracts characters
2705 from is and appends them to str as if by calling str.append(1, c). If
2706 is.width() is greater than zero, the maximum number n of characters
2707 appended is is.width(); otherwise n is str.max_size(). Characters are
2708 extracted and appended until any of the following occurs:
2709 </blockquote>
2710 <p>with:</p>
2711 <blockquote>
2712 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
2713 sentry converts to true, calls str.erase() and then extracts
2714 characters from is and appends them to str as if by calling
2715 str.append(1,c). If is.width() is greater than zero, the maximum
2716 number n of characters appended is is.width(); otherwise n is
2717 str.max_size(). Characters are extracted and appended until any of the
2718 following occurs:
2719 </blockquote>
2720
2721 <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>
2722 <blockquote>
2723 Effects: Begins by constructing a sentry object k as if by typename
2724 basic_istream&lt;charT,traits&gt;::sentry k( is, true). If bool( k) is true,
2725 it calls str.erase() and then extracts characters from is and appends
2726 them to str as if by calling str.append(1, c) until any of the
2727 following occurs:
2728 </blockquote>
2729 <p>with:</p>
2730 <blockquote>
2731 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
2732 by subsequent calls to basic_istream&lt;&gt;::gcount().  After
2733 constructing a sentry object, if the sentry converts to true, calls
2734 str.erase() and then extracts characters from is and appends them to
2735 str as if by calling str.append(1,c) until any of the following
2736 occurs:
2737 </blockquote>
2738
2739 <p><i>[Redmond: Made changes in proposed resolution.  <tt>operator&gt;&gt;</tt>
2740 should be a formatted input function, not an unformatted input function.
2741 <tt>getline</tt> should not be required to set <tt>gcount</tt>, since
2742 there is no mechanism for <tt>gcount</tt> to be set except by one of
2743 <tt>basic_istream</tt>'s member functions.]</i></p>
2744
2745 <p><i>[Curaçao: Nico agrees with proposed resolution.]</i></p>
2746
2747 <p><b>Rationale:</b></p>
2748 <p>The real issue here is whether or not these string input functions
2749 get their characters from a streambuf, rather than by calling an
2750 istream's member functions, a streambuf signals failure either by
2751 returning eof or by throwing an exception; there are no other
2752 possibilities.  The proposed resolution makes it clear that these two
2753 functions do get characters from a streambuf.</p>
2754 <hr>
2755 <a name="92"></a><h3><a name="92">92.&nbsp;Incomplete Algorithm Requirements</a></h3><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>
2756 <p>The standard does not state, how often a function object is copied,
2757 called, or the order of calls inside an algorithm. This may lead to
2758 surprising/buggy behavior. Consider the following example: </p>
2759
2760 <pre>class Nth {    // function object that returns true for the nth element
2761   private:
2762     int nth;     // element to return true for
2763     int count;   // element counter
2764   public:
2765     Nth (int n) : nth(n), count(0) {
2766     }
2767     bool operator() (int) {
2768         return ++count == nth;
2769     }
2770 };
2771 ....
2772 // remove third element
2773     list&lt;int&gt;::iterator pos;
2774     pos = remove_if(coll.begin(),coll.end(),  // range
2775                     Nth(3)),                  // remove criterion
2776     coll.erase(pos,coll.end()); </pre>
2777
2778 <p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
2779 happens because the usual implementation of the algorithm copies the
2780 function object internally: </p>
2781
2782 <pre>template &lt;class ForwIter, class Predicate&gt;
2783 ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op)
2784 {
2785     beg = find_if(beg, end, op);
2786     if (beg == end) {
2787         return beg;
2788     }
2789     else {
2790         ForwIter next = beg;
2791         return remove_copy_if(++next, end, beg, op);
2792     }
2793 } </pre>
2794
2795 <p>The algorithm uses find_if() to find the first element that should
2796 be removed. However, it then uses a copy of the passed function object
2797 to process the resulting elements (if any). Here, Nth is used again
2798 and removes also the sixth element. This behavior compromises the
2799 advantage of function objects being able to have a state. Without any
2800 cost it could be avoided (just implement it directly instead of
2801 calling find_if()). </p>
2802 <p><b>Proposed resolution:</b></p>
2803
2804 <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>
2805 <blockquote>
2806 [Note: Unless otherwise specified, algorithms that take function
2807 objects as arguments are permitted to copy those function objects
2808 freely.  Programmers for whom object identity is important should
2809 consider using a wrapper class that points to a noncopied
2810 implementation object, or some equivalent solution.]
2811 </blockquote>
2812
2813 <p><i>[Dublin: Pete Becker felt that this may not be a defect,
2814 but rather something that programmers need to be educated about.
2815 There was discussion of adding wording to the effect that the number
2816 and order of calls to function objects, including predicates, not
2817 affect the behavior of the function object.]</i></p>
2818
2819 <p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
2820 have a clear statement of "predicate" in the
2821 standard. People including me seemed to think "a function
2822 returning a Boolean value and being able to be called by an STL
2823 algorithm or be used as sorting criterion or ... is a
2824 predicate". But a predicate has more requirements: It should
2825 never change its behavior due to a call or being copied. IMHO we have
2826 to state this in the standard. If you like, see section 8.1.4 of my
2827 library book for a detailed discussion.]</i></p>
2828
2829 <p><i>[Kona: Nico will provide wording to the effect that "unless
2830 otherwise specified, the number of copies of and calls to function
2831 objects by algorithms is unspecified".&nbsp; Consider placing in
2832 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>
2833
2834 <p><i>[Santa Cruz: The standard doesn't currently guarantee that
2835   functions object won't be copied, and what isn't forbidden is
2836   allowed.  It is believed (especially since implementations that were
2837   written in concert with the standard do make copies of function
2838   objects) that this was intentional.  Thus, no normative change is
2839   needed.  What we should put in is a non-normative note suggesting to
2840   programmers that if they want to guarantee the lack of copying they
2841   should use something like the <tt>ref</tt> wrapper.]</i></p>
2842
2843 <p><i>[Oxford: Matt provided wording.]</i></p>
2844
2845
2846 <hr>
2847 <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>
2848 <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
2849 <tt>*r++</tt> of:</p>
2850
2851 <p>&nbsp;&nbsp; <tt>{ T tmp = *r; ++r; return tmp; }</tt></p>
2852
2853 <p>There are two problems with this.  First, the return type is
2854 specified to be "T", as opposed to something like "convertible to T".
2855 This is too specific: we want to allow *r++ to return an lvalue.</p>
2856
2857 <p>Second, writing the semantics in terms of code misleadingly
2858 suggests that the effects *r++ should precisely replicate the behavior
2859 of this code, including side effects.  (Does this mean that *r++
2860 should invoke the copy constructor exactly as many times as the sample
2861 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
2862 problem.</p>
2863
2864 <p><b>Proposed resolution:</b></p>
2865 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
2866 for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".
2867 <p><b>Rationale:</b></p>
2868 <p>This issue has two parts: the return type, and the number of times
2869   the copy constructor is invoked.</p>
2870
2871 <p>The LWG believes the the first part is a real issue.  It's
2872   inappropriate for the return type to be specified so much more
2873   precisely for *r++ than it is for *r.  In particular, if r is of
2874   (say) type <tt>int*</tt>, then *r++ isn't <tt>int</tt>,
2875   but <tt>int&amp;</tt>.</p>
2876
2877 <p>The LWG does not believe that the number of times the copy
2878   constructor is invoked is a real issue.  This can vary in any case,
2879   because of language rules on copy constructor elision.  That's too
2880   much to read into these semantics clauses.</p>
2881
2882 <p>Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since
2883    we're told (24.1/3) that forward iterators satisfy all the requirements
2884    of input iterators, we can't impose any requirements in the Input
2885    Iterator requirements table that forward iterators don't satisfy.</p>
2886 <hr>
2887 <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>
2888 <p>Set::iterator is described as implementation-defined with a
2889 reference to the container requirement; the container requirement says
2890 that const_iterator is an iterator pointing to const T and iterator an
2891 iterator pointing to T.</p>
2892
2893 <p>23.1.2 paragraph 2 implies that the keys should not be modified to
2894 break the ordering of elements. But that is not clearly
2895 specified. Especially considering that the current standard requires
2896 that iterator for associative containers be different from
2897 const_iterator. Set, for example, has the following: </p>
2898
2899 <p><tt>typedef implementation defined iterator;<br>
2900 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // See _lib.container.requirements_</tt></p>
2901
2902 <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
2903 to T (table 65). Disallowing user modification of keys by changing the
2904 standard to require an iterator for associative container to be the
2905 same as const_iterator would be overkill since that will unnecessarily
2906 significantly restrict the usage of associative container. A class to
2907 be used as elements of set, for example, can no longer be modified
2908 easily without either redesigning the class (using mutable on fields
2909 that have nothing to do with ordering), or using const_cast, which
2910 defeats requiring iterator to be const_iterator. The proposed solution
2911 goes in line with trusting user knows what he is doing. </p>
2912
2913 <p><b>Other Options Evaluated:</b> </p>
2914
2915 <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
2916 first sentence, and before "In addition,...", add one line:
2917 </p>
2918
2919 <blockquote>
2920   <p>Modification of keys shall not change their strict weak ordering. </p>
2921 </blockquote>
2922
2923 <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>
2924
2925 <blockquote>
2926   <p>At the end of paragraph 5: "Keys in an associative container
2927   are immutable." At the end of paragraph 6: "For
2928   associative containers where the value type is the same as the key
2929   type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
2930   constant iterators. It is unspecified whether or not
2931   <tt>iterator</tt> and <tt>const_iterator</tt> are the same
2932   type."</p>
2933 </blockquote>
2934
2935 <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
2936 currently reads:</p>
2937
2938 <blockquote>
2939   <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
2940   comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
2941   container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
2942   == false &amp;&amp; comp(k2, k1) == false.</p>
2943 </blockquote>
2944
2945 <p>&nbsp; add the following:</p>
2946
2947 <blockquote>
2948   <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
2949   value whenever it is evaluated. [Note: If k2 is removed from the container and later
2950   reinserted, comp(k1, k2) must still return a consistent value but this value may be
2951   different than it was the first time k1 and k2 were in the same container. This is
2952   intended to allow usage like a string key that contains a filename, where comp compares
2953   file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
2954   reinserted, comp(k1, k2) must again return a consistent value but this value may be
2955   different than it was the previous time k2 was in the container.]</p>
2956 </blockquote>
2957 <p><b>Proposed resolution:</b></p>
2958 <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
2959 the indicated location:</p>
2960
2961 <blockquote>
2962   <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
2963   calling comp(k1, k2) shall always return the same
2964   value."</p>
2965   <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
2966   <p>At the end of paragraph 6: "For associative containers where the value type is the
2967   same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
2968   iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
2969   are the same type."</p>
2970 </blockquote>
2971 <p><b>Rationale:</b></p>
2972 <p>Several arguments were advanced for and against allowing set elements to be
2973 mutable as long as the ordering was not effected. The argument which swayed the
2974 LWG was one of safety; if elements were mutable, there would be no compile-time
2975 way to detect of a simple user oversight which caused ordering to be
2976 modified.  There was a report that this had actually happened in practice,
2977 and had been painful to diagnose.  If users need to modify elements,
2978 it is possible to use mutable members or const_cast.</p>
2979
2980 <p>Simply requiring that keys be immutable is not sufficient, because the comparison
2981 object may indirectly (via pointers) operate on values outside of the keys.</p>
2982
2983 <p>
2984 The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
2985 to be different types to allow for potential future work in which some
2986 member functions might be overloaded between the two types.  No such
2987 member functions exist now, and the LWG believes that user functionality
2988 will not be impaired by permitting the two types to be the same.  A
2989 function that operates on both iterator types can be defined for
2990 <tt>const_iterator</tt> alone, and can rely on the automatic
2991 conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
2992 </p>
2993
2994 <p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
2995 <hr>
2996 <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>
2997 <p>This is the only place in the whole standard where the implementation has to document
2998 something private.</p>
2999 <p><b>Proposed resolution:</b></p>
3000 <p>
3001 Remove the comment which says "// remainder implementation defined" from:
3002 </p>
3003
3004 <ul>
3005   <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>
3006 </li>
3007   <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>
3008 </li>
3009   <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>
3010 </li>
3011   <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>
3012 </li>
3013 </ul>
3014 <hr>
3015 <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>
3016 <p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
3017 exception::what() is left unspecified. This issue has implications
3018 with exception safety of exception handling: some exceptions should
3019 not throw bad_alloc.</p>
3020 <p><b>Proposed resolution:</b></p>
3021 <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
3022 clause) the sentence:</p>
3023
3024 <blockquote>
3025   <p>The return value remains valid until the exception object from which it is obtained is
3026   destroyed or a non-const member function of the exception object is called.</p>
3027 </blockquote>
3028 <p><b>Rationale:</b></p>
3029 <p>If an exception object has non-const members, they may be used
3030 to set internal state that should affect the contents of the string
3031 returned by <tt>what()</tt>.
3032 </p>
3033 <hr>
3034 <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>
3035
3036 <p>There are no versions of binders that apply to non-const elements
3037 of a sequence. This makes examples like for_each() using bind2nd() on
3038 page 521 of "The C++ Programming Language (3rd)"
3039 non-conforming. Suitable versions of the binders need to be added.</p>
3040
3041 <p>Further discussion from Nico:</p>
3042
3043 <p>What is probably meant here is shown in the following example:</p>
3044
3045 <pre>class Elem {
3046   public:
3047     void print (int i) const { }
3048     void modify (int i) { }
3049 }; </pre>
3050 <pre>int main()
3051 {
3052     vector&lt;Elem&gt; coll(2);
3053     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::print),42));    // OK
3054     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::modify),42));   // ERROR
3055 }</pre>
3056
3057 <p>The error results from the fact that bind2nd() passes its first
3058 argument (the argument of the sequence) as constant reference. See the
3059 following typical implementation:</p>
3060
3061 <blockquote>
3062   <pre>template &lt;class Operation&gt;
3063 class binder2nd
3064   : public unary_function&lt;typename Operation::first_argument_type,
3065                           typename Operation::result_type&gt; {
3066 protected:
3067   Operation op;
3068   typename Operation::second_argument_type value;
3069 public:
3070   binder2nd(const Operation&amp; o,
3071             const typename Operation::second_argument_type&amp; v)
3072       : op(o), value(v) {} </pre>
3073   <pre> typename Operation::result_type
3074   operator()(const typename Operation::first_argument_type&amp; x) const {
3075     return op(x, value);
3076   }
3077 };</pre>
3078 </blockquote>
3079
3080 <p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
3081
3082 <blockquote>
3083   <pre>template &lt;class Operation&gt;
3084 class binder2nd
3085   : public unary_function&lt;typename Operation::first_argument_type,
3086                           typename Operation::result_type&gt; {
3087 protected:
3088   Operation op;
3089   typename Operation::second_argument_type value;
3090 public:
3091   binder2nd(const Operation&amp; o,
3092             const typename Operation::second_argument_type&amp; v)
3093       : op(o), value(v) {} </pre>
3094   <pre> typename Operation::result_type
3095   operator()(const typename Operation::first_argument_type&amp; x) const {
3096     return op(x, value);
3097   }
3098   typename Operation::result_type
3099   operator()(typename Operation::first_argument_type&amp; x) const {
3100     return op(x, value);
3101   }
3102 };</pre>
3103 </blockquote>
3104 <p><b>Proposed resolution:</b></p>
3105
3106 <p><b>Howard believes there is a flaw</b> in this resolution.
3107 See c++std-lib-9127.  We may need to reopen this issue.</p>
3108
3109 <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>
3110 <blockquote>
3111   <p><tt>typename Operation::result_type<br>
3112   &nbsp;operator()(const typename Operation::second_argument_type&amp; x) const;</tt></p>
3113 </blockquote>
3114 <p>insert:</p>
3115 <blockquote>
3116   <p><tt>typename Operation::result_type<br>
3117   &nbsp;operator()(typename Operation::second_argument_type&amp; x) const;</tt></p>
3118 </blockquote>
3119 <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>
3120 <blockquote>
3121   <p><tt>typename Operation::result_type<br>
3122   &nbsp;operator()(const typename Operation::first_argument_type&amp; x) const;</tt></p>
3123 </blockquote>
3124 <p>insert:</p>
3125 <blockquote>
3126   <p><tt>typename Operation::result_type<br>
3127   &nbsp;operator()(typename Operation::first_argument_type&amp; x) const;</tt></p>
3128 </blockquote>
3129
3130 <p><i>[Kona: The LWG discussed this at some length.It was agreed that
3131 this is a mistake in the design, but there was no consensus on whether
3132 it was a defect in the Standard.  Straw vote: NAD - 5.  Accept
3133 proposed resolution - 3.  Leave open - 6.]</i></p>
3134
3135 <p><i>[Copenhagen: It was generally agreed that this was a defect.
3136 Strap poll: NAD - 0.  Accept proposed resolution - 10.
3137 Leave open - 1.]</i></p>
3138
3139 <hr>
3140 <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>
3141 <p>Member istreambuf_iterator&lt;&gt;::equal is not declared
3142 "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==,
3143 which is const, calls it. This is contradictory. </p>
3144 <p><b>Proposed resolution:</b></p>
3145 <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>,
3146 replace:</p>
3147
3148 <blockquote>
3149   <pre>bool equal(istreambuf_iterator&amp; b);</pre>
3150 </blockquote>
3151
3152 <p>with:</p>
3153
3154 <blockquote>
3155   <pre>bool equal(const istreambuf_iterator&amp; b) const;</pre>
3156 </blockquote>
3157 <hr>
3158 <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>
3159 <p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
3160 constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
3161 reads "<i>s</i> is not null". However, <i>s</i> is a
3162 reference, and references can't be null. </p>
3163 <p><b>Proposed resolution:</b></p>
3164 <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>
3165
3166 <p>Move the current paragraph 1, which reads "Requires: s is not
3167 null.", from the first constructor to the second constructor.</p>
3168
3169 <p>Insert a new paragraph 1 Requires clause for the first constructor
3170 reading:</p>
3171
3172 <blockquote>
3173   <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
3174 </blockquote>
3175 <hr>
3176 <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>
3177 <p>Section 18.4.1.3 contains the following example: </p>
3178
3179 <pre>[Example: This can be useful for constructing an object at a known address:
3180         char place[sizeof(Something)];
3181         Something* p = new (place) Something();
3182  -end example]</pre>
3183
3184 <p>First code line: "place" need not have any special alignment, and the
3185 following constructor could fail due to misaligned data.</p>
3186
3187 <p>Second code line: Aren't the parens on Something() incorrect?&nbsp; [Dublin: the LWG
3188 believes the () are correct.]</p>
3189
3190 <p>Examples are not normative, but nevertheless should not show code that is invalid or
3191 likely to fail.</p>
3192 <p><b>Proposed resolution:</b></p>
3193 <p>Replace the <u> first line of code</u> in the example in
3194 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:
3195 </p>
3196
3197 <blockquote>
3198   <pre>void* place = operator new(sizeof(Something));</pre>
3199 </blockquote>
3200 <hr>
3201 <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>
3202 <p>D.7.4.1 strstream constructors paragraph 2 says: </p>
3203
3204 <blockquote>
3205   <p>Effects: Constructs an object of class strstream, initializing the base class with
3206   iostream(&amp; sb) and initializing sb with one of the two constructors: </p>
3207   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
3208   elements. The constructor is strstreambuf(s, n, s). </p>
3209   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
3210   elements that contains an NTBS whose first element is designated by s. The constructor is
3211   strstreambuf(s, n, s+std::strlen(s)).</p>
3212 </blockquote>
3213
3214 <p>Notice the second condition is the same as the first. I think the second condition
3215 should be "If mode&amp;app==app", or "mode&amp;app!=0", meaning that
3216 the append bit is set.</p>
3217 <p><b>Proposed resolution:</b></p>
3218 <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>
3219 paragraph 2, change the first condition to <tt>(mode&amp;app)==0</tt>
3220 and the second condition to <tt>(mode&amp;app)!=0</tt>.</p>
3221 <hr>
3222 <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>
3223 <p>The <b>effects</b> clause for numeric inserters says that
3224 insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
3225 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
3226 int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
3227 <tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
3228 delegated to <tt>num_put</tt>, and that insertion is performed as if
3229 through the following code fragment: </p>
3230
3231 <pre>bool failed = use_facet&lt;
3232    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3233    &gt;(getloc()).put(*this, *this, fill(), val). failed();</pre>
3234
3235 <p>This doesn't work, because <tt>num_put&lt;&gt;</tt>::put is only
3236 overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
3237 long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
3238 void*</tt>. That is, the code fragment in the standard is incorrect
3239 (it is diagnosed as ambiguous at compile time) for the types
3240 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
3241 int</tt>, and <tt>float</tt>. </p>
3242
3243 <p>We must either add new member functions to <tt>num_put</tt>, or
3244 else change the description in <tt>ostream</tt> so that it only calls
3245 functions that are actually there. I prefer the latter. </p>
3246 <p><b>Proposed resolution:</b></p>
3247 <p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
3248
3249 <blockquote>
3250 <p>
3251 The classes num_get&lt;&gt; and num_put&lt;&gt; handle localedependent numeric
3252 formatting and parsing.  These inserter functions use the imbued
3253 locale value to perform numeric formatting.  When val is of type bool,
3254 long, unsigned long, double, long double, or const void*, the
3255 formatting conversion occurs as if it performed the following code
3256 fragment:
3257 </p>
3258
3259 <pre>bool failed = use_facet&lt;
3260    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3261    &gt;(getloc()).put(*this, *this, fill(), val). failed();
3262 </pre>
3263
3264 <p>
3265 When val is of type short the formatting conversion occurs as if it
3266 performed the following code fragment:
3267 </p>
3268
3269 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
3270 bool failed = use_facet&lt;
3271    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3272    &gt;(getloc()).put(*this, *this, fill(),
3273       baseflags == ios_base::oct || baseflags == ios_base::hex
3274          ? static_cast&lt;long&gt;(static_cast&lt;unsigned short&gt;(val))
3275          : static_cast&lt;long&gt;(val)). failed();
3276 </pre>
3277
3278 <p>
3279 When val is of type int the formatting conversion occurs as if it performed
3280 the following code fragment:
3281 </p>
3282
3283 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
3284 bool failed = use_facet&lt;
3285    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3286    &gt;(getloc()).put(*this, *this, fill(),
3287       baseflags == ios_base::oct || baseflags == ios_base::hex
3288          ? static_cast&lt;long&gt;(static_cast&lt;unsigned int&gt;(val))
3289          : static_cast&lt;long&gt;(val)). failed();
3290 </pre>
3291
3292 <p>
3293 When val is of type unsigned short or unsigned int the formatting conversion
3294 occurs as if it performed the following code fragment:
3295 </p>
3296
3297 <pre>bool failed = use_facet&lt;
3298    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3299    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;unsigned long&gt;(val)).
3300 failed();
3301 </pre>
3302
3303 <p>
3304 When val is of type float the formatting conversion occurs as if it
3305 performed the following code fragment:
3306 </p>
3307
3308 <pre>bool failed = use_facet&lt;
3309    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3310    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;double&gt;(val)).
3311 failed();
3312 </pre>
3313
3314 </blockquote>
3315
3316 <p><i>[post-Toronto: This differs from the previous proposed
3317 resolution; PJP provided the new wording.  The differences are in
3318 signed short and int output.]</i></p>
3319 <p><b>Rationale:</b></p>
3320 <p>The original proposed resolution was to cast int and short to long,
3321 unsigned int and unsigned short to unsigned long, and float to double,
3322 thus ensuring that we don't try to use nonexistent num_put&lt;&gt;
3323 member functions.  The current proposed resolution is more
3324 complicated, but gives more expected results for hex and octal output
3325 of signed short and signed int.  (On a system with 16-bit short, for
3326 example, printing short(-1) in hex format should yield 0xffff.)</p>
3327 <hr>
3328 <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>
3329 <p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
3330 <tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
3331 <tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
3332 formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
3333
3334 <pre>typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3335 iostate err = 0;
3336 use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, val);
3337 setstate(err);</pre>
3338
3339 <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,
3340 <tt>num_get&lt;&gt;::get()</tt> is only overloaded for the types
3341 <tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
3342 int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
3343 <tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
3344 <tt>void*</tt>. Comparing the lists from the two sections, we find
3345 that 27.6.1.2.2 is using a nonexistent function for types
3346 <tt>short</tt> and <tt>int</tt>. </p>
3347 <p><b>Proposed resolution:</b></p>
3348 <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
3349 two lines (1st and 3rd) which read:</p>
3350 <blockquote>
3351   <pre>operator&gt;&gt;(short&amp; val);
3352 ...
3353 operator&gt;&gt;(int&amp; val);</pre>
3354 </blockquote>
3355
3356 <p>And add the following at the end of that section (27.6.1.2.2) :</p>
3357
3358 <blockquote>
3359   <pre>operator&gt;&gt;(short&amp; val);</pre>
3360   <p>The conversion occurs as if performed by the following code fragment (using
3361   the same notation as for the preceding code fragment):</p>
3362   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3363   iostate err = 0;
3364   long lval;
3365   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
3366         if (err == 0
3367                 &amp;&amp; (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval))
3368                 err = ios_base::failbit;
3369   setstate(err);</pre>
3370   <pre>operator&gt;&gt;(int&amp; val);</pre>
3371   <p>The conversion occurs as if performed by the following code fragment (using
3372   the same notation as for the preceding code fragment):</p>
3373   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3374   iostate err = 0;
3375   long lval;
3376   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
3377         if (err == 0
3378                 &amp;&amp; (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval))
3379                 err = ios_base::failbit;
3380   setstate(err);</pre>
3381 </blockquote>
3382
3383 <p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
3384 <hr>
3385 <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>
3386 <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>
3387
3388 <p>"An implementation may strengthen the exception-specification
3389 for a function by removing listed exceptions." </p>
3390
3391 <p>The problem is that if an implementation is allowed to do this for
3392 virtual functions, then a library user cannot write a class that
3393 portably derives from that class. </p>
3394
3395 <p>For example, this would not compile if ios_base::failure::~failure
3396 had an empty exception specification: </p>
3397
3398 <pre>#include &lt;ios&gt;
3399 #include &lt;string&gt;
3400
3401 class D : public std::ios_base::failure {
3402 public:
3403         D(const std::string&amp;);
3404         ~D(); // error - exception specification must be compatible with
3405               // overridden virtual function ios_base::failure::~failure()
3406 };</pre>
3407 <p><b>Proposed resolution:</b></p>
3408 <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>
3409
3410 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
3411 exception-specification for a function"</p>
3412
3413 <p>to:</p>
3414
3415 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
3416 exception-specification for a non-virtual function". </p>
3417 <hr>
3418 <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>
3419
3420 <p>The original issue asked whether a library implementor could
3421 specialize standard library templates for built-in types.  (This was
3422 an issue because users are permitted to explicitly instantiate
3423 standard library templates.)</p>
3424
3425 <p>Specializations are no longer a problem, because of the resolution
3426 to core issue 259.  Under the proposed resolution, it will be legal
3427 for a translation unit to contain both a specialization and an
3428 explicit instantiation of the same template, provided that the
3429 specialization comes first.  In such a case, the explicit
3430 instantiation will be ignored.  Further discussion of library issue
3431 120 assumes that the core 259 resolution will be adopted.</p>
3432
3433 <p>However, as noted in lib-7047, one piece of this issue still
3434 remains: what happens if a standard library implementor explicitly
3435 instantiates a standard library templates?  It's illegal for a program
3436 to contain two different explicit instantiations of the same template
3437 for the same type in two different translation units (ODR violation),
3438 and the core working group doesn't believe it is practical to relax
3439 that restriction.</p>
3440
3441 <p>The issue, then, is: are users allowed to explicitly instantiate
3442 standard library templates for non-user defined types?  The status quo
3443 answer is 'yes'.  Changing it to 'no' would give library implementors
3444 more freedom.</p>
3445
3446 <p>This is an issue because, for performance reasons, library
3447 implementors often need to explicitly instantiate standard library
3448 templates.  (for example, std::basic_string&lt;char&gt;)  Does giving
3449 users freedom to explicitly instantiate standard library templates for
3450 non-user defined types make it impossible or painfully difficult for
3451 library implementors to do this?</p>
3452
3453 <p>John Spicer suggests, in lib-8957, that library implementors have a
3454 mechanism they can use for explicit instantiations that doesn't
3455 prevent users from performing their own explicit instantiations: put
3456 each explicit instantiation in its own object file.  (Different
3457 solutions might be necessary for Unix DSOs or MS-Windows DLLs.)  On
3458 some platforms, library implementors might not need to do anything
3459 special: the "undefined behavior" that results from having two
3460 different explicit instantiations might be harmless.</p>
3461
3462 <p><b>Proposed resolution:</b></p>
3463   <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>
3464   <blockquote>
3465     A program may explicitly instantiate any templates in the standard
3466     library only if the declaration depends on the name of a user-defined
3467     type of external linkage and the instantiation meets the standard library
3468     requirements for the original template.
3469   </blockquote>
3470
3471 <p><i>[Kona: changed the wording from "a user-defined name" to "the name of
3472   a user-defined type"]</i></p>
3473
3474 <p><b>Rationale:</b></p>
3475 <p>The LWG considered another possible resolution:</p>
3476 <blockquote>
3477   <p>In light of the resolution to core issue 259, no normative changes
3478   in the library clauses are necessary.  Add the following non-normative
3479   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>
3480   <blockquote>
3481     [<i>Note:</i> A program may explicitly instantiate standard library
3482     templates, even when an explicit instantiation does not depend on
3483     a user-defined name. <i>--end note</i>]
3484   </blockquote>
3485 </blockquote>
3486
3487 <p>The LWG rejected this because it was believed that it would make
3488   it unnecessarily difficult for library implementors to write
3489   high-quality implementations.  A program may not include an
3490   explicit instantiation of the same template, for the same template
3491   arguments, in two different translation units.  If users are
3492   allowed to provide explicit instantiations of Standard Library
3493   templates for built-in types, then library implementors aren't,
3494   at least not without nonportable tricks.</p>
3495
3496 <p>The most serious problem is a class template that has writeable
3497   static member variables.  Unfortunately, such class templates are
3498   important and, in existing Standard Library implementations, are
3499   often explicitly specialized by library implementors: locale facets,
3500   which have a writeable static member variable <tt>id</tt>.  If a
3501   user's explicit instantiation collided with the implementations
3502   explicit instantiation, iostream initialization could cause locales
3503   to be constructed in an inconsistent state.</p>
3504
3505 <p>One proposed implementation technique was for Standard Library
3506   implementors to provide explicit instantiations in separate object
3507   files, so that they would not be picked up by the linker when the
3508   user also provides an explicit instantiation.  However, this
3509   technique only applies for Standard Library implementations that
3510   are packaged as static archives.  Most Standard Library
3511   implementations nowadays are packaged as dynamic libraries, so this
3512   technique would not apply.</p>
3513
3514 <p>The Committee is now considering standardization of dynamic
3515   linking.  If there are such changes in the future, it may be
3516   appropriate to revisit this issue later.</p>
3517 <hr>
3518 <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>
3519 <p>Section 27.5.2 describes the streambuf classes this way: </p>
3520
3521 <blockquote>
3522
3523 <p>The class streambuf is a specialization of the template class basic_streambuf
3524 specialized for the type char. </p>
3525
3526 <p>The class wstreambuf is a specialization of the template class basic_streambuf
3527 specialized for the type wchar_t. </p>
3528
3529 </blockquote>
3530
3531 <p>This implies that these classes must be template specializations, not typedefs. </p>
3532
3533 <p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
3534 <p><b>Proposed resolution:</b></p>
3535 <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
3536 sentences). </p>
3537 <p><b>Rationale:</b></p>
3538 <p>The <tt>streambuf</tt>  synopsis already has a declaration for the
3539 typedefs and that is sufficient. </p>
3540 <hr>
3541 <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>
3542 <p>One of the operator= in the valarray helper arrays is const and one
3543 is not. For example, look at slice_array. This operator= in Section
3544 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>
3545
3546 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const valarray&lt;T&gt;&amp;) const;</tt> </p>
3547
3548 <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>
3549
3550 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const T&amp;); </tt></p>
3551
3552 <p>The description of the semantics for these two functions is similar. </p>
3553 <p><b>Proposed resolution:</b></p>
3554
3555 <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>
3556 <blockquote>
3557
3558    <p>In the class template definition for slice_array, replace the member
3559    function declaration</p>
3560     <pre>      void operator=(const T&amp;);
3561     </pre>
3562    <p>with</p>
3563     <pre>      void operator=(const T&amp;) const;
3564     </pre>
3565 </blockquote>
3566
3567 <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>
3568 <blockquote>
3569
3570    <p>Change the function declaration</p>
3571     <pre>      void operator=(const T&amp;);
3572     </pre>
3573    <p>to</p>
3574     <pre>      void operator=(const T&amp;) const;
3575     </pre>
3576 </blockquote>
3577
3578 <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>
3579 <blockquote>
3580
3581    <p>In the class template definition for gslice_array, replace the member
3582    function declaration</p>
3583     <pre>      void operator=(const T&amp;);
3584     </pre>
3585    <p>with</p>
3586     <pre>      void operator=(const T&amp;) const;
3587     </pre>
3588 </blockquote>
3589
3590 <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>
3591 <blockquote>
3592
3593    <p>Change the function declaration</p>
3594     <pre>      void operator=(const T&amp;);
3595     </pre>
3596    <p>to</p>
3597     <pre>      void operator=(const T&amp;) const;
3598     </pre>
3599 </blockquote>
3600
3601 <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>
3602 <blockquote>
3603
3604    <p>In the class template definition for mask_array, replace the member
3605    function declaration</p>
3606     <pre>      void operator=(const T&amp;);
3607     </pre>
3608    <p>with</p>
3609     <pre>      void operator=(const T&amp;) const;
3610     </pre>
3611 </blockquote>
3612
3613 <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>
3614 <blockquote>
3615
3616    <p>Change the function declaration</p>
3617     <pre>      void operator=(const T&amp;);
3618     </pre>
3619    <p>to</p>
3620     <pre>      void operator=(const T&amp;) const;
3621     </pre>
3622 </blockquote>
3623
3624 <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>
3625 <blockquote>
3626
3627    <p>In the class template definition for indirect_array, replace the member
3628    function declaration</p>
3629     <pre>      void operator=(const T&amp;);
3630     </pre>
3631    <p>with</p>
3632     <pre>      void operator=(const T&amp;) const;
3633     </pre>
3634 </blockquote>
3635
3636 <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>
3637 <blockquote>
3638
3639    <p>Change the function declaration</p>
3640     <pre>      void operator=(const T&amp;);
3641     </pre>
3642    <p>to</p>
3643     <pre>      void operator=(const T&amp;) const;
3644     </pre>
3645 </blockquote>
3646
3647
3648 <p><i>[Redmond: Robert provided wording.]</i></p>
3649
3650 <p><b>Rationale:</b></p>
3651 <p>There's no good reason for one version of operator= being const and
3652 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
3653 matters: these functions are now callable in more circumstances.  In
3654 many existing implementations, both versions are already const.</p>
3655 <hr>
3656 <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>
3657 <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>
3658 ctype_byname&lt;charT&gt;::do_scan_is() and do_scan_not() are declared
3659 to return a const char* not a const charT*. </p>
3660 <p><b>Proposed resolution:</b></p>
3661 <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
3662 <tt>do_scan_not()</tt> to return a <tt> const
3663 charT*</tt>. </p>
3664 <hr>
3665 <a name="125"></a><h3><a name="125">125.&nbsp;valarray&lt;T&gt;::operator!() return type is inconsistent</a></h3><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>
3666 <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
3667 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
3668 latter appears to be correct. </p>
3669 <p><b>Proposed resolution:</b></p>
3670 <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
3671 <tt>operator!()</tt> so that the return type is
3672 <tt>valarray&lt;bool&gt;</tt>. </p>
3673 <hr>
3674 <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>
3675 <p>Typos in 22.2.1.1.2 need to be fixed.</p>
3676 <p><b>Proposed resolution:</b></p>
3677 <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>
3678
3679 <pre>   do_widen(do_narrow(c),0) == c</pre>
3680
3681 <p>to:</p>
3682
3683 <pre>   do_widen(do_narrow(c,0)) == c</pre>
3684
3685 <p>and change:</p>
3686
3687 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
3688
3689 <p>to:</p>
3690
3691 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
3692 <hr>
3693 <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>
3694 <p>There are two problems with the current <tt>auto_ptr</tt> wording
3695 in the standard: </p>
3696
3697 <p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
3698 because <tt>auto_ptr&lt;Derived&gt;::auto_ptr_ref</tt> is unrelated to
3699 <tt>auto_ptr&lt;Base&gt;::auto_ptr_ref</tt>.  <i>Also submitted by
3700 Nathan Myers, with the same proposed resolution.</i></p>
3701
3702 <p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
3703 <tt>auto_ptr_ref</tt> argument. </p>
3704
3705 <p>I have discussed these problems with my proposal coauthor, Bill
3706 Gibbons, and with some compiler and library implementors, and we
3707 believe that these problems are not desired or desirable implications
3708 of the standard. </p>
3709
3710 <p>25 Aug 1999: The proposed resolution now reflects changes suggested
3711 by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
3712 "assignment operator" to "public assignment
3713 operator", 2) changed effects to specify use of release(), 3)
3714 made the conversion to auto_ptr_ref const. </p>
3715
3716 <p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
3717 states that the conversion from auto_ptr to auto_ptr_ref should
3718 be const.  This is not acceptable, because it would allow
3719 initialization and assignment from _any_ const auto_ptr!  It also
3720 introduces an implementation difficulty in writing this conversion
3721 function -- namely, somewhere along the line, a const_cast will be
3722 necessary to remove that const so that release() may be called.  This
3723 may result in undefined behavior [7.1.5.1/4]. The conversion
3724 operator does not have to be const, because a non-const implicit
3725 object parameter may be bound to an rvalue [13.3.3.1.4/3]
3726 [13.3.1/5]. </p>
3727
3728   <p>Tokyo: The LWG removed the following from the proposed resolution:</p>
3729
3730   <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>,
3731   paragraph 2, make the conversion to auto_ptr_ref const:</p>
3732   <blockquote>
3733     <pre>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() const throw();</pre>
3734   </blockquote>
3735 <p><b>Proposed resolution:</b></p>
3736 <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
3737 the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
3738
3739 <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
3740 a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
3741
3742 <blockquote>
3743   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</pre>
3744 </blockquote>
3745
3746 <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>
3747
3748 <blockquote>
3749   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw()</pre>
3750
3751   <b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
3752   p</tt> that <tt>r</tt> holds a reference to.<br>
3753   <b>Returns: </b><tt>*this</tt>.
3754
3755 </blockquote>
3756 <hr>
3757 <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>
3758 <p>Currently, the standard does not specify how seekg() and seekp()
3759 indicate failure. They are not required to set failbit, and they can't
3760 return an error indication because they must return *this, i.e. the
3761 stream. Hence, it is undefined what happens if they fail. And they
3762 <i>can</i> fail, for instance, when a file stream is disconnected from the
3763 underlying file (is_open()==false) or when a wide character file
3764 stream must perform a state-dependent code conversion, etc. </p>
3765
3766 <p>The stream functions seekg() and seekp() should set failbit in the
3767 stream state in case of failure.</p>
3768 <p><b>Proposed resolution:</b></p>
3769 <p>Add to the Effects: clause of&nbsp; seekg() in
3770 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
3771 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>
3772
3773 <blockquote>
3774   <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
3775   </p>
3776 </blockquote>
3777 <p><b>Rationale:</b></p>
3778 <p>Setting failbit is the usual error reporting mechanism for streams</p>
3779 <hr>
3780 <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>
3781 <p>Table 67 (23.1.1) says that container::erase(iterator) returns an
3782 iterator. Table 69 (23.1.2) says that in addition to this requirement,
3783 associative containers also say that container::erase(iterator)
3784 returns void.  That's not an addition; it's a change to the
3785 requirements, which has the effect of making associative containers
3786 fail to meet the requirements for containers.</p>
3787 <p><b>Proposed resolution:</b></p>
3788
3789 <p>
3790 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
3791 requirements, change the return type of <tt>a.erase(q)</tt> from
3792 <tt>void</tt> to <tt>iterator</tt>.  Change the
3793 assertion/not/pre/post-condition from "erases the element pointed to
3794 by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>.
3795 Returns an iterator pointing to the element immediately following q
3796 prior to the element being erased. If no such element exists, a.end()
3797 is returned."
3798 </p>
3799
3800 <p>
3801 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
3802 requirements, change the return type of <tt>a.erase(q1, q2)</tt>
3803 from <tt>void</tt> to <tt>iterator</tt>.  Change the
3804 assertion/not/pre/post-condition from "erases the elements in the
3805 range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1,
3806 q2)</tt>.  Returns q2."
3807 </p>
3808
3809 <p>
3810 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
3811 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
3812 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
3813 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:
3814 change the signature of the first <tt>erase</tt> overload to
3815 </p>
3816 <pre>   iterator erase(iterator position);
3817 </pre>
3818 <p>and change the signature of the third <tt>erase</tt> overload to</p>
3819 <pre>  iterator erase(iterator first, iterator last);
3820 </pre>
3821
3822
3823 <p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p>
3824
3825 <p><i>[Post-Kona: the LWG agrees the return type should be
3826 <tt>iterator</tt>, not <tt>void</tt>.  (Alex Stepanov agrees too.)
3827 Matt provided wording.]</i></p>
3828
3829 <p><i>[
3830  Sydney: the proposed wording went in the right direction, but it
3831  wasn't good enough. We want to return an iterator from the range form
3832  of erase as well as the single-iterator form. Also, the wording is
3833  slightly different from the wording we have for sequences; there's no
3834  good reason for having a difference.  Matt provided new wording,
3835  which we will review at the next meeting.
3836 ]</i></p>
3837
3838 <hr>
3839 <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>
3840 <p>The description reads:</p>
3841
3842 <p>-1- Effects:</p>
3843
3844 <pre>         if (sz &gt; size())
3845            insert(end(), sz-size(), c);
3846          else if (sz &lt; size())
3847            erase(begin()+sz, end());
3848          else
3849            ;                           //  do nothing</pre>
3850
3851 <p>Obviously list::resize should not be specified in terms of random access iterators.</p>
3852 <p><b>Proposed resolution:</b></p>
3853 <p>Change 23.2.2.2 paragraph 1 to:</p>
3854
3855 <p>Effects:</p>
3856
3857 <pre>         if (sz &gt; size())
3858            insert(end(), sz-size(), c);
3859          else if (sz &lt; size())
3860          {
3861            iterator i = begin();
3862            advance(i, sz);
3863            erase(i, end());
3864          }</pre>
3865
3866 <p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
3867 with David Abrahams. They had a discussion and believe there is
3868 no issue of exception safety with the proposed resolution.]</i></p>
3869 <hr>
3870 <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>
3871 <p>The title says it all.</p>
3872 <p><b>Proposed resolution:</b></p>
3873 <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,
3874 after operator= in the map declaration:</p>
3875
3876 <pre>    allocator_type get_allocator() const;</pre>
3877 <hr>
3878 <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>
3879 <p>The complexity description says: "It does at most 2N calls to the copy constructor
3880 of T and logN reallocations if they are just input iterators ...".</p>
3881
3882 <p>This appears to be overly restrictive, dictating the precise memory/performance
3883 tradeoff for the implementor.</p>
3884 <p><b>Proposed resolution:</b></p>
3885 <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>
3886
3887 <p>-1- Complexity: The constructor template &lt;class
3888 InputIterator&gt; vector(InputIterator first, InputIterator last)
3889 makes only N calls to the copy constructor of T (where N is the
3890 distance between first and last) and no reallocations if iterators
3891 first and last are of forward, bidirectional, or random access
3892 categories. It makes order N calls to the copy constructor of T and
3893 order logN reallocations if they are just input iterators.
3894 </p>
3895 <p><b>Rationale:</b></p>
3896 <p>"at most 2N calls" is correct only if the growth factor
3897 is greater than or equal to 2.
3898 </p>
3899 <hr>
3900 <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>
3901 <p>I may be misunderstanding the intent, but should not seekg set only
3902 the input stream and seekp set only the output stream? The description
3903 seems to say that each should set both input and output streams. If
3904 that's really the intent, I withdraw this proposal.</p>
3905 <p><b>Proposed resolution:</b></p>
3906 <p>In section 27.6.1.3 change:</p>
3907
3908 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
3909 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
3910
3911 <p>To:</p>
3912
3913 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
3914 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::in). </pre>
3915
3916 <p>In section 27.6.1.3 change:</p>
3917
3918 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
3919 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
3920
3921 <p>To:</p>
3922
3923 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
3924 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::in). </pre>
3925
3926 <p>In section 27.6.2.4, paragraph 2 change:</p>
3927
3928 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
3929
3930 <p>To:</p>
3931
3932 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::out). </pre>
3933
3934 <p>In section 27.6.2.4, paragraph 4 change:</p>
3935
3936 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
3937
3938 <p>To:</p>
3939
3940 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::out). </pre>
3941
3942 <p><i>[Dublin: Dietmar Kühl thinks this is probably correct, but would
3943 like the opinion of more iostream experts before taking action.]</i></p>
3944
3945 <p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
3946 incorrect, his implementation already implements the Proposed
3947 Resolution.]</i></p>
3948
3949 <p><i>[Post-Tokyo: Matt Austern comments:<br>
3950 Is it a problem with basic_istream and basic_ostream, or is it a problem
3951 with basic_stringbuf?
3952 We could resolve the issue either by changing basic_istream and
3953 basic_ostream, or by changing basic_stringbuf. I prefer the latter
3954 change (or maybe both changes): I don't see any reason for the standard to
3955 require that std::stringbuf s(std::string("foo"), std::ios_base::in);
3956 s.pubseekoff(0, std::ios_base::beg); must fail.<br>
3957 This requirement is a bit weird. There's no similar requirement
3958 for basic_streambuf&lt;&gt;::seekpos, or for basic_filebuf&lt;&gt;::seekoff or
3959 basic_filebuf&lt;&gt;::seekpos.]</i></p>
3960 <hr>
3961 <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>
3962 <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>
3963
3964 <p>-4- In the call to use_facet&lt;Facet&gt;(loc), the type argument
3965 chooses a facet, making available all members of the named type. If
3966 Facet is not present in a locale (or, failing that, in the global
3967 locale), it throws the standard exception bad_cast. A C++ program can
3968 check if a locale implements a particular facet with the template
3969 function has_facet&lt;Facet&gt;(). </p>
3970
3971 <p>This contradicts the specification given in section
3972 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>:
3973 <br><br>
3974 template &lt;class&nbsp; Facet&gt; const&nbsp; Facet&amp; use_facet(const
3975 locale&amp;&nbsp; loc); <br>
3976 <br>
3977 -1- Get a reference to a facet of a locale. <br>
3978 -2- Returns: a reference to the corresponding facet of loc, if present. <br>
3979 -3- Throws: bad_cast if has_facet&lt;Facet&gt;(loc) is false. <br>
3980 -4- Notes: The reference returned remains valid at least as long as any copy of loc exists
3981 </p>
3982 <p><b>Proposed resolution:</b></p>
3983 <p>Remove the phrase "(or, failing that, in the global locale)"
3984 from section 22.1.1. </p>
3985 <p><b>Rationale:</b></p>
3986 <p>Needed for consistency with the way locales are handled elsewhere
3987 in the standard.</p>
3988 <hr>
3989 <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>
3990 <p>The sentence introducing the Optional sequence operation table
3991 (23.1.1 paragraph 12) has two problems:</p>
3992
3993 <p>A. It says ``The operations in table 68 are provided only for the containers for which
3994 they take constant time.''<br>
3995 <br>
3996 That could be interpreted in two ways, one of them being ``Even though table 68 shows
3997 particular operations as being provided, implementations are free to omit them if they
3998 cannot implement them in constant time.''<br>
3999 <br>
4000 B. That paragraph says nothing about amortized constant time, and it should.&nbsp;</p>
4001 <p><b>Proposed resolution:</b></p>
4002 <p>Replace the wording in 23.1.1 paragraph 12&nbsp; which begins ``The operations in table 68 are provided only..."
4003 with:</p>
4004
4005 <blockquote>
4006   <p>Table 68 lists sequence operations that are provided for some types of sequential
4007   containers but not others. An implementation shall provide these operations for all
4008   container types shown in the ``container'' column, and shall implement them so as to take
4009   amortized constant time.</p>
4010 </blockquote>
4011 <hr>
4012 <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>
4013 <p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
4014 say:<br>
4015 <br>
4016 &#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();</tt></p>
4017
4018 <p>Surely the document meant to say ``<tt>xpos &lt; size()</tt>'' in both places.</p>
4019
4020 <p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
4021 proposed resolution.]</i></p>
4022 <p><b>Proposed resolution:</b></p>
4023 <p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
4024 <br>
4025 &#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();<br>
4026 <br>
4027 </tt>to:<br>
4028 <tt><br>
4029 </tt>&#8212; <tt>xpos &lt;= pos</tt> and <tt>xpos &lt; size();</tt></p>
4030 <hr>
4031 <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>
4032 <p>The lexicographical_compare complexity is specified as:<br>
4033 <br>
4034 &nbsp;&nbsp;&nbsp;&nbsp; "At most min((last1 - first1), (last2 - first2))
4035 applications of the corresponding comparison."<br>
4036 <br>
4037 The best I can do is twice that expensive.</p>
4038
4039 <p>Nicolai Josuttis comments in lib-6862: You mean, to check for
4040 equality you have to check both &lt; and &gt;? Yes, IMO you are
4041 right! (and Matt states this complexity in his book)</p>
4042
4043 <p><b>Proposed resolution:</b></p>
4044 <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>
4045     <blockquote>
4046     At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
4047     applications of the corresponding comparison.
4048     </blockquote>
4049
4050 <p>Change the example at the end of paragraph 3 to read:</p>
4051     <blockquote>
4052     [Example:<br>
4053     <br>
4054     &nbsp;&nbsp;&nbsp; for ( ; first1 != last1 &amp;&amp; first2 != last2 ;
4055     ++first1, ++first2) {<br>
4056     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first1 &lt; *first2) return true;<br>
4057     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first2 &lt; *first1) return false;<br>
4058     &nbsp;&nbsp;&nbsp; }<br>
4059     &nbsp;&nbsp;&nbsp; return first1 == last1 &amp;&amp; first2 != last2;<br>
4060     &nbsp;&nbsp;&nbsp;<br>
4061     --end example]
4062     </blockquote>
4063 <hr>
4064 <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>
4065 <p>In 23.2.1.1 paragraph 6, the deque ctor that takes an iterator range appears
4066 to have complexity requirements which are incorrect, and which contradict the
4067 complexity requirements for insert(). I suspect that the text in question,
4068 below, was taken from vector:</p>
4069 <blockquote>
4070   <p>Complexity: If the iterators first and last are forward iterators,
4071   bidirectional iterators, or random access iterators the constructor makes only
4072   N calls to the copy constructor, and performs no reallocations, where N is
4073   last - first.</p>
4074 </blockquote>
4075 <p>The word "reallocations" does not really apply to deque. Further,
4076 all of the following appears to be spurious:</p>
4077 <blockquote>
4078   <p>It makes at most 2N calls to the copy constructor of T and log N
4079   reallocations if they are input iterators.1)</p>
4080   <p>1) The complexity is greater in the case of input iterators because each
4081   element must be added individually: it is impossible to determine the distance
4082   between first abd last before doing the copying.</p>
4083 </blockquote>
4084 <p>This makes perfect sense for vector, but not for deque. Why should deque gain
4085 an efficiency advantage from knowing in advance the number of elements to
4086 insert?</p>
4087 <p><b>Proposed resolution:</b></p>
4088 <p>In 23.2.1.1 paragraph 6, replace the Complexity description, including the
4089 footnote, with the following text (which also corrects the "abd"
4090 typo):</p>
4091 <blockquote>
4092   <p>Complexity: Makes last - first calls to the copy constructor of T.</p>
4093 </blockquote>
4094 <hr>
4095 <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>
4096 <p>The <u> extractor</u> for complex numbers is specified as:&nbsp;</p>
4097
4098 <blockquote>
4099
4100 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4101      basic_istream&lt;charT, traits&gt;&amp;&nbsp;<br>
4102      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;  is, complex&lt;T&gt;&amp;  x);<br>
4103 &nbsp;<br>
4104 Effects: Extracts a complex number x of the form: u, (u), or (u,v),
4105 where u is the real part and v is the imaginary part
4106 (lib.istream.formatted).&nbsp;<br>
4107 Requires: The input values be convertible to T. If bad input is
4108 encountered, calls is.setstate(ios::failbit) (which may throw
4109 ios::failure (lib.iostate.flags).&nbsp;<br>
4110 Returns: is .</p>
4111
4112 </blockquote>
4113 <p>Is it intended that the extractor for complex numbers does not skip
4114 whitespace, unlike all other extractors in the standard library do?
4115 Shouldn't a sentry be used?&nbsp;<br>
4116 <br>
4117 The <u>inserter</u> for complex numbers is specified as:</p>
4118
4119 <blockquote>
4120
4121 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4122      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
4123      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;  o, const complex&lt;T&gt;&amp;  x);<br>
4124 <br>
4125 Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
4126 <br>
4127      template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4128      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
4129      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; o, const complex&lt;T&gt;&amp; x)&nbsp;<br>
4130      {&nbsp;<br>
4131              basic_ostringstream&lt;charT, traits&gt; s;&nbsp;<br>
4132              s.flags(o.flags());&nbsp;<br>
4133              s.imbue(o.getloc());&nbsp;<br>
4134              s.precision(o.precision());&nbsp;<br>
4135              s &lt;&lt; '(' &lt;&lt; x.real() &lt;&lt; "," &lt;&lt; x.imag() &lt;&lt; ')';&nbsp;<br>
4136              return o &lt;&lt; s.str();&nbsp;<br>
4137      }</p>
4138
4139 </blockquote>
4140
4141 <p>Is it intended that the inserter for complex numbers ignores the
4142 field width and does not do any padding? If, with the suggested
4143 implementation above, the field width were set in the stream then the
4144 opening parentheses would be adjusted, but the rest not, because the
4145 field width is reset to zero after each insertion.</p>
4146
4147 <p>I think that both operations should use sentries, for sake of
4148 consistency with the other inserters and extractors in the
4149 library. Regarding the issue of padding in the inserter, I don't know
4150 what the intent was.&nbsp;</p>
4151 <p><b>Proposed resolution:</b></p>
4152 <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
4153 Notes clause:</p>
4154
4155 <blockquote>
4156
4157 <p>Notes: This extraction is performed as a series of simpler
4158 extractions. Therefore, the skipping of whitespace is specified to be the
4159 same for each of the simpler extractions.</p>
4160
4161 </blockquote>
4162 <p><b>Rationale:</b></p>
4163 <p>For extractors, the note is added to make it clear that skipping whitespace
4164 follows an "all-or-none" rule.</p>
4165
4166 <p>For inserters, the LWG believes there is no defect; the standard is correct
4167 as written.</p>
4168 <hr>
4169 <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>
4170 <p>The library had many global functions until 17.4.1.1 [lib.contents]
4171 paragraph 2 was added: </p>
4172
4173 <blockquote>
4174
4175 <p>All library entities except macros, operator new and operator
4176 delete are defined within the namespace std or namespaces nested
4177 within namespace std. </p>
4178
4179 </blockquote>
4180
4181 <p>It appears "global function" was never updated in the following: </p>
4182
4183 <blockquote>
4184
4185 <p>17.4.4.3 - Global functions [lib.global.functions]<br>
4186 <br>
4187 -1- It is unspecified whether any global functions in the C++ Standard
4188 Library are defined as inline (dcl.fct.spec).<br>
4189 <br>
4190 -2- A call to a global function signature described in Clauses
4191 lib.language.support through lib.input.output behaves the same as if
4192 the implementation declares no additional global function
4193 signatures.*<br>
4194 <br>
4195     [Footnote: A valid C++ program always calls the expected library
4196     global function. An implementation may also define additional
4197     global functions that would otherwise not be called by a valid C++
4198     program. --- end footnote]<br>
4199 <br>
4200 -3- A global function cannot be declared by the implementation as
4201 taking additional default arguments.&nbsp;<br>
4202 <br>
4203 17.4.4.4 - Member functions [lib.member.functions]<br>
4204 <br>
4205 -2- An implementation can declare additional non-virtual member
4206 function signatures within a class: </p>
4207
4208   <blockquote>
4209
4210 <p>-- by adding arguments with default values to a member function
4211 signature; The same latitude does not extend to the implementation of
4212 virtual or global functions, however. </p>
4213
4214   </blockquote>
4215 </blockquote>
4216 <p><b>Proposed resolution:</b></p>
4217 <p>     Change "global" to "global or non-member" in:</p>
4218 <blockquote>
4219   <p>17.4.4.3 [lib.global.functions] section title,<br>
4220   17.4.4.3 [lib.global.functions] para 1,<br>
4221   17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2
4222            places in the footnote,<br>
4223   17.4.4.3 [lib.global.functions] para 3,<br>
4224   17.4.4.4 [lib.member.functions] para 2</p>
4225 </blockquote>
4226 <p><b>Rationale:</b></p>
4227 <p>
4228 Because operator new and delete are global, the proposed resolution
4229 was changed from "non-member" to "global or non-member.
4230 </p>
4231 <hr>
4232 <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>
4233 <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
4234 do_falsename() functions in the example facet BoolNames should be
4235 const. The functions they are overriding in
4236 numpunct_byname&lt;char&gt; are const. </p>
4237 <p><b>Proposed resolution:</b></p>
4238 <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
4239 two places:</p>
4240 <blockquote>
4241   <p><tt>string do_truename() const { return "Oui Oui!"; }<br>
4242   string do_falsename() const { return "Mais Non!"; }</tt></p>
4243 </blockquote>
4244 <hr>
4245 <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>
4246 <p><b>Proposed resolution:</b></p>
4247 <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>
4248
4249 <blockquote>
4250 <p>Returns: The first iterator i in the range [first1, last1) such
4251 that for some <u>integer</u> j in the range [first2, last2) ...</p>
4252 </blockquote>
4253
4254 <p>to:</p>
4255
4256 <blockquote>
4257 <p>Returns: The first iterator i in the range [first1, last1) such
4258 that for some iterator j in the range [first2, last2) ...</p>
4259 </blockquote>
4260 <hr>
4261 <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>
4262 <p>For both sequences and associative containers, a.clear() has the
4263 semantics of erase(a.begin(),a.end()), which is undefined for an empty
4264 container since erase(q1,q2) requires that q1 be dereferenceable
4265 (23.1.1,3 and 23.1.2,7).  When the container is empty, a.begin() is
4266 not dereferenceable.<br>
4267 <br>
4268 The requirement that q1 be unconditionally dereferenceable causes many
4269 operations to be intuitively undefined, of which clearing an empty
4270 container is probably the most dire.<br>
4271 <br>
4272 Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
4273 q2) is required to be a valid range, stating that q1 and q2 must be
4274 iterators or certain kinds of iterators is unnecessary.
4275 </p>
4276 <p><b>Proposed resolution:</b></p>
4277 <p>In 23.1.1, paragraph 3, change:</p>
4278 <blockquote>
4279   <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>
4280 </blockquote>
4281 <p>to:</p>
4282 <blockquote>
4283   <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range<u>
4284   in a</u></p>
4285 </blockquote>
4286 <p>In 23.1.2, paragraph 7, change:</p>
4287 <blockquote>
4288   <p>p and q2 are valid iterators to a, q <u> and q1</u> are valid dereferenceable
4289   iterators to a, [q1, q2) is a valid range</p>
4290 </blockquote>
4291 <p>to</p>
4292 <blockquote>
4293   <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
4294   <u>into a</u></p>
4295 </blockquote>
4296 <hr>
4297 <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>
4298 <p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
4299 because there is no function <tt>is()</tt> which only takes a character as
4300 argument. Also, in the effects clause (paragraph 3), the semantic is also kept
4301 vague.</p>
4302 <p><b>Proposed resolution:</b></p>
4303 <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
4304 clause from:</p>
4305 <blockquote>
4306   <p>"... such that <tt>is(*p)</tt>
4307 would..."</p>
4308 </blockquote>
4309 <p>to:&nbsp; "... such that <tt>is(m, *p)</tt>
4310  would...."</p>
4311 <hr>
4312 <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>
4313 <p>The description of the array version of <tt>narrow()</tt> (in
4314 paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
4315 takes only three arguments because in addition to the range a default
4316 character is needed.</p>
4317
4318 <p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
4319 two signatures followed by a <b>Returns</b> clause that only addresses
4320 one of them.</p>
4321
4322 <p><b>Proposed resolution:</b></p>
4323 <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>
4324 paragraph 10 from:</p>
4325 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
4326
4327 <p>to:</p>
4328 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to),
4329 respectively.</p>
4330
4331 <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>
4332 <pre>        char        narrow(char c, char /*dfault*/) const;
4333         const char* narrow(const char* low, const char* high,
4334                            char /*dfault*/, char* to) const;</pre>
4335 <pre>        Returns: do_narrow(low, high, to).</pre>
4336 <p>to:</p>
4337 <pre>        char        narrow(char c, char dfault) const;
4338         const char* narrow(const char* low, const char* high,
4339                            char dfault, char* to) const;</pre>
4340 <pre>        Returns: do_narrow(c, dfault) or
4341                  do_narrow(low, high, dfault, to), respectively.</pre>
4342
4343 <p><i>[Kona: 1) the problem occurs in additional places, 2) a user
4344 defined version could be different.]</i></p>
4345
4346 <p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
4347 the LWG. He could find no other places the problem occurred. He
4348 asks for clarification of the Kona "a user defined
4349 version..." comment above.  Perhaps it was a circuitous way of
4350 saying "dfault" needed to be uncommented?]</i></p>
4351
4352 <p><i>[Post-Toronto: the issues list maintainer has merged in the
4353 proposed resolution from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a>, which addresses the
4354 same paragraphs.]</i></p>
4355 <hr>
4356 <a name="154"><h3>154.&nbsp;Missing <tt>double</tt> specifier for <tt>do_get()</tt>
4357 </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>
4358 <p>The table in paragraph 7 for the length modifier does not list the length
4359 modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
4360 standard asks the implementation to do undefined things when using <tt>scanf()</tt>
4361 (the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
4362 is actually a problem I found quite often in production code, too).</p>
4363 <p><b>Proposed resolution:</b></p>
4364 <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
4365 Modifier table to say that for <tt>double</tt> a length modifier
4366 <tt>l</tt> is to be used.</p>
4367 <p><b>Rationale:</b></p>
4368 <p>The standard makes an embarrassing beginner's mistake.</p>
4369 <hr>
4370 <a name="155"><h3>155.&nbsp;Typo in naming the class defining the class <tt>Init</tt>
4371 </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>
4372 <p>There are conflicting statements about where the class
4373 <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
4374 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>
4375 <p><b>Proposed resolution:</b></p>
4376 <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
4377 "<tt>basic_ios::Init"</tt> to
4378 "<tt>ios_base::Init"</tt>.</p>
4379 <p><b>Rationale:</b></p>
4380 <p>Although not strictly wrong, the standard was misleading enough to warrant
4381 the change.</p>
4382 <hr>
4383 <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>
4384 <p>There is a small discrepancy between the declarations of
4385 <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
4386 <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
4387 is passed as <tt>locale const</tt> (wrong).</p>
4388 <p><b>Proposed resolution:</b></p>
4389 <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
4390 from "<tt>locale const" to "locale
4391 const&amp;".</tt></p>
4392 <hr>
4393 <a name="158"><h3>158.&nbsp;Underspecified semantics for <tt>setbuf()</tt>
4394 </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>
4395 <p>The default behavior of <tt>setbuf()</tt> is described only for the
4396 situation that <tt>gptr() != 0 &amp;&amp; gptr() != egptr()</tt>:
4397 namely to do nothing.  What has to be done in other situations&nbsp;
4398 is not described although there is actually only one reasonable
4399 approach, namely to do nothing, too.</p>
4400
4401 <p>Since changing the buffer would almost certainly mess up most
4402 buffer management of derived classes unless these classes do it
4403 themselves, the default behavior of <tt>setbuf()</tt> should always be
4404 to do nothing.</p>
4405 <p><b>Proposed resolution:</b></p>
4406 <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,
4407 to: "Default behavior: Does nothing. Returns this."</p>
4408 <hr>
4409 <a name="159"><h3>159.&nbsp;Strange use of <tt>underflow()</tt>
4410 </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>
4411 <p>The description of the meaning of the result of
4412 <tt>showmanyc()</tt> seems to be rather strange: It uses calls to
4413 <tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
4414 this function only reads the current character but does not extract
4415 it, <tt>uflow()</tt> would extract the current character. This should
4416 be fixed to use <tt>sbumpc()</tt> instead.</p>
4417 <p><b>Proposed resolution:</b></p>
4418 <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,
4419 <tt>showmanyc()</tt>returns clause, by replacing the word
4420 "supplied" with the words "extracted from the
4421 stream".</p>
4422 <hr>
4423 <a name="160"><h3>160.&nbsp;Typo: Use of non-existing function <tt>exception()</tt>
4424 </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>
4425 <p>The paragraph 4 refers to the function <tt>exception()</tt> which
4426 is not defined. Probably, the referred function is
4427 <tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>
4428 <p><b>Proposed resolution:</b></p>
4429 <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,
4430 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>,
4431 paragraph 1, change "<tt>exception()" to
4432 "exceptions()"</tt>.</p>
4433
4434 <p><i>[Note to Editor: "exceptions" with an "s"
4435 is the correct spelling.]</i></p>
4436 <hr>
4437 <a name="161"><h3>161.&nbsp;Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt>
4438 </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>
4439 <p>The note in the second paragraph pretends that the first argument
4440 is an object of type <tt>istream_iterator</tt>. This is wrong: It is
4441 an object of type <tt>istreambuf_iterator</tt>.</p>
4442 <p><b>Proposed resolution:</b></p>
4443 <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>
4444 <blockquote>
4445   <p>The first argument provides an object of the istream_iterator class...</p>
4446 </blockquote>
4447 <p>to</p>
4448 <blockquote>
4449   <p>The first argument provides an object of the istreambuf_iterator class...</p>
4450 </blockquote>
4451 <hr>
4452 <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>
4453 <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
4454 as taking a fill character as an argument, but the description of the
4455 function does not say whether the character is used at all and, if so,
4456 in which way. The same holds for any format control parameters that
4457 are accessible through the ios_base&amp; argument, such as the
4458 adjustment or the field width. Is strftime() supposed to use the fill
4459 character in any way? In any case, the specification of
4460 time_put.do_put() looks inconsistent to me.<br> <br> Is the
4461 signature of do_put() wrong, or is the effects clause incomplete?</p>
4462 <p><b>Proposed resolution:</b></p>
4463 <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>
4464 paragraph 2:</p>
4465 <blockquote>
4466   <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
4467   for this argument. --end Note]</p>
4468 </blockquote>
4469 <p><b>Rationale:</b></p>
4470 <p>The LWG felt that while the normative text was correct,
4471 users need some guidance on what to pass for the <tt>fill</tt>
4472 argument since the standard doesn't say how it's used.</p>
4473 <hr>
4474 <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>
4475 <p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
4476 functions falling into one of the groups "formatted output functions"
4477 and "unformatted output functions" calls any stream buffer function
4478 which might call a virtual function other than <tt>overflow()</tt>. Basically
4479 this is fine but this implies that <tt>sputn()</tt> (this function would call
4480 the virtual function <tt>xsputn()</tt>) is never called by any of the standard
4481 output functions. Is this really intended? At minimum it would be convenient to
4482 call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
4483 is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
4484 with the definition of <tt>flush()</tt> which calls <tt>rdbuf()-&gt;pubsync()</tt>
4485 and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
4486 under "unformatted output functions").</p>
4487 <p>In addition, I guess that the sentence starting with "They may use other
4488 public members of <tt>basic_ostream</tt> ..." probably was intended to
4489 start with "They may use other public members of <tt>basic_streamuf</tt>..."
4490 although the problem with the virtual members exists in both cases.</p>
4491 <p>I see two obvious resolutions:</p>
4492 <ol>
4493   <li>state in a footnote that this means that <tt>xsputn()</tt> will never be
4494     called by any ostream member and that this is intended.</li>
4495   <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
4496     Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
4497 </ol>
4498 <p><b>Proposed resolution:</b></p>
4499 <p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
4500 <blockquote>
4501   <p>They may use other public members of basic_ostream except that they do not
4502   invoke any virtual members of rdbuf() except overflow().</p>
4503 </blockquote>
4504 <p>to:</p>
4505 <blockquote>
4506   <p>They may use other public members of basic_ostream except that they shall
4507   not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
4508   sync().</p>
4509 </blockquote>
4510
4511 <p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
4512 PJP why the standard is written this way.]</i></p>
4513
4514 <p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
4515 LWG. He comments: The rules can be made a little bit more specific if
4516 necessary be explicitly spelling out what virtuals are allowed to be
4517 called from what functions and eg to state specifically that flush()
4518 is allowed to call sync() while other functions are not.]</i></p>
4519 <hr>
4520 <a name="167"><h3>167.&nbsp;Improper use of <tt>traits_type::length()</tt>
4521 </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>
4522 <p>Paragraph 4 states that the length is determined using
4523 <tt>traits::length(s)</tt>.  Unfortunately, this function is not
4524 defined for example if the character type is <tt>wchar_t</tt> and the
4525 type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
4526 the character type is <tt>char</tt> and the type of <tt>s</tt> is
4527 either <tt>signed char const*</tt> or <tt>unsigned char
4528 const*</tt>.</p>
4529 <p><b>Proposed resolution:</b></p>
4530 <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>
4531 <blockquote>
4532   <p>Effects: Behaves like an formatted inserter (as described in
4533   lib.ostream.formatted.reqmts) of out. After a sentry object is
4534   constructed it inserts characters. The number of characters starting
4535   at s to be inserted is traits::length(s). Padding is determined as
4536   described in lib.facet.num.put.virtuals. The traits::length(s)
4537   characters starting at s are widened using out.widen
4538   (lib.basic.ios.members). The widened characters and any required
4539   padding are inserted into out. Calls width(0).</p>
4540 </blockquote>
4541 <p>to:</p>
4542 <blockquote>
4543   <p>Effects: Behaves like a formatted inserter (as described in
4544   lib.ostream.formatted.reqmts) of out. After a sentry object is
4545   constructed it inserts <i>n</i> characters starting at <i>s</i>,
4546   where <i>n</i> is the number that would be computed as if by:</p>
4547   <ul>
4548   <li>traits::length(s) for the overload where the first argument is of
4549     type basic_ostream&lt;charT, traits&gt;&amp; and the second is
4550     of type const charT*, and also for the overload where the first
4551     argument is of type basic_ostream&lt;char, traits&gt;&amp; and
4552     the second is of type const char*.</li>
4553   <li>std::char_traits&lt;char&gt;::length(s)
4554     for the overload where the first argument is of type
4555     basic_ostream&lt;charT, traits&gt;&amp; and the second is of type
4556     const char*.</li>
4557   <li>traits::length(reinterpret_cast&lt;const char*&gt;(s))
4558     for the other two overloads.</li>
4559   </ul>
4560   <p>Padding is determined as described in
4561   lib.facet.num.put.virtuals. The <i>n</i> characters starting at
4562   <i>s</i> are widened using out.widen (lib.basic.ios.members).  The
4563   widened characters and any required padding are inserted into
4564   out. Calls width(0).</p>
4565 </blockquote>
4566
4567 <p><i>[Santa Cruz: Matt supplied new wording]</i></p>
4568
4569 <p><i>[Kona: changed "where <i>n</i> is" to " where <i>n</i> is the
4570   number that would be computed as if by"]</i></p>
4571
4572 <p><b>Rationale:</b></p>
4573 <p>We have five separate cases.  In two of them we can use the
4574 user-supplied traits class without any fuss.  In the other three we
4575 try to use something as close to that user-supplied class as possible.
4576 In two cases we've got a traits class that's appropriate for
4577 char and what we've got is a const signed char* or a const
4578 unsigned char*; that's close enough so we can just use a reinterpret
4579 cast, and continue to use the user-supplied traits class.  Finally,
4580 there's one case where we just have to give up: where we've got a
4581 traits class for some arbitrary charT type, and we somehow have to
4582 deal with a const char*.  There's nothing better to do but fall back
4583 to char_traits&lt;char&gt;</p>
4584 <hr>
4585 <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>
4586 <p>The first paragraph begins with a descriptions what has to be done
4587 in <i>formatted</i> output functions. Probably this is a typo and the
4588 paragraph really want to describe unformatted output functions...</p>
4589 <p><b>Proposed resolution:</b></p>
4590 <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
4591 sentences, change the word "formatted" to
4592 "unformatted":</p>
4593 <blockquote>
4594   <p>"Each <b>unformatted </b> output function begins ..."<br>
4595   "... value specified for the <b>unformatted </b>  output
4596   function."</p>
4597 </blockquote>
4598 <hr>
4599 <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>
4600 <p>Paragraph 8, Notes, of this section seems to mandate an extremely
4601 inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
4602 especially in view of the restriction that <tt>basic_ostream</tt>
4603 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
4604 is to be created.</p>
4605 <p>Of course, the resolution below requires some handling of
4606 simultaneous input and output since it is no longer possible to update
4607 <tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
4608 solution is to handle this in <tt>underflow()</tt>.</p>
4609 <p><b>Proposed resolution:</b></p>
4610 <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
4611 "at least" as in the following:</p>
4612 <blockquote>
4613   <p>To make a write position available, the function reallocates (or initially
4614   allocates) an array object with a sufficient number of elements to hold the
4615   current array object (if any), plus <b>at least</b> one additional write
4616   position.</p>
4617 </blockquote>
4618 <hr>
4619 <a name="170"><h3>170.&nbsp;Inconsistent definition of <tt>traits_type</tt>
4620 </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>
4621 <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>),
4622 <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
4623 <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
4624 in their definition of the type <tt>traits_type</tt>: For
4625 <tt>istringstream</tt>, this type is defined, for the other two it is
4626 not. This should be consistent.</p>
4627 <p><b>Proposed resolution:</b></p>
4628 <p><b>Proposed resolution:</b></p> <p>To the declarations of
4629 <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
4630 <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>
4631 <blockquote>
4632 <pre>typedef traits traits_type;</pre>
4633 </blockquote>
4634 <hr>
4635 <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>
4636 <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
4637 output position is maintained by <tt>basic_filebuf</tt>. Still, the
4638 description of <tt>seekpos()</tt> seems to talk about different file
4639 positions. In particular, it is unclear (at least to me) what is
4640 supposed to happen to the output buffer (if there is one) if only the
4641 input position is changed. The standard seems to mandate that the
4642 output buffer is kept and processed as if there was no positioning of
4643 the output position (by changing the input position). Of course, this
4644 can be exactly what you want if the flag <tt>ios_base::ate</tt> is
4645 set. However, I think, the standard should say something like
4646 this:</p>
4647 <ul>
4648   <li>If <tt>(which &amp; mode) == 0</tt> neither read nor write position is
4649     changed and the call fails. Otherwise, the joint read and write position is
4650     altered to correspond to <tt>sp</tt>.</li>
4651   <li>If there is an output buffer, the output sequences is updated and any
4652     unshift sequence is written before the position is altered.</li>
4653   <li>If there is an input buffer, the input sequence is updated after the
4654     position is altered.</li>
4655 </ul>
4656 <p>Plus the appropriate error handling, that is...</p>
4657 <p><b>Proposed resolution:</b></p>
4658 <p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
4659 paragraph 14 from:</p>
4660 <blockquote>
4661   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
4662   ios_base::out);</p>
4663   <p>Alters the file position, if possible, to correspond to the position stored
4664   in sp (as described below).</p>
4665   <p>- if (which&amp;ios_base::in)!=0, set the file position to sp, then update
4666   the input sequence</p>
4667   <p>- if (which&amp;ios_base::out)!=0, then update the output sequence, write
4668   any unshift sequence, and set the file position to sp.</p>
4669 </blockquote>
4670 <p>to:</p>
4671 <blockquote>
4672   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
4673   ios_base::out);</p>
4674   <p>Alters the file position, if possible, to correspond to the position stored
4675   in sp (as described below). Altering the file position performs as follows:</p>
4676   <p>1. if (om &amp; ios_base::out)!=0, then update the output sequence and
4677   write any unshift sequence;</p>
4678   <p>2. set the file position to sp;</p>
4679   <p>3. if (om &amp; ios_base::in)!=0, then update the input sequence;</p>
4680   <p>where om is the open mode passed to the last call to open(). The operation
4681   fails if is_open() returns false.</p>
4682 </blockquote>
4683
4684 <p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
4685 <p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
4686 <hr>
4687 <a name="172"><h3>172.&nbsp;Inconsistent types for <tt>basic_istream::ignore()</tt>
4688 </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>
4689 <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
4690 <tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
4691 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>
4692 paragraph 23 the first argument is of type <tt>int.</tt></p>
4693
4694 <p>As far as I can see this is not really a contradiction because
4695 everything is consistent if <tt>streamsize</tt> is typedef to be
4696 <tt>int</tt>. However, this is almost certainly not what was
4697 intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
4698 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>.</p>
4699
4700 <p>Darin Adler also
4701 submitted this issue, commenting: Either 27.6.1.1 should be modified
4702 to show a first parameter of type int, or 27.6.1.3 should be modified
4703 to show a first parameter of type streamsize and use
4704 numeric_limits&lt;streamsize&gt;::max.</p>
4705 <p><b>Proposed resolution:</b></p>
4706 <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
4707 of <tt>int</tt> in the description of <tt>ignore()</tt> to
4708 <tt>streamsize</tt>.</p>
4709 <hr>
4710 <a name="173"><h3>173.&nbsp;Inconsistent types for <tt>basic_filebuf::setbuf()</tt>
4711 </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>
4712
4713 <p>
4714 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
4715 object of type <tt>streamsize</tt> as second argument. However, in
4716 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
4717 <tt>int</tt>.
4718 </p>
4719
4720 <p>
4721 As far as I can see this is not really a contradiction because
4722 everything is consistent if <tt>streamsize</tt> is typedef to be
4723 <tt>int</tt>. However, this is almost certainly not what was
4724 intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
4725 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>.
4726 </p>
4727
4728 <p><b>Proposed resolution:</b></p>
4729 <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
4730 <tt>int</tt> in the description of <tt>setbuf()</tt> to
4731 <tt>streamsize</tt>.</p>
4732 <hr>
4733 <a name="174"><h3>174.&nbsp;Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt>
4734 </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>
4735 <p>According to paragraph 1 of this section, <tt>streampos</tt> is the
4736 type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
4737 paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt></p>
4738 <p><b>Proposed resolution:</b></p>
4739 <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
4740 OFF_T streampos;</tt>" to "<tt>typedef POS_T
4741 streampos;</tt>"</p>
4742 <hr>
4743 <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>
4744 <p>According to paragraph 8 of this section, the methods
4745 <tt>basic_streambuf::pubseekpos()</tt>,
4746 <tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
4747 "may" be overloaded by a version of this function taking the
4748 type <tt>ios_base::open_mode</tt> as last argument argument instead of
4749 <tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
4750 in this section to be an alias for one of the integral types). The
4751 clause specifies, that the last argument has a default argument in
4752 three cases.  However, this generates an ambiguity with the overloaded
4753 version because now the arguments are absolutely identical if the last
4754 argument is not specified.</p>
4755 <p><b>Proposed resolution:</b></p>
4756 <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
4757 <tt>basic_streambuf::pubseekpos()</tt>,
4758 <tt>basic_ifstream::open()</tt>, and
4759 <tt>basic_ofstream::open().</tt></p>
4760 <hr>
4761 <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>
4762 <p>The "overload" for the function <tt>exceptions()</tt> in
4763 paragraph 8 gives the impression that there is another function of
4764 this function defined in class <tt>ios_base</tt>. However, this is not
4765 the case. Thus, it is hard to tell how the semantics (paragraph 9) can
4766 be implemented: "Call the corresponding member function specified
4767 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>
4768 <p><b>Proposed resolution:</b></p>
4769 <p>In D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, move the declaration of the
4770 function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
4771 <hr>
4772 <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>
4773 <p>Currently the following will not compile on two well-known standard
4774 library implementations:</p>
4775
4776 <blockquote>
4777   <pre>#include &lt;set&gt;
4778 using namespace std;
4779
4780 void f(const set&lt;int&gt; &amp;s)
4781 {
4782   set&lt;int&gt;::iterator i;
4783   if (i==s.end()); // s.end() returns a const_iterator
4784 }</pre>
4785 </blockquote>
4786
4787 <p>
4788 The reason this doesn't compile is because operator== was implemented
4789 as a member function of the nested classes set:iterator and
4790 set::const_iterator, and there is no conversion from const_iterator to
4791 iterator. Surprisingly, (s.end() == i) does work, though, because of
4792 the conversion from iterator to const_iterator.
4793 </p>
4794
4795 <p>
4796 I don't see a requirement anywhere in the standard that this must
4797 work. Should there be one?  If so, I think the requirement would need
4798 to be added to the tables in section 24.1.1. I'm not sure about the
4799 wording.  If this requirement existed in the standard, I would think
4800 that implementors would have to make the comparison operators
4801 non-member functions.</p>
4802
4803 <p>This issues was also raised on comp.std.c++ by Darin
4804 Adler.&nbsp; The example given was:</p>
4805
4806 <blockquote>
4807   <pre>bool check_equal(std::deque&lt;int&gt;::iterator i,
4808 std::deque&lt;int&gt;::const_iterator ci)
4809 {
4810 return i == ci;
4811 }</pre>
4812 </blockquote>
4813
4814 <p>Comment from John Potter:</p>
4815 <blockquote>
4816     <p>
4817     In case nobody has noticed, accepting it will break reverse_iterator.
4818     </p>
4819
4820     <p>
4821     The fix is to make the comparison operators templated on two types.
4822     </p>
4823
4824     <pre>    template &lt;class Iterator1, class Iterator2&gt;
4825     bool operator== (reverse_iterator&lt;Iterator1&gt; const&amp; x,
4826                      reverse_iterator&lt;Iterator2&gt; const&amp; y);
4827     </pre>
4828
4829     <p>
4830     Obviously:  return x.base() == y.base();
4831     </p>
4832
4833     <p>
4834     Currently, no reverse_iterator to const_reverse_iterator compares are
4835     valid.
4836     </p>
4837
4838     <p>
4839     BTW, I think the issue is in support of bad code.  Compares should be
4840     between two iterators of the same type.  All std::algorithms require
4841     the begin and end iterators to be of the same type.
4842     </p>
4843 </blockquote>
4844 <p><b>Proposed resolution:</b></p>
4845 <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>
4846 <blockquote>
4847   <p>In the expressions</p>
4848   <pre>    i == j
4849     i != j
4850     i &lt; j
4851     i &lt;= j
4852     i &gt;= j
4853     i &gt; j
4854     i - j
4855   </pre>
4856   <p>Where i and j denote objects of a container's iterator type,
4857   either or both may be replaced by an object of the container's
4858   const_iterator type referring to the same element with no
4859   change in semantics.</p>
4860 </blockquote>
4861
4862 <p><i>[post-Toronto: Judy supplied a proposed resolution saying that
4863 <tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
4864 iterator comparison and difference operations.]</i></p>
4865
4866 <p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
4867 explicitly listed expressions; there was concern that the previous
4868 proposed resolution was too informal.]</i></p>
4869 <p><b>Rationale:</b></p>
4870 <p>
4871 The LWG believes it is clear that the above wording applies only to
4872 the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
4873 where <tt>X</tt> is a container.  There is no requirement that
4874 <tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
4875 can be mixed.  If mixing them is considered important, that's a
4876 separate issue.  (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>.)
4877 </p>
4878 <hr>
4879 <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>
4880 <p>The claim has surfaced in Usenet that expressions such as<br>
4881 <br>
4882 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>make_pair("abc", 3)</tt><br>
4883 <br>
4884 are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
4885 parameter to <tt> const char (&amp;)[4]</tt>, which type is uncopyable.<br>
4886 <br>
4887 I doubt anyone intended that behavior...
4888 </p>
4889 <p><b>Proposed resolution:</b></p>
4890 <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
4891 declaration of make_pair():</p>
4892 <blockquote>
4893   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(const T1&amp;, const T2&amp;);</pre>
4894 </blockquote>
4895 <p>to:</p>
4896 <blockquote>
4897   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(T1, T2);</pre>
4898 </blockquote>
4899 <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>
4900 <blockquote>
4901 <pre>template &lt;class T1, class T2&gt;
4902 pair&lt;T1, T2&gt; make_pair(const T1&amp; x, const T2&amp; y);</pre>
4903 </blockquote>
4904 <p>to:</p>
4905 <blockquote>
4906 <pre>template &lt;class T1, class T2&gt;
4907 pair&lt;T1, T2&gt; make_pair(T1 x, T2 y);</pre>
4908 </blockquote>
4909 <p>and add the following footnote to the effects clause:</p>
4910 <blockquote>
4911   <p> According to 12.8 [class.copy], an implementation is permitted
4912   to not perform a copy of an argument, thus avoiding unnecessary
4913   copies.</p>
4914 </blockquote>
4915 <p><b>Rationale:</b></p>
4916 <p>Two potential fixes were suggested by Matt Austern and Dietmar
4917 Kühl, respectively, 1) overloading with array arguments, and 2) use of
4918 a reference_traits class with a specialization for arrays.  Andy
4919 Koenig suggested changing to pass by value. In discussion, it appeared
4920 that this was a much smaller change to the standard that the other two
4921 suggestions, and any efficiency concerns were more than offset by the
4922 advantages of the solution. Two implementors reported that the
4923 proposed resolution passed their test suites.</p>
4924 <hr>
4925 <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>
4926 <p>Many references to <tt> size_t</tt> throughout the document
4927 omit the <tt> std::</tt> namespace qualification.</p> <p>For
4928 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>
4929 <blockquote>
4930 <pre>&#8212; operator new(size_t)
4931 &#8212; operator new(size_t, const std::nothrow_t&amp;)
4932 &#8212; operator new[](size_t)
4933 &#8212; operator new[](size_t, const std::nothrow_t&amp;)</pre>
4934 </blockquote>
4935 <p><b>Proposed resolution:</b></p>
4936 <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>
4937 <blockquote>
4938 <p><tt>     - operator new(size_t)<br>
4939      - operator new(size_t, const std::nothrow_t&amp;)<br>
4940      - operator new[](size_t)<br>
4941      - operator new[](size_t, const std::nothrow_t&amp;)</tt></p>
4942 </blockquote>
4943 <p>    by:</p>
4944 <blockquote>
4945 <pre>- operator new(std::size_t)
4946 - operator new(std::size_t, const std::nothrow_t&amp;)
4947 - operator new[](std::size_t)
4948 - operator new[](std::size_t, const std::nothrow_t&amp;)</pre>
4949 </blockquote>
4950 <p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
4951 <blockquote>
4952   <p>The typedef members pointer, const_pointer, size_type, and difference_type
4953   are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
4954 </blockquote>
4955 <p>&nbsp;by:</p>
4956 <blockquote>
4957   <p>The typedef members pointer, const_pointer, size_type, and difference_type
4958   are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
4959   respectively.</p>
4960 </blockquote>
4961 <p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
4962 <blockquote>
4963   <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
4964   <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
4965   is unspecified when or how often this function is called. The use of hint is
4966   unspecified, but intended as an aid to locality if an implementation so
4967   desires.</p>
4968 </blockquote>
4969 <p>by:</p>
4970 <blockquote>
4971   <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
4972   <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
4973   it is unspecified when or how often this function is called. The use of hint
4974   is unspecified, but intended as an aid to locality if an implementation so
4975   desires.</p>
4976 </blockquote>
4977 <p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
4978 <blockquote>
4979   <p>In Table 37, X denotes a Traits class defining types and functions for the
4980   character container type CharT; c and d denote values of type CharT; p and q
4981   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
4982   j denote values of type size_t; e and f denote values of type X::int_type; pos
4983   denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
4984 </blockquote>
4985 <p>by:</p>
4986 <blockquote>
4987   <p>In Table 37, X denotes a Traits class defining types and functions for the
4988   character container type CharT; c and d denote values of type CharT; p and q
4989   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
4990   j denote values of type std::size_t; e and f denote values of type X::int_type;
4991   pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
4992 </blockquote>
4993 <p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
4994 X::length(p): "size_t" by "std::size_t".</p>
4995 <p>   In [lib.std.iterator.tags] 24.3.3, paragraph 2:    replace:<br>
4996 &nbsp;&nbsp;&nbsp; typedef ptrdiff_t difference_type;<br>
4997     by:<br>
4998 &nbsp;&nbsp;&nbsp; typedef std::ptrdiff_t difference_type;</p>
4999 <p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the
5000 declaration of template &lt;class charT&gt; class ctype.<br>
5001 <br>
5002    In [lib.iterator.traits] 24.3.1, paragraph 2    put namespace std { ...} around the declaration of:<br>
5003 <br>
5004 &nbsp;&nbsp;&nbsp; template&lt;class Iterator&gt; struct iterator_traits<br>
5005 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;T*&gt;<br>
5006 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;const T*&gt;</p>
5007 <p><b>Rationale:</b></p>
5008 <p>The LWG believes correcting names like <tt>size_t</tt> and
5009 <tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
5010 to be essentially editorial.  There there can't be another size_t or
5011 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>
5012
5013 <blockquote>
5014 For each type T from the Standard C library, the types ::T and std::T
5015 are reserved to the implementation and, when defined, ::T shall be
5016 identical to std::T.
5017 </blockquote>
5018
5019 <p>The issue is treated as a Defect Report to make explicit the Project
5020 Editor's authority to make this change.</p>
5021
5022 <p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
5023 request of the LWG.]</i></p>
5024
5025 <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
5026 address use of the name <tt>size_t</tt> in contexts outside of
5027 namespace std, such as in the description of <tt>::operator new</tt>.
5028 The proposed changes should be reviewed to make sure they are
5029 correct.]</i></p>
5030
5031 <p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
5032 them to be correct.]</i></p>
5033
5034 <hr>
5035 <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>
5036 <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
5037 exposition):</p>
5038 <blockquote>
5039 <p>Returns: An object s of unspecified type such that if [1] out is an (instance
5040 of) basic_ostream then the expression out&lt;&lt;s behaves as if f(s) were
5041 called, and if [2] in is an (instance of) basic_istream then the expression
5042 in&gt;&gt;s behaves as if f(s) were called. Where f can be defined as: ios_base&amp;
5043 f(ios_base&amp; str, ios_base::fmtflags mask) { // reset specified flags
5044 str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
5045 out&lt;&lt;s has type ostream&amp; and value out. [4] The expression in&gt;&gt;s
5046 has type istream&amp; and value in.</p>
5047 </blockquote>
5048 <p>Given the definitions [1] and [2] for out and in, surely [3] should read:
5049 "The expression out &lt;&lt; s has type basic_ostream&amp; ..." and
5050 [4] should read: "The expression in &gt;&gt; s has type basic_istream&amp;
5051 ..."</p>
5052 <p>If the wording in the standard is correct, I can see no way of implementing
5053 any of the manipulators so that they will work with wide character streams.</p>
5054 <p>e.g. wcout &lt;&lt; setbase( 16 );</p>
5055 <p>Must have value 'wcout' (which makes sense) and type 'ostream&amp;' (which
5056 doesn't).</p>
5057 <p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
5058 8. In addition, Para 6 [setfill] has a similar error, but relates only to
5059 ostreams.</p>
5060 <p>I'd be happier if there was a better way of saying this, to make it clear
5061 that the value of the expression is "the same specialization of
5062 basic_ostream as out"&amp;</p>
5063 <p><b>Proposed resolution:</b></p>
5064 <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
5065 following:</p>
5066 <blockquote>
5067 <p>2- The type designated smanip in each of the following function
5068 descriptions is implementation-specified and may be different for each
5069 function.<br>
5070 <br>
5071 <tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
5072 <br>
5073 -3- Returns: An object s of unspecified type such that if out is an
5074 instance of basic_ostream&lt;charT,traits&gt; then the expression
5075 out&lt;&lt;s behaves
5076 as if f(s, mask) were called, or if in is an instance of
5077 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5078 behaves as if
5079 f(s, mask) were called. The function f can be defined as:*<br>
5080 <br>
5081 [Footnote: The expression cin &gt;&gt; resetiosflags(ios_base::skipws)
5082 clears ios_base::skipws in the format flags stored in the
5083 basic_istream&lt;charT,traits&gt; object cin (the same as cin &gt;&gt;
5084 noskipws), and the expression cout &lt;&lt;
5085 resetiosflags(ios_base::showbase) clears
5086 ios_base::showbase in the format flags stored in the
5087 basic_ostream&lt;charT,traits&gt; object cout (the same as cout
5088 &lt;&lt;
5089 noshowbase). --- end footnote]<br>
5090 <br>
5091 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
5092 &nbsp;&nbsp; {<br>
5093 &nbsp;&nbsp; //  reset specified flags<br>
5094 &nbsp;&nbsp; str.setf(ios_base::fmtflags(0), mask);<br>
5095 &nbsp;&nbsp; return str;<br>
5096 &nbsp;&nbsp; }<br>
5097 </tt><br>
5098 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5099 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5100 <br>
5101 &nbsp;<tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
5102 <br>
5103 -4- Returns: An object s of unspecified type such that if out is an
5104 instance of basic_ostream&lt;charT,traits&gt; then the expression
5105 out&lt;&lt;s behaves
5106 as if f(s, mask) were called, or if in is an instance of
5107 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5108 behaves as if f(s,
5109 mask) were called. The function f can be defined as:<br>
5110 <br>
5111 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
5112 &nbsp;&nbsp; {<br>
5113 &nbsp;&nbsp; //  set specified flags<br>
5114 &nbsp;&nbsp; str.setf(mask);<br>
5115 &nbsp;&nbsp; return str;<br>
5116 &nbsp;&nbsp; }<br>
5117 </tt><br>
5118 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5119 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5120 <br>
5121 <tt>smanip setbase(int base);</tt><br>
5122 <br>
5123 -5- Returns: An object s of unspecified type such that if out is an
5124 instance of basic_ostream&lt;charT,traits&gt; then the expression
5125 out&lt;&lt;s behaves
5126 as if f(s, base) were called, or if in is an instance of
5127 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5128 behaves as if f(s,
5129 base) were called. The function f can be defined as:<br>
5130 <br>
5131 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int base)<br>
5132 &nbsp;&nbsp; {<br>
5133 &nbsp;&nbsp; //  set  basefield<br>
5134 &nbsp;&nbsp; str.setf(base ==  8 ? ios_base::oct :<br>
5135 &nbsp;&nbsp; base == 10 ? ios_base::dec :<br>
5136 &nbsp;&nbsp; base == 16 ? ios_base::hex :<br>
5137 &nbsp;&nbsp; ios_base::fmtflags(0), ios_base::basefield);<br>
5138 &nbsp;&nbsp; return str;<br>
5139 &nbsp;&nbsp; }<br>
5140 </tt><br>
5141 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5142 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5143 <br>
5144 <tt>smanip setfill(char_type c);<br>
5145 </tt><br>
5146 -6- Returns: An object s of unspecified type such that if out is (or is
5147 derived from) basic_ostream&lt;charT,traits&gt; and c has type charT
5148 then the
5149 expression out&lt;&lt;s behaves as if f(s, c) were called. The function
5150 f can be
5151 defined as:<br>
5152 <br>
5153 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>template&lt;class charT, class traits&gt;<br>
5154 &nbsp;&nbsp; basic_ios&lt;charT,traits&gt;&amp; f(basic_ios&lt;charT,traits&gt;&amp; str, charT c)<br>
5155 &nbsp;&nbsp; {<br>
5156 &nbsp;&nbsp; //  set fill character<br>
5157 &nbsp;&nbsp; str.fill(c);<br>
5158 &nbsp;&nbsp; return str;<br>
5159 &nbsp;&nbsp; }<br>
5160 </tt><br>
5161 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.<br>
5162 <br>
5163 <tt>smanip setprecision(int n);</tt><br>
5164 <br>
5165 -7- Returns: An object s of unspecified type such that if out is an
5166 instance of basic_ostream&lt;charT,traits&gt; then the expression
5167 out&lt;&lt;s behaves
5168 as if f(s, n) were called, or if in is an instance of
5169 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5170 behaves as if f(s, n)
5171 were called. The function f can be defined as:<br>
5172 <br>
5173 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
5174 &nbsp;&nbsp; {<br>
5175 &nbsp;&nbsp; //  set precision<br>
5176 &nbsp;&nbsp; str.precision(n);<br>
5177 &nbsp;&nbsp; return str;<br>
5178 &nbsp;&nbsp; }<br>
5179 </tt><br>
5180 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5181 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in<br>
5182 .<br>
5183 <tt>smanip setw(int n);<br>
5184 </tt><br>
5185 -8- Returns: An object s of unspecified type such that if out is an
5186 instance of basic_ostream&lt;charT,traits&gt; then the expression
5187 out&lt;&lt;s behaves
5188 as if f(s, n) were called, or if in is an instance of
5189 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5190 behaves as if f(s, n)
5191 were called. The function f can be defined as:<br>
5192 <br>
5193 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
5194 &nbsp;&nbsp; {<br>
5195 &nbsp;&nbsp; //  set width<br>
5196 &nbsp;&nbsp; str.width(n);<br>
5197 &nbsp;&nbsp; return str;<br>
5198 &nbsp;&nbsp; }<br>
5199 </tt><br>
5200 The expression out&lt;&lt;s has type
5201 basic_ostream&lt;charT,traits&gt;&amp; and value out.  The expression
5202 in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value
5203 in.
5204 </p>
5205 </blockquote>
5206
5207 <p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
5208 the proposed resolution.]</i></p>
5209
5210 <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
5211 the same paragraphs.]</i></p>
5212
5213 <p><i>[Post-Tokyo: The issues list maintainer combined the proposed
5214 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
5215 intertwined that dealing with them separately appear fraught with
5216 error.  The full text was supplied by Bill Plauger; it was cross
5217 checked against changes supplied by Andy Sawyer. It should be further
5218 checked by the LWG.]</i></p>
5219 <hr>
5220 <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>
5221 <p>bools are defined by the standard to be of integer types, as per
5222 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"
5223 seems to have a special meaning for the author of 18.2. The net effect
5224 is an unclear and confusing specification for
5225 numeric_limits&lt;bool&gt; as evidenced below.</p>
5226
5227 <p>18.2.1.2/7 says numeric_limits&lt;&gt;::digits is, for built-in integer
5228 types, the number of non-sign bits in the representation.</p>
5229
5230 <p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
5231 arithmetical value converts to true.</p>
5232
5233 <p>I don't think it makes sense at all to require
5234 numeric_limits&lt;bool&gt;::digits and numeric_limits&lt;bool&gt;::digits10 to
5235 be meaningful.</p>
5236
5237 <p>The standard defines what constitutes a signed (resp. unsigned) integer
5238 types. It doesn't categorize bool as being signed or unsigned. And the set of
5239 values of bool type has only two elements.</p>
5240
5241 <p>I don't think it makes sense to require numeric_limits&lt;bool&gt;::is_signed
5242 to be meaningful.</p>
5243
5244 <p>18.2.1.2/18 for numeric_limits&lt;integer_type&gt;::radix&nbsp; says:</p>
5245 <blockquote>
5246   <p>For integer types, specifies the base of the representation.186)</p>
5247 </blockquote>
5248
5249 <p>This disposition is at best misleading and confusing for the standard
5250 requires a "pure binary numeration system" for integer types as per
5251 3.9.1/7</p>
5252
5253 <p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
5254 BCD)."&nbsp; This also erroneous as the standard never defines any integer
5255 types with base representation other than 2.</p>
5256
5257 <p>Furthermore, numeric_limits&lt;bool&gt;::is_modulo and
5258 numeric_limits&lt;bool&gt;::is_signed have similar problems.</p>
5259 <p><b>Proposed resolution:</b></p>
5260 <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>
5261 <blockquote>
5262   <p>The specialization for bool shall be provided as follows:</p>
5263   <pre>    namespace std {
5264        template&lt;&gt; class numeric_limits&lt;bool&gt; {
5265        public:
5266          static const bool is_specialized = true;
5267          static bool min() throw() { return false; }
5268          static bool max() throw() { return true; }
5269
5270          static const int  digits = 1;
5271          static const int  digits10 = 0;
5272          static const bool is_signed = false;
5273          static const bool is_integer = true;
5274          static const bool is_exact = true;
5275          static const int  radix = 2;
5276          static bool epsilon() throw() { return 0; }
5277          static bool round_error() throw() { return 0; }
5278
5279          static const int  min_exponent = 0;
5280          static const int  min_exponent10 = 0;
5281          static const int  max_exponent = 0;
5282          static const int  max_exponent10 = 0;
5283
5284          static const bool has_infinity = false;
5285          static const bool has_quiet_NaN = false;
5286          static const bool has_signaling_NaN = false;
5287          static const float_denorm_style has_denorm = denorm_absent;
5288          static const bool has_denorm_loss = false;
5289          static bool infinity() throw() { return 0; }
5290          static bool quiet_NaN() throw() { return 0; }
5291          static bool signaling_NaN() throw() { return 0; }
5292          static bool denorm_min() throw() { return 0; }
5293
5294          static const bool is_iec559 = false;
5295          static const bool is_bounded = true;
5296          static const bool is_modulo = false;
5297
5298          static const bool traps = false;
5299          static const bool tinyness_before = false;
5300          static const float_round_style round_style = round_toward_zero;
5301        };
5302      }</pre>
5303 </blockquote>
5304
5305 <p><i>[Tokyo:&nbsp; The LWG desires wording that specifies exact values
5306 rather than more general wording in the original proposed
5307 resolution.]</i></p>
5308
5309 <p><i>[Post-Tokyo:&nbsp; At the request of the LWG in Tokyo, Nico
5310 Josuttis provided the above wording.]</i></p>
5311 <hr>
5312 <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>
5313 <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>
5314 <blockquote>
5315   <p>&nbsp;[Example: To negate every element of a: transform(a.begin(), a.end(),
5316   a.begin(), negate&lt;double&gt;()); The corresponding functions will inline
5317   the addition and the negation. end example]</p>
5318 </blockquote>
5319 <p>(Note: The "addition" referred to in the above is in para 3) we can
5320 find no other wording, except this (non-normative) example which suggests that
5321 any "inlining" will take place in this case.</p>
5322 <p>Indeed both:</p>
5323 <blockquote>
5324   <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
5325   unspecified whether any global functions in the C++ Standard Library
5326   are defined as inline (7.1.2).</p>
5327 </blockquote>
5328 <p>and</p>
5329 <blockquote>
5330   <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
5331   unspecified whether any member functions in the C++ Standard Library
5332   are defined as inline (7.1.2).</p>
5333 </blockquote>
5334 <p>take care to state that this may indeed NOT be the case.</p>
5335 <p>Thus the example "mandates" behavior that is explicitly
5336 not required elsewhere.</p>
5337 <p><b>Proposed resolution:</b></p>
5338 <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>
5339 <blockquote>
5340 <p>They are important for the effective use of the library.</p>
5341 </blockquote>
5342 <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>
5343 <blockquote>
5344   <p> Using function objects together with function templates
5345   increases the expressive power of the library as well as making the
5346   resulting code much more efficient.</p>
5347 </blockquote>
5348 <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>
5349 <blockquote>
5350   <p>The corresponding functions will inline the addition and the
5351   negation.</p>
5352 </blockquote>
5353
5354 <p><i>[Kona: The LWG agreed there was a defect.]</i></p>
5355 <p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
5356 <hr>
5357 <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>
5358 <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
5359 bitset::set operation to take a second parameter of type int. The
5360 function tests whether this value is non-zero to determine whether to
5361 set the bit to true or false. The type of this second parameter should
5362 be bool. For one thing, the intent is to specify a Boolean value. For
5363 another, the result type from test() is bool. In addition, it's
5364 possible to slice an integer that's larger than an int. This can't
5365 happen with bool, since conversion to bool has the semantic of
5366 translating 0 to false and any non-zero value to true.</p>
5367 <p><b>Proposed resolution:</b></p>
5368 <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>
5369 <blockquote>
5370 <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = true ); </pre>
5371 </blockquote>
5372 <p>With:</p>
5373 <blockquote>
5374   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
5375 </blockquote>
5376 <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>
5377 <blockquote>
5378   <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = 1 );</pre>
5379 </blockquote>
5380 <p>With:</p>
5381 <blockquote>
5382   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
5383 </blockquote>
5384
5385 <p><i>[Kona: The LWG agrees with the description.&nbsp; Andy Sawyer will work
5386 on better P/R wording.]</i></p>
5387 <p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
5388 <p><b>Rationale:</b></p>
5389 <p><tt>bool</tt> is a better choice.  It is believed that binary
5390 compatibility is not an issue, because this member function is
5391 usually implemented as <tt>inline</tt>, and because it is already
5392 the case that users cannot rely on the type of a pointer to a
5393 nonvirtual member of a standard library class.</p>
5394 <hr>
5395 <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>
5396 <p>The description of iter_swap in 25.2.2 paragraph 7,says that it
5397 ``exchanges the values'' of the objects to which two iterators
5398 refer.<br> <br> What it doesn't say is whether it does so using swap
5399 or using the assignment operator and copy constructor.<br> <br> This
5400 question is an important one to answer, because swap is specialized to
5401 work efficiently for standard containers.<br> For example:</p>
5402 <blockquote>
5403 <pre>vector&lt;int&gt; v1, v2;
5404 iter_swap(&amp;v1, &amp;v2);</pre>
5405 </blockquote>
5406 <p>Is this call to iter_swap equivalent to calling swap(v1, v2)?&nbsp;
5407 Or is it equivalent to</p>
5408 <blockquote>
5409 <pre>{
5410 vector&lt;int&gt; temp = v1;
5411 v1 = v2;
5412 v2 = temp;
5413 }</pre>
5414 </blockquote>
5415 <p>The first alternative is O(1); the second is O(n).</p>
5416 <p>A LWG member, Dave Abrahams, comments:</p>
5417 <blockquote>
5418 <p>Not an objection necessarily, but I want to point out the cost of
5419 that requirement:</p>
5420   <blockquote>
5421 <p><tt>iter_swap(list&lt;T&gt;::iterator, list&lt;T&gt;::iterator)</tt></p>
5422   </blockquote>
5423 <p>can currently be specialized to be more efficient than
5424 iter_swap(T*,T*) for many T (by using splicing). Your proposal would
5425 make that optimization illegal.&nbsp;</p>
5426 </blockquote>
5427
5428 <p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
5429 which are no longer permitted.]</i></p>
5430 <p><b>Proposed resolution:</b></p>
5431 <p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
5432 <blockquote>
5433 <p>Exchanges the values pointed to by the two iterators a and b.</p>
5434 </blockquote>
5435 <p>to</p>
5436 <blockquote>
5437 <p><tt>swap(*a, *b)</tt>.</p>
5438 </blockquote>
5439
5440 <p><b>Rationale:</b></p>
5441 <p>It's useful to say just what <tt>iter_swap</tt> does.  There may be
5442   some iterators for which we want to specialize <tt>iter_swap</tt>,
5443   but the fully general version should have a general specification.</p>
5444
5445 <p>Note that in the specific case of <tt>list&lt;T&gt;::iterator</tt>,
5446 iter_swap should not be specialized as suggested above.  That would do
5447 much more than exchanging the two iterators' values: it would change
5448 predecessor/successor relationships, possibly moving the iterator from
5449 one list to another.  That would surely be inappropriate.</p>
5450 <hr>
5451 <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>
5452 <p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
5453 and includes a parenthetical note saying that it is the number of
5454 digits after the decimal point.<br>
5455 <br>
5456 This claim is not strictly correct.  For example, in the default
5457 floating-point output format, setprecision sets the number of
5458 significant digits printed, not the number of digits after the decimal
5459 point.<br>
5460 <br>
5461 I would like the committee to look at the definition carefully and
5462 correct the statement in 27.4.2.2</p>
5463 <p><b>Proposed resolution:</b></p>
5464 <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
5465 "(number of digits after the decimal point)".</p>
5466 <hr>
5467 <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>
5468 <p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
5469 is<br>
5470 <br>
5471 &nbsp;&nbsp;&nbsp; `"(1) *a is the largest element"<br>
5472 <br>
5473 I think this is incorrect and should be changed to the wording in the proposed
5474 resolution.</p>
5475 <p>Actually there are two independent changes:</p>
5476 <blockquote>
5477   <p>A-"part of largest equivalence class" instead of "largest", cause 25.3
5478   [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
5479   <p>B-Take
5480 'an oldest' from that equivalence class, otherwise the heap functions
5481 could not be used for a priority queue as explained in 23.2.3.2.2
5482 [lib.priqueue.members] (where I assume that a "priority queue" respects
5483 priority AND time).</p>
5484 </blockquote>
5485 <p><b>Proposed resolution:</b></p>
5486 <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>
5487 <blockquote>
5488   <p>(1) *a is the largest element</p>
5489 </blockquote>
5490 <p>to:</p>
5491 <blockquote>
5492   <p>(1) There is no element greater than <tt>*a</tt></p>
5493 </blockquote>
5494 <hr>
5495 <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>
5496 <p>Suppose that <tt>is.flags() &amp; ios_base::skipws</tt> is nonzero.
5497 What should <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor do if it
5498 reaches eof while skipping whitespace?  27.6.1.1.2/5 suggests it
5499 should set failbit. Should it set eofbit as well?  The standard
5500 doesn't seem to answer that question.</p>
5501
5502 <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
5503 <tt>basic_istream&lt;&gt;::sentry</tt> should ever set eofbit.  On the
5504 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
5505 extraction from a <tt>streambuf</tt> "returns
5506 <tt>traits::eof()</tt>, then the input function, except as explicitly
5507 noted otherwise, completes its actions and does
5508 <tt>setstate(eofbit)"</tt>.  So the question comes down to
5509 whether <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor is an
5510 input function.</p>
5511
5512 <p>Comments from Jerry Schwarz:</p>
5513 <blockquote>
5514 <p>It was always my intention that eofbit should be set any time that a
5515 virtual returned something to indicate eof, no matter what reason
5516 iostream code had for calling the virtual.</p>
5517 <p>
5518 The motivation for this is that I did not want to require streambufs
5519 to behave consistently if their virtuals are called after they have
5520 signaled eof.</p>
5521 <p>
5522 The classic case is a streambuf reading from a UNIX file.  EOF isn't
5523 really a state for UNIX file descriptors.  The convention is that a
5524 read on UNIX returns 0 bytes to indicate "EOF", but the file
5525 descriptor isn't shut down in any way and future reads do not
5526 necessarily also return 0 bytes.  In particular, you can read from
5527 tty's on UNIX even after they have signaled "EOF".  (It
5528 isn't always understood that a ^D on UNIX is not an EOF indicator, but
5529 an EOL indicator.  By typing a "line" consisting solely of
5530 ^D you cause a read to return 0 bytes, and by convention this is
5531 interpreted as end of file.)</p>
5532 </blockquote>
5533 <p><b>Proposed resolution:</b></p>
5534 <p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
5535 <blockquote>
5536 <p>If <tt>is.rdbuf()-&gt;sbumpc()</tt> or <tt>is.rdbuf()-&gt;sgetc()</tt>
5537 returns <tt>traits::eof()</tt>, the function calls
5538 <tt>setstate(failbit | eofbit)</tt> (which may throw
5539 <tt>ios_base::failure</tt>).
5540 </p>
5541 </blockquote>
5542 <hr>
5543 <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>
5544 <p>
5545 Is a pointer or reference obtained from an iterator still valid after
5546 destruction of the iterator?
5547 </p>
5548 <p>
5549 Is a pointer or reference obtained from an iterator still valid after the value
5550 of the iterator changes?
5551 </p>
5552 <blockquote>
5553 <pre>#include &lt;iostream&gt;
5554 #include &lt;vector&gt;
5555 #include &lt;iterator&gt;
5556
5557 int main()
5558 {
5559     typedef std::vector&lt;int&gt; vec_t;
5560     vec_t v;
5561     v.push_back( 1 );
5562
5563     // Is a pointer or reference obtained from an iterator still
5564     // valid after destruction of the iterator?
5565     int * p = &amp;*v.begin();
5566     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
5567
5568     // Is a pointer or reference obtained from an iterator still
5569     // valid after the value of the iterator changes?
5570     vec_t::iterator iter( v.begin() );
5571     p = &amp;*iter++;
5572     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
5573
5574     return 0;
5575 }
5576 </pre>
5577 </blockquote>
5578
5579 <p>The standard doesn't appear to directly address these
5580 questions. The standard needs to be clarified. At least two real-world
5581 cases have been reported where library implementors wasted
5582 considerable effort because of the lack of clarity in the
5583 standard. The question is important because requiring pointers and
5584 references to remain valid has the effect for practical purposes of
5585 prohibiting iterators from pointing to cached rather than actual
5586 elements of containers.</p>
5587
5588 <p>The standard itself assumes that pointers and references obtained
5589 from an iterator are still valid after iterator destruction or
5590 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
5591 effects:</p>
5592
5593 <blockquote>
5594   <pre>Iterator tmp = current;
5595 return *--tmp;</pre>
5596 </blockquote>
5597 <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>
5598 <blockquote>
5599   <pre>return &amp;(operator*());</pre>
5600 </blockquote>
5601
5602 <p>Because the standard itself assumes pointers and references remain
5603 valid after iterator destruction or change, the standard should say so
5604 explicitly. This will also reduce the chance of user code breaking
5605 unexpectedly when porting to a different standard library
5606 implementation.</p>
5607 <p><b>Proposed resolution:</b></p>
5608 <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>
5609 <blockquote>
5610 Destruction of an iterator may invalidate pointers and references
5611 previously obtained from that iterator.
5612 </blockquote>
5613
5614 <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>
5615
5616 <blockquote>
5617 <p><b>Effects:</b></p>
5618 <pre>  this-&gt;tmp = current;
5619   --this-&gt;tmp;
5620   return *this-&gt;tmp;
5621 </pre>
5622
5623 <p>
5624 [<i>Note:</i> This operation must use an auxiliary member variable,
5625 rather than a temporary variable, to avoid returning a reference that
5626 persists beyond the lifetime of its associated iterator.  (See
5627 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
5628 exposition only.  <i>--end note</i>]
5629 </p>
5630 </blockquote>
5631
5632 <p><i>[Post-Tokyo: The issue has been reformulated purely
5633 in terms of iterators.]</i></p>
5634
5635 <p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
5636 assumption by reverse_iterator. The issue and proposed resolution was
5637 reformulated yet again to reflect this reality.]</i></p>
5638
5639 <p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
5640 assumes its underlying iterator has persistent pointers and
5641 references.  Andy Koenig pointed out that it is possible to rewrite
5642 reverse_iterator so that it no longer makes such an assupmption.
5643 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
5644 decide it is intentional that <tt>p[n]</tt> may return by value
5645 instead of reference when <tt>p</tt> is a Random Access Iterator,
5646 other changes in reverse_iterator will be necessary.]</i></p>
5647 <p><b>Rationale:</b></p>
5648 <p>This issue has been discussed extensively.  Note that it is
5649 <i>not</i> an issue about the behavior of predefined iterators.  It is
5650 asking whether or not user-defined iterators are permitted to have
5651 transient pointers and references.  Several people presented examples
5652 of useful user-defined iterators that have such a property; examples
5653 include a B-tree iterator, and an "iota iterator" that doesn't point
5654 to memory.  Library implementors already seem to be able to cope with
5655 such iterators: they take pains to avoid forming references to memory
5656 that gets iterated past.  The only place where this is a problem is
5657 <tt>reverse_iterator</tt>, so this issue changes
5658 <tt>reverse_iterator</tt> to make it work.</p>
5659
5660 <p>This resolution does not weaken any guarantees provided by
5661 predefined iterators like <tt>list&lt;int&gt;::iterator</tt>.
5662 Clause 23 should be reviewed to make sure that guarantees for
5663 predefined iterators are as strong as users expect.</p>
5664
5665 <hr>
5666 <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>
5667 <p>
5668 Suppose that <tt>A</tt> is a class that conforms to the
5669 Allocator requirements of Table 32, and <tt>a</tt> is an
5670 object of class <tt>A</tt>  What should be the return
5671 value of <tt>a.allocate(0)</tt>?  Three reasonable
5672 possibilities: forbid the argument <tt>0</tt>, return
5673 a null pointer, or require that the return value be a
5674 unique non-null pointer.
5675 </p>
5676 <p><b>Proposed resolution:</b></p>
5677 <p>
5678 Add a note to the <tt>allocate</tt> row of Table 32:
5679 "[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
5680 <p><b>Rationale:</b></p>
5681 <p>A key to understanding this issue is that the ultimate use of
5682 allocate() is to construct an iterator, and that iterator for zero
5683 length sequences must be the container's past-the-end
5684 representation.  Since this already implies special case code, it
5685 would be over-specification to mandate the return value.
5686 </p>
5687 <hr>
5688 <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>
5689 <p>
5690 In table 74, the return type of the expression <tt>*a</tt> is given
5691 as <tt>T&amp;</tt>, where <tt>T</tt> is the iterator's value type.
5692 For constant iterators, however, this is wrong.  ("Value type"
5693 is never defined very precisely, but it is clear that the value type
5694 of, say, <tt>std::list&lt;int&gt;::const_iterator</tt> is supposed to be
5695 <tt>int</tt>, not <tt>const int</tt>.)
5696 </p>
5697 <p><b>Proposed resolution:</b></p>
5698 <p>
5699 In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
5700 return type from "<tt>T&amp;</tt>" to "<tt>T&amp;</tt>
5701 if <tt>X</tt> is mutable, otherwise <tt>const T&amp;</tt>".
5702 In the <tt>a-&gt;m</tt> row, change the return type from
5703 "<tt>U&amp;</tt>" to "<tt>U&amp;</tt> if <tt>X</tt> is mutable,
5704 otherwise <tt>const U&amp;</tt>".
5705 </p>
5706
5707 <p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
5708 there are multiple const problems with the STL portion of the library
5709 and that these should be addressed as a single package.&nbsp; Note
5710 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
5711 that very reason.]</i></p>
5712
5713 <p><i>[Redmond: the LWG thinks this is separable from other constness
5714 issues.  This issue is just cleanup; it clarifies language that was
5715 written before we had iterator_traits.  Proposed resolution was
5716 modified: the original version only discussed *a.  It was pointed out
5717 that we also need to worry about *r++ and a-&gt;m.]</i></p>
5718
5719 <hr>
5720 <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>
5721 <p>
5722 What should unique() do if you give it a predicate that is not an
5723 equivalence relation?  There are at least two plausible answers:
5724 </p>
5725
5726 <blockquote>
5727
5728 <p>
5729    1. You can't, because 25.2.8 says that it it "eliminates all but
5730    the first element from every consecutive group of equal
5731    elements..." and it wouldn't make sense to interpret "equal" as
5732    meaning anything but an equivalence relation.  [It also doesn't
5733    make sense to interpret "equal" as meaning ==, because then there
5734    would never be any sense in giving a predicate as an argument at
5735    all.]
5736 </p>
5737
5738 <p>
5739    2. The word "equal" should be interpreted to mean whatever the
5740    predicate says, even if it is not an equivalence relation
5741    (and in particular, even if it is not transitive).
5742 </p>
5743
5744 </blockquote>
5745
5746 <p>
5747 The example that raised this question is from Usenet:
5748 </p>
5749
5750 <blockquote>
5751
5752 <pre>int f[] = { 1, 3, 7, 1, 2 };
5753 int* z = unique(f, f+5, greater&lt;int&gt;());</pre>
5754
5755 </blockquote>
5756
5757 <p>
5758 If one blindly applies the definition using the predicate
5759 greater&lt;int&gt;, and ignore the word "equal", you get:
5760 </p>
5761
5762 <blockquote>
5763
5764 <p>
5765     Eliminates all but the first element from every consecutive group
5766     of elements referred to by the iterator i in the range [first, last)
5767     for which *i &gt; *(i - 1).
5768 </p>
5769
5770 </blockquote>
5771
5772 <p>
5773 The first surprise is the order of the comparison.  If we wanted to
5774 allow for the predicate not being an equivalence relation, then we
5775 should surely compare elements the other way: pred(*(i - 1), *i).  If
5776 we do that, then the description would seem to say: "Break the
5777 sequence into subsequences whose elements are in strictly increasing
5778 order, and keep only the first element of each subsequence".  So the
5779 result would be 1, 1, 2.  If we take the description at its word, it
5780 would seem to call for strictly DEcreasing order, in which case the
5781 result should be 1, 3, 7, 2.<br>
5782 <br>
5783 In fact, the SGI implementation of unique() does neither: It yields 1,
5784 3, 7.
5785 </p>
5786 <p><b>Proposed resolution:</b></p>
5787 <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>
5788 <blockquote>
5789 For a nonempty range, eliminates all but the first element from every
5790 consecutive group of equivalent elements referred to by the iterator
5791 <tt>i</tt> in the range [first+1, last) for which the following
5792 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
5793 false</tt>.
5794 </blockquote>
5795
5796 <p>
5797 Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
5798 comparison function must be an equivalence relation."
5799 </p>
5800
5801 <p><i>[Redmond: discussed arguments for and against requiring the
5802 comparison function to be an equivalence relation.  Straw poll:
5803 14-2-5.  First number is to require that it be an equivalence
5804 relation, second number is to explicitly not require that it be an
5805 equivalence relation, third number is people who believe they need
5806 more time to consider the issue.  A separate issue: Andy Sawyer
5807 pointed out that "i-1" is incorrect, since "i" can refer to the first
5808 iterator in the range.  Matt provided wording to address this
5809 problem.]</i></p>
5810
5811 <p><i>[Curaçao: The LWG changed "... the range (first,
5812 last)..." to "...  the range [first+1, last)..." for
5813 clarity. They considered this change close enough to editorial to not
5814 require another round of review.]</i></p>
5815
5816 <p><b>Rationale:</b></p>
5817 <p>The LWG also considered an alternative resolution: change
5818 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>
5819
5820 <blockquote>
5821 For a nonempty range, eliminates all but the first element from every
5822 consecutive group of elements referred to by the iterator
5823 <tt>i</tt> in the range (first, last) for which the following
5824 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
5825 false</tt>.
5826 </blockquote>
5827
5828 <p>
5829 Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
5830 comparison function need not be an equivalence relation."
5831 </p>
5832
5833
5834 <p>Informally: the proposed resolution imposes an explicit requirement
5835 that the comparison function be an equivalence relation.  The
5836 alternative resolution does not, and it gives enough information so
5837 that the behavior of unique() for a non-equivalence relation is
5838 specified.  Both resolutions are consistent with the behavior of
5839 existing implementations.</p>
5840 <hr>
5841 <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>
5842 <p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
5843 past-the-end values are always non-singular."</p>
5844 <p>This places an unnecessary restriction on past-the-end iterators for
5845 containers with forward iterators (for example, a singly-linked list). If the
5846 past-the-end value on such a container was a well-known singular value, it would
5847 still satisfy all forward iterator requirements.</p>
5848 <p>Removing this restriction would allow, for example, a singly-linked list
5849 without a "footer" node.</p>
5850 <p>This would have an impact on existing code that expects past-the-end
5851 iterators obtained from different (generic) containers being not equal.</p>
5852 <p><b>Proposed resolution:</b></p>
5853 <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>
5854 <blockquote>
5855 <p>Dereferenceable and past-the-end values are always non-singular.</p>
5856 </blockquote>
5857 <p>to:</p>
5858 <blockquote>
5859 <p>Dereferenceable values are always non-singular.&nbsp;</p>
5860 </blockquote>
5861 <p><b>Rationale:</b></p>
5862 <p>For some kinds of containers, including singly linked lists and
5863 zero-length vectors, null pointers are perfectly reasonable past-the-end
5864 iterators.  Null pointers are singular.
5865 </p>
5866 <hr>
5867 <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>
5868 <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
5869 declarations use a consistent style except for the following functions:</p>
5870 <blockquote>
5871   <pre>void push_back(const charT);
5872 basic_string&amp; assign(const basic_string&amp;);
5873 void swap(basic_string&lt;charT,traits,Allocator&gt;&amp;);</pre>
5874 </blockquote>
5875 <p>- push_back, assign, swap: missing argument name&nbsp;<br>
5876 - push_back: use of const with charT (i.e. POD type passed by value
5877 not by reference - should be charT or const charT&amp; )<br>
5878 - swap: redundant use of template parameters in argument
5879 basic_string&lt;charT,traits,Allocator&gt;&amp;</p>
5880 <p><b>Proposed resolution:</b></p>
5881 <p>In Section 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> change the basic_string member
5882 function declarations push_back, assign, and swap to:</p>
5883 <blockquote>
5884   <pre>void push_back(charT c);
5885
5886 basic_string&amp; assign(const basic_string&amp; str);
5887 void swap(basic_string&amp; str);</pre>
5888 </blockquote>
5889 <p><b>Rationale:</b></p>
5890 <p>Although the standard is in general not consistent in declaration
5891 style, the basic_string declarations are consistent other than the
5892 above.  The LWG felt that this was sufficient reason to merit the
5893 change.
5894 </p>
5895 <hr>
5896 <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>
5897 <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>
5898 <blockquote>
5899   <p>      In the description of the algorithms operators + and - are used
5900            for some of the iterator categories for which they do not have to
5901            be defined. In these cases the semantics of [...] a-b is the same
5902            as of<br>
5903   <br>
5904   &nbsp;&nbsp;&nbsp;&nbsp; <tt>return distance(a, b);</tt></p>
5905 </blockquote>
5906 <p><b>Proposed resolution:</b></p>
5907 <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
5908 <tt>"a-b"</tt> to <tt>"b-a".</tt></p>
5909 <p><b>Rationale:</b></p>
5910 <p>There are two ways to fix the defect; change the description to b-a
5911 or change the return to distance(b,a).  The LWG preferred the
5912 former for consistency.</p>
5913 <hr>
5914 <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>
5915 <p>The description of the stream extraction operator for std::string (section
5916 21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
5917 the case that the operator fails to extract any characters from the input
5918 stream.</p>
5919 <p>This implies that the typical construction</p>
5920 <blockquote>
5921   <pre>std::istream is;
5922 std::string str;
5923 ...
5924 while (is &gt;&gt; str) ... ;</pre>
5925 </blockquote>
5926 <p>(which tests failbit) is not required to terminate at EOF.</p>
5927 <p>Furthermore, this is inconsistent with other extraction operators,
5928 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
5929 requirement is present, either explicitly or implicitly, for the
5930 extraction operators. It is also present explicitly in the description
5931 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>
5932 <p><b>Proposed resolution:</b></p>
5933 <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>
5934 <blockquote>
5935
5936 <p>If the function extracts no characters, it calls
5937 is.setstate(ios::failbit) which may throw ios_base::failure
5938 (27.4.4.3).</p>
5939 </blockquote>
5940 <hr>
5941 <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>
5942 <p>The standard doesn't specify what min_element() and max_element() shall
5943 return if the range is empty (first equals last). The usual implementations
5944 return last. This problem seems also apply to partition(), stable_partition(),
5945 next_permutation(), and prev_permutation().</p>
5946 <p><b>Proposed resolution:</b></p>
5947 <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
5948 9, append: Returns last if first==last.</p>
5949 <p><b>Rationale:</b></p>
5950 <p>The LWG looked in some detail at all of the above mentioned
5951 algorithms, but believes that except for min_element() and
5952 max_element() it is already clear that last is returned if first ==
5953 last.</p>
5954 <hr>
5955 <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>
5956 <p>The specification for the associative container requirements in
5957 Table 69 state that the find member function should "return
5958 iterator; const_iterator for constant a". The map and multimap
5959 container descriptions have two overloaded versions of find, but set
5960 and multiset do not, all they have is:</p>
5961 <blockquote>
5962   <pre>iterator find(const key_type &amp; x) const;</pre>
5963 </blockquote>
5964 <p><b>Proposed resolution:</b></p>
5965 <p>Change the prototypes for find(), lower_bound(), upper_bound(), and
5966 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>
5967 <blockquote>
5968   <pre>iterator find(const key_type &amp; x);
5969 const_iterator find(const key_type &amp; x) const;</pre>
5970   <pre>iterator lower_bound(const key_type &amp; x);
5971 const_iterator lower_bound(const key_type &amp; x) const;</pre>
5972   <pre>iterator upper_bound(const key_type &amp; x);
5973 const_iterator upper_bound(const key_type &amp; x) const;</pre>
5974   <pre>pair&lt;iterator, iterator&gt; equal_range(const key_type &amp; x);
5975 pair&lt;const_iterator, const_iterator&gt; equal_range(const key_type &amp; x) const;</pre>
5976 </blockquote>
5977
5978 <p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
5979 extending the proposed resolution to lower_bound, upper_bound, and
5980 equal_range.]</i></p>
5981 <hr>
5982 <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>
5983 <p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
5984 <p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
5985 must be const in order for it to be callable on a const object (a reference to
5986 which which is what std::use_facet&lt;&gt;() returns).</p>
5987 <p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
5988 name of the namespace `My'.</p>
5989 <p>3) In the definition of `loc' and subsequently in the call to use_facet&lt;&gt;()
5990 in main(), the name of the facet is misspelled: it should read `My::JCtype'
5991 rather than `My::JCType'.</p>
5992 <p><b>Proposed resolution:</b></p>
5993 <p>Replace the "Classifying Japanese characters" example in 22.2.8,
5994 paragraph 11 with the following:</p>
5995 <pre>#include &lt;locale&gt;</pre>
5996 <pre>namespace My {
5997     using namespace std;
5998     class JCtype : public locale::facet {
5999     public:
6000         static locale::id id;     //  required for use as a new locale facet
6001         bool is_kanji (wchar_t c) const;
6002         JCtype() {}
6003     protected:
6004         ~JCtype() {}
6005     };
6006 }</pre>
6007 <pre>//  file:  filt.C
6008 #include &lt;iostream&gt;
6009 #include &lt;locale&gt;
6010 #include "jctype"                 //  above
6011 std::locale::id My::JCtype::id;   //  the static  JCtype  member
6012 declared above.</pre>
6013 <pre>int main()
6014 {
6015     using namespace std;
6016     typedef ctype&lt;wchar_t&gt; wctype;
6017     locale loc(locale(""),              //  the user's preferred locale...
6018                new My::JCtype);         //  and a new feature ...
6019     wchar_t c = use_facet&lt;wctype&gt;(loc).widen('!');
6020     if (!use_facet&lt;My::JCtype&gt;(loc).is_kanji(c))
6021         cout &lt;&lt; "no it isn't!" &lt;&lt; endl;
6022     return 0;
6023 }</pre>
6024 <hr>
6025 <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>
6026 <p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
6027 paragraph 2:</p>
6028 <blockquote>
6029   <p>Effects: Destroys an object of class ios_base. Calls each registered
6030   callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
6031   time that any ios_base member function called from within fn has well defined
6032   results.</p>
6033 </blockquote>
6034 <p>But what is not clear is: If no callback functions were ever registered, does
6035 it matter whether the ios_base members were ever initialized?</p>
6036 <p>For instance, does this program have defined behavior:</p>
6037 <blockquote>
6038   <pre>#include &lt;ios&gt;</pre>
6039   <pre>class D : public std::ios_base { };</pre>
6040   <pre>int main() { D d; }</pre>
6041 </blockquote>
6042 <p>It seems that registration of a callback function would surely affect the
6043 state of an ios_base. That is, when you register a callback function with an
6044 ios_base, the ios_base must record that fact somehow.</p>
6045 <p>But if after construction the ios_base is in an indeterminate state, and that
6046 state is not made determinate before the destructor is called, then how would
6047 the destructor know if any callbacks had indeed been registered? And if the
6048 number of callbacks that had been registered is indeterminate, then is not the
6049 behavior of the destructor undefined?</p>
6050 <p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
6051 it explicit that destruction before initialization results in undefined
6052 behavior.</p>
6053 <p><b>Proposed resolution:</b></p>
6054 <p>Modify 27.4.2.7 paragraph 1 from</p>
6055 <blockquote>
6056   <p>Effects: Each ios_base member has an indeterminate value after
6057   construction.</p>
6058 </blockquote>
6059 <p>to</p>
6060 <blockquote>
6061   <p>Effects: Each ios_base member has an indeterminate
6062 value after construction. These members must be initialized by calling
6063 basic_ios::init. If an ios_base object is destroyed before these
6064 initializations have taken place, the behavior is undefined.</p>
6065 </blockquote>
6066 <hr>
6067 <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>
6068 <p>Stage 2 processing of numeric conversion is broken.</p>
6069
6070 <p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
6071 conversion specifier is %i. A %i specifier determines a number's base
6072 by its prefix (0 for octal, 0x for hex), so the intention is clearly
6073 that a 0x prefix is allowed.  Paragraph 8 in the same section,
6074 however, describes very precisely how characters are processed. (It
6075 must be done "as if" by a specified code fragment.) That
6076 description does not allow a 0x prefix to be recognized.</p>
6077
6078 <p>Very roughly, stage 2 processing reads a char_type ct. It converts
6079 ct to a char, not by using narrow but by looking it up in a
6080 translation table that was created by widening the string literal
6081 "0123456789abcdefABCDEF+-". The character "x" is
6082 not found in that table, so it can't be recognized by stage 2
6083 processing.</p>
6084 <p><b>Proposed resolution:</b></p>
6085 <p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
6086 <blockquote>
6087   <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
6088 </blockquote>
6089 <p>with the line:</p>
6090 <blockquote>
6091   <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
6092 </blockquote>
6093 <p><b>Rationale:</b></p>
6094 <p>If we're using the technique of widening a string literal, the
6095 string literal must contain every character we wish to recognize.
6096 This technique has the consequence that alternate representations
6097 of digits will not be recognized.  This design decision was made
6098 deliberately, with full knowledge of that limitation.</p>
6099 <hr>
6100 <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>
6101 <p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
6102 <blockquote>
6103   <pre>21.3.6.8 - basic_string::compare [lib.string::compare]
6104
6105 int compare(size_type pos1, size_type n1,
6106                 const basic_string&lt;charT,traits,Allocator&gt;&amp;  str ,
6107                 size_type  pos2 , size_type  n2 ) const;
6108
6109 -4- Returns:
6110
6111     basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
6112                  basic_string&lt;charT,traits,Allocator&gt;(str,pos2,n2)) .</pre>
6113 </blockquote>
6114 <p>and the constructor that's implicitly called by the above is
6115 defined to throw an out-of-range exception if pos &gt; str.size(). See
6116 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>
6117
6118 <p>On the other hand, the compare function descriptions themselves don't have
6119 "Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
6120 that do not apply to a function are omitted.</p>
6121 <p>So it seems there is an inconsistency in the standard -- are the
6122 "Effects" clauses correct, or are the "Throws" clauses
6123 missing?</p>
6124 <p><b>Proposed resolution:</b></p>
6125 <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
6126 the sentence "Descriptions of function semantics contain the
6127 following elements (as appropriate):", insert the word
6128 "further" so that the foot note reads:</p>
6129 <blockquote>
6130   <p>To save space, items that do not apply to a function are
6131   omitted. For example, if a function does not specify any further
6132   preconditions, there will be no "Requires" paragraph.</p>
6133 </blockquote>
6134 <p><b>Rationale:</b></p>
6135 <p>The standard is somewhat inconsistent, but a failure to note a
6136 throw condition in a throws clause does not grant permission not to
6137 throw.  The inconsistent wording is in a footnote, and thus
6138 non-normative. The proposed resolution from the LWG clarifies the
6139 footnote.</p>
6140 <hr>
6141 <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>
6142 <p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
6143 <p><b>Proposed resolution:</b></p>
6144 <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>
6145   <blockquote>
6146   Effects: For each non-negative integer i &lt;= (last - first)/2,
6147   applies swap to all pairs of iterators first + i, (last - i) - 1.
6148   </blockquote>
6149 <p>with:</p>
6150   <blockquote>
6151   Effects: For each non-negative integer i &lt;= (last - first)/2,
6152   applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
6153   </blockquote>
6154 <hr>
6155 <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>
6156 <p>In the associative container requirements table in 23.1.2 paragraph 7,
6157 a.clear() has complexity "log(size()) + N". However, the meaning of N
6158 is not defined.</p>
6159 <p><b>Proposed resolution:</b></p>
6160 <p>In the associative container requirements table in 23.1.2 paragraph
6161 7, the complexity of a.clear(), change "log(size()) + N" to
6162 "linear in <tt>size()</tt>".</p>
6163 <p><b>Rationale:</b></p>
6164 <p>It's the "log(size())", not the "N", that is in
6165 error: there's no difference between <i>O(N)</i> and <i>O(N +
6166 log(N))</i>.  The text in the standard is probably an incorrect
6167 cut-and-paste from the range version of <tt>erase</tt>.</p>
6168 <hr>
6169 <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>
6170 <p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
6171 user namespaces might be found through Koenig lookup?</p>
6172 <p>For example, a popular standard library implementation includes this
6173 implementation of std::unique:</p>
6174 <blockquote>
6175 <pre>namespace std {
6176     template &lt;class _ForwardIter&gt;
6177     _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
6178       __first = adjacent_find(__first, __last);
6179       return unique_copy(__first, __last, __first);
6180     }
6181     }</pre>
6182 </blockquote>
6183 <p>Imagine two users on opposite sides of town, each using unique on his own
6184 sequences bounded by my_iterators . User1 looks at his standard library
6185 implementation and says, "I know how to implement a more efficient
6186 unique_copy for my_iterators", and writes:</p>
6187 <blockquote>
6188 <pre>namespace user1 {
6189     class my_iterator;
6190     // faster version for my_iterator
6191     my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
6192     }</pre>
6193 </blockquote>
6194 <p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
6195 <p>User2 has other needs, and writes:</p>
6196 <blockquote>
6197 <pre>namespace user2 {
6198     class my_iterator;
6199     // Returns true iff *c is a unique copy of *a and *b.
6200     bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
6201     }</pre>
6202 </blockquote>
6203 <p>User2 is shocked to find later that his fully-qualified use of
6204 std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
6205 compile (if he's lucky). Looking in the standard, he sees the following Effects
6206 clause for unique():</p>
6207 <blockquote>
6208   <p>Effects: Eliminates all but the first element from every consecutive group
6209   of equal elements referred to by the iterator i in the range [first, last) for
6210   which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
6211   *(i - 1)) != false</p>
6212 </blockquote>
6213 <p>The standard gives user2 absolutely no reason to think he can interfere with
6214 std::unique by defining names in namespace user2. His standard library has been
6215 built with the template export feature, so he is unable to inspect the
6216 implementation. User1 eventually compiles his code with another compiler, and
6217 his version of unique_copy silently stops being called. Eventually, he realizes
6218 that he was depending on an implementation detail of his library and had no
6219 right to expect his unique_copy() to be called portably.</p>
6220 <p>On the face of it, and given above scenario, it may seem obvious that the
6221 implementation of unique() shown is non-conforming because it uses unique_copy()
6222 rather than ::std::unique_copy(). Most standard library implementations,
6223 however, seem to disagree with this notion.</p>
6224 <p> <i>[Tokyo:&nbsp; Steve Adamczyk from
6225 the core working group indicates that "std::" is sufficient;&nbsp;
6226 leading "::" qualification is not required because any namespace
6227 qualification is sufficient to suppress Koenig lookup.]</i></p>
6228 <p><b>Proposed resolution:</b></p>
6229 <p>Add a paragraph and a note at the end of
6230 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>
6231 <blockquote>
6232
6233 <p>Unless otherwise specified, no global or non-member function in the
6234 standard library shall use a function from another namespace which is
6235 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>
6236
6237 <p>[Note: the phrase "unless otherwise specified" is intended to
6238 allow Koenig lookup in cases like that of ostream_iterators:<br>
6239
6240 <br>
6241   Effects:</p>
6242   <blockquote>
6243 <p>*out_stream &lt;&lt; value;<br>
6244       if(delim != 0) *out_stream &lt;&lt; delim;<br>
6245       return (*this);</p>
6246     <p>--end note]</p>
6247   </blockquote>
6248 </blockquote>
6249
6250 <p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
6251 is as yet unsure if the proposed resolution is the best
6252 solution. Furthermore, the LWG believes that the same problem of
6253 unqualified library names applies to wording in the standard itself,
6254 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
6255 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
6256 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>.]</i></p>
6257
6258 <p><i>[Toronto: The LWG is not sure if this is a defect in the
6259 standard.  Most LWG members believe that an implementation of
6260 <tt>std::unique</tt> like the one quoted in this issue is already
6261 illegal, since, under certain circumstances, its semantics are not
6262 those specified in the standard.  The standard's description of
6263 <tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
6264 should have any effect.]</i></p>
6265
6266 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
6267 225, 226, and 229.  Their conclusion was that the issues should be
6268 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6269 EWG portion (Dave will write a proposal). The LWG and EWG had
6270 (separate) discussions of this plan the next day.  The proposed
6271 resolution for this issue is in accordance with Howard's paper.]</i></p>
6272
6273 <p><b>Rationale:</b></p>
6274 <p>It could be argued that this proposed isn't strictly necessary,
6275   that the Standard doesn't grant implementors license to write a
6276   standard function that behaves differently than specified in the
6277   Standard just because of an unrelated user-defined name in some
6278   other namespace.  However, this is at worst a clarification.  It is
6279   surely right that algorithsm shouldn't pick up random names, that
6280   user-defined names should have no effect unless otherwise specified.
6281   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
6282   appropriate for the standard to explicitly specify otherwise.</p>
6283 <hr>
6284 <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>
6285 <p>The issues are:&nbsp;</p>
6286 <p>1. How can a 3rd party library implementor (lib1) write a version of a standard
6287 algorithm which is specialized to work with his own class template?&nbsp;</p>
6288 <p>2. How can another library implementor (lib2) write a generic algorithm which
6289 will take advantage of the specialized algorithm in lib1?</p>
6290 <p>This appears to be the only viable answer under current language rules:</p>
6291 <blockquote>
6292   <pre>namespace lib1
6293 {
6294     // arbitrary-precision numbers using T as a basic unit
6295     template &lt;class T&gt;
6296     class big_num { //...
6297     };
6298     </pre>
6299   <pre>    // defining this in namespace std is illegal (it would be an
6300     // overload), so we hope users will rely on Koenig lookup
6301     template &lt;class T&gt;
6302     void swap(big_int&lt;T&gt;&amp;, big_int&lt;T&gt;&amp;);
6303 }</pre>
6304   <pre>#include &lt;algorithm&gt;
6305 namespace lib2
6306 {
6307     template &lt;class T&gt;
6308     void generic_sort(T* start, T* end)
6309     {
6310             ...
6311         // using-declaration required so we can work on built-in types
6312         using std::swap;
6313         // use Koenig lookup to find specialized algorithm if available
6314         swap(*x, *y);
6315     }
6316 }</pre>
6317 </blockquote>
6318 <p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
6319 and somewhat slippery. The implementor needs to remember to write the
6320 using-declaration, or generic_sort will fail to compile when T is a built-in
6321 type. The second drawback is that the use of this style in lib2 effectively
6322 "reserves" names in any namespace which defines types which may
6323 eventually be used with lib2. This may seem innocuous at first when applied to
6324 names like swap, but consider more ambiguous names like unique_copy() instead.
6325 It is easy to imagine the user wanting to define these names differently in his
6326 own namespace. A definition with semantics incompatible with the standard
6327 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>
6328 <p>Why, you may ask, can't we just partially specialize std::swap()? It's
6329 because the language doesn't allow for partial specialization of function
6330 templates. If you write:</p>
6331 <blockquote>
6332   <pre>namespace std
6333 {
6334     template &lt;class T&gt;
6335     void swap(lib1::big_int&lt;T&gt;&amp;, lib1::big_int&lt;T&gt;&amp;);
6336 }</pre>
6337 </blockquote>
6338 <p>You have just overloaded std::swap, which is illegal under the current
6339 language rules. On the other hand, the following full specialization is legal:</p>
6340 <blockquote>
6341   <pre>namespace std
6342 {
6343     template &lt;&gt;
6344     void swap(lib1::other_type&amp;, lib1::other_type&amp;);
6345 }</pre>
6346 </blockquote>
6347
6348 <p>This issue reflects concerns raised by the "Namespace issue
6349 with specialized swap" thread on comp.lang.c++.moderated. A
6350 similar set of concerns was earlier raised on the boost.org mailing
6351 list and the ACCU-general mailing list.  Also see library reflector
6352 message c++std-lib-7354.</p>
6353
6354 <p>
6355 J. C. van Winkel points out (in c++std-lib-9565) another unexpected
6356 fact: it's impossible to output a container of std::pair's using copy
6357 and an ostream_iterator, as long as both pair-members are built-in or
6358 std:: types.  That's because a user-defined operator&lt;&lt; for (for
6359 example) std::pair&lt;const std::string, int&gt; will not be found:
6360 lookup for operator&lt;&lt; will be performed only in namespace std.
6361 Opinions differed on whether or not this was a defect, and, if so,
6362 whether the defect is that something is wrong with user-defined
6363 functionality and std, or whether it's that the standard library does
6364 not provide an operator&lt;&lt; for std::pair&lt;&gt;.
6365 </p>
6366
6367 <p><b>Proposed resolution:</b></p>
6368
6369 <p>Adopt the wording proposed in Howard Hinnant's paper
6370   N1523=03-0106, "Proposed Resolution To LWG issues 225, 226, 229".</p>
6371
6372
6373 <p><i>[Tokyo: Summary, "There is no conforming way to extend
6374 std::swap for user defined templates."&nbsp; The LWG agrees that
6375 there is a problem.  Would like more information before
6376 proceeding. This may be a core issue.  Core issue 229 has been opened
6377 to discuss the core aspects of this problem. It was also noted that
6378 submissions regarding this issue have been received from several
6379 sources, but too late to be integrated into the issues list.
6380 ]</i></p>
6381
6382 <p><i>[Post-Tokyo: A paper with several proposed resolutions,
6383 J16/00-0029==WG21/N1252, "Shades of namespace std functions
6384 " by Alan Griffiths, is in the Post-Tokyo mailing. It
6385 should be considered a part of this issue.]</i></p>
6386
6387 <p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
6388 resolution that involves core changes: it would add partial
6389 specialization of function template.  The Core Working Group is
6390 reluctant to add partial specialization of function templates.  It is
6391 viewed as a large change, CWG believes that proposal presented leaves
6392 some syntactic issues unanswered; if the CWG does add partial
6393 specialization of function templates, it wishes to develop its own
6394 proposal.  The LWG continues to believe that there is a serious
6395 problem: there is no good way for users to force the library to use
6396 user specializations of generic standard library functions, and in
6397 certain cases (e.g. transcendental functions called by
6398 <tt>valarray</tt> and <tt>complex</tt>) this is important.  Koenig
6399 lookup isn't adequate, since names within the library must be
6400 qualified with <tt>std</tt> (see issue 225), specialization doesn't
6401 work (we don't have partial specialization of function templates), and
6402 users aren't permitted to add overloads within namespace std.
6403 ]</i></p>
6404
6405 <p><i>[Copenhagen: Discussed at length, with no consensus.  Relevant
6406 papers in the pre-Copenhagen mailing: N1289, N1295, N1296.  Discussion
6407 focused on four options. (1) Relax restrictions on overloads within
6408 namespace std. (2) Mandate that the standard library use unqualified
6409 calls for <tt>swap</tt> and possibly other functions.  (3) Introduce
6410 helper class templates for <tt>swap</tt> and possibly other functions.
6411 (4) Introduce partial specialization of function templates.  Every
6412 option had both support and opposition.  Straw poll (first number is
6413 support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
6414 (4) 4, 4.]</i></p>
6415
6416 <p><i>[Redmond: Discussed, again no consensus.  Herb presented an
6417 argument that a user who is defining a type <tt>T</tt> with an
6418 associated <tt>swap</tt> should not be expected to put that
6419 <tt>swap</tt> in namespace std, either by overloading or by partial
6420 specialization.  The argument is that <tt>swap</tt> is part of
6421 <tt>T</tt>'s interface, and thus should to in the same namespace as
6422 <tt>T</tt> and only in that namespace.  If we accept this argument,
6423 the consequence is that standard library functions should use
6424 unqualified call of <tt>swap</tt>.  (And which other functions? Any?)
6425 A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
6426 try to put together a proposal before the next meeting.]</i></p>
6427
6428 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
6429 225, 226, and 229.  Their conclusion was that the issues should be
6430 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6431 EWG portion (Dave will write a proposal). The LWG and EWG had
6432 (separate) discussions of this plan the next day.  The proposed
6433 resolution is the one proposed by Howard.]</i></p>
6434
6435 <p><i>[Santa Cruz: the LWG agreed with the general direction of
6436   Howard's paper, N1387.  (Roughly: Koenig lookup is disabled unless
6437   we say otherwise; this issue is about when we do say otherwise.)
6438   However, there were concerns about wording.  Howard will provide new
6439   wording.  Bill and Jeremy will review it.]</i></p>
6440
6441 <p><i>[Kona: Howard proposed the new wording.  The LWG accepted his
6442   proposed resolution.]</i></p>
6443
6444 <p><b>Rationale:</b></p>
6445 <p>Informally: introduce a Swappable concept, and specify that the
6446   value types of the iterators passed to certain standard algorithms
6447   (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
6448   to that concept.  The Swappable concept will make it clear that
6449   these algorithms use unqualified lookup for the calls
6450   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,
6451   state that the valarray transcendentals use unqualified lookup.</p>
6452 <hr>
6453 <a name="227"><h3>227.&nbsp;std::swap() should require CopyConstructible or DefaultConstructible arguments</h3></a><p><b>Section:</b>&nbsp;25.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;09 Apr 2000</p>
6454 <p>25.2.2 reads:</p>
6455 <blockquote>
6456   <p><tt>  template&lt;class T&gt; void swap(T&amp; a, T&amp; b);</tt><br>
6457   <br>
6458   Requires:    Type T is Assignable (_lib.container.requirements_).<br>
6459   Effects:    Exchanges values stored in two locations.</p>
6460 </blockquote>
6461 <p>The only reasonable** generic implementation of swap requires construction of a
6462    new temporary copy of one of its arguments:</p>
6463 <blockquote>
6464 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
6465   {
6466       T tmp(a);
6467       a = b;
6468       b = tmp;
6469   }</pre>
6470 </blockquote>
6471 <p>But a type which is only Assignable cannot be swapped by this implementation.</p>
6472 <p>**Yes, there's also an unreasonable implementation which would require T to be
6473    DefaultConstructible instead of CopyConstructible. I don't think this is worthy
6474    of consideration:</p>
6475 <blockquote>
6476 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
6477 {
6478     T tmp;
6479     tmp = a;
6480     a = b;
6481     b = tmp;
6482 }</pre>
6483 </blockquote>
6484 <p><b>Proposed resolution:</b></p>
6485 <p>Change 25.2.2 paragraph 1 from:</p>
6486 <blockquote>
6487 <p>  Requires: Type T is Assignable (23.1).</p>
6488 </blockquote>
6489 <p>to:</p>
6490 <blockquote>
6491 <p>  Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
6492 </blockquote>
6493 <hr>
6494 <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>
6495 <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>,
6496 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
6497 definitions of the "..._byname" classes by listing a bunch
6498 of virtual functions. At the same time, no semantics of these
6499 functions are defined. Real implementations do not define these
6500 functions because the functional part of the facets is actually
6501 implemented in the corresponding base classes and the constructor of
6502 the "..._byname" version just provides suitable date used by
6503 these implementations. For example, the 'numpunct' methods just return
6504 values from a struct. The base class uses a statically initialized
6505 struct while the derived version reads the contents of this struct
6506 from a table.  However, no virtual function is defined in
6507 'numpunct_byname'.</p>
6508
6509 <p>For most classes this does not impose a problem but specifically
6510 for 'ctype' it does: The specialization for 'ctype_byname&lt;char&gt;'
6511 is required because otherwise the semantics would change due to the
6512 virtual functions defined in the general version for 'ctype_byname':
6513 In 'ctype&lt;char&gt;' the method 'do_is()' is not virtual but it is
6514 made virtual in both 'ctype&lt;cT&gt;' and 'ctype_byname&lt;cT&gt;'.
6515 Thus, a class derived from 'ctype_byname&lt;char&gt;' can tell whether
6516 this class is specialized or not under the current specification:
6517 Without the specialization, 'do_is()' is virtual while with
6518 specialization it is not virtual.</p>
6519 <p><b>Proposed resolution:</b></p>
6520 <p>&nbsp; Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
6521 <pre>     namespace std {
6522        template &lt;class charT&gt;
6523        class ctype_byname : public ctype&lt;charT&gt; {
6524        public:
6525          typedef ctype&lt;charT&gt;::mask mask;
6526          explicit ctype_byname(const char*, size_t refs = 0);
6527        protected:
6528         ~ctype_byname();             //  virtual
6529        };
6530      }</pre>
6531 <p>&nbsp; Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
6532 <pre>    namespace std {
6533       template &lt;class internT, class externT, class stateT&gt;
6534       class codecvt_byname : public codecvt&lt;internT, externT, stateT&gt; {
6535       public:
6536        explicit codecvt_byname(const char*, size_t refs = 0);
6537       protected:
6538       ~codecvt_byname();             //  virtual
6539        };
6540      }
6541 </pre>
6542 <p>&nbsp; Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
6543 <pre>     namespace std {
6544        template &lt;class charT&gt;
6545        class numpunct_byname : public numpunct&lt;charT&gt; {
6546      //  this class is specialized for  char  and  wchar_t.
6547        public:
6548          typedef charT                char_type;
6549          typedef basic_string&lt;charT&gt;  string_type;
6550          explicit numpunct_byname(const char*, size_t refs = 0);
6551        protected:
6552         ~numpunct_byname();          //  virtual
6553        };
6554      }</pre>
6555 <p>&nbsp; Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
6556 <pre>     namespace std {
6557        template &lt;class charT&gt;
6558        class collate_byname : public collate&lt;charT&gt; {
6559        public:
6560          typedef basic_string&lt;charT&gt; string_type;
6561          explicit collate_byname(const char*, size_t refs = 0);
6562        protected:
6563         ~collate_byname();           //  virtual
6564        };
6565      }</pre>
6566 <p>&nbsp; Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
6567 <pre>     namespace std {
6568        template &lt;class charT, class InputIterator = istreambuf_iterator&lt;charT&gt; &gt;
6569        class time_get_byname : public time_get&lt;charT, InputIterator&gt; {
6570        public:
6571          typedef time_base::dateorder dateorder;
6572          typedef InputIterator        iter_type</pre>
6573 <pre>         explicit time_get_byname(const char*, size_t refs = 0);
6574        protected:
6575         ~time_get_byname();          //  virtual
6576        };
6577      }</pre>
6578 <p>&nbsp; Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
6579 <pre>     namespace std {
6580        template &lt;class charT, class OutputIterator = ostreambuf_iterator&lt;charT&gt; &gt;
6581        class time_put_byname : public time_put&lt;charT, OutputIterator&gt;
6582        {
6583        public:
6584          typedef charT          char_type;
6585          typedef OutputIterator iter_type;</pre>
6586 <pre>         explicit time_put_byname(const char*, size_t refs = 0);
6587        protected:
6588         ~time_put_byname();          //  virtual
6589        };
6590      }"</pre>
6591 <p>&nbsp; Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
6592 <pre>     namespace std {
6593        template &lt;class charT, bool Intl = false&gt;
6594        class moneypunct_byname : public moneypunct&lt;charT, Intl&gt; {
6595        public:
6596          typedef money_base::pattern pattern;
6597          typedef basic_string&lt;charT&gt; string_type;</pre>
6598 <pre>         explicit moneypunct_byname(const char*, size_t refs = 0);
6599        protected:
6600         ~moneypunct_byname();        //  virtual
6601        };
6602      }</pre>
6603 <p>&nbsp; Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
6604 <pre>     namespace std {
6605        template &lt;class charT&gt;
6606        class messages_byname : public messages&lt;charT&gt; {
6607        public:
6608          typedef messages_base::catalog catalog;
6609          typedef basic_string&lt;charT&gt;    string_type;</pre>
6610 <pre>         explicit messages_byname(const char*, size_t refs = 0);
6611        protected:
6612         ~messages_byname();          //  virtual
6613        };
6614      }</pre>
6615 <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
6616 this case only those members are defined to be virtual which are
6617 defined to be virtual in 'ctype&lt;cT&gt;'.)</p>
6618
6619 <p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of
6620 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>
6621
6622 <p><i>[Copenhagen: proposed resolution was revised slightly, to remove
6623 three last virtual functions from <tt>messages_byname</tt>.]</i></p>
6624
6625 <hr>
6626 <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>
6627 <p>Throughout the library chapters, the descriptions of library entities refer
6628 to other library entities without necessarily qualifying the names.</p>
6629
6630 <p>For example, section 25.2.2 "Swap" describes the effect of
6631 swap_ranges in terms of the unqualified name "swap". This section
6632 could reasonably be interpreted to mean that the library must be implemented so
6633 as to do a lookup of the unqualified name "swap", allowing users to
6634 override any ::std::swap function when Koenig lookup applies.</p>
6635
6636 <p>Although it would have been best to use explicit qualification with
6637 "::std::" throughout, too many lines in the standard would have to be
6638 adjusted to make that change in a Technical Corrigendum.</p>
6639
6640 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, which addresses qualification of
6641 <tt>size_t</tt>, is a special case of this.
6642 </p>
6643 <p><b>Proposed resolution:</b></p>
6644 <p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p>
6645 <blockquote>
6646   <p>Whenever a name x defined in the standard library is mentioned, the name x
6647   is assumed to be fully qualified as ::std::x, unless explicitly described
6648   otherwise. For example, if the Effects section for library function F is
6649   described as calling library function G, the function ::std::G is meant.</p>
6650 </blockquote>
6651
6652 <p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
6653 the LWG to solve a problem in the standard itself similar to the
6654 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
6655 coordinated with the resolution of this issue.]</i></p>
6656
6657 <p><i>[post-Toronto: Howard is undecided about whether it is
6658 appropriate for all standard library function names referred to in
6659 other standard library functions to be explicitly qualified by
6660 <tt>std</tt>: it is common advice that users should define global
6661 functions that operate on their class in the same namespace as the
6662 class, and this requires argument-dependent lookup if those functions
6663 are intended to be called by library code.  Several LWG members are
6664 concerned that valarray appears to require argument-dependent lookup,
6665 but that the wording may not be clear enough to fall under
6666 "unless explicitly described otherwise".]</i></p>
6667
6668 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
6669 225, 226, and 229.  Their conclusion was that the issues should be
6670 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6671 EWG portion (Dave will write a proposal). The LWG and EWG had
6672 (separate) discussions of this plan the next day.  This paper resolves
6673 issues 225 and 226.  In light of that resolution, the proposed
6674 resolution for the current issue makes sense.]</i></p>
6675
6676 <hr>
6677 <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>
6678 <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
6679 Assignable was specified without also specifying
6680 CopyConstructible. The LWG asked that the standard be searched to
6681 determine if the same defect existed elsewhere.</p>
6682
6683 <p>There are a number of places (see proposed resolution below) where
6684 Assignable is specified without also specifying
6685 CopyConstructible. There are also several cases where both are
6686 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>
6687 <p><b>Proposed resolution:</b></p>
6688 <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:
6689 change "T is Assignable" to "T is CopyConstructible and
6690 Assignable"
6691 </p>
6692
6693 <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
6694 "Key is Assignable" to "Key is
6695 CopyConstructible and Assignable"<br>
6696 </p>
6697
6698 <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:
6699 </p>
6700 <blockquote>
6701 <p> A class or a built-in type X satisfies the requirements of an
6702 output iterator if X is an Assignable type (23.1) and also the
6703 following expressions are valid, as shown in Table 73:
6704 </p>
6705 </blockquote>
6706 <p>to:
6707 </p>
6708 <blockquote>
6709 <p> A class or a built-in type X satisfies the requirements of an
6710 output iterator if X is a CopyConstructible (20.1.3) and Assignable
6711 type (23.1) and also the following expressions are valid, as shown in
6712 Table 73:
6713 </p>
6714 </blockquote>
6715
6716 <p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
6717 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
6718 CopyConstructible is really a requirement and may be
6719 overspecification.]</i></p>
6720
6721 <p><i>[Portions of the resolution for issue 230 have been superceded by
6722 the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.]</i></p>
6723
6724 <p><b>Rationale:</b></p>
6725 <p>The original proposed resolution also included changes to input
6726 iterator, fill, and replace.  The LWG believes that those changes are
6727 not necessary.  The LWG considered some blanket statement, where an
6728 Assignable type was also required to be Copy Constructible, but
6729 decided against this because fill and replace really don't require the
6730 Copy Constructible property.</p>
6731 <hr>
6732 <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>
6733 <p>What is the following program supposed to output?</p>
6734 <pre>#include &lt;iostream&gt;
6735
6736     int
6737     main()
6738     {
6739         std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
6740         std::cout.precision( 0 ) ;
6741         std::cout &lt;&lt; 1.00 &lt;&lt; '\n' ;
6742         return 0 ;
6743     }</pre>
6744 <p>From my C experience, I would expect "1e+00"; this is what
6745 <tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs
6746 "1.000000e+00".</p>
6747
6748 <p>The only indication I can find in the standard is 22.2.2.2.2/11,
6749 where it says "For conversion from a floating-point type, if
6750 (flags &amp; fixed) != 0 or if str.precision() &gt; 0, then
6751 str.precision() is specified in the conversion specification."
6752 This is an obvious error, however, fixed is not a mask for a field,
6753 but a value that a multi-bit field may take -- the results of and'ing
6754 fmtflags with ios::fixed are not defined, at least not if
6755 ios::scientific has been set. G++'s behavior corresponds to what might
6756 happen if you do use (flags &amp; fixed) != 0 with a typical
6757 implementation (floatfield == 3 &lt;&lt; something, fixed == 1
6758 &lt;&lt; something, and scientific == 2 &lt;&lt; something).</p>
6759
6760 <p>Presumably, the intent is either (flags &amp; floatfield) != 0, or
6761 (flags &amp; floatfield) == fixed; the first gives something more or
6762 less like the effect of precision in a printf floating point
6763 conversion. Only more or less, of course. In order to implement printf
6764 formatting correctly, you must know whether the precision was
6765 explicitly set or not. Say by initializing it to -1, instead of 6, and
6766 stating that for floating point conversions, if precision &lt; -1, 6
6767 will be used, for fixed point, if precision &lt; -1, 1 will be used,
6768 etc. Plus, of course, if precision == 0 and flags &amp; floatfield ==
6769 0, 1 should be = used. But it probably isn't necessary to emulate all
6770 of the anomalies of printf:-).</p>
6771 <p><b>Proposed resolution:</b></p>
6772 <p>
6773 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
6774 sentence:
6775 </p>
6776 <blockquote>
6777 For conversion from a floating-point type,
6778 <tt><i>str</i>.precision()</tt> is specified in the conversion
6779 specification.
6780 </blockquote>
6781 <p><b>Rationale:</b></p>
6782 <p>The floatfield determines whether numbers are formatted as if
6783 with %f, %e, or %g.  If the <tt>fixed</tt> bit is set, it's %f,
6784 if <tt>scientific</tt> it's %e, and if both bits are set, or
6785 neither, it's %g.</p>
6786 <p>Turning to the C standard, a precision of 0 is meaningful
6787 for %f and %e.  For %g, precision 0 is taken to be the same as
6788 precision 1.</p>
6789 <p>The proposed resolution has the effect that if neither
6790 <tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
6791 specifying a precision of 0, which will be internally
6792 turned into 1.  There's no need to call it out as a special
6793 case.</p>
6794 <p>The output of the above program will be "1e+00".</p>
6795
6796 <p><i>[Post-Curaçao: Howard provided improved wording covering the case
6797 where precision is 0 and mode is %g.]</i></p>
6798
6799 <hr>
6800 <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>
6801 <p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
6802 specializations of standard templates to those that "depend on a
6803 user-defined name of external linkage."</p>
6804 <p>This term, however, is not adequately defined, making it possible to
6805 construct a specialization that is, I believe, technically legal according to
6806 17.4.3.1/1, but that specializes a standard template for a built-in type such as
6807 'int'.</p>
6808 <p>The following code demonstrates the problem:</p>
6809 <blockquote>
6810   <pre>#include &lt;algorithm&gt;</pre>
6811   <pre>template&lt;class T&gt; struct X
6812 {
6813  typedef T type;
6814 };</pre>
6815   <pre>namespace std
6816 {
6817  template&lt;&gt; void swap(::X&lt;int&gt;::type&amp; i, ::X&lt;int&gt;::type&amp; j);
6818 }</pre>
6819 </blockquote>
6820 <p><b>Proposed resolution:</b></p>
6821 <p>Change "user-defined name" to "user-defined
6822 type".</p>
6823 <p><b>Rationale:</b></p>
6824 <p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
6825 Programming Language</i>.  It disallows the example in the issue,
6826 since the underlying type itself is not user-defined.  The only
6827 possible problem I can see is for non-type templates, but there's no
6828 possible way for a user to come up with a specialization for bitset,
6829 for example, that might not have already been specialized by the
6830 implementor?</p>
6831
6832 <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>
6833
6834 <p><i>[post-Toronto: Judy provided the above proposed resolution and
6835 rationale.]</i></p>
6836 <hr>
6837 <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>
6838 <p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
6839 <tt>destruct()</tt> are described as returns but the functions actually
6840 return <tt>void</tt>.</p>
6841 <p><b>Proposed resolution:</b></p>
6842 <p>Substitute "Returns" by "Effect".</p>
6843 <hr>
6844 <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>
6845 <p>The declaration of <tt>reverse_iterator</tt> lists a default
6846 constructor.  However, no specification is given what this constructor
6847 should do.</p>
6848 <p><b>Proposed resolution:</b></p>
6849   <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
6850   paragraph:</p>
6851       <blockquote>
6852       <p><tt>reverse_iterator()</tt></p>
6853
6854       <p>Default initializes <tt>current</tt>. Iterator operations
6855       applied to the resulting iterator have defined behavior if and
6856       only if the corresponding operations are defined on a default
6857       constructed iterator of type <tt>Iterator</tt>.</p>
6858       </blockquote>
6859   <p><i>[pre-Copenhagen: Dietmar provide wording for proposed
6860   resolution.]</i></p>
6861 <hr>
6862 <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>
6863 <p>The complexity specification in paragraph 6 says that the complexity
6864 is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
6865 defined on iterators this term is in general undefined because it
6866 would have to be <tt>last - first</tt>.</p>
6867 <p><b>Proposed resolution:</b></p>
6868   <p>Change paragraph 6 from</p>
6869      <blockquote>Linear in <i>first - last</i>.</blockquote>
6870   <p>to become</p>
6871      <blockquote>Linear in <i>distance(first, last)</i>.</blockquote>
6872 <hr>
6873 <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>
6874 <p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
6875 'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
6876 that far but consider this code:</p>
6877
6878 <pre>  std::basic_stringbuf&lt;char&gt; sbuf("hello, world", std::ios_base::openmode(0));
6879   std::cout &lt;&lt; "'" &lt;&lt; sbuf.str() &lt;&lt; "'\n";
6880 </pre>
6881
6882 <p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
6883 the output sequence nor the input sequence is initialized and
6884 paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
6885 returns the input or the output sequence. None of them is initialized,
6886 ie. both are empty, in which case the return from <tt>str()</tt> is
6887 defined to be <tt>basic_string&lt;cT&gt;()</tt>.</p>
6888
6889 <p>However, probably only test cases in some testsuites will detect this
6890 "problem"...</p>
6891 <p><b>Proposed resolution:</b></p>
6892 <p>Remove 27.7.1.1 paragraph 4.</p>
6893 <p><b>Rationale:</b></p>
6894 <p>We could fix 27.7.1.1 paragraph 4, but there would be no point.  If
6895 we fixed it, it would say just the same thing as text that's already
6896 in the standard.</p>
6897 <hr>
6898 <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>
6899 <p>The complexity of unique and unique_copy are inconsistent with each
6900 other and inconsistent with the implementations.&nbsp; The standard
6901 specifies:</p>
6902
6903 <p>for unique():</p>
6904
6905 <blockquote>-3- Complexity: If the range (last - first) is not empty, exactly
6906 (last - first) - 1 applications of the corresponding predicate, otherwise
6907 no applications of the predicate.</blockquote>
6908
6909 <p>for unique_copy():</p>
6910
6911 <blockquote>-7- Complexity: Exactly last - first applications of the corresponding
6912 predicate.</blockquote>
6913
6914 <p>
6915 The implementations do it the other way round: unique() applies the
6916 predicate last-first times and unique_copy() applies it last-first-1
6917 times.</p>
6918
6919 <p>As both algorithms use the predicate for pair-wise comparison of
6920 sequence elements I don't see a justification for unique_copy()
6921 applying the predicate last-first times, especially since it is not
6922 specified to which pair in the sequence the predicate is applied
6923 twice.</p>
6924 <p><b>Proposed resolution:</b></p>
6925 <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>
6926
6927 <blockquote>Complexity: For nonempty ranges, exactly last - first - 1
6928 applications of the corresponding predicate.</blockquote>
6929
6930 <hr>
6931 <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>
6932 <p>The complexity section of adjacent_find is defective:</p>
6933
6934 <blockquote>
6935 <pre>template &lt;class ForwardIterator&gt;
6936 ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
6937                               BinaryPredicate pred);
6938 </pre>
6939
6940 <p>-1- Returns: The first iterator i such that both i and i + 1 are in
6941 the range [first, last) for which the following corresponding
6942 conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
6943 last if no such iterator is found.</p>
6944
6945 <p>-2- Complexity: Exactly find(first, last, value) - first applications
6946 of the corresponding predicate.
6947 </p>
6948 </blockquote>
6949
6950 <p>In the Complexity section, it is not defined what "value"
6951 is supposed to mean. My best guess is that "value" means an
6952 object for which one of the conditions pred(*i,value) or
6953 pred(value,*i) is true, where i is the iterator defined in the Returns
6954 section. However, the value type of the input sequence need not be
6955 equality-comparable and for this reason the term find(first, last,
6956 value) - first is meaningless.</p>
6957
6958 <p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
6959 find_if(first, last, bind1st(pred,*i)) - first might come closer to
6960 the intended specification.  Binders can only be applied to function
6961 objects that have the function call operator declared const, which is
6962 not required of predicates because they can have non-const data
6963 members. For this reason, a specification using a binder could only be
6964 an "as-if" specification.</p>
6965 <p><b>Proposed resolution:</b></p>
6966 <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>
6967 <blockquote>
6968 For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
6969 (<i>last</i> - <i>first</i>) - 1)</tt> applications of the
6970 corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
6971 return value.
6972 </blockquote>
6973
6974 <p><i>[Copenhagen: the original resolution specified an upper
6975 bound.  The LWG preferred an exact count.]</i></p>
6976
6977 <hr>
6978 <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>
6979
6980 <p>Some popular implementations of unique_copy() create temporary
6981 copies of values in the input sequence, at least if the input iterator
6982 is a pointer.  Such an implementation is built on the assumption that
6983 the value type is CopyConstructible and Assignable.</p>
6984
6985 <p>It is common practice in the standard that algorithms explicitly
6986 specify any additional requirements that they impose on any of the
6987 types used by the algorithm. An example of an algorithm that creates
6988 temporary copies and correctly specifies the additional requirements
6989 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>
6990
6991 <p>Since the specifications of unique() and unique_copy() do not
6992 require CopyConstructible and Assignable of the InputIterator's value
6993 type the above mentioned implementations are not standard-compliant. I
6994 cannot judge whether this is a defect in the standard or a defect in
6995 the implementations.</p>
6996 <p><b>Proposed resolution:</b></p>
6997 <p>In 25.2.8 change:</p>
6998
6999 <blockquote>
7000 -4- Requires: The ranges [first, last) and [result, result+(last-first))
7001 shall not overlap.
7002 </blockquote>
7003
7004 <p>to:</p>
7005
7006 <blockquote>
7007   <p>-4- Requires: The ranges [first, last) and [result,
7008   result+(last-first)) shall not overlap. The expression *result =
7009   *first must be valid. If neither InputIterator nor OutputIterator
7010   meets the requirements of forward iterator then the value type of
7011   InputIterator must be copy constructible. Otherwise copy
7012   constructible is not required. </p>
7013 </blockquote>
7014
7015 <p><i>[Redmond: the original proposed resolution didn't impose an
7016 explicit requirement that the iterator's value type must be copy
7017 constructible, on the grounds that an input iterator's value type must
7018 always be copy constructible.  Not everyone in the LWG thought that
7019 this requirement was clear from table 72.  It has been suggested that
7020 it might be possible to implement <tt>unique_copy</tt> without
7021 requiring assignability, although current implementations do impose
7022 that requirement.  Howard provided new wording.]</i></p>
7023
7024 <p><i>[
7025 Curaçao: The LWG changed the PR editorially to specify
7026 "neither...nor...meet..." as clearer than
7027 "both...and...do not meet...". Change believed to be so
7028 minor as not to require re-review.
7029 ]</i></p>
7030
7031 <hr>
7032 <a name="242"><h3>242.&nbsp;Side effects of function objects</h3></a><p><b>Section:</b>&nbsp;25.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.transform"> [lib.alg.transform]</a>, 26.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numeric.ops"> [lib.numeric.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
7033 <p>The algorithms transform(), accumulate(), inner_product(),
7034 partial_sum(), and adjacent_difference() require that the function
7035 object supplied to them shall not have any side effects.</p>
7036
7037 <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>
7038 <blockquote>-7- Accessing an object designated by a volatile lvalue (basic.lval),
7039 modifying an object, calling a library I/O function, or calling a function
7040 that does any of those operations are all side effects, which are changes
7041 in the state of the execution environment.</blockquote>
7042
7043 <p>As a consequence, the function call operator of a function object supplied
7044 to any of the algorithms listed above cannot modify data members, cannot
7045 invoke any function that has a side effect, and cannot even create and
7046 modify temporary objects.&nbsp; It is difficult to imagine a function object
7047 that is still useful under these severe limitations. For instance, any
7048 non-trivial transformator supplied to transform() might involve creation
7049 and modification of temporaries, which is prohibited according to the current
7050 wording of the standard.</p>
7051
7052 <p>On the other hand, popular implementations of these algorithms exhibit
7053 uniform and predictable behavior when invoked with a side-effect-producing
7054 function objects. It looks like the strong requirement is not needed for
7055 efficient implementation of these algorithms.</p>
7056
7057 <p>The requirement of&nbsp; side-effect-free function objects could be
7058 replaced by a more relaxed basic requirement (which would hold for all
7059 function objects supplied to any algorithm in the standard library):</p>
7060 <blockquote>A function objects supplied to an algorithm shall not invalidate
7061 any iterator or sequence that is used by the algorithm. Invalidation of
7062 the sequence includes destruction of the sorting order if the algorithm
7063 relies on the sorting order (see section 25.3 - Sorting and related operations
7064 [lib.alg.sorting]).</blockquote>
7065
7066 <p>I can't judge whether it is intended that the function objects supplied
7067 to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
7068 shall not modify sequence elements through dereferenced iterators.</p>
7069
7070 <p>It is debatable whether this issue is a defect or a change request.
7071 Since the consequences for user-supplied function objects are drastic and
7072 limit the usefulness of the algorithms significantly I would consider it
7073 a defect.</p>
7074 <p><b>Proposed resolution:</b></p>
7075
7076 <p><i>Things to notice about these changes:</i></p>
7077
7078 <ol>
7079 <li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
7080      are intentional. we want to prevent side-effects from
7081      invalidating the end iterators.</i>
7082 </li>
7083
7084 <li> <i>That has the unintentional side-effect of prohibiting
7085      modification of the end element as a side-effect. This could
7086      conceivably be significant in some cases.</i>
7087 </li>
7088
7089 <li> <i>The wording also prevents side-effects from modifying elements
7090      of the output sequence. I can't imagine why anyone would want
7091      to do this, but it is arguably a restriction that implementors
7092      don't need to place on users.</i>
7093 </li>
7094
7095 <li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
7096      and simple, but would require more verbiage.</i>
7097 </li>
7098 </ol>
7099
7100 <p>Change 25.2.3/2 from:</p>
7101
7102 <blockquote>
7103    -2- Requires: op and binary_op shall not have any side effects.
7104 </blockquote>
7105
7106 <p>to:</p>
7107
7108 <blockquote>
7109   -2- Requires: in the ranges [first1, last1], [first2, first2 +
7110   (last1 - first1)] and [result, result + (last1- first1)], op and
7111   binary_op shall neither modify elements nor invalidate iterators or
7112   subranges.
7113   [Footnote: The use of fully closed ranges is intentional --end footnote]
7114 </blockquote>
7115
7116
7117 <p>Change 25.2.3/2 from:</p>
7118
7119 <blockquote>
7120    -2- Requires: op and binary_op shall not have any side effects.
7121 </blockquote>
7122
7123 <p>to:</p>
7124
7125 <blockquote>
7126   -2- Requires: op and binary_op shall not invalidate iterators or
7127    subranges, or modify elements in the ranges [first1, last1],
7128    [first2, first2 + (last1 - first1)], and [result, result + (last1
7129    - first1)].
7130   [Footnote: The use of fully closed ranges is intentional --end footnote]
7131 </blockquote>
7132
7133
7134 <p>Change 26.4.1/2 from:</p>
7135
7136 <blockquote>
7137   -2- Requires: T must meet the requirements of CopyConstructible
7138    (lib.copyconstructible) and Assignable (lib.container.requirements)
7139    types. binary_op shall not cause side effects.
7140 </blockquote>
7141
7142 <p>to:</p>
7143
7144 <blockquote>
7145   -2- Requires: T must meet the requirements of CopyConstructible
7146    (lib.copyconstructible) and Assignable
7147    (lib.container.requirements) types. In the range [first, last],
7148    binary_op shall neither modify elements nor invalidate iterators
7149    or subranges.
7150   [Footnote: The use of a fully closed range is intentional --end footnote]
7151 </blockquote>
7152
7153 <p>Change 26.4.2/2 from:</p>
7154
7155 <blockquote>
7156   -2- Requires: T must meet the requirements of CopyConstructible
7157    (lib.copyconstructible) and Assignable (lib.container.requirements)
7158    types. binary_op1 and binary_op2 shall not cause side effects.
7159 </blockquote>
7160
7161 <p>to:</p>
7162
7163 <blockquote>
7164   -2- Requires: T must meet the requirements of CopyConstructible
7165    (lib.copyconstructible) and Assignable (lib.container.requirements)
7166    types. In the ranges [first, last] and [first2, first2 + (last -
7167    first)], binary_op1 and binary_op2 shall neither modify elements
7168    nor invalidate iterators or subranges.
7169   [Footnote: The use of fully closed ranges is intentional --end footnote]
7170 </blockquote>
7171
7172
7173 <p>Change 26.4.3/4 from:</p>
7174
7175 <blockquote>
7176   -4- Requires: binary_op is expected not to have any side effects.
7177 </blockquote>
7178
7179 <p>to:</p>
7180
7181 <blockquote>
7182   -4- Requires: In the ranges [first, last] and [result, result +
7183    (last - first)], binary_op shall neither modify elements nor
7184    invalidate iterators or subranges.
7185   [Footnote: The use of fully closed ranges is intentional --end footnote]
7186 </blockquote>
7187
7188 <p>Change 26.4.4/2 from:</p>
7189
7190 <blockquote>
7191   -2- Requires: binary_op shall not have any side effects.
7192 </blockquote>
7193
7194 <p>to:</p>
7195
7196 <blockquote>
7197   -2- Requires: In the ranges [first, last] and [result, result +
7198    (last - first)], binary_op shall neither modify elements nor
7199    invalidate iterators or subranges.
7200   [Footnote: The use of fully closed ranges is intentional --end footnote]
7201 </blockquote>
7202
7203 <p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
7204
7205 <p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
7206 added footnotes pointing out that the use of closed ranges was
7207 intentional.]</i></p>
7208
7209 <hr>
7210 <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>
7211 <p>basic_istream&lt;&gt;::get(), and basic_istream&lt;&gt;::getline(),
7212 are unclear with respect to the behavior and side-effects of the named
7213 functions in case of an error.</p>
7214
7215 <p>27.6.1.3, p1 states that "... If the sentry object returns
7216 true, when converted to a value of type bool, the function endeavors
7217 to obtain the requested input..." It is not clear from this (or
7218 the rest of the paragraph) what precisely the behavior should be when
7219 the sentry ctor exits by throwing an exception or when the sentry
7220 object returns false.  In particular, what is the number of characters
7221 extracted that gcount() returns supposed to be?</p>
7222
7223 <p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
7224 "...  In any case, it then stores a null character (using
7225 charT()) into the next successive location of the array." Is not
7226 clear whether this sentence applies if either of the conditions above
7227 holds (i.e., when sentry fails).</p>
7228 <p><b>Proposed resolution:</b></p>
7229 <p>Add to 27.6.1.3, p1 after the sentence</p>
7230
7231 <blockquote>
7232 "... If the sentry object returns true, when converted to a value of
7233 type bool, the function endeavors to obtain the requested input."
7234 </blockquote>
7235
7236 <p>the following</p>
7237
7238
7239 <blockquote>
7240 "Otherwise, if the sentry constructor exits by throwing an exception or
7241 if the sentry object returns false, when converted to a value of type
7242 bool, the function returns without attempting to obtain any input. In
7243 either case the number of extracted characters is set to 0; unformatted
7244 input functions taking a character array of non-zero size as an argument
7245 shall also store a null character (using charT()) in the first location
7246 of the array."
7247 </blockquote>
7248 <p><b>Rationale:</b></p>
7249 <p>Although the general philosophy of the input functions is that the
7250 argument should not be modified upon failure, <tt>getline</tt>
7251 historically added a terminating null unconditionally.  Most
7252 implementations still do that.  Earlier versions of the draft standard
7253 had language that made this an unambiguous requirement; those words
7254 were moved to a place where their context made them less clear.  See
7255 Jerry Schwarz's message c++std-lib-7618.</p>
7256 <hr>
7257 <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>
7258 <p>There is no requirement that any of time_get member functions set
7259 ios::eofbit when they reach the end iterator while parsing their input.
7260 Since members of both the num_get and money_get facets are required to
7261 do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
7262 should follow the same requirement for consistency.</p>
7263 <p><b>Proposed resolution:</b></p>
7264 <p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
7265
7266 <blockquote>
7267 If the end iterator is reached during parsing by any of the get()
7268 member functions, the member sets ios_base::eofbit in err.
7269 </blockquote>
7270 <p><b>Rationale:</b></p>
7271 <p>Two alternative resolutions were proposed.  The LWG chose this one
7272 because it was more consistent with the way eof is described for other
7273 input facets.</p>
7274 <hr>
7275 <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>
7276 <p>
7277 Section 23.2.2.4 [lib.list.ops] states that
7278 </p>
7279 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
7280 </pre>
7281 <p>
7282 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
7283 </p>
7284
7285 <p>
7286 This is unnecessary and defeats an important feature of splice. In
7287 fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
7288 after <tt>splice</tt>.
7289 </p>
7290 <p><b>Proposed resolution:</b></p>
7291
7292 <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>
7293 <blockquote>
7294 [<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
7295 4-5, the semantics described in this clause applies only to the case
7296 where allocators compare equal.  --end footnote]
7297 </blockquote>
7298
7299 <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>
7300 <blockquote>
7301 Effects: Inserts the contents of x before position and x becomes
7302 empty.  Pointers and references to the moved elements of x now refer to
7303 those same elements but as members of *this.  Iterators referring to the
7304 moved elements will continue to refer to their elements, but they now
7305 behave as iterators into *this, not into x.
7306 </blockquote>
7307
7308 <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>
7309 <blockquote>
7310 Effects: Inserts an element pointed to by i from list x before
7311 position and removes the element from x. The result is unchanged if
7312 position == i or position == ++i.  Pointers and references to *i continue
7313 to refer to this same element but as a member of *this.  Iterators to *i
7314 (including i itself) continue to refer to the same element, but now
7315 behave as iterators into *this, not into x.
7316 </blockquote>
7317
7318 <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>
7319 <blockquote>
7320 Requires: [first, last) is a valid range in x. The result is
7321 undefined if position is an iterator in the range [first, last).
7322 Pointers and references to the moved elements of x now refer to those
7323 same elements but as members of *this.  Iterators referring to the moved
7324 elements will continue to refer to their elements, but they now behave as
7325 iterators into *this, not into x.
7326 </blockquote>
7327
7328 <p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
7329 <p><b>Rationale:</b></p>
7330 <p>The original proposed resolution said that iterators and references
7331 would remain "valid".  The new proposed resolution clarifies what that
7332 means.  Note that this only applies to the case of equal allocators.
7333 &gt;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
7334 allocators compare nonequal is outside the scope of the standard.</p>
7335 <hr>
7336 <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>
7337 <p>The synopsis for the template class <tt>basic_stringbuf</tt>
7338 doesn't list a typedef for the template parameter
7339 <tt>Allocator</tt>. This makes it impossible to determine the type of
7340 the allocator at compile time. It's also inconsistent with all other
7341 template classes in the library that do provide a typedef for the
7342 <tt>Allocator</tt> parameter.</p>
7343 <p><b>Proposed resolution:</b></p>
7344 <p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
7345 basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and
7346 basic_stringstream (27.7.4) the typedef:</p>
7347 <pre>  typedef Allocator allocator_type;
7348 </pre>
7349 <hr>
7350 <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>
7351 <p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
7352 const_cast&lt;&gt; in the Returns clause for basic_istringstream&lt;&gt;::rdbuf().
7353 The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
7354 D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
7355 the cast altogether.</p>
7356
7357 <p>C-style casts have not been deprecated, so the first part of this
7358 issue is stylistic rather than a matter of correctness.</p>
7359 <p><b>Proposed resolution:</b></p>
7360 <p>In 27.7.2.2, p1 replace </p>
7361 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
7362
7363 <p>with</p>
7364 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
7365
7366
7367 <p>In 27.7.3.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 <p>In 27.7.6, p1, replace</p>
7374 <pre>  -1- Returns: &amp;sb</pre>
7375
7376 <p>with</p>
7377 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
7378
7379 <p>In D.7.2.2, p1 replace</p>
7380 <pre>  -2- Returns: &amp;sb. </pre>
7381
7382 <p>with</p>
7383 <pre>  -2- Returns: const_cast&lt;strstreambuf*&gt;(&amp;sb).</pre>
7384 <hr>
7385 <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>
7386 <p>This discussion is adapted from message c++std-lib-7056 posted
7387 November 11, 1999.  I don't think that anyone can reasonably claim
7388 that the problem described below is NAD.</p>
7389
7390 <p>These valarray constructors can never be called:</p>
7391
7392 <pre>   template &lt;class T&gt;
7393          valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
7394    template &lt;class T&gt;
7395          valarray&lt;T&gt;::valarray(const gslice_array&lt;T&gt; &amp;);
7396    template &lt;class T&gt;
7397          valarray&lt;T&gt;::valarray(const mask_array&lt;T&gt; &amp;);
7398    template &lt;class T&gt;
7399          valarray&lt;T&gt;::valarray(const indirect_array&lt;T&gt; &amp;);
7400 </pre>
7401
7402 <p>Similarly, these valarray assignment operators cannot be
7403 called:</p>
7404
7405 <pre>     template &lt;class T&gt;
7406      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const slice_array&lt;T&gt; &amp;);
7407      template &lt;class T&gt;
7408      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const gslice_array&lt;T&gt; &amp;);
7409      template &lt;class T&gt;
7410      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const mask_array&lt;T&gt; &amp;);
7411      template &lt;class T&gt;
7412      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const indirect_array&lt;T&gt; &amp;);
7413 </pre>
7414
7415 <p>Please consider the following example:</p>
7416
7417 <pre>   #include &lt;valarray&gt;
7418    using namespace std;
7419
7420    int main()
7421    {
7422        valarray&lt;double&gt; va1(12);
7423        valarray&lt;double&gt; va2(va1[slice(1,4,3)]); // line 1
7424    }
7425 </pre>
7426
7427
7428 <p>Since the valarray va1 is non-const, the result of the sub-expression
7429 va1[slice(1,4,3)] at line 1 is an rvalue of type const
7430 std::slice_array&lt;double&gt;.  This slice_array rvalue is then used to
7431 construct va2.  The constructor that is used to construct va2 is
7432 declared like this:</p>
7433
7434 <pre>     template &lt;class T&gt;
7435      valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
7436 </pre>
7437
7438 <p>Notice the constructor's const reference parameter.  When the
7439 constructor is called, a slice_array must be bound to this reference.
7440 The rules for binding an rvalue to a const reference are in 8.5.3,
7441 paragraph 5 (see also 13.3.3.1.4).  Specifically, paragraph 5
7442 indicates that a second slice_array rvalue is constructed (in this
7443 case copy-constructed) from the first one; it is this second rvalue
7444 that is bound to the reference parameter.  Paragraph 5 also requires
7445 that the constructor that is used for this purpose be callable,
7446 regardless of whether the second rvalue is elided.  The
7447 copy-constructor in this case is not callable, however, because it is
7448 private.  Therefore, the compiler should report an error.</p>
7449
7450 <p>Since slice_arrays are always rvalues, the valarray constructor that has a
7451 parameter of type const slice_array&lt;T&gt; &amp; can never be called.  The
7452 same reasoning applies to the three other constructors and the four
7453 assignment operators that are listed at the beginning of this post.
7454 Furthermore, since these functions cannot be called, the valarray helper
7455 classes are almost entirely useless.</p>
7456 <p><b>Proposed resolution:</b></p>
7457 <p>slice_array:</p>
7458 <ul>
7459 <li> Make the copy constructor and copy-assignment operator declarations
7460      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>
7461 <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>
7462 </li>
7463 <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>
7464 </li>
7465 <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
7466     to be private.  This constructor need not be defined."</li>
7467 <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>
7468 </li>
7469 <li> Change the first three words of the second sentence of paragraph 1 of
7470     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>
7471 </ul>
7472
7473 <p>gslice_array:</p>
7474 <ul>
7475 <li> Make the copy constructor and copy-assignment operator declarations
7476     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>
7477 <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>
7478 </li>
7479 <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>
7480 </li>
7481 <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
7482     to be private.  This constructor need not be defined."</li>
7483 <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>
7484 </li>
7485 <li> Change the first three words of the second sentence of paragraph 1 of
7486     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>
7487 </ul>
7488
7489 <p>mask_array:</p>
7490 <ul>
7491 <li> Make the copy constructor and copy-assignment operator declarations
7492     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>
7493 <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>
7494 </li>
7495 <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>
7496 </li>
7497 <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
7498     to be private.  This constructor need not be defined."</li>
7499 <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>
7500 </li>
7501 <li> Change the first three words of the second sentence of paragraph 1 of
7502     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>
7503 </ul>
7504
7505 <p>indirect_array:</p>
7506 <ul>
7507 <li>Make the copy constructor and copy-assignment operator declarations
7508     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>
7509 </li>
7510 <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>
7511 </li>
7512 <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>
7513 </li>
7514 <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
7515     declared to be private.  This constructor need not be defined."</li>
7516 <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>
7517 </li>
7518 <li> Change the first three words of the second sentence of paragraph 1 of
7519     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>
7520 </ul>
7521 <p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
7522 copy constructor and copy assignment operators public, instead of
7523 removing them.]</i></p>
7524 <p><b>Rationale:</b></p>
7525 <p>Keeping the valarray constructors private is untenable.  Merely
7526 making valarray a friend of the helper classes isn't good enough,
7527 because access to the copy constructor is checked in the user's
7528 environment.</p>
7529
7530 <p>Making the assignment operator public is not strictly necessary to
7531 solve this problem.  A majority of the LWG <i>(straw poll: 13-4)</i>
7532 believed we should make the assignment operators public, in addition
7533 to the copy constructors, for reasons of symmetry and user
7534 expectation.</p>
7535 <hr>
7536 <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>
7537 <p>
7538 27.4.4.2, p17 says
7539 </p>
7540
7541 <blockquote>
7542 -17- Before copying any parts of rhs, calls each registered callback
7543 pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
7544 exceptions() have been replaced, calls each callback pair that was
7545 copied from rhs as (*fn)(copy_event,*this,index).
7546 </blockquote>
7547
7548 <p>
7549 The name copy_event isn't defined anywhere. The intended name was
7550 copyfmt_event.
7551 </p>
7552 <p><b>Proposed resolution:</b></p>
7553 <p>Replace copy_event with copyfmt_event in the named paragraph.</p>
7554 <hr>
7555 <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>
7556 <p>
7557 <i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
7558 </p>
7559
7560 <p>
7561 The standard's description of <tt>basic_string&lt;&gt;::operator[]</tt>
7562 seems to violate const correctness.
7563 </p>
7564
7565 <p>
7566 The standard (21.3.4/1) says that "If <tt>pos &lt; size()</tt>,
7567 returns <tt>data()[pos]</tt>." The types don't work.  The
7568 return value of <tt>data()</tt> is <tt>const charT*</tt>, but
7569 <tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
7570 </p>
7571 <p><b>Proposed resolution:</b></p>
7572 <p>
7573 In section 21.3.4, paragraph 1, change
7574 "<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
7575 <i>pos</i>)</tt>".
7576 </p>
7577 <hr>
7578 <a name="260"><h3>260.&nbsp;Inconsistent return type of <tt>istream_iterator::operator++(int)</tt>
7579 </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>
7580 <p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
7581 it as returning the iterator by value. 24.5.1.2, p5 shows the same
7582 operator as returning the iterator by reference. That's incorrect
7583 given the Effects clause below (since a temporary is returned). The
7584 `&amp;' is probably just a typo.</p>
7585 <p><b>Proposed resolution:</b></p>
7586 <p>Change the declaration in 24.5.1.2, p5 from</p>
7587  <pre> istream_iterator&lt;T,charT,traits,Distance&gt;&amp; operator++(int);
7588  </pre>
7589 <p>to</p>
7590  <pre> istream_iterator&lt;T,charT,traits,Distance&gt; operator++(int);
7591  </pre>
7592 <p>(that is, remove the `&amp;').</p>
7593 <hr>
7594 <a name="261"><h3>261.&nbsp;Missing description of <tt>istream_iterator::operator!=</tt>
7595 </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>
7596 <p>
7597 24.5.1, p3 lists the synopsis for
7598 </p>
7599
7600 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
7601         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
7602                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
7603 </pre>
7604
7605 <p>
7606 but there is no description of what the operator does (i.e., no Effects
7607 or Returns clause) in 24.5.1.2.
7608 </p>
7609 <p><b>Proposed resolution:</b></p>
7610 <p>
7611 Add paragraph 7 to the end of section 24.5.1.2 with the following text:
7612 </p>
7613
7614 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
7615         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
7616                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
7617 </pre>
7618
7619 <p>-7- Returns: !(x == y).</p>
7620 <hr>
7621 <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>
7622 <p>
7623 The ~ operation should be applied after the cast to int_type.
7624 </p>
7625 <p><b>Proposed resolution:</b></p>
7626 <p>
7627 Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
7628 </p>
7629
7630 <pre>   bitmask operator~ ( bitmask X )
7631      { return static_cast&lt; bitmask&gt;(static_cast&lt;int_type&gt;(~ X)); }
7632 </pre>
7633
7634 <p>
7635 to:
7636 </p>
7637
7638 <pre>   bitmask operator~ ( bitmask X )
7639      { return static_cast&lt; bitmask&gt;(~static_cast&lt;int_type&gt;(X)); }
7640 </pre>
7641 <hr>
7642 <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>
7643 <p>
7644 The note in paragraph 6 suggests that the invalidation rules for
7645 references, pointers, and iterators in paragraph 5 permit a reference-
7646 counted implementation (actually, according to paragraph 6, they permit
7647 a "reference counted implementation", but this is a minor editorial fix).
7648 </p>
7649
7650 <p>
7651 However, the last sub-bullet is so worded as to make a reference-counted
7652 implementation unviable. In the following example none of the
7653 conditions for iterator invalidation are satisfied:
7654 </p>
7655
7656 <pre>    // first example: "*******************" should be printed twice
7657     string original = "some arbitrary text", copy = original;
7658     const string &amp; alias = original;
7659
7660     string::const_iterator i = alias.begin(), e = alias.end();
7661     for(string::iterator j = original.begin(); j != original.end(); ++j)
7662         *j = '*';
7663     while(i != e)
7664         cout &lt;&lt; *i++;
7665     cout &lt;&lt; endl;
7666     cout &lt;&lt; original &lt;&lt; endl;
7667 </pre>
7668
7669 <p>
7670 Similarly, in the following example:
7671 </p>
7672
7673 <pre>    // second example: "some arbitrary text" should be printed out
7674     string original = "some arbitrary text", copy = original;
7675     const string &amp; alias = original;
7676
7677     string::const_iterator i = alias.begin();
7678     original.begin();
7679     while(i != alias.end())
7680         cout &lt;&lt; *i++;
7681 </pre>
7682
7683 <p>
7684 I have tested this on three string implementations, two of which were
7685 reference counted. The reference-counted implementations gave
7686 "surprising behavior" because they invalidated iterators on
7687 the first call to non-const begin since construction. The current
7688 wording does not permit such invalidation because it does not take
7689 into account the first call since construction, only the first call
7690 since various member and non-member function calls.
7691 </p>
7692 <p><b>Proposed resolution:</b></p>
7693 <p>
7694 Change the following sentence in 21.3 paragraph 5 from
7695 </p>
7696
7697 <blockquote>
7698     Subsequent to any of the above uses except the forms of insert() and
7699     erase() which return iterators, the first call to non-const member
7700     functions operator[](), at(), begin(), rbegin(), end(), or rend().
7701 </blockquote>
7702
7703 <p>to</p>
7704
7705 <blockquote>
7706     Following construction or any of the above uses, except the forms of
7707     insert() and erase() that return iterators, the first call to non-
7708     const member functions operator[](), at(), begin(), rbegin(), end(),
7709     or rend().
7710 </blockquote>
7711 <hr>
7712 <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>
7713 <p>
7714 Table 69 requires linear time if [i, j) is sorted.  Sorted is necessary but not sufficient.
7715 Consider inserting a sorted range of even integers into a set&lt;int&gt; containing the odd
7716 integers in the same range.
7717 </p>
7718
7719 <p><i>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></i></p>
7720 <p><b>Proposed resolution:</b></p>
7721 <p>
7722 In Table 69, in section 23.1.2, change the complexity clause for
7723 insertion of a range from "N log(size() + N) (N is the distance
7724 from i to j) in general; linear if [i, j) is sorted according to
7725 value_comp()" to "N log(size() + N), where N is the distance
7726 from i to j".
7727 </p>
7728
7729 <p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
7730 parens in the revised wording.]</i></p>
7731
7732 <p><b>Rationale:</b></p>
7733 <p>
7734 Testing for valid insertions could be less efficient than simply
7735 inserting the elements when the range is not both sorted and between
7736 two adjacent existing elements; this could be a QOI issue.
7737 </p>
7738
7739 <p>
7740 The LWG considered two other options: (a) specifying that the
7741 complexity was linear if [i, j) is sorted according to value_comp()
7742 and between two adjacent existing elements; or (b) changing to
7743 Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
7744 number of elements which do not insert immediately after the previous
7745 element from [i, j) including the first).  The LWG felt that, since
7746 we can't guarantee linear time complexity whenever the range to be
7747 inserted is sorted, it's more trouble than it's worth to say that it's
7748 linear in some special cases.
7749 </p>
7750 <hr>
7751 <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>
7752 <p>
7753 I don't see any requirements on the types of the elements of the
7754 std::pair container in 20.2.2. From the descriptions of the member
7755 functions it appears that they must at least satisfy the requirements of
7756 20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
7757 the case of the [in]equality operators also the requirements of 20.1.1
7758 [lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
7759 </p>
7760
7761 <p>
7762 I believe that the the CopyConstructible requirement is unnecessary in
7763 the case of 20.2.2, p2.
7764 </p>
7765 <p><b>Proposed resolution:</b></p>
7766 <p>Change the Effects clause in 20.2.2, p2 from</p>
7767
7768 <blockquote>
7769 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
7770 first(T1()), second(T2()) {} </tt>
7771 </blockquote>
7772
7773 <p>to</p>
7774
7775 <blockquote>
7776 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
7777 first(), second() {} </tt>
7778 </blockquote>
7779 <p><b>Rationale:</b></p>
7780 <p>The existing specification of pair's constructor appears to be a
7781 historical artifact: there was concern that pair's members be properly
7782 zero-initialized when they are built-in types.  At one time there was
7783 uncertainty about whether they would be zero-initialized if the
7784 default constructor was written the obvious way.  This has been
7785 clarified by core issue 178, and there is no longer any doubt that
7786 the straightforward implementation is correct.</p>
7787 <hr>
7788 <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>
7789 <p>
7790 The synopsis for std::bad_exception lists the function ~bad_exception()
7791 but there is no description of what the function does (the Effects
7792 clause is missing).
7793 </p>
7794 <p><b>Proposed resolution:</b></p>
7795 <p>
7796 Remove the destructor from the class synopses of
7797 <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>),
7798 <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>),
7799 <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>),
7800 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>).
7801 </p>
7802 <p><b>Rationale:</b></p>
7803 <p>
7804 This is a general problem with the exception classes in clause 18.
7805 The proposed resolution is to remove the destructors from the class
7806 synopses, rather than to document the destructors' behavior, because
7807 removing them is more consistent with how exception classes are
7808 described in clause 19.
7809 </p>
7810 <hr>
7811 <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>
7812 <p>The synopsis of the class std::locale in 22.1.1 contains two typos:
7813 the semicolons after the declarations of the default ctor
7814 locale::locale() and the copy ctor locale::locale(const locale&amp;)
7815 are missing.</p>
7816 <p><b>Proposed resolution:</b></p>
7817 <p>Add the missing semicolons, i.e., change</p>
7818
7819 <pre>    //  construct/copy/destroy:
7820         locale() throw()
7821         locale(const locale&amp; other) throw()
7822 </pre>
7823
7824 <p>in the synopsis in 22.1.1 to</p>
7825
7826 <pre>    //  construct/copy/destroy:
7827         locale() throw();
7828         locale(const locale&amp; other) throw();
7829 </pre>
7830 <hr>
7831 <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>
7832 <p>
7833 Each of the four binary search algorithms (lower_bound, upper_bound,
7834 equal_range, binary_search) has a form that allows the user to pass a
7835 comparison function object.  According to 25.3, paragraph 2, that
7836 comparison function object has to be a strict weak ordering.
7837 </p>
7838
7839 <p>
7840 This requirement is slightly too strict.  Suppose we are searching
7841 through a sequence containing objects of type X, where X is some
7842 large record with an integer key.  We might reasonably want to look
7843 up a record by key, in which case we would want to write something
7844 like this:
7845 </p>
7846 <pre>    struct key_comp {
7847       bool operator()(const X&amp; x, int n) const {
7848         return x.key() &lt; n;
7849       }
7850     }
7851
7852     std::lower_bound(first, last, 47, key_comp());
7853 </pre>
7854
7855 <p>
7856 key_comp is not a strict weak ordering, but there is no reason to
7857 prohibit its use in lower_bound.
7858 </p>
7859
7860 <p>
7861 There's no difficulty in implementing lower_bound so that it allows
7862 the use of something like key_comp.  (It will probably work unless an
7863 implementor takes special pains to forbid it.)  What's difficult is
7864 formulating language in the standard to specify what kind of
7865 comparison function is acceptable.  We need a notion that's slightly
7866 more general than that of a strict weak ordering, one that can encompass
7867 a comparison function that involves different types.  Expressing that
7868 notion may be complicated.
7869 </p>
7870
7871 <p><i>Additional questions raised at the Toronto meeting:</i></p>
7872 <ul>
7873 <li> Do we really want to specify what ordering the implementor must
7874      use when calling the function object?  The standard gives
7875      specific expressions when describing these algorithms, but it also
7876      says that other expressions (with different argument order) are
7877      equivalent.</li>
7878 <li> If we are specifying ordering, note that the standard uses both
7879      orderings when describing <tt>equal_range</tt>.</li>
7880 <li> Are we talking about requiring these algorithms to work properly
7881      when passed a binary function object whose two argument types
7882      are not the same, or are we talking about requirements when
7883      they are passed a binary function object with several overloaded
7884      versions of <tt>operator()</tt>?</li>
7885 <li> The definition of a strict weak ordering does not appear to give
7886      any guidance on issues of overloading; it only discusses expressions,
7887      and all of the values in these expressions are of the same type.
7888      Some clarification would seem to be in order.</li>
7889 </ul>
7890
7891 <p><i>Additional discussion from Copenhagen:</i></p>
7892 <ul>
7893 <li>It was generally agreed that there is a real defect here: if
7894 the predicate is merely required to be a Strict Weak Ordering, then
7895 it's possible to pass in a function object with an overloaded
7896 operator(), where the version that's actually called does something
7897 completely inappropriate.  (Such as returning a random value.)</li>
7898
7899 <li>An alternative formulation was presented in a paper distributed by
7900 David Abrahams at the meeting, "Binary Search with Heterogeneous
7901 Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
7902 predicate as a Strict Weak Ordering acting on a sorted sequence, view
7903 the predicate/value pair as something that partitions a sequence.
7904 This is almost equivalent to saying that we should view binary search
7905 as if we are given a unary predicate and a sequence, such that f(*p)
7906 is true for all p below a specific point and false for all p above it.
7907 The proposed resolution is based on that alternative formulation.</li>
7908 </ul>
7909 <p><b>Proposed resolution:</b></p>
7910
7911 <p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
7912
7913 <blockquote>
7914   3 For all algorithms that take Compare, there is a version that uses
7915   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i &lt;
7916   *j != false. For the algorithms to work correctly, comp has to
7917   induce a strict weak ordering on the values.
7918 </blockquote>
7919
7920 <p>to:</p>
7921
7922 <blockquote>
7923   3 For all algorithms that take Compare, there is a version that uses
7924   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i
7925   &lt; *j != false. For algorithms other than those described in
7926   lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
7927   a strict weak ordering on the values.
7928 </blockquote>
7929
7930 <p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
7931
7932 <blockquote>
7933   -6- A sequence [start, finish) is partitioned with respect to an
7934   expression f(e) if there exists an integer n such that
7935   for all 0 &lt;= i &lt; distance(start, finish), f(*(begin+i)) is true if
7936   and only if i &lt; n.
7937 </blockquote>
7938
7939 <p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
7940
7941 <blockquote>
7942   -1- All of the algorithms in this section are versions of binary
7943    search and assume that the sequence being searched is in order
7944    according to the implied or explicit comparison function. They work
7945    on non-random access iterators minimizing the number of
7946    comparisons, which will be logarithmic for all types of
7947    iterators. They are especially appropriate for random access
7948    iterators, because these algorithms do a logarithmic number of
7949    steps through the data structure. For non-random access iterators
7950    they execute a linear number of steps.
7951 </blockquote>
7952
7953 <p>to:</p>
7954
7955 <blockquote>
7956    -1- All of the algorithms in this section are versions of binary
7957     search and assume that the sequence being searched is partitioned
7958     with respect to an expression formed by binding the search key to
7959     an argument of the implied or explicit comparison function. They
7960     work on non-random access iterators minimizing the number of
7961     comparisons, which will be logarithmic for all types of
7962     iterators. They are especially appropriate for random access
7963     iterators, because these algorithms do a logarithmic number of
7964     steps through the data structure. For non-random access iterators
7965     they execute a linear number of steps.
7966 </blockquote>
7967
7968 <p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
7969
7970 <blockquote>
7971    -1- Requires: Type T is LessThanComparable
7972     (lib.lessthancomparable).
7973 </blockquote>
7974
7975 <p>to:</p>
7976
7977 <blockquote>
7978    -1- Requires: The elements e of [first, last) are partitioned with
7979    respect to the expression e &lt; value or comp(e, value)
7980 </blockquote>
7981
7982
7983 <p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
7984
7985 <blockquote>
7986    -2- Effects: Finds the first position into which value can be
7987     inserted without violating the ordering.
7988 </blockquote>
7989
7990 <p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
7991
7992 <blockquote>
7993   -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
7994 </blockquote>
7995
7996 <p>to:</p>
7997
7998 <blockquote>
7999    -1- Requires: The elements e of [first, last) are partitioned with
8000    respect to the expression !(value &lt; e) or !comp(value, e)
8001 </blockquote>
8002
8003 <p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
8004
8005 <blockquote>
8006    -2- Effects: Finds the furthermost position into which value can be
8007     inserted without violating the ordering.
8008 </blockquote>
8009
8010 <p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
8011
8012 <blockquote>
8013    -1- Requires: Type T is LessThanComparable
8014     (lib.lessthancomparable).
8015 </blockquote>
8016
8017 <p>to:</p>
8018
8019 <blockquote>
8020    -1- Requires: The elements e of [first, last) are partitioned with
8021    respect to the expressions e &lt; value and !(value &lt; e) or
8022    comp(e, value) and !comp(value, e).  Also, for all elements e of
8023    [first, last), e &lt; value implies !(value &lt; e) or comp(e,
8024    value) implies !comp(value, e)
8025 </blockquote>
8026
8027 <p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
8028
8029 <blockquote>
8030    -2- Effects: Finds the largest subrange [i, j) such that the value
8031     can be inserted at any iterator k in it without violating the
8032     ordering. k satisfies the corresponding conditions: !(*k &lt; value)
8033     &amp;&amp; !(value &lt; *k) or comp(*k, value) == false &amp;&amp; comp(value, *k) ==
8034     false.
8035 </blockquote>
8036
8037 <p>to:</p>
8038
8039 <pre>   -2- Returns:
8040          make_pair(lower_bound(first, last, value),
8041                    upper_bound(first, last, value))
8042        or
8043          make_pair(lower_bound(first, last, value, comp),
8044                    upper_bound(first, last, value, comp))
8045 </pre>
8046
8047 <p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
8048
8049 <blockquote>
8050    -1- Requires: Type T is LessThanComparable
8051     (lib.lessthancomparable).
8052 </blockquote>
8053
8054 <p>to:</p>
8055
8056 <blockquote>
8057    -1- Requires: The elements e of [first, last) are partitioned with
8058    respect to the expressions e &lt; value and !(value &lt; e) or comp(e,
8059    value) and !comp(value, e). Also, for all elements e of [first,
8060    last), e &lt; value implies !(value &lt; e) or comp(e, value) implies
8061    !comp(value, e)
8062 </blockquote>
8063
8064 <p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
8065
8066 <p><i>[Redmond: Minor changes in wording.  (Removed "non-negative", and
8067 changed the "other than those described in" wording.) Also, the LWG
8068 decided to accept the "optional" part.]</i></p>
8069
8070 <p><b>Rationale:</b></p>
8071 <p>The proposed resolution reinterprets binary search. Instead of
8072 thinking about searching for a value in a sorted range, we view that
8073 as an important special case of a more general algorithm: searching
8074 for the partition point in a partitioned range.</p>
8075
8076 <p>We also add a guarantee that the old wording did not: we ensure
8077 that the upper bound is no earlier than the lower bound, that
8078 the pair returned by equal_range is a valid range, and that the first
8079 part of that pair is the lower bound.</p>
8080 <hr>
8081 <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>
8082 <p>
8083 Class template basic_iostream has no typedefs.  The typedefs it
8084 inherits from its base classes can't be used, since (for example)
8085 basic_iostream&lt;T&gt;::traits_type is ambiguous.
8086 </p>
8087 <p><b>Proposed resolution:</b></p>
8088
8089 <p>Add the following to basic_iostream's class synopsis in
8090 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>
8091
8092 <pre>  // types:
8093   typedef charT                     char_type;
8094   typedef typename traits::int_type int_type;
8095   typedef typename traits::pos_type pos_type;
8096   typedef typename traits::off_type off_type;
8097   typedef traits                    traits_type;
8098 </pre>
8099 <hr>
8100 <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>
8101 <p>
8102 27.4.4.3, p4 says about the postcondition of the function: If
8103 rdbuf()!=0 then state == rdstate(); otherwise
8104 rdstate()==state|ios_base::badbit.
8105 </p>
8106
8107 <p>
8108 The expression on the right-hand-side of the operator==() needs to be
8109 parenthesized in order for the whole expression to ever evaluate to
8110 anything but non-zero.
8111 </p>
8112 <p><b>Proposed resolution:</b></p>
8113 <p>
8114 Add parentheses like so: rdstate()==(state|ios_base::badbit).
8115 </p>
8116 <hr>
8117 <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>
8118 <p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
8119 27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
8120 That's incorrect since the names are members of a dependent base
8121 class (14.6.2 [temp.dep]) and thus not visible.</p>
8122 <p><b>Proposed resolution:</b></p>
8123 <p>Qualify the names with the name of the class of which they are
8124 members, i.e., ios_base.</p>
8125 <hr>
8126 <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>
8127 <p>
8128 I see that table 31 in 20.1.5, p3 allows T in std::allocator&lt;T&gt; to be of
8129 any type. But the synopsis in 20.4.1 calls for allocator&lt;&gt;::address() to
8130 be overloaded on reference and const_reference, which is ill-formed for
8131 all T = const U. In other words, this won't work:
8132 </p>
8133
8134 <p>
8135 template class std::allocator&lt;const int&gt;;
8136 </p>
8137
8138 <p>
8139 The obvious solution is to disallow specializations of allocators on
8140 const types. However, while containers' elements are required to be
8141 assignable (which rules out specializations on const T's), I think that
8142 allocators might perhaps be potentially useful for const values in other
8143 contexts. So if allocators are to allow const types a partial
8144 specialization of std::allocator&lt;const T&gt; would probably have to be
8145 provided.
8146 </p>
8147 <p><b>Proposed resolution:</b></p>
8148 <p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
8149
8150     <blockquote>
8151     any type
8152     </blockquote>
8153
8154 <p>to</p>
8155     <blockquote>
8156     any non-const, non-reference type
8157     </blockquote>
8158
8159 <p><i>[Redmond: previous proposed resolution was "any non-const,
8160 non-volatile, non-reference type".  Got rid of the "non-volatile".]</i></p>
8161
8162 <p><b>Rationale:</b></p>
8163 <p>
8164 Two resolutions were originally proposed: one that partially
8165 specialized std::allocator for const types, and one that said an
8166 allocator's value type may not be const.  The LWG chose the second.
8167 The first wouldn't be appropriate, because allocators are intended for
8168 use by containers, and const value types don't work in containers.
8169 Encouraging the use of allocators with const value types would only
8170 lead to unsafe code.
8171 </p>
8172 <p>
8173 The original text for proposed resolution 2 was modified so that it
8174 also forbids volatile types and reference types.
8175 </p>
8176
8177 <p><i>[Curaçao: LWG double checked and believes volatile is correctly
8178 excluded from the PR.]</i></p>
8179
8180 <hr>
8181 <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>
8182 <p>
8183 In 22.2.2.1.1, we have a list of overloads for num_get&lt;&gt;::get().
8184 There are eight overloads, all of which are identical except for the
8185 last parameter.  The overloads are:
8186 </p>
8187 <ul>
8188 <li> long&amp; </li>
8189 <li> unsigned short&amp; </li>
8190 <li> unsigned int&amp; </li>
8191 <li> unsigned long&amp; </li>
8192 <li> short&amp; </li>
8193 <li> double&amp; </li>
8194 <li> long double&amp; </li>
8195 <li> void*&amp; </li>
8196 </ul>
8197
8198 <p>
8199 There is a similar list, in 22.2.2.1.2, of overloads for
8200 num_get&lt;&gt;::do_get().  In this list, the last parameter has
8201 the types:
8202 </p>
8203 <ul>
8204 <li> long&amp; </li>
8205 <li> unsigned short&amp; </li>
8206 <li> unsigned int&amp; </li>
8207 <li> unsigned long&amp; </li>
8208 <li> float&amp; </li>
8209 <li> double&amp; </li>
8210 <li> long double&amp; </li>
8211 <li> void*&amp; </li>
8212 </ul>
8213
8214 <p>
8215 These two lists are not identical.  They should be, since
8216 <tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
8217 the arguments it was given.
8218 </p>
8219 <p><b>Proposed resolution:</b></p>
8220 <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>
8221 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
8222                 ios_base::iostate&amp; err, short&amp; val) const;
8223 </pre>
8224 <p>to</p>
8225 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
8226                 ios_base::iostate&amp; err, float&amp; val) const;
8227 </pre>
8228 <hr>
8229 <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>
8230 <p>
8231 23.1/3 states that the objects stored in a container must be
8232 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,
8233 states that map satisfies all requirements for a container, while in
8234 the same time defining value_type as pair&lt;const Key, T&gt; - a type
8235 that is not Assignable.
8236 </p>
8237
8238 <p>
8239 It should be noted that there exists a valid and non-contradictory
8240 interpretation of the current text. The wording in 23.1/3 avoids
8241 mentioning value_type, referring instead to "objects stored in a
8242 container." One might argue that map does not store objects of
8243 type map::value_type, but of map::mapped_type instead, and that the
8244 Assignable requirement applies to map::mapped_type, not
8245 map::value_type.
8246 </p>
8247
8248 <p>
8249 However, this makes map a special case (other containers store objects of
8250 type value_type) and the Assignable requirement is needlessly restrictive in
8251 general.
8252 </p>
8253
8254 <p>
8255 For example, the proposed resolution of active library issue
8256 <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
8257 means that no set operations can exploit the fact that the stored
8258 objects are Assignable.
8259 </p>
8260
8261 <p>
8262 This is related to, but slightly broader than, closed issue
8263 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>.
8264 </p>
8265 <p><b>Proposed resolution:</b></p>
8266 <p>23.1/3: Strike the trailing part of the sentence:</p>
8267     <blockquote>
8268     , and the additional requirements of Assignable types from 23.1/3
8269     </blockquote>
8270 <p>so that it reads:</p>
8271     <blockquote>
8272     -3- The type of objects stored in these components must meet the
8273     requirements of CopyConstructible types (lib.copyconstructible).
8274     </blockquote>
8275
8276 <p>23.1/4: Modify to make clear that this requirement is not for all
8277 containers.  Change to:</p>
8278
8279 <blockquote>
8280 -4- Table 64 defines the Assignable requirement.  Some containers
8281 require this property of the types to be stored in the container.  T is
8282 the type used to instantiate the container. t is a value of T, and u is
8283 a value of (possibly const) T.
8284 </blockquote>
8285
8286 <p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
8287 CopyConstructible".</p>
8288
8289 <p>23.2.1/2: Add sentence for Assignable requirement.  Change to:</p>
8290
8291 <blockquote>
8292 -2- A deque satisfies all of the requirements of a container and of a
8293 reversible container (given in tables in lib.container.requirements) and
8294 of a sequence, including the optional sequence requirements
8295 (lib.sequence.reqmts).  In addition to the requirements on the stored
8296 object described in 23.1[lib.container.requirements], the stored object
8297 must also meet the requirements of Assignable.  Descriptions are
8298 provided here only for operations on deque that are not described in one
8299 of these tables or for operations where there is additional semantic
8300 information.
8301 </blockquote>
8302
8303 <p>23.2.2/2:  Add Assignable requirement to specific methods of list.
8304 Change to:</p>
8305
8306 <blockquote>
8307 <p>-2- A list satisfies all of the requirements of a container and of a
8308 reversible container (given in two tables in lib.container.requirements)
8309 and of a sequence, including most of the the optional sequence
8310 requirements (lib.sequence.reqmts). The exceptions are the operator[]
8311 and at member functions, which are not provided.
8312
8313 [Footnote: These member functions are only provided by containers whose
8314 iterators are random access iterators. --- end foonote]
8315 </p>
8316
8317 <p>list does not require the stored type T to be Assignable unless the
8318 following methods are instantiated:
8319
8320 [Footnote: Implementors are permitted but not required to take advantage
8321 of T's Assignable properties for these methods. -- end foonote]
8322 </p>
8323 <pre>     list&lt;T,Allocator&gt;&amp; operator=(const list&lt;T,Allocator&gt;&amp;  x );
8324      template &lt;class InputIterator&gt;
8325        void assign(InputIterator first, InputIterator last);
8326      void assign(size_type n, const T&amp; t);
8327 </pre>
8328
8329
8330 <p>Descriptions are provided here only for operations on list that are not
8331 described in one of these tables or for operations where there is
8332 additional semantic information.</p>
8333 </blockquote>
8334
8335 <p>23.2.4/2:   Add sentence for Assignable requirement.  Change to:</p>
8336
8337 <blockquote>
8338 -2- A vector satisfies all of the requirements of a container and of a
8339 reversible container (given in two tables in lib.container.requirements)
8340 and of a sequence, including most of the optional sequence requirements
8341 (lib.sequence.reqmts). The exceptions are the push_front and pop_front
8342 member functions, which are not provided.  In addition to the
8343 requirements on the stored object described in
8344 23.1[lib.container.requirements], the stored object must also meet the
8345 requirements of Assignable.  Descriptions are provided here only for
8346 operations on vector that are not described in one of these tables or
8347 for operations where there is additional semantic information.
8348 </blockquote>
8349 <p><b>Rationale:</b></p>
8350 <p>list, set, multiset, map, multimap are able to store non-Assignables.
8351 However, there is some concern about <tt>list&lt;T&gt;</tt>:
8352 although in general there's no reason for T to be Assignable, some
8353 implementations of the member functions <tt>operator=</tt> and
8354 <tt>assign</tt> do rely on that requirement.  The LWG does not want
8355 to forbid such implementations.</p>
8356
8357 <p>Note that the type stored in a standard container must still satisfy
8358 the requirements of the container's allocator; this rules out, for
8359 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>
8360 for more details.
8361 </p>
8362
8363 <p>In principle we could also relax the "Assignable" requirement for
8364 individual <tt>vector</tt> member functions, such as
8365 <tt>push_back</tt>.  However, the LWG did not see great value in such
8366 selective relaxation.  Doing so would remove implementors' freedom to
8367 implement <tt>vector::push_back</tt> in terms of
8368 <tt>vector::insert</tt>.</p>
8369
8370 <hr>
8371 <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>
8372 <p>
8373 Section 23.2.2.4 [lib.list.ops] states that
8374 </p>
8375 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
8376 </pre>
8377 <p>
8378 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
8379 </p>
8380
8381 <p>
8382 But what does the C++ Standard mean by "invalidate"?  You
8383 can still dereference the iterator to a spliced list element, but
8384 you'd better not use it to delimit a range within the original
8385 list. For the latter operation, it has definitely lost some of its
8386 validity.
8387 </p>
8388
8389 <p>
8390 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>,
8391 then we'd better clarify that a "valid" iterator need no
8392 longer designate an element within the same container as it once did.
8393 We then have to clarify what we mean by invalidating a past-the-end
8394 iterator, as when a vector or string grows by reallocation. Clearly,
8395 such an iterator has a different kind of validity. Perhaps we should
8396 introduce separate terms for the two kinds of "validity."
8397 </p>
8398 <p><b>Proposed resolution:</b></p>
8399 <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>,
8400 after paragraph 5:</p>
8401 <blockquote>
8402 An <i>invalid</i> iterator is an iterator that may be
8403 singular. [Footnote: This definition applies to pointers, since
8404 pointers are iterators. The effect of dereferencing an iterator that
8405 has been invalidated is undefined.]
8406 </blockquote>
8407
8408 <p><i>[post-Copenhagen: Matt provided wording.]</i></p>
8409
8410 <p><i>[Redmond: General agreement with the intent, some objections to
8411 the wording.  Dave provided new wording.]</i></p>
8412 <p><b>Rationale:</b></p>
8413 <p>This resolution simply defines a term that the Standard uses but
8414   never defines, "invalid", in terms of a term that is defined,
8415   "singular".</p>
8416
8417 <p>Why do we say "may be singular", instead of "is singular"?  That's
8418   becuase a valid iterator is one that is known to be nonsingular.
8419   Invalidating an iterator means changing it in such a way that it's
8420   no longer known to be nonsingular.  An example: inserting an
8421   element into the middle of a vector is correctly said to invalidate
8422   all iterators pointing into the vector.  That doesn't necessarily
8423   mean they all become singular.</p>
8424 <hr>
8425 <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>
8426 <p>
8427 This came from an email from Steve Cleary to Fergus in reference to
8428 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
8429 this in Toronto and believed it should be a separate issue.  There was
8430 also some reservations about whether this was a worthwhile problem to
8431 fix.
8432 </p>
8433
8434 <p>
8435 Steve said: "Fixing reverse_iterator. std::reverse_iterator can
8436 (and should) be changed to preserve these additional
8437 requirements." He also said in email that it can be done without
8438 breaking user's code: "If you take a look at my suggested
8439 solution, reverse_iterator doesn't have to take two parameters; there
8440 is no danger of breaking existing code, except someone taking the
8441 address of one of the reverse_iterator global operator functions, and
8442 I have to doubt if anyone has ever done that. . .  <i>But</i>, just in
8443 case they have, you can leave the old global functions in as well --
8444 they won't interfere with the two-template-argument functions.  With
8445 that, I don't see how <i>any</i> user code could break."
8446 </p>
8447 <p><b>Proposed resolution:</b></p>
8448 <p>
8449 <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>
8450 add/change the following declarations:</p>
8451 <pre>  A) Add a templated assignment operator, after the same manner
8452         as the templated copy constructor, i.e.:
8453
8454   template &lt; class U &gt;
8455   reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
8456
8457   B) Make all global functions (except the operator+) have
8458   two template parameters instead of one, that is, for
8459   operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
8460
8461        template &lt; class Iterator &gt;
8462        typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
8463                  const reverse_iterator&lt; Iterator &gt;&amp; x,
8464                  const reverse_iterator&lt; Iterator &gt;&amp; y);
8465
8466   with:
8467
8468       template &lt; class Iterator1, class Iterator2 &gt;
8469       typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
8470                  const reverse_iterator &lt; Iterator1 &gt; &amp; x,
8471                  const reverse_iterator &lt; Iterator2 &gt; &amp; y);
8472 </pre>
8473 <p>
8474 Also make the addition/changes for these signatures in
8475 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>.
8476 </p>
8477
8478 <p><i>[
8479 Copenhagen: The LWG is concerned that the proposed resolution
8480 introduces new overloads.  Experience shows that introducing
8481 overloads is always risky, and that it would be inappropriate to
8482 make this change without implementation experience.  It may be
8483 desirable to provide this feature in a different way.
8484 ]</i></p>
8485
8486 <p><i>[
8487 Lillehammer: We now have implementation experience, and agree that
8488 this solution is safe and correct.
8489 ]</i></p>
8490
8491 <hr>
8492 <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>
8493 <p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
8494 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>)
8495 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>).
8496 Since the functions take and return their arguments and result by
8497 const reference, I believe the <tt>CopyConstructible</tt> requirement
8498 is unnecessary.
8499 </p>
8500 <p><b>Proposed resolution:</b></p>
8501 <p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
8502 25.3.7, p1 with</p>
8503 <p><b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt>
8504 (20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
8505 </p>
8506 <p>and replace 25.3.7, p4 with</p>
8507 <p><b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt>
8508 (20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
8509 </p>
8510 <hr>
8511 <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>
8512 <p>
8513 Paragraph 16 mistakenly singles out integral types for inserting
8514 thousands_sep() characters.  This conflicts with the syntax for floating
8515 point numbers described under 22.2.3.1/2.
8516 </p>
8517 <p><b>Proposed resolution:</b></p>
8518 <p>Change paragraph 16 from:</p>
8519
8520 <blockquote>
8521 For integral types, punct.thousands_sep() characters are inserted into
8522 the sequence as determined by the value returned by punct.do_grouping()
8523 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>.
8524 </blockquote>
8525
8526 <p>To:</p>
8527
8528 <blockquote>
8529 For arithmetic types, punct.thousands_sep() characters are inserted into
8530 the sequence as determined by the value returned by punct.do_grouping()
8531 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>.
8532 </blockquote>
8533
8534 <p><i>[
8535 Copenhagen: Opinions were divided about whether this is actually an
8536 inconsistency, but at best it seems to have been unintentional.  This
8537 is only an issue for floating-point output: The standard is
8538 unambiguous that implementations must parse thousands_sep characters
8539 when performing floating-point.  The standard is also unambiguous that
8540 this requirement does not apply to the "C" locale.
8541 ]</i></p>
8542
8543 <p><i>[
8544 A survey of existing practice is needed; it is believed that some
8545 implementations do insert thousands_sep characters for floating-point
8546 output and others fail to insert thousands_sep characters for
8547 floating-point input even though this is unambiguously required by the
8548 standard.
8549 ]</i></p>
8550
8551 <p><i>[Post-Curaçao: the above proposed resolution is the consensus of
8552 Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
8553
8554 <hr>
8555 <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>
8556 <p>
8557 (revision of the further discussion)
8558 There are a number of problems with the requires clauses for the
8559 algorithms in 25.1 and 25.2. The requires clause of each algorithm
8560 should describe the necessary and sufficient requirements on the inputs
8561 to the algorithm such that the algorithm compiles and runs properly.
8562 Many of the requires clauses fail to do this. Here is a summary of the kinds
8563 of mistakes:
8564 </p>
8565
8566 <ol>
8567 <li>
8568 Use of EqualityComparable, which only puts requirements on a single
8569 type, when in fact an equality operator is required between two
8570 different types, typically either T and the iterator's value type
8571 or between the value types of two different iterators.
8572 </li>
8573 <li>
8574 Use of Assignable for T when in fact what was needed is Assignable
8575 for the value_type of the iterator, and convertability from T to the
8576 value_type of the iterator. Or for output iterators, the requirement
8577 should be that T is writable to the iterator (output iterators do
8578 not have value types).
8579 </li>
8580 </ol>
8581
8582 <p>
8583 Here is the list of algorithms that contain mistakes:
8584 </p>
8585
8586 <ul>
8587 <li>25.1.2 std::find</li>
8588 <li>25.1.6 std::count</li>
8589 <li>25.1.8 std::equal</li>
8590 <li>25.1.9 std::search, std::search_n</li>
8591 <li>25.2.4 std::replace, std::replace_copy</li>
8592 <li>25.2.5 std::fill</li>
8593 <li>25.2.7 std::remove, std::remove_copy</li>
8594 </ul>
8595
8596 <p>
8597 Also, in the requirements for EqualityComparable, the requirement that
8598 the operator be defined for const objects is lacking.
8599 </p>
8600
8601 <p><b>Proposed resolution:</b></p>
8602
8603 <p>20.1.1 Change p1 from</p>
8604
8605 <p>In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
8606 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
8607 values of type <tt>T</tt>.
8608 </p>
8609
8610 <p>to</p>
8611
8612 <p>
8613 In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
8614 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
8615 values of type <tt>const T</tt>.
8616 </p>
8617
8618 <p>25 Between p8 and p9</p>
8619
8620 <p>Add the following sentence:</p>
8621
8622 <p>When the description of an algorithm gives an expression such as
8623 <tt>*first == value</tt> for a condition, it is required that the expression
8624 evaluate to either true or false in boolean contexts.</p>
8625
8626 <p>25.1.2 Change p1 by deleting the requires clause.</p>
8627
8628 <p>25.1.6 Change p1 by deleting the requires clause.</p>
8629
8630 <p>25.1.9</p>
8631
8632 <p>Change p4 from</p>
8633
8634 <p>-4- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt>
8635 (20.1.1), type Size is convertible to integral type (4.7.12.3).
8636 </p>
8637
8638 <p>to</p>
8639
8640 <p>-4- Requires: The type <tt>Size</tt> is convertible to integral
8641 type (4.7.12.3).</p>
8642
8643 <p>25.2.4 Change p1 from</p>
8644
8645 <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>
8646
8647 <p>to</p>
8648
8649 <p>-1- Requires: The expression <tt>*first = new_value</tt> must be valid.</p>
8650
8651 <p>and change p4 from</p>
8652
8653 <p>-4- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1) (and,
8654 for <tt>replace_copy()</tt>, <tt>EqualityComparable</tt>
8655 (20.1.1)). The ranges <tt>[first, last)</tt> and <tt>[result, result +
8656 (last - first))</tt> shall not overlap.</p>
8657
8658 <p>to</p>
8659
8660 <p>-4- Requires: The results of the expressions <tt>*first</tt> and
8661 <tt>new_value</tt> must be writable to the result output iterator. The
8662 ranges <tt>[first, last)</tt> and <tt>[result, result + (last -
8663 first))</tt> shall not overlap.</p>
8664
8665
8666 <p>25.2.5 Change p1 from</p>
8667
8668 <p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1). The
8669 type <tt>Size</tt> is convertible to an integral type (4.7.12.3).</p>
8670
8671 <p>to</p>
8672
8673 <p>-1- Requires: The expression <tt>value</tt> must be is writable to
8674 the output iterator. The type <tt>Size</tt> is convertible to an
8675 integral type (4.7.12.3).</p>
8676
8677 <p>25.2.7 Change p1 from</p>
8678
8679 <p>-1- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> (20.1.1).</p>
8680
8681 <p>to</p>
8682
8683 <p>
8684 -1- Requires: The value type of the iterator must be
8685 <tt>Assignable</tt> (23.1).
8686 </p>
8687
8688 <p><b>Rationale:</b></p>
8689 <p>
8690 The general idea of the proposed solution is to remove the faulty
8691 requires clauses and let the returns and effects clauses speak for
8692 themselves. That is, the returns clauses contain expressions that must
8693 be valid, and therefore already imply the correct requirements. In
8694 addition, a sentence is added at the beginning of chapter 25 saying
8695 that expressions given as conditions must evaluate to true or false in
8696 a boolean context. An alternative would be to say that the type of
8697 these condition expressions must be literally bool, but that would be
8698 imposing a greater restriction that what the standard currently says
8699 (which is convertible to bool).
8700 </p>
8701 <hr>
8702 <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>
8703 <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
8704 library function <tt>strcmp()</tt> with the function pointer adapter
8705 <tt>ptr_fun()</tt>. But since it's unspecified whether the C library
8706 functions have <tt>extern "C"</tt> or <tt>extern
8707 "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
8708 function pointers with different the language linkage specifications
8709 (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
8710 well-formed is unspecified.
8711 </p>
8712 <p><b>Proposed resolution:</b></p>
8713 <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>
8714 <blockquote>
8715   <p>[<i>Example:</i></p>
8716   <pre>    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
8717   </pre>
8718   <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
8719 </blockquote>
8720
8721
8722 <p>to:</p>
8723 <blockquote>
8724   <p>[<i>Example:</i></p>
8725   <pre>    int compare(const char*, const char*);
8726     replace_if(v.begin(), v.end(),
8727                not1(bind2nd(ptr_fun(compare), "abc")), "def");
8728   </pre>
8729   <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
8730 </blockquote>
8731
8732 <p>Also, remove footnote 215 in that same paragraph.</p>
8733
8734 <p><i>[Copenhagen: Minor change in the proposed resolution.  Since this
8735 issue deals in part with C and C++ linkage, it was believed to be too
8736 confusing for the strings in the example to be "C" and "C++".
8737 ]</i></p>
8738
8739 <p><i>[Redmond: More minor changes.  Got rid of the footnote (which
8740 seems to make a sweeping normative requirement, even though footnotes
8741 aren't normative), and changed the sentence after the footnote so that
8742 it corresponds to the new code fragment.]</i></p>
8743
8744 <hr>
8745 <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>
8746 <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
8747 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:
8748 </p>
8749
8750 <p>... If that function returns a null pointer, calls
8751 <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
8752 </p>
8753
8754 <p>The parenthetical note doesn't apply since the ctors cannot throw an
8755 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
8756 that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
8757 </p>
8758 <p><b>Proposed resolution:</b></p>
8759 <p>
8760 Strike the parenthetical note from the Effects clause in each of the
8761 paragraphs mentioned above.
8762 </p>
8763 <hr>
8764 <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>
8765 <p>
8766 The &lt;cstdlib&gt; header file contains prototypes for bsearch and
8767 qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
8768 prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
8769 require the typedef size_t. Yet size_t is not listed in the
8770 &lt;cstdlib&gt; synopsis table 78 in section 25.4.
8771 </p>
8772 <p><b>Proposed resolution:</b></p>
8773 <p>
8774 Add the type size_t to Table 78 (section 25.4) and add
8775 the type size_t &lt;cstdlib&gt; to Table 97 (section C.2).
8776 </p>
8777 <p><b>Rationale:</b></p>
8778 <p>Since size_t is in &lt;stdlib.h&gt;, it must also be in &lt;cstdlib&gt;.</p>
8779 <hr>
8780 <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>
8781 <p>
8782 ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
8783 of macros defined in &lt;errno.h&gt; is adjusted to include a new
8784 macro, EILSEQ"
8785 </p>
8786
8787 <p>
8788 ISO/IEC 14882:1998(E) section 19.3 does not refer
8789 to the above amendment.
8790 </p>
8791
8792 <p><b>Proposed resolution:</b></p>
8793 <p>
8794 Update Table 26 (section 19.3) "Header  &lt;cerrno&gt; synopsis"
8795 and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
8796 </p>
8797 <hr>
8798 <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>
8799 <p>
8800 The standard library contains four algorithms that compute set
8801 operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
8802 <tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>.  Each
8803 of these algorithms takes two sorted ranges as inputs, and writes the
8804 output of the appropriate set operation to an output range.  The elements
8805 in the output range are sorted.
8806 </p>
8807
8808 <p>
8809 The ordinary mathematical definitions are generalized so that they
8810 apply to ranges containing multiple copies of a given element.  Two
8811 elements are considered to be "the same" if, according to an
8812 ordering relation provided by the user, neither one is less than the
8813 other.  So, for example, if one input range contains five copies of an
8814 element and another contains three, the output range of <tt>set_union</tt>
8815 will contain five copies, the output range of
8816 <tt>set_intersection</tt> will contain three, the output range of
8817 <tt>set_difference</tt> will contain two, and the output range of
8818 <tt>set_symmetric_difference</tt> will contain two.
8819 </p>
8820
8821 <p>
8822 Because two elements can be "the same" for the purposes
8823 of these set algorithms, without being identical in other respects
8824 (consider, for example, strings under case-insensitive comparison),
8825 this raises a number of unanswered questions:
8826 </p>
8827
8828 <ul>
8829 <li>If we're copying an element that's present in both of the
8830 input ranges, which one do we copy it from?</li>
8831 <li>If there are <i>n</i> copies of an element in the relevant
8832 input range, and the output range will contain fewer copies (say
8833 <i>m</i>) which ones do we choose?  The first <i>m</i>, or the last
8834 <i>m</i>, or something else?</li>
8835 <li>Are these operations stable?  That is, does a run of equivalent
8836 elements appear in the output range in the same order as as it
8837 appeared in the input range(s)?</li>
8838 </ul>
8839
8840 <p>
8841 The standard should either answer these questions, or explicitly
8842 say that the answers are unspecified.  I prefer the former option,
8843 since, as far as I know, all existing implementations behave the
8844 same way.
8845 </p>
8846
8847 <p><b>Proposed resolution:</b></p>
8848
8849 <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>
8850 <blockquote>
8851 If [first1, last1) contains <i>m</i> elements that are equivalent to
8852 each other and [first2, last2) contains <i>n</i> elements that are
8853 equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
8854 will be copied to the output range: all <i>m</i> of these elements
8855 from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
8856 [first2, last2), in that order.
8857 </blockquote>
8858
8859 <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>
8860 <blockquote>
8861 If [first1, last1) contains <i>m</i> elements that are equivalent to each
8862 other and [first2, last2) contains <i>n</i> elements that are
8863 equivalent to them, the first min(<i>m</i>, <i>n</i>) of those
8864 elements from [first1, last1) are copied to the output range.
8865 </blockquote>
8866
8867 <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>
8868 paragraph 4:</p>
8869 <blockquote>
8870 If [first1, last1) contains <i>m</i> elements that are equivalent to each
8871 other and [first2, last2) contains <i>n</i> elements that are
8872 equivalent to them, the last max(<i>m-n</i>, 0) elements from
8873 [first1, last1) are copied to the output range.
8874 </blockquote>
8875
8876 <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>
8877 paragraph 4:</p>
8878 <blockquote>
8879 If [first1, last1) contains <i>m</i> elements that are equivalent to
8880 each other and [first2, last2) contains <i>n</i> elements that are
8881 equivalent to them, then |<i>m - n</i>| of those elements will be
8882 copied to the output range: the last <i>m - n</i> of these elements
8883 from [first1, last1) if <i>m</i> &gt; <i>n</i>, and the last <i>n -
8884 m</i> of these elements from [first2, last2) if <i>m</i> &lt; <i>n</i>.
8885 </blockquote>
8886
8887 <p><i>[Santa Cruz: it's believed that this language is clearer than
8888   what's in the Standard.  However, it's also believed that the
8889   Standard may already make these guarantees (although not quite in
8890   these words).  Bill and Howard will check and see whether they think
8891   that some or all of these changes may be redundant.  If so, we may
8892   close this issue as NAD.]</i></p>
8893
8894 <p><b>Rationale:</b></p>
8895 <p>For simple cases, these descriptions are equivalent to what's
8896   already in the Standard.  For more complicated cases, they describe
8897   the behavior of existing implementations.</p>
8898 <hr>
8899 <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>
8900 <p>The Effects clause of the member function <tt>copyfmt()</tt> in
8901 27.4.4.2, p15 doesn't consider the case where the left-hand side
8902 argument is identical to the argument on the right-hand side, that is
8903 <tt>(this == &amp;rhs)</tt>.  If the two arguments are identical there
8904 is no need to copy any of the data members or call any callbacks
8905 registered with <tt>register_callback()</tt>.  Also, as Howard Hinnant
8906 points out in message c++std-lib-8149 it appears to be incorrect to
8907 allow the object to fire <tt>erase_event</tt> followed by
8908 <tt>copyfmt_event</tt> since the callback handling the latter event
8909 may inadvertently attempt to access memory freed by the former.
8910 </p>
8911 <p><b>Proposed resolution:</b></p>
8912 <p>Change the Effects clause in 27.4.4.2, p15 from</p>
8913
8914 <blockquote>
8915 <b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
8916 the corresponding member objects of <tt>rhs</tt>, except that...
8917 </blockquote>
8918
8919 <p>to</p>
8920
8921 <blockquote>
8922 <b>-15- Effects:</b>If <tt>(this == &amp;rhs)</tt> does nothing. Otherwise
8923 assigns to the member objects of <tt>*this</tt> the corresponding member
8924 objects of <tt>rhs</tt>, except that...
8925 </blockquote>
8926 <hr>
8927 <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>
8928 <p>
8929 Table 80 lists the contents of the &lt;cmath&gt; header.  It does not
8930 list <tt>abs()</tt>.  However, 26.5, paragraph 6, which lists added
8931 signatures present in &lt;cmath&gt;, does say that several overloads
8932 of <tt>abs()</tt> should be defined in &lt;cmath&gt;.
8933 </p>
8934 <p><b>Proposed resolution:</b></p>
8935 <p>
8936 Add <tt>abs</tt> to Table 80.  Also, remove the parenthetical list
8937 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>,
8938 paragraph 1.
8939 </p>
8940
8941 <p><i>[Copenhagen: Modified proposed resolution so that it also gets
8942 rid of that vestigial list of functions in paragraph 1.]</i></p>
8943
8944 <p><b>Rationale:</b></p>
8945 <p>All this DR does is fix a typo; it's uncontroversial.  A
8946 separate question is whether we're doing the right thing in
8947 putting some overloads in &lt;cmath&gt; that we aren't also
8948 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>
8949 <hr>
8950 <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>
8951 <p>The class templates <tt>const_mem_fun_t</tt> in 20.3.8, p8 and
8952 <tt>const_mem_fun1_t</tt>
8953 in 20.3.8, p9 derive from <tt>unary_function&lt;T*, S&gt;</tt>, and
8954 <tt>binary_function&lt;T*,
8955 A, S&gt;</tt>, respectively. Consequently, their <tt>argument_type</tt>, and
8956 <tt>first_argument_type</tt>
8957 members, respectively, are both defined to be <tt>T*</tt> (non-const).
8958 However, their function call member operator takes a <tt>const T*</tt>
8959 argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
8960 T*</tt> instead, so that one can easily refer to it in generic code. The
8961 example below derived from existing code fails to compile due to the
8962 discrepancy:
8963 </p>
8964
8965 <p><tt>template &lt;class T&gt;</tt>
8966 <br><tt>void foo (typename T::argument_type arg)&nbsp;&nbsp; // #1</tt>
8967 <br><tt>{</tt>
8968 <br><tt>&nbsp;&nbsp;&nbsp; typename T::result_type (T::*pf) (typename
8969 T::argument_type)
8970 const =&nbsp;&nbsp; // #2</tt>
8971 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;T::operator();</tt>
8972 <br><tt>}</tt>
8973 </p>
8974
8975 <p><tt>struct X { /* ... */ };</tt></p>
8976
8977 <p><tt>int main ()</tt>
8978 <br><tt>{</tt>
8979 <br><tt>&nbsp;&nbsp;&nbsp; const X x;</tt>
8980 <br><tt>&nbsp;&nbsp;&nbsp; foo&lt;std::const_mem_fun_t&lt;void, X&gt;
8981 &gt;(&amp;x);&nbsp;&nbsp;
8982 // #3</tt>
8983 <br><tt>}</tt>
8984 </p>
8985
8986 <p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
8987 <br>#2 the type of the pointer is incompatible with the type of the member
8988 function
8989 <br>#3 the address of a constant being passed to a function taking a non-const
8990 <tt>X*</tt>
8991 </p>
8992 <p><b>Proposed resolution:</b></p>
8993 <p>Replace the top portion of the definition of the class template
8994 const_mem_fun_t in 20.3.8, p8
8995 </p>
8996 <p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
8997 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
8998 unary_function&lt;T*, S&gt; {</tt>
8999 </p>
9000 <p>with</p>
9001 <p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
9002 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9003 unary_function&lt;<b>const</b> T*, S&gt; {</tt>
9004 </p>
9005 <p>Also replace the top portion of the definition of the class template
9006 const_mem_fun1_t in 20.3.8, p9</p>
9007 <p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
9008 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9009 binary_function&lt;T*, A, S&gt; {</tt>
9010 </p>
9011 <p>with</p>
9012 <p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
9013 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9014 binary_function&lt;<b>const</b> T*, A, S&gt; {</tt>
9015 </p>
9016 <p><b>Rationale:</b></p>
9017 <p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
9018 and the argument type itself, are not the same.</p>
9019 <hr>
9020 <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>
9021 <p>
9022 The default behavior of <tt>operator delete[]</tt> described in 18.4.1.2, p12 -
9023 namely that for non-null value of <i>ptr</i>, the operator reclaims storage
9024 allocated by the earlier call to the default <tt>operator new[]</tt> - is not
9025 correct in all cases. Since the specified <tt>operator new[]</tt> default
9026 behavior is to call <tt>operator new</tt> (18.4.1.2, p4, p8), which can be
9027 replaced, along with <tt>operator delete</tt>, by the user, to implement their
9028 own memory management, the specified default behavior of<tt> operator
9029 delete[]</tt> must be to call <tt>operator delete</tt>.
9030 </p>
9031 <p><b>Proposed resolution:</b></p>
9032 <p>Change 18.4.1.2, p12 from</p>
9033 <blockquote>
9034 <b>-12-</b> <b>Default behavior:</b>
9035 <ul>
9036 <li>
9037 For a null value of <i><tt>ptr</tt></i> , does nothing.
9038 </li>
9039 <li>
9040 Any other value of <i><tt>ptr</tt></i> shall be a value returned
9041 earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
9042 [Footnote: The value must not have been invalidated by an intervening
9043 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>).
9044 --- end footnote]
9045 For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
9046 allocated by the earlier call to the default <tt>operator new[]</tt>.
9047 </li>
9048 </ul>
9049 </blockquote>
9050
9051 <p>to</p>
9052
9053 <blockquote>
9054 <b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
9055 delete(</tt><i>ptr</i>)
9056 or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
9057 </blockquote>
9058 <p>and expunge paragraph 13.</p>
9059 <hr>
9060 <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>
9061 <p>
9062 The "Effects" clause for list::merge() (23.2.2.4, p23)
9063 appears to be incomplete: it doesn't cover the case where the argument
9064 list is identical to *this (i.e., this == &amp;x). The requirement in the
9065 note in p24 (below) is that x be empty after the merge which is surely
9066 unintended in this case.
9067 </p>
9068 <p><b>Proposed resolution:</b></p>
9069 <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>
9070 <blockquote>
9071 <p>
9072 23 Effects: if (&amp;x == this) does nothing; otherwise, merges the two
9073 sorted ranges [begin(), end()) and [x.begin(), x.end()).  The result
9074 is a range in which the elements will be sorted in non-decreasing
9075 order according to the ordering defined by comp; that is, for every
9076 iterator i in the range other than the first, the condition comp(*i,
9077 *(i - 1)) will be false.
9078 </p>
9079
9080 <p>
9081 24 Notes: Stable: if (&amp;x != this), then for equivalent elements in the
9082 two original ranges, the elements from the original range [begin(),
9083 end()) always precede the elements from the original range [x.begin(),
9084 x.end()).  If (&amp;x != this) the range [x.begin(), x.end()) is empty
9085 after the merge.
9086 </p>
9087
9088 <p>
9089 25 Complexity: At most size() + x.size() - 1 applications of comp if
9090 (&amp;x !  = this); otherwise, no applications of comp are performed.  If
9091 an exception is thrown other than by a comparison there are no
9092 effects.
9093 </p>
9094
9095 </blockquote>
9096
9097 <p><i>[Copenhagen: The original proposed resolution did not fix all of
9098 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
9099 paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
9100 Changing p23, without changing the other two, appears to introduce
9101 contradictions.  Additionally, "merges the argument list into the
9102 list" is excessively vague.]</i></p>
9103
9104 <p><i>[Post-Curaçao: Robert Klarer provided new wording.]</i></p>
9105
9106 <hr>
9107 <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>
9108 <p>
9109 The effects clause for the basic_string template ctor in 21.3.1, p15
9110 leaves out the third argument of type Allocator. I believe this to be
9111 a mistake.
9112 </p>
9113 <p><b>Proposed resolution:</b></p>
9114 <p>Replace</p>
9115
9116 <blockquote>
9117     <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
9118     type, equivalent to</p>
9119
9120     <blockquote><tt>basic_string(static_cast&lt;size_type&gt;(begin),
9121     static_cast&lt;value_type&gt;(end))</tt></blockquote>
9122 </blockquote>
9123
9124 <p>with</p>
9125
9126 <blockquote>
9127     <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
9128     type, equivalent to</p>
9129
9130     <blockquote><tt>basic_string(static_cast&lt;size_type&gt;(begin),
9131     static_cast&lt;value_type&gt;(end), <b>a</b>)</tt></blockquote>
9132 </blockquote>
9133 <hr>
9134 <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>
9135 <p>
9136 In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
9137 "Extracts up to <i>N</i> (single-byte) characters from
9138 <i>is</i>.", where <i>is</i> is a stream of type
9139 <tt>basic_istream&lt;charT, traits&gt;</tt>.
9140 </p>
9141
9142 <p>
9143 The standard does not say what it means to extract single byte
9144 characters from a stream whose character type, <tt>charT</tt>, is in
9145 general not a single-byte character type.  Existing implementations
9146 differ.
9147 </p>
9148
9149 <p>
9150 A reasonable solution will probably involve <tt>widen()</tt> and/or
9151 <tt>narrow()</tt>, since they are the supplied mechanism for
9152 converting a single character between <tt>char</tt> and
9153 arbitrary <tt>charT</tt>.
9154 </p>
9155
9156 <p>Narrowing the input characters is not the same as widening the
9157 literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
9158 locales in which more than one wide character maps to the narrow
9159 character <tt>'0'</tt>.  Narrowing means that alternate
9160 representations may be used for bitset input, widening means that
9161 they may not be.</p>
9162
9163 <p>Note that for numeric input, <tt>num_get&lt;&gt;</tt>
9164 (22.2.2.1.2/8) compares input characters to widened version of narrow
9165 character literals.</p>
9166
9167 <p>From Pete Becker, in c++std-lib-8224:</p>
9168 <blockquote>
9169 <p>
9170 Different writing systems can have different representations for the
9171 digits that represent 0 and 1. For example, in the Unicode representation
9172 of the Devanagari script (used in many of the Indic languages) the digit 0
9173 is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
9174 into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
9175 0x0031 for for the Latin representations of '0' and '1', as well as code
9176 points for the same numeric values in several other scripts (Tamil has no
9177 character for 0, but does have the digits 1-9), and any of these values
9178 would also be narrowed to '0' and '1'.
9179 </p>
9180
9181 <p>...</p>
9182
9183 <p>
9184 It's fairly common to intermix both native and Latin
9185 representations of numbers in a document. So I think the rule has to be
9186 that if a wide character represents a digit whose value is 0 then the bit
9187 should be cleared; if it represents a digit whose value is 1 then the bit
9188 should be set; otherwise throw an exception. So in a Devanagari locale,
9189 both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
9190 would set it. Widen can't do that. It would pick one of those two values,
9191 and exclude the other one.
9192 </p>
9193
9194 </blockquote>
9195
9196 <p>From Jens Maurer, in c++std-lib-8233:</p>
9197
9198 <blockquote>
9199 <p>
9200 Whatever we decide, I would find it most surprising if
9201 bitset conversion worked differently from int conversion
9202 with regard to alternate local representations of
9203 numbers.
9204 </p>
9205
9206 <p>Thus, I think the options are:</p>
9207 <ul>
9208  <li> Have a new defect issue for 22.2.2.1.2/8 so that it will
9209 require the use of narrow().</li>
9210
9211  <li> Have a defect issue for bitset() which describes clearly
9212 that widen() is to be used.</li>
9213 </ul>
9214 </blockquote>
9215 <p><b>Proposed resolution:</b></p>
9216
9217     <p>Replace the first two sentences of paragraph 5 with:</p>
9218
9219     <blockquote>
9220     Extracts up to <i>N</i> characters from <i>is</i>. Stores these
9221     characters in a temporary object <i>str</i> of type
9222     <tt>basic_string&lt;charT, traits&gt;</tt>, then evaluates the
9223     expression <tt><i>x</i> = bitset&lt;N&gt;(<i>str</i>)</tt>.
9224     </blockquote>
9225
9226     <p>Replace the third bullet item in paragraph 5 with:</p>
9227     <ul><li>
9228     the next input character is neither <tt><i>is</i>.widen(0)</tt>
9229     nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
9230     is not extracted).
9231     </li></ul>
9232
9233 <p><b>Rationale:</b></p>
9234 <p>Input for <tt>bitset</tt> should work the same way as numeric
9235 input.  Using <tt>widen</tt> does mean that alternative digit
9236 representations will not be recognized, but this was a known
9237 consequence of the design choice.</p>
9238 <hr>
9239 <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>
9240 <p>22.2.1.5/3 introduces codecvt in part with:</p>
9241
9242 <blockquote>
9243   codecvt&lt;wchar_t,char,mbstate_t&gt; converts between the native
9244   character sets for tiny and wide characters. Instantiations on
9245   mbstate_t perform conversion between encodings known to the library
9246   implementor.
9247 </blockquote>
9248
9249 <p>But 22.2.1.5.2/10 describes do_length in part with:</p>
9250
9251 <blockquote>
9252   ... codecvt&lt;wchar_t, char, mbstate_t&gt; ... return(s) the lesser of max and
9253   (from_end-from).
9254 </blockquote>
9255
9256 <p>
9257 The semantics of do_in and do_length are linked.  What one does must
9258 be consistent with what the other does.  22.2.1.5/3 leads me to
9259 believe that the vendor is allowed to choose the algorithm that
9260 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in performs so that it makes
9261 his customers happy on a given platform.  But 22.2.1.5.2/10 explicitly
9262 says what codecvt&lt;wchar_t,char,mbstate_t&gt;::do_length must
9263 return.  And thus indirectly specifies the algorithm that
9264 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in must perform.  I believe
9265 that this is not what was intended and is a defect.
9266 </p>
9267
9268 <p>Discussion from the -lib reflector:
9269
9270 <br>This proposal would have the effect of making the semantics of
9271 all of the virtual functions in <tt>codecvt&lt;wchar_t, char,
9272 mbstate_t&gt;</tt> implementation specified.  Is that what we want, or
9273 do we want to mandate specific behavior for the base class virtuals
9274 and leave the implementation specified behavior for the codecvt_byname
9275 derived class?  The tradeoff is that former allows implementors to
9276 write a base class that actually does something useful, while the
9277 latter gives users a way to get known and specified---albeit
9278 useless---behavior, and is consistent with the way the standard
9279 handles other facets.  It is not clear what the original intention
9280 was.</p>
9281
9282 <p>
9283 Nathan has suggest a compromise: a character that is a widened version
9284 of the characters in the basic execution character set must be
9285 converted to a one-byte sequence, but there is no such requirement
9286 for characters that are not part of the basic execution character set.
9287 </p>
9288 <p><b>Proposed resolution:</b></p>
9289 <p>
9290 Change 22.2.1.5.2/5 from:
9291 </p>
9292 <p>
9293 The instantiations required in Table 51 (lib.locale.category), namely
9294 codecvt&lt;wchar_t,char,mbstate_t&gt; and
9295 codecvt&lt;char,char,mbstate_t&gt;, store no characters. Stores no more
9296 than (to_limit-to) destination elements. It always leaves the to_next
9297 pointer pointing one beyond the last element successfully stored.
9298 </p>
9299 <p>
9300 to:
9301 </p>
9302 <p>
9303 Stores no more than (to_limit-to) destination elements, and leaves the
9304 to_next pointer pointing one beyond the last element successfully
9305 stored.  codecvt&lt;char,char,mbstate_t&gt; stores no characters.
9306 </p>
9307
9308 <p>Change 22.2.1.5.2/10 from:</p>
9309
9310 <blockquote>
9311 -10- Returns: (from_next-from) where from_next is the largest value in
9312 the range [from,from_end] such that the sequence of values in the
9313 range [from,from_next) represents max or fewer valid complete
9314 characters of type internT. The instantiations required in Table 51
9315 (21.1.1.1.1), namely codecvt&lt;wchar_t, char, mbstate_t&gt; and
9316 codecvt&lt;char, char, mbstate_t&gt;, return the lesser of max and
9317 (from_end-from).
9318 </blockquote>
9319
9320 <p>to:</p>
9321
9322 <blockquote>
9323 -10- Returns: (from_next-from) where from_next is the largest value in
9324 the range [from,from_end] such that the sequence of values in the range
9325 [from,from_next) represents max or fewer valid complete characters of
9326 type internT. The instantiation codecvt&lt;char, char, mbstate_t&gt; returns
9327 the lesser of max and (from_end-from).
9328 </blockquote>
9329
9330 <p><i>[Redmond: Nathan suggested an alternative resolution: same as
9331 above, but require that, in the default encoding, a character from the
9332 basic execution character set would map to a single external
9333 character.  The straw poll was 8-1 in favor of the proposed
9334 resolution.]</i></p>
9335
9336 <p><b>Rationale:</b></p>
9337 <p>The default encoding should be whatever users of a given platform
9338 would expect to be the most natural.  This varies from platform to
9339 platform.  In many cases there is a preexisting C library, and users
9340 would expect the default encoding to be whatever C uses in the default
9341 "C" locale.  We could impose a guarantee like the one Nathan suggested
9342 (a character from the basic execution character set must map to a
9343 single external character), but this would rule out important
9344 encodings that are in common use: it would rule out JIS, for
9345 example, and it would rule out a fixed-width encoding of UCS-4.</p>
9346
9347 <p><i>[Curaçao: fixed rationale typo at the request of Ichiro Koshida;
9348 "shift-JIS" changed to "JIS".]</i></p>
9349
9350 <hr>
9351 <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>
9352 <p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
9353
9354 <p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
9355 accepts a restricted set of <i>type</i> arguments in this
9356 International Standard. <i>type</i> shall be a POD structure or a POD
9357 union (clause 9). The result of applying the offsetof macro to a field
9358 that is a static data member or a function member is
9359 undefined."</p>
9360
9361 <p>For the POD requirement, it doesn't say "no diagnostic
9362 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.
9363 It's not clear whether this requirement was intended.  While it's
9364 possible to provide such a diagnostic, the extra complication doesn't
9365 seem to add any value.
9366 </p>
9367 <p><b>Proposed resolution:</b></p>
9368 <p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
9369 structure or a POD union the results are undefined."</p>
9370
9371 <p><i>[Copenhagen: straw poll was 7-4 in favor.  It was generally
9372 agreed that requiring a diagnostic was inadvertent, but some LWG
9373 members thought that diagnostics should be required whenever
9374 possible.]</i></p>
9375
9376 <hr>
9377 <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>
9378
9379 <p>From reflector message c++std-lib-8330.  See also lib-8317.</p>
9380
9381 <p>
9382 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>
9383 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.
9384 23.2.3.3/1, for example, says:
9385 </p>
9386
9387 <blockquote>
9388 -1- Any sequence supporting operations back(), push_back() and pop_back()
9389 can be used to instantiate stack. In particular, vector (lib.vector), list
9390 (lib.list) and deque (lib.deque) can be used.
9391 </blockquote>
9392
9393 <p>But this is false: vector&lt;bool&gt; can not be used, because the
9394 container adaptors return a T&amp; rather than using the underlying
9395 container's reference type.</p>
9396
9397 <p>This is a contradiction that can be fixed by:</p>
9398
9399 <ol>
9400 <li>Modifying these paragraphs to say that vector&lt;bool&gt;
9401     is an exception.</li>
9402 <li>Removing the vector&lt;bool&gt; specialization.</li>
9403 <li>Changing the return types of stack and priority_queue to use
9404     reference typedef's.</li>
9405 </ol>
9406
9407 <p>
9408 I propose 3.  This does not preclude option 2 if we choose to do it
9409 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
9410 3 offers a small step towards support for proxied containers.  This
9411 small step fixes a current contradiction, is easy for vendors to
9412 implement, is already implemented in at least one popular lib, and
9413 does not break any code.
9414 </p>
9415
9416 <p><b>Proposed resolution:</b></p>
9417 <p>Summary: Add reference and const_reference typedefs to queue,
9418 priority_queue and stack.  Change return types of "value_type&amp;" to
9419 "reference".  Change return types of "const value_type&amp;" to
9420 "const_reference".  Details:</p>
9421
9422 <p>Change 23.2.3.1/1 from:</p>
9423
9424 <pre>  namespace std {
9425     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9426     class queue {
9427     public:
9428       typedef typename Container::value_type            value_type;
9429       typedef typename Container::size_type             size_type;
9430       typedef          Container                        container_type;
9431     protected:
9432       Container c;
9433
9434     public:
9435       explicit queue(const Container&amp; = Container());
9436
9437       bool      empty() const             { return c.empty(); }
9438       size_type size()  const             { return c.size(); }
9439       value_type&amp;       front()           { return c.front(); }
9440       const value_type&amp; front() const     { return c.front(); }
9441       value_type&amp;       back()            { return c.back(); }
9442       const value_type&amp; back() const      { return c.back(); }
9443       void push(const value_type&amp; x)      { c.push_back(x); }
9444       void pop()                          { c.pop_front(); }
9445     };
9446 </pre>
9447
9448 <p>to:</p>
9449
9450 <pre>  namespace std {
9451     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9452     class queue {
9453     public:
9454       typedef typename Container::value_type            value_type;
9455       typedef typename Container::reference             reference;
9456       typedef typename Container::const_reference       const_reference;
9457       typedef typename Container::value_type            value_type;
9458       typedef typename Container::size_type             size_type;
9459       typedef          Container                        container_type;
9460     protected:
9461       Container c;
9462
9463     public:
9464       explicit queue(const Container&amp; = Container());
9465
9466       bool      empty() const             { return c.empty(); }
9467       size_type size()  const             { return c.size(); }
9468       reference         front()           { return c.front(); }
9469       const_reference   front() const     { return c.front(); }
9470       reference         back()            { return c.back(); }
9471       const_reference   back() const      { return c.back(); }
9472       void push(const value_type&amp; x)      { c.push_back(x); }
9473       void pop()                          { c.pop_front(); }
9474     };
9475 </pre>
9476
9477 <p>Change 23.2.3.2/1 from:</p>
9478
9479 <pre>  namespace std {
9480     template &lt;class T, class Container = vector&lt;T&gt;,
9481               class Compare = less&lt;typename Container::value_type&gt; &gt;
9482     class priority_queue {
9483     public:
9484       typedef typename Container::value_type            value_type;
9485       typedef typename Container::size_type             size_type;
9486       typedef          Container                        container_type;
9487     protected:
9488       Container c;
9489       Compare comp;
9490
9491     public:
9492       explicit priority_queue(const Compare&amp; x = Compare(),
9493                               const Container&amp; = Container());
9494       template &lt;class InputIterator&gt;
9495         priority_queue(InputIterator first, InputIterator last,
9496                        const Compare&amp; x = Compare(),
9497                        const Container&amp; = Container());
9498
9499       bool      empty() const       { return c.empty(); }
9500       size_type size()  const       { return c.size(); }
9501       const value_type&amp; top() const { return c.front(); }
9502       void push(const value_type&amp; x);
9503       void pop();
9504     };
9505                                   //  no equality is provided
9506   }
9507 </pre>
9508
9509 <p>to:</p>
9510
9511 <pre>  namespace std {
9512     template &lt;class T, class Container = vector&lt;T&gt;,
9513               class Compare = less&lt;typename Container::value_type&gt; &gt;
9514     class priority_queue {
9515     public:
9516       typedef typename Container::value_type            value_type;
9517       typedef typename Container::reference             reference;
9518       typedef typename Container::const_reference       const_reference;
9519       typedef typename Container::size_type             size_type;
9520       typedef          Container                        container_type;
9521     protected:
9522       Container c;
9523       Compare comp;
9524
9525     public:
9526       explicit priority_queue(const Compare&amp; x = Compare(),
9527                               const Container&amp; = Container());
9528       template &lt;class InputIterator&gt;
9529         priority_queue(InputIterator first, InputIterator last,
9530                        const Compare&amp; x = Compare(),
9531                        const Container&amp; = Container());
9532
9533       bool      empty() const       { return c.empty(); }
9534       size_type size()  const       { return c.size(); }
9535       const_reference   top() const { return c.front(); }
9536       void push(const value_type&amp; x);
9537       void pop();
9538     };
9539                                   //  no equality is provided
9540   }
9541 </pre>
9542
9543 <p>And change 23.2.3.3/1 from:</p>
9544
9545 <pre>  namespace std {
9546     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9547     class stack {
9548     public:
9549       typedef typename Container::value_type            value_type;
9550       typedef typename Container::size_type             size_type;
9551       typedef          Container                        container_type;
9552     protected:
9553       Container c;
9554
9555     public:
9556       explicit stack(const Container&amp; = Container());
9557
9558       bool      empty() const             { return c.empty(); }
9559       size_type size()  const             { return c.size(); }
9560       value_type&amp;       top()             { return c.back(); }
9561       const value_type&amp; top() const       { return c.back(); }
9562       void push(const value_type&amp; x)      { c.push_back(x); }
9563       void pop()                          { c.pop_back(); }
9564     };
9565
9566     template &lt;class T, class Container&gt;
9567       bool operator==(const stack&lt;T, Container&gt;&amp; x,
9568                       const stack&lt;T, Container&gt;&amp; y);
9569     template &lt;class T, class Container&gt;
9570       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
9571                       const stack&lt;T, Container&gt;&amp; y);
9572     template &lt;class T, class Container&gt;
9573       bool operator!=(const stack&lt;T, Container&gt;&amp; x,
9574                       const stack&lt;T, Container&gt;&amp; y);
9575     template &lt;class T, class Container&gt;
9576       bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
9577                       const stack&lt;T, Container&gt;&amp; y);
9578     template &lt;class T, class Container&gt;
9579       bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
9580                       const stack&lt;T, Container&gt;&amp; y);
9581     template &lt;class T, class Container&gt;
9582       bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
9583                       const stack&lt;T, Container&gt;&amp; y);
9584   }
9585 </pre>
9586
9587 <p>to:</p>
9588
9589 <pre>  namespace std {
9590     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9591     class stack {
9592     public:
9593       typedef typename Container::value_type            value_type;
9594       typedef typename Container::reference             reference;
9595       typedef typename Container::const_reference       const_reference;
9596       typedef typename Container::size_type             size_type;
9597       typedef          Container                        container_type;
9598     protected:
9599       Container c;
9600
9601     public:
9602       explicit stack(const Container&amp; = Container());
9603
9604       bool      empty() const             { return c.empty(); }
9605       size_type size()  const             { return c.size(); }
9606       reference         top()             { return c.back(); }
9607       const_reference   top() const       { return c.back(); }
9608       void push(const value_type&amp; x)      { c.push_back(x); }
9609       void pop()                          { c.pop_back(); }
9610     };
9611
9612     template &lt;class T, class Container&gt;
9613       bool operator==(const stack&lt;T, Container&gt;&amp; x,
9614                       const stack&lt;T, Container&gt;&amp; y);
9615     template &lt;class T, class Container&gt;
9616       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
9617                       const stack&lt;T, Container&gt;&amp; y);
9618     template &lt;class T, class Container&gt;
9619       bool operator!=(const stack&lt;T, Container&gt;&amp; x,
9620                       const stack&lt;T, Container&gt;&amp; y);
9621     template &lt;class T, class Container&gt;
9622       bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
9623                       const stack&lt;T, Container&gt;&amp; y);
9624     template &lt;class T, class Container&gt;
9625       bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
9626                       const stack&lt;T, Container&gt;&amp; y);
9627     template &lt;class T, class Container&gt;
9628       bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
9629                       const stack&lt;T, Container&gt;&amp; y);
9630   }
9631 </pre>
9632
9633 <p><i>[Copenhagen: This change was discussed before the IS was released
9634 and it was deliberately not adopted.  Nevertheless, the LWG believes
9635 (straw poll: 10-2) that it is a genuine defect.]</i></p>
9636
9637 <hr>
9638 <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>
9639 <p>
9640 Table 82 in section 27 mentions the header &lt;cstdlib&gt; for String
9641 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
9642 &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
9643 why these headers are mentioned in this context since they do not
9644 define any of the library entities described by the
9645 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
9646 are to be listed in the summary.
9647 </p>
9648 <p><b>Proposed resolution:</b></p>
9649 <p>Remove &lt;cstdlib&gt; and &lt;cwchar&gt; from
9650 Table 82.</p>
9651
9652 <p><i>[Copenhagen: changed the proposed resolution slightly.  The
9653 original proposed resolution also said to remove &lt;cstdio&gt; from
9654 Table 82.  However, &lt;cstdio&gt; is mentioned several times within
9655 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>
9656
9657 <hr>
9658 <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>
9659   <p>
9660   Exactly how should errno be declared in a conforming C++ header?
9661   </p>
9662
9663   <p>
9664   The C standard says in 7.1.4 that it is unspecified whether errno is a
9665   macro or an identifier with external linkage.  In some implementations
9666   it can be either, depending on compile-time options.  (E.g., on
9667   Solaris in multi-threading mode, errno is a macro that expands to a
9668   function call, but is an extern int otherwise.  "Unspecified" allows
9669   such variability.)
9670   </p>
9671
9672   <p>The C++ standard:</p>
9673   <ul>
9674   <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
9675   <li>17.4.3.1.3 footnote 166 says errno is reserved as an external
9676       name (true), and implies that it is an identifier.</li>
9677   <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
9678       on to say that the contents of of C++ &lt;errno.h&gt; are the
9679       same as in C, begging the question.</li>
9680   <li>C.2, table 95 lists errno as a macro, without comment.</li>
9681   </ul>
9682
9683   <p>I find no other references to errno.</p>
9684
9685   <p>We should either explicitly say that errno must be a macro, even
9686   though it need not be a macro in C, or else explicitly leave it
9687   unspecified.  We also need to say something about namespace std.
9688   A user who includes &lt;cerrno&gt; needs to know whether to write
9689   <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
9690   else &lt;cerrno&gt; is useless.</p>
9691
9692   <p>Two acceptable fixes:</p>
9693   <ul>
9694     <li><p>errno must be a macro. This is trivially satisfied by adding<br>
9695         &nbsp;&nbsp;#define errno (::std::errno)<br>
9696         to the headers if errno is not already a macro. You then always
9697         write errno without any scope qualification, and it always expands
9698         to a correct reference. Since it is always a macro, you know to
9699         avoid using errno as a local identifer.</p></li>
9700     <li><p>errno is in the global namespace. This fix is inferior, because
9701         ::errno is not guaranteed to be well-formed.</p></li>
9702   </ul>
9703
9704   <p><i>[
9705     This issue was first raised in 1999, but it slipped through
9706     the cracks.
9707   ]</i></p>
9708 <p><b>Proposed resolution:</b></p>
9709   <p>Change the Note in section 17.4.1.2p5 from</p>
9710
9711     <blockquote>
9712     Note: the names defined as macros in C include the following:
9713     assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
9714     </blockquote>
9715
9716   <p>to</p>
9717
9718     <blockquote>
9719     Note: the names defined as macros in C include the following:
9720     assert, offsetof, setjmp, va_arg, va_end, and va_start.
9721     </blockquote>
9722
9723   <p>In section 19.3, change paragraph 2 from</p>
9724
9725     <blockquote>
9726     The contents are the same as the Standard C library header
9727     &lt;errno.h&gt;.
9728     </blockquote>
9729
9730   <p>to</p>
9731
9732     <blockquote>
9733     The contents are the same as the Standard C library header
9734     &lt;errno.h&gt;, except that errno shall be defined as a macro.
9735     </blockquote>
9736 <p><b>Rationale:</b></p>
9737 <p>C++ must not leave it up to the implementation to decide whether or
9738 not a name is a macro; it must explicitly specify exactly which names
9739 are required to be macros.  The only one that really works is for it
9740 to be a macro.</p>
9741
9742 <p><i>[Curaçao: additional rationale added.]</i></p>
9743
9744 <hr>
9745 <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>
9746
9747 <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>
9748
9749 <pre>  // partial specializationss
9750   template&lt;class traits&gt;
9751     basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;( basic_ostream&lt;char,traits&gt;&amp;,
9752                                             const char * );
9753 </pre>
9754
9755 <p>Problems:</p>
9756 <ul>
9757 <li>Too many 's's at the end of "specializationss" </li>
9758 <li>This is an overload, not a partial specialization</li>
9759 </ul>
9760
9761 <p><b>Proposed resolution:</b></p>
9762 <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
9763 <i>// partial specializationss</i> comment.  Also remove the same
9764 comment (correctly spelled, but still incorrect) from the synopsis in
9765 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>.
9766 </p>
9767
9768 <p><i>[
9769 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
9770 comment in c++std-lib-8939.
9771 ]</i></p>
9772
9773 <hr>
9774 <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>
9775 <p>Table 27 in section 20 lists the header &lt;memory&gt; (only) for
9776 Memory (lib.memory) but neglects to mention the headers
9777 &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>
9778 <p><b>Proposed resolution:</b></p>
9779 <p>Add &lt;cstdlib&gt; and &lt;cstring&gt; to Table 27, in the same row
9780 as &lt;memory&gt;.</p>
9781 <hr>
9782 <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>
9783 <p>
9784 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
9785 list::unique as: "If the range (last - first) is not empty, exactly
9786 (last - first) -1 applications of the corresponding predicate,
9787 otherwise no applications of the predicate)".
9788 </p>
9789
9790 <p>
9791 "(last - first)" is not a range.
9792 </p>
9793 <p><b>Proposed resolution:</b></p>
9794 <p>
9795 Change the "range" from (last - first) to [first, last).
9796 </p>
9797 <hr>
9798 <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>
9799 <p>Table 69 says this about a_uniq.insert(t):</p>
9800
9801 <blockquote>
9802 inserts t if and only if there is no element in the container with key
9803 equivalent to the key of t. The bool component of the returned pair
9804 indicates whether the insertion takes place and the iterator component of the
9805 pair points to the element with key equivalent to the key of t.
9806 </blockquote>
9807
9808 <p>The description should be more specific about exactly how the bool component
9809 indicates whether the insertion takes place.</p>
9810 <p><b>Proposed resolution:</b></p>
9811 <p>Change the text in question to</p>
9812
9813 <blockquote>
9814 ...The bool component of the returned pair is true if and only if the insertion
9815 takes place...
9816 </blockquote>
9817 <hr>
9818 <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>
9819 <p>
9820 The localization section of the standard refers to specializations of
9821 the facet templates as instantiations even though the required facets
9822 are typically specialized rather than explicitly (or implicitly)
9823 instantiated. In the case of ctype&lt;char&gt; and
9824 ctype_byname&lt;char&gt; (and the wchar_t versions), these facets are
9825 actually required to be specialized. The terminology should be
9826 corrected to make it clear that the standard doesn't mandate explicit
9827 instantiation (the term specialization encompasses both explicit
9828 instantiations and specializations).
9829 </p>
9830 <p><b>Proposed resolution:</b></p>
9831 <p>
9832 In the following paragraphs, replace all occurrences of the word
9833 instantiation or instantiations with specialization or specializations,
9834 respectively:
9835 </p>
9836
9837 <blockquote>
9838 22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
9839 22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3,
9840 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
9841 Footnote 242.
9842 </blockquote>
9843
9844 <p>And change the text in 22.1.1.1.1, p4 from</p>
9845
9846 <blockquote>
9847     An implementation is required to provide those instantiations
9848     for facet templates identified as members of a category, and
9849     for those shown in Table 52:
9850 </blockquote>
9851
9852 <p>to</p>
9853
9854 <blockquote>
9855     An implementation is required to provide those specializations...
9856 </blockquote>
9857
9858 <p><i>[Nathan will review these changes, and will look for places where
9859 explicit specialization is necessary.]</i></p>
9860
9861 <p><b>Rationale:</b></p>
9862 <p>This is a simple matter of outdated language.  The language to
9863 describe templates was clarified during the standardization process,
9864 but the wording in clause 22 was never updated to reflect that
9865 change.</p>
9866 <hr>
9867 <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>
9868 <p>The definition of the numpunct_byname template contains the following
9869 comment:</p>
9870
9871 <pre>    namespace std {
9872         template &lt;class charT&gt;
9873         class numpunct_byname : public numpunct&lt;charT&gt; {
9874     // this class is specialized for char and wchar_t.
9875         ...
9876 </pre>
9877
9878 <p>There is no documentation of the specializations and it seems
9879 conceivable that an implementation will not explicitly specialize the
9880 template at all, but simply provide the primary template.</p>
9881 <p><b>Proposed resolution:</b></p>
9882 <p>Remove the comment from the text in 22.2.3.2 and from the proposed
9883 resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
9884 <hr>
9885 <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>
9886 <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
9887 behavior" elements describe "the semantics of a function definition
9888 provided by either the implementation or a C++ program."</p>
9889
9890 <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"
9891 elements describe "the preconditions for calling the function."</p>
9892
9893 <p>In the sections noted below, the current wording specifies
9894 "Required Behavior" for what are actually preconditions, and thus
9895 should be specified as "Requires".</p>
9896
9897 <p><b>Proposed resolution:</b></p>
9898
9899 <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>
9900 <blockquote>
9901   <p>Required behavior: accept a value of ptr that is null or that was
9902   returned by an earlier call ...</p>
9903 </blockquote>
9904 <p>to:</p>
9905 <blockquote>
9906   <p>Requires: the value of ptr is null or the value returned by an
9907   earlier call ...</p>
9908 </blockquote>
9909
9910 <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>
9911 <blockquote>
9912   <p>Required behavior: accept a value of ptr that is null or that was
9913   returned by an earlier call ...</p>
9914 </blockquote>
9915 <p>to:</p>
9916 <blockquote>
9917   <p>Requires: the value of ptr is null or the value returned by an
9918   earlier call ...</p>
9919 </blockquote>
9920
9921 <hr>
9922 <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>
9923 <p>
9924 Section 23.2.2.1, paragraphs 6-8 specify that list assign (both forms) have
9925 the "effects" of a call to erase followed by a call to insert.
9926 </p>
9927
9928 <p>
9929 I would like to document that implementers have the freedom to implement
9930 assign by other methods, as long as the end result is the same and the
9931 exception guarantee is as good or better than the basic guarantee.
9932 </p>
9933
9934 <p>
9935 The motivation for this is to use T's assignment operator to recycle
9936 existing nodes in the list instead of erasing them and reallocating
9937 them with new values.  It is also worth noting that, with careful
9938 coding, most common cases of assign (everything but assignment with
9939 true input iterators) can elevate the exception safety to strong if
9940 T's assignment has a nothrow guarantee (with no extra memory cost).
9941 Metrowerks does this.  However I do not propose that this subtlety be
9942 standardized.  It is a QoI issue.  </p>
9943
9944 <p>Existing practise:
9945 Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
9946 </p>
9947 <p><b>Proposed resolution:</b></p>
9948 <p>Change 23.2.2.1/7 from:</p>
9949
9950 <blockquote>
9951 <p>Effects:</p>
9952
9953 <pre>   erase(begin(), end());
9954    insert(begin(), first, last);
9955 </pre>
9956 </blockquote>
9957
9958 <p>to:</p>
9959
9960 <blockquote>
9961 <p>Effects: Replaces the contents of the list with the range [first, last).</p>
9962 </blockquote>
9963
9964 <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),
9965 add two new rows:</p>
9966 <pre>      a.assign(i,j)     void      pre: i,j are not iterators into a.
9967                                   Replaces elements in a with a copy
9968                                   of [i, j).
9969
9970       a.assign(n,t)     void      pre: t is not a reference into a.
9971                                   Replaces elements in a with n copies
9972                                   of t.
9973 </pre>
9974
9975 <p>Change 23.2.2.1/8 from:</p>
9976
9977 <blockquote>
9978 <p>Effects:</p>
9979 <pre>   erase(begin(), end());
9980    insert(begin(), n, t);
9981 </pre>
9982 </blockquote>
9983 <p>to:</p>
9984
9985 <blockquote>
9986 <p>Effects: Replaces the contents of the list with n copies of t.</p>
9987 </blockquote>
9988
9989 <p><i>[Redmond: Proposed resolution was changed slightly.  Previous
9990 version made explicit statement about exception safety, which wasn't
9991 consistent with the way exception safety is expressed elsewhere.
9992 Also, the change in the sequence requirements is new.  Without that
9993 change, the proposed resolution would have required that assignment of
9994 a subrange would have to work.  That too would have been
9995 overspecification; it would effectively mandate that assignment use a
9996 temporary.  Howard provided wording.
9997 ]</i></p>
9998
9999 <p><i>[Curaçao: Made editorial improvement in wording; changed
10000 "Replaces elements in a with copies of elements in [i, j)."
10001 with "Replaces the elements of a with a copy of [i, j)."
10002 Changes not deemed serious enough to requre rereview.]</i></p>
10003
10004 <hr>
10005 <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>
10006 <p>
10007 Section 22.2.2.1.2 at p7 states that "A length specifier is added to
10008 the conversion function, if needed, as indicated in Table 56."
10009 However, Table 56 uses the term "length modifier", not "length
10010 specifier".
10011 </p>
10012 <p><b>Proposed resolution:</b></p>
10013 <p>
10014 In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
10015 to be "A length modifier is added ..."
10016 </p>
10017 <p><b>Rationale:</b></p>
10018 <p>C uses the term "length modifier".  We should be consistent.</p>
10019 <hr>
10020 <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>
10021 <p>
10022 It's widely assumed that, if X is a container,
10023 iterator_traits&lt;X::iterator&gt;::value_type and
10024 iterator_traits&lt;X::const_iterator&gt;::value_type should both be
10025 X::value_type.  However, this is nowhere stated.  The language in
10026 Table 65 is not precise about the iterators' value types (it predates
10027 iterator_traits), and could even be interpreted as saying that
10028 iterator_traits&lt;X::const_iterator&gt;::value_type should be "const
10029 X::value_type".
10030 </p>
10031
10032 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a>.</p>
10033 <p><b>Proposed resolution:</b></p>
10034 <p>In Table 65 ("Container Requirements"), change the return type for
10035 X::iterator to "iterator type whose value type is T".  Change the
10036 return type for X::const_iterator to "constant iterator type whose
10037 value type is T".</p>
10038 <p><b>Rationale:</b></p>
10039 <p>
10040 This belongs as a container requirement, rather than an iterator
10041 requirement, because the whole notion of iterator/const_iterator
10042 pairs is specific to containers' iterator.
10043 </p>
10044 <p>
10045 It is existing practice that (for example)
10046 iterator_traits&lt;list&lt;int&gt;::const_iterator&gt;::value_type
10047 is "int", rather than "const int".  This is consistent with
10048 the way that const pointers are handled: the standard already
10049 requires that iterator_traits&lt;const int*&gt;::value_type is int.
10050 </p>
10051 <hr>
10052 <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>
10053
10054 <p>Table 73 suggests that output iterators have value types.  It
10055 requires the expression "*a = t".  Additionally, although Table 73
10056 never lists "a = t" or "X(a) = t" in the "expressions" column, it
10057 contains a note saying that "a = t" and "X(a) = t" have equivalent
10058 (but nowhere specified!) semantics.</p>
10059
10060 <p>According to 24.1/9, t is supposed to be "a value of value type
10061 T":</p>
10062
10063     <blockquote>
10064     In the following sections, a and b denote values of X, n denotes a
10065     value of the difference type Distance, u, tmp, and m denote
10066     identifiers, r denotes a value of X&amp;, t denotes a value of
10067     value type T.
10068     </blockquote>
10069
10070 <p>Two other parts of the standard that are relevant to whether
10071 output iterators have value types:</p>
10072
10073 <ul>
10074     <li>24.1/1 says "All iterators i support the expression *i,
10075     resulting in a value of some class, enumeration, or built-in type
10076     T, called the value type of the iterator".</li>
10077
10078     <li>
10079     24.3.1/1, which says "In the case of an output iterator, the types
10080     iterator_traits&lt;Iterator&gt;::difference_type
10081     iterator_traits&lt;Iterator&gt;::value_type are both defined as void."
10082     </li>
10083 </ul>
10084
10085 <p>The first of these passages suggests that "*i" is supposed to
10086 return a useful value, which contradicts the note in 24.1.2/2 saying
10087 that the only valid use of "*i" for output iterators is in an
10088 expression of the form "*i = t".  The second of these passages appears
10089 to contradict Table 73, because it suggests that "*i"'s return value
10090 should be void.  The second passage is also broken in the case of a an
10091 iterator type, like non-const pointers, that satisfies both the output
10092 iterator requirements and the forward iterator requirements.</p>
10093
10094 <p>What should the standard say about <tt>*i</tt>'s return value when
10095 i is an output iterator, and what should it say about that t is in the
10096 expression "*i = t"?  Finally, should the standard say anything about
10097 output iterators' pointer and reference types?</p>
10098
10099 <p><b>Proposed resolution:</b></p>
10100 <p>24.1 p1, change</p>
10101
10102 <blockquote>
10103 <p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
10104 in a value of some class, enumeration, or built-in type <tt>T</tt>,
10105 called the value type of the iterator.</p>
10106 </blockquote>
10107
10108 <p>to</p>
10109
10110 <blockquote>
10111 <p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
10112 resulting in a value of some class, enumeration, or built-in type
10113 <tt>T</tt>, called the value type of the iterator. All output
10114 iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
10115 value of some type that is in the set of types that are <i>writable</i> to
10116 the particular iterator type of <tt>i</tt>.
10117 </p>
10118 </blockquote>
10119
10120 <p>24.1 p9, add</p>
10121
10122 <blockquote>
10123 <p><tt>o</tt> denotes a value of some type that is writable to the
10124 output iterator.
10125 </p>
10126 </blockquote>
10127
10128 <p>Table 73, change</p>
10129
10130 <blockquote>
10131 <pre>*a = t
10132 </pre>
10133 </blockquote>
10134
10135 <p>to</p>
10136
10137 <blockquote>
10138 <pre>*r = o
10139 </pre>
10140 </blockquote>
10141
10142 <p>and change</p>
10143
10144 <blockquote>
10145 <pre>*r++ = t
10146 </pre>
10147 </blockquote>
10148
10149 <p>to</p>
10150
10151 <blockquote>
10152 <pre>*r++ = o
10153 </pre>
10154 </blockquote>
10155
10156 <p><i>[post-Redmond: Jeremy provided wording]</i></p>
10157
10158 <p><b>Rationale:</b></p>
10159 <p>The LWG considered two options: change all of the language that
10160 seems to imply that output iterators have value types, thus making it
10161 clear that output iterators have no value types, or else define value
10162 types for output iterator consistently.  The LWG chose the former
10163 option, because it seems clear that output iterators were never
10164 intended to have value types.  This was a deliberate design decision,
10165 and any language suggesting otherwise is simply a mistake.</p>
10166
10167 <p>A future revision of the standard may wish to revisit this design
10168 decision.</p>
10169 <hr>
10170 <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>
10171 <p>The Returns clause in 22.2.6.3.2, p3 says about
10172 moneypunct&lt;charT&gt;::do_grouping()
10173 </p>
10174
10175 <blockquote>
10176     Returns: A pattern defined identically as the result of
10177     numpunct&lt;charT&gt;::do_grouping().241)
10178 </blockquote>
10179
10180 <p>Footnote 241 then reads</p>
10181
10182 <blockquote>
10183     This is most commonly the value "\003" (not "3").
10184 </blockquote>
10185
10186 <p>
10187 The returns clause seems to imply that the two member functions must
10188 return an identical value which in reality may or may not be true,
10189 since the facets are usually implemented in terms of struct std::lconv
10190 and return the value of the grouping and mon_grouping, respectively.
10191 The footnote also implies that the member function of the moneypunct
10192 facet (rather than the overridden virtual functions in moneypunct_byname)
10193 most commonly return "\003", which contradicts the C standard which
10194 specifies the value of "" for the (most common) C locale.
10195 </p>
10196
10197 <p><b>Proposed resolution:</b></p>
10198 <p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>
10199
10200 <blockquote>
10201     Returns: A pattern defined identically as, but not necessarily
10202     equal to, the result of numpunct&lt;charT&gt;::do_grouping().241)
10203 </blockquote>
10204
10205 <p>and replace the text in Footnote 241 with the following:</p>
10206
10207 <blockquote>
10208     To specify grouping by 3s the value is "\003", not "3".
10209 </blockquote>
10210 <p><b>Rationale:</b></p>
10211 <p>
10212 The fundamental problem is that the description of the locale facet
10213 virtuals serves two purposes: describing the behavior of the base
10214 class, and describing the meaning of and constraints on the behavior
10215 in arbitrary derived classes.  The new wording makes that separation a
10216 little bit clearer.  The footnote (which is nonnormative) is not
10217 supposed to say what the grouping is in the "C" locale or in any other
10218 locale. It is just a reminder that the values are interpreted as small
10219 integers, not ASCII characters.
10220 </p>
10221 <hr>
10222 <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>
10223 <p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
10224 <tt>time_get_byname</tt> are listed incorrectly in table 52,
10225 required instantiations.  In both cases the second template
10226 parameter is given as OutputIterator.  It should instead be
10227 InputIterator, since these are input facets.</p>
10228 <p><b>Proposed resolution:</b></p>
10229 <p>
10230 In table 52, required instantiations, in
10231 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>
10232 <pre>    time_get&lt;wchar_t, OutputIterator&gt;
10233     time_get_byname&lt;wchar_t, OutputIterator&gt;
10234 </pre>
10235 <p>to</p>
10236 <pre>    time_get&lt;wchar_t, InputIterator&gt;
10237     time_get_byname&lt;wchar_t, InputIterator&gt;
10238 </pre>
10239
10240 <p><i>[Redmond: Very minor change in proposed resolution.  Original had
10241 a typo, wchart instead of wchar_t.]</i></p>
10242
10243 <hr>
10244 <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>
10245 <p>The sprintf format string , "%.01f" (that's the digit one), in the
10246 description of the do_put() member functions of the money_put facet in
10247 22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
10248 for values of type long double, and second, the precision of 01
10249 doesn't seem to make sense. What was most likely intended was
10250 "%.0Lf"., that is a precision of zero followed by the L length
10251 modifier.</p>
10252 <p><b>Proposed resolution:</b></p>
10253 <p>Change the format string to "%.0Lf".</p>
10254 <p><b>Rationale:</b></p>
10255 <p>Fixes an obvious typo</p>
10256 <hr>
10257 <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>
10258 <p>
10259 There is an apparent contradiction about which circumstances can cause
10260 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
10261 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>.
10262 </p>
10263
10264 <p>23.2.4.2p5 says:</p>
10265 <blockquote>
10266 Notes: Reallocation invalidates all the references, pointers, and iterators
10267 referring to the elements in the sequence. It is guaranteed that no
10268 reallocation takes place during insertions that happen after a call to
10269 reserve() until the time when an insertion would make the size of the vector
10270 greater than the size specified in the most recent call to reserve().
10271 </blockquote>
10272
10273 <p>Which implies if I do</p>
10274
10275 <pre>  std::vector&lt;int&gt; vec;
10276   vec.reserve(23);
10277   vec.reserve(0);
10278   vec.insert(vec.end(),1);
10279 </pre>
10280
10281 <p>then the implementation may reallocate the vector for the insert,
10282 as the size specified in the previous call to reserve was zero.</p>
10283
10284 <p>However, the previous paragraphs (23.2.4.2, p1-2) state:</p>
10285 <blockquote>
10286 <p>
10287 (capacity) Returns: The total number of elements the vector
10288 can hold without requiring reallocation
10289 </p>
10290 <p>
10291 ...After reserve(), capacity() is greater or equal to the
10292 argument of reserve if reallocation happens; and equal to the previous value
10293 of capacity() otherwise...
10294 </p>
10295 </blockquote>
10296
10297 <p>
10298 This implies that vec.capacity() is still 23, and so the insert()
10299 should not require a reallocation, as vec.size() is 0. This is backed
10300 up by 23.2.4.3p1:
10301 </p>
10302 <blockquote>
10303 (insert) Notes: Causes reallocation if the new size is greater than the old
10304 capacity.
10305 </blockquote>
10306
10307 <p>
10308 Though this doesn't rule out reallocation if the new size is less
10309 than the old capacity, I think the intent is clear.
10310 </p>
10311
10312 <p><b>Proposed resolution:</b></p>
10313 <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>
10314
10315 <blockquote>
10316 Notes: Reallocation invalidates all the references, pointers, and
10317 iterators referring to the elements in the sequence. It is guaranteed
10318 that no reallocation takes place during insertions that happen after a
10319 call to reserve() until the time when an insertion would make the size
10320 of the vector greater than the value of capacity().
10321 </blockquote>
10322
10323 <p><i>[Redmond: original proposed resolution was modified slightly.  In
10324 the original, the guarantee was that there would be no reallocation
10325 until the size would be greater than the value of capacity() after the
10326 most recent call to reserve().  The LWG did not believe that the
10327 "after the most recent call to reserve()" added any useful
10328 information.]</i></p>
10329
10330 <p><b>Rationale:</b></p>
10331 <p>There was general agreement that, when reserve() is called twice in
10332 succession and the argument to the second invocation is smaller than
10333 the argument to the first, the intent was for the second invocation to
10334 have no effect.  Wording implying that such cases have an effect on
10335 reallocation guarantees was inadvertant.</p>
10336 <hr>
10337 <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>
10338 <p>
10339 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
10340    "An implementation may strengthen the exception-specification for a
10341     non-virtual function by removing listed exceptions."
10342 (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>)
10343 and the following declaration of ~failure() in ios_base::failure
10344 </p>
10345 <pre>    namespace std {
10346        class ios_base::failure : public exception {
10347        public:
10348            ...
10349            virtual ~failure();
10350            ...
10351        };
10352      }
10353 </pre>
10354 <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
10355 exception specification:</p>
10356 <pre>    namespace std {
10357        class exception {
10358        public:
10359          ...
10360          virtual ~exception() throw();
10361          ...
10362        };
10363      }
10364 </pre>
10365 <p><b>Proposed resolution:</b></p>
10366 <p>Remove the declaration of ~failure().</p>
10367 <p><b>Rationale:</b></p>
10368 <p>The proposed resolution is consistent with the way that destructors
10369 of other classes derived from <tt>exception</tt> are handled.</p>
10370 <hr>
10371 <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>
10372 <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>
10373 <blockquote>
10374     [Footnote: The effect of executing cout &lt;&lt; endl is to insert a
10375      newline character in the output sequence controlled by cout, then
10376      synchronize it with any external file with which it might be
10377      associated. --- end foonote]
10378 </blockquote>
10379
10380 <p>
10381 Does the term "file" here refer to the external device?
10382 This leads to some implementation ambiguity on systems with fully
10383 buffered files where a newline does not cause a flush to the device.
10384 </p>
10385
10386 <p>
10387 Choosing to sync with the device leads to significant performance
10388 penalties for each call to endl, while not sync-ing leads to
10389 errors under special circumstances.
10390 </p>
10391
10392 <p>
10393 I could not find any other statement that explicitly defined
10394 the behavior one way or the other.
10395 </p>
10396 <p><b>Proposed resolution:</b></p>
10397 <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>
10398 <p><b>Rationale:</b></p>
10399 <p>We already have normative text saying what <tt>endl</tt> does: it
10400 inserts a newline character and calls <tt>flush</tt>.  This footnote
10401 is at best redundant, at worst (as this issue says) misleading,
10402 because it appears to make promises about what <tt>flush</tt>
10403 does.</p>
10404 <hr>
10405 <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>
10406 <p>
10407 The current standard describes map::operator[] using a
10408 code example. That code example is however quite
10409 inefficient because it requires several useless copies
10410 of both the passed key_type value and of default
10411 constructed mapped_type instances.
10412 My opinion is that was not meant by the comitee to
10413 require all those temporary copies.
10414 </p>
10415
10416 <p>Currently map::operator[] behaviour is specified as: </p>
10417 <pre>  Returns:
10418     (*((insert(make_pair(x, T()))).first)).second.
10419 </pre>
10420
10421 <p>
10422 This specification however uses make_pair that is a
10423 template function of which parameters in this case
10424 will be deduced being of type const key_type&amp; and
10425 const T&amp;. This will create a pair&lt;key_type,T&gt; that
10426 isn't the correct type expected by map::insert so
10427 another copy will be required using the template
10428 conversion constructor available in pair to build
10429 the required pair&lt;const key_type,T&gt; instance.
10430 </p>
10431
10432 <p>If we consider calling of key_type copy constructor
10433 and mapped_type default constructor and copy
10434 constructor as observable behaviour (as I think we
10435 should) then the standard is in this place requiring
10436 two copies of a key_type element plus a default
10437 construction and two copy construction of a mapped_type
10438 (supposing the addressed element is already present
10439 in the map; otherwise at least another copy
10440 construction for each type).
10441 </p>
10442
10443 <p>A simple (half) solution would be replacing the description with:</p>
10444 <pre>  Returns:
10445     (*((insert(value_type(x, T()))).first)).second.
10446 </pre>
10447
10448 <p>This will remove the wrong typed pair construction that
10449 requires one extra copy of both key and value.</p>
10450
10451 <p>However still the using of map::insert requires temporary
10452 objects while the operation, from a logical point of view,
10453 doesn't require any. </p>
10454
10455 <p>I think that a better solution would be leaving free an
10456 implementer to use a different approach than map::insert
10457 that, because of its interface, forces default constructed
10458 temporaries and copies in this case.
10459 The best solution in my opinion would be just requiring
10460 map::operator[] to return a reference to the mapped_type
10461 part of the contained element creating a default element
10462 with the specified key if no such an element is already
10463 present in the container. Also a logarithmic complexity
10464 requirement should be specified for the operation.
10465 </p>
10466
10467 <p>
10468 This would allow library implementers to write alternative
10469 implementations not using map::insert and reaching optimal
10470 performance in both cases of the addressed element being
10471 present or absent from the map (no temporaries at all and
10472 just the creation of a new pair inside the container if
10473 the element isn't present).
10474 Some implementer has already taken this option but I think
10475 that the current wording of the standard rules that as
10476 non-conforming.
10477 </p>
10478
10479 <p><b>Proposed resolution:</b></p>
10480
10481 <p>
10482 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
10483 </p>
10484 <blockquote>
10485 <p>
10486 -1- Effects:  If there is no key equivalent to x in the map, inserts
10487 value_type(x, T()) into the map.
10488 </p>
10489 <p>
10490 -2- Returns: A reference to the mapped_type corresponding to x in *this.
10491 </p>
10492 <p>
10493 -3- Complexity: logarithmic.
10494 </p>
10495 </blockquote>
10496
10497 <p><i>[This is the second option mentioned above.  Howard provided
10498 wording.  We may also wish to have a blanket statement somewhere in
10499 clause 17 saying that we do not intend the semantics of sample code
10500 fragments to be interpreted as specifing exactly how many copies are
10501 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>
10502
10503 <p><b>Rationale:</b></p>
10504 <p>
10505 This is the second solution described above; as noted, it is
10506 consistent with existing practice.
10507 </p>
10508
10509 <p>Note that we now need to specify the complexity explicitly, because
10510 we are no longer defining <tt>operator[]</tt> in terms of
10511 <tt>insert</tt>.</p>
10512 <hr>
10513 <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>
10514 <p>
10515 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
10516 as:
10517 </p>
10518 <pre>  X::assign(c,d)   assigns c = d.
10519 </pre>
10520
10521 <p>And para 1 says:</p>
10522
10523 <blockquote>
10524  [...] c and d denote values of type CharT [...]
10525 </blockquote>
10526
10527 <p>
10528 Naturally, if c and d are <i>values</i>, then the assignment is
10529 (effectively) meaningless. It's clearly intended that (in the case of
10530 assign, at least), 'c' is intended to be a reference type.
10531 </p>
10532
10533 <p>I did a quick survey of the four implementations I happened to have
10534 lying around, and sure enough they all have signatures:</p>
10535 <pre>    assign( charT&amp;, const charT&amp; );
10536 </pre>
10537
10538 <p>(or the equivalent). It's also described this way in Nico's book.
10539 (Not to mention the synopses of char_traits&lt;char&gt; in 21.1.3.1
10540 and char_traits&lt;wchar_t&gt; in 21.1.3.2...)
10541 </p>
10542 <p><b>Proposed resolution:</b></p>
10543 <p>Add the following to 21.1.1 para 1:</p>
10544 <blockquote>
10545  r denotes an lvalue of CharT
10546 </blockquote>
10547
10548 <p>and change the description of assign in the table to:</p>
10549 <pre>  X::assign(r,d)   assigns r = d
10550 </pre>
10551 <hr>
10552 <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>
10553 <p>From c++std-edit-873:</p>
10554
10555 <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
10556 &lt;strstream&gt; is missing.</p>
10557
10558 <p>This shows a general problem: The whole clause 17 refers quite
10559 often to clauses 18 through 27, but D.7 is also a part of the standard
10560 library (though a deprecated one).</p>
10561
10562 <p><b>Proposed resolution:</b></p>
10563
10564 <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
10565 "&lt;strstream&gt;".</p>
10566
10567 <p>In the following places, change "clauses 17 through 27" to "clauses
10568 17 through 27 and Annex D":</p>
10569
10570 <ul>
10571 <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>
10572 <li>1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/intro.html#intro.defs"> [intro.defs]</a> Definitions/1</li>
10573 <li>7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/dcl.html#dcl.dcl"> [dcl.dcl]</a> Library introduction/9</li>
10574 <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>
10575 <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>
10576 <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>
10577 <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>
10578 <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>
10579 <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>
10580 <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>
10581 <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>
10582 <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>
10583 </ul>
10584
10585
10586 <hr>
10587 <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>
10588 <p>From c++std-edit-876:</p>
10589
10590 <p>
10591 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
10592 parameter of template replace_copy_if should be "InputIterator"
10593 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
10594 parameter name conveys real normative meaning.
10595 </p>
10596 <p><b>Proposed resolution:</b></p>
10597 <p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
10598 <hr>
10599 <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>
10600 <p>
10601 &gt;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
10602 original text or the text corrected by the proposed resolution of
10603 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
10604 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
10605 format for integer and floating point values, says that whitespace is
10606 optional between a plusminus and a sign.
10607 </p>
10608
10609 <p>
10610 The text needs to be clarified to either consistently allow or
10611 disallow whitespace between a plusminus and a sign. It might be
10612 worthwhile to consider the fact that the C library stdio facility does
10613 not permit whitespace embedded in numbers and neither does the C or
10614 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).
10615 </p>
10616 <p><b>Proposed resolution:</b></p>
10617 <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>
10618 <blockquote>
10619 <p>
10620 The syntax for number formats is as follows, where <tt>digit</tt>
10621 represents the radix set specified by the <tt>fmtflags</tt> argument
10622 value, <tt>whitespace</tt> is as determined by the facet
10623 <tt>ctype&lt;charT&gt;</tt> (22.2.1.1), and <tt>thousands-sep</tt> and
10624 <tt>decimal-point</tt> are the results of corresponding
10625 <tt>numpunct&lt;charT&gt;</tt> members.  Integer values have the
10626 format:
10627 </p>
10628 <pre>  integer   ::= [sign] units
10629   sign      ::= plusminus [whitespace]
10630   plusminus ::= '+' | '-'
10631   units     ::= digits [thousands-sep units]
10632   digits    ::= digit [digits]
10633 </pre>
10634 </blockquote>
10635 <p>to:</p>
10636 <blockquote>
10637 <p>
10638 The syntax for number formats is as follows, where <tt>digit</tt>
10639 represents the radix set specified by the <tt>fmtflags</tt> argument
10640 value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
10641 results of corresponding <tt>numpunct&lt;charT&gt;</tt> members.
10642 Integer values have the format:
10643 </p>
10644 <pre>  integer   ::= [sign] units
10645   sign      ::= plusminus
10646   plusminus ::= '+' | '-'
10647   units     ::= digits [thousands-sep units]
10648   digits    ::= digit [digits]
10649 </pre>
10650 </blockquote>
10651 <p><b>Rationale:</b></p>
10652 <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
10653 standard says how, or whether, it's used.  However, there's no reason
10654 for it to differ gratuitously from the very specific description of
10655 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
10656 resolution removes all mention of "whitespace" from that format.</p>
10657 <hr>
10658 <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>
10659 <p>
10660 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
10661 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
10662 clause 27, making the reference in 22.2.1 somewhat dubious.
10663 </p>
10664 <p><b>Proposed resolution:</b></p>
10665 <p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
10666     <blockquote>
10667     Several types defined in clause 27 are bitmask types. Each bitmask type
10668     can be implemented as an enumerated type that overloads certain operators,
10669     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>).
10670     </blockquote>
10671 <p>to read</p>
10672     <blockquote>
10673     Several types defined in clauses lib.language.support through
10674     lib.input.output and Annex D are bitmask types. Each bitmask type can
10675     be implemented as an enumerated type that overloads certain operators,
10676     as an integer  type, or as a bitset (lib.template.bitset).
10677     </blockquote>
10678
10679 <p>
10680 Additionally, change the definition in 22.2.1 to adopt the same
10681 convention as in clause 27 by replacing the existing text with the
10682 following (note, in particluar, the cross-reference to 17.3.2.1.2 in
10683 22.2.1, p1):
10684 </p>
10685
10686 <blockquote>
10687 <p>22.2.1 The ctype category [lib.category.ctype]</p>
10688 <pre>namespace std {
10689     class ctype_base {
10690     public:
10691         typedef <b><i>T</i></b> mask;
10692
10693         // numeric values are for exposition only.
10694         static const mask space = 1 &lt;&lt; 0;
10695         static const mask print = 1 &lt;&lt; 1;
10696         static const mask cntrl = 1 &lt;&lt; 2;
10697         static const mask upper = 1 &lt;&lt; 3;
10698         static const mask lower = 1 &lt;&lt; 4;
10699         static const mask alpha = 1 &lt;&lt; 5;
10700         static const mask digit = 1 &lt;&lt; 6;
10701         static const mask punct = 1 &lt;&lt; 7;
10702         static const mask xdigit = 1 &lt;&lt; 8;
10703         static const mask alnum = alpha | digit;
10704         static const mask graph = alnum | punct;
10705     };
10706 }
10707 </pre>
10708
10709 <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>
10710 </blockquote>
10711
10712 <p><i>[Curaçao: The LWG notes that T above should be bold-italics to be
10713 consistent with the rest of the standard.]</i></p>
10714
10715 <hr>
10716 <a name="340"><h3>340.&nbsp;interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt>
10717 </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>
10718 <p>
10719 It's unclear whether 22.1.1.1.1, p3 says that
10720 <tt>has_facet&lt;Facet&gt;(loc)</tt> returns true for any <tt>Facet</tt>
10721 from Table 51 or whether it includes Table 52 as well:
10722 </p>
10723
10724 <blockquote>
10725 For any locale <tt>loc</tt> either constructed, or returned by
10726 locale::classic(), and any facet <tt>Facet</tt> that is a member of a
10727 standard category, <tt>has_facet&lt;Facet&gt;(loc)</tt> is true. Each
10728 locale member function which takes a <tt>locale::category</tt>
10729 argument operates on the corresponding set of facets.
10730 </blockquote>
10731
10732 <p>
10733 It seems that it comes down to which facets are considered to be members of a
10734 standard category. Intuitively, I would classify all the facets in Table 52 as
10735 members of their respective standard categories, but there are an unbounded set
10736 of them...
10737 </p>
10738
10739 <p>
10740 The paragraph implies that, for instance, <tt>has_facet&lt;num_put&lt;C,
10741 OutputIterator&gt; &gt;(loc)</tt> must always return true. I don't think that's
10742 possible. If it were, then <tt>use_facet&lt;num_put&lt;C, OutputIterator&gt;
10743 &gt;(loc)</tt> would have to return a reference to a distinct object for each
10744 valid specialization of <tt>num_put&lt;C, OutputIteratory&gt;</tt>, which is
10745 clearly impossible.
10746 </p>
10747
10748 <p>
10749 On the other hand, if none of the facets in Table 52 is a member of a standard
10750 category then none of the locale member functions that operate on entire
10751 categories of facets will work properly.
10752 </p>
10753
10754 <p>
10755 It seems that what p3 should mention that it's required (permitted?)
10756 to hold only for specializations of <tt>Facet</tt> from Table 52 on
10757 <tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
10758 <tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
10759 {
10760 {i,o}<tt>streambuf_iterator</tt>&lt;{<tt>char</tt>,<tt>wchar_t</tt>}<tt>&gt;</tt>
10761 }.
10762 </p>
10763 <p><b>Proposed resolution:</b></p>
10764 <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
10765 "that is a member of a standard category" to "shown in Table 51".</p>
10766 <p><b>Rationale:</b></p>
10767 <p>The facets in Table 52 are an unbounded set.  Locales should not be
10768 required to contain an infinite number of facets.</p>
10769
10770 <p>It's not necessary to talk about which values of InputIterator and
10771 OutputIterator must be supported.  Table 51 already contains a
10772 complete list of the ones we need.</p>
10773 <hr>
10774 <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>
10775 <p>It is a common idiom to reduce the capacity of a vector by swapping it with
10776 an empty one:</p>
10777 <pre>  std::vector&lt;SomeType&gt; vec;
10778   // fill vec with data
10779   std::vector&lt;SomeType&gt;().swap(vec);
10780   // vec is now empty, with minimal capacity
10781 </pre>
10782
10783 <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
10784 the capacity of a vector being reduced, following a call to
10785 reserve(). This invalidates the idiom, as swap() is thus prevented
10786 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
10787 requires the temporary to be expanded to cater for the contents of
10788 vec, and the contents be copied across. This is a linear-time
10789 operation.</p>
10790
10791 <p>However, the container requirements state that swap must have constant
10792 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>
10793
10794 <p>This is an important issue, as reallocation affects the validity of
10795 references and iterators.</p>
10796
10797 <p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
10798 references and iterators remain valid after a call to swap, if they refer to
10799 an element before the new end() of the vector into which they originally
10800 pointed, in which case they refer to the element at the same index position.
10801 Iterators and references that referred to an element whose index position
10802 was beyond the new end of the vector are invalidated.</p>
10803
10804 <p>If the note to table 65 is taken as the desired intent, then there are two
10805 possibilities with regard to iterators and references:</p>
10806
10807 <ol>
10808 <li>All Iterators and references into both vectors are invalidated.</li>
10809 <li>Iterators and references into either vector remain valid, and remain
10810 pointing to the same element. Consequently iterators and references that
10811 referred to one vector now refer to the other, and vice-versa.</li>
10812 </ol>
10813 <p><b>Proposed resolution:</b></p>
10814 <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>
10815 <blockquote>
10816 <pre>  void swap(vector&lt;T,Allocator&gt;&amp; x);
10817 </pre>
10818 <p><b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
10819 with that of <tt>x</tt>.</p>
10820 <p><b>Complexity:</b> Constant time.</p>
10821 </blockquote>
10822
10823 <p><i>[This solves the problem reported for this issue.  We may also
10824 have a problem with a circular definition of swap() for other
10825 containers.]</i></p>
10826
10827 <p><b>Rationale:</b></p>
10828 <p>
10829 swap should be constant time.  The clear intent is that it should just
10830 do pointer twiddling, and that it should exchange all properties of
10831 the two vectors, including their reallocation guarantees.
10832 </p>
10833 <hr>
10834 <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>
10835 <p>
10836 C99, and presumably amendment 1 to C90, specify that &lt;wchar.h&gt;
10837 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
10838 &lt;cwchar&gt;. Is this omission intentional or accidental?
10839 </p>
10840 <p><b>Proposed resolution:</b></p>
10841 <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>
10842 <hr>
10843 <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>
10844 <p>Iterator member functions and operators that do not change the state
10845 of the iterator should be defined as const member functions or as
10846 functions that take iterators either by const reference or by
10847 value. The standard does not explicitly state which functions should
10848 be const.  Since this a fairly common mistake, the following changes
10849 are suggested to make this explicit.</p>
10850
10851 <p>The tables almost indicate constness properly through naming: r
10852 for non-const and a,b for const iterators. The following changes
10853 make this more explicit and also fix a couple problems.</p>
10854 <p><b>Proposed resolution:</b></p>
10855 <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
10856 "In the following sections, a and b denote values of X..." to
10857 "In the following sections, a and b denote values of type const X...".</p>
10858
10859 <p>In Table 73, change</p>
10860 <pre>    a-&gt;m   U&amp;         ...
10861 </pre>
10862
10863 <p>to</p>
10864
10865 <pre>    a-&gt;m   const U&amp;   ...
10866     r-&gt;m   U&amp;         ...
10867 </pre>
10868
10869 <p>In Table 73 expression column, change</p>
10870
10871 <pre>    *a = t
10872 </pre>
10873
10874 <p>to</p>
10875
10876 <pre>    *r = t
10877 </pre>
10878
10879 <p><i>[Redmond: The container requirements should be reviewed to see if
10880 the same problem appears there.]</i></p>
10881
10882 <hr>
10883 <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>
10884 <p>
10885 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
10886 are described as bitmask elements.  In fact, the bitmask requirements
10887 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>
10888 and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
10889
10890 <p>In particular, the requirements for <tt>none</tt> interact poorly
10891 with the requirement that the LC_* constants from the C library must
10892 be recognizable as C++ locale category constants.  LC_* values should
10893 not be mixed with these values to make category values.</p>
10894
10895 <p>We have two options for the proposed resolution.  Informally:
10896 option 1 removes the requirement that LC_* values be recognized as
10897 category arguments.  Option 2 changes the category type so that this
10898 requirement is implementable, by allowing <tt>none</tt> to be some
10899 value such as 0x1000 instead of 0.</p>
10900
10901 <p>Nathan writes: "I believe my proposed resolution [Option 2] merely
10902 re-expresses the status quo more clearly, without introducing any
10903 changes beyond resolving the DR.</p>
10904
10905 <p><b>Proposed resolution:</b></p>
10906 <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>
10907 <blockquote>
10908 <pre>    typedef int category;
10909 </pre>
10910
10911 <p>Valid category values include the <tt>locale</tt> member bitmask
10912 elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
10913 <tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
10914 represents a single locale category. In addition, <tt>locale</tt> member
10915 bitmask constant <tt>none</tt> is defined as zero and represents no
10916 category. And locale member bitmask constant <tt>all</tt> is defined such that
10917 the expression</p>
10918 <pre>    (collate | ctype | monetary | numeric | time | messages | all) == all
10919 </pre>
10920 <p>
10921 is <tt>true</tt>, and represents the union of all categories.  Further
10922 the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
10923 represent a single category, represents the union of the two
10924 categories.
10925 </p>
10926
10927 <p>
10928 <tt>locale</tt> member functions expecting a <tt>category</tt>
10929 argument require one of the <tt>category</tt> values defined above, or
10930 the union of two or more such values. Such a <tt>category</tt>
10931 argument identifies a set of locale categories. Each locale category,
10932 in turn, identifies a set of locale facets, including at least those
10933 shown in Table 51:
10934 </p>
10935 </blockquote>
10936 <p><i>[Curaçao: need input from locale experts.]</i></p>
10937
10938 <p><b>Rationale:</b></p>
10939
10940 <p>The LWG considered, and rejected, an alternate proposal (described
10941   as "Option 2" in the discussion).  The main reason for rejecting it
10942   was that library implementors were concerened about implementation
10943   difficult, given that getting a C++ library to work smoothly with a
10944   separately written C library is already a delicate business.  Some
10945   library implementers were also concerned about the issue of adding
10946   extra locale categories.</p>
10947
10948 <blockquote>
10949 <p><b>Option 2:</b> <br>
10950 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>
10951 <blockquote>
10952 <p>
10953 Valid category values include the enumerated values.  In addition, the
10954 result of applying commutative operators | and &amp; to any two valid
10955 values is valid, and results in the setwise union and intersection,
10956 respectively, of the argument categories.  The values <tt>all</tt> and
10957 <tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
10958 expressions <tt>(cat | all == all)</tt>, <tt>(cat &amp; all == cat)</tt>,
10959 <tt>(cat | none == cat)</tt> and <tt>(cat &amp; none == none)</tt> are
10960 true.  For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
10961 remaining enumerated values, <tt>(cat1 &amp; cat2 == none)</tt> is true.
10962 For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
10963 of <tt>(cat1 &amp; ~cat2)</tt> is valid, and equals the setwise union of
10964 those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
10965 [Footnote: it is not required that <tt>all</tt> equal the setwise union
10966 of the other enumerated values; implementations may add extra categories.]
10967 </p>
10968 </blockquote>
10969 </blockquote>
10970 <hr>
10971 <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>
10972 <p>24.5.2 [lib.ostream.iterator] states:</p>
10973 <pre>    [...]
10974
10975     private:
10976     // basic_ostream&lt;charT,traits&gt;* out_stream; exposition only
10977     // const char* delim; exposition only
10978 </pre>
10979
10980 <p>Whilst it's clearly marked "exposition only", I suspect 'delim'
10981 should be of type 'const charT*'.</p>
10982 <p><b>Proposed resolution:</b></p>
10983 <p>
10984 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
10985 <tt>const charT* delim</tt>.
10986 </p>
10987 <hr>
10988 <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>
10989 <p>
10990 <i>(1)</i>
10991 There are no requirements on the <tt>stateT</tt> template parameter of
10992 <tt>fpos</tt> listed in 27.4.3. The interface appears to require that
10993 the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
10994 and I think also DefaultConstructible (to implement the operations in
10995 Table 88).
10996 </p>
10997 <p>
10998 21.1.2, p3, however, only requires that
10999 <tt>char_traits&lt;charT&gt;::state_type</tt> meet the requirements of
11000 CopyConstructible types.
11001 </p>
11002 <p>
11003 <i>(2)</i>
11004 Additionally, the <tt>stateT</tt> template argument has no
11005 corresponding typedef in fpos which might make it difficult to use in
11006 generic code.
11007 </p>
11008 <p><b>Proposed resolution:</b></p>
11009 <p>
11010 Modify 21.1.2, p4 from
11011 </p>
11012 <p>
11013     Requires: <tt>state_type</tt> shall meet the requirements of
11014               CopyConstructible types (20.1.3).
11015 </p>
11016 <p>
11017     Requires: state_type shall meet the requirements of Assignable
11018               (23.1, p4), CopyConstructible (20.1.3), and
11019               DefaultConstructible  (20.1.4) types.
11020 </p>
11021
11022 <p><b>Rationale:</b></p>
11023 <p>The LWG feels this is two issues, as indicated above. The first is
11024 a defect---std::basic_fstream is unimplementable without these
11025 additional requirements---and the proposed resolution fixes it.  The
11026 second is questionable; who would use that typedef?  The class
11027 template fpos is used only in a very few places, all of which know the
11028 state type already.  Unless motivation is provided, the second should
11029 be considered NAD.</p>
11030 <hr>
11031 <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>
11032 <p>
11033 Discussions in the thread "Associative container lower/upper bound
11034 requirements" on comp.std.c++ suggests that there is a defect in the
11035 C++ standard, Table 69 of section 23.1.2, "Associative containers",
11036 [lib.associative.reqmts].  It currently says:</p>
11037
11038 <blockquote>
11039 <p>
11040 a.find(k): returns an iterator pointing to an element with the key equivalent to
11041 k, or a.end() if such an element is not found.
11042 </p>
11043
11044 <p>
11045 a.lower_bound(k): returns an iterator pointing to the first element with
11046 key not less than k.
11047 </p>
11048
11049 <p>
11050 a.upper_bound(k): returns an iterator pointing to the first element with
11051 key greater than k.
11052 </p>
11053 </blockquote>
11054
11055 <p>
11056 We have "or a.end() if such an element is not found" for
11057 <tt>find</tt>, but not for <tt>upper_bound</tt> or
11058 <tt>lower_bound</tt>.  As the text stands, one would be forced to
11059 insert a new element into the container and return an iterator to that
11060 in case the sought iterator does not exist, which does not seem to be
11061 the intention (and not possible with the "const" versions).
11062 </p>
11063 <p><b>Proposed resolution:</b></p>
11064
11065 <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
11066 to:</p>
11067
11068 <blockquote>
11069 <p>
11070 a.lower_bound(k): returns an iterator pointing to the first element with
11071 key not less than k, or a.end() if such an element is not found.
11072 </p>
11073
11074 <p>
11075 a.upper_bound(k): returns an iterator pointing to the first element with
11076 key greater than k, or a.end() if such an element is not found.
11077 </p>
11078 </blockquote>
11079
11080 <p><i>[Curaçao: LWG reviewed PR.]</i></p>
11081
11082 <hr>
11083 <a name="355"></a><h3><a name="355">355.&nbsp;Operational semantics for a.back()</a></h3><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>
11084
11085 <p>Table 68 "Optional Sequence Operations" in 23.1.1/12
11086 specifies operational semantics for "a.back()" as
11087 "*--a.end()", which may be ill-formed <i>[because calling
11088 operator-- on a temporary (the return) of a built-in type is
11089 ill-formed]</i>, provided a.end() returns a simple pointer rvalue
11090 (this is almost always the case for std::vector::end(), for
11091 example). Thus, the specification is not only incorrect, it
11092 demonstrates a dangerous construct: "--a.end()" may
11093 successfully compile and run as intended, but after changing the type
11094 of the container or the mode of compilation it may produce
11095 compile-time error. </p>
11096
11097 <p><b>Proposed resolution:</b></p>
11098 <p>Change the specification in table 68 "Optional Sequence
11099 Operations" in 23.1.1/12 for "a.back()" from</p>
11100
11101
11102 <blockquote>
11103 *--a.end()
11104 </blockquote>
11105
11106 <p>to</p>
11107
11108 <blockquote>
11109   { iterator tmp = a.end(); --tmp; return *tmp; }
11110 </blockquote>
11111
11112 <p>and the specification for "a.pop_back()" from</p>
11113
11114 <blockquote>
11115 a.erase(--a.end())
11116 </blockquote>
11117
11118 <p>to</p>
11119
11120 <blockquote>
11121   { iterator tmp = a.end(); --tmp; a.erase(tmp); }
11122 </blockquote>
11123
11124 <p><i>[Curaçao: LWG changed PR from "{ X::iterator tmp =
11125 a.end(); return *--tmp; }" to "*a.rbegin()", and from
11126 "{ X::iterator tmp = a.end(); a.erase(--tmp); }" to
11127 "a.erase(rbegin())".]</i></p>
11128
11129 <p><i>[There is a second possible defect; table 68 "Optional
11130 Sequence Operations" in the "Operational Semantics"
11131 column uses operations present only in the "Reversible
11132 Container" requirements, yet there is no stated dependency
11133 between these separate requirements tables. Ask in Santa Cruz if the
11134 LWG would like a new issue opened.]</i></p>
11135
11136 <p><i>[Santa Cruz: the proposed resolution is even worse than what's in
11137   the current standard: erase is undefined for reverse iterator.  If
11138   we're going to make the change, we need to define a temporary and
11139   use operator--.  Additionally, we don't know how prevalent this is:
11140   do we need to make this change in more than one place?  Martin has
11141   volunteered to review the standard and see if this problem occurs
11142   elsewhere.]</i></p>
11143
11144 <p><i>[Oxford: Matt provided new wording to address the concerns raised
11145   in Santa Cruz.  It does not appear that this problem appears
11146   anywhere else in clauses 23 or 24.]</i></p>
11147
11148 <p><i>[Kona: In definition of operational semantics of back(), change
11149 "*tmp" to "return *tmp;"]</i></p>
11150
11151 <hr>
11152 <a name="358"></a><h3><a name="358">358.&nbsp;interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt>
11153 </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#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
11154 <p>
11155 I don't think <tt>thousands_sep</tt> is being treated correctly after
11156 decimal_point has been seen. Since grouping applies only to the
11157 integral part of the number, the first such occurrence should, IMO,
11158 terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
11159 and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
11160 interpreted in the fractional part of a number.)
11161 </p>
11162
11163 <p>
11164 The easiest change I can think of that resolves this issue would be
11165 something like below.
11166 </p>
11167 <p><b>Proposed resolution:</b></p>
11168 <p>
11169 Change the first sentence of 22.2.2.1.2, p9 from
11170 </p>
11171
11172 <blockquote>
11173     If discard is true then the position of the character is
11174     remembered, but the character is otherwise ignored. If it is not
11175     discarded, then a check is made to determine if c is allowed as
11176     the next character of an input field of the conversion specifier
11177     returned by stage 1. If so it is accumulated.
11178 </blockquote>
11179
11180 <p>to</p>
11181
11182 <blockquote>
11183     If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
11184     accumulated, then the position of the character is remembered, but
11185     the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
11186     already been accumulated, the character is discarded and Stage 2
11187      terminates. ...
11188 </blockquote>
11189
11190 <p><b>Rationale:</b></p>
11191 <p>We believe this reflects the intent of the Standard.  Thousands sep
11192   characters after the decimal point are not useful in any locale.
11193   Some formatting conventions do group digits that follow the decimal
11194   point, but they usually introduce a different grouping character
11195   instead of reusing the thousand sep character.  If we want to add
11196   support for such conventions, we need to do so explicitly.</p>
11197
11198 <hr>
11199 <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>
11200 <p>22.2.2.2.1, p1:</p>
11201
11202     <pre>    iter_type put (iter_type out, ios_base&amp; str, char_type fill,
11203                    bool val) const;
11204     ...
11205
11206     1   Returns: do_put (out, str, fill, val).
11207     </pre>
11208
11209 <p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
11210 however, 22.2.2.2.2, p23:</p>
11211
11212 <blockquote>
11213 <pre>iter_type put (iter_type out, ios_base&amp; str, char_type fill,
11214                bool val) const;
11215 </pre>
11216
11217
11218         Effects: If (str.flags() &amp; ios_base::boolalpha) == 0 then do
11219              out = do_put(out, str, fill, (int)val)
11220            Otherwise do
11221 <pre>             string_type s =
11222                  val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
11223                      : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
11224 </pre>
11225            and then insert the characters of s into out. <i>out</i>.
11226 </blockquote>
11227
11228 <p>
11229 This means that the bool overload of <tt>do_put()</tt> will never be called,
11230 which contradicts the first paragraph. Perhaps the declaration
11231 should read <tt>do_put()</tt>, and not <tt>put()</tt>?
11232 </p>
11233
11234 <p>
11235 Note also that there is no <b>Returns</b> clause for this function, which
11236 should probably be corrected, just as should the second occurrence
11237 of <i>"out."</i> in the text.
11238 </p>
11239
11240 <p>
11241 I think the least invasive change to fix it would be something like
11242 the following:
11243 </p>
11244 <p><b>Proposed resolution:</b></p>
11245 <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
11246   the <tt>bool</tt> overload.</p>
11247
11248 <p>
11249 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
11250 </p>
11251
11252 <blockquote>
11253      Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
11254      of the member function.
11255 </blockquote>
11256
11257 <blockquote>
11258     Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
11259     avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
11260     do_put (..., bool))</tt>
11261     like so:
11262 </blockquote>
11263
11264 <blockquote>
11265     23   <b>Returns</b>: If <tt>(str.flags() &amp;
11266          ios_base::boolalpha) == 0</tt> then
11267          <tt>do_put (out, str, fill, (long)val)</tt>
11268          Otherwise the function obtains a string <tt>s</tt> as if by
11269 <pre>             string_type s =
11270                 val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
11271                     : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
11272 </pre>
11273          and then inserts each character <tt>c</tt> of s into out via
11274            <tt>*out++ = c</tt>
11275          and returns <tt>out</tt>.
11276 </blockquote>
11277
11278 <p><b>Rationale:</b></p>
11279 <p>
11280 This fixes a couple of obvious typos, and also fixes what appears to
11281 be a requirement of gratuitous inefficiency.
11282 </p>
11283 <hr>
11284 <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>
11285 <p>
11286 22.1.1, p7 (copied below) allows iostream formatters and extractors
11287 to make assumptions about the values returned from facet members.
11288 However, such assumptions are apparently not guaranteed to hold
11289 in other cases (e.g., when the facet members are being called directly
11290 rather than as a result of iostream calls, or between successive
11291 calls to the same iostream functions with no interevening calls to
11292 <tt>imbue()</tt>, or even when the facet member functions are called
11293 from other member functions of other facets). This restriction
11294 prevents locale from being implemented efficiently.
11295 </p>
11296 <p><b>Proposed resolution:</b></p>
11297 <p>Change the first sentence in 22.1.1, p7 from</p>
11298 <blockquote>
11299     In successive calls to a locale facet member function during
11300     a call to an iostream inserter or extractor or a streambuf member
11301     function, the returned result shall be identical. [Note: This
11302     implies that such results may safely be reused without calling
11303     the locale facet member function again, and that member functions
11304     of iostream classes cannot safely call <tt>imbue()</tt>
11305     themselves, except as specified elsewhere. --end note]
11306 </blockquote>
11307
11308 <p>to</p>
11309
11310 <blockquote>
11311     In successive calls to a locale facet member function on a facet
11312     object installed in the same locale, the returned result shall be
11313     identical. ...
11314 </blockquote>
11315
11316 <p><b>Rationale:</b></p>
11317 <p>This change is reasonable becuase it clarifies the intent of this
11318   part of the standard.</p>
11319 <hr>
11320 <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>
11321 <p>
11322 The destructor of ios_base::failure should have an empty throw
11323 specification, because the destructor of its base class, exception, is
11324 declared in this way.
11325 </p>
11326 <p><b>Proposed resolution:</b></p>
11327 <p>Change the destructor to</p>
11328 <pre>  virtual ~failure() throw();
11329 </pre>
11330 <p><b>Rationale:</b></p>
11331 <p>Fixes an obvious glitch.  This is almost editorial.</p>
11332 <hr>
11333 <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>
11334 <p>
11335 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
11336 clause for seekoff.
11337 </p>
11338 <p><b>Proposed resolution:</b></p>
11339 <p>
11340 Make this paragraph, the Effects clause for setbuf, consistent in wording
11341 with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
11342 to indicate the purpose of setbuf:
11343 </p>
11344
11345 <p>Original text:</p>
11346
11347 <blockquote>
11348 1 Effects: Performs an operation that is defined separately for each
11349 class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
11350 </blockquote>
11351
11352 <p>Proposed text:</p>
11353
11354 <blockquote>
11355 1 Effects: Influences stream buffering in a way that is defined separately
11356 for each class derived from basic_streambuf in this clause
11357 (27.7.1.3, 27.8.1.4).
11358 </blockquote>
11359
11360 <p><b>Rationale:</b></p>
11361 <p>The LWG doesn't believe there is any normative difference between
11362   the existing wording and what's in the proposed resolution, but the
11363   change may make the intent clearer.</p>
11364 <hr>
11365 <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>
11366 <p>
11367 Some stream and streambuf member functions are declared non-const,
11368 even thought they appear only to report information rather than to
11369 change an object's logical state.  They should be declared const.  See
11370 document N1360 for details and rationale.
11371 </p>
11372
11373 <p>The list of member functions under discussion: <tt>in_avail</tt>,
11374 <tt>showmanyc</tt>, <tt>tellg</tt>, <tt>tellp</tt>, <tt>is_open</tt>.</p>
11375
11376 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a></p>
11377
11378 <p><b>Proposed resolution:</b></p>
11379 <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>
11380 <p>Replace</p>
11381 <pre>  bool is_open();
11382 </pre>
11383 <p>with</p>
11384 <pre>  bool is_open() const;
11385 </pre>
11386 <p><b>Rationale:</b></p>
11387 <p>Of the changes proposed in N1360, the only one that is safe is
11388 changing the filestreams' is_open to const.  The LWG believed that
11389 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
11390 member function, after all,is already const.</p>
11391
11392 <p>The other proposed changes are less safe, because some streambuf
11393 functions that appear merely to report a value do actually perform
11394 mutating operations.  It's not even clear that they should be
11395 considered "logically const", because streambuf has two interfaces, a
11396 public one and a protected one.  These functions may, and often do,
11397 change the state as exposed by the protected interface, even if the
11398 state exposed by the public interface is unchanged.</p>
11399
11400 <p>Note that implementers can make this change in a binary compatible
11401 way by providing both overloads; this would be a conforming extension.</p>
11402
11403 <hr>
11404 <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>
11405 <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
11406 with the following signature:</p>
11407
11408 <pre>  basic_istream&lt;charT,traits&gt;&amp; get(basic_streambuf&lt;char_type,traits&gt;&amp;
11409   sb);
11410 </pre>
11411
11412 <p>is incorrect. It reads</p>
11413
11414 <blockquote>
11415   Effects: Calls get(s,n,widen('\n'))
11416 </blockquote>
11417
11418 <p>which I believe should be:</p>
11419
11420 <blockquote>
11421   Effects: Calls get(sb,widen('\n'))
11422 </blockquote>
11423 <p><b>Proposed resolution:</b></p>
11424 <p>Change the <b>Effects</b> paragraph to:</p>
11425 <blockquote>
11426   Effects: Calls get(sb,this-&gt;widen('\n'))
11427 </blockquote>
11428
11429 <p><i>[Pre-Oxford: Minor correction from Howard: replaced 'widen'
11430       with 'this-&gt;widen'.]</i></p>
11431
11432 <p><b>Rationale:</b></p>
11433 <p>Fixes an obvious typo.</p>
11434 <hr>
11435 <a name="373"></a><h3><a name="373">373.&nbsp;Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</a></h3><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>
11436
11437 <p>
11438 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>
11439 (exception()&amp;badbit) != 0 is used in testing for rethrow, yet
11440 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
11441 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?
11442 </p>
11443
11444 <p><b>Proposed resolution:</b></p>
11445 <p>
11446 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
11447 "(exception()&amp;badbit) != 0" to "(exceptions()&amp;badbit) != 0".
11448 </p>
11449 <p><b>Rationale:</b></p>
11450 <p>Fixes an obvious typo.</p>
11451 <hr>
11452 <a name="375"></a><h3><a name="375">375.&nbsp;basic_ios should be ios_base in 27.7.1.3</a></h3><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
11453 <p>
11454 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
11455 14 all contain references to "basic_ios::" which should be
11456 "ios_base::".
11457 </p>
11458 <p><b>Proposed resolution:</b></p>
11459 <p>
11460 Change all references to "basic_ios" in Table 90, Table 91, and
11461 paragraph 14 to "ios_base".
11462 </p>
11463 <p><b>Rationale:</b></p>
11464 <p>Fixes an obvious typo.</p>
11465 <hr>
11466 <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>
11467 <p>
11468 The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
11469 </p>
11470 <pre>  charT do_widen (char c) const;
11471
11472   -11- Effects: Applies the simplest reasonable transformation from
11473        a char value or sequence of char values to the corresponding
11474        charT value or values. The only characters for which unique
11475        transformations are required are those in the basic source
11476        character set (2.2). For any named ctype category with a
11477        ctype&lt;charT&gt; facet ctw and valid ctype_base::mask value
11478        M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
11479 </pre>
11480 <p>
11481 Shouldn't the last sentence instead read
11482 </p>
11483 <pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
11484        and valid ctype_base::mask value M
11485        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
11486 </pre>
11487 <p>
11488 I.e., if the narrow character c is not a member of a class of
11489 characters then neither is the widened form of c. (To paraphrase
11490 footnote 224.)
11491 </p>
11492 <p><b>Proposed resolution:</b></p>
11493 <p>
11494 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
11495 following text:
11496 </p>
11497 <pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
11498        and valid ctype_base::mask value M,
11499        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
11500 </pre>
11501
11502 <p><i>[Kona: Minor edit. Added a comma after the <i>M</i> for clarity.]</i></p>
11503
11504 <p><b>Rationale:</b></p>
11505 <p>The LWG believes this is just a typo, and that this is the correct fix.</p>
11506 <hr>
11507 <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>
11508 <p>
11509 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
11510 result values," when surely "do_in/do_out result values" must have
11511 been intended for Table 53 and "do_unshift result values" for Table
11512 54.
11513 </p>
11514 <p>
11515 Table 54, row 3 says that the meaning of partial is "more characters
11516 needed to be supplied to complete termination." The function is not
11517 supplied any characters, it is given a buffer which it fills with
11518 characters or, more precisely, destination elements (i.e., an escape
11519 sequence). So partial means that space for more than (to_limit - to)
11520 destination elements was needed to terminate a sequence given the
11521 value of state.
11522 </p>
11523 <p><b>Proposed resolution:</b></p>
11524 <p>
11525 Change the title of Table 53 to "do_in/do_out result values" and
11526 the title of Table 54 to "do_unshift result values."
11527 </p>
11528 <p>
11529 Change the text in Table 54, row 3 (the <b>partial</b> row), under the
11530 heading Meaning, to "space for more than (to_limit - to) destination
11531 elements was needed to terminate a sequence given the value of state."
11532 </p>
11533 <hr>
11534 <a name="381"></a><h3><a name="381">381.&nbsp;detection of invalid mbstate_t in codecvt</a></h3><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>
11535 <p>
11536 All but one codecvt member functions that take a state_type argument
11537 list as one of their preconditions that the state_type argument have
11538 a valid value. However, according to 22.2.1.5.2, p6,
11539 codecvt::do_unshift() is the only codecvt member that is supposed to
11540 return error if the state_type object is invalid.
11541 </p>
11542
11543 <p>
11544 It seems to me that the treatment of state_type by all codecvt member
11545 functions should be the same and the current requirements should be
11546 changed. Since the detection of invalid state_type values may be
11547 difficult in general or computationally expensive in some specific
11548 cases, I propose the following:
11549 </p>
11550 <p><b>Proposed resolution:</b></p>
11551 <p>
11552 Add a new paragraph before 22.2.1.5.2, p5, and after the function
11553 declaration below
11554 </p>
11555 <pre>    result do_unshift(stateT&amp; state,
11556     externT* to, externT* to_limit, externT*&amp; to_next) const;
11557 </pre>
11558 <p>
11559 as follows:
11560 </p>
11561 <pre>    Requires: (to &lt;= to_end) well defined and true; state initialized,
11562     if at the beginning of a sequence, or else equal to the result of
11563     converting the preceding characters in the sequence.
11564 </pre>
11565 <p>
11566 and change the text in Table 54, row 4, the <b>error</b> row, under
11567 the heading Meaning, from
11568 </p>
11569 <pre>    state has invalid value
11570 </pre>
11571 <p>
11572 to
11573 </p>
11574 <pre>    an unspecified error has occurred
11575 </pre>
11576 <p><b>Rationale:</b></p>
11577 <p>The intent is that implementations should not be required to detect
11578 invalid state values; such a requirement appears nowhere else.  An
11579 invalid state value is a precondition violation, <i>i.e.</i> undefined
11580 behavior.  Implementations that do choose to detect invalid state
11581 values, or that choose to detect any other kind of error, may return
11582 <b>error</b> as an indication.</p>
11583 <hr>
11584 <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>
11585 <p>
11586 Following a discussion on the boost list regarding end iterators and
11587 the possibility of performing operator--() on them, it seems to me
11588 that there is a typo in the standard.  This typo has nothing to do
11589 with that discussion.
11590 </p>
11591
11592 <p>
11593 I have checked this newsgroup, as well as attempted a search of the
11594 Active/Defect/Closed Issues List on the site for the words "s is
11595 derefer" so I believe this has not been proposed before.  Furthermore,
11596 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
11597 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.
11598 </p>
11599
11600 <p>
11601 The standard makes the following assertion on bidirectional iterators,
11602 in section 24.1.4 [lib.bidirectional.iterators], Table 75:
11603 </p>
11604
11605 <pre>                         operational  assertion/note
11606 expression  return type   semantics    pre/post-condition
11607
11608 --r          X&amp;                        pre: there exists s such
11609                                        that r == ++s.
11610                                        post: s is dereferenceable.
11611                                        --(++r) == r.
11612                                        --r == --s implies r == s.
11613                                        &amp;r == &amp;--r.
11614 </pre>
11615
11616 <p>
11617 (See <a href="http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763">http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763</a>.)
11618 </p>
11619
11620 <p>
11621 In particular, "s is dereferenceable" seems to be in error.  It seems
11622 that the intention was to say "r is dereferenceable".
11623 </p>
11624
11625 <p>
11626 If it were to say "r is dereferenceable" it would
11627 make perfect sense.  Since s must be dereferenceable prior to
11628 operator++, then the natural result of operator-- (to undo operator++)
11629 would be to make r dereferenceable.  Furthermore, without other
11630 assertions, and basing only on precondition and postconditions, we
11631 could not otherwise know this.  So it is also interesting information.
11632 </p>
11633
11634 <p><b>Proposed resolution:</b></p>
11635 <p>
11636 Change the guarantee to "postcondition: r is dereferenceable."
11637 </p>
11638 <p><b>Rationale:</b></p>
11639 <p>Fixes an obvious typo</p>
11640 <hr>
11641 <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>
11642 <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>
11643 is specified as having a return type of <tt>reverse_iterator::reference</tt>,
11644 which is the same as <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.
11645 (Where <tt>Iterator</tt> is the underlying iterator type.)</p>
11646
11647 <p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't
11648   necessarily have a return type
11649   of <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.   Its
11650   return type is merely required to be convertible
11651   to <tt>Iterator</tt>'s value type.  The return type specified for
11652   reverse_iterator's operator[] would thus appear to be impossible.</p>
11653
11654 <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
11655   <tt>a[n]</tt> will continue to be required (for random access
11656   iterators) to be convertible to the value type, and also <tt>a[n] =
11657   t</tt> will be a valid expression.  Implementations of
11658   <tt>reverse_iterator</tt> will likely need to return a proxy from
11659   <tt>operator[]</tt> to meet these requirements. As mentioned in the
11660   comment from Dave Abrahams, the simplest way to specify that
11661   <tt>reverse_iterator</tt> meet this requirement to just mandate
11662   it and leave the return type of <tt>operator[]</tt> unspecified.</p>
11663
11664 <p><b>Proposed resolution:</b></p>
11665
11666 <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>
11667
11668 <blockquote>
11669 <pre>reference operator[](difference_type n) const;
11670 </pre>
11671 </blockquote>
11672
11673 <p>to:</p>
11674
11675 <blockquote>
11676 <pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see <font color="red">lib.random.access.iterators</font>
11677 </pre>
11678 </blockquote>
11679
11680
11681
11682
11683 <p><i>[
11684 Comments from Dave Abrahams: IMO we should resolve 386 by just saying
11685     that the return type of reverse_iterator's operator[] is
11686     unspecified, allowing the random access iterator requirements to
11687     impose an appropriate return type.  If we accept 299's proposed
11688     resolution (and I think we should), the return type will be
11689     readable and writable, which is about as good as we can do.
11690 ]</i></p>
11691 <hr>
11692 <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>
11693 <p>Consider the following program:</p>
11694 <pre>    #include &lt;iostream&gt;
11695     #include &lt;ostream&gt;
11696     #include &lt;vector&gt;
11697     #include &lt;valarray&gt;
11698     #include &lt;algorithm&gt;
11699     #include &lt;iterator&gt;
11700     template&lt;typename Array&gt;
11701     void print(const Array&amp; a)
11702     {
11703     using namespace std;
11704     typedef typename Array::value_type T;
11705     copy(&amp;a[0], &amp;a[0] + a.size(),
11706     ostream_iterator&lt;T&gt;(std::cout, " "));
11707     }
11708     template&lt;typename T, unsigned N&gt;
11709     unsigned size(T(&amp;)[N]) { return N; }
11710     int main()
11711     {
11712     double array[] = { 0.89, 9.3, 7, 6.23 };
11713     std::vector&lt;double&gt; v(array, array + size(array));
11714     std::valarray&lt;double&gt; w(array, size(array));
11715     print(v); // #1
11716     std::cout &lt;&lt; std::endl;
11717     print(w); // #2
11718     std::cout &lt;&lt; std::endl;
11719     }
11720 </pre>
11721
11722 <p>While the call numbered #1 succeeds, the call numbered #2 fails
11723 because the const version of the member function
11724 valarray&lt;T&gt;::operator[](size_t) returns a value instead of a
11725 const-reference. That seems to be so for no apparent reason, no
11726 benefit. Not only does that defeats users' expectation but it also
11727 does hinder existing software (written either in C or Fortran)
11728 integration within programs written in C++.  There is no reason why
11729 subscripting an expression of type valarray&lt;T&gt; that is const-qualified
11730 should not return a const T&amp;.</p>
11731 <p><b>Proposed resolution:</b></p>
11732 <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
11733 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>
11734 <pre>  T operator[](size_t const);
11735 </pre>
11736 <p>to</p>
11737 <pre>  const T&amp; operator[](size_t const);
11738 </pre>
11739
11740 <p><i>[Kona: fixed a minor typo: put semicolon at the end of the line
11741   wehre it belongs.]</i></p>
11742
11743 <p><b>Rationale:</b></p>
11744 <p>Return by value seems to serve no purpose.  Valaray was explicitly
11745 designed to have a specified layout so that it could easily be
11746 integrated with libraries in other languages, and return by value
11747 defeats that purpose.  It is believed that this change will have no
11748 impact on allowable optimizations.</p>
11749 <hr>
11750 <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>
11751 <p>
11752 The specifications of toupper and tolower both specify the functions as
11753 const, althought they are not member functions, and are not specified as
11754 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>.
11755 </p>
11756 <p><b>Proposed resolution:</b></p>
11757 <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
11758   declarations of std::toupper and std::tolower</p>
11759 <p><b>Rationale:</b></p>
11760 <p>Fixes an obvious typo</p>
11761 <hr>
11762 <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>
11763 <p>
11764 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
11765 definition of rand(); in the C standard, it is written that "The
11766 implementation shall behave as if no library function calls the rand
11767 function."
11768 </p>
11769
11770 <p>
11771 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
11772 how the two parameter version of the function generates its random
11773 value.  I believe that all current implementations in fact call rand()
11774 (in contradiction with the requirement avove); if an implementation does
11775 not call rand(), there is the question of how whatever random generator
11776 it does use is seeded.  Something is missing.
11777 </p>
11778
11779 <p><b>Proposed resolution:</b></p>
11780 <p>
11781 In [lib.c.math], add a paragraph specifying that the C definition of
11782 rand shal be modified to say that "Unless otherwise specified, the
11783 implementation shall behave as if no library function calls the rand
11784 function."
11785 </p>
11786
11787 <p>
11788 In [lib.alg.random.shuffle], add a sentence to the effect that "In
11789 the two argument form of the function, the underlying source of
11790 random numbers is implementation defined. [Note: in particular, an
11791 implementation is permitted to use <tt>rand</tt>.]
11792 </p>
11793 <p><b>Rationale:</b></p>
11794 <p>The original proposed resolution proposed requiring the
11795   two-argument from of <tt>random_shuffle</tt> to
11796   use <tt>rand</tt>. We don't want to do that, because some existing
11797   implementations already use something else: gcc
11798   uses <tt>lrand48</tt>, for example.  Using <tt>rand</tt> presents a
11799   problem if the number of elements in the sequence is greater than
11800   RAND_MAX.</p>
11801 <hr>
11802 <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>
11803 <p>
11804 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
11805 the following 3 lines:
11806 </p>
11807
11808 <pre>  12 Returns: new((void *) p) T( val)
11809      void destroy(pointer p);
11810   13 Returns: ((T*) p)-&gt;~T()
11811 </pre>
11812
11813 <p>
11814 The type cast "(T*) p" in the last line is redundant cause
11815 we know that std::allocator&lt;T&gt;::pointer is a typedef for T*.
11816 </p>
11817 <p><b>Proposed resolution:</b></p>
11818 <p>
11819 Replace "((T*) p)" with "p".
11820 </p>
11821 <p><b>Rationale:</b></p>
11822 <p>Just a typo, this is really editorial.</p>
11823 <hr>
11824 <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>
11825 <p>
11826 This applies to the new expression that is contained in both par12 of
11827 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>.
11828 I think this new expression is wrong, involving unintended side
11829 effects.
11830 </p>
11831
11832
11833 <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>
11834
11835 <pre>  11 Returns: the largest value N for which the call allocate(N,0) might succeed.
11836      void construct(pointer p, const_reference val);
11837   12 Returns: new((void *) p) T( val)
11838 </pre>
11839
11840
11841 <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>
11842 <pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
11843 </pre>
11844
11845 <p>
11846 .... with the prerequisits coming from the preceding two paragraphs,
11847 especially from table 31:
11848 </p>
11849
11850 <pre>  alloc&lt;T&gt;             a     ;// an allocator for T
11851   alloc&lt;T&gt;::pointer    p     ;// random access iterator
11852                               // (may be different from T*)
11853   alloc&lt;T&gt;::reference  r = *p;// T&amp;
11854   T const&amp;             t     ;
11855 </pre>
11856
11857 <p>
11858 Cause of using "new" but not "::new", any existing "T::operator new"
11859 function will hide the global placement new function. When there is no
11860 "T::operator new" with adequate signature,
11861 every_alloc&lt;T&gt;::construct(..) is ill-formed, and most
11862 std::container&lt;T,every_alloc&lt;T&gt;&gt; use it; a workaround
11863 would be adding placement new and delete functions with adequate
11864 signature and semantic to class T, but class T might come from another
11865 party. Maybe even worse is the case when T has placement new and
11866 delete functions with adequate signature but with "unknown" semantic:
11867 I dont like to speculate about it, but whoever implements
11868 any_container&lt;T,any_alloc&gt; and wants to use construct(..)
11869 probably must think about it.
11870 </p>
11871 <p><b>Proposed resolution:</b></p>
11872 <p>
11873 Replace "new" with "::new" in both cases.
11874 </p>
11875 <hr>
11876 <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>
11877
11878 <p>
11879 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
11880 basic_string "conforms to the requirements of a Sequence, as specified
11881 in (23.1.1)." The sequence requirements specified in (23.1.1) to not
11882 include any prohibition on swap members throwing exceptions.
11883 </p>
11884
11885 <p>
11886 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
11887 which exceptions may be thrown, but applies only to "all container
11888 types defined in this clause" and so excludes basic_string::swap
11889 because it is defined elsewhere.
11890 </p>
11891
11892 <p>
11893 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
11894 permits basic_string::swap to invalidates iterators, which is
11895 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
11896 be contradictory if it were read or extended to read as having
11897 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.
11898 </p>
11899
11900 <p>
11901 Yet several LWG members have expressed the belief that the original
11902 intent was that basic_string::swap should not throw exceptions as
11903 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
11904 unclear on this issue. The complexity of basic_string::swap is
11905 specified as "constant time", indicating the intent was to avoid
11906 copying (which could cause a bad_alloc or other exception). An
11907 important use of swap is to ensure that exceptions are not thrown in
11908 exception-safe code.
11909 </p>
11910
11911 <p>
11912 Note: There remains long standing concern over whether or not it is
11913 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
11914 requirements when allocators are unequal. The specification of
11915 basic_string::swap exception requirements is in no way intended to
11916 address, prejudice, or otherwise impact that concern.
11917 </p>
11918
11919
11920
11921
11922
11923 <p><b>Proposed resolution:</b></p>
11924 <p>
11925 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:
11926 </p>
11927
11928 <p>
11929 Throws: Shall not throw exceptions.
11930 </p>
11931 <hr>
11932 <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>
11933 <p>
11934 The eight basic dynamic memory allocation functions (single-object
11935 and array versions of ::operator new and ::operator delete, in the
11936 ordinary and nothrow forms) are replaceable.  A C++ program may
11937 provide an alternative definition for any of them, which will be used
11938 in preference to the implementation's definition.
11939 </p>
11940
11941 <p>
11942 Three different parts of the standard mention requirements on
11943 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>
11944 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>.
11945 </p>
11946
11947 <p>None of these three places say whether a replacement function may
11948   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
11949   signature for the replacement function, but that's not enough:
11950   the <tt>inline</tt> specifier is not part of a function's signature.
11951   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
11952   requires that "an inline function shall be defined in every
11953   translation unit in which it is used," but this may not be quite
11954   specific enough either.  We should either explicitly allow or
11955   explicitly forbid inline replacement memory allocation
11956   functions.</p>
11957 <p><b>Proposed resolution:</b></p>
11958 <p>
11959 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:
11960 "The program's definitions shall not be specified as <tt>inline</tt>.
11961 No diagnostic is required."
11962 </p>
11963
11964 <p><i>[Kona: added "no diagnostic is required"]</i></p>
11965
11966 <p><b>Rationale:</b></p>
11967 <p>
11968 The fact that <tt>inline</tt> isn't mentioned appears to have been
11969 nothing more than an oversight.  Existing implementations do not
11970 permit inline functions as replacement memory allocation functions.
11971 Providing this functionality would be difficult in some cases, and is
11972 believed to be of limited value.
11973 </p>
11974 <hr>
11975 <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>
11976 <p>
11977 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
11978 standard library. Paragraph 4 does not list any restrictions on qsort,
11979 but it should limit the base parameter to point to POD.  Presumably,
11980 qsort sorts the array by copying bytes, which requires POD.
11981 </p>
11982 <p><b>Proposed resolution:</b></p>
11983 <p>
11984 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
11985 before the nonnormative note, add these words: "both of which have the
11986 same behavior as the original declaration.  The behavior is undefined
11987 unless the objects in the array pointed to by <i>base</i> are of POD
11988 type."
11989 </p>
11990
11991 <p><i>[Something along these lines is clearly necessary.  Matt
11992   provided wording.]</i></p>
11993 <hr>
11994 <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>
11995 <p>
11996 There is a possible defect in the standard: the standard text was
11997 never intended to prevent arbitrary ForwardIterators, whose operations
11998 may throw exceptions, from being passed, and it also wasn't intended
11999 to require a temporary buffer in the case where ForwardIterators were
12000 passed (and I think most implementations don't use one).  As is, the
12001 standard appears to impose requirements that aren't met by any
12002 existing implementation.
12003 </p>
12004 <p><b>Proposed resolution:</b></p>
12005 <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>
12006 <blockquote>
12007   1- Notes: Causes reallocation if the new size is greater than the
12008   old capacity. If no reallocation happens, all the iterators and
12009   references before the insertion point remain valid. If an exception
12010   is thrown other than by the copy constructor or assignment operator
12011   of T or by any InputIterator operation there are no effects.
12012 </blockquote>
12013
12014 <p><i>[We probably need to say something similar for deque.]</i></p>
12015
12016 <hr>
12017 <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>
12018 <p>
12019 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
12020 that is defined for a singular iterator is "an assignment of a
12021 non-singular value to an iterator that holds a singular value".  This
12022 means that destroying a singular iterator (e.g. letting an automatic
12023 variable go out of scope) is technically undefined behavior.  This
12024 seems overly strict, and probably unintentional.
12025 </p>
12026 <p><b>Proposed resolution:</b></p>
12027 <p>
12028 Change the sentence in question to "... the only exceptions are
12029 destroying an iterator that holds a singular value, or the assignment
12030 of a non-singular value to an iterator that holds a singular value."
12031 </p>
12032 <hr>
12033 <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>
12034 <p>
12035 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
12036 closing a basic_[io]fstream does not affect the error bits.  This
12037 means, for example, that if you read through a file up to EOF, and
12038 then close the stream and reopen it at the beginning of the file,
12039 the EOF bit in the stream's error state is still set.  This is
12040 counterintuitive.
12041 </p>
12042 <p>
12043 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>,
12044 and put in a footnote to clarify that the strict reading was indeed
12045 correct.  We did that because we believed the standard was
12046 unambiguous and consistent, and that we should not make architectural
12047 changes in a TC.  Now that we're working on a new revision of the
12048 language, those considerations no longer apply.
12049 </p>
12050 <p><b>Proposed resolution:</b></p>
12051
12052 <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>
12053
12054 <blockquote>
12055 Calls rdbuf()-&gt;open(s,mode|in). If that function returns a null
12056 pointer, calls setstate(failbit) (which may throw ios_base::failure
12057 [Footnote: (lib.iostate.flags)].
12058 </blockquote>
12059
12060 <p>to:</p>
12061
12062 <blockquote>Calls rdbuf()-&gt;open(s,mode|in). If that function returns
12063 a null pointer, calls setstate(failbit) (which may throw
12064 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
12065 </blockquote>
12066
12067 <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>
12068
12069 <blockquote>Calls rdbuf()-&gt;open(s,mode|out). If that function
12070 returns a null pointer, calls setstate(failbit) (which may throw
12071 ios_base::failure [Footnote: (lib.iostate.flags)).
12072 </blockquote>
12073
12074 <p>to:</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)), else calls clear().
12079 </blockquote>
12080
12081 <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>
12082
12083 <blockquote>Calls rdbuf()-&gt;open(s,mode), If that function returns a
12084 null pointer, calls setstate(failbit), (which may throw
12085 ios_base::failure). (lib.iostate.flags) )
12086 </blockquote>
12087
12088 <p>to:</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) ), else calls clear().
12093 </blockquote>
12094
12095
12096
12097 <p><i>[Kona: the LWG agrees this is a good idea.  Post-Kona: Bill
12098 provided wording.  He suggests having open, not close, clear the error
12099 flags.]</i></p>
12100
12101 <p><i>[Post-Sydney: Howard provided a new proposed resolution.  The
12102   old one didn't make sense because it proposed to fix this at the
12103   level of basic_filebuf, which doesn't have access to the stream's
12104   error state.  Howard's proposed resolution fixes this at the level
12105   of the three fstream class template instead.]</i></p>
12106
12107 <hr>
12108 <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>
12109 <p>
12110 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
12111 comparison operators (==, !=, &lt;, &lt;=, &gt;, =&gt;) for queue and
12112 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>
12113 par3) are defined.
12114 </p>
12115 <p><b>Proposed resolution:</b></p>
12116
12117 <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>
12118   paragraph 3:</p>
12119
12120 <blockquote>
12121
12122 <pre>  operator!=
12123 </pre>
12124 <p>Returns: <tt>x.c != y.c</tt></p>
12125
12126 <pre>  operator&gt;
12127 </pre>
12128 <p>Returns: <tt>x.c &gt; y.c</tt></p>
12129
12130 <pre>  operator&lt;=
12131 </pre>
12132 <p>Returns: <tt>x.c &lt;= y.c</tt></p>
12133
12134 <pre>  operator&gt;=
12135 </pre>
12136 <p>Returns: <tt>x.c &gt;= y.c</tt></p>
12137
12138 </blockquote>
12139
12140 <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>
12141
12142 <blockquote>
12143
12144 <pre>  operator==
12145 </pre>
12146 <p>Returns: <tt>x.c == y.c</tt></p>
12147
12148 <pre>  operator&lt;
12149 </pre>
12150 <p>Returns: <tt>x.c &lt; y.c</tt></p>
12151
12152 <pre>  operator!=
12153 </pre>
12154 <p>Returns: <tt>x.c != y.c</tt></p>
12155
12156 <pre>  operator&gt;
12157 </pre>
12158 <p>Returns: <tt>x.c &gt; y.c</tt></p>
12159
12160 <pre>  operator&lt;=
12161 </pre>
12162 <p>Returns: <tt>x.c &lt;= y.c</tt></p>
12163
12164 <pre>  operator&gt;=
12165 </pre>
12166 <p>Returns: <tt>x.c &gt;= y.c</tt></p>
12167
12168 </blockquote>
12169
12170
12171 <p><i>[Kona: Matt provided wording.]</i></p>
12172
12173 <p><b>Rationale:</b></p>
12174 There isn't any real doubt about what these operators are
12175 supposed to do, but we ought to spell it out.
12176 <hr>
12177 <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>
12178 <p>
12179 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:
12180 "The semantics of the set operations are generalized to multisets in a
12181 standard way by defining union() to contain the maximum number of
12182 occurrences of every element, intersection() to contain the minimum, and
12183 so on."
12184 </p>
12185
12186 <p>
12187 This is wrong.  The name of the functions are set_union() and
12188 set_intersection(), not union() and intersection().
12189 </p>
12190 <p><b>Proposed resolution:</b></p>
12191 <p>Change that sentence to use the correct names.</p>
12192 <hr>
12193 <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>
12194 <p>
12195 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
12196 function only throws if the respective bits are already set prior to
12197 the function call. That's obviously not the intent. The typo ought to
12198 be corrected and the text reworded as: "If (<i>state</i> &amp;
12199 exceptions()) == 0, returns. ..."
12200 </p>
12201 <p><b>Proposed resolution:</b></p>
12202 <p>
12203 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;
12204 exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
12205 &amp; exceptions()) == 0".
12206 </p>
12207
12208 <p><i>[Kona: the original proposed resolution wasn't quite right.  We
12209   really do mean rdstate(); the ambiguity is that the wording in the
12210   standard doesn't make it clear whether we mean rdstate() before
12211   setting the new state, or rdsate() after setting it.  We intend the
12212   latter, of course. Post-Kona: Martin provided wording.]</i></p>
12213
12214 <hr>
12215 <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>
12216 <p>
12217 The second sentence of the proposed resolution says:
12218 </p>
12219
12220 <p>
12221 "If it inserted no characters because it caught an exception thrown
12222 while extracting characters from sb and ..."
12223 </p>
12224
12225 <p>
12226 However, we are not extracting from sb, but extracting from the
12227 basic_istream (*this) and inserting into sb. I can't really tell if
12228 "extracting" or "sb" is a typo.
12229 </p>
12230
12231 <p><i>[
12232 Sydney: Definitely a real issue. We are, indeed, extracting characters
12233 from an istream and not from sb. The problem was there in the FDIS and
12234 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
12235 to have *this instead of sb. We're talking about the exception flag
12236 state of a basic_istream object, and there's only one basic_istream
12237 object in this discussion, so that would be a consistent
12238 interpretation.  (But we need to be careful: the exception policy of
12239 this member function must be consistent with that of other
12240 extractors.)  PJP will provide wording.
12241 ]</i></p>
12242
12243 <p><b>Proposed resolution:</b></p>
12244 <p>Change the sentence from:</p>
12245
12246 <blockquote>
12247 If it inserted no characters because it caught an exception thrown
12248 while extracting characters from sb and failbit is on in exceptions(),
12249 then the caught exception is rethrown.
12250 </blockquote>
12251
12252 <p>to:</p>
12253
12254 <blockquote>
12255 If it inserted no characters because it caught an exception thrown
12256 while extracting characters from *this and failbit is on in exceptions(),
12257 then the caught exception is rethrown.
12258 </blockquote>
12259 <hr>
12260 <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>
12261 <p>
12262 Consider the following code fragment:
12263 </p>
12264 <blockquote>
12265 <pre>int A[8] = { 1,3,5,7,9,8,4,2 };
12266 std::vector&lt;int&gt; v(A, A+8);
12267
12268 std::vector&lt;int&gt;::iterator i1 = v.begin() + 3;
12269 std::vector&lt;int&gt;::iterator i2 = v.begin() + 4;
12270 v.erase(i1);
12271 </pre>
12272 </blockquote>
12273
12274 <p>
12275 Which iterators are invalidated by <tt>v.erase(i1)</tt>: i1, i2,
12276 both, or neither?
12277 </p>
12278
12279 <p>
12280 On all existing implementations that I know of, the status of i1 and
12281 i2 is the same: both of them will be iterators that point to some
12282 elements of the vector (albeit not the same elements they did
12283 before).  You won't get a crash if you use them.  Depending on
12284 exactly what you mean by "invalidate", you might say that neither one
12285 has been invalidated because they still point to <i>something</i>,
12286 or you might say that both have been invalidated because in both
12287 cases the elements they point to have been changed out from under the
12288 iterator.
12289 </p>
12290
12291 <p>
12292 The standard doesn't say either of those things.  It says that erase
12293 invalidates all iterators and references "after the point of the
12294 erase".  This doesn't include i1, since it's at the point of the
12295 erase instead of after it.  I can't think of any sensible definition
12296 of invalidation by which one can say that i2 is invalidated but i1
12297 isn't.
12298 </p>
12299
12300 <p>
12301 (This issue is important if you try to reason about iterator validity
12302 based only on the guarantees in the standard, rather than reasoning
12303 from typical implementation techniques.  Strict debugging modes,
12304 which some programmers find useful, do not use typical implementation
12305 techniques.)
12306 </p>
12307 <p><b>Proposed resolution:</b></p>
12308 <p>
12309 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
12310 iterators and references after the point of the erase" to
12311 "Invalidates iterators and references at or after the point of the
12312 erase".
12313 </p>
12314 <p><b>Rationale:</b></p>
12315 <p>I believe this was essentially a typographical error, and that it
12316   was taken for granted that erasing an element invalidates iterators
12317   that point to it.  The effects clause in question treats iterators
12318   and references in parallel, and it would seem counterintuitive to
12319   say that a reference to an erased value remains valid.</p>
12320 <hr>
12321 <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>
12322 <p>
12323 According to 27.6.1.4, the ws() manipulator is not required to construct
12324 the sentry object. The manipulator is also not a member function so the
12325 text in 27.6.1, p1 through 4 that describes the exception policy for
12326 istream member functions does not apply. That seems inconsistent with
12327 the rest of extractors and all the other input functions (i.e., ws will
12328 not cause a tied stream to be flushed before extraction, it doesn't check
12329 the stream's exceptions or catch exceptions thrown during input, and it
12330 doesn't affect the stream's gcount).
12331 </p>
12332 <p><b>Proposed resolution:</b></p>
12333 <p>
12334 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
12335 of paragraph 1, the following text:
12336 </p>
12337
12338     <blockquote>
12339     Behaves as an unformatted input function (as described in
12340     27.6.1.3, paragraph 1), except that it does not count the number
12341     of characters extracted and does not affect the value returned by
12342     subsequent calls to is.gcount(). After constructing a sentry
12343     object...
12344     </blockquote>
12345
12346 <p><i>[Post-Kona: Martin provided wording]</i></p>
12347
12348 <hr>
12349 <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>
12350 <p>
12351 7.19.1, p2, of C99 requires that the FILE type only be declared in
12352 &lt;stdio.h&gt;.  None of the (implementation-defined) members of the
12353 struct is mentioned anywhere for obvious reasons.
12354 </p>
12355
12356 <p>
12357 C++ says in 27.8.1, p2 that FILE is a type that's defined in &lt;cstdio&gt;. Is
12358 it really the intent that FILE be a complete type or is an implementation
12359 allowed to just declare it without providing a full definition?
12360 </p>
12361 <p><b>Proposed resolution:</b></p>
12362 <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
12363   "defined" to "declared".</p>
12364 <p><b>Rationale:</b></p>
12365 <p>We don't want to impose any restrictions beyond what the C standard
12366   already says. We don't want to make anything implementation defined,
12367   because that imposes new requirements in implementations.</p>
12368 <hr>
12369 <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>
12370 <p>
12371 The standard is not clear about the requirements on the value returned from
12372 a call to get_temporary_buffer(0). In particular, it fails to specify whether
12373 the call should return a distinct pointer each time it is called (like
12374 operator new), or whether the value is unspecified (as if returned by
12375 malloc). The standard also fails to mention what the required behavior
12376 is when the argument is less than 0.
12377 </p>
12378 <p><b>Proposed resolution:</b></p>
12379 <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
12380 values if no storage can be obtained" to "...or a pair of 0 values if
12381 no storage can be obtained or if <i>n</i> &lt;= 0."</p>
12382 <p><i>[Kona: Matt provided wording]</i></p>
12383 <hr>
12384 <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>
12385 <p>
12386 The complexity requirements for these function templates are incorrect
12387 (or don't even make sense) for negative n:</p>
12388
12389 <p>25.1.9, p7 (search_n):
12390 <br>
12391 Complexity: At most (last1 - first1) * count applications
12392 of the corresponding predicate.</p>
12393
12394 <p>25.2.5, p3 (fill_n):
12395 <br>
12396 Complexity: Exactly last - first (or n) assignments.</p>
12397 <br>
12398
12399 <p>25.2.6, p3 (generate_n):
12400 <br>
12401 Complexity: Exactly last - first (or n) assignments.</p>
12402
12403 <p>
12404 In addition, the Requirements or the Effects clauses for the latter two
12405 templates don't say anything about the behavior when n is negative.
12406 </p>
12407 <p><b>Proposed resolution:</b></p>
12408 <p>Change 25.1.9, p7 to</p>
12409
12410 <blockquote>
12411 Complexity: At most (last1 - first1) * count applications
12412 of the corresponding predicate if count is positive,
12413 or 0 otherwise.
12414 </blockquote>
12415
12416 <p>Change 25.2.5, p2 to</p>
12417 <blockquote>
12418 Effects: Assigns value through all the iterators in the range [first,
12419 last), or [first, first + n) if n is positive, none otherwise.
12420 </blockquote>
12421
12422 <p>Change 25.2.5, p3 to:</p>
12423 <blockquote>
12424 Complexity: Exactly last - first (or n if n is positive,
12425 or 0 otherwise) assignments.
12426 </blockquote>
12427
12428 <p>
12429 Change 25.2.6, p1
12430 to (notice the correction for the misspelled "through"):
12431 </p>
12432 <blockquote>
12433 Effects: Invokes the function object genand assigns the return
12434 value of gen through all the iterators in the range [first, last),
12435 or [first, first + n) if n is positive, or [first, first)
12436 otherwise.
12437 </blockquote>
12438
12439 <p>Change 25.2.6, p3 to:</p>
12440 <blockquote>
12441 Complexity: Exactly last - first (or n if n is positive,
12442 or 0 otherwise) assignments.
12443 </blockquote>
12444 <p><b>Rationale:</b></p>
12445 <p>Informally, we want to say that whenever we see a negative number
12446   we treat it the same as if it were zero.  We believe the above
12447   changes do that (although they may not be the minimal way of saying
12448   so).  The LWG considered and rejected the alternative of saying that
12449   negative numbers are undefined behavior.</p>
12450 <hr>
12451 <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>
12452 <p>
12453 23.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q)
12454 that q must be a valid dereferenceable iterator into the sequence a.
12455 </p>
12456
12457 <p>
12458 However, 21.3.5.5, p5 describing string::erase(p) only requires that
12459 p be a valid iterator.
12460 </p>
12461
12462 <p>
12463 This may be interepreted as a relaxation of the general requirement,
12464 which is most likely not the intent.
12465 </p>
12466 <p><b>Proposed resolution:</b></p>
12467 <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>
12468 <p><b>Rationale:</b></p>
12469 <p>The LWG considered two options: changing the string requirements to
12470   match the general container requirements, or just removing the
12471   erroneous string requirements altogether.  The LWG chose the latter
12472   option, on the grounds that duplicating text always risks the
12473   possibility that it might be duplicated incorrectly.</p>
12474 <hr>
12475 <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>
12476 <p>27.7.1.3 par 8 says:</p>
12477 <blockquote>
12478 Notes: The function can make a write position available only if
12479     ( mode &amp; ios_base::out) != 0. To make a write position
12480     available, the function reallocates (or initially allocates) an
12481     array object with a sufficient number of elements to hold the
12482     current array object (if any), plus one additional write position.
12483     If ( mode &amp; ios_base::in) != 0, the function alters the read end
12484     pointer egptr() to point just past the new write position (as
12485     does the write end pointer epptr()).
12486 </blockquote>
12487
12488 <p>
12489 The sentences "plus one additional write position." and especially
12490     "(as does the write end pointer epptr())" COULD by interpreted
12491     (and is interpreted by at least my library vendor) as:
12492 </p>
12493
12494 <blockquote>
12495     post-condition: epptr() == pptr()+1
12496 </blockquote>
12497
12498 <p>
12499 This WOULD force sputc() to call the virtual overflow() each time.
12500 </p>
12501
12502 <p>The proposed change also affects Defect Report 169.</p>
12503
12504 <p><b>Proposed resolution:</b></p>
12505 <p>27.7.1.1/2 Change:</p>
12506
12507 <blockquote>
12508 2- Notes: The function allocates no array object.
12509 </blockquote>
12510
12511 <p>
12512 to:
12513 </p>
12514
12515 <blockquote>
12516 2- Postcondition: str() == "".
12517 </blockquote>
12518
12519 <p>
12520 27.7.1.1/3 Change:
12521 </p>
12522
12523 <blockquote>
12524 <p>
12525 -3- Effects: Constructs an object of class basic_stringbuf,
12526 initializing the base class with basic_streambuf()
12527 (lib.streambuf.cons), and initializing mode with which . Then copies
12528 the content of str into the basic_stringbuf underlying character
12529 sequence and initializes the input and output sequences according to
12530 which. If which &amp; ios_base::out is true, initializes the output
12531 sequence with the underlying sequence. If which &amp; ios_base::in is
12532 true, initializes the input sequence with the underlying sequence.
12533 </p>
12534 </blockquote>
12535
12536 <p>to:</p>
12537
12538 <blockquote>
12539 <p>
12540 -3- Effects: Constructs an object of class basic_stringbuf,
12541 initializing the base class with basic_streambuf()
12542 (lib.streambuf.cons), and initializing mode with which. Then copies
12543 the content of str into the basic_stringbuf underlying character
12544 sequence. If which &amp; ios_base::out is true, initializes the output
12545 sequence such that pbase() points to the first underlying character,
12546 epptr() points one past the last underlying character, and if (which &amp;
12547 ios_base::ate) is true, pptr() is set equal to
12548 epptr() else pptr() is set equal to pbase(). If which &amp; ios_base::in
12549 is true, initializes the input sequence such that eback() and gptr()
12550 point to the first underlying character and egptr() points one past
12551 the last underlying character.
12552 </p>
12553 </blockquote>
12554
12555 <p>27.7.1.2/1 Change:</p>
12556
12557 <blockquote>
12558 <p>
12559 -1- Returns: A basic_string object whose content is equal to the
12560 basic_stringbuf underlying character sequence. If the buffer is only
12561 created in input mode, the underlying character sequence is equal to
12562 the input sequence; otherwise, it is equal to the output sequence. In
12563 case of an empty underlying character sequence, the function returns
12564 basic_string&lt;charT,traits,Allocator&gt;().
12565 </p>
12566 </blockquote>
12567
12568 <p>to:</p>
12569
12570 <blockquote>
12571 <p>
12572 -1- Returns: A basic_string object whose content is equal to the
12573 basic_stringbuf underlying character sequence. If the basic_stringbuf
12574 was created only in input mode, the resultant basic_string contains
12575 the character sequence in the range [eback(), egptr()).  If the
12576 basic_stringbuf was created with (which &amp; ios_base::out) being true
12577 then the resultant basic_string contains the character sequence in the
12578 range [pbase(), high_mark) where high_mark represents the position one
12579 past the highest initialized character in the buffer.  Characters can
12580 be initialized either through writing to the stream, or by
12581 constructing the basic_stringbuf with a basic_string, or by calling
12582 the str(basic_string) member function.  In the case of calling the
12583 str(basic_string) member function, all characters initialized prior to
12584 the call are now considered uninitialized (except for those
12585 characters re-initialized by the new basic_string).  Otherwise the
12586 basic_stringbuf has been created in neither input nor output mode and
12587 a zero length basic_string is returned.
12588 </p>
12589 </blockquote>
12590
12591 <p>
12592 27.7.1.2/2 Change:
12593 </p>
12594
12595 <blockquote>
12596 <p>
12597 -2- Effects: If the basic_stringbuf's underlying character sequence is
12598 not empty, deallocates it. Then copies the content of s into the
12599 basic_stringbuf underlying character sequence and initializes the
12600 input and output sequences according to the mode stored when creating
12601 the basic_stringbuf object. If (mode&amp;ios_base::out) is true, then
12602 initializes the output sequence with the underlying sequence. If
12603 (mode&amp;ios_base::in) is true, then initializes the input sequence with
12604 the underlying sequence.
12605 </p>
12606 </blockquote>
12607
12608 <p>to:</p>
12609
12610 <blockquote>
12611 <p>
12612 -2- Effects: Copies the content of s into the basic_stringbuf
12613 underlying character sequence. If mode &amp; ios_base::out is true,
12614 initializes the output sequence such that pbase() points to the first
12615 underlying character, epptr() points one past the last underlying
12616 character, and if (mode &amp; ios_base::ate) is true,
12617 pptr() is set equal to epptr() else pptr() is set equal to pbase(). If
12618 mode &amp; ios_base::in is true, initializes the input sequence such that
12619 eback() and gptr() point to the first underlying character and egptr()
12620 points one past the last underlying character.
12621 </p>
12622 </blockquote>
12623
12624 <p>Remove 27.2.1.2/3.  (Same rationale as issue 238: incorrect and unnecessary.)</p>
12625
12626 <p>27.7.1.3/1 Change:</p>
12627
12628 <blockquote>
12629 <p>
12630 1- Returns: If the input sequence has a read position available,
12631 returns traits::to_int_type(*gptr()).  Otherwise, returns
12632 traits::eof().
12633 </p>
12634 </blockquote>
12635
12636 <p>to:</p>
12637
12638 <blockquote>
12639 <p>
12640 1- Returns: If the input sequence has a read position available,
12641 returns traits::to_int_type(*gptr()).  Otherwise, returns
12642 traits::eof().  Any character in the underlying buffer which has been
12643 initialized is considered to be part of the input sequence.
12644 </p>
12645 </blockquote>
12646
12647 <p>27.7.1.3/9 Change:</p>
12648
12649 <blockquote>
12650 <p>
12651 -9- Notes: The function can make a write position available only if (
12652 mode &amp; ios_base::out) != 0. To make a write position available, the
12653 function reallocates (or initially allocates) an array object with a
12654 sufficient number of elements to hold the current array object (if
12655 any), plus one additional write position. If ( mode &amp; ios_base::in) !=
12656 0, the function alters the read end pointer egptr() to point just past
12657 the new write position (as does the write end pointer epptr()).
12658 </p>
12659 </blockquote>
12660
12661 <p>to:</p>
12662
12663 <blockquote>
12664 <p>
12665 -9- The function can make a write position available only if ( mode &amp;
12666 ios_base::out) != 0. To make a write position available, the function
12667 reallocates (or initially allocates) an array object with a sufficient
12668 number of elements to hold the current array object (if any), plus one
12669 additional write position. If ( mode &amp; ios_base::in) != 0, the
12670 function alters the read end pointer egptr() to point just past the
12671 new write position.
12672 </p>
12673 </blockquote>
12674
12675 <p>27.7.1.3/12 Change:</p>
12676
12677 <blockquote>
12678 <p>
12679 -12- _ If (newoff + off) &lt; 0, or (xend - xbeg) &lt; (newoff + off), the
12680 positioning operation fails. Otherwise, the function assigns xbeg +
12681 newoff + off to the next pointer xnext .
12682 </p>
12683 </blockquote>
12684
12685 <p>to:</p>
12686
12687 <blockquote>
12688 <p>
12689 -12- _ If (newoff + off) &lt; 0, or if (newoff + off) refers to an
12690 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>
12691 paragraph 1), the positioning operation fails. Otherwise, the function
12692 assigns xbeg + newoff + off to the next pointer xnext .
12693 </p>
12694 </blockquote>
12695
12696 <p><i>[post-Kona: Howard provided wording.  At Kona the LWG agreed that
12697   something along these lines was a good idea, but the original
12698   proposed resolution didn't say enough about the effect of various
12699   member functions on the underlying character sequences.]</i></p>
12700
12701 <p><b>Rationale:</b></p>
12702 <p>The current basic_stringbuf description is over-constrained in such
12703 a way as to prohibit vendors from making this the high-performance
12704 in-memory stream it was meant to be.  The fundamental problem is that
12705 the pointers: eback(), gptr(), egptr(), pbase(), pptr(), epptr() are
12706 observable from a derived client, and the current description
12707 restricts the range [pbase(), epptr()) from being grown geometrically.
12708 This change allows, but does not require, geometric growth of this
12709 range.</p>
12710
12711 <p>Backwards compatibility issues: These changes will break code that
12712 derives from basic_stringbuf, observes epptr(), and depends upon
12713 [pbase(), epptr()) growing by one character on each call to overflow()
12714 (i.e. test suites).  Otherwise there are no backwards compatibility
12715 issues.</p>
12716
12717 <p>27.7.1.1/2: The non-normative note is non-binding, and if it were
12718 binding, would be over specification.  The recommended change focuses
12719 on the important observable fact.</p>
12720
12721 <p>27.7.1.1/3: This change does two things: 1.  It describes exactly
12722 what must happen in terms of the sequences.  The terms "input
12723 sequence" and "output sequence" are not well defined.  2.  It
12724 introduces a common extension: open with app or ate mode.  I concur
12725 with issue 238 that paragraph 4 is both wrong and unnecessary.</p>
12726
12727 <p>27.7.1.2/1: This change is the crux of the efficiency issue.  The
12728 resultant basic_string is not dependent upon epptr(), and thus
12729 implementors are free to grow the underlying buffer geometrically
12730 during overflow() *and* place epptr() at the end of that buffer.</p>
12731
12732 <p>27.7.1.2/2:  Made consistent with the proposed 27.7.1.1/3.</p>
12733
12734 <p>27.7.1.3/1: Clarifies that characters written to the stream beyond
12735 the initially specified string are available for reading in an i/o
12736 basic_streambuf.</p>
12737
12738 <p>27.7.1.3/9: Made normative by removing "Notes:", and removed the
12739 trailing parenthetical comment concerning epptr().</p>
12740
12741 <p>27.7.1.3/12: Restricting the positioning to [xbeg, xend) is no
12742 longer allowable since [pbase(), epptr()) may now contain
12743 uninitialized characters.  Positioning is only allowable over the
12744 initialized range.</p>
12745 <hr>
12746 <a name="434"><h3>434.&nbsp;bitset::to_string() hard to use</h3></a><p><b>Section:</b>&nbsp;23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2003</p>
12747 <p>
12748 It has been pointed out a number of times that the bitset to_string() member
12749 function template is tedious to use since callers must explicitly specify the
12750 entire template argument list (3 arguments). At least two implementations
12751 provide a number of overloads of this template to make it easier to use.
12752 </p>
12753 <p><b>Proposed resolution:</b></p>
12754 <p>In order to allow callers to specify no template arguments at all, just the
12755 first one (charT), or the first 2 (charT and traits), in addition to all
12756 three template arguments, add the following three overloads to both the
12757 interface (declarations only) of the class template bitset as well as to
12758 section 23.3.5.2, immediately after p34, the Returns clause of the existing
12759 to_string() member function template:</p>
12760
12761 <pre>    template &lt;class charT, class traits&gt;
12762     basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
12763     to_string () const;
12764
12765     -34.1- Returns: to_string&lt;charT, traits, allocator&lt;charT&gt; &gt;().
12766
12767     template &lt;class charT&gt;
12768     basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
12769     to_string () const;
12770
12771     -34.2- Returns: to_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;().
12772
12773     basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
12774     to_string () const;
12775
12776     -34.3- Returns: to_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;().
12777 </pre>
12778
12779 <p><i>[Kona: the LWG agrees that this is an improvement over the
12780   status quo.  Dietmar thought about an alternative using a proxy
12781   object but now believes that the proposed resolution above is the
12782   right choice.
12783 ]</i></p>
12784
12785 <hr>
12786 <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>
12787
12788 <p>
12789 It has been pointed out that the proposed resolution in DR 25 may not be
12790 quite up to snuff: <br>
12791 http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html
12792 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#25<br>
12793 </p>
12794
12795 <p>
12796 It looks like Petur is right. The complete corrected text is copied below.
12797 I think we may have have been confused by the reference to 22.2.2.2.2 and
12798 the subsequent description of `n' which actually talks about the second
12799 argument to sputn(), not about the number of fill characters to pad with.
12800 </p>
12801
12802 <p>
12803 So the question is: was the original text correct? If the intent was to
12804 follow classic iostreams then it most likely wasn't, since setting width()
12805 to less than the length of the string doesn't truncate it on output. This
12806 is also the behavior of most implementations (except for SGI's standard
12807 iostreams where the operator does truncate).
12808 </p>
12809 <p><b>Proposed resolution:</b></p>
12810 <p>Change the text in 21.3.7.9, p4 from</p>
12811     <blockquote>
12812     If bool(k) is true, inserts characters as if by calling
12813     os.rdbuf()-&gt;sputn(str.data(), n), padding as described in stage 3
12814     of lib.facet.num.put.virtuals, where n is the larger of os.width()
12815     and str.size();
12816     </blockquote>
12817 <p>to</p>
12818     <blockquote>
12819     If bool(k) is true, determines padding as described in
12820     lib.facet.num.put.virtuals, and then inserts the resulting
12821     sequence of characters <tt>seq</tt> as if by calling
12822     <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where <tt>n</tt> is the larger of
12823     <tt>os.width()</tt> and <tt>str.size()</tt>;
12824      </blockquote>
12825
12826 <p><i>[Kona: it appears that neither the original wording, DR25, nor the
12827   proposed resolution, is quite what we want.  We want to say that
12828   the string will be output, padded to os.width() if necessary.  We
12829   don't want to duplicate the padding rules in clause 22, because
12830   they're complicated, but we need to be careful because they weren't
12831   quite written with quite this case in mind.  We need to say what
12832   the character sequence is, and then defer to clause 22.  Post-Kona:
12833   Benjamin provided wording.]</i></p>
12834
12835 <hr>
12836 <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>
12837 <p>
12838 Is "const std::ctype&lt;char&gt;" a valid template argument to has_facet, use_facet,
12839 and the locale template ctor? And if so, does it designate the same Facet as
12840 the non-const "std::ctype&lt;char&gt;?" What about "volatile std::ctype&lt;char&gt;?"
12841 Different implementations behave differently: some fail to compile, others
12842 accept such types but behave inconsistently.
12843 </p>
12844 <p><b>Proposed resolution:</b></p>
12845 <p>Change 22.1.1.1.2, p1 to read:</p>
12846
12847 <p>Template parameters in this clause which are required to be facets
12848 are those named Facet in declarations. A program that passes a type
12849 that is not a facet, or a type that refers to volatile-qualified
12850 facet, as an (explicit or deduced) template parameter to a locale
12851 function expecting a facet, is ill-formed.  A const-qualified facet is
12852 a valid template argument to any locale function that expects a Facet
12853 template parameter.</p>
12854
12855 <p><i>[Kona: changed the last sentence from a footnote to normative
12856 text.]</i></p>
12857
12858 <hr>
12859 <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>
12860
12861 <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
12862 noticed with statements like:</p>
12863 <pre>vector&lt;int&gt; v(10, 1);
12864 </pre>
12865
12866 <p>The intent of the above statement was to construct with:</p>
12867 <pre>vector(size_type, const value_type&amp;);
12868 </pre>
12869
12870 <p>but early implementations failed to compile as they bound to:</p>
12871 <pre>template &lt;class InputIterator&gt;
12872 vector(InputIterator f, InputIterator l);
12873 </pre>
12874 <p>instead.</p>
12875
12876 <p>Paragraphs 9-11 say that if InputIterator is an integral type, then the
12877 member template constructor will have the same effect as:</p>
12878 <pre>vector&lt;static_cast&lt;size_type&gt;(f), static_cast&lt;value_type&gt;(l));
12879 </pre>
12880 <p>(and similarly for the other member template functions of sequences).</p>
12881
12882 <p>There is also a note that describes one implementation technique:</p>
12883 <blockquote>
12884    One way that sequence implementors can satisfy this requirement is to
12885    specialize the member template for every integral type.
12886 </blockquote>
12887
12888 <p>This might look something like:</p>
12889 <blockquote>
12890 <pre>template &lt;class T&gt;
12891 struct vector
12892 {
12893      typedef unsigned size_type;
12894
12895      explicit vector(size_type) {}
12896      vector(size_type, const T&amp;) {}
12897
12898      template &lt;class I&gt;
12899      vector(I, I);
12900
12901      // ...
12902 };
12903
12904 template &lt;class T&gt;
12905 template &lt;class I&gt;
12906 vector&lt;T&gt;::vector(I, I) { ... }
12907
12908 template &lt;&gt;
12909 template &lt;&gt;
12910 vector&lt;int&gt;::vector(int, int) { ... }
12911
12912 template &lt;&gt;
12913 template &lt;&gt;
12914 vector&lt;int&gt;::vector(unsigned, unsigned) { ... }
12915
12916 //  ...
12917 </pre>
12918 </blockquote>
12919
12920 <p>Label this solution 'A'.</p>
12921
12922 <p>The standard also says:</p>
12923 <blockquote>
12924  Less cumbersome implementation techniques also exist.
12925 </blockquote>
12926 <p>
12927 A popular technique is to not specialize as above, but instead catch
12928 every call with the member template, detect the type of InputIterator,
12929 and then redirect to the correct logic.  Something like:
12930 </p>
12931 <blockquote>
12932 <pre>template &lt;class T&gt;
12933 template &lt;class I&gt;
12934 vector&lt;T&gt;::vector(I f, I l)
12935 {
12936      choose_init(f, l, int2type&lt;is_integral&lt;I&gt;::value&gt;());
12937 }
12938
12939 template &lt;class T&gt;
12940 template &lt;class I&gt;
12941 vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;false&gt;)
12942 {
12943     // construct with iterators
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;true&gt;)
12949 {
12950     size_type sz = static_cast&lt;size_type&gt;(f);
12951     value_type v = static_cast&lt;value_type&gt;(l);
12952     // construct with sz,v
12953 }
12954 </pre>
12955 </blockquote>
12956
12957 <p>Label this solution 'B'.</p>
12958
12959 <p>Both of these solutions solve the case the standard specifically
12960 mentions:</p>
12961 <pre>vector&lt;int&gt; v(10, 1);  // ok, vector size 10, initialized to 1
12962 </pre>
12963
12964 <p>
12965 However, (and here is the problem), the two solutions have different
12966 behavior in some cases where the value_type of the sequence is not an
12967 integral type.  For example consider:
12968 </p>
12969 <blockquote><pre>     pair&lt;char, char&gt;                     p('a', 'b');
12970      vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
12971 </pre></blockquote>
12972 <p>
12973 The second line of this snippet is likely an error.  Solution A catches
12974 the error and refuses to compile.  The reason is that there is no
12975 specialization of the member template constructor that looks like:
12976 </p>
12977 <pre>template &lt;&gt;
12978 template &lt;&gt;
12979 vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;::vector(char, char) { ... }
12980 </pre>
12981
12982 <p>
12983 So the expression binds to the unspecialized member template
12984 constructor, and then fails (compile time) because char is not an
12985 InputIterator.
12986 </p>
12987
12988 <p>
12989 Solution B compiles the above example though.  'a' is casted to an
12990 unsigned integral type and used to size the outer vector.  'b' is
12991 static casted to the inner vector using it's explicit constructor:
12992 </p>
12993
12994 <pre>explicit vector(size_type n);
12995 </pre>
12996
12997 <p>
12998 and so you end up with a static_cast&lt;size_type&gt;('a') by
12999 static_cast&lt;size_type&gt;('b') matrix.
13000 </p>
13001
13002 <p>
13003 It is certainly possible that this is what the coder intended.  But the
13004 explicit qualifier on the inner vector has been thwarted at any rate.
13005 </p>
13006
13007 <p>
13008 The standard is not clear whether the expression:
13009 </p>
13010
13011 <pre>     vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
13012 </pre>
13013
13014 <p>
13015 (and similar expressions) are:
13016 </p>
13017
13018 <ol>
13019 <li>  undefined behavior.</li>
13020 <li>  illegal and must be rejected.</li>
13021 <li>  legal and must be accepted.</li>
13022 </ol>
13023
13024 <p>My preference is listed in the order presented.</p>
13025
13026 <p>There are still other techniques for implementing the requirements of
13027 paragraphs 9-11, namely the "restricted template technique" (e.g.
13028 enable_if).  This technique is the most compact and easy way of coding
13029 the requirements, and has the behavior of #2 (rejects the above
13030 expression).
13031 </p>
13032
13033 <p>
13034 Choosing 1 would allow all implementation techniques I'm aware of.
13035 Choosing 2 would allow only solution 'A' and the enable_if technique.
13036 Choosing 3 would allow only solution 'B'.
13037 </p>
13038
13039 <p>
13040 Possible wording for a future standard if we wanted to actively reject
13041 the expression above would be to change "static_cast" in paragraphs
13042 9-11 to "implicit_cast" where that is defined by:
13043 </p>
13044
13045 <blockquote>
13046 <pre>template &lt;class T, class U&gt;
13047 inline
13048 T implicit_cast(const U&amp; u)
13049 {
13050      return u;
13051 }
13052 </pre>
13053 </blockquote>
13054
13055 <p><b>Proposed resolution:</b></p>
13056
13057 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:
13058
13059 <p>For every sequence defined in this clause and in clause lib.strings:</p>
13060
13061 <ul>
13062   <li>
13063     <p>If the constructor</p>
13064        <pre>       template &lt;class InputIterator&gt;
13065        X(InputIterator f, InputIterator l,
13066          const allocator_type&amp; a = allocator_type())
13067        </pre>
13068     <p>is called with a type InputIterator that does not qualify as
13069     an input iterator, then the constructor will behave as if the
13070     overloaded constructor:</p>
13071        <pre>       X(size_type, const value_type&amp; = value_type(),
13072          const allocator_type&amp; = allocator_type())
13073        </pre>
13074     <p>were called instead, with the arguments static_cast&lt;size_type&gt;(f), l and a, respectively.</p>
13075   </li>
13076
13077   <li>
13078     <p>If the member functions of the forms:</p>
13079        <pre>       template &lt;class InputIterator&gt;          //  such as  insert()
13080        rt fx1(iterator p, InputIterator f, InputIterator l);
13081
13082        template &lt;class InputIterator&gt;          //  such as  append(), assign()
13083        rt fx2(InputIterator f, InputIterator l);
13084
13085        template &lt;class InputIterator&gt;          //  such as  replace()
13086        rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l);
13087        </pre>
13088     <p>are called with a type InputIterator that does not qualify as
13089     an input iterator, then these functions will behave as if the
13090     overloaded member functions:</p>
13091        <pre>       rt fx1(iterator, size_type, const value_type&amp;);
13092
13093        rt fx2(size_type, const value_type&amp;);
13094
13095        rt fx3(iterator, iterator, size_type, const value_type&amp;);
13096        </pre>
13097     <p>were called instead, with the same arguments.</p>
13098   </li>
13099 </ul>
13100
13101 <p>In the previous paragraph the alternative binding will fail if f
13102 is not implicitly convertible to X::size_type or if l is not implicitly
13103 convertible to X::value_type.</p>
13104
13105 <p>
13106 The extent to which an implementation determines that a type cannot be
13107 an input iterator is unspecified, except that as a minimum integral
13108 types shall not qualify as input iterators.
13109 </p>
13110
13111
13112
13113 <p><i>[
13114 Kona: agreed that the current standard requires <tt>v('a', 'b')</tt>
13115 to be accepted, and also agreed that this is surprising behavior.  The
13116 LWG considered several options, including something like
13117 implicit_cast, which doesn't appear to be quite what we want.  We
13118 considered Howards three options: allow acceptance or rejection,
13119 require rejection as a compile time error, and require acceptance.  By
13120 straw poll (1-6-1), we chose to require a compile time error.
13121 Post-Kona: Howard provided wording.
13122 ]</i></p>
13123
13124 <p><i>[
13125 Sydney: The LWG agreed with this general direction, but there was some
13126 discomfort with the wording in the original proposed resolution.
13127 Howard submitted new wording, and we will review this again in
13128 Redmond.
13129 ]</i></p>
13130
13131 <p><i>[Redmond: one very small change in wording: the first argument
13132   is cast to size_t.  This fixes the problem of something like
13133   <tt>vector&lt;vector&lt;int&gt; &gt;(5, 5)</tt>, where int is not
13134   implicitly convertible to the value type.]</i></p>
13135
13136 <p><b>Rationale:</b></p>
13137 <p>The proposed resolution fixes:</p>
13138
13139 <pre>  vector&lt;int&gt; v(10, 1);
13140 </pre>
13141
13142 <p>
13143 since as integral types 10 and 1 must be disqualified as input
13144 iterators and therefore the (size,value) constructor is called (as
13145 if).</p>
13146
13147 <p>The proposed resolution breaks:</p>
13148
13149 <pre>  vector&lt;vector&lt;T&gt; &gt; v(10, 1);
13150 </pre>
13151
13152 <p>
13153 because the integral type 1 is not *implicitly* convertible to
13154 vector&lt;T&gt;.  The wording above requires a diagnostic.</p>
13155
13156 <p>
13157 The proposed resolution leaves the behavior of the following code
13158 unspecified.
13159 </p>
13160
13161 <pre>  struct A
13162   {
13163     operator int () const {return 10;}
13164   };
13165
13166   struct B
13167   {
13168     B(A) {}
13169   };
13170
13171   vector&lt;B&gt; v(A(), A());
13172 </pre>
13173
13174 <p>
13175 The implementation may or may not detect that A is not an input
13176 iterator and employee the (size,value) constructor.  Note though that
13177 in the above example if the B(A) constructor is qualified explicit,
13178 then the implementation must reject the constructor as A is no longer
13179 implicitly convertible to B.
13180 </p>
13181 <hr>
13182 <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>
13183 <p>
13184 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
13185 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.
13186 </p>
13187 <p><b>Proposed resolution:</b></p>
13188 <p>
13189 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
13190 <tt>fpos&lt;stateT&gt;::state()</tt> to const.
13191 </p>
13192 <hr>
13193 <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>
13194 <p>
13195 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
13196 basic_ostream&lt;charT, traits&gt;::sentry::operator bool() is declared
13197 as non const, but in section 27.6.2.3, in synopsis it is declared
13198 const.
13199 </p>
13200 <p><b>Proposed resolution:</b></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, change the declaration
13203 of <tt>sentry::operator bool()</tt> to const.
13204 </p>
13205 <hr>
13206 <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>
13207 <p>
13208 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
13209 basic_filebuf&lt;charT, traits&gt;::close(), overflow(EOF) is used twice;
13210 should be overflow(traits::eof()).
13211 </p>
13212 <p><b>Proposed resolution:</b></p>
13213 <p>
13214 Change overflow(EOF) to overflow(traits::eof()).
13215 </p>
13216 <hr>
13217 <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>
13218 <p>
13219 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
13220 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>.
13221 </p>
13222 <p><b>Proposed resolution:</b></p>
13223
13224 <p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away
13225  constness. The other two places are stylistic: we could change the
13226  C-style casts to const_cast. Post-Sydney: Howard provided wording.
13227 ]</i></p>
13228
13229 <p>Change 27.8.1.7/1 from:</p>
13230 <blockquote>
13231   Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
13232 </blockquote>
13233
13234 <p>to:</p>
13235 <blockquote>
13236   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
13237 </blockquote>
13238
13239 <p>Change 27.8.1.10/1 from:</p>
13240 <blockquote>
13241   Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
13242 </blockquote>
13243
13244 <p>to:</p>
13245 <blockquote>
13246   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
13247 </blockquote>
13248
13249 <p>Change 27.8.1.13/1 from:</p>
13250 <blockquote>
13251   Returns: &amp;sb.
13252 </blockquote>
13253
13254 <p>to:</p>
13255 <blockquote>
13256   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
13257 </blockquote>
13258
13259
13260
13261 <hr>
13262 <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>
13263 <p>
13264 The standard places no restrictions at all on the reference type
13265 of input, output, or forward iterators (for forward iterators it
13266 only specifies that *x must be value_type&amp; and doesn't mention
13267 the reference type).  Bidirectional iterators' reference type is
13268 restricted only by implication, since the base iterator's
13269 reference type is used as the return type of reverse_iterator's
13270 operator*, which must be T&amp; in order to be a conforming forward
13271 iterator.
13272 </p>
13273
13274 <p>
13275 Here's what I think we ought to be able to expect from an input
13276 or forward iterator's reference type R, where a is an iterator
13277 and V is its value_type
13278 </p>
13279
13280 <ul>
13281   <li>
13282       *a is convertible to R
13283   </li>
13284
13285   <li>
13286       R is convertible to V
13287   </li>
13288
13289   <li>
13290       static_cast&lt;V&gt;(static_cast&lt;R&gt;(*a)) is equivalent to
13291       static_cast&lt;V&gt;(*a)
13292   </li>
13293 </ul>
13294
13295 <p>A mutable forward iterator ought to satisfy, for x of type V:</p>
13296   <li>
13297       { R r = *a; r = x; } is equivalent to *a = x;
13298   </li>
13299
13300 <p>
13301 I think these requirements capture existing container iterators
13302 (including vector&lt;bool&gt;'s), but render istream_iterator invalid;
13303 its reference type would have to be changed to a constant
13304 reference.
13305 </p>
13306
13307
13308 <p>
13309 (Jeremy Siek) During the discussion in Sydney, it was felt that a
13310 simpler long term solution for this was needed. The solution proposed
13311 was to require <tt>reference</tt> to be the same type as <tt>*a</tt>
13312 and <tt>pointer</tt> to be the same type as <tt>a-&gt;</tt>.  Most
13313 iterators in the Standard Library already meet this requirement. Some
13314 iterators are output iterators, and do not need to meet the
13315 requirement, and others are only specified through the general
13316 iterator requirements (which will change with this resolution). The
13317 sole case where there is an explicit definition of the reference type
13318 that will need to change is <tt>istreambuf_iterator</tt> which returns
13319 <tt>charT</tt> from <tt>operator*</tt> but has a reference type of
13320 <tt>charT&amp;</tt>. We propose changing the reference type of
13321 <tt>istreambuf_iterator</tt> to <tt>charT</tt>.
13322 </p>
13323
13324 <p>The other option for resolving the issue with <tt>pointer</tt>,
13325   mentioned in the note below, is to remove <tt>pointer</tt>
13326   altogether. I prefer placing requirements on <tt>pointer</tt> to
13327   removing it for two reasons. First, <tt>pointer</tt> will become
13328   useful for implementing iterator adaptors and in particular,
13329   <tt>reverse_iterator</tt> will become more well defined. Second,
13330   removing <tt>pointer</tt> is a rather drastic and publicly-visible
13331   action to take.</p>
13332
13333 <p>The proposed resolution technically enlarges the requirements for
13334 iterators, which means there are existing iterators (such as
13335 <tt>istreambuf_iterator</tt>, and potentially some programmer-defined
13336 iterators) that will no longer meet the requirements. Will this break
13337 existing code? The scenario in which it would is if an algorithm
13338 implementation (say in the Standard Library) is changed to rely on
13339 <tt>iterator_traits::reference</tt>, and then is used with one of the
13340 iterators that do not have an appropriately defined
13341 <tt>iterator_traits::reference</tt>.
13342 </p>
13343
13344
13345 <p>The proposed resolution makes one other subtle change. Previously,
13346 it was required that output iterators have a <tt>difference_type</tt>
13347 and <tt>value_type</tt> of <tt>void</tt>, which means that a forward
13348 iterator could not be an output iterator. This is clearly a mistake,
13349 so I've changed the wording to say that those types may be
13350 <tt>void</tt>.
13351 </p>
13352
13353 <p><b>Proposed resolution:</b></p>
13354
13355 <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>
13356
13357 <blockquote>
13358 be defined as the iterator's difference type, value type and iterator
13359 category, respectively.
13360 </blockquote>
13361
13362 <p>add</p>
13363
13364 <blockquote>
13365 In addition, the types
13366 <pre>iterator_traits&lt;Iterator&gt;::reference
13367 iterator_traits&lt;Iterator&gt;::pointer
13368 </pre>
13369 must be defined as the iterator's reference and pointer types, that
13370 is, the same type as the type of <tt>*a</tt> and <tt>a-&gt;</tt>,
13371 respectively.
13372 </blockquote>
13373
13374 <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>
13375
13376 <blockquote>
13377 In the case of an output iterator, the types
13378 <pre>iterator_traits&lt;Iterator&gt;::difference_type
13379 iterator_traits&lt;Iterator&gt;::value_type
13380 </pre>
13381 are both defined as <tt>void</tt>.
13382 </blockquote>
13383
13384 <p>to:</p>
13385 <blockquote>
13386 In the case of an output iterator, the types
13387 <pre>iterator_traits&lt;Iterator&gt;::difference_type
13388 iterator_traits&lt;Iterator&gt;::value_type
13389 iterator_traits&lt;Iterator&gt;::reference
13390 iterator_traits&lt;Iterator&gt;::pointer
13391 </pre>
13392 may be defined as <tt>void</tt>.
13393 </blockquote>
13394
13395 <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>
13396 <blockquote>
13397 <pre>typename traits::off_type, charT*, charT&amp;&gt;
13398 </pre>
13399 </blockquote>
13400 <p>to:</p>
13401 <blockquote>
13402 <pre>typename traits::off_type, charT*, charT&gt;
13403 </pre>
13404 </blockquote>
13405
13406 <p><i>[
13407 Redmond: there was concern in Sydney that this might not be the only place
13408 where things were underspecified and needed to be changed.  Jeremy
13409 reviewed iterators in the standard and confirmed that nothing else
13410 needed to be changed.
13411 ]</i></p>
13412
13413 <hr>
13414 <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>
13415 <p>
13416 Table 76, the random access iterator requirement table, says that the
13417 return type of a[n] must be "convertible to T".  When an iterator's
13418 value_type T is an abstract class, nothing is convertible to T.
13419 Surely this isn't an intended restriction?
13420 </p>
13421 <p><b>Proposed resolution:</b></p>
13422 <p>
13423 Change the return type to "convertible to T const&amp;".
13424 </p>
13425 <hr>
13426 <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>
13427 <p>Original text:</p>
13428 <blockquote>
13429 The macro offsetof accepts a restricted set of type arguments in this
13430 International Standard. type shall be a POD structure or a POD union
13431 (clause 9). The result of applying the offsetof macro to a field that
13432 is a static data member or a function member is undefined."
13433 </blockquote>
13434
13435 <p>Revised text:</p>
13436 <blockquote>
13437 "If type is not a POD structure or a POD union the results are undefined."
13438 </blockquote>
13439
13440 <p>
13441 Looks to me like the revised text should have replaced only the second
13442 sentence. It doesn't make sense standing alone.
13443 </p>
13444
13445 <p><b>Proposed resolution:</b></p>
13446 <p>Change 18.1, paragraph 5, to:</p>
13447
13448 <blockquote>
13449 The macro offsetof accepts a restricted set of type arguments in this
13450 International Standard.  If type is not a POD structure or a POD union
13451 the results are undefined.  The result of applying the offsetof macro
13452 to a field that is a static data member or a function member is
13453 undefined."
13454 </blockquote>
13455 <hr>
13456 <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>
13457 <pre>  pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
13458                                     ios_base::openmode);
13459 </pre>
13460 <p>
13461 is obliged to fail if nothing has been inserted into the stream. This
13462 is unnecessary and undesirable. It should be permissible to seek to
13463 an effective offset of zero.</p>
13464
13465 <p><i>[
13466  Sydney: Agreed that this is an annoying problem: seeking to zero should be
13467  legal. Bill will provide wording.
13468 ]</i></p>
13469
13470 <p><b>Proposed resolution:</b></p>
13471 <p>Change the sentence from:</p>
13472 <blockquote>
13473 For a sequence to be positioned, if its next pointer (either
13474 gptr() or pptr()) is a null pointer, the positioning operation
13475 fails.
13476 </blockquote>
13477
13478 <p>to:</p>
13479
13480 <blockquote>
13481 For a sequence to be positioned, if its next pointer (either
13482 gptr() or pptr()) is a null pointer and the new offset newoff
13483 is nonzero, the positioning operation fails.
13484 </blockquote>
13485 <hr>
13486 <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>
13487 <p>
13488 Both cerr::tie() and wcerr::tie() are obliged to be null at program
13489 startup. This is overspecification and overkill. It is both traditional
13490 and useful to tie cerr to cout, to ensure that standard output is drained
13491 whenever an error message is written. This behavior should at least be
13492 permitted if not required. Same for wcerr::tie().
13493 </p>
13494 <p><b>Proposed resolution:</b></p>
13495
13496 <p>Add to the description of cerr:</p>
13497 <blockquote>
13498 After the object cerr is initialized, cerr.tie() returns &amp;cout.
13499 Its state is otherwise the same as required for basic_ios&lt;char&gt;::init
13500 (lib.basic.ios.cons).
13501 </blockquote>
13502
13503 <p>Add to the description of wcerr:</p>
13504
13505 <blockquote>
13506 After the object wcerr is initialized, wcerr.tie() returns &amp;wcout.
13507 Its state is otherwise the same as required for basic_ios&lt;wchar_t&gt;::init
13508 (lib.basic.ios.cons).
13509 </blockquote>
13510
13511 <p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just
13512   permit, cout and cerr to be tied on startup.  Pre-Redmond: Bill will
13513   provide wording.]</i></p>
13514 <hr>
13515 <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>
13516 <p>
13517 The constructor from unsigned long says it initializes "the first M
13518 bit positions to the corresponding bit values in val. M is the smaller
13519 of N and the value CHAR_BIT * sizeof(unsigned long)."
13520 </p>
13521
13522 <p>
13523 Object-representation vs. value-representation strikes again. CHAR_BIT *
13524 sizeof (unsigned long) does not give us the number of bits an unsigned long
13525 uses to hold the value. Thus, the first M bit position above is not
13526 guaranteed to have any corresponding bit values in val.
13527 </p>
13528 <p><b>Proposed resolution:</b></p>
13529 <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
13530   N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
13531   "<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in
13532   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
13533   long</tt>."
13534 </p>
13535 <hr>
13536 <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>
13537 <p>
13538 The second parameters of the non-default constructor and of the open
13539 member function for basic_fstream, named "mode", are optional
13540 according to the class declaration in 27.8.1.11 [lib.fstream].  The
13541 specifications of these members in 27.8.1.12 [lib.fstream.cons] and
13542 27.8.1.13 lib.fstream.members] disagree with this, though the
13543 constructor declaration has the "explicit" function-specifier implying
13544 that it is intended to be callable with one argument.
13545 </p>
13546 <p><b>Proposed resolution:</b></p>
13547 <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>
13548 <pre>  explicit basic_fstream(const char* s, ios_base::openmode mode);
13549 </pre>
13550 <p>to</p>
13551 <pre>  explicit basic_fstream(const char* s,
13552                          ios_base::openmode mode = ios_base::in|ios_base::out);
13553 </pre>
13554 <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>
13555 <pre>  void open(const char*s, ios_base::openmode mode);
13556 </pre>
13557 <p>to</p>
13558   void open(const char*s,
13559             ios_base::openmode mode = ios_base::in|ios_base::out);
13560 <hr>
13561 <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>
13562 <p>
13563 Template time_get currently contains difficult, if not impossible,
13564 requirements for do_date_order, do_get_time, and do_get_date. All require
13565 the implementation to scan a field generated by the %x or %X conversion
13566 specifier in strftime. Yes, do_date_order can always return no_order, but
13567 that doesn't help the other functions. The problem is that %x can be
13568 nearly anything, and it can vary widely with locales. It's horribly
13569 onerous to have to parse "third sunday after Michaelmas in the year of
13570 our Lord two thousand and three," but that's what we currently ask of
13571 do_get_date. More practically, it leads some people to think that if
13572 %x produces 10.2.04, we should know to look for dots as separators. Still
13573 not easy.
13574 </p>
13575
13576 <p>
13577 Note that this is the <i>opposite</i> effect from the intent stated in the
13578 footnote earlier in this subclause:
13579 </p>
13580
13581 <blockquote>
13582 "In other words, user confirmation is required for reliable parsing of
13583 user-entered dates and times, but machine-generated formats can be
13584 parsed reliably. This allows parsers to be aggressive about interpreting
13585 user variations on standard formats."
13586 </blockquote>
13587
13588 <p>
13589 We should give both implementers and users an easier and more reliable
13590 alternative: provide a (short) list of alternative delimiters and say
13591 what the default date order is for no_order. For backward compatibility,
13592 and maximum latitude, we can permit an implementation to parse whatever
13593 %x or %X generates, but we shouldn't require it.
13594 </p>
13595 <p><b>Proposed resolution:</b></p>
13596
13597 <p><b>In the description:</b></p>
13598 <pre>iter_type do_get_time(iter_type s, iter_type end, ios_base&amp; str,
13599         ios_base::iostate&amp; err, tm* t) const;
13600 </pre>
13601
13602 <p>
13603 2 Effects: Reads characters starting at suntil it has extracted those
13604 struct tm members, and remaining format characters, used by
13605 time_put&lt;&gt;::put to produce the format specified by 'X', or until it
13606 encounters an error or end of sequence.
13607 </p>
13608
13609 <p><b>change:</b> 'X'</p>
13610
13611 <p><b>to:</b> "%H:%M:%S"</p>
13612
13613
13614 <p>Change</p>
13615 <pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
13616         ios_base::iostate&amp; err, tm* t) const;
13617
13618 4 Effects: Reads characters starting at s until it has extracted those
13619 struct tm members, and remaining format characters, used by
13620 time_put&lt;&gt;::put to produce the format specified by 'x', or until it
13621 encounters an error.
13622 </pre>
13623
13624 <p>to</p>
13625 iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
13626         ios_base::iostate&amp; err, tm* t) const;
13627
13628 4 Effects: Reads characters starting at s until it has extracted those
13629 struct tm members, and remaining format characters, used by
13630 time_put&lt;&gt;::put to produce one of the following formats, or until it
13631 encounters an error. The format depends on the value returned by
13632 date_order() as follows:
13633
13634         date_order()  format
13635
13636         no_order      "%m/%d/%y"
13637         dmy           "%d/%m/%y"
13638         mdy           "%m/%d/%y"
13639         ymd           "%y/%m/%d"
13640         ydm           "%y/%d/%m"
13641
13642 An implementation may also accept additional implementation-defined formats.
13643 <pre></pre>
13644
13645 <p><i>[Redmond: agreed that this is a real problem.  The solution is
13646   probably to match C99's parsing rules.  Bill provided wording.
13647 ]</i></p>
13648
13649 <hr>
13650 <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>
13651
13652 <p>To add slightly more convenience to vector&lt;T&gt; and map&lt;Key,T&gt; we should consider to add</p>
13653 <ol>
13654 <li> add vector&lt;T&gt;::data() member (const and non-const version)
13655 semantics: if( empty() ) return 0; else return buffer_;</li>
13656 <li> add map&lt;Key,T&gt;::at( const Key&amp; k ) member (const and non-const version)
13657 <i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
13658 </ol>
13659
13660 <p>Rationale:</p>
13661
13662 <ul>
13663 <li>To obtain a pointer to the vector's buffer, one must use either
13664 operator[]() (which can give undefined behavior for empty vectors) or
13665 at() (which will then throw if the vector is empty). </li>
13666 <li>tr1::array&lt;T,sz&gt; already has a data() member</li>
13667 <li>e cannot use operator[]() when T is not DefaultDonstructible</li>
13668 <li>Neither when the map is const.</li>
13669 <li>when we want to make sure we don't add an element accidently</li>
13670 <li>when it should be considered an error if a key is not in the map</li>
13671 </ul>
13672
13673 <p><b>Proposed resolution:</b></p>
13674 <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>
13675   synopsis after "element access" and before "modifiers":</p>
13676 <pre>  // <i>[lib.vector.data] data access</i>
13677   pointer       data();
13678   const_pointer data() const;
13679 </pre>
13680
13681 <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>
13682 <blockquote>
13683 <p>23.2.4.x <tt>vector</tt> data access</p>
13684 <pre>   pointer       data();
13685    const_pointer data() const;
13686 </pre>
13687 <p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
13688    range.  For a non-empty vector, data() == &amp;front().</p>
13689 <p><b>Complexity:</b> Constant time.</p>
13690 <p><b>Throws:</b> Nothing.</p>
13691 </blockquote>
13692
13693 <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>
13694 synopsis immediately after the line for operator[]:</p>
13695 <pre>  T&amp;       at(const key_type&amp; x);
13696   const T&amp; at(const key_type&amp; x) const;
13697 </pre>
13698
13699 <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>
13700 <blockquote>
13701 <pre>  T&amp;       at(const key_type&amp; x);
13702   const T&amp; at(const key_type&amp; x) const;
13703 </pre>
13704
13705 <p><b>Returns:</b> A reference to the element whose key is equivalent
13706   to x, if such an element is present in the map.</p>
13707 <p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
13708
13709 </blockquote>
13710
13711 <p><b>Rationale:</b></p>
13712 <p>Neither of these additions provides any new functionality but the
13713   LWG agreed that they are convenient, especially for novices.  The
13714   exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
13715   was chosen to match <tt>vector::at</tt>.</p>
13716 <hr>
13717 <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>
13718 <p>C header &lt;iso646.h&gt; defines macros for some operators, such as
13719 not_eq for !=.</p>
13720
13721 <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
13722 clauses 18 through 27, the &lt;cname&gt; C++ header contents are the same
13723 as the C header &lt;name.h&gt;. In particular, table 12 lists
13724 &lt;ciso646&gt; as a C++ header.</p>
13725
13726 <p>I don't find any other mention of &lt;ciso646&gt;, or any mention of
13727 &lt;iso646.h&gt;, in clauses 17 thorough 27. That implies that the
13728 contents of &lt;ciso646&gt; are the same as C header &lt;iso646.h&gt;.</p>
13729
13730 <p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
13731 "Header &lt;iso646.h&gt;" says that the alternative tokens are not
13732 defined as macros in &lt;ciso646&gt;, but does not mention the contents
13733 of &lt;iso646.h&gt;.</p>
13734
13735 <p>I don't find any normative text to support C.2.2.2.</p>
13736
13737 <p><b>Proposed resolution:</b></p>
13738 <p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
13739   paragraph 6 (the one about functions must be functions):</p>
13740
13741 <blockquote>
13742 <p>Identifiers that are keywords or operators in C++ shall not be defined
13743 as macros in C++ standard library headers.
13744 [Footnote:In particular, including the standard header &lt;iso646.h&gt;
13745 or &lt;ciso646&gt; has no effect. </p>
13746 </blockquote>
13747
13748 <p><i>[post-Redmond: Steve provided wording.]</i></p>
13749
13750 <hr>
13751 <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>
13752
13753 <p>
13754 Table 37 describes the requirements on Traits::compare() in terms of
13755 those on Traits::lt(). 21.1.3.1, p6 requires char_traits&lt;char&gt;::lt()
13756 to yield the same result as operator&lt;(char, char).
13757 </p>
13758
13759 <p>
13760 Most, if not all, implementations of char_traits&lt;char&gt;::compare()
13761 call memcmp() for efficiency. However, the C standard requires both
13762 memcmp() and strcmp() to interpret characters under comparison as
13763 unsigned, regardless of the signedness of char. As a result, all
13764 these char_traits implementations fail to meet the requirement
13765 imposed by Table 37 on compare() when char is signed.
13766 </p>
13767
13768
13769 <p>Read email thread starting with c++std-lib-13499 for more. </p>
13770 <p><b>Proposed resolution:</b></p>
13771
13772
13773 <p>Change 21.1.3.1, p6 from</p>
13774 <blockquote>
13775     The two-argument members assign, eq, and lt are defined identically
13776     to the built-in operators =, ==, and &lt; respectively.
13777 </blockquote>
13778 <p>to</p>
13779 <blockquote>
13780   The two-argument member assign is defined identically to
13781   the built-in operator =. The two
13782   argument members eq and lt are defined identically to
13783   the built-in operators == and &lt; for type unsigned char.
13784 </blockquote>
13785
13786 <p><i>[Redmond: The LWG agreed with this general direction, but we
13787   also need to change <tt>eq</tt> to be consistent with this change.
13788   Post-Redmond: Martin provided wording.]</i></p>
13789
13790 <hr>
13791 <a name="468"><h3>468.&nbsp;unexpected consequences of ios_base::operator void*()</h3></a><p><b>Section:</b>&nbsp;27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
13792
13793 <p>The program below is required to compile but when run it typically
13794 produces unexpected results due to the user-defined conversion from
13795 std::cout or any object derived from basic_ios to void*.
13796 </p>
13797
13798 <pre>    #include &lt;cassert&gt;
13799     #include &lt;iostream&gt;
13800
13801     int main ()
13802     {
13803         assert (std::cin.tie () == std::cout);
13804         // calls std::cout.ios::operator void*()
13805     }
13806 </pre>
13807
13808 <p><b>Proposed resolution:</b></p>
13809
13810 <p>
13811 Replace std::basic_ios&lt;charT, traits&gt;::operator void*() with another
13812 conversion operator to some unspecified type that is guaranteed not
13813 to be convertible to any other type except for bool (a pointer-to-member
13814 might be one such suitable type). In addition, make it clear that the
13815 pointer type need not be a pointer to a complete type and when non-null,
13816 the value need not be valid.
13817 </p>
13818
13819 <p>Specifically, change in [lib.ios] the signature of</p>
13820 <pre>    operator void*() const;
13821 </pre>
13822 <p>to</p>
13823 <pre>    operator unspecified-bool-type() const;
13824 </pre>
13825 <p>and change [lib.iostate.flags], p1 from</p>
13826 <pre>    operator void*() const;
13827 </pre>
13828 <p>to</p>
13829 <pre>operator unspecified-bool-type() const;
13830
13831      -1- Returns: if fail() then a value that will evaluate false in a
13832       boolean context; otherwise a value that will evaluate true in a
13833       boolean context. The value type returned shall not be
13834       convertible to int.
13835
13836      -2- [Note: This conversion can be used in contexts where a bool
13837       is expected (e.g., an if condition); however, implicit
13838       conversions (e.g., to int) that can occur with bool are not
13839       allowed, eliminating some sources of user error. One possible
13840       implementation choice for this type is pointer-to-member.  - end
13841       note]
13842 </pre>
13843
13844 <p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
13845 <p><i>[Lillehammer: Doug provided revised wording for
13846   "unspecified-bool-type".]</i></p>
13847
13848 <hr>
13849 <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>
13850
13851 <p>
13852 The overloads of relational operators for vector&lt;bool&gt; specified
13853 in [lib.vector.bool] are redundant (they are semantically identical
13854 to those provided for the vector primary template) and may even be
13855 diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation
13856 in c++std-lib-13647).
13857 </p>
13858
13859 <p><b>Proposed resolution:</b></p>
13860 <p>
13861 Remove all overloads of overloads of relational operators for
13862 vector&lt;bool&gt; from [lib.vector.bool].
13863 </p>
13864 <hr>
13865 <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>
13866
13867 <p>
13868 I think Footnote 297 is confused. The paragraph it applies to seems
13869 quite clear in that widen() is only called if the object is not a char
13870 stream (i.e., not basic_ostream&lt;char&gt;), so it's irrelevant what the
13871 value of widen(c) is otherwise.
13872 </p>
13873 <p><b>Proposed resolution:</b></p>
13874 <p>
13875 I propose to strike the Footnote.
13876 </p>
13877 <hr>
13878 <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>
13879 <p>
13880 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>,
13881 the non-template assign() function has the signature</p>
13882
13883 <pre>  void assign( size_type n, const T&amp; t );
13884 </pre>
13885
13886 <p>The type, T, is not defined in this context.</p>
13887 <p><b>Proposed resolution:</b></p>
13888 <p>Replace "T" with "value_type".</p>
13889 <p>----- End of document -----</p>
13890 </body></html>