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

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
   2 <html><head><title>C++ Standard Library Defect Report List</title></head>
   3
   4 <body bgcolor="#ffffff" text="#000000">
   5 <table>
   6 <tbody><tr>
   7 <td align="left">Doc. no.</td>
   8 <td align="left">N1754=05-0014</td>
   9 </tr>
  10 <tr>
  11 <td align="left">Date:</td>
  12 <td align="left">2005-01-17</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">Matt Austern &lt;austern@apple.com&gt;</td>
  21 </tr>
  22 </tbody></table>
  23 <h1>C++ Standard Library Defect Report List (Revision 34)</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/papers/2005/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/papers/2005/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/papers/2005/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/papers/2005/lwg-active.html">Library Active Issues List</a></li>
  34       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#DR">DR</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>, or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#RR">RR</a>. See the
  39   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/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>R34:
  46 2005-01 mid-term mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#494">494</a>.
  47 </li>
  48 <li>R33:
  49 2004-11 post-Redmond mailing.  Reflections actions taken in Redmond.
  50 </li>
  51 <li>R32:
  52 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
  53 new issues received after the 2004-07 mailing.  Added
  54 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#481">481</a>.
  55 </li>
  56 <li>R31:
  57 2004-07 mid-term mailing: reflects new proposed resolutions and
  58 new issues received after the post-Sydney mailing.  Added
  59 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#478">478</a>.
  60 </li>
  61 <li>R30:
  62 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
  63 Voted all "Ready" issues from R29 into the working paper.
  64 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#462">462</a>.
  65 </li>
  66 <li>R29:
  67 Pre-Sydney mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#457">457</a>.
  68 </li>
  69 <li>R28:
  70 Post-Kona mailing: reflects decisions made at the Kona meeting.
  71 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#432">432</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#440">440</a>.
  72 </li>
  73 <li>R27:
  74 Pre-Kona mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#431">431</a>.
  75 </li>
  76 <li>R26:
  77 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
  78 All issues in Ready status were voted into DR status.  All issues in
  79 DR status were voted into WP status.
  80 </li>
  81 <li>R25:
  82 Pre-Oxford mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#390">390</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#402">402</a>.
  83 </li>
  84 <li>R24:
  85 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
  86 meeting.  All Ready issues from R23 with the exception of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#253">253</a>, which has been given a new proposed resolution, were
  87 moved to DR status.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#389">389</a>.  (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#389">389</a> were discussed
  88 at the meeting.)  Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#225">225</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining
  89 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#226">226</a> involve wording.
  90 </li>
  91 <li>R23:
  92 Pre-Santa Cruz mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#367">367</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#382">382</a>.
  93 Moved issues in the TC to TC status.
  94 </li>
  95 <li>R22:
  96 Post-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#366">366</a>.
  97 </li>
  98 <li>R21:
  99 Pre-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#361">361</a>.
 100 </li>
 101 <li>R20:
 102 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 103 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#336">336</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#350">350</a>, of which issues
 104 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#347">347</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#350">350</a> were added since Redmond, hence
 105 not discussed at the meeting.
 106
 107 All Ready issues were moved to DR status, with the exception of issues
 108 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#241">241</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#267">267</a>.
 109
 110 Noteworthy issues discussed at Redmond include
 111 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#120">120</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#233">233</a>,
 112 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#323">323</a>.
 113 </li>
 114 <li>R19:
 115 Pre-Redmond mailing.  Added new issues
 116 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#323">323</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#335">335</a>.
 117 </li>
 118 <li>R18:
 119 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
 120 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#312">312</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#317">317</a>, and discussed
 121 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#271">271</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#314">314</a>.
 122
 123 Changed status of issues
 124 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#103">103</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#118">118</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#136">136</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#153">153</a>
 125 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#165">165</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#171">171</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#183">183</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#184">184</a>
 126 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#185">185</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#186">186</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#214">214</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#221">221</a>
 127 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#234">234</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#237">237</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#243">243</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#248">248</a>
 128 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#251">251</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#252">252</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#256">256</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#260">260</a>
 129 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#261">261</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#262">262</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#263">263</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#265">265</a>
 130 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#268">268</a>
 131 to DR.
 132
 133 Changed status of issues
 134 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#49">49</a>  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#109">109</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#117">117</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#182">182</a>
 135 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#228">228</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#230">230</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#232">232</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#235">235</a>
 136 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#238">238</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#241">241</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#242">242</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#250">250</a>
 137 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#259">259</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#264">264</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#266">266</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#267">267</a>
 138 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#271">271</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#272">272</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#273">273</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#275">275</a>
 139 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#281">281</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#284">284</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#285">285</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#286">286</a>
 140 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#288">288</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#292">292</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#295">295</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#297">297</a>
 141 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#298">298</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#301">301</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#303">303</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#306">306</a>
 142 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#307">307</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#308">308</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#312">312</a>
 143 to Ready.
 144
 145 Closed issues
 146 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#111">111</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#287">287</a>
 147 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#289">289</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#293">293</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#302">302</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#313">313</a>
 148 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#314">314</a>
 149 as NAD.
 150
 151 </li>
 152 <li>R17:
 153 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 154 resolutions for issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#267">267</a>.
 155 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#278">278</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#311">311</a>.
 156 </li>
 157 <li>R16:
 158 post-Toronto mailing; reflects actions taken in Toronto. Added new
 159 issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#265">265</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#277">277</a>.  Changed status of issues
 160 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#19">19</a>,
 161 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#61">61</a>,
 162 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#108">108</a>,
 163 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#115">115</a>,
 164 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#129">129</a>,
 165 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#142">142</a>,
 166 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#147">147</a>,
 167 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#170">170</a>,
 168 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#208">208</a>,
 169 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#211">211</a>,
 170 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#220">220</a>,
 171 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#224">224</a>,
 172 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#227">227</a> to "DR".  Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#23">23</a>. Reopened
 173 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#2">2</a> and
 174 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#17">17</a>. Fixed
 175 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#70">70</a>: signature should be changed both places it
 176 appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#160">160</a>: previous version didn't fix
 177 the bug in enough places.
 178 </li>
 179 <li>R15:
 180 pre-Toronto mailing. Added issues
 181 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#233">233</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#264">264</a>. Some small HTML formatting
 182 changes so that we pass Weblint tests.
 183 </li>
 184 <li>R14:
 185 post-Tokyo II mailing; reflects committee actions taken in
 186 Tokyo. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#228">228</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#232">232</a>. (00-0019R1/N1242)
 187 </li>
 188 <li>R13:
 189 pre-Tokyo II updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#212">212</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#227">227</a>.
 190 </li>
 191 <li>R12:
 192 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#199">199</a> to
 193 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
 194 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#29">29</a>.  Add further rationale to issue
 195 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#178">178</a>.
 196 </li>
 197 <li>R11:
 198 post-Kona mailing: Updated to reflect LWG and full committee actions
 199 in Kona (99-0048/N1224). Note changed resolution of issues
 200 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#4">4</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#38">38</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#196">196</a>
 201 to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
 202 "closed" documents.  Changed the proposed resolution of issue
 203 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
 204 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#38">38</a>.
 205 </li>
 206 <li>R10:
 207 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#83">83</a>,
 208 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#92">92</a>,
 209 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#190">190</a> to
 210 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 211 </li>
 212 <li>R9:
 213 pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#140">140</a> to
 214 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
 215 "closed" documents. (99-0030/N1206, 25 Aug 99)
 216 </li>
 217 <li>R8:
 218 post-Dublin mailing. Updated to reflect LWG and full committee actions
 219 in Dublin. (99-0016/N1193, 21 Apr 99)
 220 </li>
 221 <li>R7:
 222 pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#131">131</a>,
 223 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#134">134</a>,
 224 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#137">137</a>,
 225 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#139">139</a> (31 Mar 99)
 226 </li>
 227 <li>R6:
 228 pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#128">128</a>,
 229 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 230 </li>
 231 <li>R5:
 232 update issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#112">112</a>; added issues
 233 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#114">114</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#126">126</a>. Format revisions to prepare
 234 for making list public. (30 Dec 98)
 235 </li>
 236 <li>R4:
 237 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#110">110</a>,
 238 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#113">113</a> added, several
 239 issues corrected. (22 Oct 98)
 240 </li>
 241 <li>R3:
 242 post-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#94">94</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#109">109</a>
 243 added, many issues updated to reflect LWG consensus (12 Oct 98)
 244 </li>
 245 <li>R2:
 246 pre-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#73">73</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#93">93</a> added,
 247 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#17">17</a> updated. (29 Sep 98)
 248 </li>
 249 <li>R1:
 250 Correction to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#55">55</a> resolution, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#60">60</a> code
 251 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#64">64</a> title. (17 Sep 98)
 252 </li>
 253 </ul>
 254 <h2>Defect Reports</h2>
 255 <hr>
 256 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;16 Nov 1997</p>
 257 <p>The change specified in the proposed resolution below did not make
 258 it into the Standard. This change was accepted in principle at the
 259 London meeting, and the exact wording below was accepted at the
 260 Morristown meeting.</p>
 261 <p><b>Proposed resolution:</b></p>
 262 <p>Change 17.4.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a> paragraph 2
 263 from:</p>
 264
 265 <blockquote>
 266   <p>It is unspecified whether a name from the Standard C library
 267   declared with external linkage has either extern "C" or
 268   extern "C++" linkage.</p>
 269 </blockquote>
 270
 271 <p>to:</p>
 272
 273 <blockquote>
 274   <p>Whether a name from the Standard C library declared with external
 275   linkage has extern "C" or extern "C++" linkage
 276   is implementation defined. It is recommended that an implementation
 277   use extern "C++" linkage for this purpose.</p>
 278 </blockquote>
 279 <hr>
 280 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;12 Dec 1997</p>
 281 <p>We appear not to have covered all the possibilities of
 282  exit processing with respect to
 283 atexit registration. <br>
 284 <br>
 285 Example 1: (C and C++)</p>
 286
 287 <pre>    #include &lt;stdlib.h&gt;
 288     void f1() { }
 289     void f2() { atexit(f1); }
 290
 291     int main()
 292     {
 293         atexit(f2); // the only use of f2
 294         return 0; // for C compatibility
 295     }</pre>
 296
 297 <p>At program exit, f2 gets called due to its registration in
 298 main. Running f2 causes f1 to be newly registered during the exit
 299 processing. Is this a valid program? If so, what are its
 300 semantics?</p>
 301
 302 <p>
 303 Interestingly, neither the C standard, nor the C++ draft standard nor
 304 the forthcoming C9X Committee Draft says directly whether you can
 305 register a function with atexit during exit processing.</p>
 306
 307 <p>
 308 All 3 standards say that functions are run in reverse order of their
 309 registration. Since f1 is registered last, it ought to be run first,
 310 but by the time it is registered, it is too late to be first.</p>
 311
 312 <p>If the program is valid, the standards are self-contradictory about
 313 its semantics.</p>
 314
 315 <p>Example 2: (C++ only)</p>
 316
 317 <pre>
 318     void F() { static T t; } // type T has a destructor
 319
 320     int main()
 321     {
 322         atexit(F); // the only use of F
 323     }
 324 </pre>
 325
 326 <p>Function F registered with atexit has a local static variable t,
 327 and F is called for the first time during exit processing. A local
 328 static object is initialized the first time control flow passes
 329 through its definition, and all static objects are destroyed during
 330 exit processing. Is the code valid? If so, what are its semantics?</p>
 331
 332 <p>
 333 Section 18.3 "Start and termination" says that if a function
 334 F is registered with atexit before a static object t is initialized, F
 335 will not be called until after t's destructor completes.</p>
 336
 337 <p>
 338 In example 2, function F is registered with atexit before its local
 339 static object O could possibly be initialized. On that basis, it must
 340 not be called by exit processing until after O's destructor
 341 completes. But the destructor cannot be run until after F is called,
 342 since otherwise the object could not be constructed in the first
 343 place.</p>
 344
 345 <p>If the program is valid, the standard is self-contradictory about
 346 its semantics.</p>
 347
 348 <p>I plan to submit Example 1 as a public comment on the C9X CD, with
 349 a recommendation that the results be undefined. (Alternative: make it
 350 unspecified. I don't think it is worthwhile to specify the case where
 351 f1 itself registers additional functions, each of which registers
 352 still more functions.)</p>
 353
 354 <p>I think we should resolve the situation in the whatever way the C
 355 committee decides. </p>
 356
 357 <p>For Example 2, I recommend we declare the results undefined.</p>
 358
 359 <p><i>[See reflector message lib-6500 for further discussion.]</i></p>
 360
 361 <p><b>Proposed resolution:</b></p>
 362 <p>Change section 18.3/8 from:</p>
 363 <blockquote>
 364   First, objects with static storage duration are destroyed and
 365   functions registered by calling atexit are called. Objects with
 366   static storage duration are destroyed in the reverse order of the
 367   completion of their constructor.  (Automatic objects are not
 368   destroyed as a result of calling exit().) Functions registered with
 369   atexit are called in the reverse order of their registration.  A
 370   function registered with atexit before an object obj1 of static
 371   storage duration is initialized will not be called until obj1's
 372   destruction has completed. A function registered with atexit after
 373   an object obj2 of static storage duration is initialized will be
 374   called before obj2's destruction starts.
 375 </blockquote>
 376 <p>to:</p>
 377 <blockquote>
 378   First, objects with static storage duration are destroyed and
 379   functions registered by calling atexit are called. Non-local objects
 380   with static storage duration are destroyed in the reverse order of
 381   the completion of their constructor. (Automatic objects are not
 382   destroyed as a result of calling exit().) Functions registered with
 383   atexit are called in the reverse order of their registration, except
 384   that a function is called after any previously registered functions
 385   that had already been called at the time it was registered. A
 386   function registered with atexit before a non-local object obj1 of
 387   static storage duration is initialized will not be called until
 388   obj1's destruction has completed. A function registered with atexit
 389   after a non-local object obj2 of static storage duration is
 390   initialized will be called before obj2's destruction starts. A local
 391   static object obj3 is destroyed at the same time it would be if a
 392   function calling the obj3 destructor were registered with atexit at
 393   the completion of the obj3 constructor.
 394 </blockquote>
 395 <p><b>Rationale:</b></p>
 396 <p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
 397 supporting to the proposed resolution.</p>
 398 <hr>
 399 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jack Reeves&nbsp; <b>Date:</b>&nbsp;11 Dec 1997</p>
 400 <p>At the very end of the basic_string class definition is the signature: int
 401 compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
 402 following text this is defined as: returns
 403 basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
 404 basic_string&lt;charT,traits,Allocator&gt;(s,n2); </p>
 405
 406 <p>Since the constructor basic_string(const charT* s, size_type n, const Allocator&amp; a
 407 = Allocator()) clearly requires that s != NULL and n &lt; npos and further states that it
 408 throws length_error if n == npos, it appears the compare() signature above should always
 409 throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
 410 null terminated character array. </p>
 411
 412 <p>This appears to be a typo since the obvious intent is to allow either the call above or
 413 something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
 414
 415 <p>This would imply that what was really intended was two signatures int compare(size_type
 416 pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
 417 charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
 418 <p><b>Proposed resolution:</b></p>
 419 <p>Replace the compare signature in 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>
 420 (at the very end of the basic_string synopsis) which reads:</p>
 421
 422 <blockquote>
 423   <p><tt>int compare(size_type pos1, size_type n1,<br>
 424   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
 425   size_type n2 = npos) const;</tt></p>
 426 </blockquote>
 427
 428 <p>with:</p>
 429
 430 <blockquote>
 431   <p><tt>int compare(size_type pos1, size_type n1,<br>
 432   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s) const;<br>
 433   int compare(size_type pos1, size_type n1,<br>
 434   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
 435   size_type n2) const;</tt></p>
 436 </blockquote>
 437
 438 <p>Replace the portion of 21.3.6.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string::compare"> [lib.string::compare]</a>
 439 paragraphs 5 and 6 which read:</p>
 440
 441 <blockquote>
 442   <p><tt>int compare(size_type pos, size_type n1,<br>
 443   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; charT * s, size_type n2
 444   = npos) const;<br>
 445   </tt>Returns:<tt><br>
 446   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 447   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 448   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
 449 </blockquote>
 450
 451 <p>with:</p>
 452
 453 <blockquote>
 454   <p><tt>int compare(size_type pos, size_type n1,<br>
 455   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s) const;<br>
 456   </tt>Returns:<tt><br>
 457   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 458   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 459   basic_string&lt;charT,traits,Allocator&gt;( s ))<br>
 460   <br>
 461   int compare(size_type pos, size_type n1,<br>
 462   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s,
 463   size_type n2) const;<br>
 464   </tt>Returns:<tt><br>
 465   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 466   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 467   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
 468 </blockquote>
 469
 470 <p>Editors please note that in addition to splitting the signature, the third argument
 471 becomes const, matching the existing synopsis.</p>
 472 <p><b>Rationale:</b></p>
 473 <p>While the LWG dislikes adding signatures, this is a clear defect in
 474 the Standard which must be fixed.&nbsp; The same problem was also
 475 identified in issues 7 (item 5) and 87.</p>
 476 <hr>
 477 <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/papers/2005/lib-strings.html#lib.strings"> [lib.strings]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;15 Dec 1997</p>
 478 <p>(1) In 21.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, the description of template
 479 &lt;class InputIterator&gt; insert(iterator, InputIterator,
 480 InputIterator) makes no sense. It refers to a member function that
 481 doesn't exist. It also talks about the return value of a void
 482 function. </p>
 483
 484 <p>(2) Several versions of basic_string::replace don't appear in the
 485 class synopsis. </p>
 486
 487 <p>(3) basic_string::push_back appears in the synopsis, but is never
 488 described elsewhere.  In the synopsis its argument is const charT,
 489 which doesn't makes much sense; it should probably be charT, or
 490 possible const charT&amp;. </p>
 491
 492 <p>(4) basic_string::pop_back is missing. </p>
 493
 494 <p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
 495 = npos) make no sense. First, it's const charT* in the synopsis and
 496 charT* in the description. Second, given what it says in RETURNS,
 497 leaving out the final argument will always result in an exception
 498 getting thrown. This is paragraphs 5 and 6 of
 499 21.3.6.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string::compare"> [lib.string::compare]</a></p>
 500
 501 <p>(6) In table 37, in section 21.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>,
 502 there's a note for X::move(s, p, n). It says "Copies correctly
 503 even where p is in [s, s+n)". This is correct as far as it goes,
 504 but it doesn't go far enough; it should also guarantee that the copy
 505 is correct even where s in in [p, p+n). These are two orthogonal
 506 guarantees, and neither one follows from the other. Both guarantees
 507 are necessary if X::move is supposed to have the same sort of
 508 semantics as memmove (which was clearly the intent), and both
 509 guarantees are necessary if X::move is actually supposed to be
 510 useful. </p>
 511 <p><b>Proposed resolution:</b></p>
 512 <p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
 513 <br>
 514 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
 515 <br>
 516 ITEM 2:&nbsp; Not a defect; the Standard is clear.. There are ten versions of replace() in
 517 the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
 518 <br>
 519 ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
 520 [lib.basic.string]) from:</p>
 521
 522 <p>&nbsp;&nbsp;&nbsp;&nbsp; void push_back(const charT)<br>
 523 <br>
 524 to<br>
 525 <br>
 526 &nbsp;&nbsp;&nbsp;&nbsp; void push_back(charT)<br>
 527 <br>
 528 Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
 529 <br>
 530 &nbsp;&nbsp;&nbsp; void basic_string::push_back(charT c);<br>
 531 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to append(static_cast&lt;size_type&gt;(1), c);<br>
 532 <br>
 533 ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
 534 <br>
 535 ITEM 5: Duplicate; see issue 5 (and 87).<br>
 536 <br>
 537 ITEM 6: In table 37, Replace:<br>
 538 <br>
 539 &nbsp;&nbsp;&nbsp; "Copies correctly even where p is in [s, s+n)."<br>
 540 <br>
 541 with:<br>
 542 <br>
 543 &nbsp;&nbsp;&nbsp;&nbsp; "Copies correctly even where the ranges [p, p+n) and [s,
 544 s+n) overlap."</p>
 545 <hr>
 546 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;24 Dec 1997</p>
 547 <p>It appears there's an important guarantee missing from clause
 548 22. We're told that invoking locale::global(L) sets the C locale if L
 549 has a name. However, we're not told whether or not invoking
 550 setlocale(s) sets the global C++ locale. </p>
 551
 552 <p>The intent, I think, is that it should not, but I can't find any
 553 such words anywhere. </p>
 554 <p><b>Proposed resolution:</b></p>
 555 <p>Add a sentence at the end of 22.1.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a>,
 556 paragraph 2:&nbsp; </p>
 557
 558 <blockquote>
 559   <p>No library function other than <tt>locale::global()</tt> shall affect
 560   the value returned by <tt>locale()</tt>. </p>
 561
 562 </blockquote>
 563 <hr>
 564 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;4 Jan 1998</p>
 565 <p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
 566 section 3.7.3.1 of CD2 seems to allow for the possibility that all
 567 calls to operator new(0) yield the same pointer, an implementation
 568 technique specifically prohibited by ARM 5.3.3.Was this prohibition
 569 really lifted? Does the FDIS agree with CD2 in the regard? [Issues
 570 list maintainer's note: the IS is the same.]</p>
 571 <p><b>Proposed resolution:</b></p>
 572 <p>Change the last paragraph of 3.7.3 from:</p>
 573 <blockquote>
 574   <p>Any allocation and/or deallocation functions defined in a C++ program shall
 575   conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
 576 </blockquote>
 577 <p>to:</p>
 578 <blockquote>
 579   <p>Any allocation and/or deallocation functions defined in a C++ program,
 580   including the default versions in the library, shall conform to the semantics
 581   specified in 3.7.3.1 and 3.7.3.2.</p>
 582 </blockquote>
 583 <p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
 584 <blockquote>
 585   <p>If the size of the space requested is zero, the value returned shall not be
 586   a null pointer value (4.10).</p>
 587 </blockquote>
 588 <p>to:</p>
 589 <blockquote>
 590   <p>Even if the size of the space requested is zero, the request can fail. If
 591   the request succeeds, the value returned shall be a non-null pointer value
 592   (4.10) p0 different from any previously returned value p1, unless that value
 593   p1 was since passed to an operator delete.</p>
 594 </blockquote>
 595 <p>5.3.4/7 currently reads:</p>
 596 <blockquote>
 597   <p>When the value of the expression in a direct-new-declarator is zero, the
 598   allocation function is called to allocate an array with no elements. The
 599   pointer returned by the new-expression is non-null. [Note: If the library
 600   allocation function is called, the pointer returned is distinct from the
 601   pointer to any other object.]</p>
 602 </blockquote>
 603 <p>Retain the first sentence, and delete the remainder.</p>
 604 <p>18.4.1 currently has no text. Add the following:</p>
 605 <blockquote>
 606   <p>Except where otherwise specified, the provisions of 3.7.3 apply to the
 607   library versions of operator new and operator delete.</p>
 608 </blockquote>
 609 <p>To 18.4.1.3, add the following text:</p>
 610 <blockquote>
 611   <p>The provisions of 3.7.3 do not apply to these reserved placement forms of
 612   operator new and operator delete.</p>
 613 </blockquote>
 614 <p><b>Rationale:</b></p>
 615 <p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
 616 supporting to the proposed resolution.</p>
 617 <hr>
 618 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;22 Jan 1998</p>
 619 <p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is
 620 not documented in 23.3.5.2. </p>
 621
 622 <p>(2) The class synopsis only gives a single signature for bitset&lt;&gt;::operator[],
 623 reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
 624 on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
 625
 626 <p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
 627 trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
 628 go in the Effects clause.</p>
 629 <p><b>Proposed resolution:</b></p>
 630 <p>ITEMS 1 AND 2:<br>
 631 <br>
 632 In the bitset synopsis (23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>),
 633 replace the member function <br>
 634 <br>
 635 <tt>&nbsp;&nbsp;&nbsp; reference operator[](size_t pos);<br>
 636 </tt><br>
 637 with the two member functions<br>
 638 <br>
 639 <tt>&nbsp;&nbsp;&nbsp; bool operator[](size_t pos) const; <br>
 640 &nbsp;&nbsp;&nbsp; reference operator[](size_t pos); <br>
 641 </tt><br>
 642 Add the following text at the end of 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>,
 643 immediately after paragraph 45:</p>
 644
 645 <blockquote>
 646   <p><tt>bool operator[](size_t pos) const;</tt><br>
 647   Requires: pos is valid<br>
 648   Throws: nothing<br>
 649   Returns: <tt>test(pos)</tt><br>
 650   <br>
 651   <tt>bitset&lt;N&gt;::reference operator[](size_t pos);</tt> <br>
 652   Requires: pos is valid<br>
 653   Throws: nothing<br>
 654   Returns: An object of type <tt>bitset&lt;N&gt;::reference</tt> such that <tt>(*this)[pos]
 655   == this-&gt;test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this-&gt;set(pos,
 656   val);</tt></p>
 657 </blockquote>
 658 <p><b>Rationale:</b></p>
 659 <p>The LWG believes Item 3 is not a defect. "Formatted
 660 input" implies the desired semantics. See 27.6.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream.formatted"> [lib.istream.formatted]</a>.
 661 </p>
 662 <hr>
 663 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;William M. Miller&nbsp; <b>Date:</b>&nbsp;3 Mar 1998</p>
 664 <p>In 27.6.1.2.3, there is a reference to "eos", which is
 665 the only one in the whole draft (at least using Acrobat search), so
 666 it's undefined. </p>
 667 <p><b>Proposed resolution:</b></p>
 668 <p>In 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, replace "eos" with
 669 "charT()"</p>
 670 <hr>
 671 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 672 <p>locale::combine is the only member function of locale (other than constructors and
 673 destructor) that is not const. There is no reason for it not to be const, and good reasons
 674 why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
 675 paragraph 6: "An instance of a locale is immutable." </p>
 676
 677 <p>History: this member function originally was a constructor. it happened that the
 678 interface it specified had no corresponding language syntax, so it was changed to a member
 679 function. As constructors are never const, there was no "const" in the interface
 680 which was transformed into member "combine". It should have been added at that
 681 time, but the omission was not noticed. </p>
 682 <p><b>Proposed resolution:</b></p>
 683 <p>In 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-locales.html#lib.locale.members"> [lib.locale.members]</a>, add
 684 "const" to the declaration of member combine: </p>
 685 <blockquote>
 686   <pre>template &lt;class Facet&gt; locale combine(const locale&amp; other) const; </pre>
 687 </blockquote>
 688 <hr>
 689 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 690 <p>locale::name() is described as returning a string that can be passed to a locale
 691 constructor, but there is no matching constructor. </p>
 692 <p><b>Proposed resolution:</b></p>
 693 <p>In 22.1.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.members"> [lib.locale.members]</a>, paragraph 5, replace
 694 "<tt>locale(name())</tt>" with
 695 "<tt>locale(name().c_str())</tt>".
 696 </p>
 697 <hr>
 698 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 699 <p>The new virtual members ctype_byname&lt;char&gt;::do_widen and do_narrow did not get
 700 edited in properly. Instead, the member do_widen appears four times, with wrong argument
 701 lists. </p>
 702 <p><b>Proposed resolution:</b></p>
 703 <p>The correct declarations for the overloaded members
 704 <tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
 705 from 22.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.ctype.special"> [lib.facet.ctype.special]</a>.</p>
 706 <hr>
 707 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 708 <p>This section describes the process of parsing a text boolean value from the input
 709 stream. It does not say it recognizes either of the sequences "true" or
 710 "false" and returns the corresponding bool value; instead, it says it recognizes
 711 only one of those sequences, and chooses which according to the received value of a
 712 reference argument intended for returning the result, and reports an error if the other
 713 sequence is found. (!) Furthermore, it claims to get the names from the ctype&lt;&gt;
 714 facet rather than the numpunct&lt;&gt; facet, and it examines the "boolalpha"
 715 flag wrongly; it doesn't define the value "loc"; and finally, it computes
 716 wrongly whether to use numeric or "alpha" parsing.<br>
 717 <br>
 718 I believe the correct algorithm is "as if": </p>
 719
 720 <pre>  // in, err, val, and str are arguments.
 721   err = 0;
 722   const numpunct&lt;charT&gt;&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(str.getloc());
 723   const string_type t = np.truename(), f = np.falsename();
 724   bool tm = true, fm = true;
 725   size_t pos = 0;
 726   while (tm &amp;&amp; pos &lt; t.size() || fm &amp;&amp; pos &lt; f.size()) {
 727     if (in == end) { err = str.eofbit; }
 728     bool matched = false;
 729     if (tm &amp;&amp; pos &lt; t.size()) {
 730       if (!err &amp;&amp; t[pos] == *in) matched = true;
 731       else tm = false;
 732     }
 733     if (fm &amp;&amp; pos &lt; f.size()) {
 734       if (!err &amp;&amp; f[pos] == *in) matched = true;
 735       else fm = false;
 736     }
 737     if (matched) { ++in; ++pos; }
 738     if (pos &gt; t.size()) tm = false;
 739     if (pos &gt; f.size()) fm = false;
 740   }
 741   if (tm == fm || pos == 0) { err |= str.failbit; }
 742   else                      { val = tm; }
 743   return in;</pre>
 744
 745 <p>Notice this works reasonably when the candidate strings are both empty, or equal, or
 746 when one is a substring of the other. The proposed text below captures the logic of the
 747 code above.</p>
 748 <p><b>Proposed resolution:</b></p>
 749 <p>In 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, in the first line of paragraph 14,
 750 change "&amp;&amp;" to "&amp;".</p>
 751
 752 <p>Then, replace paragraphs 15 and 16 as follows:</p>
 753
 754 <blockquote>
 755
 756   <p>Otherwise target sequences are determined "as if" by
 757   calling the members <tt>falsename()</tt> and
 758   <tt>truename()</tt> of the facet obtained by
 759   <tt>use_facet&lt;numpunct&lt;charT&gt;&nbsp;&gt;(str.getloc())</tt>.
 760   Successive characters in the range <tt>[in,end)</tt> (see
 761   [lib.sequence.reqmts]) are obtained and matched against
 762   corresponding positions in the target sequences only as necessary to
 763   identify a unique match. The input iterator <tt>in</tt> is
 764   compared to <tt>end</tt> only when necessary to obtain a
 765   character. If and only if a target sequence is uniquely matched,
 766   <tt>val</tt> is set to the corresponding value.</p>
 767
 768 </blockquote>
 769
 770 <blockquote>
 771   <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
 772   successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
 773   <tt>str.eofbit</tt> if, when seeking another character to match, it is found that
 774   <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
 775   <tt>(str.failbit|str.eofbit)</tt>if
 776   the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
 777   <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
 778   <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
 779   <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
 780   <tt>true</tt>:"1"
 781   and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
 782   and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
 783   <tt>err==str.failbit</tt>. --end example]</p>
 784 </blockquote>
 785 <hr>
 786 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 787 <p>In the list of num_get&lt;&gt; non-virtual members on page 22-23, the member
 788 that parses bool values was omitted from the list of definitions of non-virtual
 789 members, though it is listed in the class definition and the corresponding
 790 virtual is listed everywhere appropriate. </p>
 791 <p><b>Proposed resolution:</b></p>
 792 <p>Add at the beginning of 22.2.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>
 793 another get member for bool&amp;, copied from the entry in
 794 22.2.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.num.get"> [lib.locale.num.get]</a>.</p>
 795 <hr>
 796 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 797 <p>
 798 In the definitions of codecvt&lt;&gt;::do_out and do_in, they are
 799 specified to return noconv if "no conversion is
 800 needed". This definition is too vague, and does not say
 801 normatively what is done with the buffers.
 802 </p>
 803 <p><b>Proposed resolution:</b></p>
 804 <p>
 805 Change the entry for noconv in the table under paragraph 4 in section
 806 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> to read:
 807 </p>
 808 <blockquote>
 809   <p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
 810   and input sequence is identical to converted sequence.</p>
 811 </blockquote>
 812 <p>Change the Note in paragraph 2 to normative text as follows:</p>
 813 <blockquote>
 814   <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
 815   same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
 816   <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
 817   unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
 818 </blockquote>
 819 <hr>
 820 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 821 <p>The synopsis for numpunct&lt;&gt;::do_thousands_sep, and the
 822 definition of numpunct&lt;&gt;::thousands_sep which calls it, specify
 823 that it returns a value of type char_type. Here it is erroneously
 824 described as returning a "string_type". </p>
 825 <p><b>Proposed resolution:</b></p>
 826 <p>In 22.2.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>, above paragraph 2, change
 827 "string_type" to "char_type". </p>
 828 <hr>
 829 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 830 <p>In the second table in the section, captioned "Required
 831 instantiations", the instantiations for codecvt_byname&lt;&gt;
 832 have been omitted. These are necessary to allow users to construct a
 833 locale by name from facets. </p>
 834 <p><b>Proposed resolution:</b></p>
 835 <p>Add in 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> to the table captioned
 836 "Required instantiations", in the category "ctype"
 837 the lines </p>
 838
 839 <blockquote>
 840   <pre>codecvt_byname&lt;char,char,mbstate_t&gt;,
 841 codecvt_byname&lt;wchar_t,char,mbstate_t&gt; </pre>
 842 </blockquote>
 843 <hr>
 844 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 845 <p>The description of basic_istream&lt;&gt;::open leaves unanswered questions about how it
 846 responds to or changes flags in the error status for the stream. A strict reading
 847 indicates that it ignores the bits and does not change them, which confuses users who do
 848 not expect eofbit and failbit to remain set after a successful open. There are three
 849 reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
 850 and eofbit on call to open(). </p>
 851 <p><b>Proposed resolution:</b></p>
 852 <p>In 27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a> paragraph 3, under open() effects, add a footnote:
 853 </p>
 854
 855 <blockquote>
 856   <p>A successful open does not change the error state.</p>
 857 </blockquote>
 858 <p><b>Rationale:</b></p>
 859 <p>This may seem surprising to some users, but it's just an instance
 860 of a general rule: error flags are never cleared by the
 861 implementation. The only way error flags are are ever cleared is if
 862 the user explicitly clears them by hand.</p>
 863
 864 <p>The LWG believed that preserving this general rule was
 865 important enough so that an exception shouldn't be made just for this
 866 one case.  The resolution of this issue clarifies what the LWG
 867 believes to have been the original intent.</p>
 868
 869 <hr>
 870 <a name="24"><h3>24.&nbsp;"do_convert" doesn't exist</h3></a><p><b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 871 <p>The description of codecvt&lt;&gt;::do_out and do_in mentions a
 872 symbol "do_convert" which is not defined in the
 873 standard. This is a leftover from an edit, and should be "do_in
 874 and do_out". </p>
 875 <p><b>Proposed resolution:</b></p>
 876 <p>In 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>, paragraph 3, change
 877 "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/papers/2005/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, change "do_convert()" to "do_in
 878 or do_out". </p>
 879 <hr>
 880 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 881 <p>In the description of operator&lt;&lt; applied to strings, the standard says that uses
 882 the smaller of os.width() and str.size(), to pad "as described in stage 3"
 883 elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
 884 <p><b>Proposed resolution:</b></p>
 885 <p>Change 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string.io"> [lib.string.io]</a>  paragraph 4 from:<br>
 886 <br>
 887 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
 888 ..."<br>
 889 <br>
 890 to: <br>
 891 <br>
 892 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
 893 ..."</p>
 894 <hr>
 895 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 896 <p>In paragraph 6, the code in the example: </p>
 897
 898 <pre>  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
 899   basic_istream&lt;charT,traits&gt;::sentry(
 900            basic_istream&lt;charT,traits&gt;&amp; is, bool noskipws = false) {
 901       ...
 902       int_type c;
 903       typedef ctype&lt;charT&gt; ctype_type;
 904       const ctype_type&amp; ctype = use_facet&lt;ctype_type&gt;(is.getloc());
 905       while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
 906         if (ctype.is(ctype.space,c)==0) {
 907           is.rdbuf()-&gt;sputbackc (c);
 908           break;
 909         }
 910       }
 911       ...
 912    }</pre>
 913
 914 <p>fails to demonstrate correct use of the facilities described. In
 915 particular, it fails to use traits operators, and specifies incorrect
 916 semantics. (E.g. it specifies skipping over the first character in the
 917 sequence without examining it.) </p>
 918 <p><b>Proposed resolution:</b></p>
 919 <p>Remove the example above from 27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>
 920 paragraph 6.</p>
 921 <p><b>Rationale:</b></p>
 922 <p>The originally proposed replacement code for the example was not
 923 correct. The LWG tried in Kona and again in Tokyo to correct it
 924 without success. In Tokyo, an implementor reported that actual working
 925 code ran over one page in length and was quite complicated. The LWG
 926 decided that it would be counter-productive to include such a lengthy
 927 example, which might well still contain errors.</p>
 928 <hr>
 929 <a name="27"></a><h3><a name="27">27.&nbsp;String::erase(range) yields wrong iterator</a></h3><p><b>Section:</b>&nbsp;21.3.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 930 <p>The string::erase(iterator first, iterator last) is specified to return an element one
 931 place beyond the next element after the last one erased. E.g. for the string
 932 "abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
 933 while 'd' has not been erased. </p>
 934 <p><b>Proposed resolution:</b></p>
 935 <p>In 21.3.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string::erase"> [lib.string::erase]</a>, paragraph 10, change: </p>
 936
 937 <blockquote>
 938   <p>Returns: an iterator which points to the element immediately following _last_ prior to
 939   the element being erased. </p>
 940 </blockquote>
 941
 942 <p>to read </p>
 943
 944 <blockquote>
 945   <p>Returns: an iterator which points to the element pointed to by _last_ prior to the
 946   other elements being erased. </p>
 947 </blockquote>
 948 <hr>
 949 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 950 <p>The description of the vector form of ctype&lt;char&gt;::is can be interpreted to mean
 951 something very different from what was intended. Paragraph 4 says </p>
 952
 953 <blockquote>
 954   <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
 955   table()[(unsigned char)*p]. </p>
 956 </blockquote>
 957
 958 <p>This is intended to copy the value indexed from table()[] into the place identified in
 959 vec[]. </p>
 960 <p><b>Proposed resolution:</b></p>
 961 <p>Change 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a>, paragraph 4, to read </p>
 962
 963 <blockquote>
 964   <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
 965   the value table()[(unsigned char)*p]. </p>
 966 </blockquote>
 967 <hr>
 968 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 969 <p>Sections 27.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-iostreams.html#lib.wide.stream.objects"> [lib.wide.stream.objects]</a> mention
 970 a function ios_base::init, which is not defined. Probably they mean
 971 basic_ios&lt;&gt;::init, defined in 27.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>,
 972 paragraph 3. </p>
 973 <p><b>Proposed resolution:</b></p>
 974 <p>[R12: modified to include paragraph 5.]</p>
 975
 976 <p>In 27.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> paragraph 2 and 5, change </p>
 977
 978 <blockquote>
 979   <p>ios_base::init </p>
 980 </blockquote>
 981
 982 <p>to </p>
 983
 984 <blockquote>
 985   <p>basic_ios&lt;char&gt;::init </p>
 986 </blockquote>
 987
 988 <p>Also, make a similar change in 27.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.wide.stream.objects"> [lib.wide.stream.objects]</a> except it
 989 should read </p>
 990
 991 <blockquote>
 992   <p>basic_ios&lt;wchar_t&gt;::init </p>
 993 </blockquote>
 994 <hr>
 995 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 996 <p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in &lt;cctype&gt;,
 997 where they are in fact defined elsewhere to appear in &lt;clocale&gt;. </p>
 998 <p><b>Proposed resolution:</b></p>
 999 <p>In 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, paragraph 2, change
1000 "&lt;cctype&gt;" to read "&lt;clocale&gt;". </p>
1001 <hr>
1002 <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/papers/2005/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1003 <p>Paragraph 6, says "An instance of <tt>locale</tt> is
1004 <i>immutable</i>; once a facet reference is obtained from it,
1005 ...". This has caused some confusion, because locale variables
1006 are manifestly assignable. </p>
1007 <p><b>Proposed resolution:</b></p>
1008 <p>In 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale"> [lib.locale]</a> replace paragraph 6</p>
1009
1010 <blockquote>
1011   <p>An instance of <tt>locale</tt> is immutable; once a facet
1012   reference is obtained from it, that reference remains usable as long
1013   as the locale value itself exists.</p>
1014 </blockquote>
1015
1016 <p>with</p>
1017
1018 <blockquote>
1019   <p>Once a facet reference is obtained from a locale object by
1020   calling use_facet&lt;&gt;, that reference remains usable, and the
1021   results from member functions of it may be cached and re-used, as
1022   long as some locale object refers to that facet.</p>
1023 </blockquote>
1024 <hr>
1025 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1026 <p>The description of the required state before calling virtual member
1027 basic_streambuf&lt;&gt;::pbackfail requirements is inconsistent with the conditions
1028 described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
1029 Specifically, the latter says it calls pbackfail if: </p>
1030
1031 <p>&nbsp;&nbsp;&nbsp; traits::eq(c,gptr()[-1]) is false </p>
1032
1033 <p>where pbackfail claims to require: </p>
1034
1035 <p>&nbsp;&nbsp;&nbsp; traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
1036
1037 <p>It appears that the pbackfail description is wrong. </p>
1038 <p><b>Proposed resolution:</b></p>
1039 <p>In 27.5.2.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a>, paragraph 1, change:</p>
1040
1041 <blockquote>
1042   <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
1043 </blockquote>
1044
1045 <p>to </p>
1046
1047 <blockquote>
1048   <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
1049   </p>
1050 </blockquote>
1051 <p><b>Rationale:</b></p>
1052 <p>Note deliberate reordering of arguments for clarity in addition to the correction of
1053 the argument value.</p>
1054 <hr>
1055 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1056 <p>In the table defining the results from do_out and do_in, the specification for the
1057 result <i>error</i> says </p>
1058
1059 <blockquote>
1060   <p>encountered a from_type character it could not convert </p>
1061 </blockquote>
1062
1063 <p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
1064 an internT for do_out. </p>
1065 <p><b>Proposed resolution:</b></p>
1066 <p>In 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 4, replace the definition
1067 in the table for the case of _error_ with </p>
1068
1069 <blockquote>
1070   <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
1071 </blockquote>
1072 <hr>
1073 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1074 <p>In paragraph 19, Effects:, members truename() and falsename are used from facet
1075 ctype&lt;charT&gt;, but it has no such members. Note that this is also a problem in
1076 22.2.2.1.2, addressed in (4). </p>
1077 <p><b>Proposed resolution:</b></p>
1078 <p>In 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, paragraph 19, in the Effects:
1079 clause for member put(...., bool), replace the initialization of the
1080 string_type value s as follows: </p>
1081
1082 <blockquote>
1083   <pre>const numpunct&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(loc);
1084 string_type s = val ? np.truename() : np.falsename(); </pre>
1085 </blockquote>
1086 <hr>
1087 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1088 <p>In 27.4.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.fmtflags.manip"> [lib.fmtflags.manip]</a>, we have a definition for a manipulator
1089 named "unitbuf". Unlike other manipulators, it's not listed
1090 in synopsis. Similarly for "nounitbuf". </p>
1091 <p><b>Proposed resolution:</b></p>
1092 <p>Add to the synopsis for &lt;ios&gt; in 27.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a>, after
1093 the entry for "nouppercase", the prototypes: </p>
1094
1095 <blockquote>
1096   <pre>ios_base&amp; unitbuf(ios_base&amp; str);
1097 ios_base&amp; nounitbuf(ios_base&amp; str); </pre>
1098 </blockquote>
1099 <hr>
1100 <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/papers/2005/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/papers/2005/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 the definitions for ios_base::iword and pword, the lifetime of the storage is
1102 specified badly, so that an implementation which only keeps the last value stored appears
1103 to conform. In particular, it says: </p>
1104
1105 <p>The reference returned may become invalid after another call to the object's iword
1106 member with a different index ... </p>
1107
1108 <p>This is not idle speculation; at least one implementation was done this way. </p>
1109 <p><b>Proposed resolution:</b></p>
1110 <p>Add in 27.4.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a>, in both paragraph 2 and also in
1111 paragraph 4, replace the sentence: </p>
1112
1113 <blockquote>
1114   <p>The reference returned may become invalid after another call to the object's iword
1115   [pword] member with a different index, after a call to its copyfmt member, or when the
1116   object is destroyed. </p>
1117 </blockquote>
1118
1119 <p>with: </p>
1120
1121 <blockquote>
1122   <p>The reference returned is invalid after any other operations on the object. However,
1123   the value of the storage referred to is retained, so that until the next call to copyfmt,
1124   calling iword [pword] with the same index yields another reference to the same value. </p>
1125 </blockquote>
1126
1127 <p>substituting "iword" or "pword" as appropriate. </p>
1128 <hr>
1129 <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/papers/2005/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1130 <p>In the overview of locale semantics, paragraph 4, is the sentence </p>
1131
1132 <blockquote>
1133   <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
1134   the standard exception bad_cast. </p>
1135 </blockquote>
1136
1137 <p>This is not supported by the definition of use_facet&lt;&gt;, and represents semantics
1138 from an old draft. </p>
1139 <p><b>Proposed resolution:</b></p>
1140 <p>In 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale"> [lib.locale]</a>, paragraph 4, delete the parenthesized
1141 expression </p>
1142
1143 <blockquote>
1144   <p>(or, failing that, in the global locale) </p>
1145 </blockquote>
1146 <hr>
1147 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1148 <p>It has been noticed by Esa Pulkkinen that the definition of
1149 "facet" is incomplete. In particular, a class derived from
1150 another facet, but which does not define a member <i>id</i>, cannot
1151 safely serve as the argument <i>F</i> to use_facet&lt;F&gt;(loc),
1152 because there is no guarantee that a reference to the facet instance
1153 stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
1154 <p><b>Proposed resolution:</b></p>
1155 <p>In the definition of std::use_facet&lt;&gt;(), replace the text in paragraph 1 which
1156 reads: </p>
1157
1158 <blockquote>
1159   <p>Get a reference to a facet of a locale. </p>
1160 </blockquote>
1161
1162 <p>with: </p>
1163
1164 <blockquote>
1165   <p>Requires: <tt>Facet</tt> is a facet class whose definition
1166   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/papers/2005/lib-locales.html#lib.locale.facet"> [lib.locale.facet]</a>. </p>
1167 </blockquote>
1168
1169 <p><i>[
1170 Kona: strike as overspecification the text "(not inherits)"
1171 from the original resolution, which read "... whose definition
1172 contains (not inherits) the public static member
1173 <tt>id</tt>..."
1174 ]</i></p>
1175
1176 <hr>
1177 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1178 <p>Following the definition of istreambuf_iterator&lt;&gt;::operator++(int) in paragraph
1179 3, the standard contains three lines of garbage text left over from a previous edit. </p>
1180
1181 <blockquote>
1182   <pre>istreambuf_iterator&lt;charT,traits&gt; tmp = *this;
1183 sbuf_-&gt;sbumpc();
1184 return(tmp); </pre>
1185 </blockquote>
1186 <p><b>Proposed resolution:</b></p>
1187 <p>In 24.5.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.istreambuf.iterator::op++"> [lib.istreambuf.iterator::op++]</a>, delete the three lines of code at the
1188 end of paragraph 3. </p>
1189 <hr>
1190 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1191 <p>Paragraph 3 of the locale examples is a description of part of an
1192 implementation technique that has lost its referent, and doesn't mean
1193 anything. </p>
1194 <p><b>Proposed resolution:</b></p>
1195 <p>Delete 22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 3 which begins "This
1196 initialization/identification system depends...", or (at the
1197 editor's option) replace it with a place-holder to keep the paragraph
1198 numbering the same. </p>
1199 <hr>
1200 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1201 <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/papers/2005/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>, say that if they fail, they "set badbit,
1202 which may throw an exception". However, ios_base offers no
1203 interface to set or to test badbit; those interfaces are defined in
1204 basic_ios&lt;&gt;. </p>
1205 <p><b>Proposed resolution:</b></p>
1206 <p>Change the description in 27.4.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a> in
1207 paragraph 2, and also in paragraph 4, as follows. Replace</p>
1208
1209 <blockquote>
1210   <p>If the function fails it sets badbit, which may throw an exception.</p>
1211 </blockquote>
1212
1213 <p>with</p>
1214
1215 <blockquote>
1216   <p>If the function fails, and <tt>*this</tt> is a base sub-object of
1217   a <tt>basic_ios&lt;&gt;</tt> object or sub-object, the effect is
1218   equivalent to calling <tt>basic_ios&lt;&gt;::setstate(badbit)</tt>
1219   on the derived object (which may throw <tt>failure</tt>).</p>
1220 </blockquote>
1221
1222 <p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
1223 setstate(badbit).]</i></p>
1224
1225 <hr>
1226 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1227 <p>The basic_string&lt;&gt; copy constructor: </p>
1228
1229 <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1230              size_type n = npos, const Allocator&amp; a = Allocator()); </pre>
1231
1232 <p>specifies an Allocator argument default value that is
1233 counter-intuitive. The natural choice for a the allocator to copy from
1234 is str.get_allocator(). Though this cannot be expressed in
1235 default-argument notation, overloading suffices. </p>
1236
1237 <p>Alternatively, the other containers in Clause 23 (deque, list,
1238 vector) do not have this form of constructor, so it is inconsistent,
1239 and an evident source of confusion, for basic_string&lt;&gt; to have
1240 it, so it might better be removed. </p>
1241 <p><b>Proposed resolution:</b></p>
1242 <p> In 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, replace the declaration of the copy
1243 constructor as follows: </p>
1244
1245 <blockquote>
1246   <pre>basic_string(const basic_string&amp; str);
1247 basic_string(const basic_string&amp; str, size_type pos, size_type n = npos,
1248              const Allocator&amp; a = Allocator());</pre>
1249 </blockquote>
1250
1251 <p>In 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace the copy constructor declaration
1252 as above. Add to paragraph 5, Effects:</p>
1253
1254 <blockquote>
1255   <p>In the first form, the Allocator value used is copied from
1256   <tt>str.get_allocator()</tt>.</p>
1257 </blockquote>
1258 <p><b>Rationale:</b></p>
1259 <p>The LWG believes the constructor is actually broken, rather than
1260 just an unfortunate design choice.</p>
1261
1262 <p>The LWG considered two other possible resolutions:</p>
1263
1264 <p>A. In 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, replace the declaration of the copy
1265 constructor as follows:</p>
1266
1267 <blockquote>
1268   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1269              size_type n = npos);
1270 basic_string(const basic_string&amp; str, size_type pos,
1271              size_type n, const Allocator&amp; a); </pre>
1272 </blockquote>
1273
1274 <p>In 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace the copy constructor declaration
1275 as above. Add to paragraph 5, Effects: </p>
1276
1277 <blockquote>
1278   <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
1279   value <tt>str.get_allocator()</tt>. </p>
1280 </blockquote>
1281
1282 <p>B. In 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace
1283 the declaration of the copy constructor as follows: </p>
1284
1285 <blockquote>
1286   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1287              size_type n = npos); </pre>
1288 </blockquote>
1289
1290 <p>The proposed resolution reflects the original intent of the LWG. It
1291 was also noted by Pete Becker that this fix "will cause
1292 a small amount of existing code to now work correctly."</p>
1293
1294 <p><i>[
1295 Kona: issue editing snafu fixed - the proposed resolution now correctly
1296 reflects the LWG consensus.
1297 ]</i></p>
1298 <hr>
1299 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1300 <p>Many of the specifications for iostreams specify that character
1301 values or their int_type equivalents are compared using operators ==
1302 or !=, though in other places traits::eq() or traits::eq_int_type is
1303 specified to be used throughout. This is an inconsistency; we should
1304 change uses of == and != to use the traits members instead. </p>
1305 <p><b>Proposed resolution:</b></p>
1306
1307 <p><i>[Pre-Kona: Dietmar supplied wording]</i></p>
1308
1309 <p>List of changes to clause 27:</p>
1310 <ol>
1311 <li>
1312    In lib.basic.ios.members paragraph 13 (postcondition clause for
1313    'fill(cT)') change
1314
1315 <blockquote>
1316      fillch == fill()
1317 </blockquote>
1318
1319    to
1320
1321 <blockquote>
1322      traits::eq(fillch, fill())
1323 </blockquote>
1324
1325
1326 </li>
1327 <li>
1328    In lib.istream.unformatted paragraph 7 (effects clause for
1329    'get(cT,streamsize,cT)'), third bullet, change
1330
1331 <blockquote>
1332      c == delim for the next available input character c
1333 </blockquote>
1334
1335    to
1336
1337 <blockquote>
1338      traits::eq(c, delim) for the next available input character c
1339   </blockquote>
1340
1341 </li>
1342 <li>
1343    In lib.istream.unformatted paragraph 12 (effects clause for
1344    'get(basic_streambuf&lt;cT,Tr&gt;&amp;,cT)'), third bullet, change
1345
1346 <blockquote>
1347      c == delim for the next available input character c
1348 </blockquote>
1349
1350    to
1351
1352 <blockquote>
1353      traits::eq(c, delim) for the next available input character c
1354 </blockquote>
1355
1356 </li>
1357 <li>
1358    In lib.istream.unformatted paragraph 17 (effects clause for
1359    'getline(cT,streamsize,cT)'), second bullet, change
1360
1361 <blockquote>
1362      c == delim for the next available input character c
1363 </blockquote>
1364
1365    to
1366
1367 <blockquote>
1368      traits::eq(c, delim) for the next available input character c
1369   </blockquote>
1370
1371 </li>
1372 <li>
1373    In lib.istream.unformatted paragraph 24 (effects clause for
1374    'ignore(int,int_type)'), second bullet, change
1375
1376 <blockquote>
1377      c == delim for the next available input character c
1378 </blockquote>
1379
1380    to
1381
1382 <blockquote>
1383      traits::eq_int_type(c, delim) for the next available input
1384      character c
1385 </blockquote>
1386
1387 </li>
1388 <li>
1389    In lib.istream.unformatted paragraph 25 (notes clause for
1390    'ignore(int,int_type)'), second bullet, change
1391
1392 <blockquote>
1393      The last condition will never occur if delim == traits::eof()
1394 </blockquote>
1395
1396    to
1397
1398 <blockquote>
1399      The last condition will never occur if
1400      traits::eq_int_type(delim, traits::eof()).
1401 </blockquote>
1402
1403 </li>
1404 <li>
1405    In lib.istream.sentry paragraph 6 (example implementation for the
1406    sentry constructor) change
1407
1408 <blockquote>
1409      while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
1410 </blockquote>
1411
1412    to
1413
1414 <blockquote>
1415      while (!traits::eq_int_type(c = is.rdbuf()-&gt;snextc(), traits::eof())) {
1416 </blockquote>
1417
1418 </li>
1419 </ol>
1420
1421 <p>List of changes to Chapter 21:</p>
1422
1423 <ol>
1424 <li>
1425    In lib.string::find paragraph 1 (effects clause for find()),
1426    second bullet, change
1427
1428 <blockquote>
1429      at(xpos+I) == str.at(I) for all elements ...
1430 </blockquote>
1431
1432    to
1433
1434 <blockquote>
1435      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1436 </blockquote>
1437
1438 </li>
1439 <li>
1440    In lib.string::rfind paragraph 1 (effects clause for rfind()),
1441    second bullet, change
1442
1443 <blockquote>
1444      at(xpos+I) == str.at(I) for all elements ...
1445 </blockquote>
1446
1447    to
1448
1449 <blockquote>
1450      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1451 </blockquote>
1452
1453 </li>
1454 <li>
1455    In lib.string::find.first.of paragraph 1 (effects clause for
1456    find_first_of()), second bullet, change
1457
1458 <blockquote>
1459      at(xpos+I) == str.at(I) for all elements ...
1460 </blockquote>
1461
1462    to
1463
1464 <blockquote>
1465      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1466 </blockquote>
1467
1468 </li>
1469 <li>
1470    In lib.string::find.last.of paragraph 1 (effects clause for
1471    find_last_of()), second bullet, change
1472
1473 <blockquote>
1474      at(xpos+I) == str.at(I) for all elements ...
1475 </blockquote>
1476
1477    to
1478
1479 <blockquote>
1480      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1481 </blockquote>
1482
1483 </li>
1484 <li>
1485    In lib.string::find.first.not.of paragraph 1 (effects clause for
1486    find_first_not_of()), second bullet, change
1487
1488 <blockquote>
1489      at(xpos+I) == str.at(I) for all elements ...
1490 </blockquote>
1491
1492    to
1493
1494 <blockquote>
1495      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1496 </blockquote>
1497 </li>
1498
1499 <li>
1500    In lib.string::find.last.not.of paragraph 1 (effects clause for
1501    find_last_not_of()), second bullet, change
1502
1503 <blockquote>
1504      at(xpos+I) == str.at(I) for all elements ...
1505 </blockquote>
1506
1507    to
1508
1509 <blockquote>
1510      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1511 </blockquote>
1512 </li>
1513
1514 <li>
1515    In lib.string.ios paragraph 5 (effects clause for getline()),
1516    second bullet, change
1517
1518 <blockquote>
1519      c == delim for the next available input character c
1520 </blockquote>
1521
1522    to
1523
1524 <blockquote>
1525      traits::eq(c, delim) for the next available input character c
1526 </blockquote>
1527 </li>
1528
1529 </ol>
1530
1531 <p>Notes:</p>
1532 <ul>
1533 <li>
1534   Fixing this issue highlights another sloppyness in
1535   lib.istream.unformatted paragraph 24: this clause mentions a "character"
1536   which is then compared to an 'int_type' (see item 5. in the list
1537   below). It is not clear whether this requires explicit words and
1538   if so what these words are supposed to be. A similar issue exists,
1539   BTW, for operator*() of istreambuf_iterator which returns the result
1540   of sgetc() as a character type (see lib.istreambuf.iterator::op*
1541   paragraph 1), and for operator++() of istreambuf_iterator which
1542   passes the result of sbumpc() to a constructor taking a char_type
1543   (see lib.istreambuf.iterator::operator++ paragraph 3). Similarily, the
1544   assignment operator ostreambuf_iterator passes a char_type to a function
1545   taking an int_type (see lib.ostreambuf.iter.ops paragraph 1).
1546 </li>
1547 <li>
1548   It is inconsistent to use comparisons using the traits functions in
1549   Chapter 27 while not using them in Chapter 21, especially as some
1550   of the inconsistent uses actually involve streams (eg. getline() on
1551   streams). To avoid leaving this issue open still longer due to this
1552   inconsistency (it is open since 1998), a list of changes to Chapter
1553   21 is below.
1554 </li>
1555 <li>
1556   In Chapter 24 there are several places with statements like "the end
1557   of stream is reached (streambuf_type::sgetc() returns traits::eof())"
1558   (lib.istreambuf.iterator paragraph 1, lib.ostreambuf.iter.ops
1559   paragraph 5). It is unclear whether these should be clarified to use
1560   traits::eq_int_type() for detecting traits::eof().
1561 </li>
1562 </ul>
1563
1564 <hr>
1565 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Brendan Kehoe&nbsp; <b>Date:</b>&nbsp; 1 Jun 1998</p>
1566 <p>See lib-6522 and edit-814.</p>
1567 <p><b>Proposed resolution:</b></p>
1568 <p>Change D.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/future.html#depr.strstreambuf"> [depr.strstreambuf]</a> (since streambuf is a typedef of
1569 basic_streambuf&lt;char&gt;) from:</p>
1570
1571 <pre>         virtual streambuf&lt;char&gt;* setbuf(char* s, streamsize n);</pre>
1572
1573 <p>to:</p>
1574
1575 <pre>         virtual streambuf* setbuf(char* s, streamsize n);</pre>
1576
1577 <p>In D.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/future.html#depr.strstream"> [depr.strstream]</a> insert the semicolon now missing after
1578 int_type:</p>
1579
1580 <pre>     namespace std {
1581        class strstream
1582          : public basic_iostream&lt;char&gt; {
1583        public:
1584          // Types
1585          typedef char                                char_type;
1586          typedef typename char_traits&lt;char&gt;::int_type int_type
1587          typedef typename char_traits&lt;char&gt;::pos_type pos_type;</pre>
1588 <hr>
1589 <a name="47"></a><h3><a name="47">47.&nbsp;Imbue() and getloc() Returns clauses swapped</a></h3><p><b>Section:</b>&nbsp;27.4.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
1590 <p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
1591 section has two RETURNS clauses, and they make no sense as
1592 stated. They make perfect sense, though, if you swap them. Am I
1593 correct in thinking that paragraphs 2 and 4 just got mixed up by
1594 accident?</p>
1595 <p><b>Proposed resolution:</b></p>
1596 <p>In 27.4.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> swap paragraphs 2 and 4.</p>
1597 <hr>
1598 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
1599 <p>27.4.2.1.1, paragraph 2, says that class failure initializes the
1600 base class, exception, with exception(msg). Class exception (see
1601 18.6.1) has no such constructor.</p>
1602 <p><b>Proposed resolution:</b></p>
1603 <p>Replace 27.4.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>, paragraph 2, with</p>
1604
1605 <blockquote>
1606   <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
1607 </blockquote>
1608 <hr>
1609 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
1610 <p>Two problems</p>
1611
1612 <p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
1613 returns. Does it return f, or does it return the previous
1614 synchronization state? My guess is the latter, but the standard
1615 doesn't say so.</p>
1616
1617 <p>(2) 27.4.2.4 doesn't say what it means for streams to be
1618 synchronized with stdio.  Again, of course, I can make some
1619 guesses. (And I'm unhappy about the performance implications of those
1620 guesses, but that's another matter.)</p>
1621 <p><b>Proposed resolution:</b></p>
1622 <p>Change the following sentence in 27.4.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>
1623 returns clause from:</p>
1624
1625 <blockquote>
1626   <p><tt>true</tt> if the standard iostream objects (27.3) are
1627   synchronized and otherwise returns <tt>false</tt>.</p>
1628 </blockquote>
1629
1630 <p>to:</p>
1631
1632 <blockquote>
1633   <p><tt>true</tt> if the previous state of the standard iostream
1634   objects (27.3) was synchronized and otherwise returns
1635   <tt>false</tt>.</p>
1636 </blockquote>
1637
1638 <p>Add the following immediately after 27.4.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>,
1639 paragraph 2:</p>
1640
1641 <blockquote>
1642 <p>When a standard iostream object str is <i>synchronized</i> with a
1643 standard stdio stream f, the effect of inserting a character c by</p>
1644 <pre>  fputc(f, c);
1645 </pre>
1646
1647 <p>is the same as the effect of</p>
1648 <pre>  str.rdbuf()-&gt;sputc(c);
1649 </pre>
1650
1651 <p>for any sequence of characters; the effect of extracting a
1652 character c by</p>
1653 <pre>  c = fgetc(f);
1654 </pre>
1655
1656 <p>is the same as the effect of:</p>
1657 <pre>  c = str.rdbuf()-&gt;sbumpc(c);
1658 </pre>
1659
1660 <p>for any sequences of characters; and the effect of pushing
1661 back a character c by</p>
1662 <pre>  ungetc(c, f);
1663 </pre>
1664
1665 <p>is the same as the effect of</p>
1666 <pre>  str.rdbuf()-&gt;sputbackc(c);
1667 </pre>
1668
1669 <p>for any sequence of characters.  [<i>Footnote</i>: This implies
1670 that operations on a standard iostream object can be mixed arbitrarily
1671 with operations on the corresponding stdio stream.  In practical
1672 terms, synchronization usually means that a standard iostream object
1673 and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
1674 </blockquote>
1675
1676 <p><i>[pre-Copenhagen: PJP and Matt contributed the definition
1677 of "synchronization"]</i></p>
1678
1679 <p><i>[post-Copenhagen: proposed resolution was revised slightly:
1680 text was added in the non-normative footnote to say that operations
1681 on the two streams can be mixed arbitrarily.]</i></p>
1682 <hr>
1683 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
1684 <p>As written, ios_base has a copy constructor and an assignment
1685 operator. (Nothing in the standard says it doesn't have one, and all
1686 classes have copy constructors and assignment operators unless you
1687 take specific steps to avoid them.) However, nothing in 27.4.2 says
1688 what the copy constructor and assignment operator do. </p>
1689
1690 <p>My guess is that this was an oversight, that ios_base is, like
1691 basic_ios, not supposed to have a copy constructor or an assignment
1692 operator.</p>
1693
1694 <p>
1695 Jerry Schwarz comments: Yes, its an oversight, but in the opposite
1696 sense to what you're suggesting. At one point there was a definite
1697 intention that you could copy ios_base. It's an easy way to save the
1698 entire state of a stream for future use. As you note, to carry out
1699 that intention would have required a explicit description of the
1700 semantics (e.g. what happens to the iarray and parray stuff).
1701 </p>
1702 <p><b>Proposed resolution:</b></p>
1703 <p>In 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>, class ios_base, specify the copy
1704 constructor and operator= members as being private.</p>
1705 <p><b>Rationale:</b></p>
1706 <p>The LWG believes the difficulty of specifying correct semantics
1707 outweighs any benefit of allowing ios_base objects to be copyable.</p>
1708 <hr>
1709 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;David Vandevoorde&nbsp; <b>Date:</b>&nbsp;23 Jun 1998</p>
1710 <p>The std::sort algorithm can in general only sort a given sequence
1711 by moving around values. The list&lt;&gt;::sort() member on the other
1712 hand could move around values or just update internal pointers. Either
1713 method can leave iterators into the list&lt;&gt; dereferencable, but
1714 they would point to different things. </p>
1715
1716 <p>Does the FDIS mandate anywhere which method should be used for
1717 list&lt;&gt;::sort()?</p>
1718
1719 <p>Matt Austern comments:</p>
1720
1721 <p>I think you've found an omission in the standard. </p>
1722
1723 <p>The library working group discussed this point, and there was
1724 supposed to be a general requirement saying that list, set, map,
1725 multiset, and multimap may not invalidate iterators, or change the
1726 values that iterators point to, except when an operation does it
1727 explicitly. So, for example, insert() doesn't invalidate any iterators
1728 and erase() and remove() only invalidate iterators pointing to the
1729 elements that are being erased. </p>
1730
1731 <p>I looked for that general requirement in the FDIS, and, while I
1732 found a limited form of it for the sorted associative containers, I
1733 didn't find it for list. It looks like it just got omitted. </p>
1734
1735 <p>The intention, though, is that list&lt;&gt;::sort does not
1736 invalidate any iterators and does not change the values that any
1737 iterator points to. There would be no reason to have the member
1738 function otherwise.</p>
1739 <p><b>Proposed resolution:</b></p>
1740 <p>Add a new paragraph at the end of 23.1:</p>
1741
1742 <blockquote>
1743   <p>Unless otherwise specified (either explicitly or by defining a function in terms of
1744   other functions), invoking a container member function or passing a container as an
1745   argument to a library function shall not invalidate iterators to, or change the values of,
1746   objects within that container. </p>
1747 </blockquote>
1748 <p><b>Rationale:</b></p>
1749 <p>This was US issue CD2-23-011; it was accepted in London but the
1750 change was not made due to an editing oversight. The wording in the
1751 proposed resolution below is somewhat updated from CD2-23-011,
1752 particularly the addition of the phrase "or change the values
1753 of"</p>
1754 <hr>
1755 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Jun 1998</p>
1756 <p>First, 27.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>, table 89. This is pretty obvious:
1757 it should be titled "basic_ios&lt;&gt;() effects", not
1758 "ios_base() effects". </p>
1759
1760 <p>[The second item is a duplicate; see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#6">6</a> for
1761 resolution.]</p>
1762
1763 <p>Second, 27.4.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a> table 88 . There are a couple
1764 different things wrong with it, some of which I've already discussed
1765 with Jerry, but the most obvious mechanical sort of error is that it
1766 uses expressions like P(i) and p(i), without ever defining what sort
1767 of thing "i" is.
1768 </p>
1769
1770 <p>(The other problem is that it requires support for streampos
1771 arithmetic. This is impossible on some systems, i.e. ones where file
1772 position is a complicated structure rather than just a number. Jerry
1773 tells me that the intention was to require syntactic support for
1774 streampos arithmetic, but that it wasn't actually supposed to do
1775 anything meaningful except on platforms, like Unix, where genuine
1776 arithmetic is possible.) </p>
1777 <p><b>Proposed resolution:</b></p>
1778 <p>Change 27.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> table 89 title from
1779 "ios_base() effects" to "basic_ios&lt;&gt;()
1780 effects". </p>
1781 <hr>
1782 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Jun 1998</p>
1783 <p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
1784 The important question is whether basic_ios::~basic_ios() destroys
1785 rdbuf().</p>
1786 <p><b>Proposed resolution:</b></p>
1787 <p>Add after 27.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> paragraph 2:</p>
1788
1789 <blockquote>
1790   <p><tt>virtual ~basic_ios();</tt></p>
1791   <p><b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
1792 </blockquote>
1793 <p><b>Rationale:</b></p>
1794 <p>The LWG reviewed the additional question of whether or not
1795 <tt>rdbuf(0)</tt> may set <tt>badbit</tt>.  The answer is
1796 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/papers/2005/lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a>, paragraph 6.  This issue was reviewed at length
1797 by the LWG, which removed from the original proposed resolution a
1798 footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
1799 <tt>badbit</tt>".</p>
1800 <hr>
1801 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;25 Jun 1998</p>
1802 <p>The class synopsis for basic_streambuf shows a (virtual)
1803 destructor, but the standard doesn't say what that destructor does. My
1804 assumption is that it does nothing, but the standard should say so
1805 explicitly. </p>
1806 <p><b>Proposed resolution:</b></p>
1807 <p>Add after 27.5.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a> paragraph 2:</p>
1808
1809 <blockquote>
1810   <p><tt>virtual&nbsp; ~basic_streambuf();</tt></p>
1811   <p><b>Effects</b>: None.</p>
1812 </blockquote>
1813 <hr>
1814 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;26 Jun 1998</p>
1815 <p>Several member functions in clause 27 are defined in certain
1816 circumstances to return an "invalid stream position", a term
1817 that is defined nowhere in the standard. Two places (27.5.2.4.2,
1818 paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
1819 a definition in _lib.iostreams.definitions_, a nonexistent
1820 section. </p>
1821
1822 <p>I suspect that the invalid stream position is just supposed to be
1823 pos_type(-1).  Probably best to say explicitly in (for example)
1824 27.5.2.4.2 that the return value is pos_type(-1), rather than to use
1825 the term "invalid stream position", define that term
1826 somewhere, and then put in a cross-reference. </p>
1827
1828 <p>The phrase "invalid stream position" appears ten times in
1829 the C++ Standard.  In seven places it refers to a return value, and it
1830 should be changed. In three places it refers to an argument, and it
1831 should not be changed. Here are the three places where "invalid
1832 stream position" should not be changed:</p>
1833
1834 <blockquote>
1835   <p>27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, paragraph 14<br>
1836   27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 14<br>
1837   D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 17
1838   </p>
1839 </blockquote>
1840 <p><b>Proposed resolution:</b></p>
1841 <p>In 27.5.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 4, change "Returns an
1842 object of class pos_type that stores an invalid stream position
1843 (_lib.iostreams.definitions_)" to "Returns
1844 <tt>pos_type(off_type(-1))</tt>".
1845 </p>
1846
1847 <p>In 27.5.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 6, change "Returns
1848 an object of class pos_type that stores an invalid stream
1849 position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
1850
1851 <p>In 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, paragraph 13, change "the object
1852 stores an invalid stream position" to "the return value is
1853 <tt>pos_type(off_type(-1))</tt>". </p>
1854
1855 <p>In 27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 13, change "returns an
1856 invalid stream position (27.4.3)" to "returns
1857 <tt>pos_type(off_type(-1))</tt>" </p>
1858
1859 <p>In 27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 15, change "Otherwise
1860 returns an invalid stream position (_lib.iostreams.definitions_)"
1861 to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
1862 </p>
1863
1864 <p>In D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 15, change "the object
1865 stores an invalid stream position" to "the return value is
1866 <tt>pos_type(off_type(-1))</tt>" </p>
1867
1868 <p>In D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 18, change "the object
1869 stores an invalid stream position" to "the return value is
1870 <tt>pos_type(off_type(-1))</tt>"</p>
1871 <hr>
1872 <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/papers/2005/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;29 Jun 1998</p>
1873 <p>The class summary for basic_streambuf&lt;&gt;, in 27.5.2, says that
1874 showmanyc has return type int. However, 27.5.2.4.3 says that its
1875 return type is streamsize. </p>
1876 <p><b>Proposed resolution:</b></p>
1877 <p>Change <tt>showmanyc</tt>'s return type in the
1878 27.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> class summary to <tt>streamsize</tt>.</p>
1879 <hr>
1880 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;1 Jul 1998</p>
1881 <p>21.1.3.2, paragraph 3, says "The types streampos and
1882 wstreampos may be different if the implementation supports no shift
1883 encoding in narrow-oriented iostreams but supports one or more shift
1884 encodings in wide-oriented streams". </p>
1885
1886 <p>That's wrong: the two are the same type. The &lt;iosfwd&gt; summary
1887 in 27.2 says that streampos and wstreampos are, respectively, synonyms
1888 for fpos&lt;char_traits&lt;char&gt;::state_type&gt; and
1889 fpos&lt;char_traits&lt;wchar_t&gt;::state_type&gt;, and, flipping back
1890 to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
1891 char_traits&lt;char&gt;::state_type and
1892 char_traits&lt;wchar_t&gt;::state_type must both be mbstate_t. </p>
1893 <p><b>Proposed resolution:</b></p>
1894 <p>Remove the sentence in 21.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a> paragraph 3 which
1895 begins "The types streampos and wstreampos may be
1896 different..." . </p>
1897 <hr>
1898 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;28 Jul 1998</p>
1899 <p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
1900 next pointer for the input sequence by n." </p>
1901
1902 <p>The straightforward interpretation is that it is just gptr() +=
1903 n. An alternative interpretation, though, is that it behaves as if it
1904 calls sbumpc n times. (The issue, of course, is whether it might ever
1905 call underflow.) There is a similar ambiguity in the case of
1906 pbump. </p>
1907
1908 <p>(The "classic" AT&amp;T implementation used the
1909 former interpretation.)</p>
1910 <p><b>Proposed resolution:</b></p>
1911 <p>Change 27.5.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</a> paragraph 4 gbump effects from:</p>
1912
1913 <blockquote>
1914   <p>Effects: Advances the next pointer for the input sequence by n.</p>
1915 </blockquote>
1916
1917 <p>to:</p>
1918
1919 <blockquote>
1920   <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
1921 </blockquote>
1922
1923 <p>Make the same change to 27.5.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.streambuf.put.area"> [lib.streambuf.put.area]</a> paragraph 4 pbump
1924 effects.</p>
1925 <hr>
1926 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;3 Aug 1998</p>
1927 <p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
1928 formatted input functions. Some of the functions defined in section
1929 27.6.1.2 explicitly say that those requirements apply ("Behaves
1930 like a formatted input member (as described in 27.6.1.2.1)"), but
1931 others don't. The question: is 27.6.1.2.1 supposed to apply to
1932 everything in 27.6.1.2, or only to those member functions that
1933 explicitly say "behaves like a formatted input member"? Or
1934 to put it differently: are we to assume that everything that appears
1935 in a section called "Formatted input functions" really is a
1936 formatted input function? I assume that 27.6.1.2.1 is intended to
1937 apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
1938 is not intended to apply to extractors like </p>
1939
1940 <pre>    basic_istream&amp; operator&gt;&gt;(basic_istream&amp; (*pf)(basic_istream&amp;));</pre>
1941
1942 <p>and </p>
1943
1944 <pre>    basic_istream&amp; operator&gt;&gt;(basic_streammbuf*);</pre>
1945
1946 <p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
1947 output. </p>
1948
1949 <p>Comments from Judy Ward: It seems like the problem is that the
1950 basic_istream and basic_ostream operator &lt;&lt;()'s that are used
1951 for the manipulators and streambuf* are in the wrong section and
1952 should have their own separate section or be modified to make it clear
1953 that the "Common requirements" listed in section 27.6.1.2.1
1954 (for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
1955 apply to them. </p>
1956
1957 <p>Additional comments from Dietmar Kühl: It appears to be somewhat
1958 nonsensical to consider the functions defined in 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> paragraphs 1 to 5 to be "Formatted input
1959 function" but since these functions are defined in a section
1960 labeled "Formatted input functions" it is unclear to me
1961 whether these operators are considered formatted input functions which
1962 have to conform to the "common requirements" from 27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>: If this is the case, all manipulators, not
1963 just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
1964 set (... but setting <tt>noskipws</tt> using the manipulator syntax
1965 would also skip whitespace :-)</p> <p>It is not clear which functions
1966 are to be considered unformatted input functions. As written, it seems
1967 that all functions in 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> are unformatted input
1968 functions. However, it does not really make much sense to construct a
1969 sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
1970 unclear what happens to the <tt>gcount()</tt> if
1971 eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
1972 <tt>sync()</tt> is called: These functions don't extract characters,
1973 some of them even "unextract" a character. Should this still
1974 be reflected in <tt>gcount()</tt>? Of course, it could be read as if
1975 after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
1976 (the last unformatted input function, <tt>gcount()</tt>, didn't
1977 extract any character) and after a call to <tt>putback()</tt>
1978 <tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
1979 function <tt>putback()</tt> did "extract" back into the
1980 stream). Correspondingly for <tt>unget()</tt>. Is this what is
1981 intended?  If so, this should be clarified. Otherwise, a corresponding
1982 clarification should be used.</p>
1983 <p><b>Proposed resolution:</b></p>
1984 <p>
1985 In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
1986 Change the beginning of the second sentence from "The conversion
1987 occurs" to "These extractors behave as formatted input functions (as
1988 described in 27.6.1.2.1).  After a sentry object is constructed,
1989 the conversion occurs"
1990 </p>
1991
1992 <p>
1993 In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
1994 Add an effects clause.  "Effects: None.  This extractor does
1995 not behave as a formatted input function (as described in
1996 27.6.1.2.1).
1997 </p>
1998
1999 <p>
2000 In 27.6.1.2.3, [lib.istream::extractors], paragraph 2.  Change the
2001 effects clause to "Effects: Calls pf(*this).  This extractor does not
2002 behave as a formatted input function (as described in 27.6.1.2.1).
2003 </p>
2004
2005 <p>
2006 In 27.6.1.2.3, [lib.istream::extractors], paragraph 4.  Change the
2007 effects clause to "Effects: Calls pf(*this).  This extractor does not
2008 behave as a formatted input function (as described in 27.6.1.2.1).
2009 </p>
2010
2011 <p>
2012 In 27.6.1.2.3, [lib.istream::extractors], paragraph 12.  Change the
2013 first two sentences from "If sb is null, calls setstate(failbit),
2014 which may throw ios_base::failure (27.4.4.3).  Extracts characters
2015 from *this..." to "Behaves as a formatted input function (as described
2016 in 27.6.1.2.1).  If sb is null, calls setstate(failbit), which may
2017 throw ios_base::failure (27.4.4.3).  After a sentry object is
2018 constructed, extracts characters from *this...".
2019 </p>
2020
2021 <p>
2022 In 27.6.1.3, [lib.istream.unformatted], before paragraph 2.  Add an
2023 effects clause.  "Effects: none. This member function does not behave
2024 as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
2025 </p>
2026
2027 <p>
2028 In 27.6.1.3, [lib.istream.unformatted], paragraph 3.  Change the
2029 beginning of the first sentence of the effects clause from "Extracts a
2030 character" to "Behaves as an unformatted input function (as described
2031 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
2032 character"
2033 </p>
2034
2035 <p>
2036 In 27.6.1.3, [lib.istream.unformatted], paragraph 5.  Change the
2037 beginning of the first sentence of the effects clause from "Extracts a
2038 character" to "Behaves as an unformatted input function (as described
2039 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
2040 character"
2041 </p>
2042
2043 <p>
2044 In 27.6.1.3, [lib.istream.unformatted], paragraph 5.  Change the
2045 beginning of the first sentence of the effects clause from "Extracts
2046 characters" to "Behaves as an unformatted input function (as described
2047 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2048 characters"
2049 </p>
2050
2051 <p>
2052 [No change needed in paragraph 10, because it refers to paragraph 7.]
2053 </p>
2054
2055 <p>
2056 In 27.6.1.3, [lib.istream.unformatted], paragraph 12.  Change the
2057 beginning of the first sentence of the effects clause from "Extracts
2058 characters" to "Behaves as an unformatted input function (as described
2059 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2060 characters"
2061 </p>
2062
2063 <p>
2064 [No change needed in paragraph 15.]
2065 </p>
2066
2067 <p>
2068 In 27.6.1.3, [lib.istream.unformatted], paragraph 17.  Change the
2069 beginning of the first sentence of the effects clause from "Extracts
2070 characters" to "Behaves as an unformatted input function (as described
2071 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2072 characters"
2073 </p>
2074
2075 <p>
2076 [No change needed in paragraph 23.]
2077 </p>
2078
2079 <p>
2080 In 27.6.1.3, [lib.istream.unformatted], paragraph 24.  Change the
2081 beginning of the first sentence of the effects clause from "Extracts
2082 characters" to "Behaves as an unformatted input function (as described
2083 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2084 characters"
2085 </p>
2086
2087 <p>
2088 In 27.6.1.3, [lib.istream.unformatted], before paragraph 27.  Add an
2089 Effects clause: "Effects: Behaves as an unformatted input function (as
2090 described in 27.6.1.3, paragraph 1).  After constructing a sentry
2091 object, reads but does not extract the current input character."
2092 </p>
2093
2094 <p>
2095 In 27.6.1.3, [lib.istream.unformatted], paragraph 28.  Change the
2096 first sentence of the Effects clause from "If !good() calls" to
2097 Behaves as an unformatted input function (as described in 27.6.1.3,
2098 paragraph 1).  After constructing a sentry object, if !good() calls"
2099 </p>
2100
2101 <p>
2102 In 27.6.1.3, [lib.istream.unformatted], paragraph 30.  Change the
2103 first sentence of the Effects clause from "If !good() calls" to
2104 "Behaves as an unformatted input function (as described in 27.6.1.3,
2105 paragraph 1).  After constructing a sentry object, if !good() calls"
2106 </p>
2107
2108 <p>
2109 In 27.6.1.3, [lib.istream.unformatted], paragraph 32.  Change the
2110 first sentence of the Effects clause from "If !good() calls..." to
2111 "Behaves as an unformatted input function (as described in 27.6.1.3,
2112 paragraph 1).  After constructing a sentry object, if !good()
2113 calls..."  Add a new sentence to the end of the Effects clause:
2114 "[Note: this function extracts no characters, so the value returned
2115 by the next call to gcount() is 0.]"
2116 </p>
2117
2118 <p>
2119 In 27.6.1.3, [lib.istream.unformatted], paragraph 34.  Change the
2120 first sentence of the Effects clause from "If !good() calls" to
2121 "Behaves as an unformatted input function (as described in 27.6.1.3,
2122 paragraph 1).  After constructing a sentry object, if !good() calls".
2123 Add a new sentence to the end of the Effects clause: "[Note: this
2124 function extracts no characters, so the value returned by the next
2125 call to gcount() is 0.]"
2126 </p>
2127
2128 <p>
2129 In 27.6.1.3, [lib.istream.unformatted], paragraph 36.  Change the
2130 first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
2131 as an unformatted input function (as described in 27.6.1.3, paragraph
2132 1), except that it does not count the number of characters extracted
2133 and does not affect the value returned by subsequent calls to
2134 gcount().  After constructing a sentry object, if rdbuf() is"
2135 </p>
2136
2137 <p>
2138 In 27.6.1.3, [lib.istream.unformatted], before paragraph 37.  Add an
2139 Effects clause: "Effects: Behaves as an unformatted input function (as
2140 described in 27.6.1.3, paragraph 1), except that it does not count the
2141 number of characters extracted and does not affect the value returned
2142 by subsequent calls to gcount()."  Change the first sentence of
2143 paragraph 37 from "if fail()" to "after constructing a sentry object,
2144 if fail()".
2145 </p>
2146
2147 <p>
2148 In 27.6.1.3, [lib.istream.unformatted], paragraph 38.  Change the
2149 first sentence of the Effects clause from "If fail()" to "Behaves
2150 as an unformatted input function (as described in 27.6.1.3, paragraph
2151 1), except that it does not count the number of characters extracted
2152 and does not affect the value returned by subsequent calls to
2153 gcount().  After constructing a sentry object, if fail()
2154 </p>
2155
2156 <p>
2157 In 27.6.1.3, [lib.istream.unformatted], paragraph 40.  Change the
2158 first sentence of the Effects clause from "If fail()" to "Behaves
2159 as an unformatted input function (as described in 27.6.1.3, paragraph
2160 1), except that it does not count the number of characters extracted
2161 and does not affect the value returned by subsequent calls to
2162 gcount().  After constructing a sentry object, if fail()
2163 </p>
2164
2165 <p>
2166 In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1.  Change
2167 the beginning of the third sentence from "The formatting conversion"
2168 to "These extractors behave as formatted output functions (as
2169 described in 27.6.2.5.1).  After the sentry object is constructed, the
2170 conversion occurs".
2171 </p>
2172
2173 <p>
2174 In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1.  Add an
2175 effects clause: "Effects: None. Does not behave as a formatted output
2176 function (as described in 27.6.2.5.1).".
2177 </p>
2178
2179 <p>
2180 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2.  Change the
2181 effects clause to "Effects: calls pf(*this).  This extractor does not
2182 behave as a formatted output function (as described in 27.6.2.5.1).".
2183 </p>
2184
2185 <p>
2186 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4.  Change the
2187 effects clause to "Effects: calls pf(*this).  This extractor does not
2188 behave as a formatted output function (as described in 27.6.2.5.1).".
2189 </p>
2190
2191 <p>
2192 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6.  Change the first
2193 sentence from "If sb" to "Behaves as a formatted output function (as
2194 described in 27.6.2.5.1).  After the sentry object is constructed, if
2195 sb".
2196 </p>
2197
2198 <p>
2199 In 27.6.2.6 [lib.ostream.unformatted], paragraph 2.  Change the first
2200 sentence from "Inserts the character" to "Behaves as an unformatted
2201 output function (as described in 27.6.2.6, paragraph 1).  After
2202 constructing a sentry object, inserts the character".
2203 </p>
2204
2205 <p>
2206 In 27.6.2.6 [lib.ostream.unformatted], paragraph 5.  Change the first
2207 sentence from "Obtains characters" to "Behaves as an unformatted
2208 output function (as described in 27.6.2.6, paragraph 1).  After
2209 constructing a sentry object, obtains characters".
2210 </p>
2211
2212 <p>
2213 In 27.6.2.6 [lib.ostream.unformatted], paragraph 7.  Add a new
2214 sentence at the end of the paragraph: "Does not behave as an
2215 unformatted output function (as described in 27.6.2.6, paragraph 1)."
2216 </p>
2217 <p><b>Rationale:</b></p>
2218 <p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
2219 by Judy Ward and Matt Austern.  This proposed resolution is section
2220 VI of that paper.</p>
2221 <hr>
2222 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
2223 <p>The introduction to the section on unformatted input (27.6.1.3)
2224 says that every unformatted input function catches all exceptions that
2225 were thrown during input, sets badbit, and then conditionally rethrows
2226 the exception. That seems clear enough. Several of the specific
2227 functions, however, such as get() and read(), are documented in some
2228 circumstances as setting eofbit and/or failbit. (The standard notes,
2229 correctly, that setting eofbit or failbit can sometimes result in an
2230 exception being thrown.) The question: if one of these functions
2231 throws an exception triggered by setting failbit, is this an exception
2232 "thrown during input" and hence covered by 27.6.1.3, or does
2233 27.6.1.3 only refer to a limited class of exceptions? Just to make
2234 this concrete, suppose you have the following snippet. </p>
2235
2236 <pre>
2237   char buffer[N];
2238   istream is;
2239   ...
2240   is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
2241   is.read(buffer, N);</pre>
2242
2243 <p>Now suppose we reach EOF before we've read N characters. What
2244 iostate bits can we expect to be set, and what exception (if any) will
2245 be thrown? </p>
2246 <p><b>Proposed resolution:</b></p>
2247 <p>
2248 In 27.6.1.3, paragraph 1, after the sentence that begins
2249 "If an exception is thrown...", add the following
2250 parenthetical comment: "(Exceptions thrown from
2251 <tt>basic_ios&lt;&gt;::clear()</tt> are not caught or rethrown.)"
2252 </p>
2253 <p><b>Rationale:</b></p>
2254 <p>The LWG looked to two alternative wordings, and choose the proposed
2255 resolution as better standardese.</p>
2256 <hr>
2257 <a name="62"></a><h3><a name="62">62.&nbsp;<tt>Sync</tt>'s return value</a></h3><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
2258 <p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
2259 "calls rdbuf()-&gt;pubsync() and, if that function returns -1
2260 ... returns traits::eof()." </p>
2261
2262 <p>That looks suspicious, because traits::eof() is of type
2263 traits::int_type while the return type of sync() is int. </p>
2264 <p><b>Proposed resolution:</b></p>
2265 <p>In 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, paragraph 36, change "returns
2266 <tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
2267 </p>
2268 <hr>
2269 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;11 Aug 1998</p>
2270 <p>Clause 27 details an exception-handling policy for formatted input,
2271 unformatted input, and formatted output. It says nothing for
2272 unformatted output (27.6.2.6). 27.6.2.6 should either include the same
2273 kind of exception-handling policy as in the other three places, or
2274 else it should have a footnote saying that the omission is
2275 deliberate. </p>
2276 <p><b>Proposed resolution:</b></p>
2277 <p>
2278 In 27.6.2.6, paragraph 1, replace the last sentence ("In any
2279 case, the unformatted output function ends by destroying the sentry
2280 object, then returning the value specified for the formatted output
2281 function.") with the following text:
2282 </p>
2283 <blockquote>
2284 If an exception is thrown during output, then <tt>ios::badbit</tt> is
2285 turned on [Footnote: without causing an <tt>ios::failure</tt> to be
2286 thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &amp;
2287 badbit) != 0</tt> then the exception is rethrown.  In any case, the
2288 unformatted output function ends by destroying the sentry object,
2289 then, if no exception was thrown, returning the value specified for
2290 the formatted output function.
2291 </blockquote>
2292 <p><b>Rationale:</b></p>
2293 <p>
2294 This exception-handling policy is consistent with that of formatted
2295 input, unformatted input, and formatted output.
2296 </p>
2297 <hr>
2298 <a name="64"><h3>64.&nbsp;Exception handling in <tt>basic_istream::operator&gt;&gt;(basic_streambuf*)</tt>
2299 </h3></a><p><b>Section:</b>&nbsp;27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;11 Aug 1998 </p>
2300 <p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
2301 different ways, depending on whether the second sentence is read as an
2302 elaboration of the first. </p>
2303 <p><b>Proposed resolution:</b></p>
2304 <p>Replace 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, paragraph 13, which begins
2305 "If the function inserts no characters ..." with:</p>
2306
2307 <blockquote>
2308   <p>If the function inserts no characters, it calls
2309   <tt>setstate(failbit)</tt>, which may throw
2310   <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
2311   because it caught an exception thrown while extracting characters
2312   from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
2313   (27.4.4.3), then the caught exception is rethrown. </p>
2314 </blockquote>
2315 <hr>
2316 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;18 Aug 1998</p>
2317 <p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
2318 "Performs an operation that is defined separately for each class
2319 derived from strstreambuf". This is obviously an incorrect
2320 cut-and-paste from basic_streambuf. There are no classes derived from
2321 strstreambuf. </p>
2322 <p><b>Proposed resolution:</b></p>
2323 <p>D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 19, replace the setbuf effects
2324 clause which currently says "Performs an operation that is
2325 defined separately for each class derived from strstreambuf"
2326 with:</p>
2327
2328 <blockquote>
2329   <p><b>Effects</b>: implementation defined, except that
2330   <tt>setbuf(0,0)</tt> has no effect.</p>
2331 </blockquote>
2332 <hr>
2333 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;14 Jul 1998</p>
2334 <p>Extractors for char* (27.6.1.2.3) do not store a null character
2335 after the extracted character sequence whereas the unformatted
2336 functions like get() do. Why is this?</p>
2337
2338 <p>Comment from Jerry Schwarz: There is apparently an editing
2339 glitch. You'll notice that the last item of the list of what stops
2340 extraction doesn't make any sense. It was supposed to be the line that
2341 said a null is stored.</p>
2342 <p><b>Proposed resolution:</b></p>
2343 <p>27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, paragraph 7, change the last list
2344 item from:</p>
2345
2346 <blockquote>
2347   A null byte (<tt>charT()</tt>) in the next position, which may be
2348   the first position if no characters were extracted.
2349 </blockquote>
2350
2351 <p>to become a new paragraph which reads:</p>
2352
2353 <blockquote>
2354   Operator&gt;&gt; then stores a null byte (<tt>charT()</tt>) in the
2355   next position, which may be the first position if no characters were
2356   extracted.
2357 </blockquote>
2358 <hr>
2359 <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/papers/2005/lib-containers.html#lib.vector"> [lib.vector]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;29 Jul 1998</p>
2360 <p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
2361
2362 <p>(Please note that this is entirely separate from the question of
2363 whether a vector iterator is required to be a pointer; the answer to
2364 that question is clearly "no," as it would rule out
2365 debugging implementations)</p>
2366 <p><b>Proposed resolution:</b></p>
2367 <p>Add the following text to the end of 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.vector"> [lib.vector]</a>,
2368 paragraph 1. </p>
2369
2370 <blockquote>
2371   <p>The elements of a vector are stored contiguously, meaning that if
2372   v is a <tt>vector&lt;T, Allocator&gt;</tt> where T is some type
2373   other than <tt>bool</tt>, then it obeys the identity <tt>&amp;v[n]
2374   == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt; v.size()</tt>.</p>
2375 </blockquote>
2376 <p><b>Rationale:</b></p>
2377 <p>The LWG feels that as a practical matter the answer is clearly
2378 "yes".  There was considerable discussion as to the best way
2379 to express the concept of "contiguous", which is not
2380 directly defined in the standard.  Discussion included:</p>
2381
2382 <ul>
2383   <li>An operational definition similar to the above proposed resolution is
2384     already used for valarray (26.3.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a>).</li>
2385   <li>There is no need to explicitly consider a user-defined operator&amp;
2386     because elements must be copyconstructible (23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> para 3)
2387     and copyconstructible (20.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>) specifies
2388     requirements for operator&amp;.</li>
2389   <li>There is no issue of one-past-the-end because of language rules.</li>
2390 </ul>
2391 <hr>
2392 <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/papers/2005/lib-support.html#lib.support.exception"> [lib.support.exception]</a>, 18.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.uncaught"> [lib.uncaught]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;Unknown</p>
2393 <p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
2394
2395 <p>uncaught_exception() doesn't have a throw specification.</p>
2396
2397 <p>It is intentional ? Does it means that one should be prepared to
2398 handle exceptions thrown from uncaught_exception() ?</p>
2399
2400 <p>uncaught_exception() is called in exception handling contexts where
2401 exception safety is very important.</p>
2402 <p><b>Proposed resolution:</b></p>
2403 <p>In 15.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/except.html#except.uncaught"> [except.uncaught]</a>, paragraph 1, 18.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-support.html#lib.uncaught"> [lib.uncaught]</a>, add "throw()" to uncaught_exception().</p>
2404 <hr>
2405 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;13 Aug 1998</p>
2406 <p>The locale facet member <tt>time_get&lt;&gt;::do_get_monthname</tt>
2407 is described in 22.2.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.virtuals]</a> with five arguments,
2408 consistent with do_get_weekday and with its specified use by member
2409 get_monthname. However, in the synopsis, it is specified instead with
2410 four arguments. The missing argument is the "end" iterator
2411 value.</p>
2412 <p><b>Proposed resolution:</b></p>
2413 <p>In 22.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a>, add an "end" argument to
2414 the declaration of member do_monthname as follows:</p>
2415
2416 <pre>  virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&amp;,
2417                                      ios_base::iostate&amp; err, tm* t) const;</pre>
2418 <hr>
2419 <a name="74"><h3>74.&nbsp;Garbled text for <tt>codecvt::do_max_length</tt>
2420 </h3></a><p><b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;8 Sep 1998</p>
2421 <p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
2422 clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
2423 parentheses and a spurious <b>n</b>.</p>
2424 <p><b>Proposed resolution:</b></p>
2425 <p>Replace 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 11 with the
2426 following:</p>
2427
2428 <blockquote>
2429   <b>Returns</b>: The maximum value that
2430   <tt>do_length(state, from, from_end, 1)</tt> can return for any
2431   valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
2432   <tt>state</tt>. The specialization <tt>codecvt&lt;char, char,
2433   mbstate_t&gt;::do_max_length()</tt> returns 1.
2434 </blockquote>
2435 <hr>
2436 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp; Matt
2437 Austern&nbsp; <b>Date:</b>&nbsp; 18 Sep 1998</p>
2438 <p>The class synopses for classes <tt>codecvt&lt;&gt;</tt> (22.2.1.5)
2439 and <tt>codecvt_byname&lt;&gt;</tt> (22.2.1.6) say that the first
2440 parameter of the member functions <tt>length</tt> and
2441 <tt>do_length</tt> is of type <tt>const stateT&amp;</tt>. The member
2442 function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
2443 paragraph 9) say that the type is <tt>stateT&amp;</tt>.  Either the
2444 synopsis or the summary must be changed. </p>
2445
2446 <p>If (as I believe) the member function descriptions are correct,
2447 then we must also add text saying how <tt>do_length</tt> changes its
2448 <tt>stateT</tt> argument. </p>
2449 <p><b>Proposed resolution:</b></p>
2450 <p>In 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>,
2451 change the <tt>stateT</tt> argument type on both member
2452 <tt>length()</tt> and member <tt>do_length()</tt> from </p>
2453
2454 <blockquote>
2455   <p><tt>const stateT&amp;</tt></p>
2456 </blockquote>
2457
2458 <p>to</p>
2459
2460 <blockquote>
2461   <p><tt>stateT&amp;</tt></p>
2462 </blockquote>
2463
2464 <p>In 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, add to the definition for member
2465 <tt>do_length</tt> a paragraph:</p>
2466
2467 <blockquote>
2468   <p>Effects: The effect on the <tt>state</tt> argument is ``as if''
2469   it called <tt>do_in(state, from, from_end, from, to, to+max,
2470   to)</tt> for <tt>to</tt> pointing to a buffer of at least
2471   <tt>max</tt> elements.</p>
2472 </blockquote>
2473 <hr>
2474 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;25 Sep 1998</p>
2475 <p>This issue concerns the requirements on classes derived from
2476 <tt>codecvt</tt>, including user-defined classes. What are the
2477 restrictions on the conversion from external characters
2478 (e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
2479 Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
2480 the I/O library make? </p>
2481
2482 <p>The question is whether it's possible to convert from internal
2483 characters to external characters one internal character at a time,
2484 and whether, given a valid sequence of external characters, it's
2485 possible to pick off internal characters one at a time. Or, to put it
2486 differently: given a sequence of external characters and the
2487 corresponding sequence of internal characters, does a position in the
2488 internal sequence correspond to some position in the external
2489 sequence? </p>
2490
2491 <p>To make this concrete, suppose that <tt>[first, last)</tt> is a
2492 sequence of <i>M</i> external characters and that <tt>[ifirst,
2493 ilast)</tt> is the corresponding sequence of <i>N</i> internal
2494 characters, where <i>N &gt; 1</i>. That is, <tt>my_encoding.in()</tt>,
2495 applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
2496 ilast)</tt>. Now the question: does there necessarily exist a
2497 subsequence of external characters, <tt>[first, last_1)</tt>, such
2498 that the corresponding sequence of internal characters is the single
2499 character <tt>*ifirst</tt>?
2500 </p>
2501
2502 <p>(What a "no" answer would mean is that
2503 <tt>my_encoding</tt> translates sequences only as blocks. There's a
2504 sequence of <i>M</i> external characters that maps to a sequence of
2505 <i>N</i> internal characters, but that external sequence has no
2506 subsequence that maps to <i>N-1</i> internal characters.) </p>
2507
2508 <p>Some of the wording in the standard, such as the description of
2509 <tt>codecvt::do_max_length</tt> (22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>,
2510 paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 3) suggests that it must always be
2511 possible to pick off internal characters one at a time from a sequence
2512 of external characters. However, this is never explicitly stated one
2513 way or the other. </p>
2514
2515 <p>This issue seems (and is) quite technical, but it is important if
2516 we expect users to provide their own encoding facets. This is an area
2517 where the standard library calls user-supplied code, so a well-defined
2518 set of requirements for the user-supplied code is crucial. Users must
2519 be aware of the assumptions that the library makes. This issue affects
2520 positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
2521 and several of <tt>codecvt</tt>'s member functions. </p>
2522 <p><b>Proposed resolution:</b></p>
2523 <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/papers/2005/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 2:</p>
2524
2525 <blockquote>
2526 <p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
2527 (27.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>) must have the property that if</p>
2528 <pre>    do_out(state, from, from_end, from_next, to, to_lim, to_next)
2529 </pre>
2530 would return <tt>ok</tt>, where <tt>from != from_end</tt>, then
2531 <pre>    do_out(state, from, from + 1, from_next, to, to_end, to_next)
2532 </pre>
2533 must also return <tt>ok</tt>, and that if
2534 <pre>    do_in(state, from, from_end, from_next, to, to_lim, to_next)
2535 </pre>
2536 would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then
2537 <pre>    do_in(state, from, from_end, from_next, to, to + 1, to_next)
2538 </pre>
2539 <p>must also return <tt>ok</tt>.  [<i>Footnote:</i> Informally, this
2540 means that <tt>basic_filebuf</tt> assumes that the mapping from
2541 internal to external characters is 1 to N: a <tt>codecvt</tt> that is
2542 used by <tt>basic_filebuf</tt> must be able to translate characters
2543 one internal character at a time.  <i>--End Footnote</i>]</p>
2544 </blockquote>
2545
2546 <p><i>[Redmond: Minor change in proposed resolution.  Original
2547 proposed resolution talked about "success", with a parenthetical
2548 comment that success meant returning <tt>ok</tt>.  New wording
2549 removes all talk about "success", and just talks about the
2550 return value.]</i></p>
2551
2552 <p><b>Rationale:</b></p>
2553
2554   <p>The proposed resoluion says that conversions can be performed one
2555   internal character at a time.  This rules out some encodings that
2556   would otherwise be legal.  The alternative answer would mean there
2557   would be some internal positions that do not correspond to any
2558   external file position.</p>
2559   <p>
2560   An example of an encoding that this rules out is one where the
2561   <tt>internT</tt> and <tt>externT</tt> are of the same type, and
2562   where the internal sequence <tt>c1 c2</tt> corresponds to the
2563   external sequence <tt>c2 c1</tt>.
2564   </p>
2565   <p>It was generally agreed that <tt>basic_filebuf</tt> relies
2566   on this property: it was designed under the assumption that
2567   the external-to-internal mapping is N-to-1, and it is not clear
2568   that <tt>basic_filebuf</tt> is implementable without that
2569   restriction.
2570   </p>
2571   <p>
2572   The proposed resolution is expressed as a restriction on
2573   <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
2574   than a blanket restriction on all <tt>codecvt</tt> facets,
2575   because <tt>basic_filebuf</tt> is the only other part of the
2576   library that uses <tt>codecvt</tt>.  If a user wants to define
2577   a <tt>codecvt</tt> facet that implements a more general N-to-M
2578   mapping, there is no reason to prohibit it, so long as the user
2579   does not expect <tt>basic_filebuf</tt> to be able to use it.
2580   </p>
2581 <hr>
2582 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2583 <p>typo: event_call_back should be event_callback &nbsp; </p>
2584 <p><b>Proposed resolution:</b></p>
2585 <p>In the 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> synopsis change
2586 "event_call_back" to "event_callback". </p>
2587 <hr>
2588 <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/papers/2005/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2589 <p>In 26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> polar is declared as follows:</p>
2590 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;); </pre>
2591
2592 <p>In 26.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> it is declared as follows:</p>
2593 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
2594
2595 <p>Thus whether the second parameter is optional is not clear. </p>
2596 <p><b>Proposed resolution:</b></p>
2597 <p>In 26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> change:</p>
2598 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;);</pre>
2599
2600 <p>to:</p>
2601 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
2602 <hr>
2603 <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/papers/2005/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.complex"> [lib.complex]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2604 <p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
2605 class complex. This redundancy should be removed.</p>
2606 <p><b>Proposed resolution:</b></p>
2607 <p>Reduce redundancy according to the general style of the standard. </p>
2608 <hr>
2609 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2610 <p>Many string member functions throw if size is getting or exceeding
2611 npos. However, I wonder why they don't throw if size is getting or
2612 exceeding max_size() instead of npos.  May be npos is known at compile
2613 time, while max_size() is known at runtime. However, what happens if
2614 size exceeds max_size() but not npos, then? It seems the standard
2615 lacks some clarifications here.</p>
2616 <p><b>Proposed resolution:</b></p>
2617 <p>After 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> paragraph 4 ("The functions
2618 described in this clause...") add a new paragraph:</p>
2619
2620 <blockquote>
2621   <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
2622   <tt> max_size()</tt> then
2623   the operation throws <tt>length_error</tt>.</p>
2624 </blockquote>
2625 <p><b>Rationale:</b></p>
2626 <p>The LWG believes length_error is the correct exception to throw.</p>
2627 <hr>
2628 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2629 <p>The constructor from a range:</p>
2630
2631 <pre>template&lt;class InputIterator&gt;
2632          basic_string(InputIterator begin, InputIterator end,
2633                       const Allocator&amp; a = Allocator());</pre>
2634
2635 <p>lacks a throws clause. However, I would expect that it throws
2636 according to the other constructors if the numbers of characters in
2637 the range equals npos (or exceeds max_size(), see above). </p>
2638 <p><b>Proposed resolution:</b></p>
2639 <p>In 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, Strike throws paragraphs for
2640 constructors which say "Throws: length_error if n ==
2641 npos."</p>
2642 <p><b>Rationale:</b></p>
2643 <p>Throws clauses for length_error if n == npos are no longer needed
2644 because they are subsumed by the general wording added by the
2645 resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#83">83</a>.</p>
2646 <hr>
2647 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2648 <p>The effect of operator &gt;&gt; for strings contain the following item:</p>
2649
2650 <p>&nbsp;&nbsp;&nbsp; <tt>isspace(c,getloc())</tt> is true for the next available input
2651 character c.</p>
2652
2653 <p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
2654 <p><b>Proposed resolution:</b></p>
2655 <p>In 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 1 Effects clause replace:</p>
2656
2657 <blockquote>
2658   <p><tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
2659 </blockquote>
2660
2661 <p>with:</p>
2662
2663 <blockquote>
2664   <p><tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
2665 </blockquote>
2666 <hr>
2667 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2668 <p>Operator &gt;&gt; and getline() for strings read until eof()
2669 in the input stream is true. However, this might never happen, if the
2670 stream can't read anymore without reaching EOF. So shouldn't it be
2671 changed into that it reads until !good() ? </p>
2672 <p><b>Proposed resolution:</b></p>
2673 <p>In 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string.io"> [lib.string.io]</a>, paragraph 1, replace:</p>
2674 <blockquote>
2675 Effects: Begins by constructing a sentry object k as if k were
2676 constructed by typename basic_istream&lt;charT,traits&gt;::sentry k( is). If
2677 bool( k) is true, it calls str.erase() and then extracts characters
2678 from is and appends them to str as if by calling str.append(1, c). If
2679 is.width() is greater than zero, the maximum number n of characters
2680 appended is is.width(); otherwise n is str.max_size(). Characters are
2681 extracted and appended until any of the following occurs:
2682 </blockquote>
2683 <p>with:</p>
2684 <blockquote>
2685 Effects: Behaves as a formatted input function (27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>).  After constructing a sentry object, if the
2686 sentry converts to true, calls str.erase() and then extracts
2687 characters from is and appends them to str as if by calling
2688 str.append(1,c). If is.width() is greater than zero, the maximum
2689 number n of characters appended is is.width(); otherwise n is
2690 str.max_size(). Characters are extracted and appended until any of the
2691 following occurs:
2692 </blockquote>
2693
2694 <p>In 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string.io"> [lib.string.io]</a>, paragraph 6, replace</p>
2695 <blockquote>
2696 Effects: Begins by constructing a sentry object k as if by typename
2697 basic_istream&lt;charT,traits&gt;::sentry k( is, true). If bool( k) is true,
2698 it calls str.erase() and then extracts characters from is and appends
2699 them to str as if by calling str.append(1, c) until any of the
2700 following occurs:
2701 </blockquote>
2702 <p>with:</p>
2703 <blockquote>
2704 Effects: Behaves as an unformatted input function (27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), except that it does not affect the value returned
2705 by subsequent calls to basic_istream&lt;&gt;::gcount().  After
2706 constructing a sentry object, if the sentry converts to true, calls
2707 str.erase() and then extracts characters from is and appends them to
2708 str as if by calling str.append(1,c) until any of the following
2709 occurs:
2710 </blockquote>
2711
2712 <p><i>[Redmond: Made changes in proposed resolution.  <tt>operator&gt;&gt;</tt>
2713 should be a formatted input function, not an unformatted input function.
2714 <tt>getline</tt> should not be required to set <tt>gcount</tt>, since
2715 there is no mechanism for <tt>gcount</tt> to be set except by one of
2716 <tt>basic_istream</tt>'s member functions.]</i></p>
2717
2718 <p><i>[Curaçao: Nico agrees with proposed resolution.]</i></p>
2719
2720 <p><b>Rationale:</b></p>
2721 <p>The real issue here is whether or not these string input functions
2722 get their characters from a streambuf, rather than by calling an
2723 istream's member functions, a streambuf signals failure either by
2724 returning eof or by throwing an exception; there are no other
2725 possibilities.  The proposed resolution makes it clear that these two
2726 functions do get characters from a streambuf.</p>
2727 <hr>
2728 <a name="92"><h3>92.&nbsp;Incomplete Algorithm Requirements</h3></a><p><b>Section:</b>&nbsp;25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2729 <p>The standard does not state, how often a function object is copied,
2730 called, or the order of calls inside an algorithm. This may lead to
2731 surprising/buggy behavior. Consider the following example: </p>
2732
2733 <pre>class Nth {    // function object that returns true for the nth element
2734   private:
2735     int nth;     // element to return true for
2736     int count;   // element counter
2737   public:
2738     Nth (int n) : nth(n), count(0) {
2739     }
2740     bool operator() (int) {
2741         return ++count == nth;
2742     }
2743 };
2744 ....
2745 // remove third element
2746     list&lt;int&gt;::iterator pos;
2747     pos = remove_if(coll.begin(),coll.end(),  // range
2748                     Nth(3)),                  // remove criterion
2749     coll.erase(pos,coll.end()); </pre>
2750
2751 <p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
2752 happens because the usual implementation of the algorithm copies the
2753 function object internally: </p>
2754
2755 <pre>template &lt;class ForwIter, class Predicate&gt;
2756 ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op)
2757 {
2758     beg = find_if(beg, end, op);
2759     if (beg == end) {
2760         return beg;
2761     }
2762     else {
2763         ForwIter next = beg;
2764         return remove_copy_if(++next, end, beg, op);
2765     }
2766 } </pre>
2767
2768 <p>The algorithm uses find_if() to find the first element that should
2769 be removed. However, it then uses a copy of the passed function object
2770 to process the resulting elements (if any). Here, Nth is used again
2771 and removes also the sixth element. This behavior compromises the
2772 advantage of function objects being able to have a state. Without any
2773 cost it could be avoided (just implement it directly instead of
2774 calling find_if()). </p>
2775 <p><b>Proposed resolution:</b></p>
2776
2777 <p>Add a new paragraph following 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> paragraph 8:</p>
2778 <blockquote>
2779 [Note: Unless otherwise specified, algorithms that take function
2780 objects as arguments are permitted to copy those function objects
2781 freely.  Programmers for whom object identity is important should
2782 consider using a wrapper class that points to a noncopied
2783 implementation object, or some equivalent solution.]
2784 </blockquote>
2785
2786 <p><i>[Dublin: Pete Becker felt that this may not be a defect,
2787 but rather something that programmers need to be educated about.
2788 There was discussion of adding wording to the effect that the number
2789 and order of calls to function objects, including predicates, not
2790 affect the behavior of the function object.]</i></p>
2791
2792 <p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
2793 have a clear statement of "predicate" in the
2794 standard. People including me seemed to think "a function
2795 returning a Boolean value and being able to be called by an STL
2796 algorithm or be used as sorting criterion or ... is a
2797 predicate". But a predicate has more requirements: It should
2798 never change its behavior due to a call or being copied. IMHO we have
2799 to state this in the standard. If you like, see section 8.1.4 of my
2800 library book for a detailed discussion.]</i></p>
2801
2802 <p><i>[Kona: Nico will provide wording to the effect that "unless
2803 otherwise specified, the number of copies of and calls to function
2804 objects by algorithms is unspecified".&nbsp; Consider placing in
2805 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> after paragraph 9.]</i></p>
2806
2807 <p><i>[Santa Cruz: The standard doesn't currently guarantee that
2808   functions object won't be copied, and what isn't forbidden is
2809   allowed.  It is believed (especially since implementations that were
2810   written in concert with the standard do make copies of function
2811   objects) that this was intentional.  Thus, no normative change is
2812   needed.  What we should put in is a non-normative note suggesting to
2813   programmers that if they want to guarantee the lack of copying they
2814   should use something like the <tt>ref</tt> wrapper.]</i></p>
2815
2816 <p><i>[Oxford: Matt provided wording.]</i></p>
2817
2818
2819 <hr>
2820 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
2821 <p>Table 72 in 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> specifies semantics for
2822 <tt>*r++</tt> of:</p>
2823
2824 <p>&nbsp;&nbsp; <tt>{ T tmp = *r; ++r; return tmp; }</tt></p>
2825
2826 <p>There are two problems with this.  First, the return type is
2827 specified to be "T", as opposed to something like "convertible to T".
2828 This is too specific: we want to allow *r++ to return an lvalue.</p>
2829
2830 <p>Second, writing the semantics in terms of code misleadingly
2831 suggests that the effects *r++ should precisely replicate the behavior
2832 of this code, including side effects.  (Does this mean that *r++
2833 should invoke the copy constructor exactly as many times as the sample
2834 code above would?) See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#334">334</a> for a similar
2835 problem.</p>
2836
2837 <p><b>Proposed resolution:</b></p>
2838 In Table 72 in 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a>, change the return type
2839 for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".
2840 <p><b>Rationale:</b></p>
2841 <p>This issue has two parts: the return type, and the number of times
2842   the copy constructor is invoked.</p>
2843
2844 <p>The LWG believes the the first part is a real issue.  It's
2845   inappropriate for the return type to be specified so much more
2846   precisely for *r++ than it is for *r.  In particular, if r is of
2847   (say) type <tt>int*</tt>, then *r++ isn't <tt>int</tt>,
2848   but <tt>int&amp;</tt>.</p>
2849
2850 <p>The LWG does not believe that the number of times the copy
2851   constructor is invoked is a real issue.  This can vary in any case,
2852   because of language rules on copy constructor elision.  That's too
2853   much to read into these semantics clauses.</p>
2854
2855 <p>Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since
2856    we're told (24.1/3) that forward iterators satisfy all the requirements
2857    of input iterators, we can't impose any requirements in the Input
2858    Iterator requirements table that forward iterators don't satisfy.</p>
2859 <hr>
2860 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
2861 <p>Set::iterator is described as implementation-defined with a
2862 reference to the container requirement; the container requirement says
2863 that const_iterator is an iterator pointing to const T and iterator an
2864 iterator pointing to T.</p>
2865
2866 <p>23.1.2 paragraph 2 implies that the keys should not be modified to
2867 break the ordering of elements. But that is not clearly
2868 specified. Especially considering that the current standard requires
2869 that iterator for associative containers be different from
2870 const_iterator. Set, for example, has the following: </p>
2871
2872 <p><tt>typedef implementation defined iterator;<br>
2873 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // See _lib.container.requirements_</tt></p>
2874
2875 <p>23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> actually requires that iterator type pointing
2876 to T (table 65). Disallowing user modification of keys by changing the
2877 standard to require an iterator for associative container to be the
2878 same as const_iterator would be overkill since that will unnecessarily
2879 significantly restrict the usage of associative container. A class to
2880 be used as elements of set, for example, can no longer be modified
2881 easily without either redesigning the class (using mutable on fields
2882 that have nothing to do with ordering), or using const_cast, which
2883 defeats requiring iterator to be const_iterator. The proposed solution
2884 goes in line with trusting user knows what he is doing. </p>
2885
2886 <p><b>Other Options Evaluated:</b> </p>
2887
2888 <p>Option A.&nbsp;&nbsp; In 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, paragraph 2, after
2889 first sentence, and before "In addition,...", add one line:
2890 </p>
2891
2892 <blockquote>
2893   <p>Modification of keys shall not change their strict weak ordering. </p>
2894 </blockquote>
2895
2896 <p>Option B.&nbsp;Add three new sentences to 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>:</p>
2897
2898 <blockquote>
2899   <p>At the end of paragraph 5: "Keys in an associative container
2900   are immutable." At the end of paragraph 6: "For
2901   associative containers where the value type is the same as the key
2902   type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
2903   constant iterators. It is unspecified whether or not
2904   <tt>iterator</tt> and <tt>const_iterator</tt> are the same
2905   type."</p>
2906 </blockquote>
2907
2908 <p>Option C.&nbsp;To 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, paragraph 3, which
2909 currently reads:</p>
2910
2911 <blockquote>
2912   <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
2913   comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
2914   container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
2915   == false &amp;&amp; comp(k2, k1) == false.</p>
2916 </blockquote>
2917
2918 <p>&nbsp; add the following:</p>
2919
2920 <blockquote>
2921   <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
2922   value whenever it is evaluated. [Note: If k2 is removed from the container and later
2923   reinserted, comp(k1, k2) must still return a consistent value but this value may be
2924   different than it was the first time k1 and k2 were in the same container. This is
2925   intended to allow usage like a string key that contains a filename, where comp compares
2926   file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
2927   reinserted, comp(k1, k2) must again return a consistent value but this value may be
2928   different than it was the previous time k2 was in the container.]</p>
2929 </blockquote>
2930 <p><b>Proposed resolution:</b></p>
2931 <p>Add the following to 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> at
2932 the indicated location:</p>
2933
2934 <blockquote>
2935   <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
2936   calling comp(k1, k2) shall always return the same
2937   value."</p>
2938   <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
2939   <p>At the end of paragraph 6: "For associative containers where the value type is the
2940   same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
2941   iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
2942   are the same type."</p>
2943 </blockquote>
2944 <p><b>Rationale:</b></p>
2945 <p>Several arguments were advanced for and against allowing set elements to be
2946 mutable as long as the ordering was not effected. The argument which swayed the
2947 LWG was one of safety; if elements were mutable, there would be no compile-time
2948 way to detect of a simple user oversight which caused ordering to be
2949 modified.  There was a report that this had actually happened in practice,
2950 and had been painful to diagnose.  If users need to modify elements,
2951 it is possible to use mutable members or const_cast.</p>
2952
2953 <p>Simply requiring that keys be immutable is not sufficient, because the comparison
2954 object may indirectly (via pointers) operate on values outside of the keys.</p>
2955
2956 <p>
2957 The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
2958 to be different types to allow for potential future work in which some
2959 member functions might be overloaded between the two types.  No such
2960 member functions exist now, and the LWG believes that user functionality
2961 will not be impaired by permitting the two types to be the same.  A
2962 function that operates on both iterator types can be defined for
2963 <tt>const_iterator</tt> alone, and can rely on the automatic
2964 conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
2965 </p>
2966
2967 <p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
2968 <hr>
2969 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
2970 <p>This is the only place in the whole standard where the implementation has to document
2971 something private.</p>
2972 <p><b>Proposed resolution:</b></p>
2973 <p>
2974 Remove the comment which says "// remainder implementation defined" from:
2975 </p>
2976
2977 <ul>
2978   <li>26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>
2979 </li>
2980   <li>26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a>
2981 </li>
2982   <li>26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a>
2983 </li>
2984   <li>26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
2985 </li>
2986 </ul>
2987 <hr>
2988 <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/papers/2005/lib-support.html#lib.exception"> [lib.exception]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
2989 <p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
2990 exception::what() is left unspecified. This issue has implications
2991 with exception safety of exception handling: some exceptions should
2992 not throw bad_alloc.</p>
2993 <p><b>Proposed resolution:</b></p>
2994 <p>Add to 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.exception"> [lib.exception]</a> paragraph 9 (exception::what notes
2995 clause) the sentence:</p>
2996
2997 <blockquote>
2998   <p>The return value remains valid until the exception object from which it is obtained is
2999   destroyed or a non-const member function of the exception object is called.</p>
3000 </blockquote>
3001 <p><b>Rationale:</b></p>
3002 <p>If an exception object has non-const members, they may be used
3003 to set internal state that should affect the contents of the string
3004 returned by <tt>what()</tt>.
3005 </p>
3006 <hr>
3007 <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/papers/2005/lib-utilities.html#lib.binders"> [lib.binders]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Bjarne Stroustrup&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
3008
3009 <p>There are no versions of binders that apply to non-const elements
3010 of a sequence. This makes examples like for_each() using bind2nd() on
3011 page 521 of "The C++ Programming Language (3rd)"
3012 non-conforming. Suitable versions of the binders need to be added.</p>
3013
3014 <p>Further discussion from Nico:</p>
3015
3016 <p>What is probably meant here is shown in the following example:</p>
3017
3018 <pre>class Elem {
3019   public:
3020     void print (int i) const { }
3021     void modify (int i) { }
3022 }; </pre>
3023 <pre>int main()
3024 {
3025     vector&lt;Elem&gt; coll(2);
3026     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::print),42));    // OK
3027     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::modify),42));   // ERROR
3028 }</pre>
3029
3030 <p>The error results from the fact that bind2nd() passes its first
3031 argument (the argument of the sequence) as constant reference. See the
3032 following typical implementation:</p>
3033
3034 <blockquote>
3035   <pre>template &lt;class Operation&gt;
3036 class binder2nd
3037   : public unary_function&lt;typename Operation::first_argument_type,
3038                           typename Operation::result_type&gt; {
3039 protected:
3040   Operation op;
3041   typename Operation::second_argument_type value;
3042 public:
3043   binder2nd(const Operation&amp; o,
3044             const typename Operation::second_argument_type&amp; v)
3045       : op(o), value(v) {} </pre>
3046   <pre> typename Operation::result_type
3047   operator()(const typename Operation::first_argument_type&amp; x) const {
3048     return op(x, value);
3049   }
3050 };</pre>
3051 </blockquote>
3052
3053 <p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
3054
3055 <blockquote>
3056   <pre>template &lt;class Operation&gt;
3057 class binder2nd
3058   : public unary_function&lt;typename Operation::first_argument_type,
3059                           typename Operation::result_type&gt; {
3060 protected:
3061   Operation op;
3062   typename Operation::second_argument_type value;
3063 public:
3064   binder2nd(const Operation&amp; o,
3065             const typename Operation::second_argument_type&amp; v)
3066       : op(o), value(v) {} </pre>
3067   <pre> typename Operation::result_type
3068   operator()(const typename Operation::first_argument_type&amp; x) const {
3069     return op(x, value);
3070   }
3071   typename Operation::result_type
3072   operator()(typename Operation::first_argument_type&amp; x) const {
3073     return op(x, value);
3074   }
3075 };</pre>
3076 </blockquote>
3077 <p><b>Proposed resolution:</b></p>
3078
3079 <p><b>Howard believes there is a flaw</b> in this resolution.
3080 See c++std-lib-9127.  We may need to reopen this issue.</p>
3081
3082 <p>In 20.3.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.binder.1st"> [lib.binder.1st]</a> in the declaration of binder1st after:</p>
3083 <blockquote>
3084   <p><tt>typename Operation::result_type<br>
3085   &nbsp;operator()(const typename Operation::second_argument_type&amp; x) const;</tt></p>
3086 </blockquote>
3087 <p>insert:</p>
3088 <blockquote>
3089   <p><tt>typename Operation::result_type<br>
3090   &nbsp;operator()(typename Operation::second_argument_type&amp; x) const;</tt></p>
3091 </blockquote>
3092 <p>In 20.3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.binder.2nd"> [lib.binder.2nd]</a> in the declaration of binder2nd after:</p>
3093 <blockquote>
3094   <p><tt>typename Operation::result_type<br>
3095   &nbsp;operator()(const typename Operation::first_argument_type&amp; x) const;</tt></p>
3096 </blockquote>
3097 <p>insert:</p>
3098 <blockquote>
3099   <p><tt>typename Operation::result_type<br>
3100   &nbsp;operator()(typename Operation::first_argument_type&amp; x) const;</tt></p>
3101 </blockquote>
3102
3103 <p><i>[Kona: The LWG discussed this at some length.It was agreed that
3104 this is a mistake in the design, but there was no consensus on whether
3105 it was a defect in the Standard.  Straw vote: NAD - 5.  Accept
3106 proposed resolution - 3.  Leave open - 6.]</i></p>
3107
3108 <p><i>[Copenhagen: It was generally agreed that this was a defect.
3109 Strap poll: NAD - 0.  Accept proposed resolution - 10.
3110 Leave open - 1.]</i></p>
3111
3112 <hr>
3113 <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/papers/2005/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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;15 Oct 1998</p>
3114 <p>Member istreambuf_iterator&lt;&gt;::equal is not declared
3115 "const", yet 24.5.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.istreambuf.iterator::op=="> [lib.istreambuf.iterator::op==]</a> says that operator==,
3116 which is const, calls it. This is contradictory. </p>
3117 <p><b>Proposed resolution:</b></p>
3118 <p>In 24.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a>,
3119 replace:</p>
3120
3121 <blockquote>
3122   <pre>bool equal(istreambuf_iterator&amp; b);</pre>
3123 </blockquote>
3124
3125 <p>with:</p>
3126
3127 <blockquote>
3128   <pre>bool equal(const istreambuf_iterator&amp; b) const;</pre>
3129 </blockquote>
3130 <hr>
3131 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Oct 1998</p>
3132 <p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
3133 constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
3134 reads "<i>s</i> is not null". However, <i>s</i> is a
3135 reference, and references can't be null. </p>
3136 <p><b>Proposed resolution:</b></p>
3137 <p>In 24.5.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a>:</p>
3138
3139 <p>Move the current paragraph 1, which reads "Requires: s is not
3140 null.", from the first constructor to the second constructor.</p>
3141
3142 <p>Insert a new paragraph 1 Requires clause for the first constructor
3143 reading:</p>
3144
3145 <blockquote>
3146   <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
3147 </blockquote>
3148 <hr>
3149 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;28 Oct 1998</p>
3150 <p>Section 18.4.1.3 contains the following example: </p>
3151
3152 <pre>[Example: This can be useful for constructing an object at a known address:
3153         char place[sizeof(Something)];
3154         Something* p = new (place) Something();
3155  -end example]</pre>
3156
3157 <p>First code line: "place" need not have any special alignment, and the
3158 following constructor could fail due to misaligned data.</p>
3159
3160 <p>Second code line: Aren't the parens on Something() incorrect?&nbsp; [Dublin: the LWG
3161 believes the () are correct.]</p>
3162
3163 <p>Examples are not normative, but nevertheless should not show code that is invalid or
3164 likely to fail.</p>
3165 <p><b>Proposed resolution:</b></p>
3166 <p>Replace the <u> first line of code</u> in the example in
3167 18.4.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> with:
3168 </p>
3169
3170 <blockquote>
3171   <pre>void* place = operator new(sizeof(Something));</pre>
3172 </blockquote>
3173 <hr>
3174 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;2 Nov 1998</p>
3175 <p>D.7.4.1 strstream constructors paragraph 2 says: </p>
3176
3177 <blockquote>
3178   <p>Effects: Constructs an object of class strstream, initializing the base class with
3179   iostream(&amp; sb) and initializing sb with one of the two constructors: </p>
3180   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
3181   elements. The constructor is strstreambuf(s, n, s). </p>
3182   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
3183   elements that contains an NTBS whose first element is designated by s. The constructor is
3184   strstreambuf(s, n, s+std::strlen(s)).</p>
3185 </blockquote>
3186
3187 <p>Notice the second condition is the same as the first. I think the second condition
3188 should be "If mode&amp;app==app", or "mode&amp;app!=0", meaning that
3189 the append bit is set.</p>
3190 <p><b>Proposed resolution:</b></p>
3191 <p>In D.7.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/future.html#depr.strstream.cons"> [depr.strstream.cons]</a>
3192 paragraph 2, change the first condition to <tt>(mode&amp;app)==0</tt>
3193 and the second condition to <tt>(mode&amp;app)!=0</tt>.</p>
3194 <hr>
3195 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Nov 1998</p>
3196 <p>The <b>effects</b> clause for numeric inserters says that
3197 insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
3198 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
3199 int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
3200 <tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
3201 delegated to <tt>num_put</tt>, and that insertion is performed as if
3202 through the following code fragment: </p>
3203
3204 <pre>bool failed = use_facet&lt;
3205    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3206    &gt;(getloc()).put(*this, *this, fill(), val). failed();</pre>
3207
3208 <p>This doesn't work, because <tt>num_put&lt;&gt;</tt>::put is only
3209 overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
3210 long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
3211 void*</tt>. That is, the code fragment in the standard is incorrect
3212 (it is diagnosed as ambiguous at compile time) for the types
3213 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
3214 int</tt>, and <tt>float</tt>. </p>
3215
3216 <p>We must either add new member functions to <tt>num_put</tt>, or
3217 else change the description in <tt>ostream</tt> so that it only calls
3218 functions that are actually there. I prefer the latter. </p>
3219 <p><b>Proposed resolution:</b></p>
3220 <p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
3221
3222 <blockquote>
3223 <p>
3224 The classes num_get&lt;&gt; and num_put&lt;&gt; handle localedependent numeric
3225 formatting and parsing.  These inserter functions use the imbued
3226 locale value to perform numeric formatting.  When val is of type bool,
3227 long, unsigned long, double, long double, or const void*, the
3228 formatting conversion occurs as if it performed the following code
3229 fragment:
3230 </p>
3231
3232 <pre>bool failed = use_facet&lt;
3233    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3234    &gt;(getloc()).put(*this, *this, fill(), val). failed();
3235 </pre>
3236
3237 <p>
3238 When val is of type short the formatting conversion occurs as if it
3239 performed the following code fragment:
3240 </p>
3241
3242 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
3243 bool failed = use_facet&lt;
3244    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3245    &gt;(getloc()).put(*this, *this, fill(),
3246       baseflags == ios_base::oct || baseflags == ios_base::hex
3247          ? static_cast&lt;long&gt;(static_cast&lt;unsigned short&gt;(val))
3248          : static_cast&lt;long&gt;(val)). failed();
3249 </pre>
3250
3251 <p>
3252 When val is of type int the formatting conversion occurs as if it performed
3253 the following code fragment:
3254 </p>
3255
3256 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
3257 bool failed = use_facet&lt;
3258    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3259    &gt;(getloc()).put(*this, *this, fill(),
3260       baseflags == ios_base::oct || baseflags == ios_base::hex
3261          ? static_cast&lt;long&gt;(static_cast&lt;unsigned int&gt;(val))
3262          : static_cast&lt;long&gt;(val)). failed();
3263 </pre>
3264
3265 <p>
3266 When val is of type unsigned short or unsigned int the formatting conversion
3267 occurs as if it performed the following code fragment:
3268 </p>
3269
3270 <pre>bool failed = use_facet&lt;
3271    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3272    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;unsigned long&gt;(val)).
3273 failed();
3274 </pre>
3275
3276 <p>
3277 When val is of type float the formatting conversion occurs as if it
3278 performed the following code fragment:
3279 </p>
3280
3281 <pre>bool failed = use_facet&lt;
3282    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3283    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;double&gt;(val)).
3284 failed();
3285 </pre>
3286
3287 </blockquote>
3288
3289 <p><i>[post-Toronto: This differs from the previous proposed
3290 resolution; PJP provided the new wording.  The differences are in
3291 signed short and int output.]</i></p>
3292 <p><b>Rationale:</b></p>
3293 <p>The original proposed resolution was to cast int and short to long,
3294 unsigned int and unsigned short to unsigned long, and float to double,
3295 thus ensuring that we don't try to use nonexistent num_put&lt;&gt;
3296 member functions.  The current proposed resolution is more
3297 complicated, but gives more expected results for hex and octal output
3298 of signed short and signed int.  (On a system with 16-bit short, for
3299 example, printing short(-1) in hex format should yield 0xffff.)</p>
3300 <hr>
3301 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Nov 1998</p>
3302 <p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
3303 <tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
3304 <tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
3305 formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
3306
3307 <pre>typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3308 iostate err = 0;
3309 use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, val);
3310 setstate(err);</pre>
3311
3312 <p>According to section 22.2.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>, however,
3313 <tt>num_get&lt;&gt;::get()</tt> is only overloaded for the types
3314 <tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
3315 int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
3316 <tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
3317 <tt>void*</tt>. Comparing the lists from the two sections, we find
3318 that 27.6.1.2.2 is using a nonexistent function for types
3319 <tt>short</tt> and <tt>int</tt>. </p>
3320 <p><b>Proposed resolution:</b></p>
3321 <p>In 27.6.1.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> Arithmetic Extractors, remove the
3322 two lines (1st and 3rd) which read:</p>
3323 <blockquote>
3324   <pre>operator&gt;&gt;(short&amp; val);
3325 ...
3326 operator&gt;&gt;(int&amp; val);</pre>
3327 </blockquote>
3328
3329 <p>And add the following at the end of that section (27.6.1.2.2) :</p>
3330
3331 <blockquote>
3332   <pre>operator&gt;&gt;(short&amp; val);</pre>
3333   <p>The conversion occurs as if performed by the following code fragment (using
3334   the same notation as for the preceding code fragment):</p>
3335   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3336   iostate err = 0;
3337   long lval;
3338   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
3339         if (err == 0
3340                 &amp;&amp; (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval))
3341                 err = ios_base::failbit;
3342   setstate(err);</pre>
3343   <pre>operator&gt;&gt;(int&amp; val);</pre>
3344   <p>The conversion occurs as if performed by the following code fragment (using
3345   the same notation as for the preceding code fragment):</p>
3346   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3347   iostate err = 0;
3348   long lval;
3349   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
3350         if (err == 0
3351                 &amp;&amp; (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval))
3352                 err = ios_base::failbit;
3353   setstate(err);</pre>
3354 </blockquote>
3355
3356 <p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
3357 <hr>
3358 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3359 <p>Section 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> states: </p>
3360
3361 <p>"An implementation may strengthen the exception-specification
3362 for a function by removing listed exceptions." </p>
3363
3364 <p>The problem is that if an implementation is allowed to do this for
3365 virtual functions, then a library user cannot write a class that
3366 portably derives from that class. </p>
3367
3368 <p>For example, this would not compile if ios_base::failure::~failure
3369 had an empty exception specification: </p>
3370
3371 <pre>#include &lt;ios&gt;
3372 #include &lt;string&gt;
3373
3374 class D : public std::ios_base::failure {
3375 public:
3376         D(const std::string&amp;);
3377         ~D(); // error - exception specification must be compatible with
3378               // overridden virtual function ios_base::failure::~failure()
3379 };</pre>
3380 <p><b>Proposed resolution:</b></p>
3381 <p>Change Section 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> from:</p>
3382
3383 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
3384 exception-specification for a function"</p>
3385
3386 <p>to:</p>
3387
3388 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
3389 exception-specification for a non-virtual function". </p>
3390 <hr>
3391 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3392
3393 <p>The original issue asked whether a library implementor could
3394 specialize standard library templates for built-in types.  (This was
3395 an issue because users are permitted to explicitly instantiate
3396 standard library templates.)</p>
3397
3398 <p>Specializations are no longer a problem, because of the resolution
3399 to core issue 259.  Under the proposed resolution, it will be legal
3400 for a translation unit to contain both a specialization and an
3401 explicit instantiation of the same template, provided that the
3402 specialization comes first.  In such a case, the explicit
3403 instantiation will be ignored.  Further discussion of library issue
3404 120 assumes that the core 259 resolution will be adopted.</p>
3405
3406 <p>However, as noted in lib-7047, one piece of this issue still
3407 remains: what happens if a standard library implementor explicitly
3408 instantiates a standard library templates?  It's illegal for a program
3409 to contain two different explicit instantiations of the same template
3410 for the same type in two different translation units (ODR violation),
3411 and the core working group doesn't believe it is practical to relax
3412 that restriction.</p>
3413
3414 <p>The issue, then, is: are users allowed to explicitly instantiate
3415 standard library templates for non-user defined types?  The status quo
3416 answer is 'yes'.  Changing it to 'no' would give library implementors
3417 more freedom.</p>
3418
3419 <p>This is an issue because, for performance reasons, library
3420 implementors often need to explicitly instantiate standard library
3421 templates.  (for example, std::basic_string&lt;char&gt;)  Does giving
3422 users freedom to explicitly instantiate standard library templates for
3423 non-user defined types make it impossible or painfully difficult for
3424 library implementors to do this?</p>
3425
3426 <p>John Spicer suggests, in lib-8957, that library implementors have a
3427 mechanism they can use for explicit instantiations that doesn't
3428 prevent users from performing their own explicit instantiations: put
3429 each explicit instantiation in its own object file.  (Different
3430 solutions might be necessary for Unix DSOs or MS-Windows DLLs.)  On
3431 some platforms, library implementors might not need to do anything
3432 special: the "undefined behavior" that results from having two
3433 different explicit instantiations might be harmless.</p>
3434
3435 <p><b>Proposed resolution:</b></p>
3436   <p>Append to 17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> paragraph 1: </p>
3437   <blockquote>
3438     A program may explicitly instantiate any templates in the standard
3439     library only if the declaration depends on the name of a user-defined
3440     type of external linkage and the instantiation meets the standard library
3441     requirements for the original template.
3442   </blockquote>
3443
3444 <p><i>[Kona: changed the wording from "a user-defined name" to "the name of
3445   a user-defined type"]</i></p>
3446
3447 <p><b>Rationale:</b></p>
3448 <p>The LWG considered another possible resolution:</p>
3449 <blockquote>
3450   <p>In light of the resolution to core issue 259, no normative changes
3451   in the library clauses are necessary.  Add the following non-normative
3452   note to the end of 17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> paragraph 1:</p>
3453   <blockquote>
3454     [<i>Note:</i> A program may explicitly instantiate standard library
3455     templates, even when an explicit instantiation does not depend on
3456     a user-defined name. <i>--end note</i>]
3457   </blockquote>
3458 </blockquote>
3459
3460 <p>The LWG rejected this because it was believed that it would make
3461   it unnecessarily difficult for library implementors to write
3462   high-quality implementations.  A program may not include an
3463   explicit instantiation of the same template, for the same template
3464   arguments, in two different translation units.  If users are
3465   allowed to provide explicit instantiations of Standard Library
3466   templates for built-in types, then library implementors aren't,
3467   at least not without nonportable tricks.</p>
3468
3469 <p>The most serious problem is a class template that has writeable
3470   static member variables.  Unfortunately, such class templates are
3471   important and, in existing Standard Library implementations, are
3472   often explicitly specialized by library implementors: locale facets,
3473   which have a writeable static member variable <tt>id</tt>.  If a
3474   user's explicit instantiation collided with the implementations
3475   explicit instantiation, iostream initialization could cause locales
3476   to be constructed in an inconsistent state.</p>
3477
3478 <p>One proposed implementation technique was for Standard Library
3479   implementors to provide explicit instantiations in separate object
3480   files, so that they would not be picked up by the linker when the
3481   user also provides an explicit instantiation.  However, this
3482   technique only applies for Standard Library implementations that
3483   are packaged as static archives.  Most Standard Library
3484   implementations nowadays are packaged as dynamic libraries, so this
3485   technique would not apply.</p>
3486
3487 <p>The Committee is now considering standardization of dynamic
3488   linking.  If there are such changes in the future, it may be
3489   appropriate to revisit this issue later.</p>
3490 <hr>
3491 <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/papers/2005/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3492 <p>Section 27.5.2 describes the streambuf classes this way: </p>
3493
3494 <blockquote>
3495
3496 <p>The class streambuf is a specialization of the template class basic_streambuf
3497 specialized for the type char. </p>
3498
3499 <p>The class wstreambuf is a specialization of the template class basic_streambuf
3500 specialized for the type wchar_t. </p>
3501
3502 </blockquote>
3503
3504 <p>This implies that these classes must be template specializations, not typedefs. </p>
3505
3506 <p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
3507 <p><b>Proposed resolution:</b></p>
3508 <p>Remove 27.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> paragraphs 2 and 3 (the above two
3509 sentences). </p>
3510 <p><b>Rationale:</b></p>
3511 <p>The <tt>streambuf</tt>  synopsis already has a declaration for the
3512 typedefs and that is sufficient. </p>
3513 <hr>
3514 <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/papers/2005/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/papers/2005/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/papers/2005/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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998 </p>
3515 <p>One of the operator= in the valarray helper arrays is const and one
3516 is not. For example, look at slice_array. This operator= in Section
3517 26.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> is const: </p>
3518
3519 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const valarray&lt;T&gt;&amp;) const;</tt> </p>
3520
3521 <p>but this one in Section 26.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> is not: </p>
3522
3523 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const T&amp;); </tt></p>
3524
3525 <p>The description of the semantics for these two functions is similar. </p>
3526 <p><b>Proposed resolution:</b></p>
3527
3528 <p>26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> Template class slice_array</p>
3529 <blockquote>
3530
3531    <p>In the class template definition for slice_array, replace the member
3532    function declaration</p>
3533     <pre>      void operator=(const T&amp;);
3534     </pre>
3535    <p>with</p>
3536     <pre>      void operator=(const T&amp;) const;
3537     </pre>
3538 </blockquote>
3539
3540 <p>26.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> slice_array fill function</p>
3541 <blockquote>
3542
3543    <p>Change the function declaration</p>
3544     <pre>      void operator=(const T&amp;);
3545     </pre>
3546    <p>to</p>
3547     <pre>      void operator=(const T&amp;) const;
3548     </pre>
3549 </blockquote>
3550
3551 <p>26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> Template class gslice_array</p>
3552 <blockquote>
3553
3554    <p>In the class template definition for gslice_array, replace the member
3555    function declaration</p>
3556     <pre>      void operator=(const T&amp;);
3557     </pre>
3558    <p>with</p>
3559     <pre>      void operator=(const T&amp;) const;
3560     </pre>
3561 </blockquote>
3562
3563 <p>26.3.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a> gslice_array fill function</p>
3564 <blockquote>
3565
3566    <p>Change the function declaration</p>
3567     <pre>      void operator=(const T&amp;);
3568     </pre>
3569    <p>to</p>
3570     <pre>      void operator=(const T&amp;) const;
3571     </pre>
3572 </blockquote>
3573
3574 <p>26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> Template class mask_array</p>
3575 <blockquote>
3576
3577    <p>In the class template definition for mask_array, replace the member
3578    function declaration</p>
3579     <pre>      void operator=(const T&amp;);
3580     </pre>
3581    <p>with</p>
3582     <pre>      void operator=(const T&amp;) const;
3583     </pre>
3584 </blockquote>
3585
3586 <p>26.3.8.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a> mask_array fill function</p>
3587 <blockquote>
3588
3589    <p>Change the function declaration</p>
3590     <pre>      void operator=(const T&amp;);
3591     </pre>
3592    <p>to</p>
3593     <pre>      void operator=(const T&amp;) const;
3594     </pre>
3595 </blockquote>
3596
3597 <p>26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a> Template class indirect_array</p>
3598 <blockquote>
3599
3600    <p>In the class template definition for indirect_array, replace the member
3601    function declaration</p>
3602     <pre>      void operator=(const T&amp;);
3603     </pre>
3604    <p>with</p>
3605     <pre>      void operator=(const T&amp;) const;
3606     </pre>
3607 </blockquote>
3608
3609 <p>26.3.9.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a> indirect_array fill function</p>
3610 <blockquote>
3611
3612    <p>Change the function declaration</p>
3613     <pre>      void operator=(const T&amp;);
3614     </pre>
3615    <p>to</p>
3616     <pre>      void operator=(const T&amp;) const;
3617     </pre>
3618 </blockquote>
3619
3620
3621 <p><i>[Redmond: Robert provided wording.]</i></p>
3622
3623 <p><b>Rationale:</b></p>
3624 <p>There's no good reason for one version of operator= being const and
3625 another one not.  Because of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#253">253</a>, this now
3626 matters: these functions are now callable in more circumstances.  In
3627 many existing implementations, both versions are already const.</p>
3628 <hr>
3629 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3630 <p>In Section 22.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>
3631 ctype_byname&lt;charT&gt;::do_scan_is() and do_scan_not() are declared
3632 to return a const char* not a const charT*. </p>
3633 <p><b>Proposed resolution:</b></p>
3634 <p>Change Section 22.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a> <tt>do_scan_is()</tt> and
3635 <tt>do_scan_not()</tt> to return a <tt> const
3636 charT*</tt>. </p>
3637 <hr>
3638 <a name="125"><h3>125.&nbsp;valarray&lt;T&gt;::operator!() return type is inconsistent</h3></a><p><b>Section:</b>&nbsp;26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3639 <p>In Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> valarray&lt;T&gt;::operator!() is
3640 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/papers/2005/lib-numerics.html#lib.valarray.unary"> [lib.valarray.unary]</a> it is declared to return a valarray&lt;bool&gt;. The
3641 latter appears to be correct. </p>
3642 <p><b>Proposed resolution:</b></p>
3643 <p>Change in Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> the declaration of
3644 <tt>operator!()</tt> so that the return type is
3645 <tt>valarray&lt;bool&gt;</tt>. </p>
3646 <hr>
3647 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3648 <p>Typos in 22.2.1.1.2 need to be fixed.</p>
3649 <p><b>Proposed resolution:</b></p>
3650 <p>In Section 22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> change: </p>
3651
3652 <pre>   do_widen(do_narrow(c),0) == c</pre>
3653
3654 <p>to:</p>
3655
3656 <pre>   do_widen(do_narrow(c,0)) == c</pre>
3657
3658 <p>and change:</p>
3659
3660 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
3661
3662 <p>to:</p>
3663
3664 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
3665 <hr>
3666 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Colvin&nbsp; <b>Date:</b>&nbsp;17 Feb 1999</p>
3667 <p>There are two problems with the current <tt>auto_ptr</tt> wording
3668 in the standard: </p>
3669
3670 <p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
3671 because <tt>auto_ptr&lt;Derived&gt;::auto_ptr_ref</tt> is unrelated to
3672 <tt>auto_ptr&lt;Base&gt;::auto_ptr_ref</tt>.  <i>Also submitted by
3673 Nathan Myers, with the same proposed resolution.</i></p>
3674
3675 <p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
3676 <tt>auto_ptr_ref</tt> argument. </p>
3677
3678 <p>I have discussed these problems with my proposal coauthor, Bill
3679 Gibbons, and with some compiler and library implementors, and we
3680 believe that these problems are not desired or desirable implications
3681 of the standard. </p>
3682
3683 <p>25 Aug 1999: The proposed resolution now reflects changes suggested
3684 by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
3685 "assignment operator" to "public assignment
3686 operator", 2) changed effects to specify use of release(), 3)
3687 made the conversion to auto_ptr_ref const. </p>
3688
3689 <p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
3690 states that the conversion from auto_ptr to auto_ptr_ref should
3691 be const.  This is not acceptable, because it would allow
3692 initialization and assignment from _any_ const auto_ptr!  It also
3693 introduces an implementation difficulty in writing this conversion
3694 function -- namely, somewhere along the line, a const_cast will be
3695 necessary to remove that const so that release() may be called.  This
3696 may result in undefined behavior [7.1.5.1/4]. The conversion
3697 operator does not have to be const, because a non-const implicit
3698 object parameter may be bound to an rvalue [13.3.3.1.4/3]
3699 [13.3.1/5]. </p>
3700
3701   <p>Tokyo: The LWG removed the following from the proposed resolution:</p>
3702
3703   <p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-utilities.html#lib.auto.ptr.conv"> [lib.auto.ptr.conv]</a>,
3704   paragraph 2, make the conversion to auto_ptr_ref const:</p>
3705   <blockquote>
3706     <pre>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() const throw();</pre>
3707   </blockquote>
3708 <p><b>Proposed resolution:</b></p>
3709 <p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, move
3710 the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
3711
3712 <p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, add
3713 a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
3714
3715 <blockquote>
3716   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</pre>
3717 </blockquote>
3718
3719 <p>Also add the assignment operator to 20.4.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.auto.ptr.conv"> [lib.auto.ptr.conv]</a>: </p>
3720
3721 <blockquote>
3722   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw()</pre>
3723
3724   <b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
3725   p</tt> that <tt>r</tt> holds a reference to.<br>
3726   <b>Returns: </b><tt>*this</tt>.
3727
3728 </blockquote>
3729 <hr>
3730 <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/papers/2005/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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;22 Feb 1999</p>
3731 <p>Currently, the standard does not specify how seekg() and seekp()
3732 indicate failure. They are not required to set failbit, and they can't
3733 return an error indication because they must return *this, i.e. the
3734 stream. Hence, it is undefined what happens if they fail. And they
3735 <i>can</i> fail, for instance, when a file stream is disconnected from the
3736 underlying file (is_open()==false) or when a wide character file
3737 stream must perform a state-dependent code conversion, etc. </p>
3738
3739 <p>The stream functions seekg() and seekp() should set failbit in the
3740 stream state in case of failure.</p>
3741 <p><b>Proposed resolution:</b></p>
3742 <p>Add to the Effects: clause of&nbsp; seekg() in
3743 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> and to the Effects: clause of seekp() in
3744 27.6.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a>: </p>
3745
3746 <blockquote>
3747   <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
3748   </p>
3749 </blockquote>
3750 <p><b>Rationale:</b></p>
3751 <p>Setting failbit is the usual error reporting mechanism for streams</p>
3752 <hr>
3753 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3754 <p>The description reads:</p>
3755
3756 <p>-1- Effects:</p>
3757
3758 <pre>         if (sz &gt; size())
3759            insert(end(), sz-size(), c);
3760          else if (sz &lt; size())
3761            erase(begin()+sz, end());
3762          else
3763            ;                           //  do nothing</pre>
3764
3765 <p>Obviously list::resize should not be specified in terms of random access iterators.</p>
3766 <p><b>Proposed resolution:</b></p>
3767 <p>Change 23.2.2.2 paragraph 1 to:</p>
3768
3769 <p>Effects:</p>
3770
3771 <pre>         if (sz &gt; size())
3772            insert(end(), sz-size(), c);
3773          else if (sz &lt; size())
3774          {
3775            iterator i = begin();
3776            advance(i, sz);
3777            erase(i, end());
3778          }</pre>
3779
3780 <p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
3781 with David Abrahams. They had a discussion and believe there is
3782 no issue of exception safety with the proposed resolution.]</i></p>
3783 <hr>
3784 <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/papers/2005/lib-containers.html#lib.map"> [lib.map]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3785 <p>The title says it all.</p>
3786 <p><b>Proposed resolution:</b></p>
3787 <p>Insert in 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
3788 after operator= in the map declaration:</p>
3789
3790 <pre>    allocator_type get_allocator() const;</pre>
3791 <hr>
3792 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3793 <p>The complexity description says: "It does at most 2N calls to the copy constructor
3794 of T and logN reallocations if they are just input iterators ...".</p>
3795
3796 <p>This appears to be overly restrictive, dictating the precise memory/performance
3797 tradeoff for the implementor.</p>
3798 <p><b>Proposed resolution:</b></p>
3799 <p>Change 23.2.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a>, paragraph 1 to:</p>
3800
3801 <p>-1- Complexity: The constructor template &lt;class
3802 InputIterator&gt; vector(InputIterator first, InputIterator last)
3803 makes only N calls to the copy constructor of T (where N is the
3804 distance between first and last) and no reallocations if iterators
3805 first and last are of forward, bidirectional, or random access
3806 categories. It makes order N calls to the copy constructor of T and
3807 order logN reallocations if they are just input iterators.
3808 </p>
3809 <p><b>Rationale:</b></p>
3810 <p>"at most 2N calls" is correct only if the growth factor
3811 is greater than or equal to 2.
3812 </p>
3813 <hr>
3814 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3815 <p>I may be misunderstanding the intent, but should not seekg set only
3816 the input stream and seekp set only the output stream? The description
3817 seems to say that each should set both input and output streams. If
3818 that's really the intent, I withdraw this proposal.</p>
3819 <p><b>Proposed resolution:</b></p>
3820 <p>In section 27.6.1.3 change:</p>
3821
3822 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
3823 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
3824
3825 <p>To:</p>
3826
3827 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
3828 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::in). </pre>
3829
3830 <p>In section 27.6.1.3 change:</p>
3831
3832 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
3833 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
3834
3835 <p>To:</p>
3836
3837 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
3838 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::in). </pre>
3839
3840 <p>In section 27.6.2.4, paragraph 2 change:</p>
3841
3842 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
3843
3844 <p>To:</p>
3845
3846 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::out). </pre>
3847
3848 <p>In section 27.6.2.4, paragraph 4 change:</p>
3849
3850 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
3851
3852 <p>To:</p>
3853
3854 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::out). </pre>
3855
3856 <p><i>[Dublin: Dietmar Kühl thinks this is probably correct, but would
3857 like the opinion of more iostream experts before taking action.]</i></p>
3858
3859 <p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
3860 incorrect, his implementation already implements the Proposed
3861 Resolution.]</i></p>
3862
3863 <p><i>[Post-Tokyo: Matt Austern comments:<br>
3864 Is it a problem with basic_istream and basic_ostream, or is it a problem
3865 with basic_stringbuf?
3866 We could resolve the issue either by changing basic_istream and
3867 basic_ostream, or by changing basic_stringbuf. I prefer the latter
3868 change (or maybe both changes): I don't see any reason for the standard to
3869 require that std::stringbuf s(std::string("foo"), std::ios_base::in);
3870 s.pubseekoff(0, std::ios_base::beg); must fail.<br>
3871 This requirement is a bit weird. There's no similar requirement
3872 for basic_streambuf&lt;&gt;::seekpos, or for basic_filebuf&lt;&gt;::seekoff or
3873 basic_filebuf&lt;&gt;::seekpos.]</i></p>
3874 <hr>
3875 <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/papers/2005/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;17 Mar 1999</p>
3876 <p>Section 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale"> [lib.locale]</a> says:</p>
3877
3878 <p>-4- In the call to use_facet&lt;Facet&gt;(loc), the type argument
3879 chooses a facet, making available all members of the named type. If
3880 Facet is not present in a locale (or, failing that, in the global
3881 locale), it throws the standard exception bad_cast. A C++ program can
3882 check if a locale implements a particular facet with the template
3883 function has_facet&lt;Facet&gt;(). </p>
3884
3885 <p>This contradicts the specification given in section
3886 22.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a>:
3887 <br><br>
3888 template &lt;class&nbsp; Facet&gt; const&nbsp; Facet&amp; use_facet(const
3889 locale&amp;&nbsp; loc); <br>
3890 <br>
3891 -1- Get a reference to a facet of a locale. <br>
3892 -2- Returns: a reference to the corresponding facet of loc, if present. <br>
3893 -3- Throws: bad_cast if has_facet&lt;Facet&gt;(loc) is false. <br>
3894 -4- Notes: The reference returned remains valid at least as long as any copy of loc exists
3895 </p>
3896 <p><b>Proposed resolution:</b></p>
3897 <p>Remove the phrase "(or, failing that, in the global locale)"
3898 from section 22.1.1. </p>
3899 <p><b>Rationale:</b></p>
3900 <p>Needed for consistency with the way locales are handled elsewhere
3901 in the standard.</p>
3902 <hr>
3903 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;30 Mar 1999</p>
3904 <p>The sentence introducing the Optional sequence operation table
3905 (23.1.1 paragraph 12) has two problems:</p>
3906
3907 <p>A. It says ``The operations in table 68 are provided only for the containers for which
3908 they take constant time.''<br>
3909 <br>
3910 That could be interpreted in two ways, one of them being ``Even though table 68 shows
3911 particular operations as being provided, implementations are free to omit them if they
3912 cannot implement them in constant time.''<br>
3913 <br>
3914 B. That paragraph says nothing about amortized constant time, and it should.&nbsp;</p>
3915 <p><b>Proposed resolution:</b></p>
3916 <p>Replace the wording in 23.1.1 paragraph 12&nbsp; which begins ``The operations in table 68 are provided only..."
3917 with:</p>
3918
3919 <blockquote>
3920   <p>Table 68 lists sequence operations that are provided for some types of sequential
3921   containers but not others. An implementation shall provide these operations for all
3922   container types shown in the ``container'' column, and shall implement them so as to take
3923   amortized constant time.</p>
3924 </blockquote>
3925 <hr>
3926 <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/papers/2005/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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Arch Robison&nbsp; <b>Date:</b>&nbsp;28 Apr 1999</p>
3927 <p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
3928 say:<br>
3929 <br>
3930 &#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();</tt></p>
3931
3932 <p>Surely the document meant to say ``<tt>xpos &lt; size()</tt>'' in both places.</p>
3933
3934 <p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
3935 proposed resolution.]</i></p>
3936 <p><b>Proposed resolution:</b></p>
3937 <p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
3938 <br>
3939 &#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();<br>
3940 <br>
3941 </tt>to:<br>
3942 <tt><br>
3943 </tt>&#8212; <tt>xpos &lt;= pos</tt> and <tt>xpos &lt; size();</tt></p>
3944 <hr>
3945 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;20 Jun 1999</p>
3946 <p>The lexicographical_compare complexity is specified as:<br>
3947 <br>
3948 &nbsp;&nbsp;&nbsp;&nbsp; "At most min((last1 - first1), (last2 - first2))
3949 applications of the corresponding comparison."<br>
3950 <br>
3951 The best I can do is twice that expensive.</p>
3952
3953 <p>Nicolai Josuttis comments in lib-6862: You mean, to check for
3954 equality you have to check both &lt; and &gt;? Yes, IMO you are
3955 right! (and Matt states this complexity in his book)</p>
3956
3957 <p><b>Proposed resolution:</b></p>
3958 <p>Change 25.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a> complexity to:</p>
3959     <blockquote>
3960     At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
3961     applications of the corresponding comparison.
3962     </blockquote>
3963
3964 <p>Change the example at the end of paragraph 3 to read:</p>
3965     <blockquote>
3966     [Example:<br>
3967     <br>
3968     &nbsp;&nbsp;&nbsp; for ( ; first1 != last1 &amp;&amp; first2 != last2 ;
3969     ++first1, ++first2) {<br>
3970     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first1 &lt; *first2) return true;<br>
3971     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first2 &lt; *first1) return false;<br>
3972     &nbsp;&nbsp;&nbsp; }<br>
3973     &nbsp;&nbsp;&nbsp; return first1 == last1 &amp;&amp; first2 != last2;<br>
3974     &nbsp;&nbsp;&nbsp;<br>
3975     --end example]
3976     </blockquote>
3977 <hr>
3978 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Herb Sutter&nbsp; <b>Date:</b>&nbsp;9 May 1999</p>
3979 <p>In 23.2.1.1 paragraph 6, the deque ctor that takes an iterator range appears
3980 to have complexity requirements which are incorrect, and which contradict the
3981 complexity requirements for insert(). I suspect that the text in question,
3982 below, was taken from vector:</p>
3983 <blockquote>
3984   <p>Complexity: If the iterators first and last are forward iterators,
3985   bidirectional iterators, or random access iterators the constructor makes only
3986   N calls to the copy constructor, and performs no reallocations, where N is
3987   last - first.</p>
3988 </blockquote>
3989 <p>The word "reallocations" does not really apply to deque. Further,
3990 all of the following appears to be spurious:</p>
3991 <blockquote>
3992   <p>It makes at most 2N calls to the copy constructor of T and log N
3993   reallocations if they are input iterators.1)</p>
3994   <p>1) The complexity is greater in the case of input iterators because each
3995   element must be added individually: it is impossible to determine the distance
3996   between first abd last before doing the copying.</p>
3997 </blockquote>
3998 <p>This makes perfect sense for vector, but not for deque. Why should deque gain
3999 an efficiency advantage from knowing in advance the number of elements to
4000 insert?</p>
4001 <p><b>Proposed resolution:</b></p>
4002 <p>In 23.2.1.1 paragraph 6, replace the Complexity description, including the
4003 footnote, with the following text (which also corrects the "abd"
4004 typo):</p>
4005 <blockquote>
4006   <p>Complexity: Makes last - first calls to the copy constructor of T.</p>
4007 </blockquote>
4008 <hr>
4009 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;12 May 1999</p>
4010 <p>The <u> extractor</u> for complex numbers is specified as:&nbsp;</p>
4011
4012 <blockquote>
4013
4014 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4015      basic_istream&lt;charT, traits&gt;&amp;&nbsp;<br>
4016      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;  is, complex&lt;T&gt;&amp;  x);<br>
4017 &nbsp;<br>
4018 Effects: Extracts a complex number x of the form: u, (u), or (u,v),
4019 where u is the real part and v is the imaginary part
4020 (lib.istream.formatted).&nbsp;<br>
4021 Requires: The input values be convertible to T. If bad input is
4022 encountered, calls is.setstate(ios::failbit) (which may throw
4023 ios::failure (lib.iostate.flags).&nbsp;<br>
4024 Returns: is .</p>
4025
4026 </blockquote>
4027 <p>Is it intended that the extractor for complex numbers does not skip
4028 whitespace, unlike all other extractors in the standard library do?
4029 Shouldn't a sentry be used?&nbsp;<br>
4030 <br>
4031 The <u>inserter</u> for complex numbers is specified as:</p>
4032
4033 <blockquote>
4034
4035 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4036      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
4037      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;  o, const complex&lt;T&gt;&amp;  x);<br>
4038 <br>
4039 Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
4040 <br>
4041      template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4042      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
4043      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; o, const complex&lt;T&gt;&amp; x)&nbsp;<br>
4044      {&nbsp;<br>
4045              basic_ostringstream&lt;charT, traits&gt; s;&nbsp;<br>
4046              s.flags(o.flags());&nbsp;<br>
4047              s.imbue(o.getloc());&nbsp;<br>
4048              s.precision(o.precision());&nbsp;<br>
4049              s &lt;&lt; '(' &lt;&lt; x.real() &lt;&lt; "," &lt;&lt; x.imag() &lt;&lt; ')';&nbsp;<br>
4050              return o &lt;&lt; s.str();&nbsp;<br>
4051      }</p>
4052
4053 </blockquote>
4054
4055 <p>Is it intended that the inserter for complex numbers ignores the
4056 field width and does not do any padding? If, with the suggested
4057 implementation above, the field width were set in the stream then the
4058 opening parentheses would be adjusted, but the rest not, because the
4059 field width is reset to zero after each insertion.</p>
4060
4061 <p>I think that both operations should use sentries, for sake of
4062 consistency with the other inserters and extractors in the
4063 library. Regarding the issue of padding in the inserter, I don't know
4064 what the intent was.&nbsp;</p>
4065 <p><b>Proposed resolution:</b></p>
4066 <p>After 26.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> paragraph 14 (operator&gt;&gt;), add a
4067 Notes clause:</p>
4068
4069 <blockquote>
4070
4071 <p>Notes: This extraction is performed as a series of simpler
4072 extractions. Therefore, the skipping of whitespace is specified to be the
4073 same for each of the simpler extractions.</p>
4074
4075 </blockquote>
4076 <p><b>Rationale:</b></p>
4077 <p>For extractors, the note is added to make it clear that skipping whitespace
4078 follows an "all-or-none" rule.</p>
4079
4080 <p>For inserters, the LWG believes there is no defect; the standard is correct
4081 as written.</p>
4082 <hr>
4083 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Lois Goldthwaite&nbsp; <b>Date:</b>&nbsp;4 Jun 1999</p>
4084 <p>The library had many global functions until 17.4.1.1 [lib.contents]
4085 paragraph 2 was added: </p>
4086
4087 <blockquote>
4088
4089 <p>All library entities except macros, operator new and operator
4090 delete are defined within the namespace std or namespaces nested
4091 within namespace std. </p>
4092
4093 </blockquote>
4094
4095 <p>It appears "global function" was never updated in the following: </p>
4096
4097 <blockquote>
4098
4099 <p>17.4.4.3 - Global functions [lib.global.functions]<br>
4100 <br>
4101 -1- It is unspecified whether any global functions in the C++ Standard
4102 Library are defined as inline (dcl.fct.spec).<br>
4103 <br>
4104 -2- A call to a global function signature described in Clauses
4105 lib.language.support through lib.input.output behaves the same as if
4106 the implementation declares no additional global function
4107 signatures.*<br>
4108 <br>
4109     [Footnote: A valid C++ program always calls the expected library
4110     global function. An implementation may also define additional
4111     global functions that would otherwise not be called by a valid C++
4112     program. --- end footnote]<br>
4113 <br>
4114 -3- A global function cannot be declared by the implementation as
4115 taking additional default arguments.&nbsp;<br>
4116 <br>
4117 17.4.4.4 - Member functions [lib.member.functions]<br>
4118 <br>
4119 -2- An implementation can declare additional non-virtual member
4120 function signatures within a class: </p>
4121
4122   <blockquote>
4123
4124 <p>-- by adding arguments with default values to a member function
4125 signature; The same latitude does not extend to the implementation of
4126 virtual or global functions, however. </p>
4127
4128   </blockquote>
4129 </blockquote>
4130 <p><b>Proposed resolution:</b></p>
4131 <p>     Change "global" to "global or non-member" in:</p>
4132 <blockquote>
4133   <p>17.4.4.3 [lib.global.functions] section title,<br>
4134   17.4.4.3 [lib.global.functions] para 1,<br>
4135   17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2
4136            places in the footnote,<br>
4137   17.4.4.3 [lib.global.functions] para 3,<br>
4138   17.4.4.4 [lib.member.functions] para 2</p>
4139 </blockquote>
4140 <p><b>Rationale:</b></p>
4141 <p>
4142 Because operator new and delete are global, the proposed resolution
4143 was changed from "non-member" to "global or non-member.
4144 </p>
4145 <hr>
4146 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jeremy Siek&nbsp; <b>Date:</b>&nbsp;3 Jun 1999</p>
4147 <p>In 22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, the do_truename() and
4148 do_falsename() functions in the example facet BoolNames should be
4149 const. The functions they are overriding in
4150 numpunct_byname&lt;char&gt; are const. </p>
4151 <p><b>Proposed resolution:</b></p>
4152 <p>In 22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, insert "const" in
4153 two places:</p>
4154 <blockquote>
4155   <p><tt>string do_truename() const { return "Oui Oui!"; }<br>
4156   string do_falsename() const { return "Mais Non!"; }</tt></p>
4157 </blockquote>
4158 <hr>
4159 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt McClure&nbsp; <b>Date:</b>&nbsp;30 Jun 1999</p>
4160 <p><b>Proposed resolution:</b></p>
4161 <p>Change 25.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> paragraph 2 from:</p>
4162
4163 <blockquote>
4164 <p>Returns: The first iterator i in the range [first1, last1) such
4165 that for some <u>integer</u> j in the range [first2, last2) ...</p>
4166 </blockquote>
4167
4168 <p>to:</p>
4169
4170 <blockquote>
4171 <p>Returns: The first iterator i in the range [first1, last1) such
4172 that for some iterator j in the range [first2, last2) ...</p>
4173 </blockquote>
4174 <hr>
4175 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Ed Brey&nbsp; <b>Date:</b>&nbsp;21 Jun 1999</p>
4176 <p>For both sequences and associative containers, a.clear() has the
4177 semantics of erase(a.begin(),a.end()), which is undefined for an empty
4178 container since erase(q1,q2) requires that q1 be dereferenceable
4179 (23.1.1,3 and 23.1.2,7).  When the container is empty, a.begin() is
4180 not dereferenceable.<br>
4181 <br>
4182 The requirement that q1 be unconditionally dereferenceable causes many
4183 operations to be intuitively undefined, of which clearing an empty
4184 container is probably the most dire.<br>
4185 <br>
4186 Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
4187 q2) is required to be a valid range, stating that q1 and q2 must be
4188 iterators or certain kinds of iterators is unnecessary.
4189 </p>
4190 <p><b>Proposed resolution:</b></p>
4191 <p>In 23.1.1, paragraph 3, change:</p>
4192 <blockquote>
4193   <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>
4194 </blockquote>
4195 <p>to:</p>
4196 <blockquote>
4197   <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range<u>
4198   in a</u></p>
4199 </blockquote>
4200 <p>In 23.1.2, paragraph 7, change:</p>
4201 <blockquote>
4202   <p>p and q2 are valid iterators to a, q <u> and q1</u> are valid dereferenceable
4203   iterators to a, [q1, q2) is a valid range</p>
4204 </blockquote>
4205 <p>to</p>
4206 <blockquote>
4207   <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
4208   <u>into a</u></p>
4209 </blockquote>
4210 <hr>
4211 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4212 <p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
4213 because there is no function <tt>is()</tt> which only takes a character as
4214 argument. Also, in the effects clause (paragraph 3), the semantic is also kept
4215 vague.</p>
4216 <p><b>Proposed resolution:</b></p>
4217 <p>In 22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> paragraphs 4 and 6, change the returns
4218 clause from:</p>
4219 <blockquote>
4220   <p>"... such that <tt>is(*p)</tt>
4221 would..."</p>
4222 </blockquote>
4223 <p>to:&nbsp; "... such that <tt>is(m, *p)</tt>
4224  would...."</p>
4225 <hr>
4226 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4227 <p>The description of the array version of <tt>narrow()</tt> (in
4228 paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
4229 takes only three arguments because in addition to the range a default
4230 character is needed.</p>
4231
4232 <p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
4233 two signatures followed by a <b>Returns</b> clause that only addresses
4234 one of them.</p>
4235
4236 <p><b>Proposed resolution:</b></p>
4237 <p>Change the returns clause in 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a>
4238 paragraph 10 from:</p>
4239 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
4240
4241 <p>to:</p>
4242 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to),
4243 respectively.</p>
4244
4245 <p>Change 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> paragraph 10 and 11 from:</p>
4246 <pre>        char        narrow(char c, char /*dfault*/) const;
4247         const char* narrow(const char* low, const char* high,
4248                            char /*dfault*/, char* to) const;</pre>
4249 <pre>        Returns: do_narrow(low, high, to).</pre>
4250 <p>to:</p>
4251 <pre>        char        narrow(char c, char dfault) const;
4252         const char* narrow(const char* low, const char* high,
4253                            char dfault, char* to) const;</pre>
4254 <pre>        Returns: do_narrow(c, dfault) or
4255                  do_narrow(low, high, dfault, to), respectively.</pre>
4256
4257 <p><i>[Kona: 1) the problem occurs in additional places, 2) a user
4258 defined version could be different.]</i></p>
4259
4260 <p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
4261 the LWG. He could find no other places the problem occurred. He
4262 asks for clarification of the Kona "a user defined
4263 version..." comment above.  Perhaps it was a circuitous way of
4264 saying "dfault" needed to be uncommented?]</i></p>
4265
4266 <p><i>[Post-Toronto: the issues list maintainer has merged in the
4267 proposed resolution from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#207">207</a>, which addresses the
4268 same paragraphs.]</i></p>
4269 <hr>
4270 <a name="154"><h3>154.&nbsp;Missing <tt>double</tt> specifier for <tt>do_get()</tt>
4271 </h3></a><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4272 <p>The table in paragraph 7 for the length modifier does not list the length
4273 modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
4274 standard asks the implementation to do undefined things when using <tt>scanf()</tt>
4275 (the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
4276 is actually a problem I found quite often in production code, too).</p>
4277 <p><b>Proposed resolution:</b></p>
4278 <p>In 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, paragraph 7, add a row in the Length
4279 Modifier table to say that for <tt>double</tt> a length modifier
4280 <tt>l</tt> is to be used.</p>
4281 <p><b>Rationale:</b></p>
4282 <p>The standard makes an embarrassing beginner's mistake.</p>
4283 <hr>
4284 <a name="155"><h3>155.&nbsp;Typo in naming the class defining the class <tt>Init</tt>
4285 </h3></a><p><b>Section:</b>&nbsp;27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4286 <p>There are conflicting statements about where the class
4287 <tt>Init</tt> is defined. According to 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2
4288 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/papers/2005/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> it is defined as <tt>ios_base::Init</tt>.</p>
4289 <p><b>Proposed resolution:</b></p>
4290 <p>Change 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2 from
4291 "<tt>basic_ios::Init"</tt> to
4292 "<tt>ios_base::Init"</tt>.</p>
4293 <p><b>Rationale:</b></p>
4294 <p>Although not strictly wrong, the standard was misleading enough to warrant
4295 the change.</p>
4296 <hr>
4297 <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/papers/2005/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/papers/2005/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>There is a small discrepancy between the declarations of
4299 <tt>imbue()</tt>: in 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> the argument is passed as
4300 <tt>locale const&amp;</tt> (correct), in 27.4.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> it
4301 is passed as <tt>locale const</tt> (wrong).</p>
4302 <p><b>Proposed resolution:</b></p>
4303 <p>In 27.4.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> change the <tt>imbue</tt> argument
4304 from "<tt>locale const" to "locale
4305 const&amp;".</tt></p>
4306 <hr>
4307 <a name="158"><h3>158.&nbsp;Underspecified semantics for <tt>setbuf()</tt>
4308 </h3></a><p><b>Section:</b>&nbsp;27.5.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4309 <p>The default behavior of <tt>setbuf()</tt> is described only for the
4310 situation that <tt>gptr() != 0 &amp;&amp; gptr() != egptr()</tt>:
4311 namely to do nothing.  What has to be done in other situations&nbsp;
4312 is not described although there is actually only one reasonable
4313 approach, namely to do nothing, too.</p>
4314
4315 <p>Since changing the buffer would almost certainly mess up most
4316 buffer management of derived classes unless these classes do it
4317 themselves, the default behavior of <tt>setbuf()</tt> should always be
4318 to do nothing.</p>
4319 <p><b>Proposed resolution:</b></p>
4320 <p>Change 27.5.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 3, Default behavior,
4321 to: "Default behavior: Does nothing. Returns this."</p>
4322 <hr>
4323 <a name="159"><h3>159.&nbsp;Strange use of <tt>underflow()</tt>
4324 </h3></a><p><b>Section:</b>&nbsp;27.5.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4325 <p>The description of the meaning of the result of
4326 <tt>showmanyc()</tt> seems to be rather strange: It uses calls to
4327 <tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
4328 this function only reads the current character but does not extract
4329 it, <tt>uflow()</tt> would extract the current character. This should
4330 be fixed to use <tt>sbumpc()</tt> instead.</p>
4331 <p><b>Proposed resolution:</b></p>
4332 <p>Change 27.5.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a> paragraph 1,
4333 <tt>showmanyc()</tt>returns clause, by replacing the word
4334 "supplied" with the words "extracted from the
4335 stream".</p>
4336 <hr>
4337 <a name="160"><h3>160.&nbsp;Typo: Use of non-existing function <tt>exception()</tt>
4338 </h3></a><p><b>Section:</b>&nbsp;27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream"> [lib.istream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4339 <p>The paragraph 4 refers to the function <tt>exception()</tt> which
4340 is not defined. Probably, the referred function is
4341 <tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>
4342 <p><b>Proposed resolution:</b></p>
4343 <p>In 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream"> [lib.istream]</a>, 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, paragraph 1,
4344 27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>,
4345 paragraph 1, change "<tt>exception()" to
4346 "exceptions()"</tt>.</p>
4347
4348 <p><i>[Note to Editor: "exceptions" with an "s"
4349 is the correct spelling.]</i></p>
4350 <hr>
4351 <a name="161"><h3>161.&nbsp;Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt>
4352 </h3></a><p><b>Section:</b>&nbsp;27.6.1.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4353 <p>The note in the second paragraph pretends that the first argument
4354 is an object of type <tt>istream_iterator</tt>. This is wrong: It is
4355 an object of type <tt>istreambuf_iterator</tt>.</p>
4356 <p><b>Proposed resolution:</b></p>
4357 <p>Change 27.6.1.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> from:</p>
4358 <blockquote>
4359   <p>The first argument provides an object of the istream_iterator class...</p>
4360 </blockquote>
4361 <p>to</p>
4362 <blockquote>
4363   <p>The first argument provides an object of the istreambuf_iterator class...</p>
4364 </blockquote>
4365 <hr>
4366 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4367 <p>In 22.2.5.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> the do_put() function is specified
4368 as taking a fill character as an argument, but the description of the
4369 function does not say whether the character is used at all and, if so,
4370 in which way. The same holds for any format control parameters that
4371 are accessible through the ios_base&amp; argument, such as the
4372 adjustment or the field width. Is strftime() supposed to use the fill
4373 character in any way? In any case, the specification of
4374 time_put.do_put() looks inconsistent to me.<br> <br> Is the
4375 signature of do_put() wrong, or is the effects clause incomplete?</p>
4376 <p><b>Proposed resolution:</b></p>
4377 <p>Add the following note after 22.2.5.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a>
4378 paragraph 2:</p>
4379 <blockquote>
4380   <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
4381   for this argument. --end Note]</p>
4382 </blockquote>
4383 <p><b>Rationale:</b></p>
4384 <p>The LWG felt that while the normative text was correct,
4385 users need some guidance on what to pass for the <tt>fill</tt>
4386 argument since the standard doesn't say how it's used.</p>
4387 <hr>
4388 <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/papers/2005/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4389 <p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
4390 functions falling into one of the groups "formatted output functions"
4391 and "unformatted output functions" calls any stream buffer function
4392 which might call a virtual function other than <tt>overflow()</tt>. Basically
4393 this is fine but this implies that <tt>sputn()</tt> (this function would call
4394 the virtual function <tt>xsputn()</tt>) is never called by any of the standard
4395 output functions. Is this really intended? At minimum it would be convenient to
4396 call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
4397 is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
4398 with the definition of <tt>flush()</tt> which calls <tt>rdbuf()-&gt;pubsync()</tt>
4399 and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
4400 under "unformatted output functions").</p>
4401 <p>In addition, I guess that the sentence starting with "They may use other
4402 public members of <tt>basic_ostream</tt> ..." probably was intended to
4403 start with "They may use other public members of <tt>basic_streamuf</tt>..."
4404 although the problem with the virtual members exists in both cases.</p>
4405 <p>I see two obvious resolutions:</p>
4406 <ol>
4407   <li>state in a footnote that this means that <tt>xsputn()</tt> will never be
4408     called by any ostream member and that this is intended.</li>
4409   <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
4410     Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
4411 </ol>
4412 <p><b>Proposed resolution:</b></p>
4413 <p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
4414 <blockquote>
4415   <p>They may use other public members of basic_ostream except that they do not
4416   invoke any virtual members of rdbuf() except overflow().</p>
4417 </blockquote>
4418 <p>to:</p>
4419 <blockquote>
4420   <p>They may use other public members of basic_ostream except that they shall
4421   not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
4422   sync().</p>
4423 </blockquote>
4424
4425 <p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
4426 PJP why the standard is written this way.]</i></p>
4427
4428 <p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
4429 LWG. He comments: The rules can be made a little bit more specific if
4430 necessary be explicitly spelling out what virtuals are allowed to be
4431 called from what functions and eg to state specifically that flush()
4432 is allowed to call sync() while other functions are not.]</i></p>
4433 <hr>
4434 <a name="167"><h3>167.&nbsp;Improper use of <tt>traits_type::length()</tt>
4435 </h3></a><p><b>Section:</b>&nbsp;27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4436 <p>Paragraph 4 states that the length is determined using
4437 <tt>traits::length(s)</tt>.  Unfortunately, this function is not
4438 defined for example if the character type is <tt>wchar_t</tt> and the
4439 type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
4440 the character type is <tt>char</tt> and the type of <tt>s</tt> is
4441 either <tt>signed char const*</tt> or <tt>unsigned char
4442 const*</tt>.</p>
4443 <p><b>Proposed resolution:</b></p>
4444 <p>Change 27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> paragraph 4 from:</p>
4445 <blockquote>
4446   <p>Effects: Behaves like an formatted inserter (as described in
4447   lib.ostream.formatted.reqmts) of out. After a sentry object is
4448   constructed it inserts characters. The number of characters starting
4449   at s to be inserted is traits::length(s). Padding is determined as
4450   described in lib.facet.num.put.virtuals. The traits::length(s)
4451   characters starting at s are widened using out.widen
4452   (lib.basic.ios.members). The widened characters and any required
4453   padding are inserted into out. Calls width(0).</p>
4454 </blockquote>
4455 <p>to:</p>
4456 <blockquote>
4457   <p>Effects: Behaves like a formatted inserter (as described in
4458   lib.ostream.formatted.reqmts) of out. After a sentry object is
4459   constructed it inserts <i>n</i> characters starting at <i>s</i>,
4460   where <i>n</i> is the number that would be computed as if by:</p>
4461   <ul>
4462   <li>traits::length(s) for the overload where the first argument is of
4463     type basic_ostream&lt;charT, traits&gt;&amp; and the second is
4464     of type const charT*, and also for the overload where the first
4465     argument is of type basic_ostream&lt;char, traits&gt;&amp; and
4466     the second is of type const char*.</li>
4467   <li>std::char_traits&lt;char&gt;::length(s)
4468     for the overload where the first argument is of type
4469     basic_ostream&lt;charT, traits&gt;&amp; and the second is of type
4470     const char*.</li>
4471   <li>traits::length(reinterpret_cast&lt;const char*&gt;(s))
4472     for the other two overloads.</li>
4473   </ul>
4474   <p>Padding is determined as described in
4475   lib.facet.num.put.virtuals. The <i>n</i> characters starting at
4476   <i>s</i> are widened using out.widen (lib.basic.ios.members).  The
4477   widened characters and any required padding are inserted into
4478   out. Calls width(0).</p>
4479 </blockquote>
4480
4481 <p><i>[Santa Cruz: Matt supplied new wording]</i></p>
4482
4483 <p><i>[Kona: changed "where <i>n</i> is" to " where <i>n</i> is the
4484   number that would be computed as if by"]</i></p>
4485
4486 <p><b>Rationale:</b></p>
4487 <p>We have five separate cases.  In two of them we can use the
4488 user-supplied traits class without any fuss.  In the other three we
4489 try to use something as close to that user-supplied class as possible.
4490 In two cases we've got a traits class that's appropriate for
4491 char and what we've got is a const signed char* or a const
4492 unsigned char*; that's close enough so we can just use a reinterpret
4493 cast, and continue to use the user-supplied traits class.  Finally,
4494 there's one case where we just have to give up: where we've got a
4495 traits class for some arbitrary charT type, and we somehow have to
4496 deal with a const char*.  There's nothing better to do but fall back
4497 to char_traits&lt;char&gt;</p>
4498 <hr>
4499 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4500 <p>The first paragraph begins with a descriptions what has to be done
4501 in <i>formatted</i> output functions. Probably this is a typo and the
4502 paragraph really want to describe unformatted output functions...</p>
4503 <p><b>Proposed resolution:</b></p>
4504 <p>In 27.6.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> paragraph 1, the first and last
4505 sentences, change the word "formatted" to
4506 "unformatted":</p>
4507 <blockquote>
4508   <p>"Each <b>unformatted </b> output function begins ..."<br>
4509   "... value specified for the <b>unformatted </b>  output
4510   function."</p>
4511 </blockquote>
4512 <hr>
4513 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4514 <p>Paragraph 8, Notes, of this section seems to mandate an extremely
4515 inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
4516 especially in view of the restriction that <tt>basic_ostream</tt>
4517 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/papers/2005/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>): For each character to be inserted, a new buffer
4518 is to be created.</p>
4519 <p>Of course, the resolution below requires some handling of
4520 simultaneous input and output since it is no longer possible to update
4521 <tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
4522 solution is to handle this in <tt>underflow()</tt>.</p>
4523 <p><b>Proposed resolution:</b></p>
4524 <p>In 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> paragraph 8, Notes, insert the words
4525 "at least" as in the following:</p>
4526 <blockquote>
4527   <p>To make a write position available, the function reallocates (or initially
4528   allocates) an array object with a sufficient number of elements to hold the
4529   current array object (if any), plus <b>at least</b> one additional write
4530   position.</p>
4531 </blockquote>
4532 <hr>
4533 <a name="170"><h3>170.&nbsp;Inconsistent definition of <tt>traits_type</tt>
4534 </h3></a><p><b>Section:</b>&nbsp;27.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4535 <p>The classes <tt>basic_stringstream</tt> (27.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>),
4536 <tt>basic_istringstream</tt> (27.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istringstream"> [lib.istringstream]</a>), and
4537 <tt>basic_ostringstream</tt> (27.7.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) are inconsistent
4538 in their definition of the type <tt>traits_type</tt>: For
4539 <tt>istringstream</tt>, this type is defined, for the other two it is
4540 not. This should be consistent.</p>
4541 <p><b>Proposed resolution:</b></p>
4542 <p><b>Proposed resolution:</b></p> <p>To the declarations of
4543 <tt>basic_ostringstream</tt> (27.7.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) and
4544 <tt>basic_stringstream</tt> (27.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>) add:</p>
4545 <blockquote>
4546 <pre>typedef traits traits_type;</pre>
4547 </blockquote>
4548 <hr>
4549 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4550 <p>Overridden virtual functions, seekpos()</p> <p>In 27.8.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> paragraph 3, it is stated that a joint input and
4551 output position is maintained by <tt>basic_filebuf</tt>. Still, the
4552 description of <tt>seekpos()</tt> seems to talk about different file
4553 positions. In particular, it is unclear (at least to me) what is
4554 supposed to happen to the output buffer (if there is one) if only the
4555 input position is changed. The standard seems to mandate that the
4556 output buffer is kept and processed as if there was no positioning of
4557 the output position (by changing the input position). Of course, this
4558 can be exactly what you want if the flag <tt>ios_base::ate</tt> is
4559 set. However, I think, the standard should say something like
4560 this:</p>
4561 <ul>
4562   <li>If <tt>(which &amp; mode) == 0</tt> neither read nor write position is
4563     changed and the call fails. Otherwise, the joint read and write position is
4564     altered to correspond to <tt>sp</tt>.</li>
4565   <li>If there is an output buffer, the output sequences is updated and any
4566     unshift sequence is written before the position is altered.</li>
4567   <li>If there is an input buffer, the input sequence is updated after the
4568     position is altered.</li>
4569 </ul>
4570 <p>Plus the appropriate error handling, that is...</p>
4571 <p><b>Proposed resolution:</b></p>
4572 <p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
4573 paragraph 14 from:</p>
4574 <blockquote>
4575   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
4576   ios_base::out);</p>
4577   <p>Alters the file position, if possible, to correspond to the position stored
4578   in sp (as described below).</p>
4579   <p>- if (which&amp;ios_base::in)!=0, set the file position to sp, then update
4580   the input sequence</p>
4581   <p>- if (which&amp;ios_base::out)!=0, then update the output sequence, write
4582   any unshift sequence, and set the file position to sp.</p>
4583 </blockquote>
4584 <p>to:</p>
4585 <blockquote>
4586   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
4587   ios_base::out);</p>
4588   <p>Alters the file position, if possible, to correspond to the position stored
4589   in sp (as described below). Altering the file position performs as follows:</p>
4590   <p>1. if (om &amp; ios_base::out)!=0, then update the output sequence and
4591   write any unshift sequence;</p>
4592   <p>2. set the file position to sp;</p>
4593   <p>3. if (om &amp; ios_base::in)!=0, then update the input sequence;</p>
4594   <p>where om is the open mode passed to the last call to open(). The operation
4595   fails if is_open() returns false.</p>
4596 </blockquote>
4597
4598 <p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
4599 <p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
4600 <hr>
4601 <a name="172"><h3>172.&nbsp;Inconsistent types for <tt>basic_istream::ignore()</tt>
4602 </h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/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>
4603 <p>In 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream"> [lib.istream]</a> the function
4604 <tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
4605 argument. However, in 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>
4606 paragraph 23 the first argument is of type <tt>int.</tt></p>
4607
4608 <p>As far as I can see this is not really a contradiction because
4609 everything is consistent if <tt>streamsize</tt> is typedef to be
4610 <tt>int</tt>. However, this is almost certainly not what was
4611 intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
4612 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#173">173</a>.</p>
4613
4614 <p>Darin Adler also
4615 submitted this issue, commenting: Either 27.6.1.1 should be modified
4616 to show a first parameter of type int, or 27.6.1.3 should be modified
4617 to show a first parameter of type streamsize and use
4618 numeric_limits&lt;streamsize&gt;::max.</p>
4619 <p><b>Proposed resolution:</b></p>
4620 <p>In 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> paragraph 23 and 24, change both uses
4621 of <tt>int</tt> in the description of <tt>ignore()</tt> to
4622 <tt>streamsize</tt>.</p>
4623 <hr>
4624 <a name="173"><h3>173.&nbsp;Inconsistent types for <tt>basic_filebuf::setbuf()</tt>
4625 </h3></a><p><b>Section:</b>&nbsp;27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/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>
4626
4627 <p>
4628 In 27.8.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> the function <tt>setbuf()</tt> gets an
4629 object of type <tt>streamsize</tt> as second argument. However, in
4630 27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> paragraph 9 the second argument is of type
4631 <tt>int</tt>.
4632 </p>
4633
4634 <p>
4635 As far as I can see this is not really a contradiction because
4636 everything is consistent if <tt>streamsize</tt> is typedef to be
4637 <tt>int</tt>. However, this is almost certainly not what was
4638 intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
4639 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#172">172</a>.
4640 </p>
4641
4642 <p><b>Proposed resolution:</b></p>
4643 <p>In 27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> paragraph 9, change all uses of
4644 <tt>int</tt> in the description of <tt>setbuf()</tt> to
4645 <tt>streamsize</tt>.</p>
4646 <hr>
4647 <a name="174"><h3>174.&nbsp;Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt>
4648 </h3></a><p><b>Section:</b>&nbsp;D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4649 <p>According to paragraph 1 of this section, <tt>streampos</tt> is the
4650 type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
4651 paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt></p>
4652 <p><b>Proposed resolution:</b></p>
4653 <p>Change D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 1 from "<tt>typedef
4654 OFF_T streampos;</tt>" to "<tt>typedef POS_T
4655 streampos;</tt>"</p>
4656 <hr>
4657 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4658 <p>According to paragraph 8 of this section, the methods
4659 <tt>basic_streambuf::pubseekpos()</tt>,
4660 <tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
4661 "may" be overloaded by a version of this function taking the
4662 type <tt>ios_base::open_mode</tt> as last argument argument instead of
4663 <tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
4664 in this section to be an alias for one of the integral types). The
4665 clause specifies, that the last argument has a default argument in
4666 three cases.  However, this generates an ambiguity with the overloaded
4667 version because now the arguments are absolutely identical if the last
4668 argument is not specified.</p>
4669 <p><b>Proposed resolution:</b></p>
4670 <p>In D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, remove the default arguments for
4671 <tt>basic_streambuf::pubseekpos()</tt>,
4672 <tt>basic_ifstream::open()</tt>, and
4673 <tt>basic_ofstream::open().</tt></p>
4674 <hr>
4675 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4676 <p>The "overload" for the function <tt>exceptions()</tt> in
4677 paragraph 8 gives the impression that there is another function of
4678 this function defined in class <tt>ios_base</tt>. However, this is not
4679 the case. Thus, it is hard to tell how the semantics (paragraph 9) can
4680 be implemented: "Call the corresponding member function specified
4681 in clause 27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>."</p>
4682 <p><b>Proposed resolution:</b></p>
4683 <p>In D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, move the declaration of the
4684 function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
4685 <hr>
4686 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;2 Jul 1998</p>
4687 <p>Currently the following will not compile on two well-known standard
4688 library implementations:</p>
4689
4690 <blockquote>
4691   <pre>#include &lt;set&gt;
4692 using namespace std;
4693
4694 void f(const set&lt;int&gt; &amp;s)
4695 {
4696   set&lt;int&gt;::iterator i;
4697   if (i==s.end()); // s.end() returns a const_iterator
4698 }</pre>
4699 </blockquote>
4700
4701 <p>
4702 The reason this doesn't compile is because operator== was implemented
4703 as a member function of the nested classes set:iterator and
4704 set::const_iterator, and there is no conversion from const_iterator to
4705 iterator. Surprisingly, (s.end() == i) does work, though, because of
4706 the conversion from iterator to const_iterator.
4707 </p>
4708
4709 <p>
4710 I don't see a requirement anywhere in the standard that this must
4711 work. Should there be one?  If so, I think the requirement would need
4712 to be added to the tables in section 24.1.1. I'm not sure about the
4713 wording.  If this requirement existed in the standard, I would think
4714 that implementors would have to make the comparison operators
4715 non-member functions.</p>
4716
4717 <p>This issues was also raised on comp.std.c++ by Darin
4718 Adler.&nbsp; The example given was:</p>
4719
4720 <blockquote>
4721   <pre>bool check_equal(std::deque&lt;int&gt;::iterator i,
4722 std::deque&lt;int&gt;::const_iterator ci)
4723 {
4724 return i == ci;
4725 }</pre>
4726 </blockquote>
4727
4728 <p>Comment from John Potter:</p>
4729 <blockquote>
4730     <p>
4731     In case nobody has noticed, accepting it will break reverse_iterator.
4732     </p>
4733
4734     <p>
4735     The fix is to make the comparison operators templated on two types.
4736     </p>
4737
4738     <pre>    template &lt;class Iterator1, class Iterator2&gt;
4739     bool operator== (reverse_iterator&lt;Iterator1&gt; const&amp; x,
4740                      reverse_iterator&lt;Iterator2&gt; const&amp; y);
4741     </pre>
4742
4743     <p>
4744     Obviously:  return x.base() == y.base();
4745     </p>
4746
4747     <p>
4748     Currently, no reverse_iterator to const_reverse_iterator compares are
4749     valid.
4750     </p>
4751
4752     <p>
4753     BTW, I think the issue is in support of bad code.  Compares should be
4754     between two iterators of the same type.  All std::algorithms require
4755     the begin and end iterators to be of the same type.
4756     </p>
4757 </blockquote>
4758 <p><b>Proposed resolution:</b></p>
4759 <p>Insert this paragraph after 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 7:</p>
4760 <blockquote>
4761   <p>In the expressions</p>
4762   <pre>    i == j
4763     i != j
4764     i &lt; j
4765     i &lt;= j
4766     i &gt;= j
4767     i &gt; j
4768     i - j
4769   </pre>
4770   <p>Where i and j denote objects of a container's iterator type,
4771   either or both may be replaced by an object of the container's
4772   const_iterator type referring to the same element with no
4773   change in semantics.</p>
4774 </blockquote>
4775
4776 <p><i>[post-Toronto: Judy supplied a proposed resolution saying that
4777 <tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
4778 iterator comparison and difference operations.]</i></p>
4779
4780 <p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
4781 explicitly listed expressions; there was concern that the previous
4782 proposed resolution was too informal.]</i></p>
4783 <p><b>Rationale:</b></p>
4784 <p>
4785 The LWG believes it is clear that the above wording applies only to
4786 the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
4787 where <tt>X</tt> is a container.  There is no requirement that
4788 <tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
4789 can be mixed.  If mixing them is considered important, that's a
4790 separate issue.  (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#280">280</a>.)
4791 </p>
4792 <hr>
4793 <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/papers/2005/lib-utilities.html#lib.pairs"> [lib.pairs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;3 Aug 1999</p>
4794 <p>The claim has surfaced in Usenet that expressions such as<br>
4795 <br>
4796 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>make_pair("abc", 3)</tt><br>
4797 <br>
4798 are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
4799 parameter to <tt> const char (&amp;)[4]</tt>, which type is uncopyable.<br>
4800 <br>
4801 I doubt anyone intended that behavior...
4802 </p>
4803 <p><b>Proposed resolution:</b></p>
4804 <p>In 20.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.utility"> [lib.utility]</a>, paragraph 1 change the following
4805 declaration of make_pair():</p>
4806 <blockquote>
4807   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(const T1&amp;, const T2&amp;);</pre>
4808 </blockquote>
4809 <p>to:</p>
4810 <blockquote>
4811   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(T1, T2);</pre>
4812 </blockquote>
4813 <p>  In 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.pairs"> [lib.pairs]</a> paragraph 7 and the line before, change:</p>
4814 <blockquote>
4815 <pre>template &lt;class T1, class T2&gt;
4816 pair&lt;T1, T2&gt; make_pair(const T1&amp; x, const T2&amp; y);</pre>
4817 </blockquote>
4818 <p>to:</p>
4819 <blockquote>
4820 <pre>template &lt;class T1, class T2&gt;
4821 pair&lt;T1, T2&gt; make_pair(T1 x, T2 y);</pre>
4822 </blockquote>
4823 <p>and add the following footnote to the effects clause:</p>
4824 <blockquote>
4825   <p> According to 12.8 [class.copy], an implementation is permitted
4826   to not perform a copy of an argument, thus avoiding unnecessary
4827   copies.</p>
4828 </blockquote>
4829 <p><b>Rationale:</b></p>
4830 <p>Two potential fixes were suggested by Matt Austern and Dietmar
4831 Kühl, respectively, 1) overloading with array arguments, and 2) use of
4832 a reference_traits class with a specialization for arrays.  Andy
4833 Koenig suggested changing to pass by value. In discussion, it appeared
4834 that this was a much smaller change to the standard that the other two
4835 suggestions, and any efficiency concerns were more than offset by the
4836 advantages of the solution. Two implementors reported that the
4837 proposed resolution passed their test suites.</p>
4838 <hr>
4839 <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/papers/2005/lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Al Stevens&nbsp; <b>Date:</b>&nbsp;15 Aug 1999</p>
4840 <p>Many references to <tt> size_t</tt> throughout the document
4841 omit the <tt> std::</tt> namespace qualification.</p> <p>For
4842 example, 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2:</p>
4843 <blockquote>
4844 <pre>&#8212; operator new(size_t)
4845 &#8212; operator new(size_t, const std::nothrow_t&amp;)
4846 &#8212; operator new[](size_t)
4847 &#8212; operator new[](size_t, const std::nothrow_t&amp;)</pre>
4848 </blockquote>
4849 <p><b>Proposed resolution:</b></p>
4850 <p>   In 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2: replace:</p>
4851 <blockquote>
4852 <p><tt>     - operator new(size_t)<br>
4853      - operator new(size_t, const std::nothrow_t&amp;)<br>
4854      - operator new[](size_t)<br>
4855      - operator new[](size_t, const std::nothrow_t&amp;)</tt></p>
4856 </blockquote>
4857 <p>    by:</p>
4858 <blockquote>
4859 <pre>- operator new(std::size_t)
4860 - operator new(std::size_t, const std::nothrow_t&amp;)
4861 - operator new[](std::size_t)
4862 - operator new[](std::size_t, const std::nothrow_t&amp;)</pre>
4863 </blockquote>
4864 <p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
4865 <blockquote>
4866   <p>The typedef members pointer, const_pointer, size_type, and difference_type
4867   are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
4868 </blockquote>
4869 <p>&nbsp;by:</p>
4870 <blockquote>
4871   <p>The typedef members pointer, const_pointer, size_type, and difference_type
4872   are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
4873   respectively.</p>
4874 </blockquote>
4875 <p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
4876 <blockquote>
4877   <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
4878   <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
4879   is unspecified when or how often this function is called. The use of hint is
4880   unspecified, but intended as an aid to locality if an implementation so
4881   desires.</p>
4882 </blockquote>
4883 <p>by:</p>
4884 <blockquote>
4885   <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
4886   <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
4887   it is unspecified when or how often this function is called. The use of hint
4888   is unspecified, but intended as an aid to locality if an implementation so
4889   desires.</p>
4890 </blockquote>
4891 <p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
4892 <blockquote>
4893   <p>In Table 37, X denotes a Traits class defining types and functions for the
4894   character container type CharT; c and d denote values of type CharT; p and q
4895   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
4896   j denote values of type size_t; e and f denote values of type X::int_type; pos
4897   denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
4898 </blockquote>
4899 <p>by:</p>
4900 <blockquote>
4901   <p>In Table 37, X denotes a Traits class defining types and functions for the
4902   character container type CharT; c and d denote values of type CharT; p and q
4903   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
4904   j denote values of type std::size_t; e and f denote values of type X::int_type;
4905   pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
4906 </blockquote>
4907 <p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
4908 X::length(p): "size_t" by "std::size_t".</p>
4909 <p>   In [lib.std.iterator.tags] 24.3.3, paragraph 2:    replace:<br>
4910 &nbsp;&nbsp;&nbsp; typedef ptrdiff_t difference_type;<br>
4911     by:<br>
4912 &nbsp;&nbsp;&nbsp; typedef std::ptrdiff_t difference_type;</p>
4913 <p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the
4914 declaration of template &lt;class charT&gt; class ctype.<br>
4915 <br>
4916    In [lib.iterator.traits] 24.3.1, paragraph 2    put namespace std { ...} around the declaration of:<br>
4917 <br>
4918 &nbsp;&nbsp;&nbsp; template&lt;class Iterator&gt; struct iterator_traits<br>
4919 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;T*&gt;<br>
4920 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;const T*&gt;</p>
4921 <p><b>Rationale:</b></p>
4922 <p>The LWG believes correcting names like <tt>size_t</tt> and
4923 <tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
4924 to be essentially editorial.  There there can't be another size_t or
4925 ptrdiff_t meant anyway because, according to 17.4.3.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.extern.types"> [lib.extern.types]</a>,</p>
4926
4927 <blockquote>
4928 For each type T from the Standard C library, the types ::T and std::T
4929 are reserved to the implementation and, when defined, ::T shall be
4930 identical to std::T.
4931 </blockquote>
4932
4933 <p>The issue is treated as a Defect Report to make explicit the Project
4934 Editor's authority to make this change.</p>
4935
4936 <p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
4937 request of the LWG.]</i></p>
4938
4939 <p><i>[Toronto: This is tangentially related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#229">229</a>, but only tangentially: the intent of this issue is to
4940 address use of the name <tt>size_t</tt> in contexts outside of
4941 namespace std, such as in the description of <tt>::operator new</tt>.
4942 The proposed changes should be reviewed to make sure they are
4943 correct.]</i></p>
4944
4945 <p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
4946 them to be correct.]</i></p>
4947
4948 <hr>
4949 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;7 Jul 1999</p>
4950 <p>27.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> paragraph 3 says (clause numbering added for
4951 exposition):</p>
4952 <blockquote>
4953 <p>Returns: An object s of unspecified type such that if [1] out is an (instance
4954 of) basic_ostream then the expression out&lt;&lt;s behaves as if f(s) were
4955 called, and if [2] in is an (instance of) basic_istream then the expression
4956 in&gt;&gt;s behaves as if f(s) were called. Where f can be defined as: ios_base&amp;
4957 f(ios_base&amp; str, ios_base::fmtflags mask) { // reset specified flags
4958 str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
4959 out&lt;&lt;s has type ostream&amp; and value out. [4] The expression in&gt;&gt;s
4960 has type istream&amp; and value in.</p>
4961 </blockquote>
4962 <p>Given the definitions [1] and [2] for out and in, surely [3] should read:
4963 "The expression out &lt;&lt; s has type basic_ostream&amp; ..." and
4964 [4] should read: "The expression in &gt;&gt; s has type basic_istream&amp;
4965 ..."</p>
4966 <p>If the wording in the standard is correct, I can see no way of implementing
4967 any of the manipulators so that they will work with wide character streams.</p>
4968 <p>e.g. wcout &lt;&lt; setbase( 16 );</p>
4969 <p>Must have value 'wcout' (which makes sense) and type 'ostream&amp;' (which
4970 doesn't).</p>
4971 <p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
4972 8. In addition, Para 6 [setfill] has a similar error, but relates only to
4973 ostreams.</p>
4974 <p>I'd be happier if there was a better way of saying this, to make it clear
4975 that the value of the expression is "the same specialization of
4976 basic_ostream as out"&amp;</p>
4977 <p><b>Proposed resolution:</b></p>
4978 <p>Replace section 27.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> except paragraph 1 with the
4979 following:</p>
4980 <blockquote>
4981 <p>2- The type designated smanip in each of the following function
4982 descriptions is implementation-specified and may be different for each
4983 function.<br>
4984 <br>
4985 <tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
4986 <br>
4987 -3- Returns: An object s of unspecified type such that if out is an
4988 instance of basic_ostream&lt;charT,traits&gt; then the expression
4989 out&lt;&lt;s behaves
4990 as if f(s, mask) were called, or if in is an instance of
4991 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
4992 behaves as if
4993 f(s, mask) were called. The function f can be defined as:*<br>
4994 <br>
4995 [Footnote: The expression cin &gt;&gt; resetiosflags(ios_base::skipws)
4996 clears ios_base::skipws in the format flags stored in the
4997 basic_istream&lt;charT,traits&gt; object cin (the same as cin &gt;&gt;
4998 noskipws), and the expression cout &lt;&lt;
4999 resetiosflags(ios_base::showbase) clears
5000 ios_base::showbase in the format flags stored in the
5001 basic_ostream&lt;charT,traits&gt; object cout (the same as cout
5002 &lt;&lt;
5003 noshowbase). --- end footnote]<br>
5004 <br>
5005 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
5006 &nbsp;&nbsp; {<br>
5007 &nbsp;&nbsp; //  reset specified flags<br>
5008 &nbsp;&nbsp; str.setf(ios_base::fmtflags(0), mask);<br>
5009 &nbsp;&nbsp; return str;<br>
5010 &nbsp;&nbsp; }<br>
5011 </tt><br>
5012 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5013 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5014 <br>
5015 &nbsp;<tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
5016 <br>
5017 -4- Returns: An object s of unspecified type such that if out is an
5018 instance of basic_ostream&lt;charT,traits&gt; then the expression
5019 out&lt;&lt;s behaves
5020 as if f(s, mask) were called, or if in is an instance of
5021 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5022 behaves as if f(s,
5023 mask) were called. The function f can be defined as:<br>
5024 <br>
5025 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
5026 &nbsp;&nbsp; {<br>
5027 &nbsp;&nbsp; //  set specified flags<br>
5028 &nbsp;&nbsp; str.setf(mask);<br>
5029 &nbsp;&nbsp; return str;<br>
5030 &nbsp;&nbsp; }<br>
5031 </tt><br>
5032 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5033 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5034 <br>
5035 <tt>smanip setbase(int base);</tt><br>
5036 <br>
5037 -5- Returns: An object s of unspecified type such that if out is an
5038 instance of basic_ostream&lt;charT,traits&gt; then the expression
5039 out&lt;&lt;s behaves
5040 as if f(s, base) were called, or if in is an instance of
5041 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5042 behaves as if f(s,
5043 base) were called. The function f can be defined as:<br>
5044 <br>
5045 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int base)<br>
5046 &nbsp;&nbsp; {<br>
5047 &nbsp;&nbsp; //  set  basefield<br>
5048 &nbsp;&nbsp; str.setf(base ==  8 ? ios_base::oct :<br>
5049 &nbsp;&nbsp; base == 10 ? ios_base::dec :<br>
5050 &nbsp;&nbsp; base == 16 ? ios_base::hex :<br>
5051 &nbsp;&nbsp; ios_base::fmtflags(0), ios_base::basefield);<br>
5052 &nbsp;&nbsp; return str;<br>
5053 &nbsp;&nbsp; }<br>
5054 </tt><br>
5055 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5056 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5057 <br>
5058 <tt>smanip setfill(char_type c);<br>
5059 </tt><br>
5060 -6- Returns: An object s of unspecified type such that if out is (or is
5061 derived from) basic_ostream&lt;charT,traits&gt; and c has type charT
5062 then the
5063 expression out&lt;&lt;s behaves as if f(s, c) were called. The function
5064 f can be
5065 defined as:<br>
5066 <br>
5067 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>template&lt;class charT, class traits&gt;<br>
5068 &nbsp;&nbsp; basic_ios&lt;charT,traits&gt;&amp; f(basic_ios&lt;charT,traits&gt;&amp; str, charT c)<br>
5069 &nbsp;&nbsp; {<br>
5070 &nbsp;&nbsp; //  set fill character<br>
5071 &nbsp;&nbsp; str.fill(c);<br>
5072 &nbsp;&nbsp; return str;<br>
5073 &nbsp;&nbsp; }<br>
5074 </tt><br>
5075 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.<br>
5076 <br>
5077 <tt>smanip setprecision(int n);</tt><br>
5078 <br>
5079 -7- Returns: An object s of unspecified type such that if out is an
5080 instance of basic_ostream&lt;charT,traits&gt; then the expression
5081 out&lt;&lt;s behaves
5082 as if f(s, n) were called, or if in is an instance of
5083 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5084 behaves as if f(s, n)
5085 were called. The function f can be defined as:<br>
5086 <br>
5087 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
5088 &nbsp;&nbsp; {<br>
5089 &nbsp;&nbsp; //  set precision<br>
5090 &nbsp;&nbsp; str.precision(n);<br>
5091 &nbsp;&nbsp; return str;<br>
5092 &nbsp;&nbsp; }<br>
5093 </tt><br>
5094 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5095 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in<br>
5096 .<br>
5097 <tt>smanip setw(int n);<br>
5098 </tt><br>
5099 -8- Returns: An object s of unspecified type such that if out is an
5100 instance of basic_ostream&lt;charT,traits&gt; then the expression
5101 out&lt;&lt;s behaves
5102 as if f(s, n) were called, or if in is an instance of
5103 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5104 behaves as if f(s, n)
5105 were called. The function f can be defined as:<br>
5106 <br>
5107 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
5108 &nbsp;&nbsp; {<br>
5109 &nbsp;&nbsp; //  set width<br>
5110 &nbsp;&nbsp; str.width(n);<br>
5111 &nbsp;&nbsp; return str;<br>
5112 &nbsp;&nbsp; }<br>
5113 </tt><br>
5114 The expression out&lt;&lt;s has type
5115 basic_ostream&lt;charT,traits&gt;&amp; and value out.  The expression
5116 in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value
5117 in.
5118 </p>
5119 </blockquote>
5120
5121 <p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
5122 the proposed resolution.]</i></p>
5123
5124 <p><i>[Tokyo - The LWG noted that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#216">216</a> involves
5125 the same paragraphs.]</i></p>
5126
5127 <p><i>[Post-Tokyo: The issues list maintainer combined the proposed
5128 resolution of this issue with the proposed resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#216">216</a> as they both involved the same paragraphs, and were so
5129 intertwined that dealing with them separately appear fraught with
5130 error.  The full text was supplied by Bill Plauger; it was cross
5131 checked against changes supplied by Andy Sawyer. It should be further
5132 checked by the LWG.]</i></p>
5133 <hr>
5134 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Gabriel Dos Reis&nbsp; <b>Date:</b>&nbsp;21 Jul 1999</p>
5135 <p>bools are defined by the standard to be of integer types, as per
5136 3.9.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/basic.html#basic.fundamental"> [basic.fundamental]</a> paragraph 7.  However "integer types"
5137 seems to have a special meaning for the author of 18.2. The net effect
5138 is an unclear and confusing specification for
5139 numeric_limits&lt;bool&gt; as evidenced below.</p>
5140
5141 <p>18.2.1.2/7 says numeric_limits&lt;&gt;::digits is, for built-in integer
5142 types, the number of non-sign bits in the representation.</p>
5143
5144 <p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
5145 arithmetical value converts to true.</p>
5146
5147 <p>I don't think it makes sense at all to require
5148 numeric_limits&lt;bool&gt;::digits and numeric_limits&lt;bool&gt;::digits10 to
5149 be meaningful.</p>
5150
5151 <p>The standard defines what constitutes a signed (resp. unsigned) integer
5152 types. It doesn't categorize bool as being signed or unsigned. And the set of
5153 values of bool type has only two elements.</p>
5154
5155 <p>I don't think it makes sense to require numeric_limits&lt;bool&gt;::is_signed
5156 to be meaningful.</p>
5157
5158 <p>18.2.1.2/18 for numeric_limits&lt;integer_type&gt;::radix&nbsp; says:</p>
5159 <blockquote>
5160   <p>For integer types, specifies the base of the representation.186)</p>
5161 </blockquote>
5162
5163 <p>This disposition is at best misleading and confusing for the standard
5164 requires a "pure binary numeration system" for integer types as per
5165 3.9.1/7</p>
5166
5167 <p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
5168 BCD)."&nbsp; This also erroneous as the standard never defines any integer
5169 types with base representation other than 2.</p>
5170
5171 <p>Furthermore, numeric_limits&lt;bool&gt;::is_modulo and
5172 numeric_limits&lt;bool&gt;::is_signed have similar problems.</p>
5173 <p><b>Proposed resolution:</b></p>
5174 <p>Append to the end of 18.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.numeric.special"> [lib.numeric.special]</a>:</p>
5175 <blockquote>
5176   <p>The specialization for bool shall be provided as follows:</p>
5177   <pre>    namespace std {
5178        template&lt;&gt; class numeric_limits&lt;bool&gt; {
5179        public:
5180          static const bool is_specialized = true;
5181          static bool min() throw() { return false; }
5182          static bool max() throw() { return true; }
5183
5184          static const int  digits = 1;
5185          static const int  digits10 = 0;
5186          static const bool is_signed = false;
5187          static const bool is_integer = true;
5188          static const bool is_exact = true;
5189          static const int  radix = 2;
5190          static bool epsilon() throw() { return 0; }
5191          static bool round_error() throw() { return 0; }
5192
5193          static const int  min_exponent = 0;
5194          static const int  min_exponent10 = 0;
5195          static const int  max_exponent = 0;
5196          static const int  max_exponent10 = 0;
5197
5198          static const bool has_infinity = false;
5199          static const bool has_quiet_NaN = false;
5200          static const bool has_signaling_NaN = false;
5201          static const float_denorm_style has_denorm = denorm_absent;
5202          static const bool has_denorm_loss = false;
5203          static bool infinity() throw() { return 0; }
5204          static bool quiet_NaN() throw() { return 0; }
5205          static bool signaling_NaN() throw() { return 0; }
5206          static bool denorm_min() throw() { return 0; }
5207
5208          static const bool is_iec559 = false;
5209          static const bool is_bounded = true;
5210          static const bool is_modulo = false;
5211
5212          static const bool traps = false;
5213          static const bool tinyness_before = false;
5214          static const float_round_style round_style = round_toward_zero;
5215        };
5216      }</pre>
5217 </blockquote>
5218
5219 <p><i>[Tokyo:&nbsp; The LWG desires wording that specifies exact values
5220 rather than more general wording in the original proposed
5221 resolution.]</i></p>
5222
5223 <p><i>[Post-Tokyo:&nbsp; At the request of the LWG in Tokyo, Nico
5224 Josuttis provided the above wording.]</i></p>
5225 <hr>
5226 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;UK Panel&nbsp; <b>Date:</b>&nbsp;26 Jul 1999</p>
5227 <p>Paragraph 4 of 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> says:</p>
5228 <blockquote>
5229   <p>&nbsp;[Example: To negate every element of a: transform(a.begin(), a.end(),
5230   a.begin(), negate&lt;double&gt;()); The corresponding functions will inline
5231   the addition and the negation. end example]</p>
5232 </blockquote>
5233 <p>(Note: The "addition" referred to in the above is in para 3) we can
5234 find no other wording, except this (non-normative) example which suggests that
5235 any "inlining" will take place in this case.</p>
5236 <p>Indeed both:</p>
5237 <blockquote>
5238   <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
5239   unspecified whether any global functions in the C++ Standard Library
5240   are defined as inline (7.1.2).</p>
5241 </blockquote>
5242 <p>and</p>
5243 <blockquote>
5244   <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
5245   unspecified whether any member functions in the C++ Standard Library
5246   are defined as inline (7.1.2).</p>
5247 </blockquote>
5248 <p>take care to state that this may indeed NOT be the case.</p>
5249 <p>Thus the example "mandates" behavior that is explicitly
5250 not required elsewhere.</p>
5251 <p><b>Proposed resolution:</b></p>
5252 <p>In 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 1, remove the sentence:</p>
5253 <blockquote>
5254 <p>They are important for the effective use of the library.</p>
5255 </blockquote>
5256 <p>Remove 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 2, which reads:</p>
5257 <blockquote>
5258   <p> Using function objects together with function templates
5259   increases the expressive power of the library as well as making the
5260   resulting code much more efficient.</p>
5261 </blockquote>
5262 <p>In 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 4, remove the sentence:</p>
5263 <blockquote>
5264   <p>The corresponding functions will inline the addition and the
5265   negation.</p>
5266 </blockquote>
5267
5268 <p><i>[Kona: The LWG agreed there was a defect.]</i></p>
5269 <p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
5270 <hr>
5271 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Darin Adler&nbsp; <b>Date:</b>&nbsp;13 Aug 1999</p>
5272 <p>In section 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>, paragraph 13 defines the
5273 bitset::set operation to take a second parameter of type int. The
5274 function tests whether this value is non-zero to determine whether to
5275 set the bit to true or false. The type of this second parameter should
5276 be bool. For one thing, the intent is to specify a Boolean value. For
5277 another, the result type from test() is bool. In addition, it's
5278 possible to slice an integer that's larger than an int. This can't
5279 happen with bool, since conversion to bool has the semantic of
5280 translating 0 to false and any non-zero value to true.</p>
5281 <p><b>Proposed resolution:</b></p>
5282 <p>In 23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> Para 1 Replace:</p>
5283 <blockquote>
5284 <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = true ); </pre>
5285 </blockquote>
5286 <p>With:</p>
5287 <blockquote>
5288   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
5289 </blockquote>
5290 <p>In 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> Para 12(.5) Replace:</p>
5291 <blockquote>
5292   <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = 1 );</pre>
5293 </blockquote>
5294 <p>With:</p>
5295 <blockquote>
5296   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
5297 </blockquote>
5298
5299 <p><i>[Kona: The LWG agrees with the description.&nbsp; Andy Sawyer will work
5300 on better P/R wording.]</i></p>
5301 <p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
5302 <p><b>Rationale:</b></p>
5303 <p><tt>bool</tt> is a better choice.  It is believed that binary
5304 compatibility is not an issue, because this member function is
5305 usually implemented as <tt>inline</tt>, and because it is already
5306 the case that users cannot rely on the type of a pointer to a
5307 nonvirtual member of a standard library class.</p>
5308 <hr>
5309 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;14 Aug 1999</p>
5310 <p>The description of iter_swap in 25.2.2 paragraph 7,says that it
5311 ``exchanges the values'' of the objects to which two iterators
5312 refer.<br> <br> What it doesn't say is whether it does so using swap
5313 or using the assignment operator and copy constructor.<br> <br> This
5314 question is an important one to answer, because swap is specialized to
5315 work efficiently for standard containers.<br> For example:</p>
5316 <blockquote>
5317 <pre>vector&lt;int&gt; v1, v2;
5318 iter_swap(&amp;v1, &amp;v2);</pre>
5319 </blockquote>
5320 <p>Is this call to iter_swap equivalent to calling swap(v1, v2)?&nbsp;
5321 Or is it equivalent to</p>
5322 <blockquote>
5323 <pre>{
5324 vector&lt;int&gt; temp = v1;
5325 v1 = v2;
5326 v2 = temp;
5327 }</pre>
5328 </blockquote>
5329 <p>The first alternative is O(1); the second is O(n).</p>
5330 <p>A LWG member, Dave Abrahams, comments:</p>
5331 <blockquote>
5332 <p>Not an objection necessarily, but I want to point out the cost of
5333 that requirement:</p>
5334   <blockquote>
5335 <p><tt>iter_swap(list&lt;T&gt;::iterator, list&lt;T&gt;::iterator)</tt></p>
5336   </blockquote>
5337 <p>can currently be specialized to be more efficient than
5338 iter_swap(T*,T*) for many T (by using splicing). Your proposal would
5339 make that optimization illegal.&nbsp;</p>
5340 </blockquote>
5341
5342 <p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
5343 which are no longer permitted.]</i></p>
5344 <p><b>Proposed resolution:</b></p>
5345 <p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
5346 <blockquote>
5347 <p>Exchanges the values pointed to by the two iterators a and b.</p>
5348 </blockquote>
5349 <p>to</p>
5350 <blockquote>
5351 <p><tt>swap(*a, *b)</tt>.</p>
5352 </blockquote>
5353
5354 <p><b>Rationale:</b></p>
5355 <p>It's useful to say just what <tt>iter_swap</tt> does.  There may be
5356   some iterators for which we want to specialize <tt>iter_swap</tt>,
5357   but the fully general version should have a general specification.</p>
5358
5359 <p>Note that in the specific case of <tt>list&lt;T&gt;::iterator</tt>,
5360 iter_swap should not be specialized as suggested above.  That would do
5361 much more than exchanging the two iterators' values: it would change
5362 predecessor/successor relationships, possibly moving the iterator from
5363 one list to another.  That would surely be inappropriate.</p>
5364 <hr>
5365 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;25 Aug 1999</p>
5366 <p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
5367 and includes a parenthetical note saying that it is the number of
5368 digits after the decimal point.<br>
5369 <br>
5370 This claim is not strictly correct.  For example, in the default
5371 floating-point output format, setprecision sets the number of
5372 significant digits printed, not the number of digits after the decimal
5373 point.<br>
5374 <br>
5375 I would like the committee to look at the definition carefully and
5376 correct the statement in 27.4.2.2</p>
5377 <p><b>Proposed resolution:</b></p>
5378 <p>Remove from 27.4.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a>, paragraph 9, the text
5379 "(number of digits after the decimal point)".</p>
5380 <hr>
5381 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;24 Sep 1999</p>
5382 <p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
5383 is<br>
5384 <br>
5385 &nbsp;&nbsp;&nbsp; `"(1) *a is the largest element"<br>
5386 <br>
5387 I think this is incorrect and should be changed to the wording in the proposed
5388 resolution.</p>
5389 <p>Actually there are two independent changes:</p>
5390 <blockquote>
5391   <p>A-"part of largest equivalence class" instead of "largest", cause 25.3
5392   [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
5393   <p>B-Take
5394 'an oldest' from that equivalence class, otherwise the heap functions
5395 could not be used for a priority queue as explained in 23.2.3.2.2
5396 [lib.priqueue.members] (where I assume that a "priority queue" respects
5397 priority AND time).</p>
5398 </blockquote>
5399 <p><b>Proposed resolution:</b></p>
5400 <p>Change 25.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a> property (1) from:</p>
5401 <blockquote>
5402   <p>(1) *a is the largest element</p>
5403 </blockquote>
5404 <p>to:</p>
5405 <blockquote>
5406   <p>(1) There is no element greater than <tt>*a</tt></p>
5407 </blockquote>
5408 <hr>
5409 <a name="195"></a><h3><a name="195">195.&nbsp;Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</a></h3><p><b>Section:</b>&nbsp;27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;13 Oct 1999</p>
5410 <p>Suppose that <tt>is.flags() &amp; ios_base::skipws</tt> is nonzero.
5411 What should <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor do if it
5412 reaches eof while skipping whitespace?  27.6.1.1.2/5 suggests it
5413 should set failbit. Should it set eofbit as well?  The standard
5414 doesn't seem to answer that question.</p>
5415
5416 <p>On the one hand, nothing in 27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> says that
5417 <tt>basic_istream&lt;&gt;::sentry</tt> should ever set eofbit.  On the
5418 other hand, 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream"> [lib.istream]</a> paragraph 4 says that if
5419 extraction from a <tt>streambuf</tt> "returns
5420 <tt>traits::eof()</tt>, then the input function, except as explicitly
5421 noted otherwise, completes its actions and does
5422 <tt>setstate(eofbit)"</tt>.  So the question comes down to
5423 whether <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor is an
5424 input function.</p>
5425
5426 <p>Comments from Jerry Schwarz:</p>
5427 <blockquote>
5428 <p>It was always my intention that eofbit should be set any time that a
5429 virtual returned something to indicate eof, no matter what reason
5430 iostream code had for calling the virtual.</p>
5431 <p>
5432 The motivation for this is that I did not want to require streambufs
5433 to behave consistently if their virtuals are called after they have
5434 signaled eof.</p>
5435 <p>
5436 The classic case is a streambuf reading from a UNIX file.  EOF isn't
5437 really a state for UNIX file descriptors.  The convention is that a
5438 read on UNIX returns 0 bytes to indicate "EOF", but the file
5439 descriptor isn't shut down in any way and future reads do not
5440 necessarily also return 0 bytes.  In particular, you can read from
5441 tty's on UNIX even after they have signaled "EOF".  (It
5442 isn't always understood that a ^D on UNIX is not an EOF indicator, but
5443 an EOL indicator.  By typing a "line" consisting solely of
5444 ^D you cause a read to return 0 bytes, and by convention this is
5445 interpreted as end of file.)</p>
5446 </blockquote>
5447 <p><b>Proposed resolution:</b></p>
5448 <p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
5449 <blockquote>
5450 <p>If <tt>is.rdbuf()-&gt;sbumpc()</tt> or <tt>is.rdbuf()-&gt;sgetc()</tt>
5451 returns <tt>traits::eof()</tt>, the function calls
5452 <tt>setstate(failbit | eofbit)</tt> (which may throw
5453 <tt>ios_base::failure</tt>).
5454 </p>
5455 </blockquote>
5456 <hr>
5457 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;3 Nov 1999</p>
5458 <p>
5459 Is a pointer or reference obtained from an iterator still valid after
5460 destruction of the iterator?
5461 </p>
5462 <p>
5463 Is a pointer or reference obtained from an iterator still valid after the value
5464 of the iterator changes?
5465 </p>
5466 <blockquote>
5467 <pre>#include &lt;iostream&gt;
5468 #include &lt;vector&gt;
5469 #include &lt;iterator&gt;
5470
5471 int main()
5472 {
5473     typedef std::vector&lt;int&gt; vec_t;
5474     vec_t v;
5475     v.push_back( 1 );
5476
5477     // Is a pointer or reference obtained from an iterator still
5478     // valid after destruction of the iterator?
5479     int * p = &amp;*v.begin();
5480     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
5481
5482     // Is a pointer or reference obtained from an iterator still
5483     // valid after the value of the iterator changes?
5484     vec_t::iterator iter( v.begin() );
5485     p = &amp;*iter++;
5486     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
5487
5488     return 0;
5489 }
5490 </pre>
5491 </blockquote>
5492
5493 <p>The standard doesn't appear to directly address these
5494 questions. The standard needs to be clarified. At least two real-world
5495 cases have been reported where library implementors wasted
5496 considerable effort because of the lack of clarity in the
5497 standard. The question is important because requiring pointers and
5498 references to remain valid has the effect for practical purposes of
5499 prohibiting iterators from pointing to cached rather than actual
5500 elements of containers.</p>
5501
5502 <p>The standard itself assumes that pointers and references obtained
5503 from an iterator are still valid after iterator destruction or
5504 change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a>, which returns a reference, defines
5505 effects:</p>
5506
5507 <blockquote>
5508   <pre>Iterator tmp = current;
5509 return *--tmp;</pre>
5510 </blockquote>
5511 <p>The definition of reverse_iterator::operator-&gt;(), 24.4.1.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.reverse.iter.opref"> [lib.reverse.iter.opref]</a>, which returns a pointer, defines effects:</p>
5512 <blockquote>
5513   <pre>return &amp;(operator*());</pre>
5514 </blockquote>
5515
5516 <p>Because the standard itself assumes pointers and references remain
5517 valid after iterator destruction or change, the standard should say so
5518 explicitly. This will also reduce the chance of user code breaking
5519 unexpectedly when porting to a different standard library
5520 implementation.</p>
5521 <p><b>Proposed resolution:</b></p>
5522 <p>Add a new paragraph to 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>:</p>
5523 <blockquote>
5524 Destruction of an iterator may invalidate pointers and references
5525 previously obtained from that iterator.
5526 </blockquote>
5527
5528 <p>Replace paragraph 1 of 24.4.1.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a> with:</p>
5529
5530 <blockquote>
5531 <p><b>Effects:</b></p>
5532 <pre>  this-&gt;tmp = current;
5533   --this-&gt;tmp;
5534   return *this-&gt;tmp;
5535 </pre>
5536
5537 <p>
5538 [<i>Note:</i> This operation must use an auxiliary member variable,
5539 rather than a temporary variable, to avoid returning a reference that
5540 persists beyond the lifetime of its associated iterator.  (See
5541 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>.)  The name of this member variable is shown for
5542 exposition only.  <i>--end note</i>]
5543 </p>
5544 </blockquote>
5545
5546 <p><i>[Post-Tokyo: The issue has been reformulated purely
5547 in terms of iterators.]</i></p>
5548
5549 <p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
5550 assumption by reverse_iterator. The issue and proposed resolution was
5551 reformulated yet again to reflect this reality.]</i></p>
5552
5553 <p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
5554 assumes its underlying iterator has persistent pointers and
5555 references.  Andy Koenig pointed out that it is possible to rewrite
5556 reverse_iterator so that it no longer makes such an assupmption.
5557 However, this issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#299">299</a>.  If we
5558 decide it is intentional that <tt>p[n]</tt> may return by value
5559 instead of reference when <tt>p</tt> is a Random Access Iterator,
5560 other changes in reverse_iterator will be necessary.]</i></p>
5561 <p><b>Rationale:</b></p>
5562 <p>This issue has been discussed extensively.  Note that it is
5563 <i>not</i> an issue about the behavior of predefined iterators.  It is
5564 asking whether or not user-defined iterators are permitted to have
5565 transient pointers and references.  Several people presented examples
5566 of useful user-defined iterators that have such a property; examples
5567 include a B-tree iterator, and an "iota iterator" that doesn't point
5568 to memory.  Library implementors already seem to be able to cope with
5569 such iterators: they take pains to avoid forming references to memory
5570 that gets iterated past.  The only place where this is a problem is
5571 <tt>reverse_iterator</tt>, so this issue changes
5572 <tt>reverse_iterator</tt> to make it work.</p>
5573
5574 <p>This resolution does not weaken any guarantees provided by
5575 predefined iterators like <tt>list&lt;int&gt;::iterator</tt>.
5576 Clause 23 should be reviewed to make sure that guarantees for
5577 predefined iterators are as strong as users expect.</p>
5578
5579 <hr>
5580 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Nov 1999</p>
5581 <p>
5582 Suppose that <tt>A</tt> is a class that conforms to the
5583 Allocator requirements of Table 32, and <tt>a</tt> is an
5584 object of class <tt>A</tt>  What should be the return
5585 value of <tt>a.allocate(0)</tt>?  Three reasonable
5586 possibilities: forbid the argument <tt>0</tt>, return
5587 a null pointer, or require that the return value be a
5588 unique non-null pointer.
5589 </p>
5590 <p><b>Proposed resolution:</b></p>
5591 <p>
5592 Add a note to the <tt>allocate</tt> row of Table 32:
5593 "[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
5594 <p><b>Rationale:</b></p>
5595 <p>A key to understanding this issue is that the ultimate use of
5596 allocate() is to construct an iterator, and that iterator for zero
5597 length sequences must be the container's past-the-end
5598 representation.  Since this already implies special case code, it
5599 would be over-specification to mandate the return value.
5600 </p>
5601 <hr>
5602 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Nov 1999</p>
5603 <p>
5604 In table 74, the return type of the expression <tt>*a</tt> is given
5605 as <tt>T&amp;</tt>, where <tt>T</tt> is the iterator's value type.
5606 For constant iterators, however, this is wrong.  ("Value type"
5607 is never defined very precisely, but it is clear that the value type
5608 of, say, <tt>std::list&lt;int&gt;::const_iterator</tt> is supposed to be
5609 <tt>int</tt>, not <tt>const int</tt>.)
5610 </p>
5611 <p><b>Proposed resolution:</b></p>
5612 <p>
5613 In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
5614 return type from "<tt>T&amp;</tt>" to "<tt>T&amp;</tt>
5615 if <tt>X</tt> is mutable, otherwise <tt>const T&amp;</tt>".
5616 In the <tt>a-&gt;m</tt> row, change the return type from
5617 "<tt>U&amp;</tt>" to "<tt>U&amp;</tt> if <tt>X</tt> is mutable,
5618 otherwise <tt>const U&amp;</tt>".
5619 </p>
5620
5621 <p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
5622 there are multiple const problems with the STL portion of the library
5623 and that these should be addressed as a single package.&nbsp; Note
5624 that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#180">180</a> has already been declared NAD Future for
5625 that very reason.]</i></p>
5626
5627 <p><i>[Redmond: the LWG thinks this is separable from other constness
5628 issues.  This issue is just cleanup; it clarifies language that was
5629 written before we had iterator_traits.  Proposed resolution was
5630 modified: the original version only discussed *a.  It was pointed out
5631 that we also need to worry about *r++ and a-&gt;m.]</i></p>
5632
5633 <hr>
5634 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;13 Jan 2000</p>
5635 <p>
5636 What should unique() do if you give it a predicate that is not an
5637 equivalence relation?  There are at least two plausible answers:
5638 </p>
5639
5640 <blockquote>
5641
5642 <p>
5643    1. You can't, because 25.2.8 says that it it "eliminates all but
5644    the first element from every consecutive group of equal
5645    elements..." and it wouldn't make sense to interpret "equal" as
5646    meaning anything but an equivalence relation.  [It also doesn't
5647    make sense to interpret "equal" as meaning ==, because then there
5648    would never be any sense in giving a predicate as an argument at
5649    all.]
5650 </p>
5651
5652 <p>
5653    2. The word "equal" should be interpreted to mean whatever the
5654    predicate says, even if it is not an equivalence relation
5655    (and in particular, even if it is not transitive).
5656 </p>
5657
5658 </blockquote>
5659
5660 <p>
5661 The example that raised this question is from Usenet:
5662 </p>
5663
5664 <blockquote>
5665
5666 <pre>int f[] = { 1, 3, 7, 1, 2 };
5667 int* z = unique(f, f+5, greater&lt;int&gt;());</pre>
5668
5669 </blockquote>
5670
5671 <p>
5672 If one blindly applies the definition using the predicate
5673 greater&lt;int&gt;, and ignore the word "equal", you get:
5674 </p>
5675
5676 <blockquote>
5677
5678 <p>
5679     Eliminates all but the first element from every consecutive group
5680     of elements referred to by the iterator i in the range [first, last)
5681     for which *i &gt; *(i - 1).
5682 </p>
5683
5684 </blockquote>
5685
5686 <p>
5687 The first surprise is the order of the comparison.  If we wanted to
5688 allow for the predicate not being an equivalence relation, then we
5689 should surely compare elements the other way: pred(*(i - 1), *i).  If
5690 we do that, then the description would seem to say: "Break the
5691 sequence into subsequences whose elements are in strictly increasing
5692 order, and keep only the first element of each subsequence".  So the
5693 result would be 1, 1, 2.  If we take the description at its word, it
5694 would seem to call for strictly DEcreasing order, in which case the
5695 result should be 1, 3, 7, 2.<br>
5696 <br>
5697 In fact, the SGI implementation of unique() does neither: It yields 1,
5698 3, 7.
5699 </p>
5700 <p><b>Proposed resolution:</b></p>
5701 <p>Change 25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> paragraph 1 to:</p>
5702 <blockquote>
5703 For a nonempty range, eliminates all but the first element from every
5704 consecutive group of equivalent elements referred to by the iterator
5705 <tt>i</tt> in the range [first+1, last) for which the following
5706 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
5707 false</tt>.
5708 </blockquote>
5709
5710 <p>
5711 Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
5712 comparison function must be an equivalence relation."
5713 </p>
5714
5715 <p><i>[Redmond: discussed arguments for and against requiring the
5716 comparison function to be an equivalence relation.  Straw poll:
5717 14-2-5.  First number is to require that it be an equivalence
5718 relation, second number is to explicitly not require that it be an
5719 equivalence relation, third number is people who believe they need
5720 more time to consider the issue.  A separate issue: Andy Sawyer
5721 pointed out that "i-1" is incorrect, since "i" can refer to the first
5722 iterator in the range.  Matt provided wording to address this
5723 problem.]</i></p>
5724
5725 <p><i>[Curaçao: The LWG changed "... the range (first,
5726 last)..." to "...  the range [first+1, last)..." for
5727 clarity. They considered this change close enough to editorial to not
5728 require another round of review.]</i></p>
5729
5730 <p><b>Rationale:</b></p>
5731 <p>The LWG also considered an alternative resolution: change
5732 25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> paragraph 1 to:</p>
5733
5734 <blockquote>
5735 For a nonempty range, eliminates all but the first element from every
5736 consecutive group of elements referred to by the iterator
5737 <tt>i</tt> in the range (first, last) for which the following
5738 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
5739 false</tt>.
5740 </blockquote>
5741
5742 <p>
5743 Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
5744 comparison function need not be an equivalence relation."
5745 </p>
5746
5747
5748 <p>Informally: the proposed resolution imposes an explicit requirement
5749 that the comparison function be an equivalence relation.  The
5750 alternative resolution does not, and it gives enough information so
5751 that the behavior of unique() for a non-equivalence relation is
5752 specified.  Both resolutions are consistent with the behavior of
5753 existing implementations.</p>
5754 <hr>
5755 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Stephen Cleary&nbsp; <b>Date:</b>&nbsp;02 Feb 2000</p>
5756 <p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
5757 past-the-end values are always non-singular."</p>
5758 <p>This places an unnecessary restriction on past-the-end iterators for
5759 containers with forward iterators (for example, a singly-linked list). If the
5760 past-the-end value on such a container was a well-known singular value, it would
5761 still satisfy all forward iterator requirements.</p>
5762 <p>Removing this restriction would allow, for example, a singly-linked list
5763 without a "footer" node.</p>
5764 <p>This would have an impact on existing code that expects past-the-end
5765 iterators obtained from different (generic) containers being not equal.</p>
5766 <p><b>Proposed resolution:</b></p>
5767 <p>Change 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> paragraph 5, the last sentence, from:</p>
5768 <blockquote>
5769 <p>Dereferenceable and past-the-end values are always non-singular.</p>
5770 </blockquote>
5771 <p>to:</p>
5772 <blockquote>
5773 <p>Dereferenceable values are always non-singular.&nbsp;</p>
5774 </blockquote>
5775 <p><b>Rationale:</b></p>
5776 <p>For some kinds of containers, including singly linked lists and
5777 zero-length vectors, null pointers are perfectly reasonable past-the-end
5778 iterators.  Null pointers are singular.
5779 </p>
5780 <hr>
5781 <a name="209"></a><h3><a name="209">209.&nbsp;basic_string declarations inconsistent</a></h3><p><b>Section:</b>&nbsp;21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Igor Stauder&nbsp; <b>Date:</b>&nbsp;11 Feb 2000</p>
5782 <p>In Section 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> the basic_string member function
5783 declarations use a consistent style except for the following functions:</p>
5784 <blockquote>
5785   <pre>void push_back(const charT);
5786 basic_string&amp; assign(const basic_string&amp;);
5787 void swap(basic_string&lt;charT,traits,Allocator&gt;&amp;);</pre>
5788 </blockquote>
5789 <p>- push_back, assign, swap: missing argument name&nbsp;<br>
5790 - push_back: use of const with charT (i.e. POD type passed by value
5791 not by reference - should be charT or const charT&amp; )<br>
5792 - swap: redundant use of template parameters in argument
5793 basic_string&lt;charT,traits,Allocator&gt;&amp;</p>
5794 <p><b>Proposed resolution:</b></p>
5795 <p>In Section 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> change the basic_string member
5796 function declarations push_back, assign, and swap to:</p>
5797 <blockquote>
5798   <pre>void push_back(charT c);
5799
5800 basic_string&amp; assign(const basic_string&amp; str);
5801 void swap(basic_string&amp; str);</pre>
5802 </blockquote>
5803 <p><b>Rationale:</b></p>
5804 <p>Although the standard is in general not consistent in declaration
5805 style, the basic_string declarations are consistent other than the
5806 above.  The LWG felt that this was sufficient reason to merit the
5807 change.
5808 </p>
5809 <hr>
5810 <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/papers/2005/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;15 Feb 2000</p>
5811 <p>In paragraph 9 of section 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>, it is written:</p>
5812 <blockquote>
5813   <p>      In the description of the algorithms operators + and - are used
5814            for some of the iterator categories for which they do not have to
5815            be defined. In these cases the semantics of [...] a-b is the same
5816            as of<br>
5817   <br>
5818   &nbsp;&nbsp;&nbsp;&nbsp; <tt>return distance(a, b);</tt></p>
5819 </blockquote>
5820 <p><b>Proposed resolution:</b></p>
5821 <p>On the last line of paragraph 9 of section 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> change
5822 <tt>"a-b"</tt> to <tt>"b-a".</tt></p>
5823 <p><b>Rationale:</b></p>
5824 <p>There are two ways to fix the defect; change the description to b-a
5825 or change the return to distance(b,a).  The LWG preferred the
5826 former for consistency.</p>
5827 <hr>
5828 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Scott Snyder&nbsp; <b>Date:</b>&nbsp;4 Feb 2000</p>
5829 <p>The description of the stream extraction operator for std::string (section
5830 21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
5831 the case that the operator fails to extract any characters from the input
5832 stream.</p>
5833 <p>This implies that the typical construction</p>
5834 <blockquote>
5835   <pre>std::istream is;
5836 std::string str;
5837 ...
5838 while (is &gt;&gt; str) ... ;</pre>
5839 </blockquote>
5840 <p>(which tests failbit) is not required to terminate at EOF.</p>
5841 <p>Furthermore, this is inconsistent with other extraction operators,
5842 which do include this requirement. (See sections 27.6.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), where this
5843 requirement is present, either explicitly or implicitly, for the
5844 extraction operators. It is also present explicitly in the description
5845 of getline (istream&amp;, string&amp;, charT) in section 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 8.)</p>
5846 <p><b>Proposed resolution:</b></p>
5847 <p>Insert new paragraph after paragraph 2 in section 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string.io"> [lib.string.io]</a>:</p>
5848 <blockquote>
5849
5850 <p>If the function extracts no characters, it calls
5851 is.setstate(ios::failbit) which may throw ios_base::failure
5852 (27.4.4.3).</p>
5853 </blockquote>
5854 <hr>
5855 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;26 Feb 2000</p>
5856 <p>The standard doesn't specify what min_element() and max_element() shall
5857 return if the range is empty (first equals last). The usual implementations
5858 return last. This problem seems also apply to partition(), stable_partition(),
5859 next_permutation(), and prev_permutation().</p>
5860 <p><b>Proposed resolution:</b></p>
5861 <p>In 25.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> - Minimum and maximum, paragraphs 7 and
5862 9, append: Returns last if first==last.</p>
5863 <p><b>Rationale:</b></p>
5864 <p>The LWG looked in some detail at all of the above mentioned
5865 algorithms, but believes that except for min_element() and
5866 max_element() it is already clear that last is returned if first ==
5867 last.</p>
5868 <hr>
5869 <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/papers/2005/lib-containers.html#lib.set"> [lib.set]</a>, 23.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.multiset"> [lib.multiset]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;28 Feb 2000</p>
5870 <p>The specification for the associative container requirements in
5871 Table 69 state that the find member function should "return
5872 iterator; const_iterator for constant a". The map and multimap
5873 container descriptions have two overloaded versions of find, but set
5874 and multiset do not, all they have is:</p>
5875 <blockquote>
5876   <pre>iterator find(const key_type &amp; x) const;</pre>
5877 </blockquote>
5878 <p><b>Proposed resolution:</b></p>
5879 <p>Change the prototypes for find(), lower_bound(), upper_bound(), and
5880 equal_range() in section 23.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.set"> [lib.set]</a> and section 23.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.multiset"> [lib.multiset]</a> to each have two overloads:</p>
5881 <blockquote>
5882   <pre>iterator find(const key_type &amp; x);
5883 const_iterator find(const key_type &amp; x) const;</pre>
5884   <pre>iterator lower_bound(const key_type &amp; x);
5885 const_iterator lower_bound(const key_type &amp; x) const;</pre>
5886   <pre>iterator upper_bound(const key_type &amp; x);
5887 const_iterator upper_bound(const key_type &amp; x) const;</pre>
5888   <pre>pair&lt;iterator, iterator&gt; equal_range(const key_type &amp; x);
5889 pair&lt;const_iterator, const_iterator&gt; equal_range(const key_type &amp; x) const;</pre>
5890 </blockquote>
5891
5892 <p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
5893 extending the proposed resolution to lower_bound, upper_bound, and
5894 equal_range.]</i></p>
5895 <hr>
5896 <a name="217"></a><h3><a name="217">217.&nbsp;Facets example (Classifying Japanese characters) contains errors</a></h3><p><b>Section:</b>&nbsp;22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;29 Feb 2000</p>
5897 <p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
5898 <p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
5899 must be const in order for it to be callable on a const object (a reference to
5900 which which is what std::use_facet&lt;&gt;() returns).</p>
5901 <p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
5902 name of the namespace `My'.</p>
5903 <p>3) In the definition of `loc' and subsequently in the call to use_facet&lt;&gt;()
5904 in main(), the name of the facet is misspelled: it should read `My::JCtype'
5905 rather than `My::JCType'.</p>
5906 <p><b>Proposed resolution:</b></p>
5907 <p>Replace the "Classifying Japanese characters" example in 22.2.8,
5908 paragraph 11 with the following:</p>
5909 <pre>#include &lt;locale&gt;</pre>
5910 <pre>namespace My {
5911     using namespace std;
5912     class JCtype : public locale::facet {
5913     public:
5914         static locale::id id;     //  required for use as a new locale facet
5915         bool is_kanji (wchar_t c) const;
5916         JCtype() {}
5917     protected:
5918         ~JCtype() {}
5919     };
5920 }</pre>
5921 <pre>//  file:  filt.C
5922 #include &lt;iostream&gt;
5923 #include &lt;locale&gt;
5924 #include "jctype"                 //  above
5925 std::locale::id My::JCtype::id;   //  the static  JCtype  member
5926 declared above.</pre>
5927 <pre>int main()
5928 {
5929     using namespace std;
5930     typedef ctype&lt;wchar_t&gt; wctype;
5931     locale loc(locale(""),              //  the user's preferred locale...
5932                new My::JCtype);         //  and a new feature ...
5933     wchar_t c = use_facet&lt;wctype&gt;(loc).widen('!');
5934     if (!use_facet&lt;My::JCtype&gt;(loc).is_kanji(c))
5935         cout &lt;&lt; "no it isn't!" &lt;&lt; endl;
5936     return 0;
5937 }</pre>
5938 <hr>
5939 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jonathan Schilling, Howard Hinnant&nbsp; <b>Date:</b>&nbsp;13 Mar 2000</p>
5940 <p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
5941 paragraph 2:</p>
5942 <blockquote>
5943   <p>Effects: Destroys an object of class ios_base. Calls each registered
5944   callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
5945   time that any ios_base member function called from within fn has well defined
5946   results.</p>
5947 </blockquote>
5948 <p>But what is not clear is: If no callback functions were ever registered, does
5949 it matter whether the ios_base members were ever initialized?</p>
5950 <p>For instance, does this program have defined behavior:</p>
5951 <blockquote>
5952   <pre>#include &lt;ios&gt;</pre>
5953   <pre>class D : public std::ios_base { };</pre>
5954   <pre>int main() { D d; }</pre>
5955 </blockquote>
5956 <p>It seems that registration of a callback function would surely affect the
5957 state of an ios_base. That is, when you register a callback function with an
5958 ios_base, the ios_base must record that fact somehow.</p>
5959 <p>But if after construction the ios_base is in an indeterminate state, and that
5960 state is not made determinate before the destructor is called, then how would
5961 the destructor know if any callbacks had indeed been registered? And if the
5962 number of callbacks that had been registered is indeterminate, then is not the
5963 behavior of the destructor undefined?</p>
5964 <p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
5965 it explicit that destruction before initialization results in undefined
5966 behavior.</p>
5967 <p><b>Proposed resolution:</b></p>
5968 <p>Modify 27.4.2.7 paragraph 1 from</p>
5969 <blockquote>
5970   <p>Effects: Each ios_base member has an indeterminate value after
5971   construction.</p>
5972 </blockquote>
5973 <p>to</p>
5974 <blockquote>
5975   <p>Effects: Each ios_base member has an indeterminate
5976 value after construction. These members must be initialized by calling
5977 basic_ios::init. If an ios_base object is destroyed before these
5978 initializations have taken place, the behavior is undefined.</p>
5979 </blockquote>
5980 <hr>
5981 <a name="221"></a><h3><a name="221">221.&nbsp;num_get&lt;&gt;::do_get stage 2 processing broken</a></h3><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;14 Mar 2000</p>
5982 <p>Stage 2 processing of numeric conversion is broken.</p>
5983
5984 <p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
5985 conversion specifier is %i. A %i specifier determines a number's base
5986 by its prefix (0 for octal, 0x for hex), so the intention is clearly
5987 that a 0x prefix is allowed.  Paragraph 8 in the same section,
5988 however, describes very precisely how characters are processed. (It
5989 must be done "as if" by a specified code fragment.) That
5990 description does not allow a 0x prefix to be recognized.</p>
5991
5992 <p>Very roughly, stage 2 processing reads a char_type ct. It converts
5993 ct to a char, not by using narrow but by looking it up in a
5994 translation table that was created by widening the string literal
5995 "0123456789abcdefABCDEF+-". The character "x" is
5996 not found in that table, so it can't be recognized by stage 2
5997 processing.</p>
5998 <p><b>Proposed resolution:</b></p>
5999 <p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
6000 <blockquote>
6001   <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
6002 </blockquote>
6003 <p>with the line:</p>
6004 <blockquote>
6005   <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
6006 </blockquote>
6007 <p><b>Rationale:</b></p>
6008 <p>If we're using the technique of widening a string literal, the
6009 string literal must contain every character we wish to recognize.
6010 This technique has the consequence that alternate representations
6011 of digits will not be recognized.  This design decision was made
6012 deliberately, with full knowledge of that limitation.</p>
6013 <hr>
6014 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;17 Mar 2000</p>
6015 <p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
6016 <blockquote>
6017   <pre>21.3.6.8 - basic_string::compare [lib.string::compare]
6018
6019 int compare(size_type pos1, size_type n1,
6020                 const basic_string&lt;charT,traits,Allocator&gt;&amp;  str ,
6021                 size_type  pos2 , size_type  n2 ) const;
6022
6023 -4- Returns:
6024
6025     basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
6026                  basic_string&lt;charT,traits,Allocator&gt;(str,pos2,n2)) .</pre>
6027 </blockquote>
6028 <p>and the constructor that's implicitly called by the above is
6029 defined to throw an out-of-range exception if pos &gt; str.size(). See
6030 section 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string.cons"> [lib.string.cons]</a> paragraph 4.</p>
6031
6032 <p>On the other hand, the compare function descriptions themselves don't have
6033 "Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
6034 that do not apply to a function are omitted.</p>
6035 <p>So it seems there is an inconsistency in the standard -- are the
6036 "Effects" clauses correct, or are the "Throws" clauses
6037 missing?</p>
6038 <p><b>Proposed resolution:</b></p>
6039 <p>In 17.3.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> paragraph 3, the footnote 148 attached to
6040 the sentence "Descriptions of function semantics contain the
6041 following elements (as appropriate):", insert the word
6042 "further" so that the foot note reads:</p>
6043 <blockquote>
6044   <p>To save space, items that do not apply to a function are
6045   omitted. For example, if a function does not specify any further
6046   preconditions, there will be no "Requires" paragraph.</p>
6047 </blockquote>
6048 <p><b>Rationale:</b></p>
6049 <p>The standard is somewhat inconsistent, but a failure to note a
6050 throw condition in a throws clause does not grant permission not to
6051 throw.  The inconsistent wording is in a footnote, and thus
6052 non-normative. The proposed resolution from the LWG clarifies the
6053 footnote.</p>
6054 <hr>
6055 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;21 Mar 2000</p>
6056 <p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
6057 <p><b>Proposed resolution:</b></p>
6058 <p>In 25.2.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a>, replace:</p>
6059   <blockquote>
6060   Effects: For each non-negative integer i &lt;= (last - first)/2,
6061   applies swap to all pairs of iterators first + i, (last - i) - 1.
6062   </blockquote>
6063 <p>with:</p>
6064   <blockquote>
6065   Effects: For each non-negative integer i &lt;= (last - first)/2,
6066   applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
6067   </blockquote>
6068 <hr>
6069 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Ed Brey&nbsp; <b>Date:</b>&nbsp;23 Mar 2000</p>
6070 <p>In the associative container requirements table in 23.1.2 paragraph 7,
6071 a.clear() has complexity "log(size()) + N". However, the meaning of N
6072 is not defined.</p>
6073 <p><b>Proposed resolution:</b></p>
6074 <p>In the associative container requirements table in 23.1.2 paragraph
6075 7, the complexity of a.clear(), change "log(size()) + N" to
6076 "linear in <tt>size()</tt>".</p>
6077 <p><b>Rationale:</b></p>
6078 <p>It's the "log(size())", not the "N", that is in
6079 error: there's no difference between <i>O(N)</i> and <i>O(N +
6080 log(N))</i>.  The text in the standard is probably an incorrect
6081 cut-and-paste from the range version of <tt>erase</tt>.</p>
6082 <hr>
6083 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
6084 <p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
6085 user namespaces might be found through Koenig lookup?</p>
6086 <p>For example, a popular standard library implementation includes this
6087 implementation of std::unique:</p>
6088 <blockquote>
6089 <pre>namespace std {
6090     template &lt;class _ForwardIter&gt;
6091     _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
6092       __first = adjacent_find(__first, __last);
6093       return unique_copy(__first, __last, __first);
6094     }
6095     }</pre>
6096 </blockquote>
6097 <p>Imagine two users on opposite sides of town, each using unique on his own
6098 sequences bounded by my_iterators . User1 looks at his standard library
6099 implementation and says, "I know how to implement a more efficient
6100 unique_copy for my_iterators", and writes:</p>
6101 <blockquote>
6102 <pre>namespace user1 {
6103     class my_iterator;
6104     // faster version for my_iterator
6105     my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
6106     }</pre>
6107 </blockquote>
6108 <p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
6109 <p>User2 has other needs, and writes:</p>
6110 <blockquote>
6111 <pre>namespace user2 {
6112     class my_iterator;
6113     // Returns true iff *c is a unique copy of *a and *b.
6114     bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
6115     }</pre>
6116 </blockquote>
6117 <p>User2 is shocked to find later that his fully-qualified use of
6118 std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
6119 compile (if he's lucky). Looking in the standard, he sees the following Effects
6120 clause for unique():</p>
6121 <blockquote>
6122   <p>Effects: Eliminates all but the first element from every consecutive group
6123   of equal elements referred to by the iterator i in the range [first, last) for
6124   which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
6125   *(i - 1)) != false</p>
6126 </blockquote>
6127 <p>The standard gives user2 absolutely no reason to think he can interfere with
6128 std::unique by defining names in namespace user2. His standard library has been
6129 built with the template export feature, so he is unable to inspect the
6130 implementation. User1 eventually compiles his code with another compiler, and
6131 his version of unique_copy silently stops being called. Eventually, he realizes
6132 that he was depending on an implementation detail of his library and had no
6133 right to expect his unique_copy() to be called portably.</p>
6134 <p>On the face of it, and given above scenario, it may seem obvious that the
6135 implementation of unique() shown is non-conforming because it uses unique_copy()
6136 rather than ::std::unique_copy(). Most standard library implementations,
6137 however, seem to disagree with this notion.</p>
6138 <p> <i>[Tokyo:&nbsp; Steve Adamczyk from
6139 the core working group indicates that "std::" is sufficient;&nbsp;
6140 leading "::" qualification is not required because any namespace
6141 qualification is sufficient to suppress Koenig lookup.]</i></p>
6142 <p><b>Proposed resolution:</b></p>
6143 <p>Add a paragraph and a note at the end of
6144 17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.global.functions"> [lib.global.functions]</a>:</p>
6145 <blockquote>
6146
6147 <p>Unless otherwise specified, no global or non-member function in the
6148 standard library shall use a function from another namespace which is
6149 found through <i>argument-dependent name lookup</i> (3.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/basic.html#basic.lookup.koenig"> [basic.lookup.koenig]</a>).</p>
6150
6151 <p>[Note: the phrase "unless otherwise specified" is intended to
6152 allow Koenig lookup in cases like that of ostream_iterators:<br>
6153
6154 <br>
6155   Effects:</p>
6156   <blockquote>
6157 <p>*out_stream &lt;&lt; value;<br>
6158       if(delim != 0) *out_stream &lt;&lt; delim;<br>
6159       return (*this);</p>
6160     <p>--end note]</p>
6161   </blockquote>
6162 </blockquote>
6163
6164 <p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
6165 is as yet unsure if the proposed resolution is the best
6166 solution. Furthermore, the LWG believes that the same problem of
6167 unqualified library names applies to wording in the standard itself,
6168 and has opened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#229">229</a> accordingly. Any resolution of
6169 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#225">225</a> should be coordinated with the resolution of
6170 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#229">229</a>.]</i></p>
6171
6172 <p><i>[Toronto: The LWG is not sure if this is a defect in the
6173 standard.  Most LWG members believe that an implementation of
6174 <tt>std::unique</tt> like the one quoted in this issue is already
6175 illegal, since, under certain circumstances, its semantics are not
6176 those specified in the standard.  The standard's description of
6177 <tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
6178 should have any effect.]</i></p>
6179
6180 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
6181 225, 226, and 229.  Their conclusion was that the issues should be
6182 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6183 EWG portion (Dave will write a proposal). The LWG and EWG had
6184 (separate) discussions of this plan the next day.  The proposed
6185 resolution for this issue is in accordance with Howard's paper.]</i></p>
6186
6187 <p><b>Rationale:</b></p>
6188 <p>It could be argued that this proposed isn't strictly necessary,
6189   that the Standard doesn't grant implementors license to write a
6190   standard function that behaves differently than specified in the
6191   Standard just because of an unrelated user-defined name in some
6192   other namespace.  However, this is at worst a clarification.  It is
6193   surely right that algorithsm shouldn't pick up random names, that
6194   user-defined names should have no effect unless otherwise specified.
6195   Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#226">226</a> deals with the question of when it is
6196   appropriate for the standard to explicitly specify otherwise.</p>
6197 <hr>
6198 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
6199 <p>The issues are:&nbsp;</p>
6200 <p>1. How can a 3rd party library implementor (lib1) write a version of a standard
6201 algorithm which is specialized to work with his own class template?&nbsp;</p>
6202 <p>2. How can another library implementor (lib2) write a generic algorithm which
6203 will take advantage of the specialized algorithm in lib1?</p>
6204 <p>This appears to be the only viable answer under current language rules:</p>
6205 <blockquote>
6206   <pre>namespace lib1
6207 {
6208     // arbitrary-precision numbers using T as a basic unit
6209     template &lt;class T&gt;
6210     class big_num { //...
6211     };
6212     </pre>
6213   <pre>    // defining this in namespace std is illegal (it would be an
6214     // overload), so we hope users will rely on Koenig lookup
6215     template &lt;class T&gt;
6216     void swap(big_int&lt;T&gt;&amp;, big_int&lt;T&gt;&amp;);
6217 }</pre>
6218   <pre>#include &lt;algorithm&gt;
6219 namespace lib2
6220 {
6221     template &lt;class T&gt;
6222     void generic_sort(T* start, T* end)
6223     {
6224             ...
6225         // using-declaration required so we can work on built-in types
6226         using std::swap;
6227         // use Koenig lookup to find specialized algorithm if available
6228         swap(*x, *y);
6229     }
6230 }</pre>
6231 </blockquote>
6232 <p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
6233 and somewhat slippery. The implementor needs to remember to write the
6234 using-declaration, or generic_sort will fail to compile when T is a built-in
6235 type. The second drawback is that the use of this style in lib2 effectively
6236 "reserves" names in any namespace which defines types which may
6237 eventually be used with lib2. This may seem innocuous at first when applied to
6238 names like swap, but consider more ambiguous names like unique_copy() instead.
6239 It is easy to imagine the user wanting to define these names differently in his
6240 own namespace. A definition with semantics incompatible with the standard
6241 library could cause serious problems (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#225">225</a>).</p>
6242 <p>Why, you may ask, can't we just partially specialize std::swap()? It's
6243 because the language doesn't allow for partial specialization of function
6244 templates. If you write:</p>
6245 <blockquote>
6246   <pre>namespace std
6247 {
6248     template &lt;class T&gt;
6249     void swap(lib1::big_int&lt;T&gt;&amp;, lib1::big_int&lt;T&gt;&amp;);
6250 }</pre>
6251 </blockquote>
6252 <p>You have just overloaded std::swap, which is illegal under the current
6253 language rules. On the other hand, the following full specialization is legal:</p>
6254 <blockquote>
6255   <pre>namespace std
6256 {
6257     template &lt;&gt;
6258     void swap(lib1::other_type&amp;, lib1::other_type&amp;);
6259 }</pre>
6260 </blockquote>
6261
6262 <p>This issue reflects concerns raised by the "Namespace issue
6263 with specialized swap" thread on comp.lang.c++.moderated. A
6264 similar set of concerns was earlier raised on the boost.org mailing
6265 list and the ACCU-general mailing list.  Also see library reflector
6266 message c++std-lib-7354.</p>
6267
6268 <p>
6269 J. C. van Winkel points out (in c++std-lib-9565) another unexpected
6270 fact: it's impossible to output a container of std::pair's using copy
6271 and an ostream_iterator, as long as both pair-members are built-in or
6272 std:: types.  That's because a user-defined operator&lt;&lt; for (for
6273 example) std::pair&lt;const std::string, int&gt; will not be found:
6274 lookup for operator&lt;&lt; will be performed only in namespace std.
6275 Opinions differed on whether or not this was a defect, and, if so,
6276 whether the defect is that something is wrong with user-defined
6277 functionality and std, or whether it's that the standard library does
6278 not provide an operator&lt;&lt; for std::pair&lt;&gt;.
6279 </p>
6280
6281 <p><b>Proposed resolution:</b></p>
6282
6283 <p>Adopt the wording proposed in Howard Hinnant's paper
6284   N1523=03-0106, "Proposed Resolution To LWG issues 225, 226, 229".</p>
6285
6286
6287 <p><i>[Tokyo: Summary, "There is no conforming way to extend
6288 std::swap for user defined templates."&nbsp; The LWG agrees that
6289 there is a problem.  Would like more information before
6290 proceeding. This may be a core issue.  Core issue 229 has been opened
6291 to discuss the core aspects of this problem. It was also noted that
6292 submissions regarding this issue have been received from several
6293 sources, but too late to be integrated into the issues list.
6294 ]</i></p>
6295
6296 <p><i>[Post-Tokyo: A paper with several proposed resolutions,
6297 J16/00-0029==WG21/N1252, "Shades of namespace std functions
6298 " by Alan Griffiths, is in the Post-Tokyo mailing. It
6299 should be considered a part of this issue.]</i></p>
6300
6301 <p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
6302 resolution that involves core changes: it would add partial
6303 specialization of function template.  The Core Working Group is
6304 reluctant to add partial specialization of function templates.  It is
6305 viewed as a large change, CWG believes that proposal presented leaves
6306 some syntactic issues unanswered; if the CWG does add partial
6307 specialization of function templates, it wishes to develop its own
6308 proposal.  The LWG continues to believe that there is a serious
6309 problem: there is no good way for users to force the library to use
6310 user specializations of generic standard library functions, and in
6311 certain cases (e.g. transcendental functions called by
6312 <tt>valarray</tt> and <tt>complex</tt>) this is important.  Koenig
6313 lookup isn't adequate, since names within the library must be
6314 qualified with <tt>std</tt> (see issue 225), specialization doesn't
6315 work (we don't have partial specialization of function templates), and
6316 users aren't permitted to add overloads within namespace std.
6317 ]</i></p>
6318
6319 <p><i>[Copenhagen: Discussed at length, with no consensus.  Relevant
6320 papers in the pre-Copenhagen mailing: N1289, N1295, N1296.  Discussion
6321 focused on four options. (1) Relax restrictions on overloads within
6322 namespace std. (2) Mandate that the standard library use unqualified
6323 calls for <tt>swap</tt> and possibly other functions.  (3) Introduce
6324 helper class templates for <tt>swap</tt> and possibly other functions.
6325 (4) Introduce partial specialization of function templates.  Every
6326 option had both support and opposition.  Straw poll (first number is
6327 support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
6328 (4) 4, 4.]</i></p>
6329
6330 <p><i>[Redmond: Discussed, again no consensus.  Herb presented an
6331 argument that a user who is defining a type <tt>T</tt> with an
6332 associated <tt>swap</tt> should not be expected to put that
6333 <tt>swap</tt> in namespace std, either by overloading or by partial
6334 specialization.  The argument is that <tt>swap</tt> is part of
6335 <tt>T</tt>'s interface, and thus should to in the same namespace as
6336 <tt>T</tt> and only in that namespace.  If we accept this argument,
6337 the consequence is that standard library functions should use
6338 unqualified call of <tt>swap</tt>.  (And which other functions? Any?)
6339 A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
6340 try to put together a proposal before the next meeting.]</i></p>
6341
6342 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
6343 225, 226, and 229.  Their conclusion was that the issues should be
6344 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6345 EWG portion (Dave will write a proposal). The LWG and EWG had
6346 (separate) discussions of this plan the next day.  The proposed
6347 resolution is the one proposed by Howard.]</i></p>
6348
6349 <p><i>[Santa Cruz: the LWG agreed with the general direction of
6350   Howard's paper, N1387.  (Roughly: Koenig lookup is disabled unless
6351   we say otherwise; this issue is about when we do say otherwise.)
6352   However, there were concerns about wording.  Howard will provide new
6353   wording.  Bill and Jeremy will review it.]</i></p>
6354
6355 <p><i>[Kona: Howard proposed the new wording.  The LWG accepted his
6356   proposed resolution.]</i></p>
6357
6358 <p><b>Rationale:</b></p>
6359 <p>Informally: introduce a Swappable concept, and specify that the
6360   value types of the iterators passed to certain standard algorithms
6361   (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
6362   to that concept.  The Swappable concept will make it clear that
6363   these algorithms use unqualified lookup for the calls
6364   to <tt>swap</tt>.  Also, in 26.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.valarray.transcend"> [lib.valarray.transcend]</a> paragraph 1,
6365   state that the valarray transcendentals use unqualified lookup.</p>
6366 <hr>
6367 <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/papers/2005/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/papers/2005/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;09 Apr 2000</p>
6368 <p>25.2.2 reads:</p>
6369 <blockquote>
6370   <p><tt>  template&lt;class T&gt; void swap(T&amp; a, T&amp; b);</tt><br>
6371   <br>
6372   Requires:    Type T is Assignable (_lib.container.requirements_).<br>
6373   Effects:    Exchanges values stored in two locations.</p>
6374 </blockquote>
6375 <p>The only reasonable** generic implementation of swap requires construction of a
6376    new temporary copy of one of its arguments:</p>
6377 <blockquote>
6378 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
6379   {
6380       T tmp(a);
6381       a = b;
6382       b = tmp;
6383   }</pre>
6384 </blockquote>
6385 <p>But a type which is only Assignable cannot be swapped by this implementation.</p>
6386 <p>**Yes, there's also an unreasonable implementation which would require T to be
6387    DefaultConstructible instead of CopyConstructible. I don't think this is worthy
6388    of consideration:</p>
6389 <blockquote>
6390 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
6391 {
6392     T tmp;
6393     tmp = a;
6394     a = b;
6395     b = tmp;
6396 }</pre>
6397 </blockquote>
6398 <p><b>Proposed resolution:</b></p>
6399 <p>Change 25.2.2 paragraph 1 from:</p>
6400 <blockquote>
6401 <p>  Requires: Type T is Assignable (23.1).</p>
6402 </blockquote>
6403 <p>to:</p>
6404 <blockquote>
6405 <p>  Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
6406 </blockquote>
6407 <hr>
6408 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Apr 2000</p>
6409 <p>The sections 22.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a>,
6410 22.2.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/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/papers/2005/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/papers/2005/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/papers/2005/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/papers/2005/lib-locales.html#lib.locale.messages.byname"> [lib.locale.messages.byname]</a> overspecify the
6411 definitions of the "..._byname" classes by listing a bunch
6412 of virtual functions. At the same time, no semantics of these
6413 functions are defined. Real implementations do not define these
6414 functions because the functional part of the facets is actually
6415 implemented in the corresponding base classes and the constructor of
6416 the "..._byname" version just provides suitable date used by
6417 these implementations. For example, the 'numpunct' methods just return
6418 values from a struct. The base class uses a statically initialized
6419 struct while the derived version reads the contents of this struct
6420 from a table.  However, no virtual function is defined in
6421 'numpunct_byname'.</p>
6422
6423 <p>For most classes this does not impose a problem but specifically
6424 for 'ctype' it does: The specialization for 'ctype_byname&lt;char&gt;'
6425 is required because otherwise the semantics would change due to the
6426 virtual functions defined in the general version for 'ctype_byname':
6427 In 'ctype&lt;char&gt;' the method 'do_is()' is not virtual but it is
6428 made virtual in both 'ctype&lt;cT&gt;' and 'ctype_byname&lt;cT&gt;'.
6429 Thus, a class derived from 'ctype_byname&lt;char&gt;' can tell whether
6430 this class is specialized or not under the current specification:
6431 Without the specialization, 'do_is()' is virtual while with
6432 specialization it is not virtual.</p>
6433 <p><b>Proposed resolution:</b></p>
6434 <p>&nbsp; Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
6435 <pre>     namespace std {
6436        template &lt;class charT&gt;
6437        class ctype_byname : public ctype&lt;charT&gt; {
6438        public:
6439          typedef ctype&lt;charT&gt;::mask mask;
6440          explicit ctype_byname(const char*, size_t refs = 0);
6441        protected:
6442         ~ctype_byname();             //  virtual
6443        };
6444      }</pre>
6445 <p>&nbsp; Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
6446 <pre>    namespace std {
6447       template &lt;class internT, class externT, class stateT&gt;
6448       class codecvt_byname : public codecvt&lt;internT, externT, stateT&gt; {
6449       public:
6450        explicit codecvt_byname(const char*, size_t refs = 0);
6451       protected:
6452       ~codecvt_byname();             //  virtual
6453        };
6454      }
6455 </pre>
6456 <p>&nbsp; Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
6457 <pre>     namespace std {
6458        template &lt;class charT&gt;
6459        class numpunct_byname : public numpunct&lt;charT&gt; {
6460      //  this class is specialized for  char  and  wchar_t.
6461        public:
6462          typedef charT                char_type;
6463          typedef basic_string&lt;charT&gt;  string_type;
6464          explicit numpunct_byname(const char*, size_t refs = 0);
6465        protected:
6466         ~numpunct_byname();          //  virtual
6467        };
6468      }</pre>
6469 <p>&nbsp; Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
6470 <pre>     namespace std {
6471        template &lt;class charT&gt;
6472        class collate_byname : public collate&lt;charT&gt; {
6473        public:
6474          typedef basic_string&lt;charT&gt; string_type;
6475          explicit collate_byname(const char*, size_t refs = 0);
6476        protected:
6477         ~collate_byname();           //  virtual
6478        };
6479      }</pre>
6480 <p>&nbsp; Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
6481 <pre>     namespace std {
6482        template &lt;class charT, class InputIterator = istreambuf_iterator&lt;charT&gt; &gt;
6483        class time_get_byname : public time_get&lt;charT, InputIterator&gt; {
6484        public:
6485          typedef time_base::dateorder dateorder;
6486          typedef InputIterator        iter_type</pre>
6487 <pre>         explicit time_get_byname(const char*, size_t refs = 0);
6488        protected:
6489         ~time_get_byname();          //  virtual
6490        };
6491      }</pre>
6492 <p>&nbsp; Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
6493 <pre>     namespace std {
6494        template &lt;class charT, class OutputIterator = ostreambuf_iterator&lt;charT&gt; &gt;
6495        class time_put_byname : public time_put&lt;charT, OutputIterator&gt;
6496        {
6497        public:
6498          typedef charT          char_type;
6499          typedef OutputIterator iter_type;</pre>
6500 <pre>         explicit time_put_byname(const char*, size_t refs = 0);
6501        protected:
6502         ~time_put_byname();          //  virtual
6503        };
6504      }"</pre>
6505 <p>&nbsp; Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
6506 <pre>     namespace std {
6507        template &lt;class charT, bool Intl = false&gt;
6508        class moneypunct_byname : public moneypunct&lt;charT, Intl&gt; {
6509        public:
6510          typedef money_base::pattern pattern;
6511          typedef basic_string&lt;charT&gt; string_type;</pre>
6512 <pre>         explicit moneypunct_byname(const char*, size_t refs = 0);
6513        protected:
6514         ~moneypunct_byname();        //  virtual
6515        };
6516      }</pre>
6517 <p>&nbsp; Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
6518 <pre>     namespace std {
6519        template &lt;class charT&gt;
6520        class messages_byname : public messages&lt;charT&gt; {
6521        public:
6522          typedef messages_base::catalog catalog;
6523          typedef basic_string&lt;charT&gt;    string_type;</pre>
6524 <pre>         explicit messages_byname(const char*, size_t refs = 0);
6525        protected:
6526         ~messages_byname();          //  virtual
6527        };
6528      }</pre>
6529 <p>Remove section 22.2.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a> completely (because in
6530 this case only those members are defined to be virtual which are
6531 defined to be virtual in 'ctype&lt;cT&gt;'.)</p>
6532
6533 <p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of
6534 the LWG to solve the underlying problems raised by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#138">138</a>.]</i></p>
6535
6536 <p><i>[Copenhagen: proposed resolution was revised slightly, to remove
6537 three last virtual functions from <tt>messages_byname</tt>.]</i></p>
6538
6539 <hr>
6540 <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/papers/2005/lib-intro.html#lib.contents"> [lib.contents]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;19 Apr 2000</p>
6541 <p>Throughout the library chapters, the descriptions of library entities refer
6542 to other library entities without necessarily qualifying the names.</p>
6543
6544 <p>For example, section 25.2.2 "Swap" describes the effect of
6545 swap_ranges in terms of the unqualified name "swap". This section
6546 could reasonably be interpreted to mean that the library must be implemented so
6547 as to do a lookup of the unqualified name "swap", allowing users to
6548 override any ::std::swap function when Koenig lookup applies.</p>
6549
6550 <p>Although it would have been best to use explicit qualification with
6551 "::std::" throughout, too many lines in the standard would have to be
6552 adjusted to make that change in a Technical Corrigendum.</p>
6553
6554 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#182">182</a>, which addresses qualification of
6555 <tt>size_t</tt>, is a special case of this.
6556 </p>
6557 <p><b>Proposed resolution:</b></p>
6558 <p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p>
6559 <blockquote>
6560   <p>Whenever a name x defined in the standard library is mentioned, the name x
6561   is assumed to be fully qualified as ::std::x, unless explicitly described
6562   otherwise. For example, if the Effects section for library function F is
6563   described as calling library function G, the function ::std::G is meant.</p>
6564 </blockquote>
6565
6566 <p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
6567 the LWG to solve a problem in the standard itself similar to the
6568 problem within implementations of library identified by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#225">225</a>.  Any resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#225">225</a> should be
6569 coordinated with the resolution of this issue.]</i></p>
6570
6571 <p><i>[post-Toronto: Howard is undecided about whether it is
6572 appropriate for all standard library function names referred to in
6573 other standard library functions to be explicitly qualified by
6574 <tt>std</tt>: it is common advice that users should define global
6575 functions that operate on their class in the same namespace as the
6576 class, and this requires argument-dependent lookup if those functions
6577 are intended to be called by library code.  Several LWG members are
6578 concerned that valarray appears to require argument-dependent lookup,
6579 but that the wording may not be clear enough to fall under
6580 "unless explicitly described otherwise".]</i></p>
6581
6582 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
6583 225, 226, and 229.  Their conclusion was that the issues should be
6584 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6585 EWG portion (Dave will write a proposal). The LWG and EWG had
6586 (separate) discussions of this plan the next day.  This paper resolves
6587 issues 225 and 226.  In light of that resolution, the proposed
6588 resolution for the current issue makes sense.]</i></p>
6589
6590 <hr>
6591 <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/papers/2005/lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;26 Apr 2000</p>
6592 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#227">227</a> identified an instance (std::swap) where
6593 Assignable was specified without also specifying
6594 CopyConstructible. The LWG asked that the standard be searched to
6595 determine if the same defect existed elsewhere.</p>
6596
6597 <p>There are a number of places (see proposed resolution below) where
6598 Assignable is specified without also specifying
6599 CopyConstructible. There are also several cases where both are
6600 specified. For example, 26.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p>
6601 <p><b>Proposed resolution:</b></p>
6602 <p>In  23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> table 65 for value_type:
6603 change "T is Assignable" to "T is CopyConstructible and
6604 Assignable"
6605 </p>
6606
6607 <p>In 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> table 69 X::key_type; change
6608 "Key is Assignable" to "Key is
6609 CopyConstructible and Assignable"<br>
6610 </p>
6611
6612 <p>In 24.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a> paragraph 1, change:
6613 </p>
6614 <blockquote>
6615 <p> A class or a built-in type X satisfies the requirements of an
6616 output iterator if X is an Assignable type (23.1) and also the
6617 following expressions are valid, as shown in Table 73:
6618 </p>
6619 </blockquote>
6620 <p>to:
6621 </p>
6622 <blockquote>
6623 <p> A class or a built-in type X satisfies the requirements of an
6624 output iterator if X is a CopyConstructible (20.1.3) and Assignable
6625 type (23.1) and also the following expressions are valid, as shown in
6626 Table 73:
6627 </p>
6628 </blockquote>
6629
6630 <p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
6631 the LWG.  He asks that the 25.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a> changes be studied carefully, as it is not clear that
6632 CopyConstructible is really a requirement and may be
6633 overspecification.]</i></p>
6634
6635 <p><i>[Portions of the resolution for issue 230 have been superceded by
6636 the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#276">276</a>.]</i></p>
6637
6638 <p><b>Rationale:</b></p>
6639 <p>The original proposed resolution also included changes to input
6640 iterator, fill, and replace.  The LWG believes that those changes are
6641 not necessary.  The LWG considered some blanket statement, where an
6642 Assignable type was also required to be Copy Constructible, but
6643 decided against this because fill and replace really don't require the
6644 Copy Constructible property.</p>
6645 <hr>
6646 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze, Stephen Clamage&nbsp; <b>Date:</b>&nbsp; 25 Apr 2000</p>
6647 <p>What is the following program supposed to output?</p>
6648 <pre>#include &lt;iostream&gt;
6649
6650     int
6651     main()
6652     {
6653         std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
6654         std::cout.precision( 0 ) ;
6655         std::cout &lt;&lt; 1.00 &lt;&lt; '\n' ;
6656         return 0 ;
6657     }</pre>
6658 <p>From my C experience, I would expect "1e+00"; this is what
6659 <tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs
6660 "1.000000e+00".</p>
6661
6662 <p>The only indication I can find in the standard is 22.2.2.2.2/11,
6663 where it says "For conversion from a floating-point type, if
6664 (flags &amp; fixed) != 0 or if str.precision() &gt; 0, then
6665 str.precision() is specified in the conversion specification."
6666 This is an obvious error, however, fixed is not a mask for a field,
6667 but a value that a multi-bit field may take -- the results of and'ing
6668 fmtflags with ios::fixed are not defined, at least not if
6669 ios::scientific has been set. G++'s behavior corresponds to what might
6670 happen if you do use (flags &amp; fixed) != 0 with a typical
6671 implementation (floatfield == 3 &lt;&lt; something, fixed == 1
6672 &lt;&lt; something, and scientific == 2 &lt;&lt; something).</p>
6673
6674 <p>Presumably, the intent is either (flags &amp; floatfield) != 0, or
6675 (flags &amp; floatfield) == fixed; the first gives something more or
6676 less like the effect of precision in a printf floating point
6677 conversion. Only more or less, of course. In order to implement printf
6678 formatting correctly, you must know whether the precision was
6679 explicitly set or not. Say by initializing it to -1, instead of 6, and
6680 stating that for floating point conversions, if precision &lt; -1, 6
6681 will be used, for fixed point, if precision &lt; -1, 1 will be used,
6682 etc. Plus, of course, if precision == 0 and flags &amp; floatfield ==
6683 0, 1 should be = used. But it probably isn't necessary to emulate all
6684 of the anomalies of printf:-).</p>
6685 <p><b>Proposed resolution:</b></p>
6686 <p>
6687 Replace 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, paragraph 11, with the following
6688 sentence:
6689 </p>
6690 <blockquote>
6691 For conversion from a floating-point type,
6692 <tt><i>str</i>.precision()</tt> is specified in the conversion
6693 specification.
6694 </blockquote>
6695 <p><b>Rationale:</b></p>
6696 <p>The floatfield determines whether numbers are formatted as if
6697 with %f, %e, or %g.  If the <tt>fixed</tt> bit is set, it's %f,
6698 if <tt>scientific</tt> it's %e, and if both bits are set, or
6699 neither, it's %g.</p>
6700 <p>Turning to the C standard, a precision of 0 is meaningful
6701 for %f and %e.  For %g, precision 0 is taken to be the same as
6702 precision 1.</p>
6703 <p>The proposed resolution has the effect that if neither
6704 <tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
6705 specifying a precision of 0, which will be internally
6706 turned into 1.  There's no need to call it out as a special
6707 case.</p>
6708 <p>The output of the above program will be "1e+00".</p>
6709
6710 <p><i>[Post-Curaçao: Howard provided improved wording covering the case
6711 where precision is 0 and mode is %g.]</i></p>
6712
6713 <hr>
6714 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;18 Apr 2000</p>
6715 <p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
6716 specializations of standard templates to those that "depend on a
6717 user-defined name of external linkage."</p>
6718 <p>This term, however, is not adequately defined, making it possible to
6719 construct a specialization that is, I believe, technically legal according to
6720 17.4.3.1/1, but that specializes a standard template for a built-in type such as
6721 'int'.</p>
6722 <p>The following code demonstrates the problem:</p>
6723 <blockquote>
6724   <pre>#include &lt;algorithm&gt;</pre>
6725   <pre>template&lt;class T&gt; struct X
6726 {
6727  typedef T type;
6728 };</pre>
6729   <pre>namespace std
6730 {
6731  template&lt;&gt; void swap(::X&lt;int&gt;::type&amp; i, ::X&lt;int&gt;::type&amp; j);
6732 }</pre>
6733 </blockquote>
6734 <p><b>Proposed resolution:</b></p>
6735 <p>Change "user-defined name" to "user-defined
6736 type".</p>
6737 <p><b>Rationale:</b></p>
6738 <p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
6739 Programming Language</i>.  It disallows the example in the issue,
6740 since the underlying type itself is not user-defined.  The only
6741 possible problem I can see is for non-type templates, but there's no
6742 possible way for a user to come up with a specialization for bitset,
6743 for example, that might not have already been specialized by the
6744 implementor?</p>
6745
6746 <p><i>[Toronto: this may be related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#120">120</a>.]</i></p>
6747
6748 <p><i>[post-Toronto: Judy provided the above proposed resolution and
6749 rationale.]</i></p>
6750 <hr>
6751 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;24 Apr 2000</p>
6752 <p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
6753 <tt>destruct()</tt> are described as returns but the functions actually
6754 return <tt>void</tt>.</p>
6755 <p><b>Proposed resolution:</b></p>
6756 <p>Substitute "Returns" by "Effect".</p>
6757 <hr>
6758 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;24 Apr 2000</p>
6759 <p>The declaration of <tt>reverse_iterator</tt> lists a default
6760 constructor.  However, no specification is given what this constructor
6761 should do.</p>
6762 <p><b>Proposed resolution:</b></p>
6763   <p>In section 24.4.1.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.reverse.iter.cons"> [lib.reverse.iter.cons]</a> add the following
6764   paragraph:</p>
6765       <blockquote>
6766       <p><tt>reverse_iterator()</tt></p>
6767
6768       <p>Default initializes <tt>current</tt>. Iterator operations
6769       applied to the resulting iterator have defined behavior if and
6770       only if the corresponding operations are defined on a default
6771       constructed iterator of type <tt>Iterator</tt>.</p>
6772       </blockquote>
6773   <p><i>[pre-Copenhagen: Dietmar provide wording for proposed
6774   resolution.]</i></p>
6775 <hr>
6776 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;24 Apr 2000</p>
6777 <p>The complexity specification in paragraph 6 says that the complexity
6778 is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
6779 defined on iterators this term is in general undefined because it
6780 would have to be <tt>last - first</tt>.</p>
6781 <p><b>Proposed resolution:</b></p>
6782   <p>Change paragraph 6 from</p>
6783      <blockquote>Linear in <i>first - last</i>.</blockquote>
6784   <p>to become</p>
6785      <blockquote>Linear in <i>distance(first, last)</i>.</blockquote>
6786 <hr>
6787 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;11 May 2000</p>
6788 <p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
6789 'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
6790 that far but consider this code:</p>
6791
6792 <pre>  std::basic_stringbuf&lt;char&gt; sbuf("hello, world", std::ios_base::openmode(0));
6793   std::cout &lt;&lt; "'" &lt;&lt; sbuf.str() &lt;&lt; "'\n";
6794 </pre>
6795
6796 <p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
6797 the output sequence nor the input sequence is initialized and
6798 paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
6799 returns the input or the output sequence. None of them is initialized,
6800 ie. both are empty, in which case the return from <tt>str()</tt> is
6801 defined to be <tt>basic_string&lt;cT&gt;()</tt>.</p>
6802
6803 <p>However, probably only test cases in some testsuites will detect this
6804 "problem"...</p>
6805 <p><b>Proposed resolution:</b></p>
6806 <p>Remove 27.7.1.1 paragraph 4.</p>
6807 <p><b>Rationale:</b></p>
6808 <p>We could fix 27.7.1.1 paragraph 4, but there would be no point.  If
6809 we fixed it, it would say just the same thing as text that's already
6810 in the standard.</p>
6811 <hr>
6812 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
6813 <p>The complexity of unique and unique_copy are inconsistent with each
6814 other and inconsistent with the implementations.&nbsp; The standard
6815 specifies:</p>
6816
6817 <p>for unique():</p>
6818
6819 <blockquote>-3- Complexity: If the range (last - first) is not empty, exactly
6820 (last - first) - 1 applications of the corresponding predicate, otherwise
6821 no applications of the predicate.</blockquote>
6822
6823 <p>for unique_copy():</p>
6824
6825 <blockquote>-7- Complexity: Exactly last - first applications of the corresponding
6826 predicate.</blockquote>
6827
6828 <p>
6829 The implementations do it the other way round: unique() applies the
6830 predicate last-first times and unique_copy() applies it last-first-1
6831 times.</p>
6832
6833 <p>As both algorithms use the predicate for pair-wise comparison of
6834 sequence elements I don't see a justification for unique_copy()
6835 applying the predicate last-first times, especially since it is not
6836 specified to which pair in the sequence the predicate is applied
6837 twice.</p>
6838 <p><b>Proposed resolution:</b></p>
6839 <p>Change both complexity sections in 25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> to:</p>
6840
6841 <blockquote>Complexity: For nonempty ranges, exactly last - first - 1
6842 applications of the corresponding predicate.</blockquote>
6843
6844 <hr>
6845 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
6846 <p>The complexity section of adjacent_find is defective:</p>
6847
6848 <blockquote>
6849 <pre>template &lt;class ForwardIterator&gt;
6850 ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
6851                               BinaryPredicate pred);
6852 </pre>
6853
6854 <p>-1- Returns: The first iterator i such that both i and i + 1 are in
6855 the range [first, last) for which the following corresponding
6856 conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
6857 last if no such iterator is found.</p>
6858
6859 <p>-2- Complexity: Exactly find(first, last, value) - first applications
6860 of the corresponding predicate.
6861 </p>
6862 </blockquote>
6863
6864 <p>In the Complexity section, it is not defined what "value"
6865 is supposed to mean. My best guess is that "value" means an
6866 object for which one of the conditions pred(*i,value) or
6867 pred(value,*i) is true, where i is the iterator defined in the Returns
6868 section. However, the value type of the input sequence need not be
6869 equality-comparable and for this reason the term find(first, last,
6870 value) - first is meaningless.</p>
6871
6872 <p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
6873 find_if(first, last, bind1st(pred,*i)) - first might come closer to
6874 the intended specification.  Binders can only be applied to function
6875 objects that have the function call operator declared const, which is
6876 not required of predicates because they can have non-const data
6877 members. For this reason, a specification using a binder could only be
6878 an "as-if" specification.</p>
6879 <p><b>Proposed resolution:</b></p>
6880 <p>Change the complexity section in 25.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a> to:</p>
6881 <blockquote>
6882 For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
6883 (<i>last</i> - <i>first</i>) - 1)</tt> applications of the
6884 corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
6885 return value.
6886 </blockquote>
6887
6888 <p><i>[Copenhagen: the original resolution specified an upper
6889 bound.  The LWG preferred an exact count.]</i></p>
6890
6891 <hr>
6892 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
6893
6894 <p>Some popular implementations of unique_copy() create temporary
6895 copies of values in the input sequence, at least if the input iterator
6896 is a pointer.  Such an implementation is built on the assumption that
6897 the value type is CopyConstructible and Assignable.</p>
6898
6899 <p>It is common practice in the standard that algorithms explicitly
6900 specify any additional requirements that they impose on any of the
6901 types used by the algorithm. An example of an algorithm that creates
6902 temporary copies and correctly specifies the additional requirements
6903 is accumulate(), 26.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p>
6904
6905 <p>Since the specifications of unique() and unique_copy() do not
6906 require CopyConstructible and Assignable of the InputIterator's value
6907 type the above mentioned implementations are not standard-compliant. I
6908 cannot judge whether this is a defect in the standard or a defect in
6909 the implementations.</p>
6910 <p><b>Proposed resolution:</b></p>
6911 <p>In 25.2.8 change:</p>
6912
6913 <blockquote>
6914 -4- Requires: The ranges [first, last) and [result, result+(last-first))
6915 shall not overlap.
6916 </blockquote>
6917
6918 <p>to:</p>
6919
6920 <blockquote>
6921   <p>-4- Requires: The ranges [first, last) and [result,
6922   result+(last-first)) shall not overlap. The expression *result =
6923   *first must be valid. If neither InputIterator nor OutputIterator
6924   meets the requirements of forward iterator then the value type of
6925   InputIterator must be copy constructible. Otherwise copy
6926   constructible is not required. </p>
6927 </blockquote>
6928
6929 <p><i>[Redmond: the original proposed resolution didn't impose an
6930 explicit requirement that the iterator's value type must be copy
6931 constructible, on the grounds that an input iterator's value type must
6932 always be copy constructible.  Not everyone in the LWG thought that
6933 this requirement was clear from table 72.  It has been suggested that
6934 it might be possible to implement <tt>unique_copy</tt> without
6935 requiring assignability, although current implementations do impose
6936 that requirement.  Howard provided new wording.]</i></p>
6937
6938 <p><i>[
6939 Curaçao: The LWG changed the PR editorially to specify
6940 "neither...nor...meet..." as clearer than
6941 "both...and...do not meet...". Change believed to be so
6942 minor as not to require re-review.
6943 ]</i></p>
6944
6945 <hr>
6946 <a name="242"></a><h3><a name="242">242.&nbsp;Side effects of function objects</a></h3><p><b>Section:</b>&nbsp;25.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.transform"> [lib.alg.transform]</a>, 26.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
6947 <p>The algorithms transform(), accumulate(), inner_product(),
6948 partial_sum(), and adjacent_difference() require that the function
6949 object supplied to them shall not have any side effects.</p>
6950
6951 <p>The standard defines a side effect in 1.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/intro.html#intro.execution"> [intro.execution]</a> as:</p>
6952 <blockquote>-7- Accessing an object designated by a volatile lvalue (basic.lval),
6953 modifying an object, calling a library I/O function, or calling a function
6954 that does any of those operations are all side effects, which are changes
6955 in the state of the execution environment.</blockquote>
6956
6957 <p>As a consequence, the function call operator of a function object supplied
6958 to any of the algorithms listed above cannot modify data members, cannot
6959 invoke any function that has a side effect, and cannot even create and
6960 modify temporary objects.&nbsp; It is difficult to imagine a function object
6961 that is still useful under these severe limitations. For instance, any
6962 non-trivial transformator supplied to transform() might involve creation
6963 and modification of temporaries, which is prohibited according to the current
6964 wording of the standard.</p>
6965
6966 <p>On the other hand, popular implementations of these algorithms exhibit
6967 uniform and predictable behavior when invoked with a side-effect-producing
6968 function objects. It looks like the strong requirement is not needed for
6969 efficient implementation of these algorithms.</p>
6970
6971 <p>The requirement of&nbsp; side-effect-free function objects could be
6972 replaced by a more relaxed basic requirement (which would hold for all
6973 function objects supplied to any algorithm in the standard library):</p>
6974 <blockquote>A function objects supplied to an algorithm shall not invalidate
6975 any iterator or sequence that is used by the algorithm. Invalidation of
6976 the sequence includes destruction of the sorting order if the algorithm
6977 relies on the sorting order (see section 25.3 - Sorting and related operations
6978 [lib.alg.sorting]).</blockquote>
6979
6980 <p>I can't judge whether it is intended that the function objects supplied
6981 to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
6982 shall not modify sequence elements through dereferenced iterators.</p>
6983
6984 <p>It is debatable whether this issue is a defect or a change request.
6985 Since the consequences for user-supplied function objects are drastic and
6986 limit the usefulness of the algorithms significantly I would consider it
6987 a defect.</p>
6988 <p><b>Proposed resolution:</b></p>
6989
6990 <p><i>Things to notice about these changes:</i></p>
6991
6992 <ol>
6993 <li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
6994      are intentional. we want to prevent side-effects from
6995      invalidating the end iterators.</i>
6996 </li>
6997
6998 <li> <i>That has the unintentional side-effect of prohibiting
6999      modification of the end element as a side-effect. This could
7000      conceivably be significant in some cases.</i>
7001 </li>
7002
7003 <li> <i>The wording also prevents side-effects from modifying elements
7004      of the output sequence. I can't imagine why anyone would want
7005      to do this, but it is arguably a restriction that implementors
7006      don't need to place on users.</i>
7007 </li>
7008
7009 <li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
7010      and simple, but would require more verbiage.</i>
7011 </li>
7012 </ol>
7013
7014 <p>Change 25.2.3/2 from:</p>
7015
7016 <blockquote>
7017    -2- Requires: op and binary_op shall not have any side effects.
7018 </blockquote>
7019
7020 <p>to:</p>
7021
7022 <blockquote>
7023   -2- Requires: in the ranges [first1, last1], [first2, first2 +
7024   (last1 - first1)] and [result, result + (last1- first1)], op and
7025   binary_op shall neither modify elements nor invalidate iterators or
7026   subranges.
7027   [Footnote: The use of fully closed ranges is intentional --end footnote]
7028 </blockquote>
7029
7030
7031 <p>Change 25.2.3/2 from:</p>
7032
7033 <blockquote>
7034    -2- Requires: op and binary_op shall not have any side effects.
7035 </blockquote>
7036
7037 <p>to:</p>
7038
7039 <blockquote>
7040   -2- Requires: op and binary_op shall not invalidate iterators or
7041    subranges, or modify elements in the ranges [first1, last1],
7042    [first2, first2 + (last1 - first1)], and [result, result + (last1
7043    - first1)].
7044   [Footnote: The use of fully closed ranges is intentional --end footnote]
7045 </blockquote>
7046
7047
7048 <p>Change 26.4.1/2 from:</p>
7049
7050 <blockquote>
7051   -2- Requires: T must meet the requirements of CopyConstructible
7052    (lib.copyconstructible) and Assignable (lib.container.requirements)
7053    types. binary_op shall not cause side effects.
7054 </blockquote>
7055
7056 <p>to:</p>
7057
7058 <blockquote>
7059   -2- Requires: T must meet the requirements of CopyConstructible
7060    (lib.copyconstructible) and Assignable
7061    (lib.container.requirements) types. In the range [first, last],
7062    binary_op shall neither modify elements nor invalidate iterators
7063    or subranges.
7064   [Footnote: The use of a fully closed range is intentional --end footnote]
7065 </blockquote>
7066
7067 <p>Change 26.4.2/2 from:</p>
7068
7069 <blockquote>
7070   -2- Requires: T must meet the requirements of CopyConstructible
7071    (lib.copyconstructible) and Assignable (lib.container.requirements)
7072    types. binary_op1 and binary_op2 shall not cause side effects.
7073 </blockquote>
7074
7075 <p>to:</p>
7076
7077 <blockquote>
7078   -2- Requires: T must meet the requirements of CopyConstructible
7079    (lib.copyconstructible) and Assignable (lib.container.requirements)
7080    types. In the ranges [first, last] and [first2, first2 + (last -
7081    first)], binary_op1 and binary_op2 shall neither modify elements
7082    nor invalidate iterators or subranges.
7083   [Footnote: The use of fully closed ranges is intentional --end footnote]
7084 </blockquote>
7085
7086
7087 <p>Change 26.4.3/4 from:</p>
7088
7089 <blockquote>
7090   -4- Requires: binary_op is expected not to have any side effects.
7091 </blockquote>
7092
7093 <p>to:</p>
7094
7095 <blockquote>
7096   -4- Requires: In the ranges [first, last] and [result, result +
7097    (last - first)], binary_op shall neither modify elements nor
7098    invalidate iterators or subranges.
7099   [Footnote: The use of fully closed ranges is intentional --end footnote]
7100 </blockquote>
7101
7102 <p>Change 26.4.4/2 from:</p>
7103
7104 <blockquote>
7105   -2- Requires: binary_op shall not have any side effects.
7106 </blockquote>
7107
7108 <p>to:</p>
7109
7110 <blockquote>
7111   -2- Requires: In the ranges [first, last] and [result, result +
7112    (last - first)], binary_op shall neither modify elements nor
7113    invalidate iterators or subranges.
7114   [Footnote: The use of fully closed ranges is intentional --end footnote]
7115 </blockquote>
7116
7117 <p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
7118
7119 <p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
7120 added footnotes pointing out that the use of closed ranges was
7121 intentional.]</i></p>
7122
7123 <hr>
7124 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
7125 <p>basic_istream&lt;&gt;::get(), and basic_istream&lt;&gt;::getline(),
7126 are unclear with respect to the behavior and side-effects of the named
7127 functions in case of an error.</p>
7128
7129 <p>27.6.1.3, p1 states that "... If the sentry object returns
7130 true, when converted to a value of type bool, the function endeavors
7131 to obtain the requested input..." It is not clear from this (or
7132 the rest of the paragraph) what precisely the behavior should be when
7133 the sentry ctor exits by throwing an exception or when the sentry
7134 object returns false.  In particular, what is the number of characters
7135 extracted that gcount() returns supposed to be?</p>
7136
7137 <p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
7138 "...  In any case, it then stores a null character (using
7139 charT()) into the next successive location of the array." Is not
7140 clear whether this sentence applies if either of the conditions above
7141 holds (i.e., when sentry fails).</p>
7142 <p><b>Proposed resolution:</b></p>
7143 <p>Add to 27.6.1.3, p1 after the sentence</p>
7144
7145 <blockquote>
7146 "... If the sentry object returns true, when converted to a value of
7147 type bool, the function endeavors to obtain the requested input."
7148 </blockquote>
7149
7150 <p>the following</p>
7151
7152
7153 <blockquote>
7154 "Otherwise, if the sentry constructor exits by throwing an exception or
7155 if the sentry object returns false, when converted to a value of type
7156 bool, the function returns without attempting to obtain any input. In
7157 either case the number of extracted characters is set to 0; unformatted
7158 input functions taking a character array of non-zero size as an argument
7159 shall also store a null character (using charT()) in the first location
7160 of the array."
7161 </blockquote>
7162 <p><b>Rationale:</b></p>
7163 <p>Although the general philosophy of the input functions is that the
7164 argument should not be modified upon failure, <tt>getline</tt>
7165 historically added a terminating null unconditionally.  Most
7166 implementations still do that.  Earlier versions of the draft standard
7167 had language that made this an unambiguous requirement; those words
7168 were moved to a place where their context made them less clear.  See
7169 Jerry Schwarz's message c++std-lib-7618.</p>
7170 <hr>
7171 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;22 June 2000</p>
7172 <p>There is no requirement that any of time_get member functions set
7173 ios::eofbit when they reach the end iterator while parsing their input.
7174 Since members of both the num_get and money_get facets are required to
7175 do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
7176 should follow the same requirement for consistency.</p>
7177 <p><b>Proposed resolution:</b></p>
7178 <p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
7179
7180 <blockquote>
7181 If the end iterator is reached during parsing by any of the get()
7182 member functions, the member sets ios_base::eofbit in err.
7183 </blockquote>
7184 <p><b>Rationale:</b></p>
7185 <p>Two alternative resolutions were proposed.  The LWG chose this one
7186 because it was more consistent with the way eof is described for other
7187 input facets.</p>
7188 <hr>
7189 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Brian Parker &nbsp; <b>Date:</b>&nbsp;14 Jul 2000</p>
7190 <p>
7191 Section 23.2.2.4 [lib.list.ops] states that
7192 </p>
7193 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
7194 </pre>
7195 <p>
7196 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
7197 </p>
7198
7199 <p>
7200 This is unnecessary and defeats an important feature of splice. In
7201 fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
7202 after <tt>splice</tt>.
7203 </p>
7204 <p><b>Proposed resolution:</b></p>
7205
7206 <p>Add a footnote to 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, paragraph 1:</p>
7207 <blockquote>
7208 [<i>Footnote:</i> As specified in 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, paragraphs
7209 4-5, the semantics described in this clause applies only to the case
7210 where allocators compare equal.  --end footnote]
7211 </blockquote>
7212
7213 <p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 4 with:</p>
7214 <blockquote>
7215 Effects: Inserts the contents of x before position and x becomes
7216 empty.  Pointers and references to the moved elements of x now refer to
7217 those same elements but as members of *this.  Iterators referring to the
7218 moved elements will continue to refer to their elements, but they now
7219 behave as iterators into *this, not into x.
7220 </blockquote>
7221
7222 <p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 7 with:</p>
7223 <blockquote>
7224 Effects: Inserts an element pointed to by i from list x before
7225 position and removes the element from x. The result is unchanged if
7226 position == i or position == ++i.  Pointers and references to *i continue
7227 to refer to this same element but as a member of *this.  Iterators to *i
7228 (including i itself) continue to refer to the same element, but now
7229 behave as iterators into *this, not into x.
7230 </blockquote>
7231
7232 <p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 12 with:</p>
7233 <blockquote>
7234 Requires: [first, last) is a valid range in x. The result is
7235 undefined if position is an iterator in the range [first, last).
7236 Pointers and references to the moved elements of x now refer to those
7237 same elements but as members of *this.  Iterators referring to the moved
7238 elements will continue to refer to their elements, but they now behave as
7239 iterators into *this, not into x.
7240 </blockquote>
7241
7242 <p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
7243 <p><b>Rationale:</b></p>
7244 <p>The original proposed resolution said that iterators and references
7245 would remain "valid".  The new proposed resolution clarifies what that
7246 means.  Note that this only applies to the case of equal allocators.
7247 From 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> paragraph 4, the behavior of list when
7248 allocators compare nonequal is outside the scope of the standard.</p>
7249 <hr>
7250 <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/papers/2005/lib-iostreams.html#lib.stringbuf"> [lib.stringbuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jul 2000</p>
7251 <p>The synopsis for the template class <tt>basic_stringbuf</tt>
7252 doesn't list a typedef for the template parameter
7253 <tt>Allocator</tt>. This makes it impossible to determine the type of
7254 the allocator at compile time. It's also inconsistent with all other
7255 template classes in the library that do provide a typedef for the
7256 <tt>Allocator</tt> parameter.</p>
7257 <p><b>Proposed resolution:</b></p>
7258 <p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
7259 basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and
7260 basic_stringstream (27.7.4) the typedef:</p>
7261 <pre>  typedef Allocator allocator_type;
7262 </pre>
7263 <hr>
7264 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jul 2000</p>
7265 <p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
7266 const_cast&lt;&gt; in the Returns clause for basic_istringstream&lt;&gt;::rdbuf().
7267 The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
7268 D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
7269 the cast altogether.</p>
7270
7271 <p>C-style casts have not been deprecated, so the first part of this
7272 issue is stylistic rather than a matter of correctness.</p>
7273 <p><b>Proposed resolution:</b></p>
7274 <p>In 27.7.2.2, p1 replace </p>
7275 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
7276
7277 <p>with</p>
7278 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
7279
7280
7281 <p>In 27.7.3.2, p1 replace</p>
7282 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
7283
7284 <p>with</p>
7285 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
7286
7287 <p>In 27.7.6, p1, replace</p>
7288 <pre>  -1- Returns: &amp;sb</pre>
7289
7290 <p>with</p>
7291 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
7292
7293 <p>In D.7.2.2, p1 replace</p>
7294 <pre>  -2- Returns: &amp;sb. </pre>
7295
7296 <p>with</p>
7297 <pre>  -2- Returns: const_cast&lt;strstreambuf*&gt;(&amp;sb).</pre>
7298 <hr>
7299 <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/papers/2005/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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Robert Klarer&nbsp; <b>Date:</b>&nbsp;31 Jul 2000</p>
7300 <p>This discussion is adapted from message c++std-lib-7056 posted
7301 November 11, 1999.  I don't think that anyone can reasonably claim
7302 that the problem described below is NAD.</p>
7303
7304 <p>These valarray constructors can never be called:</p>
7305
7306 <pre>   template &lt;class T&gt;
7307          valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
7308    template &lt;class T&gt;
7309          valarray&lt;T&gt;::valarray(const gslice_array&lt;T&gt; &amp;);
7310    template &lt;class T&gt;
7311          valarray&lt;T&gt;::valarray(const mask_array&lt;T&gt; &amp;);
7312    template &lt;class T&gt;
7313          valarray&lt;T&gt;::valarray(const indirect_array&lt;T&gt; &amp;);
7314 </pre>
7315
7316 <p>Similarly, these valarray assignment operators cannot be
7317 called:</p>
7318
7319 <pre>     template &lt;class T&gt;
7320      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const slice_array&lt;T&gt; &amp;);
7321      template &lt;class T&gt;
7322      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const gslice_array&lt;T&gt; &amp;);
7323      template &lt;class T&gt;
7324      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const mask_array&lt;T&gt; &amp;);
7325      template &lt;class T&gt;
7326      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const indirect_array&lt;T&gt; &amp;);
7327 </pre>
7328
7329 <p>Please consider the following example:</p>
7330
7331 <pre>   #include &lt;valarray&gt;
7332    using namespace std;
7333
7334    int main()
7335    {
7336        valarray&lt;double&gt; va1(12);
7337        valarray&lt;double&gt; va2(va1[slice(1,4,3)]); // line 1
7338    }
7339 </pre>
7340
7341
7342 <p>Since the valarray va1 is non-const, the result of the sub-expression
7343 va1[slice(1,4,3)] at line 1 is an rvalue of type const
7344 std::slice_array&lt;double&gt;.  This slice_array rvalue is then used to
7345 construct va2.  The constructor that is used to construct va2 is
7346 declared like this:</p>
7347
7348 <pre>     template &lt;class T&gt;
7349      valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
7350 </pre>
7351
7352 <p>Notice the constructor's const reference parameter.  When the
7353 constructor is called, a slice_array must be bound to this reference.
7354 The rules for binding an rvalue to a const reference are in 8.5.3,
7355 paragraph 5 (see also 13.3.3.1.4).  Specifically, paragraph 5
7356 indicates that a second slice_array rvalue is constructed (in this
7357 case copy-constructed) from the first one; it is this second rvalue
7358 that is bound to the reference parameter.  Paragraph 5 also requires
7359 that the constructor that is used for this purpose be callable,
7360 regardless of whether the second rvalue is elided.  The
7361 copy-constructor in this case is not callable, however, because it is
7362 private.  Therefore, the compiler should report an error.</p>
7363
7364 <p>Since slice_arrays are always rvalues, the valarray constructor that has a
7365 parameter of type const slice_array&lt;T&gt; &amp; can never be called.  The
7366 same reasoning applies to the three other constructors and the four
7367 assignment operators that are listed at the beginning of this post.
7368 Furthermore, since these functions cannot be called, the valarray helper
7369 classes are almost entirely useless.</p>
7370 <p><b>Proposed resolution:</b></p>
7371 <p>slice_array:</p>
7372 <ul>
7373 <li> Make the copy constructor and copy-assignment operator declarations
7374      public in the slice_array class template definition in 26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> </li>
7375 <li> remove paragraph 3 of 26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>
7376 </li>
7377 <li> remove the copy constructor declaration from 26.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a>
7378 </li>
7379 <li> change paragraph 1 of 26.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a> to read "This constructor is declared
7380     to be private.  This constructor need not be defined."</li>
7381 <li> remove the first sentence of paragraph 1 of 26.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a>
7382 </li>
7383 <li> Change the first three words of the second sentence of paragraph 1 of
7384     26.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> to "These assignment operators have"</li>
7385 </ul>
7386
7387 <p>gslice_array:</p>
7388 <ul>
7389 <li> Make the copy constructor and copy-assignment operator declarations
7390     public in the gslice_array class template definition in 26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> </li>
7391 <li> remove the note in paragraph 3 of 26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a>
7392 </li>
7393 <li> remove the copy constructor declaration from 26.3.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a>
7394 </li>
7395 <li> change paragraph 1 of 26.3.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a> to read "This constructor is declared
7396     to be private.  This constructor need not be defined."</li>
7397 <li> remove the first sentence of paragraph 1 of 26.3.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a>
7398 </li>
7399 <li> Change the first three words of the second sentence of paragraph 1 of
7400     26.3.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a> to "These assignment operators have"</li>
7401 </ul>
7402
7403 <p>mask_array:</p>
7404 <ul>
7405 <li> Make the copy constructor and copy-assignment operator declarations
7406     public in the mask_array class template definition in 26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> </li>
7407 <li> remove the note in paragraph 2 of 26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a>
7408 </li>
7409 <li> remove the copy constructor declaration from 26.3.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a>
7410 </li>
7411 <li> change paragraph 1 of 26.3.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a> to read "This constructor is declared
7412     to be private.  This constructor need not be defined."</li>
7413 <li> remove the first sentence of paragraph 1 of 26.3.8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a>
7414 </li>
7415 <li> Change the first three words of the second sentence of paragraph 1 of
7416     26.3.8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a> to "These assignment operators have"</li>
7417 </ul>
7418
7419 <p>indirect_array:</p>
7420 <ul>
7421 <li>Make the copy constructor and copy-assignment operator declarations
7422     public in the indirect_array class definition in 26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
7423 </li>
7424 <li> remove the note in paragraph 2 of 26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
7425 </li>
7426 <li> remove the copy constructor declaration from 26.3.9.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a>
7427 </li>
7428 <li> change the descriptive text in 26.3.9.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a> to read "This constructor is
7429     declared to be private.  This constructor need not be defined."</li>
7430 <li> remove the first sentence of paragraph 1 of 26.3.9.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a>
7431 </li>
7432 <li> Change the first three words of the second sentence of paragraph 1 of
7433     26.3.9.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a> to "These assignment operators have"</li>
7434 </ul>
7435 <p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
7436 copy constructor and copy assignment operators public, instead of
7437 removing them.]</i></p>
7438 <p><b>Rationale:</b></p>
7439 <p>Keeping the valarray constructors private is untenable.  Merely
7440 making valarray a friend of the helper classes isn't good enough,
7441 because access to the copy constructor is checked in the user's
7442 environment.</p>
7443
7444 <p>Making the assignment operator public is not strictly necessary to
7445 solve this problem.  A majority of the LWG <i>(straw poll: 13-4)</i>
7446 believed we should make the assignment operators public, in addition
7447 to the copy constructors, for reasons of symmetry and user
7448 expectation.</p>
7449 <hr>
7450 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;21 Aug 2000</p>
7451 <p>
7452 27.4.4.2, p17 says
7453 </p>
7454
7455 <blockquote>
7456 -17- Before copying any parts of rhs, calls each registered callback
7457 pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
7458 exceptions() have been replaced, calls each callback pair that was
7459 copied from rhs as (*fn)(copy_event,*this,index).
7460 </blockquote>
7461
7462 <p>
7463 The name copy_event isn't defined anywhere. The intended name was
7464 copyfmt_event.
7465 </p>
7466 <p><b>Proposed resolution:</b></p>
7467 <p>Replace copy_event with copyfmt_event in the named paragraph.</p>
7468 <hr>
7469 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Chris Newton &nbsp; <b>Date:</b>&nbsp;27 Aug 2000</p>
7470 <p>
7471 <i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
7472 </p>
7473
7474 <p>
7475 The standard's description of <tt>basic_string&lt;&gt;::operator[]</tt>
7476 seems to violate const correctness.
7477 </p>
7478
7479 <p>
7480 The standard (21.3.4/1) says that "If <tt>pos &lt; size()</tt>,
7481 returns <tt>data()[pos]</tt>." The types don't work.  The
7482 return value of <tt>data()</tt> is <tt>const charT*</tt>, but
7483 <tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
7484 </p>
7485 <p><b>Proposed resolution:</b></p>
7486 <p>
7487 In section 21.3.4, paragraph 1, change
7488 "<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
7489 <i>pos</i>)</tt>".
7490 </p>
7491 <hr>
7492 <a name="260"><h3>260.&nbsp;Inconsistent return type of <tt>istream_iterator::operator++(int)</tt>
7493 </h3></a><p><b>Section:</b>&nbsp;24.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Aug 2000</p>
7494 <p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
7495 it as returning the iterator by value. 24.5.1.2, p5 shows the same
7496 operator as returning the iterator by reference. That's incorrect
7497 given the Effects clause below (since a temporary is returned). The
7498 `&amp;' is probably just a typo.</p>
7499 <p><b>Proposed resolution:</b></p>
7500 <p>Change the declaration in 24.5.1.2, p5 from</p>
7501  <pre> istream_iterator&lt;T,charT,traits,Distance&gt;&amp; operator++(int);
7502  </pre>
7503 <p>to</p>
7504  <pre> istream_iterator&lt;T,charT,traits,Distance&gt; operator++(int);
7505  </pre>
7506 <p>(that is, remove the `&amp;').</p>
7507 <hr>
7508 <a name="261"><h3>261.&nbsp;Missing description of <tt>istream_iterator::operator!=</tt>
7509 </h3></a><p><b>Section:</b>&nbsp;24.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Aug 2000</p>
7510 <p>
7511 24.5.1, p3 lists the synopsis for
7512 </p>
7513
7514 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
7515         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
7516                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
7517 </pre>
7518
7519 <p>
7520 but there is no description of what the operator does (i.e., no Effects
7521 or Returns clause) in 24.5.1.2.
7522 </p>
7523 <p><b>Proposed resolution:</b></p>
7524 <p>
7525 Add paragraph 7 to the end of section 24.5.1.2 with the following text:
7526 </p>
7527
7528 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
7529         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
7530                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
7531 </pre>
7532
7533 <p>-7- Returns: !(x == y).</p>
7534 <hr>
7535 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;03 Sep 2000</p>
7536 <p>
7537 The ~ operation should be applied after the cast to int_type.
7538 </p>
7539 <p><b>Proposed resolution:</b></p>
7540 <p>
7541 Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
7542 </p>
7543
7544 <pre>   bitmask operator~ ( bitmask X )
7545      { return static_cast&lt; bitmask&gt;(static_cast&lt;int_type&gt;(~ X)); }
7546 </pre>
7547
7548 <p>
7549 to:
7550 </p>
7551
7552 <pre>   bitmask operator~ ( bitmask X )
7553      { return static_cast&lt; bitmask&gt;(~static_cast&lt;int_type&gt;(X)); }
7554 </pre>
7555 <hr>
7556 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Kevlin Henney&nbsp; <b>Date:</b>&nbsp;04 Sep 2000</p>
7557 <p>
7558 The note in paragraph 6 suggests that the invalidation rules for
7559 references, pointers, and iterators in paragraph 5 permit a reference-
7560 counted implementation (actually, according to paragraph 6, they permit
7561 a "reference counted implementation", but this is a minor editorial fix).
7562 </p>
7563
7564 <p>
7565 However, the last sub-bullet is so worded as to make a reference-counted
7566 implementation unviable. In the following example none of the
7567 conditions for iterator invalidation are satisfied:
7568 </p>
7569
7570 <pre>    // first example: "*******************" should be printed twice
7571     string original = "some arbitrary text", copy = original;
7572     const string &amp; alias = original;
7573
7574     string::const_iterator i = alias.begin(), e = alias.end();
7575     for(string::iterator j = original.begin(); j != original.end(); ++j)
7576         *j = '*';
7577     while(i != e)
7578         cout &lt;&lt; *i++;
7579     cout &lt;&lt; endl;
7580     cout &lt;&lt; original &lt;&lt; endl;
7581 </pre>
7582
7583 <p>
7584 Similarly, in the following example:
7585 </p>
7586
7587 <pre>    // second example: "some arbitrary text" should be printed out
7588     string original = "some arbitrary text", copy = original;
7589     const string &amp; alias = original;
7590
7591     string::const_iterator i = alias.begin();
7592     original.begin();
7593     while(i != alias.end())
7594         cout &lt;&lt; *i++;
7595 </pre>
7596
7597 <p>
7598 I have tested this on three string implementations, two of which were
7599 reference counted. The reference-counted implementations gave
7600 "surprising behavior" because they invalidated iterators on
7601 the first call to non-const begin since construction. The current
7602 wording does not permit such invalidation because it does not take
7603 into account the first call since construction, only the first call
7604 since various member and non-member function calls.
7605 </p>
7606 <p><b>Proposed resolution:</b></p>
7607 <p>
7608 Change the following sentence in 21.3 paragraph 5 from
7609 </p>
7610
7611 <blockquote>
7612     Subsequent to any of the above uses except the forms of insert() and
7613     erase() which return iterators, the first call to non-const member
7614     functions operator[](), at(), begin(), rbegin(), end(), or rend().
7615 </blockquote>
7616
7617 <p>to</p>
7618
7619 <blockquote>
7620     Following construction or any of the above uses, except the forms of
7621     insert() and erase() that return iterators, the first call to non-
7622     const member functions operator[](), at(), begin(), rbegin(), end(),
7623     or rend().
7624 </blockquote>
7625 <hr>
7626 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;John Potter&nbsp; <b>Date:</b>&nbsp;07 Sep 2000</p>
7627 <p>
7628 Table 69 requires linear time if [i, j) is sorted.  Sorted is necessary but not sufficient.
7629 Consider inserting a sorted range of even integers into a set&lt;int&gt; containing the odd
7630 integers in the same range.
7631 </p>
7632
7633 <p><i>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#102">102</a></i></p>
7634 <p><b>Proposed resolution:</b></p>
7635 <p>
7636 In Table 69, in section 23.1.2, change the complexity clause for
7637 insertion of a range from "N log(size() + N) (N is the distance
7638 from i to j) in general; linear if [i, j) is sorted according to
7639 value_comp()" to "N log(size() + N), where N is the distance
7640 from i to j".
7641 </p>
7642
7643 <p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
7644 parens in the revised wording.]</i></p>
7645
7646 <p><b>Rationale:</b></p>
7647 <p>
7648 Testing for valid insertions could be less efficient than simply
7649 inserting the elements when the range is not both sorted and between
7650 two adjacent existing elements; this could be a QOI issue.
7651 </p>
7652
7653 <p>
7654 The LWG considered two other options: (a) specifying that the
7655 complexity was linear if [i, j) is sorted according to value_comp()
7656 and between two adjacent existing elements; or (b) changing to
7657 Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
7658 number of elements which do not insert immediately after the previous
7659 element from [i, j) including the first).  The LWG felt that, since
7660 we can't guarantee linear time complexity whenever the range to be
7661 inserted is sorted, it's more trouble than it's worth to say that it's
7662 linear in some special cases.
7663 </p>
7664 <hr>
7665 <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/papers/2005/lib-utilities.html#lib.pairs"> [lib.pairs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;11 Sep 2000</p>
7666 <p>
7667 I don't see any requirements on the types of the elements of the
7668 std::pair container in 20.2.2. From the descriptions of the member
7669 functions it appears that they must at least satisfy the requirements of
7670 20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
7671 the case of the [in]equality operators also the requirements of 20.1.1
7672 [lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
7673 </p>
7674
7675 <p>
7676 I believe that the the CopyConstructible requirement is unnecessary in
7677 the case of 20.2.2, p2.
7678 </p>
7679 <p><b>Proposed resolution:</b></p>
7680 <p>Change the Effects clause in 20.2.2, p2 from</p>
7681
7682 <blockquote>
7683 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
7684 first(T1()), second(T2()) {} </tt>
7685 </blockquote>
7686
7687 <p>to</p>
7688
7689 <blockquote>
7690 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
7691 first(), second() {} </tt>
7692 </blockquote>
7693 <p><b>Rationale:</b></p>
7694 <p>The existing specification of pair's constructor appears to be a
7695 historical artifact: there was concern that pair's members be properly
7696 zero-initialized when they are built-in types.  At one time there was
7697 uncertainty about whether they would be zero-initialized if the
7698 default constructor was written the obvious way.  This has been
7699 clarified by core issue 178, and there is no longer any doubt that
7700 the straightforward implementation is correct.</p>
7701 <hr>
7702 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;24 Sep 2000</p>
7703 <p>
7704 The synopsis for std::bad_exception lists the function ~bad_exception()
7705 but there is no description of what the function does (the Effects
7706 clause is missing).
7707 </p>
7708 <p><b>Proposed resolution:</b></p>
7709 <p>
7710 Remove the destructor from the class synopses of
7711 <tt>bad_alloc</tt> (18.4.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.bad.alloc"> [lib.bad.alloc]</a>),
7712 <tt>bad_cast</tt> (18.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.bad.cast"> [lib.bad.cast]</a>),
7713 <tt>bad_typeid</tt> (18.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.bad.typeid"> [lib.bad.typeid]</a>),
7714 and <tt>bad_exception</tt> (18.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.bad.exception"> [lib.bad.exception]</a>).
7715 </p>
7716 <p><b>Rationale:</b></p>
7717 <p>
7718 This is a general problem with the exception classes in clause 18.
7719 The proposed resolution is to remove the destructors from the class
7720 synopses, rather than to document the destructors' behavior, because
7721 removing them is more consistent with how exception classes are
7722 described in clause 19.
7723 </p>
7724 <hr>
7725 <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/papers/2005/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Oct 2000</p>
7726 <p>The synopsis of the class std::locale in 22.1.1 contains two typos:
7727 the semicolons after the declarations of the default ctor
7728 locale::locale() and the copy ctor locale::locale(const locale&amp;)
7729 are missing.</p>
7730 <p><b>Proposed resolution:</b></p>
7731 <p>Add the missing semicolons, i.e., change</p>
7732
7733 <pre>    //  construct/copy/destroy:
7734         locale() throw()
7735         locale(const locale&amp; other) throw()
7736 </pre>
7737
7738 <p>in the synopsis in 22.1.1 to</p>
7739
7740 <pre>    //  construct/copy/destroy:
7741         locale() throw();
7742         locale(const locale&amp; other) throw();
7743 </pre>
7744 <hr>
7745 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;18 Oct 2000</p>
7746 <p>
7747 Each of the four binary search algorithms (lower_bound, upper_bound,
7748 equal_range, binary_search) has a form that allows the user to pass a
7749 comparison function object.  According to 25.3, paragraph 2, that
7750 comparison function object has to be a strict weak ordering.
7751 </p>
7752
7753 <p>
7754 This requirement is slightly too strict.  Suppose we are searching
7755 through a sequence containing objects of type X, where X is some
7756 large record with an integer key.  We might reasonably want to look
7757 up a record by key, in which case we would want to write something
7758 like this:
7759 </p>
7760 <pre>    struct key_comp {
7761       bool operator()(const X&amp; x, int n) const {
7762         return x.key() &lt; n;
7763       }
7764     }
7765
7766     std::lower_bound(first, last, 47, key_comp());
7767 </pre>
7768
7769 <p>
7770 key_comp is not a strict weak ordering, but there is no reason to
7771 prohibit its use in lower_bound.
7772 </p>
7773
7774 <p>
7775 There's no difficulty in implementing lower_bound so that it allows
7776 the use of something like key_comp.  (It will probably work unless an
7777 implementor takes special pains to forbid it.)  What's difficult is
7778 formulating language in the standard to specify what kind of
7779 comparison function is acceptable.  We need a notion that's slightly
7780 more general than that of a strict weak ordering, one that can encompass
7781 a comparison function that involves different types.  Expressing that
7782 notion may be complicated.
7783 </p>
7784
7785 <p><i>Additional questions raised at the Toronto meeting:</i></p>
7786 <ul>
7787 <li> Do we really want to specify what ordering the implementor must
7788      use when calling the function object?  The standard gives
7789      specific expressions when describing these algorithms, but it also
7790      says that other expressions (with different argument order) are
7791      equivalent.</li>
7792 <li> If we are specifying ordering, note that the standard uses both
7793      orderings when describing <tt>equal_range</tt>.</li>
7794 <li> Are we talking about requiring these algorithms to work properly
7795      when passed a binary function object whose two argument types
7796      are not the same, or are we talking about requirements when
7797      they are passed a binary function object with several overloaded
7798      versions of <tt>operator()</tt>?</li>
7799 <li> The definition of a strict weak ordering does not appear to give
7800      any guidance on issues of overloading; it only discusses expressions,
7801      and all of the values in these expressions are of the same type.
7802      Some clarification would seem to be in order.</li>
7803 </ul>
7804
7805 <p><i>Additional discussion from Copenhagen:</i></p>
7806 <ul>
7807 <li>It was generally agreed that there is a real defect here: if
7808 the predicate is merely required to be a Strict Weak Ordering, then
7809 it's possible to pass in a function object with an overloaded
7810 operator(), where the version that's actually called does something
7811 completely inappropriate.  (Such as returning a random value.)</li>
7812
7813 <li>An alternative formulation was presented in a paper distributed by
7814 David Abrahams at the meeting, "Binary Search with Heterogeneous
7815 Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
7816 predicate as a Strict Weak Ordering acting on a sorted sequence, view
7817 the predicate/value pair as something that partitions a sequence.
7818 This is almost equivalent to saying that we should view binary search
7819 as if we are given a unary predicate and a sequence, such that f(*p)
7820 is true for all p below a specific point and false for all p above it.
7821 The proposed resolution is based on that alternative formulation.</li>
7822 </ul>
7823 <p><b>Proposed resolution:</b></p>
7824
7825 <p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
7826
7827 <blockquote>
7828   3 For all algorithms that take Compare, there is a version that uses
7829   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i &lt;
7830   *j != false. For the algorithms to work correctly, comp has to
7831   induce a strict weak ordering on the values.
7832 </blockquote>
7833
7834 <p>to:</p>
7835
7836 <blockquote>
7837   3 For all algorithms that take Compare, there is a version that uses
7838   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i
7839   &lt; *j != false. For algorithms other than those described in
7840   lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
7841   a strict weak ordering on the values.
7842 </blockquote>
7843
7844 <p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
7845
7846 <blockquote>
7847   -6- A sequence [start, finish) is partitioned with respect to an
7848   expression f(e) if there exists an integer n such that
7849   for all 0 &lt;= i &lt; distance(start, finish), f(*(begin+i)) is true if
7850   and only if i &lt; n.
7851 </blockquote>
7852
7853 <p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
7854
7855 <blockquote>
7856   -1- All of the algorithms in this section are versions of binary
7857    search and assume that the sequence being searched is in order
7858    according to the implied or explicit comparison function. They work
7859    on non-random access iterators minimizing the number of
7860    comparisons, which will be logarithmic for all types of
7861    iterators. They are especially appropriate for random access
7862    iterators, because these algorithms do a logarithmic number of
7863    steps through the data structure. For non-random access iterators
7864    they execute a linear number of steps.
7865 </blockquote>
7866
7867 <p>to:</p>
7868
7869 <blockquote>
7870    -1- All of the algorithms in this section are versions of binary
7871     search and assume that the sequence being searched is partitioned
7872     with respect to an expression formed by binding the search key to
7873     an argument of the implied or explicit comparison function. They
7874     work on non-random access iterators minimizing the number of
7875     comparisons, which will be logarithmic for all types of
7876     iterators. They are especially appropriate for random access
7877     iterators, because these algorithms do a logarithmic number of
7878     steps through the data structure. For non-random access iterators
7879     they execute a linear number of steps.
7880 </blockquote>
7881
7882 <p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
7883
7884 <blockquote>
7885    -1- Requires: Type T is LessThanComparable
7886     (lib.lessthancomparable).
7887 </blockquote>
7888
7889 <p>to:</p>
7890
7891 <blockquote>
7892    -1- Requires: The elements e of [first, last) are partitioned with
7893    respect to the expression e &lt; value or comp(e, value)
7894 </blockquote>
7895
7896
7897 <p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
7898
7899 <blockquote>
7900    -2- Effects: Finds the first position into which value can be
7901     inserted without violating the ordering.
7902 </blockquote>
7903
7904 <p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
7905
7906 <blockquote>
7907   -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
7908 </blockquote>
7909
7910 <p>to:</p>
7911
7912 <blockquote>
7913    -1- Requires: The elements e of [first, last) are partitioned with
7914    respect to the expression !(value &lt; e) or !comp(value, e)
7915 </blockquote>
7916
7917 <p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
7918
7919 <blockquote>
7920    -2- Effects: Finds the furthermost position into which value can be
7921     inserted without violating the ordering.
7922 </blockquote>
7923
7924 <p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
7925
7926 <blockquote>
7927    -1- Requires: Type T is LessThanComparable
7928     (lib.lessthancomparable).
7929 </blockquote>
7930
7931 <p>to:</p>
7932
7933 <blockquote>
7934    -1- Requires: The elements e of [first, last) are partitioned with
7935    respect to the expressions e &lt; value and !(value &lt; e) or
7936    comp(e, value) and !comp(value, e).  Also, for all elements e of
7937    [first, last), e &lt; value implies !(value &lt; e) or comp(e,
7938    value) implies !comp(value, e)
7939 </blockquote>
7940
7941 <p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
7942
7943 <blockquote>
7944    -2- Effects: Finds the largest subrange [i, j) such that the value
7945     can be inserted at any iterator k in it without violating the
7946     ordering. k satisfies the corresponding conditions: !(*k &lt; value)
7947     &amp;&amp; !(value &lt; *k) or comp(*k, value) == false &amp;&amp; comp(value, *k) ==
7948     false.
7949 </blockquote>
7950
7951 <p>to:</p>
7952
7953 <pre>   -2- Returns:
7954          make_pair(lower_bound(first, last, value),
7955                    upper_bound(first, last, value))
7956        or
7957          make_pair(lower_bound(first, last, value, comp),
7958                    upper_bound(first, last, value, comp))
7959 </pre>
7960
7961 <p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
7962
7963 <blockquote>
7964    -1- Requires: Type T is LessThanComparable
7965     (lib.lessthancomparable).
7966 </blockquote>
7967
7968 <p>to:</p>
7969
7970 <blockquote>
7971    -1- Requires: The elements e of [first, last) are partitioned with
7972    respect to the expressions e &lt; value and !(value &lt; e) or comp(e,
7973    value) and !comp(value, e). Also, for all elements e of [first,
7974    last), e &lt; value implies !(value &lt; e) or comp(e, value) implies
7975    !comp(value, e)
7976 </blockquote>
7977
7978 <p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
7979
7980 <p><i>[Redmond: Minor changes in wording.  (Removed "non-negative", and
7981 changed the "other than those described in" wording.) Also, the LWG
7982 decided to accept the "optional" part.]</i></p>
7983
7984 <p><b>Rationale:</b></p>
7985 <p>The proposed resolution reinterprets binary search. Instead of
7986 thinking about searching for a value in a sorted range, we view that
7987 as an important special case of a more general algorithm: searching
7988 for the partition point in a partitioned range.</p>
7989
7990 <p>We also add a guarantee that the old wording did not: we ensure
7991 that the upper bound is no earlier than the lower bound, that
7992 the pair returned by equal_range is a valid range, and that the first
7993 part of that pair is the lower bound.</p>
7994 <hr>
7995 <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/papers/2005/lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
7996 <p>
7997 Class template basic_iostream has no typedefs.  The typedefs it
7998 inherits from its base classes can't be used, since (for example)
7999 basic_iostream&lt;T&gt;::traits_type is ambiguous.
8000 </p>
8001 <p><b>Proposed resolution:</b></p>
8002
8003 <p>Add the following to basic_iostream's class synopsis in
8004 27.6.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a>, immediately after <tt>public</tt>:</p>
8005
8006 <pre>  // types:
8007   typedef charT                     char_type;
8008   typedef typename traits::int_type int_type;
8009   typedef typename traits::pos_type pos_type;
8010   typedef typename traits::off_type off_type;
8011   typedef traits                    traits_type;
8012 </pre>
8013 <hr>
8014 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
8015 <p>
8016 27.4.4.3, p4 says about the postcondition of the function: If
8017 rdbuf()!=0 then state == rdstate(); otherwise
8018 rdstate()==state|ios_base::badbit.
8019 </p>
8020
8021 <p>
8022 The expression on the right-hand-side of the operator==() needs to be
8023 parenthesized in order for the whole expression to ever evaluate to
8024 anything but non-zero.
8025 </p>
8026 <p><b>Proposed resolution:</b></p>
8027 <p>
8028 Add parentheses like so: rdstate()==(state|ios_base::badbit).
8029 </p>
8030 <hr>
8031 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
8032 <p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
8033 27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
8034 That's incorrect since the names are members of a dependent base
8035 class (14.6.2 [temp.dep]) and thus not visible.</p>
8036 <p><b>Proposed resolution:</b></p>
8037 <p>Qualify the names with the name of the class of which they are
8038 members, i.e., ios_base.</p>
8039 <hr>
8040 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
8041 <p>
8042 I see that table 31 in 20.1.5, p3 allows T in std::allocator&lt;T&gt; to be of
8043 any type. But the synopsis in 20.4.1 calls for allocator&lt;&gt;::address() to
8044 be overloaded on reference and const_reference, which is ill-formed for
8045 all T = const U. In other words, this won't work:
8046 </p>
8047
8048 <p>
8049 template class std::allocator&lt;const int&gt;;
8050 </p>
8051
8052 <p>
8053 The obvious solution is to disallow specializations of allocators on
8054 const types. However, while containers' elements are required to be
8055 assignable (which rules out specializations on const T's), I think that
8056 allocators might perhaps be potentially useful for const values in other
8057 contexts. So if allocators are to allow const types a partial
8058 specialization of std::allocator&lt;const T&gt; would probably have to be
8059 provided.
8060 </p>
8061 <p><b>Proposed resolution:</b></p>
8062 <p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
8063
8064     <blockquote>
8065     any type
8066     </blockquote>
8067
8068 <p>to</p>
8069     <blockquote>
8070     any non-const, non-reference type
8071     </blockquote>
8072
8073 <p><i>[Redmond: previous proposed resolution was "any non-const,
8074 non-volatile, non-reference type".  Got rid of the "non-volatile".]</i></p>
8075
8076 <p><b>Rationale:</b></p>
8077 <p>
8078 Two resolutions were originally proposed: one that partially
8079 specialized std::allocator for const types, and one that said an
8080 allocator's value type may not be const.  The LWG chose the second.
8081 The first wouldn't be appropriate, because allocators are intended for
8082 use by containers, and const value types don't work in containers.
8083 Encouraging the use of allocators with const value types would only
8084 lead to unsafe code.
8085 </p>
8086 <p>
8087 The original text for proposed resolution 2 was modified so that it
8088 also forbids volatile types and reference types.
8089 </p>
8090
8091 <p><i>[Curaçao: LWG double checked and believes volatile is correctly
8092 excluded from the PR.]</i></p>
8093
8094 <hr>
8095 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
8096 <p>
8097 In 22.2.2.1.1, we have a list of overloads for num_get&lt;&gt;::get().
8098 There are eight overloads, all of which are identical except for the
8099 last parameter.  The overloads are:
8100 </p>
8101 <ul>
8102 <li> long&amp; </li>
8103 <li> unsigned short&amp; </li>
8104 <li> unsigned int&amp; </li>
8105 <li> unsigned long&amp; </li>
8106 <li> short&amp; </li>
8107 <li> double&amp; </li>
8108 <li> long double&amp; </li>
8109 <li> void*&amp; </li>
8110 </ul>
8111
8112 <p>
8113 There is a similar list, in 22.2.2.1.2, of overloads for
8114 num_get&lt;&gt;::do_get().  In this list, the last parameter has
8115 the types:
8116 </p>
8117 <ul>
8118 <li> long&amp; </li>
8119 <li> unsigned short&amp; </li>
8120 <li> unsigned int&amp; </li>
8121 <li> unsigned long&amp; </li>
8122 <li> float&amp; </li>
8123 <li> double&amp; </li>
8124 <li> long double&amp; </li>
8125 <li> void*&amp; </li>
8126 </ul>
8127
8128 <p>
8129 These two lists are not identical.  They should be, since
8130 <tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
8131 the arguments it was given.
8132 </p>
8133 <p><b>Proposed resolution:</b></p>
8134 <p>In 22.2.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>, change</p>
8135 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
8136                 ios_base::iostate&amp; err, short&amp; val) const;
8137 </pre>
8138 <p>to</p>
8139 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
8140                 ios_base::iostate&amp; err, float&amp; val) const;
8141 </pre>
8142 <hr>
8143 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;07 Nov 2000</p>
8144 <p>
8145 23.1/3 states that the objects stored in a container must be
8146 Assignable.  23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
8147 states that map satisfies all requirements for a container, while in
8148 the same time defining value_type as pair&lt;const Key, T&gt; - a type
8149 that is not Assignable.
8150 </p>
8151
8152 <p>
8153 It should be noted that there exists a valid and non-contradictory
8154 interpretation of the current text. The wording in 23.1/3 avoids
8155 mentioning value_type, referring instead to "objects stored in a
8156 container." One might argue that map does not store objects of
8157 type map::value_type, but of map::mapped_type instead, and that the
8158 Assignable requirement applies to map::mapped_type, not
8159 map::value_type.
8160 </p>
8161
8162 <p>
8163 However, this makes map a special case (other containers store objects of
8164 type value_type) and the Assignable requirement is needlessly restrictive in
8165 general.
8166 </p>
8167
8168 <p>
8169 For example, the proposed resolution of active library issue
8170 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#103">103</a> is to make set::iterator a constant iterator; this
8171 means that no set operations can exploit the fact that the stored
8172 objects are Assignable.
8173 </p>
8174
8175 <p>
8176 This is related to, but slightly broader than, closed issue
8177 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#140">140</a>.
8178 </p>
8179 <p><b>Proposed resolution:</b></p>
8180 <p>23.1/3: Strike the trailing part of the sentence:</p>
8181     <blockquote>
8182     , and the additional requirements of Assignable types from 23.1/3
8183     </blockquote>
8184 <p>so that it reads:</p>
8185     <blockquote>
8186     -3- The type of objects stored in these components must meet the
8187     requirements of CopyConstructible types (lib.copyconstructible).
8188     </blockquote>
8189
8190 <p>23.1/4: Modify to make clear that this requirement is not for all
8191 containers.  Change to:</p>
8192
8193 <blockquote>
8194 -4- Table 64 defines the Assignable requirement.  Some containers
8195 require this property of the types to be stored in the container.  T is
8196 the type used to instantiate the container. t is a value of T, and u is
8197 a value of (possibly const) T.
8198 </blockquote>
8199
8200 <p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
8201 CopyConstructible".</p>
8202
8203 <p>23.2.1/2: Add sentence for Assignable requirement.  Change to:</p>
8204
8205 <blockquote>
8206 -2- A deque satisfies all of the requirements of a container and of a
8207 reversible container (given in tables in lib.container.requirements) and
8208 of a sequence, including the optional sequence requirements
8209 (lib.sequence.reqmts).  In addition to the requirements on the stored
8210 object described in 23.1[lib.container.requirements], the stored object
8211 must also meet the requirements of Assignable.  Descriptions are
8212 provided here only for operations on deque that are not described in one
8213 of these tables or for operations where there is additional semantic
8214 information.
8215 </blockquote>
8216
8217 <p>23.2.2/2:  Add Assignable requirement to specific methods of list.
8218 Change to:</p>
8219
8220 <blockquote>
8221 <p>-2- A list satisfies all of the requirements of a container and of a
8222 reversible container (given in two tables in lib.container.requirements)
8223 and of a sequence, including most of the the optional sequence
8224 requirements (lib.sequence.reqmts). The exceptions are the operator[]
8225 and at member functions, which are not provided.
8226
8227 [Footnote: These member functions are only provided by containers whose
8228 iterators are random access iterators. --- end foonote]
8229 </p>
8230
8231 <p>list does not require the stored type T to be Assignable unless the
8232 following methods are instantiated:
8233
8234 [Footnote: Implementors are permitted but not required to take advantage
8235 of T's Assignable properties for these methods. -- end foonote]
8236 </p>
8237 <pre>     list&lt;T,Allocator&gt;&amp; operator=(const list&lt;T,Allocator&gt;&amp;  x );
8238      template &lt;class InputIterator&gt;
8239        void assign(InputIterator first, InputIterator last);
8240      void assign(size_type n, const T&amp; t);
8241 </pre>
8242
8243
8244 <p>Descriptions are provided here only for operations on list that are not
8245 described in one of these tables or for operations where there is
8246 additional semantic information.</p>
8247 </blockquote>
8248
8249 <p>23.2.4/2:   Add sentence for Assignable requirement.  Change to:</p>
8250
8251 <blockquote>
8252 -2- A vector satisfies all of the requirements of a container and of a
8253 reversible container (given in two tables in lib.container.requirements)
8254 and of a sequence, including most of the optional sequence requirements
8255 (lib.sequence.reqmts). The exceptions are the push_front and pop_front
8256 member functions, which are not provided.  In addition to the
8257 requirements on the stored object described in
8258 23.1[lib.container.requirements], the stored object must also meet the
8259 requirements of Assignable.  Descriptions are provided here only for
8260 operations on vector that are not described in one of these tables or
8261 for operations where there is additional semantic information.
8262 </blockquote>
8263 <p><b>Rationale:</b></p>
8264 <p>list, set, multiset, map, multimap are able to store non-Assignables.
8265 However, there is some concern about <tt>list&lt;T&gt;</tt>:
8266 although in general there's no reason for T to be Assignable, some
8267 implementations of the member functions <tt>operator=</tt> and
8268 <tt>assign</tt> do rely on that requirement.  The LWG does not want
8269 to forbid such implementations.</p>
8270
8271 <p>Note that the type stored in a standard container must still satisfy
8272 the requirements of the container's allocator; this rules out, for
8273 example, such types as "const int".  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#274">274</a>
8274 for more details.
8275 </p>
8276
8277 <p>In principle we could also relax the "Assignable" requirement for
8278 individual <tt>vector</tt> member functions, such as
8279 <tt>push_back</tt>.  However, the LWG did not see great value in such
8280 selective relaxation.  Doing so would remove implementors' freedom to
8281 implement <tt>vector::push_back</tt> in terms of
8282 <tt>vector::insert</tt>.</p>
8283
8284 <hr>
8285 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;P.J. Plauger&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
8286 <p>
8287 Section 23.2.2.4 [lib.list.ops] states that
8288 </p>
8289 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
8290 </pre>
8291 <p>
8292 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
8293 </p>
8294
8295 <p>
8296 But what does the C++ Standard mean by "invalidate"?  You
8297 can still dereference the iterator to a spliced list element, but
8298 you'd better not use it to delimit a range within the original
8299 list. For the latter operation, it has definitely lost some of its
8300 validity.
8301 </p>
8302
8303 <p>
8304 If we accept the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#250">250</a>,
8305 then we'd better clarify that a "valid" iterator need no
8306 longer designate an element within the same container as it once did.
8307 We then have to clarify what we mean by invalidating a past-the-end
8308 iterator, as when a vector or string grows by reallocation. Clearly,
8309 such an iterator has a different kind of validity. Perhaps we should
8310 introduce separate terms for the two kinds of "validity."
8311 </p>
8312 <p><b>Proposed resolution:</b></p>
8313 <p>Add the following text to the end of section 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>,
8314 after paragraph 5:</p>
8315 <blockquote>
8316 An <i>invalid</i> iterator is an iterator that may be
8317 singular. [Footnote: This definition applies to pointers, since
8318 pointers are iterators. The effect of dereferencing an iterator that
8319 has been invalidated is undefined.]
8320 </blockquote>
8321
8322 <p><i>[post-Copenhagen: Matt provided wording.]</i></p>
8323
8324 <p><i>[Redmond: General agreement with the intent, some objections to
8325 the wording.  Dave provided new wording.]</i></p>
8326 <p><b>Rationale:</b></p>
8327 <p>This resolution simply defines a term that the Standard uses but
8328   never defines, "invalid", in terms of a term that is defined,
8329   "singular".</p>
8330
8331 <p>Why do we say "may be singular", instead of "is singular"?  That's
8332   becuase a valid iterator is one that is known to be nonsingular.
8333   Invalidating an iterator means changing it in such a way that it's
8334   no longer known to be nonsingular.  An example: inserting an
8335   element into the middle of a vector is correctly said to invalidate
8336   all iterators pointing into the vector.  That doesn't necessarily
8337   mean they all become singular.</p>
8338 <hr>
8339 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Dec 2000</p>
8340 <p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
8341 requirements of <tt>LessThanComparable</tt> (20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>)
8342 and <tt>CopyConstructible</tt> (20.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>).
8343 Since the functions take and return their arguments and result by
8344 const reference, I believe the <tt>CopyConstructible</tt> requirement
8345 is unnecessary.
8346 </p>
8347 <p><b>Proposed resolution:</b></p>
8348 <p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
8349 25.3.7, p1 with</p>
8350 <p><b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt>
8351 (20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
8352 </p>
8353 <p>and replace 25.3.7, p4 with</p>
8354 <p><b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt>
8355 (20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
8356 </p>
8357 <hr>
8358 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;5 Dec 2000</p>
8359 <p>
8360 Paragraph 16 mistakenly singles out integral types for inserting
8361 thousands_sep() characters.  This conflicts with the syntax for floating
8362 point numbers described under 22.2.3.1/2.
8363 </p>
8364 <p><b>Proposed resolution:</b></p>
8365 <p>Change paragraph 16 from:</p>
8366
8367 <blockquote>
8368 For integral types, punct.thousands_sep() characters are inserted into
8369 the sequence as determined by the value returned by punct.do_grouping()
8370 using the method described in 22.2.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>.
8371 </blockquote>
8372
8373 <p>To:</p>
8374
8375 <blockquote>
8376 For arithmetic types, punct.thousands_sep() characters are inserted into
8377 the sequence as determined by the value returned by punct.do_grouping()
8378 using the method described in 22.2.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>.
8379 </blockquote>
8380
8381 <p><i>[
8382 Copenhagen: Opinions were divided about whether this is actually an
8383 inconsistency, but at best it seems to have been unintentional.  This
8384 is only an issue for floating-point output: The standard is
8385 unambiguous that implementations must parse thousands_sep characters
8386 when performing floating-point.  The standard is also unambiguous that
8387 this requirement does not apply to the "C" locale.
8388 ]</i></p>
8389
8390 <p><i>[
8391 A survey of existing practice is needed; it is believed that some
8392 implementations do insert thousands_sep characters for floating-point
8393 output and others fail to insert thousands_sep characters for
8394 floating-point input even though this is unambiguously required by the
8395 standard.
8396 ]</i></p>
8397
8398 <p><i>[Post-Curaçao: the above proposed resolution is the consensus of
8399 Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
8400
8401 <hr>
8402 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Dec 2000</p>
8403 <p>
8404 (revision of the further discussion)
8405 There are a number of problems with the requires clauses for the
8406 algorithms in 25.1 and 25.2. The requires clause of each algorithm
8407 should describe the necessary and sufficient requirements on the inputs
8408 to the algorithm such that the algorithm compiles and runs properly.
8409 Many of the requires clauses fail to do this. Here is a summary of the kinds
8410 of mistakes:
8411 </p>
8412
8413 <ol>
8414 <li>
8415 Use of EqualityComparable, which only puts requirements on a single
8416 type, when in fact an equality operator is required between two
8417 different types, typically either T and the iterator's value type
8418 or between the value types of two different iterators.
8419 </li>
8420 <li>
8421 Use of Assignable for T when in fact what was needed is Assignable
8422 for the value_type of the iterator, and convertability from T to the
8423 value_type of the iterator. Or for output iterators, the requirement
8424 should be that T is writable to the iterator (output iterators do
8425 not have value types).
8426 </li>
8427 </ol>
8428
8429 <p>
8430 Here is the list of algorithms that contain mistakes:
8431 </p>
8432
8433 <ul>
8434 <li>25.1.2 std::find</li>
8435 <li>25.1.6 std::count</li>
8436 <li>25.1.8 std::equal</li>
8437 <li>25.1.9 std::search, std::search_n</li>
8438 <li>25.2.4 std::replace, std::replace_copy</li>
8439 <li>25.2.5 std::fill</li>
8440 <li>25.2.7 std::remove, std::remove_copy</li>
8441 </ul>
8442
8443 <p>
8444 Also, in the requirements for EqualityComparable, the requirement that
8445 the operator be defined for const objects is lacking.
8446 </p>
8447
8448 <p><b>Proposed resolution:</b></p>
8449
8450 <p>20.1.1 Change p1 from</p>
8451
8452 <p>In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
8453 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
8454 values of type <tt>T</tt>.
8455 </p>
8456
8457 <p>to</p>
8458
8459 <p>
8460 In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
8461 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
8462 values of type <tt>const T</tt>.
8463 </p>
8464
8465 <p>25 Between p8 and p9</p>
8466
8467 <p>Add the following sentence:</p>
8468
8469 <p>When the description of an algorithm gives an expression such as
8470 <tt>*first == value</tt> for a condition, it is required that the expression
8471 evaluate to either true or false in boolean contexts.</p>
8472
8473 <p>25.1.2 Change p1 by deleting the requires clause.</p>
8474
8475 <p>25.1.6 Change p1 by deleting the requires clause.</p>
8476
8477 <p>25.1.9</p>
8478
8479 <p>Change p4 from</p>
8480
8481 <p>-4- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt>
8482 (20.1.1), type Size is convertible to integral type (4.7.12.3).
8483 </p>
8484
8485 <p>to</p>
8486
8487 <p>-4- Requires: The type <tt>Size</tt> is convertible to integral
8488 type (4.7.12.3).</p>
8489
8490 <p>25.2.4 Change p1 from</p>
8491
8492 <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>
8493
8494 <p>to</p>
8495
8496 <p>-1- Requires: The expression <tt>*first = new_value</tt> must be valid.</p>
8497
8498 <p>and change p4 from</p>
8499
8500 <p>-4- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1) (and,
8501 for <tt>replace_copy()</tt>, <tt>EqualityComparable</tt>
8502 (20.1.1)). The ranges <tt>[first, last)</tt> and <tt>[result, result +
8503 (last - first))</tt> shall not overlap.</p>
8504
8505 <p>to</p>
8506
8507 <p>-4- Requires: The results of the expressions <tt>*first</tt> and
8508 <tt>new_value</tt> must be writable to the result output iterator. The
8509 ranges <tt>[first, last)</tt> and <tt>[result, result + (last -
8510 first))</tt> shall not overlap.</p>
8511
8512
8513 <p>25.2.5 Change p1 from</p>
8514
8515 <p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1). The
8516 type <tt>Size</tt> is convertible to an integral type (4.7.12.3).</p>
8517
8518 <p>to</p>
8519
8520 <p>-1- Requires: The expression <tt>value</tt> must be is writable to
8521 the output iterator. The type <tt>Size</tt> is convertible to an
8522 integral type (4.7.12.3).</p>
8523
8524 <p>25.2.7 Change p1 from</p>
8525
8526 <p>-1- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> (20.1.1).</p>
8527
8528 <p>to</p>
8529
8530 <p>
8531 -1- Requires: The value type of the iterator must be
8532 <tt>Assignable</tt> (23.1).
8533 </p>
8534
8535 <p><b>Rationale:</b></p>
8536 <p>
8537 The general idea of the proposed solution is to remove the faulty
8538 requires clauses and let the returns and effects clauses speak for
8539 themselves. That is, the returns clauses contain expressions that must
8540 be valid, and therefore already imply the correct requirements. In
8541 addition, a sentence is added at the beginning of chapter 25 saying
8542 that expressions given as conditions must evaluate to true or false in
8543 a boolean context. An alternative would be to say that the type of
8544 these condition expressions must be literally bool, but that would be
8545 imposing a greater restriction that what the standard currently says
8546 (which is convertible to bool).
8547 </p>
8548 <hr>
8549 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;26 Dec 2000</p>
8550 <p>The example in 20.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a>, p6 shows how to use the C
8551 library function <tt>strcmp()</tt> with the function pointer adapter
8552 <tt>ptr_fun()</tt>. But since it's unspecified whether the C library
8553 functions have <tt>extern "C"</tt> or <tt>extern
8554 "C++"</tt> linkage [17.4.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a>], and since
8555 function pointers with different the language linkage specifications
8556 (7.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/dcl.html#dcl.link"> [dcl.link]</a>) are incompatible, whether this example is
8557 well-formed is unspecified.
8558 </p>
8559 <p><b>Proposed resolution:</b></p>
8560 <p>Change 20.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a> paragraph 6 from:</p>
8561 <blockquote>
8562   <p>[<i>Example:</i></p>
8563   <pre>    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
8564   </pre>
8565   <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
8566 </blockquote>
8567
8568
8569 <p>to:</p>
8570 <blockquote>
8571   <p>[<i>Example:</i></p>
8572   <pre>    int compare(const char*, const char*);
8573     replace_if(v.begin(), v.end(),
8574                not1(bind2nd(ptr_fun(compare), "abc")), "def");
8575   </pre>
8576   <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
8577 </blockquote>
8578
8579 <p>Also, remove footnote 215 in that same paragraph.</p>
8580
8581 <p><i>[Copenhagen: Minor change in the proposed resolution.  Since this
8582 issue deals in part with C and C++ linkage, it was believed to be too
8583 confusing for the strings in the example to be "C" and "C++".
8584 ]</i></p>
8585
8586 <p><i>[Redmond: More minor changes.  Got rid of the footnote (which
8587 seems to make a sweeping normative requirement, even though footnotes
8588 aren't normative), and changed the sentence after the footnote so that
8589 it corresponds to the new code fragment.]</i></p>
8590
8591 <hr>
8592 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;31 Dec 2000</p>
8593 <p>27.8.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-iostreams.html#lib.ofstream.cons"> [lib.ofstream.cons]</a>, p2, and
8594 27.8.1.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.fstream.cons"> [lib.fstream.cons]</a>, p2 say about the effects of each constructor:
8595 </p>
8596
8597 <p>... If that function returns a null pointer, calls
8598 <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
8599 </p>
8600
8601 <p>The parenthetical note doesn't apply since the ctors cannot throw an
8602 exception due to the requirement in 27.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>, p3
8603 that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
8604 </p>
8605 <p><b>Proposed resolution:</b></p>
8606 <p>
8607 Strike the parenthetical note from the Effects clause in each of the
8608 paragraphs mentioned above.
8609 </p>
8610 <hr>
8611 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;30 Dec 2000</p>
8612 <p>
8613 The &lt;cstdlib&gt; header file contains prototypes for bsearch and
8614 qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
8615 prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
8616 require the typedef size_t. Yet size_t is not listed in the
8617 &lt;cstdlib&gt; synopsis table 78 in section 25.4.
8618 </p>
8619 <p><b>Proposed resolution:</b></p>
8620 <p>
8621 Add the type size_t to Table 78 (section 25.4) and add
8622 the type size_t &lt;cstdlib&gt; to Table 97 (section C.2).
8623 </p>
8624 <p><b>Rationale:</b></p>
8625 <p>Since size_t is in &lt;stdlib.h&gt;, it must also be in &lt;cstdlib&gt;.</p>
8626 <hr>
8627 <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/papers/2005/lib-diagnostics.html#lib.errno"> [lib.errno]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;30 Dec 2000</p>
8628 <p>
8629 ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
8630 of macros defined in &lt;errno.h&gt; is adjusted to include a new
8631 macro, EILSEQ"
8632 </p>
8633
8634 <p>
8635 ISO/IEC 14882:1998(E) section 19.3 does not refer
8636 to the above amendment.
8637 </p>
8638
8639 <p><b>Proposed resolution:</b></p>
8640 <p>
8641 Update Table 26 (section 19.3) "Header  &lt;cerrno&gt; synopsis"
8642 and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
8643 </p>
8644 <hr>
8645 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;03 Jan 2001</p>
8646 <p>
8647 The standard library contains four algorithms that compute set
8648 operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
8649 <tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>.  Each
8650 of these algorithms takes two sorted ranges as inputs, and writes the
8651 output of the appropriate set operation to an output range.  The elements
8652 in the output range are sorted.
8653 </p>
8654
8655 <p>
8656 The ordinary mathematical definitions are generalized so that they
8657 apply to ranges containing multiple copies of a given element.  Two
8658 elements are considered to be "the same" if, according to an
8659 ordering relation provided by the user, neither one is less than the
8660 other.  So, for example, if one input range contains five copies of an
8661 element and another contains three, the output range of <tt>set_union</tt>
8662 will contain five copies, the output range of
8663 <tt>set_intersection</tt> will contain three, the output range of
8664 <tt>set_difference</tt> will contain two, and the output range of
8665 <tt>set_symmetric_difference</tt> will contain two.
8666 </p>
8667
8668 <p>
8669 Because two elements can be "the same" for the purposes
8670 of these set algorithms, without being identical in other respects
8671 (consider, for example, strings under case-insensitive comparison),
8672 this raises a number of unanswered questions:
8673 </p>
8674
8675 <ul>
8676 <li>If we're copying an element that's present in both of the
8677 input ranges, which one do we copy it from?</li>
8678 <li>If there are <i>n</i> copies of an element in the relevant
8679 input range, and the output range will contain fewer copies (say
8680 <i>m</i>) which ones do we choose?  The first <i>m</i>, or the last
8681 <i>m</i>, or something else?</li>
8682 <li>Are these operations stable?  That is, does a run of equivalent
8683 elements appear in the output range in the same order as as it
8684 appeared in the input range(s)?</li>
8685 </ul>
8686
8687 <p>
8688 The standard should either answer these questions, or explicitly
8689 say that the answers are unspecified.  I prefer the former option,
8690 since, as far as I know, all existing implementations behave the
8691 same way.
8692 </p>
8693
8694 <p><b>Proposed resolution:</b></p>
8695
8696 <p>Add the following to the end of 25.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.set.union"> [lib.set.union]</a> paragraph 5:</p>
8697 <blockquote>
8698 If [first1, last1) contains <i>m</i> elements that are equivalent to
8699 each other and [first2, last2) contains <i>n</i> elements that are
8700 equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
8701 will be copied to the output range: all <i>m</i> of these elements
8702 from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
8703 [first2, last2), in that order.
8704 </blockquote>
8705
8706 <p>Add the following to the end of 25.3.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.set.intersection"> [lib.set.intersection]</a> paragraph 5:</p>
8707 <blockquote>
8708 If [first1, last1) contains <i>m</i> elements that are equivalent to each
8709 other and [first2, last2) contains <i>n</i> elements that are
8710 equivalent to them, the first min(<i>m</i>, <i>n</i>) of those
8711 elements from [first1, last1) are copied to the output range.
8712 </blockquote>
8713
8714 <p>Add a new paragraph, <b>Notes</b>, after 25.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.set.difference"> [lib.set.difference]</a>
8715 paragraph 4:</p>
8716 <blockquote>
8717 If [first1, last1) contains <i>m</i> elements that are equivalent to each
8718 other and [first2, last2) contains <i>n</i> elements that are
8719 equivalent to them, the last max(<i>m-n</i>, 0) elements from
8720 [first1, last1) are copied to the output range.
8721 </blockquote>
8722
8723 <p>Add a new paragraph, <b>Notes</b>, after 25.3.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.set.symmetric.difference"> [lib.set.symmetric.difference]</a>
8724 paragraph 4:</p>
8725 <blockquote>
8726 If [first1, last1) contains <i>m</i> elements that are equivalent to
8727 each other and [first2, last2) contains <i>n</i> elements that are
8728 equivalent to them, then |<i>m - n</i>| of those elements will be
8729 copied to the output range: the last <i>m - n</i> of these elements
8730 from [first1, last1) if <i>m</i> &gt; <i>n</i>, and the last <i>n -
8731 m</i> of these elements from [first2, last2) if <i>m</i> &lt; <i>n</i>.
8732 </blockquote>
8733
8734 <p><i>[Santa Cruz: it's believed that this language is clearer than
8735   what's in the Standard.  However, it's also believed that the
8736   Standard may already make these guarantees (although not quite in
8737   these words).  Bill and Howard will check and see whether they think
8738   that some or all of these changes may be redundant.  If so, we may
8739   close this issue as NAD.]</i></p>
8740
8741 <p><b>Rationale:</b></p>
8742 <p>For simple cases, these descriptions are equivalent to what's
8743   already in the Standard.  For more complicated cases, they describe
8744   the behavior of existing implementations.</p>
8745 <hr>
8746 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;05 Jan 2001</p>
8747 <p>The Effects clause of the member function <tt>copyfmt()</tt> in
8748 27.4.4.2, p15 doesn't consider the case where the left-hand side
8749 argument is identical to the argument on the right-hand side, that is
8750 <tt>(this == &amp;rhs)</tt>.  If the two arguments are identical there
8751 is no need to copy any of the data members or call any callbacks
8752 registered with <tt>register_callback()</tt>.  Also, as Howard Hinnant
8753 points out in message c++std-lib-8149 it appears to be incorrect to
8754 allow the object to fire <tt>erase_event</tt> followed by
8755 <tt>copyfmt_event</tt> since the callback handling the latter event
8756 may inadvertently attempt to access memory freed by the former.
8757 </p>
8758 <p><b>Proposed resolution:</b></p>
8759 <p>Change the Effects clause in 27.4.4.2, p15 from</p>
8760
8761 <blockquote>
8762 <b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
8763 the corresponding member objects of <tt>rhs</tt>, except that...
8764 </blockquote>
8765
8766 <p>to</p>
8767
8768 <blockquote>
8769 <b>-15- Effects:</b>If <tt>(this == &amp;rhs)</tt> does nothing. Otherwise
8770 assigns to the member objects of <tt>*this</tt> the corresponding member
8771 objects of <tt>rhs</tt>, except that...
8772 </blockquote>
8773 <hr>
8774 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Jens Maurer&nbsp; <b>Date:</b>&nbsp;12 Jan 2001</p>
8775 <p>
8776 Table 80 lists the contents of the &lt;cmath&gt; header.  It does not
8777 list <tt>abs()</tt>.  However, 26.5, paragraph 6, which lists added
8778 signatures present in &lt;cmath&gt;, does say that several overloads
8779 of <tt>abs()</tt> should be defined in &lt;cmath&gt;.
8780 </p>
8781 <p><b>Proposed resolution:</b></p>
8782 <p>
8783 Add <tt>abs</tt> to Table 80.  Also, remove the parenthetical list
8784 of functions "(abs(), div(), rand(), srand())" from 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.c.math"> [lib.c.math]</a>,
8785 paragraph 1.
8786 </p>
8787
8788 <p><i>[Copenhagen: Modified proposed resolution so that it also gets
8789 rid of that vestigial list of functions in paragraph 1.]</i></p>
8790
8791 <p><b>Rationale:</b></p>
8792 <p>All this DR does is fix a typo; it's uncontroversial.  A
8793 separate question is whether we're doing the right thing in
8794 putting some overloads in &lt;cmath&gt; that we aren't also
8795 putting in &lt;cstdlib&gt;.  That's issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#323">323</a>.</p>
8796 <hr>
8797 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Jan 2001</p>
8798 <p>The class templates <tt>const_mem_fun_t</tt> in 20.3.8, p8 and
8799 <tt>const_mem_fun1_t</tt>
8800 in 20.3.8, p9 derive from <tt>unary_function&lt;T*, S&gt;</tt>, and
8801 <tt>binary_function&lt;T*,
8802 A, S&gt;</tt>, respectively. Consequently, their <tt>argument_type</tt>, and
8803 <tt>first_argument_type</tt>
8804 members, respectively, are both defined to be <tt>T*</tt> (non-const).
8805 However, their function call member operator takes a <tt>const T*</tt>
8806 argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
8807 T*</tt> instead, so that one can easily refer to it in generic code. The
8808 example below derived from existing code fails to compile due to the
8809 discrepancy:
8810 </p>
8811
8812 <p><tt>template &lt;class T&gt;</tt>
8813 <br><tt>void foo (typename T::argument_type arg)&nbsp;&nbsp; // #1</tt>
8814 <br><tt>{</tt>
8815 <br><tt>&nbsp;&nbsp;&nbsp; typename T::result_type (T::*pf) (typename
8816 T::argument_type)
8817 const =&nbsp;&nbsp; // #2</tt>
8818 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;T::operator();</tt>
8819 <br><tt>}</tt>
8820 </p>
8821
8822 <p><tt>struct X { /* ... */ };</tt></p>
8823
8824 <p><tt>int main ()</tt>
8825 <br><tt>{</tt>
8826 <br><tt>&nbsp;&nbsp;&nbsp; const X x;</tt>
8827 <br><tt>&nbsp;&nbsp;&nbsp; foo&lt;std::const_mem_fun_t&lt;void, X&gt;
8828 &gt;(&amp;x);&nbsp;&nbsp;
8829 // #3</tt>
8830 <br><tt>}</tt>
8831 </p>
8832
8833 <p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
8834 <br>#2 the type of the pointer is incompatible with the type of the member
8835 function
8836 <br>#3 the address of a constant being passed to a function taking a non-const
8837 <tt>X*</tt>
8838 </p>
8839 <p><b>Proposed resolution:</b></p>
8840 <p>Replace the top portion of the definition of the class template
8841 const_mem_fun_t in 20.3.8, p8
8842 </p>
8843 <p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
8844 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
8845 unary_function&lt;T*, S&gt; {</tt>
8846 </p>
8847 <p>with</p>
8848 <p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
8849 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
8850 unary_function&lt;<b>const</b> T*, S&gt; {</tt>
8851 </p>
8852 <p>Also replace the top portion of the definition of the class template
8853 const_mem_fun1_t in 20.3.8, p9</p>
8854 <p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
8855 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
8856 binary_function&lt;T*, A, S&gt; {</tt>
8857 </p>
8858 <p>with</p>
8859 <p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
8860 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
8861 binary_function&lt;<b>const</b> T*, A, S&gt; {</tt>
8862 </p>
8863 <p><b>Rationale:</b></p>
8864 <p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
8865 and the argument type itself, are not the same.</p>
8866 <hr>
8867 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;John A. Pedretti&nbsp; <b>Date:</b>&nbsp;10 Jan 2001</p>
8868 <p>
8869 The default behavior of <tt>operator delete[]</tt> described in 18.4.1.2, p12 -
8870 namely that for non-null value of <i>ptr</i>, the operator reclaims storage
8871 allocated by the earlier call to the default <tt>operator new[]</tt> - is not
8872 correct in all cases. Since the specified <tt>operator new[]</tt> default
8873 behavior is to call <tt>operator new</tt> (18.4.1.2, p4, p8), which can be
8874 replaced, along with <tt>operator delete</tt>, by the user, to implement their
8875 own memory management, the specified default behavior of<tt> operator
8876 delete[]</tt> must be to call <tt>operator delete</tt>.
8877 </p>
8878 <p><b>Proposed resolution:</b></p>
8879 <p>Change 18.4.1.2, p12 from</p>
8880 <blockquote>
8881 <b>-12-</b> <b>Default behavior:</b>
8882 <ul>
8883 <li>
8884 For a null value of <i><tt>ptr</tt></i> , does nothing.
8885 </li>
8886 <li>
8887 Any other value of <i><tt>ptr</tt></i> shall be a value returned
8888 earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
8889 [Footnote: The value must not have been invalidated by an intervening
8890 call to <tt>operator delete[](void*)</tt> (17.4.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.res.on.arguments"> [lib.res.on.arguments]</a>).
8891 --- end footnote]
8892 For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
8893 allocated by the earlier call to the default <tt>operator new[]</tt>.
8894 </li>
8895 </ul>
8896 </blockquote>
8897
8898 <p>to</p>
8899
8900 <blockquote>
8901 <b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
8902 delete(</tt><i>ptr</i>)
8903 or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
8904 </blockquote>
8905 <p>and expunge paragraph 13.</p>
8906 <hr>
8907 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;John Pedretti&nbsp; <b>Date:</b>&nbsp;23 Jan 2001</p>
8908 <p>
8909 The "Effects" clause for list::merge() (23.2.2.4, p23)
8910 appears to be incomplete: it doesn't cover the case where the argument
8911 list is identical to *this (i.e., this == &amp;x). The requirement in the
8912 note in p24 (below) is that x be empty after the merge which is surely
8913 unintended in this case.
8914 </p>
8915 <p><b>Proposed resolution:</b></p>
8916 <p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraps 23-25 with:</p>
8917 <blockquote>
8918 <p>
8919 23 Effects: if (&amp;x == this) does nothing; otherwise, merges the two
8920 sorted ranges [begin(), end()) and [x.begin(), x.end()).  The result
8921 is a range in which the elements will be sorted in non-decreasing
8922 order according to the ordering defined by comp; that is, for every
8923 iterator i in the range other than the first, the condition comp(*i,
8924 *(i - 1)) will be false.
8925 </p>
8926
8927 <p>
8928 24 Notes: Stable: if (&amp;x != this), then for equivalent elements in the
8929 two original ranges, the elements from the original range [begin(),
8930 end()) always precede the elements from the original range [x.begin(),
8931 x.end()).  If (&amp;x != this) the range [x.begin(), x.end()) is empty
8932 after the merge.
8933 </p>
8934
8935 <p>
8936 25 Complexity: At most size() + x.size() - 1 applications of comp if
8937 (&amp;x !  = this); otherwise, no applications of comp are performed.  If
8938 an exception is thrown other than by a comparison there are no
8939 effects.
8940 </p>
8941
8942 </blockquote>
8943
8944 <p><i>[Copenhagen: The original proposed resolution did not fix all of
8945 the problems in 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, p22-25.  Three different
8946 paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
8947 Changing p23, without changing the other two, appears to introduce
8948 contradictions.  Additionally, "merges the argument list into the
8949 list" is excessively vague.]</i></p>
8950
8951 <p><i>[Post-Curaçao: Robert Klarer provided new wording.]</i></p>
8952
8953 <hr>
8954 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Jan 2001</p>
8955 <p>
8956 The effects clause for the basic_string template ctor in 21.3.1, p15
8957 leaves out the third argument of type Allocator. I believe this to be
8958 a mistake.
8959 </p>
8960 <p><b>Proposed resolution:</b></p>
8961 <p>Replace</p>
8962
8963 <blockquote>
8964     <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
8965     type, equivalent to</p>
8966
8967     <blockquote><tt>basic_string(static_cast&lt;size_type&gt;(begin),
8968     static_cast&lt;value_type&gt;(end))</tt></blockquote>
8969 </blockquote>
8970
8971 <p>with</p>
8972
8973 <blockquote>
8974     <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
8975     type, equivalent to</p>
8976
8977     <blockquote><tt>basic_string(static_cast&lt;size_type&gt;(begin),
8978     static_cast&lt;value_type&gt;(end), <b>a</b>)</tt></blockquote>
8979 </blockquote>
8980 <hr>
8981 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;5 Feb 2001</p>
8982 <p>
8983 In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
8984 "Extracts up to <i>N</i> (single-byte) characters from
8985 <i>is</i>.", where <i>is</i> is a stream of type
8986 <tt>basic_istream&lt;charT, traits&gt;</tt>.
8987 </p>
8988
8989 <p>
8990 The standard does not say what it means to extract single byte
8991 characters from a stream whose character type, <tt>charT</tt>, is in
8992 general not a single-byte character type.  Existing implementations
8993 differ.
8994 </p>
8995
8996 <p>
8997 A reasonable solution will probably involve <tt>widen()</tt> and/or
8998 <tt>narrow()</tt>, since they are the supplied mechanism for
8999 converting a single character between <tt>char</tt> and
9000 arbitrary <tt>charT</tt>.
9001 </p>
9002
9003 <p>Narrowing the input characters is not the same as widening the
9004 literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
9005 locales in which more than one wide character maps to the narrow
9006 character <tt>'0'</tt>.  Narrowing means that alternate
9007 representations may be used for bitset input, widening means that
9008 they may not be.</p>
9009
9010 <p>Note that for numeric input, <tt>num_get&lt;&gt;</tt>
9011 (22.2.2.1.2/8) compares input characters to widened version of narrow
9012 character literals.</p>
9013
9014 <p>From Pete Becker, in c++std-lib-8224:</p>
9015 <blockquote>
9016 <p>
9017 Different writing systems can have different representations for the
9018 digits that represent 0 and 1. For example, in the Unicode representation
9019 of the Devanagari script (used in many of the Indic languages) the digit 0
9020 is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
9021 into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
9022 0x0031 for for the Latin representations of '0' and '1', as well as code
9023 points for the same numeric values in several other scripts (Tamil has no
9024 character for 0, but does have the digits 1-9), and any of these values
9025 would also be narrowed to '0' and '1'.
9026 </p>
9027
9028 <p>...</p>
9029
9030 <p>
9031 It's fairly common to intermix both native and Latin
9032 representations of numbers in a document. So I think the rule has to be
9033 that if a wide character represents a digit whose value is 0 then the bit
9034 should be cleared; if it represents a digit whose value is 1 then the bit
9035 should be set; otherwise throw an exception. So in a Devanagari locale,
9036 both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
9037 would set it. Widen can't do that. It would pick one of those two values,
9038 and exclude the other one.
9039 </p>
9040
9041 </blockquote>
9042
9043 <p>From Jens Maurer, in c++std-lib-8233:</p>
9044
9045 <blockquote>
9046 <p>
9047 Whatever we decide, I would find it most surprising if
9048 bitset conversion worked differently from int conversion
9049 with regard to alternate local representations of
9050 numbers.
9051 </p>
9052
9053 <p>Thus, I think the options are:</p>
9054 <ul>
9055  <li> Have a new defect issue for 22.2.2.1.2/8 so that it will
9056 require the use of narrow().</li>
9057
9058  <li> Have a defect issue for bitset() which describes clearly
9059 that widen() is to be used.</li>
9060 </ul>
9061 </blockquote>
9062 <p><b>Proposed resolution:</b></p>
9063
9064     <p>Replace the first two sentences of paragraph 5 with:</p>
9065
9066     <blockquote>
9067     Extracts up to <i>N</i> characters from <i>is</i>. Stores these
9068     characters in a temporary object <i>str</i> of type
9069     <tt>basic_string&lt;charT, traits&gt;</tt>, then evaluates the
9070     expression <tt><i>x</i> = bitset&lt;N&gt;(<i>str</i>)</tt>.
9071     </blockquote>
9072
9073     <p>Replace the third bullet item in paragraph 5 with:</p>
9074     <ul><li>
9075     the next input character is neither <tt><i>is</i>.widen(0)</tt>
9076     nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
9077     is not extracted).
9078     </li></ul>
9079
9080 <p><b>Rationale:</b></p>
9081 <p>Input for <tt>bitset</tt> should work the same way as numeric
9082 input.  Using <tt>widen</tt> does mean that alternative digit
9083 representations will not be recognized, but this was a known
9084 consequence of the design choice.</p>
9085 <hr>
9086 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;24 Jan 2001</p>
9087 <p>22.2.1.5/3 introduces codecvt in part with:</p>
9088
9089 <blockquote>
9090   codecvt&lt;wchar_t,char,mbstate_t&gt; converts between the native
9091   character sets for tiny and wide characters. Instantiations on
9092   mbstate_t perform conversion between encodings known to the library
9093   implementor.
9094 </blockquote>
9095
9096 <p>But 22.2.1.5.2/10 describes do_length in part with:</p>
9097
9098 <blockquote>
9099   ... codecvt&lt;wchar_t, char, mbstate_t&gt; ... return(s) the lesser of max and
9100   (from_end-from).
9101 </blockquote>
9102
9103 <p>
9104 The semantics of do_in and do_length are linked.  What one does must
9105 be consistent with what the other does.  22.2.1.5/3 leads me to
9106 believe that the vendor is allowed to choose the algorithm that
9107 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in performs so that it makes
9108 his customers happy on a given platform.  But 22.2.1.5.2/10 explicitly
9109 says what codecvt&lt;wchar_t,char,mbstate_t&gt;::do_length must
9110 return.  And thus indirectly specifies the algorithm that
9111 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in must perform.  I believe
9112 that this is not what was intended and is a defect.
9113 </p>
9114
9115 <p>Discussion from the -lib reflector:
9116
9117 <br>This proposal would have the effect of making the semantics of
9118 all of the virtual functions in <tt>codecvt&lt;wchar_t, char,
9119 mbstate_t&gt;</tt> implementation specified.  Is that what we want, or
9120 do we want to mandate specific behavior for the base class virtuals
9121 and leave the implementation specified behavior for the codecvt_byname
9122 derived class?  The tradeoff is that former allows implementors to
9123 write a base class that actually does something useful, while the
9124 latter gives users a way to get known and specified---albeit
9125 useless---behavior, and is consistent with the way the standard
9126 handles other facets.  It is not clear what the original intention
9127 was.</p>
9128
9129 <p>
9130 Nathan has suggest a compromise: a character that is a widened version
9131 of the characters in the basic execution character set must be
9132 converted to a one-byte sequence, but there is no such requirement
9133 for characters that are not part of the basic execution character set.
9134 </p>
9135 <p><b>Proposed resolution:</b></p>
9136 <p>
9137 Change 22.2.1.5.2/5 from:
9138 </p>
9139 <p>
9140 The instantiations required in Table 51 (lib.locale.category), namely
9141 codecvt&lt;wchar_t,char,mbstate_t&gt; and
9142 codecvt&lt;char,char,mbstate_t&gt;, store no characters. Stores no more
9143 than (to_limit-to) destination elements. It always leaves the to_next
9144 pointer pointing one beyond the last element successfully stored.
9145 </p>
9146 <p>
9147 to:
9148 </p>
9149 <p>
9150 Stores no more than (to_limit-to) destination elements, and leaves the
9151 to_next pointer pointing one beyond the last element successfully
9152 stored.  codecvt&lt;char,char,mbstate_t&gt; stores no characters.
9153 </p>
9154
9155 <p>Change 22.2.1.5.2/10 from:</p>
9156
9157 <blockquote>
9158 -10- Returns: (from_next-from) where from_next is the largest value in
9159 the range [from,from_end] such that the sequence of values in the
9160 range [from,from_next) represents max or fewer valid complete
9161 characters of type internT. The instantiations required in Table 51
9162 (21.1.1.1.1), namely codecvt&lt;wchar_t, char, mbstate_t&gt; and
9163 codecvt&lt;char, char, mbstate_t&gt;, return the lesser of max and
9164 (from_end-from).
9165 </blockquote>
9166
9167 <p>to:</p>
9168
9169 <blockquote>
9170 -10- Returns: (from_next-from) where from_next is the largest value in
9171 the range [from,from_end] such that the sequence of values in the range
9172 [from,from_next) represents max or fewer valid complete characters of
9173 type internT. The instantiation codecvt&lt;char, char, mbstate_t&gt; returns
9174 the lesser of max and (from_end-from).
9175 </blockquote>
9176
9177 <p><i>[Redmond: Nathan suggested an alternative resolution: same as
9178 above, but require that, in the default encoding, a character from the
9179 basic execution character set would map to a single external
9180 character.  The straw poll was 8-1 in favor of the proposed
9181 resolution.]</i></p>
9182
9183 <p><b>Rationale:</b></p>
9184 <p>The default encoding should be whatever users of a given platform
9185 would expect to be the most natural.  This varies from platform to
9186 platform.  In many cases there is a preexisting C library, and users
9187 would expect the default encoding to be whatever C uses in the default
9188 "C" locale.  We could impose a guarantee like the one Nathan suggested
9189 (a character from the basic execution character set must map to a
9190 single external character), but this would rule out important
9191 encodings that are in common use: it would rule out JIS, for
9192 example, and it would rule out a fixed-width encoding of UCS-4.</p>
9193
9194 <p><i>[Curaçao: fixed rationale typo at the request of Ichiro Koshida;
9195 "shift-JIS" changed to "JIS".]</i></p>
9196
9197 <hr>
9198 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;21 Feb 2001</p>
9199 <p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
9200
9201 <p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
9202 accepts a restricted set of <i>type</i> arguments in this
9203 International Standard. <i>type</i> shall be a POD structure or a POD
9204 union (clause 9). The result of applying the offsetof macro to a field
9205 that is a static data member or a function member is
9206 undefined."</p>
9207
9208 <p>For the POD requirement, it doesn't say "no diagnostic
9209 required" or "undefined behavior". I read 1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/intro.html#intro.compliance"> [intro.compliance]</a>, paragraph 1, to mean that a diagnostic is required.
9210 It's not clear whether this requirement was intended.  While it's
9211 possible to provide such a diagnostic, the extra complication doesn't
9212 seem to add any value.
9213 </p>
9214 <p><b>Proposed resolution:</b></p>
9215 <p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
9216 structure or a POD union the results are undefined."</p>
9217
9218 <p><i>[Copenhagen: straw poll was 7-4 in favor.  It was generally
9219 agreed that requiring a diagnostic was inadvertent, but some LWG
9220 members thought that diagnostics should be required whenever
9221 possible.]</i></p>
9222
9223 <hr>
9224 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;13 Mar 2001</p>
9225
9226 <p>From reflector message c++std-lib-8330.  See also lib-8317.</p>
9227
9228 <p>
9229 The standard is currently inconsistent in 23.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a>
9230 paragraph 1 and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.stack"> [lib.stack]</a> paragraph 1.
9231 23.2.3.3/1, for example, says:
9232 </p>
9233
9234 <blockquote>
9235 -1- Any sequence supporting operations back(), push_back() and pop_back()
9236 can be used to instantiate stack. In particular, vector (lib.vector), list
9237 (lib.list) and deque (lib.deque) can be used.
9238 </blockquote>
9239
9240 <p>But this is false: vector&lt;bool&gt; can not be used, because the
9241 container adaptors return a T&amp; rather than using the underlying
9242 container's reference type.</p>
9243
9244 <p>This is a contradiction that can be fixed by:</p>
9245
9246 <ol>
9247 <li>Modifying these paragraphs to say that vector&lt;bool&gt;
9248     is an exception.</li>
9249 <li>Removing the vector&lt;bool&gt; specialization.</li>
9250 <li>Changing the return types of stack and priority_queue to use
9251     reference typedef's.</li>
9252 </ol>
9253
9254 <p>
9255 I propose 3.  This does not preclude option 2 if we choose to do it
9256 later (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#96">96</a>); the issues are independent.  Option
9257 3 offers a small step towards support for proxied containers.  This
9258 small step fixes a current contradiction, is easy for vendors to
9259 implement, is already implemented in at least one popular lib, and
9260 does not break any code.
9261 </p>
9262
9263 <p><b>Proposed resolution:</b></p>
9264 <p>Summary: Add reference and const_reference typedefs to queue,
9265 priority_queue and stack.  Change return types of "value_type&amp;" to
9266 "reference".  Change return types of "const value_type&amp;" to
9267 "const_reference".  Details:</p>
9268
9269 <p>Change 23.2.3.1/1 from:</p>
9270
9271 <pre>  namespace std {
9272     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9273     class queue {
9274     public:
9275       typedef typename Container::value_type            value_type;
9276       typedef typename Container::size_type             size_type;
9277       typedef          Container                        container_type;
9278     protected:
9279       Container c;
9280
9281     public:
9282       explicit queue(const Container&amp; = Container());
9283
9284       bool      empty() const             { return c.empty(); }
9285       size_type size()  const             { return c.size(); }
9286       value_type&amp;       front()           { return c.front(); }
9287       const value_type&amp; front() const     { return c.front(); }
9288       value_type&amp;       back()            { return c.back(); }
9289       const value_type&amp; back() const      { return c.back(); }
9290       void push(const value_type&amp; x)      { c.push_back(x); }
9291       void pop()                          { c.pop_front(); }
9292     };
9293 </pre>
9294
9295 <p>to:</p>
9296
9297 <pre>  namespace std {
9298     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9299     class queue {
9300     public:
9301       typedef typename Container::value_type            value_type;
9302       typedef typename Container::reference             reference;
9303       typedef typename Container::const_reference       const_reference;
9304       typedef typename Container::value_type            value_type;
9305       typedef typename Container::size_type             size_type;
9306       typedef          Container                        container_type;
9307     protected:
9308       Container c;
9309
9310     public:
9311       explicit queue(const Container&amp; = Container());
9312
9313       bool      empty() const             { return c.empty(); }
9314       size_type size()  const             { return c.size(); }
9315       reference         front()           { return c.front(); }
9316       const_reference   front() const     { return c.front(); }
9317       reference         back()            { return c.back(); }
9318       const_reference   back() const      { return c.back(); }
9319       void push(const value_type&amp; x)      { c.push_back(x); }
9320       void pop()                          { c.pop_front(); }
9321     };
9322 </pre>
9323
9324 <p>Change 23.2.3.2/1 from:</p>
9325
9326 <pre>  namespace std {
9327     template &lt;class T, class Container = vector&lt;T&gt;,
9328               class Compare = less&lt;typename Container::value_type&gt; &gt;
9329     class priority_queue {
9330     public:
9331       typedef typename Container::value_type            value_type;
9332       typedef typename Container::size_type             size_type;
9333       typedef          Container                        container_type;
9334     protected:
9335       Container c;
9336       Compare comp;
9337
9338     public:
9339       explicit priority_queue(const Compare&amp; x = Compare(),
9340                               const Container&amp; = Container());
9341       template &lt;class InputIterator&gt;
9342         priority_queue(InputIterator first, InputIterator last,
9343                        const Compare&amp; x = Compare(),
9344                        const Container&amp; = Container());
9345
9346       bool      empty() const       { return c.empty(); }
9347       size_type size()  const       { return c.size(); }
9348       const value_type&amp; top() const { return c.front(); }
9349       void push(const value_type&amp; x);
9350       void pop();
9351     };
9352                                   //  no equality is provided
9353   }
9354 </pre>
9355
9356 <p>to:</p>
9357
9358 <pre>  namespace std {
9359     template &lt;class T, class Container = vector&lt;T&gt;,
9360               class Compare = less&lt;typename Container::value_type&gt; &gt;
9361     class priority_queue {
9362     public:
9363       typedef typename Container::value_type            value_type;
9364       typedef typename Container::reference             reference;
9365       typedef typename Container::const_reference       const_reference;
9366       typedef typename Container::size_type             size_type;
9367       typedef          Container                        container_type;
9368     protected:
9369       Container c;
9370       Compare comp;
9371
9372     public:
9373       explicit priority_queue(const Compare&amp; x = Compare(),
9374                               const Container&amp; = Container());
9375       template &lt;class InputIterator&gt;
9376         priority_queue(InputIterator first, InputIterator last,
9377                        const Compare&amp; x = Compare(),
9378                        const Container&amp; = Container());
9379
9380       bool      empty() const       { return c.empty(); }
9381       size_type size()  const       { return c.size(); }
9382       const_reference   top() const { return c.front(); }
9383       void push(const value_type&amp; x);
9384       void pop();
9385     };
9386                                   //  no equality is provided
9387   }
9388 </pre>
9389
9390 <p>And change 23.2.3.3/1 from:</p>
9391
9392 <pre>  namespace std {
9393     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9394     class stack {
9395     public:
9396       typedef typename Container::value_type            value_type;
9397       typedef typename Container::size_type             size_type;
9398       typedef          Container                        container_type;
9399     protected:
9400       Container c;
9401
9402     public:
9403       explicit stack(const Container&amp; = Container());
9404
9405       bool      empty() const             { return c.empty(); }
9406       size_type size()  const             { return c.size(); }
9407       value_type&amp;       top()             { return c.back(); }
9408       const value_type&amp; top() const       { return c.back(); }
9409       void push(const value_type&amp; x)      { c.push_back(x); }
9410       void pop()                          { c.pop_back(); }
9411     };
9412
9413     template &lt;class T, class Container&gt;
9414       bool operator==(const stack&lt;T, Container&gt;&amp; x,
9415                       const stack&lt;T, Container&gt;&amp; y);
9416     template &lt;class T, class Container&gt;
9417       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
9418                       const stack&lt;T, Container&gt;&amp; y);
9419     template &lt;class T, class Container&gt;
9420       bool operator!=(const stack&lt;T, Container&gt;&amp; x,
9421                       const stack&lt;T, Container&gt;&amp; y);
9422     template &lt;class T, class Container&gt;
9423       bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
9424                       const stack&lt;T, Container&gt;&amp; y);
9425     template &lt;class T, class Container&gt;
9426       bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
9427                       const stack&lt;T, Container&gt;&amp; y);
9428     template &lt;class T, class Container&gt;
9429       bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
9430                       const stack&lt;T, Container&gt;&amp; y);
9431   }
9432 </pre>
9433
9434 <p>to:</p>
9435
9436 <pre>  namespace std {
9437     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9438     class stack {
9439     public:
9440       typedef typename Container::value_type            value_type;
9441       typedef typename Container::reference             reference;
9442       typedef typename Container::const_reference       const_reference;
9443       typedef typename Container::size_type             size_type;
9444       typedef          Container                        container_type;
9445     protected:
9446       Container c;
9447
9448     public:
9449       explicit stack(const Container&amp; = Container());
9450
9451       bool      empty() const             { return c.empty(); }
9452       size_type size()  const             { return c.size(); }
9453       reference         top()             { return c.back(); }
9454       const_reference   top() const       { return c.back(); }
9455       void push(const value_type&amp; x)      { c.push_back(x); }
9456       void pop()                          { c.pop_back(); }
9457     };
9458
9459     template &lt;class T, class Container&gt;
9460       bool operator==(const stack&lt;T, Container&gt;&amp; x,
9461                       const stack&lt;T, Container&gt;&amp; y);
9462     template &lt;class T, class Container&gt;
9463       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
9464                       const stack&lt;T, Container&gt;&amp; y);
9465     template &lt;class T, class Container&gt;
9466       bool operator!=(const stack&lt;T, Container&gt;&amp; x,
9467                       const stack&lt;T, Container&gt;&amp; y);
9468     template &lt;class T, class Container&gt;
9469       bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
9470                       const stack&lt;T, Container&gt;&amp; y);
9471     template &lt;class T, class Container&gt;
9472       bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
9473                       const stack&lt;T, Container&gt;&amp; y);
9474     template &lt;class T, class Container&gt;
9475       bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
9476                       const stack&lt;T, Container&gt;&amp; y);
9477   }
9478 </pre>
9479
9480 <p><i>[Copenhagen: This change was discussed before the IS was released
9481 and it was deliberately not adopted.  Nevertheless, the LWG believes
9482 (straw poll: 10-2) that it is a genuine defect.]</i></p>
9483
9484 <hr>
9485 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Mar 2001</p>
9486 <p>
9487 Table 82 in section 27 mentions the header &lt;cstdlib&gt; for String
9488 streams (27.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a>) and the headers &lt;cstdio&gt; and
9489 &lt;cwchar&gt; for File streams (27.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>). It's not clear
9490 why these headers are mentioned in this context since they do not
9491 define any of the library entities described by the
9492 subclauses. According to 17.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.contents"> [lib.contents]</a>, only such headers
9493 are to be listed in the summary.
9494 </p>
9495 <p><b>Proposed resolution:</b></p>
9496 <p>Remove &lt;cstdlib&gt; and &lt;cwchar&gt; from
9497 Table 82.</p>
9498
9499 <p><i>[Copenhagen: changed the proposed resolution slightly.  The
9500 original proposed resolution also said to remove &lt;cstdio&gt; from
9501 Table 82.  However, &lt;cstdio&gt; is mentioned several times within
9502 section 27.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-iostreams.html#lib.c.files"> [lib.c.files]</a>.]</i></p>
9503
9504 <hr>
9505 <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/papers/2005/lib-intro.html#lib.headers"> [lib.headers]</a>, 19.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-diagnostics.html#lib.errno"> [lib.errno]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;21 Mar 2001</p>
9506   <p>
9507   Exactly how should errno be declared in a conforming C++ header?
9508   </p>
9509
9510   <p>
9511   The C standard says in 7.1.4 that it is unspecified whether errno is a
9512   macro or an identifier with external linkage.  In some implementations
9513   it can be either, depending on compile-time options.  (E.g., on
9514   Solaris in multi-threading mode, errno is a macro that expands to a
9515   function call, but is an extern int otherwise.  "Unspecified" allows
9516   such variability.)
9517   </p>
9518
9519   <p>The C++ standard:</p>
9520   <ul>
9521   <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
9522   <li>17.4.3.1.3 footnote 166 says errno is reserved as an external
9523       name (true), and implies that it is an identifier.</li>
9524   <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
9525       on to say that the contents of of C++ &lt;errno.h&gt; are the
9526       same as in C, begging the question.</li>
9527   <li>C.2, table 95 lists errno as a macro, without comment.</li>
9528   </ul>
9529
9530   <p>I find no other references to errno.</p>
9531
9532   <p>We should either explicitly say that errno must be a macro, even
9533   though it need not be a macro in C, or else explicitly leave it
9534   unspecified.  We also need to say something about namespace std.
9535   A user who includes &lt;cerrno&gt; needs to know whether to write
9536   <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
9537   else &lt;cerrno&gt; is useless.</p>
9538
9539   <p>Two acceptable fixes:</p>
9540   <ul>
9541     <li><p>errno must be a macro. This is trivially satisfied by adding<br>
9542         &nbsp;&nbsp;#define errno (::std::errno)<br>
9543         to the headers if errno is not already a macro. You then always
9544         write errno without any scope qualification, and it always expands
9545         to a correct reference. Since it is always a macro, you know to
9546         avoid using errno as a local identifer.</p></li>
9547     <li><p>errno is in the global namespace. This fix is inferior, because
9548         ::errno is not guaranteed to be well-formed.</p></li>
9549   </ul>
9550
9551   <p><i>[
9552     This issue was first raised in 1999, but it slipped through
9553     the cracks.
9554   ]</i></p>
9555 <p><b>Proposed resolution:</b></p>
9556   <p>Change the Note in section 17.4.1.2p5 from</p>
9557
9558     <blockquote>
9559     Note: the names defined as macros in C include the following:
9560     assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
9561     </blockquote>
9562
9563   <p>to</p>
9564
9565     <blockquote>
9566     Note: the names defined as macros in C include the following:
9567     assert, offsetof, setjmp, va_arg, va_end, and va_start.
9568     </blockquote>
9569
9570   <p>In section 19.3, change paragraph 2 from</p>
9571
9572     <blockquote>
9573     The contents are the same as the Standard C library header
9574     &lt;errno.h&gt;.
9575     </blockquote>
9576
9577   <p>to</p>
9578
9579     <blockquote>
9580     The contents are the same as the Standard C library header
9581     &lt;errno.h&gt;, except that errno shall be defined as a macro.
9582     </blockquote>
9583 <p><b>Rationale:</b></p>
9584 <p>C++ must not leave it up to the implementation to decide whether or
9585 not a name is a macro; it must explicitly specify exactly which names
9586 are required to be macros.  The only one that really works is for it
9587 to be a macro.</p>
9588
9589 <p><i>[Curaçao: additional rationale added.]</i></p>
9590
9591 <hr>
9592 <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/papers/2005/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;21 Mar 2001</p>
9593
9594 <p>In 27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, the synopsis of class basic_ostream says:</p>
9595
9596 <pre>  // partial specializationss
9597   template&lt;class traits&gt;
9598     basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;( basic_ostream&lt;char,traits&gt;&amp;,
9599                                             const char * );
9600 </pre>
9601
9602 <p>Problems:</p>
9603 <ul>
9604 <li>Too many 's's at the end of "specializationss" </li>
9605 <li>This is an overload, not a partial specialization</li>
9606 </ul>
9607
9608 <p><b>Proposed resolution:</b></p>
9609 <p>In the synopsis in 27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, remove the
9610 <i>// partial specializationss</i> comment.  Also remove the same
9611 comment (correctly spelled, but still incorrect) from the synopsis in
9612 27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a>.
9613 </p>
9614
9615 <p><i>[
9616 Pre-Redmond: added 27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> because of Martin's
9617 comment in c++std-lib-8939.
9618 ]</i></p>
9619
9620 <hr>
9621 <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/papers/2005/lib-utilities.html#lib.utilities"> [lib.utilities]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;29 Mar 2001</p>
9622 <p>Table 27 in section 20 lists the header &lt;memory&gt; (only) for
9623 Memory (lib.memory) but neglects to mention the headers
9624 &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/papers/2005/lib-utilities.html#lib.c.malloc"> [lib.c.malloc]</a>.</p>
9625 <p><b>Proposed resolution:</b></p>
9626 <p>Add &lt;cstdlib&gt; and &lt;cstring&gt; to Table 27, in the same row
9627 as &lt;memory&gt;.</p>
9628 <hr>
9629 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;1 May 2001</p>
9630 <p>
9631 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, Para 21 describes the complexity of
9632 list::unique as: "If the range (last - first) is not empty, exactly
9633 (last - first) -1 applications of the corresponding predicate,
9634 otherwise no applications of the predicate)".
9635 </p>
9636
9637 <p>
9638 "(last - first)" is not a range.
9639 </p>
9640 <p><b>Proposed resolution:</b></p>
9641 <p>
9642 Change the "range" from (last - first) to [first, last).
9643 </p>
9644 <hr>
9645 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;4 May 2001</p>
9646 <p>Table 69 says this about a_uniq.insert(t):</p>
9647
9648 <blockquote>
9649 inserts t if and only if there is no element in the container with key
9650 equivalent to the key of t. The bool component of the returned pair
9651 indicates whether the insertion takes place and the iterator component of the
9652 pair points to the element with key equivalent to the key of t.
9653 </blockquote>
9654
9655 <p>The description should be more specific about exactly how the bool component
9656 indicates whether the insertion takes place.</p>
9657 <p><b>Proposed resolution:</b></p>
9658 <p>Change the text in question to</p>
9659
9660 <blockquote>
9661 ...The bool component of the returned pair is true if and only if the insertion
9662 takes place...
9663 </blockquote>
9664 <hr>
9665 <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/papers/2005/lib-locales.html#lib.localization"> [lib.localization]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;4 May 2001</p>
9666 <p>
9667 The localization section of the standard refers to specializations of
9668 the facet templates as instantiations even though the required facets
9669 are typically specialized rather than explicitly (or implicitly)
9670 instantiated. In the case of ctype&lt;char&gt; and
9671 ctype_byname&lt;char&gt; (and the wchar_t versions), these facets are
9672 actually required to be specialized. The terminology should be
9673 corrected to make it clear that the standard doesn't mandate explicit
9674 instantiation (the term specialization encompasses both explicit
9675 instantiations and specializations).
9676 </p>
9677 <p><b>Proposed resolution:</b></p>
9678 <p>
9679 In the following paragraphs, replace all occurrences of the word
9680 instantiation or instantiations with specialization or specializations,
9681 respectively:
9682 </p>
9683
9684 <blockquote>
9685 22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
9686 22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3,
9687 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
9688 Footnote 242.
9689 </blockquote>
9690
9691 <p>And change the text in 22.1.1.1.1, p4 from</p>
9692
9693 <blockquote>
9694     An implementation is required to provide those instantiations
9695     for facet templates identified as members of a category, and
9696     for those shown in Table 52:
9697 </blockquote>
9698
9699 <p>to</p>
9700
9701 <blockquote>
9702     An implementation is required to provide those specializations...
9703 </blockquote>
9704
9705 <p><i>[Nathan will review these changes, and will look for places where
9706 explicit specialization is necessary.]</i></p>
9707
9708 <p><b>Rationale:</b></p>
9709 <p>This is a simple matter of outdated language.  The language to
9710 describe templates was clarified during the standardization process,
9711 but the wording in clause 22 was never updated to reflect that
9712 change.</p>
9713 <hr>
9714 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 May 2001</p>
9715 <p>The definition of the numpunct_byname template contains the following
9716 comment:</p>
9717
9718 <pre>    namespace std {
9719         template &lt;class charT&gt;
9720         class numpunct_byname : public numpunct&lt;charT&gt; {
9721     // this class is specialized for char and wchar_t.
9722         ...
9723 </pre>
9724
9725 <p>There is no documentation of the specializations and it seems
9726 conceivable that an implementation will not explicitly specialize the
9727 template at all, but simply provide the primary template.</p>
9728 <p><b>Proposed resolution:</b></p>
9729 <p>Remove the comment from the text in 22.2.3.2 and from the proposed
9730 resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#228">228</a>.</p>
9731 <hr>
9732 <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/papers/2005/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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;15 May 2001</p>
9733 <p>The standard specifies 17.3.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that "Required
9734 behavior" elements describe "the semantics of a function definition
9735 provided by either the implementation or a C++ program."</p>
9736
9737 <p>The standard specifies 17.3.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that "Requires"
9738 elements describe "the preconditions for calling the function."</p>
9739
9740 <p>In the sections noted below, the current wording specifies
9741 "Required Behavior" for what are actually preconditions, and thus
9742 should be specified as "Requires".</p>
9743
9744 <p><b>Proposed resolution:</b></p>
9745
9746 <p>In 18.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> Para 12 Change:</p>
9747 <blockquote>
9748   <p>Required behavior: accept a value of ptr that is null or that was
9749   returned by an earlier call ...</p>
9750 </blockquote>
9751 <p>to:</p>
9752 <blockquote>
9753   <p>Requires: the value of ptr is null or the value returned by an
9754   earlier call ...</p>
9755 </blockquote>
9756
9757 <p>In 18.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> Para 11 Change:</p>
9758 <blockquote>
9759   <p>Required behavior: accept a value of ptr that is null or that was
9760   returned by an earlier call ...</p>
9761 </blockquote>
9762 <p>to:</p>
9763 <blockquote>
9764   <p>Requires: the value of ptr is null or the value returned by an
9765   earlier call ...</p>
9766 </blockquote>
9767
9768 <hr>
9769 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
9770 <p>
9771 Section 23.2.2.1, paragraphs 6-8 specify that list assign (both forms) have
9772 the "effects" of a call to erase followed by a call to insert.
9773 </p>
9774
9775 <p>
9776 I would like to document that implementers have the freedom to implement
9777 assign by other methods, as long as the end result is the same and the
9778 exception guarantee is as good or better than the basic guarantee.
9779 </p>
9780
9781 <p>
9782 The motivation for this is to use T's assignment operator to recycle
9783 existing nodes in the list instead of erasing them and reallocating
9784 them with new values.  It is also worth noting that, with careful
9785 coding, most common cases of assign (everything but assignment with
9786 true input iterators) can elevate the exception safety to strong if
9787 T's assignment has a nothrow guarantee (with no extra memory cost).
9788 Metrowerks does this.  However I do not propose that this subtlety be
9789 standardized.  It is a QoI issue.  </p>
9790
9791 <p>Existing practise:
9792 Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
9793 </p>
9794 <p><b>Proposed resolution:</b></p>
9795 <p>Change 23.2.2.1/7 from:</p>
9796
9797 <blockquote>
9798 <p>Effects:</p>
9799
9800 <pre>   erase(begin(), end());
9801    insert(begin(), first, last);
9802 </pre>
9803 </blockquote>
9804
9805 <p>to:</p>
9806
9807 <blockquote>
9808 <p>Effects: Replaces the contents of the list with the range [first, last).</p>
9809 </blockquote>
9810
9811 <p>In 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>, in Table 67 (sequence requirements),
9812 add two new rows:</p>
9813 <pre>      a.assign(i,j)     void      pre: i,j are not iterators into a.
9814                                   Replaces elements in a with a copy
9815                                   of [i, j).
9816
9817       a.assign(n,t)     void      pre: t is not a reference into a.
9818                                   Replaces elements in a with n copies
9819                                   of t.
9820 </pre>
9821
9822 <p>Change 23.2.2.1/8 from:</p>
9823
9824 <blockquote>
9825 <p>Effects:</p>
9826 <pre>   erase(begin(), end());
9827    insert(begin(), n, t);
9828 </pre>
9829 </blockquote>
9830 <p>to:</p>
9831
9832 <blockquote>
9833 <p>Effects: Replaces the contents of the list with n copies of t.</p>
9834 </blockquote>
9835
9836 <p><i>[Redmond: Proposed resolution was changed slightly.  Previous
9837 version made explicit statement about exception safety, which wasn't
9838 consistent with the way exception safety is expressed elsewhere.
9839 Also, the change in the sequence requirements is new.  Without that
9840 change, the proposed resolution would have required that assignment of
9841 a subrange would have to work.  That too would have been
9842 overspecification; it would effectively mandate that assignment use a
9843 temporary.  Howard provided wording.
9844 ]</i></p>
9845
9846 <p><i>[Curaçao: Made editorial improvement in wording; changed
9847 "Replaces elements in a with copies of elements in [i, j)."
9848 with "Replaces the elements of a with a copy of [i, j)."
9849 Changes not deemed serious enough to requre rereview.]</i></p>
9850
9851 <hr>
9852 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Kevin Djang&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
9853 <p>
9854 Section 22.2.2.1.2 at p7 states that "A length specifier is added to
9855 the conversion function, if needed, as indicated in Table 56."
9856 However, Table 56 uses the term "length modifier", not "length
9857 specifier".
9858 </p>
9859 <p><b>Proposed resolution:</b></p>
9860 <p>
9861 In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
9862 to be "A length modifier is added ..."
9863 </p>
9864 <p><b>Rationale:</b></p>
9865 <p>C uses the term "length modifier".  We should be consistent.</p>
9866 <hr>
9867 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
9868 <p>
9869 It's widely assumed that, if X is a container,
9870 iterator_traits&lt;X::iterator&gt;::value_type and
9871 iterator_traits&lt;X::const_iterator&gt;::value_type should both be
9872 X::value_type.  However, this is nowhere stated.  The language in
9873 Table 65 is not precise about the iterators' value types (it predates
9874 iterator_traits), and could even be interpreted as saying that
9875 iterator_traits&lt;X::const_iterator&gt;::value_type should be "const
9876 X::value_type".
9877 </p>
9878
9879 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#279">279</a>.</p>
9880 <p><b>Proposed resolution:</b></p>
9881 <p>In Table 65 ("Container Requirements"), change the return type for
9882 X::iterator to "iterator type whose value type is T".  Change the
9883 return type for X::const_iterator to "constant iterator type whose
9884 value type is T".</p>
9885 <p><b>Rationale:</b></p>
9886 <p>
9887 This belongs as a container requirement, rather than an iterator
9888 requirement, because the whole notion of iterator/const_iterator
9889 pairs is specific to containers' iterator.
9890 </p>
9891 <p>
9892 It is existing practice that (for example)
9893 iterator_traits&lt;list&lt;int&gt;::const_iterator&gt;::value_type
9894 is "int", rather than "const int".  This is consistent with
9895 the way that const pointers are handled: the standard already
9896 requires that iterator_traits&lt;const int*&gt;::value_type is int.
9897 </p>
9898 <hr>
9899 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;7 June 2001</p>
9900
9901 <p>Table 73 suggests that output iterators have value types.  It
9902 requires the expression "*a = t".  Additionally, although Table 73
9903 never lists "a = t" or "X(a) = t" in the "expressions" column, it
9904 contains a note saying that "a = t" and "X(a) = t" have equivalent
9905 (but nowhere specified!) semantics.</p>
9906
9907 <p>According to 24.1/9, t is supposed to be "a value of value type
9908 T":</p>
9909
9910     <blockquote>
9911     In the following sections, a and b denote values of X, n denotes a
9912     value of the difference type Distance, u, tmp, and m denote
9913     identifiers, r denotes a value of X&amp;, t denotes a value of
9914     value type T.
9915     </blockquote>
9916
9917 <p>Two other parts of the standard that are relevant to whether
9918 output iterators have value types:</p>
9919
9920 <ul>
9921     <li>24.1/1 says "All iterators i support the expression *i,
9922     resulting in a value of some class, enumeration, or built-in type
9923     T, called the value type of the iterator".</li>
9924
9925     <li>
9926     24.3.1/1, which says "In the case of an output iterator, the types
9927     iterator_traits&lt;Iterator&gt;::difference_type
9928     iterator_traits&lt;Iterator&gt;::value_type are both defined as void."
9929     </li>
9930 </ul>
9931
9932 <p>The first of these passages suggests that "*i" is supposed to
9933 return a useful value, which contradicts the note in 24.1.2/2 saying
9934 that the only valid use of "*i" for output iterators is in an
9935 expression of the form "*i = t".  The second of these passages appears
9936 to contradict Table 73, because it suggests that "*i"'s return value
9937 should be void.  The second passage is also broken in the case of a an
9938 iterator type, like non-const pointers, that satisfies both the output
9939 iterator requirements and the forward iterator requirements.</p>
9940
9941 <p>What should the standard say about <tt>*i</tt>'s return value when
9942 i is an output iterator, and what should it say about that t is in the
9943 expression "*i = t"?  Finally, should the standard say anything about
9944 output iterators' pointer and reference types?</p>
9945
9946 <p><b>Proposed resolution:</b></p>
9947 <p>24.1 p1, change</p>
9948
9949 <blockquote>
9950 <p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
9951 in a value of some class, enumeration, or built-in type <tt>T</tt>,
9952 called the value type of the iterator.</p>
9953 </blockquote>
9954
9955 <p>to</p>
9956
9957 <blockquote>
9958 <p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
9959 resulting in a value of some class, enumeration, or built-in type
9960 <tt>T</tt>, called the value type of the iterator. All output
9961 iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
9962 value of some type that is in the set of types that are <i>writable</i> to
9963 the particular iterator type of <tt>i</tt>.
9964 </p>
9965 </blockquote>
9966
9967 <p>24.1 p9, add</p>
9968
9969 <blockquote>
9970 <p><tt>o</tt> denotes a value of some type that is writable to the
9971 output iterator.
9972 </p>
9973 </blockquote>
9974
9975 <p>Table 73, change</p>
9976
9977 <blockquote>
9978 <pre>*a = t
9979 </pre>
9980 </blockquote>
9981
9982 <p>to</p>
9983
9984 <blockquote>
9985 <pre>*r = o
9986 </pre>
9987 </blockquote>
9988
9989 <p>and change</p>
9990
9991 <blockquote>
9992 <pre>*r++ = t
9993 </pre>
9994 </blockquote>
9995
9996 <p>to</p>
9997
9998 <blockquote>
9999 <pre>*r++ = o
10000 </pre>
10001 </blockquote>
10002
10003 <p><i>[post-Redmond: Jeremy provided wording]</i></p>
10004
10005 <p><b>Rationale:</b></p>
10006 <p>The LWG considered two options: change all of the language that
10007 seems to imply that output iterators have value types, thus making it
10008 clear that output iterators have no value types, or else define value
10009 types for output iterator consistently.  The LWG chose the former
10010 option, because it seems clear that output iterators were never
10011 intended to have value types.  This was a deliberate design decision,
10012 and any language suggesting otherwise is simply a mistake.</p>
10013
10014 <p>A future revision of the standard may wish to revisit this design
10015 decision.</p>
10016 <hr>
10017 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Jul 2001</p>
10018 <p>The Returns clause in 22.2.6.3.2, p3 says about
10019 moneypunct&lt;charT&gt;::do_grouping()
10020 </p>
10021
10022 <blockquote>
10023     Returns: A pattern defined identically as the result of
10024     numpunct&lt;charT&gt;::do_grouping().241)
10025 </blockquote>
10026
10027 <p>Footnote 241 then reads</p>
10028
10029 <blockquote>
10030     This is most commonly the value "\003" (not "3").
10031 </blockquote>
10032
10033 <p>
10034 The returns clause seems to imply that the two member functions must
10035 return an identical value which in reality may or may not be true,
10036 since the facets are usually implemented in terms of struct std::lconv
10037 and return the value of the grouping and mon_grouping, respectively.
10038 The footnote also implies that the member function of the moneypunct
10039 facet (rather than the overridden virtual functions in moneypunct_byname)
10040 most commonly return "\003", which contradicts the C standard which
10041 specifies the value of "" for the (most common) C locale.
10042 </p>
10043
10044 <p><b>Proposed resolution:</b></p>
10045 <p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>
10046
10047 <blockquote>
10048     Returns: A pattern defined identically as, but not necessarily
10049     equal to, the result of numpunct&lt;charT&gt;::do_grouping().241)
10050 </blockquote>
10051
10052 <p>and replace the text in Footnote 241 with the following:</p>
10053
10054 <blockquote>
10055     To specify grouping by 3s the value is "\003", not "3".
10056 </blockquote>
10057 <p><b>Rationale:</b></p>
10058 <p>
10059 The fundamental problem is that the description of the locale facet
10060 virtuals serves two purposes: describing the behavior of the base
10061 class, and describing the meaning of and constraints on the behavior
10062 in arbitrary derived classes.  The new wording makes that separation a
10063 little bit clearer.  The footnote (which is nonnormative) is not
10064 supposed to say what the grouping is in the "C" locale or in any other
10065 locale. It is just a reminder that the values are interpreted as small
10066 integers, not ASCII characters.
10067 </p>
10068 <hr>
10069 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Tiki Wan&nbsp; <b>Date:</b>&nbsp;06 Jul 2001</p>
10070 <p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
10071 <tt>time_get_byname</tt> are listed incorrectly in table 52,
10072 required instantiations.  In both cases the second template
10073 parameter is given as OutputIterator.  It should instead be
10074 InputIterator, since these are input facets.</p>
10075 <p><b>Proposed resolution:</b></p>
10076 <p>
10077 In table 52, required instantiations, in
10078 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, change</p>
10079 <pre>    time_get&lt;wchar_t, OutputIterator&gt;
10080     time_get_byname&lt;wchar_t, OutputIterator&gt;
10081 </pre>
10082 <p>to</p>
10083 <pre>    time_get&lt;wchar_t, InputIterator&gt;
10084     time_get_byname&lt;wchar_t, InputIterator&gt;
10085 </pre>
10086
10087 <p><i>[Redmond: Very minor change in proposed resolution.  Original had
10088 a typo, wchart instead of wchar_t.]</i></p>
10089
10090 <hr>
10091 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;07 Jul 2001</p>
10092 <p>The sprintf format string , "%.01f" (that's the digit one), in the
10093 description of the do_put() member functions of the money_put facet in
10094 22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
10095 for values of type long double, and second, the precision of 01
10096 doesn't seem to make sense. What was most likely intended was
10097 "%.0Lf"., that is a precision of zero followed by the L length
10098 modifier.</p>
10099 <p><b>Proposed resolution:</b></p>
10100 <p>Change the format string to "%.0Lf".</p>
10101 <p><b>Rationale:</b></p>
10102 <p>Fixes an obvious typo</p>
10103 <hr>
10104 <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/papers/2005/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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;13 Jul 2001</p>
10105 <p>
10106 There is an apparent contradiction about which circumstances can cause
10107 a reallocation of a vector in Section 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> and
10108 section 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>.
10109 </p>
10110
10111 <p>23.2.4.2p5 says:</p>
10112 <blockquote>
10113 Notes: Reallocation invalidates all the references, pointers, and iterators
10114 referring to the elements in the sequence. It is guaranteed that no
10115 reallocation takes place during insertions that happen after a call to
10116 reserve() until the time when an insertion would make the size of the vector
10117 greater than the size specified in the most recent call to reserve().
10118 </blockquote>
10119
10120 <p>Which implies if I do</p>
10121
10122 <pre>  std::vector&lt;int&gt; vec;
10123   vec.reserve(23);
10124   vec.reserve(0);
10125   vec.insert(vec.end(),1);
10126 </pre>
10127
10128 <p>then the implementation may reallocate the vector for the insert,
10129 as the size specified in the previous call to reserve was zero.</p>
10130
10131 <p>However, the previous paragraphs (23.2.4.2, p1-2) state:</p>
10132 <blockquote>
10133 <p>
10134 (capacity) Returns: The total number of elements the vector
10135 can hold without requiring reallocation
10136 </p>
10137 <p>
10138 ...After reserve(), capacity() is greater or equal to the
10139 argument of reserve if reallocation happens; and equal to the previous value
10140 of capacity() otherwise...
10141 </p>
10142 </blockquote>
10143
10144 <p>
10145 This implies that vec.capacity() is still 23, and so the insert()
10146 should not require a reallocation, as vec.size() is 0. This is backed
10147 up by 23.2.4.3p1:
10148 </p>
10149 <blockquote>
10150 (insert) Notes: Causes reallocation if the new size is greater than the old
10151 capacity.
10152 </blockquote>
10153
10154 <p>
10155 Though this doesn't rule out reallocation if the new size is less
10156 than the old capacity, I think the intent is clear.
10157 </p>
10158
10159 <p><b>Proposed resolution:</b></p>
10160 <p>Change the wording of 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> paragraph 5 to:</p>
10161
10162 <blockquote>
10163 Notes: Reallocation invalidates all the references, pointers, and
10164 iterators referring to the elements in the sequence. It is guaranteed
10165 that no reallocation takes place during insertions that happen after a
10166 call to reserve() until the time when an insertion would make the size
10167 of the vector greater than the value of capacity().
10168 </blockquote>
10169
10170 <p><i>[Redmond: original proposed resolution was modified slightly.  In
10171 the original, the guarantee was that there would be no reallocation
10172 until the size would be greater than the value of capacity() after the
10173 most recent call to reserve().  The LWG did not believe that the
10174 "after the most recent call to reserve()" added any useful
10175 information.]</i></p>
10176
10177 <p><b>Rationale:</b></p>
10178 <p>There was general agreement that, when reserve() is called twice in
10179 succession and the argument to the second invocation is smaller than
10180 the argument to the first, the intent was for the second invocation to
10181 have no effect.  Wording implying that such cases have an effect on
10182 reallocation guarantees was inadvertant.</p>
10183 <hr>
10184 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;PremAnand M. Rao&nbsp; <b>Date:</b>&nbsp;23 Aug 2001</p>
10185 <p>
10186 With the change in 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> to state
10187    "An implementation may strengthen the exception-specification for a
10188     non-virtual function by removing listed exceptions."
10189 (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#119">119</a>)
10190 and the following declaration of ~failure() in ios_base::failure
10191 </p>
10192 <pre>    namespace std {
10193        class ios_base::failure : public exception {
10194        public:
10195            ...
10196            virtual ~failure();
10197            ...
10198        };
10199      }
10200 </pre>
10201 <p>the class failure cannot be implemented since in 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.exception"> [lib.exception]</a> the destructor of class exception has an empty
10202 exception specification:</p>
10203 <pre>    namespace std {
10204        class exception {
10205        public:
10206          ...
10207          virtual ~exception() throw();
10208          ...
10209        };
10210      }
10211 </pre>
10212 <p><b>Proposed resolution:</b></p>
10213 <p>Remove the declaration of ~failure().</p>
10214 <p><b>Rationale:</b></p>
10215 <p>The proposed resolution is consistent with the way that destructors
10216 of other classes derived from <tt>exception</tt> are handled.</p>
10217 <hr>
10218 <a name="333"></a><h3><a name="333">333.&nbsp;does endl imply synchronization with the device?</a></h3><p><b>Section:</b>&nbsp;27.6.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;PremAnand M. Rao&nbsp; <b>Date:</b>&nbsp;27 Aug 2001</p>
10219 <p>A footnote in 27.6.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a> states:</p>
10220 <blockquote>
10221     [Footnote: The effect of executing cout &lt;&lt; endl is to insert a
10222      newline character in the output sequence controlled by cout, then
10223      synchronize it with any external file with which it might be
10224      associated. --- end foonote]
10225 </blockquote>
10226
10227 <p>
10228 Does the term "file" here refer to the external device?
10229 This leads to some implementation ambiguity on systems with fully
10230 buffered files where a newline does not cause a flush to the device.
10231 </p>
10232
10233 <p>
10234 Choosing to sync with the device leads to significant performance
10235 penalties for each call to endl, while not sync-ing leads to
10236 errors under special circumstances.
10237 </p>
10238
10239 <p>
10240 I could not find any other statement that explicitly defined
10241 the behavior one way or the other.
10242 </p>
10243 <p><b>Proposed resolution:</b></p>
10244 <p>Remove footnote 300 from section 27.6.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a>.</p>
10245 <p><b>Rationale:</b></p>
10246 <p>We already have normative text saying what <tt>endl</tt> does: it
10247 inserts a newline character and calls <tt>flush</tt>.  This footnote
10248 is at best redundant, at worst (as this issue says) misleading,
10249 because it appears to make promises about what <tt>flush</tt>
10250 does.</p>
10251 <hr>
10252 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andrea Griffini&nbsp; <b>Date:</b>&nbsp;02 Sep 2001</p>
10253 <p>
10254 The current standard describes map::operator[] using a
10255 code example. That code example is however quite
10256 inefficient because it requires several useless copies
10257 of both the passed key_type value and of default
10258 constructed mapped_type instances.
10259 My opinion is that was not meant by the comitee to
10260 require all those temporary copies.
10261 </p>
10262
10263 <p>Currently map::operator[] behaviour is specified as: </p>
10264 <pre>  Returns:
10265     (*((insert(make_pair(x, T()))).first)).second.
10266 </pre>
10267
10268 <p>
10269 This specification however uses make_pair that is a
10270 template function of which parameters in this case
10271 will be deduced being of type const key_type&amp; and
10272 const T&amp;. This will create a pair&lt;key_type,T&gt; that
10273 isn't the correct type expected by map::insert so
10274 another copy will be required using the template
10275 conversion constructor available in pair to build
10276 the required pair&lt;const key_type,T&gt; instance.
10277 </p>
10278
10279 <p>If we consider calling of key_type copy constructor
10280 and mapped_type default constructor and copy
10281 constructor as observable behaviour (as I think we
10282 should) then the standard is in this place requiring
10283 two copies of a key_type element plus a default
10284 construction and two copy construction of a mapped_type
10285 (supposing the addressed element is already present
10286 in the map; otherwise at least another copy
10287 construction for each type).
10288 </p>
10289
10290 <p>A simple (half) solution would be replacing the description with:</p>
10291 <pre>  Returns:
10292     (*((insert(value_type(x, T()))).first)).second.
10293 </pre>
10294
10295 <p>This will remove the wrong typed pair construction that
10296 requires one extra copy of both key and value.</p>
10297
10298 <p>However still the using of map::insert requires temporary
10299 objects while the operation, from a logical point of view,
10300 doesn't require any. </p>
10301
10302 <p>I think that a better solution would be leaving free an
10303 implementer to use a different approach than map::insert
10304 that, because of its interface, forces default constructed
10305 temporaries and copies in this case.
10306 The best solution in my opinion would be just requiring
10307 map::operator[] to return a reference to the mapped_type
10308 part of the contained element creating a default element
10309 with the specified key if no such an element is already
10310 present in the container. Also a logarithmic complexity
10311 requirement should be specified for the operation.
10312 </p>
10313
10314 <p>
10315 This would allow library implementers to write alternative
10316 implementations not using map::insert and reaching optimal
10317 performance in both cases of the addressed element being
10318 present or absent from the map (no temporaries at all and
10319 just the creation of a new pair inside the container if
10320 the element isn't present).
10321 Some implementer has already taken this option but I think
10322 that the current wording of the standard rules that as
10323 non-conforming.
10324 </p>
10325
10326 <p><b>Proposed resolution:</b></p>
10327
10328 <p>
10329 Replace 23.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.map.access"> [lib.map.access]</a> paragraph 1 with
10330 </p>
10331 <blockquote>
10332 <p>
10333 -1- Effects:  If there is no key equivalent to x in the map, inserts
10334 value_type(x, T()) into the map.
10335 </p>
10336 <p>
10337 -2- Returns: A reference to the mapped_type corresponding to x in *this.
10338 </p>
10339 <p>
10340 -3- Complexity: logarithmic.
10341 </p>
10342 </blockquote>
10343
10344 <p><i>[This is the second option mentioned above.  Howard provided
10345 wording.  We may also wish to have a blanket statement somewhere in
10346 clause 17 saying that we do not intend the semantics of sample code
10347 fragments to be interpreted as specifing exactly how many copies are
10348 made.  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#98">98</a> for a similar problem.]</i></p>
10349
10350 <p><b>Rationale:</b></p>
10351 <p>
10352 This is the second solution described above; as noted, it is
10353 consistent with existing practice.
10354 </p>
10355
10356 <p>Note that we now need to specify the complexity explicitly, because
10357 we are no longer defining <tt>operator[]</tt> in terms of
10358 <tt>insert</tt>.</p>
10359 <hr>
10360 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;06 Sep 2001</p>
10361 <p>
10362 Table 37, in 21.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>, descibes char_traits::assign
10363 as:
10364 </p>
10365 <pre>  X::assign(c,d)   assigns c = d.
10366 </pre>
10367
10368 <p>And para 1 says:</p>
10369
10370 <blockquote>
10371  [...] c and d denote values of type CharT [...]
10372 </blockquote>
10373
10374 <p>
10375 Naturally, if c and d are <i>values</i>, then the assignment is
10376 (effectively) meaningless. It's clearly intended that (in the case of
10377 assign, at least), 'c' is intended to be a reference type.
10378 </p>
10379
10380 <p>I did a quick survey of the four implementations I happened to have
10381 lying around, and sure enough they all have signatures:</p>
10382 <pre>    assign( charT&amp;, const charT&amp; );
10383 </pre>
10384
10385 <p>(or the equivalent). It's also described this way in Nico's book.
10386 (Not to mention the synopses of char_traits&lt;char&gt; in 21.1.3.1
10387 and char_traits&lt;wchar_t&gt; in 21.1.3.2...)
10388 </p>
10389 <p><b>Proposed resolution:</b></p>
10390 <p>Add the following to 21.1.1 para 1:</p>
10391 <blockquote>
10392  r denotes an lvalue of CharT
10393 </blockquote>
10394
10395 <p>and change the description of assign in the table to:</p>
10396 <pre>  X::assign(r,d)   assigns r = d
10397 </pre>
10398 <hr>
10399 <a name="336"></a><h3><a name="336">336.&nbsp;Clause 17 lack of references to deprecated headers</a></h3><p><b>Section:</b>&nbsp;17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Detlef Vollmann&nbsp; <b>Date:</b>&nbsp;05 Sep 2001</p>
10400 <p>From c++std-edit-873:</p>
10401
10402 <p>17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.headers"> [lib.headers]</a>, Table 11.  In this table, the header
10403 &lt;strstream&gt; is missing.</p>
10404
10405 <p>This shows a general problem: The whole clause 17 refers quite
10406 often to clauses 18 through 27, but D.7 is also a part of the standard
10407 library (though a deprecated one).</p>
10408
10409 <p><b>Proposed resolution:</b></p>
10410
10411 <p>To 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.headers"> [lib.headers]</a> Table 11, C++ Library Headers, add
10412 "&lt;strstream&gt;".</p>
10413
10414 <p>In the following places, change "clauses 17 through 27" to "clauses
10415 17 through 27 and Annex D":</p>
10416
10417 <ul>
10418 <li>1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/intro.html#intro.refs"> [intro.refs]</a> Normative references/1/footnote 1</li>
10419 <li>1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/intro.html#intro.defs"> [intro.defs]</a> Definitions/1</li>
10420 <li>7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/dcl.html#dcl.dcl"> [dcl.dcl]</a> Library introduction/9</li>
10421 <li>17.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.description"> [lib.description]</a> Method of description (Informative)/1</li>
10422 <li>17.3.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.character.seq"> [lib.character.seq]</a> Character sequences/1/bullet 2</li>
10423 <li>17.3.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.functions.within.classes"> [lib.functions.within.classes]</a> Functions within classes/1</li>
10424 <li>17.3.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.objects.within.classes"> [lib.objects.within.classes]</a> Private members/1/(2 places)</li>
10425 <li>17.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.requirements"> [lib.requirements]</a> Library-wide requirements/1</li>
10426 <li>17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.headers"> [lib.headers]</a> Headers/4</li>
10427 <li>17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> Replacement functions/1</li>
10428 <li>17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.global.functions"> [lib.global.functions]</a> Global or non-member functions/2</li>
10429 <li>17.4.4.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.protection.within.classes"> [lib.protection.within.classes]</a> Protection within classes/1</li>
10430 </ul>
10431
10432
10433 <hr>
10434 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Detlef Vollmann&nbsp; <b>Date:</b>&nbsp;07 Sep 2001</p>
10435 <p>From c++std-edit-876:</p>
10436
10437 <p>
10438 In section 25.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> before p4: The name of the first
10439 parameter of template replace_copy_if should be "InputIterator"
10440 instead of "Iterator".  According to 17.3.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a> p1 the
10441 parameter name conveys real normative meaning.
10442 </p>
10443 <p><b>Proposed resolution:</b></p>
10444 <p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
10445 <hr>
10446 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 Sep 2001</p>
10447 <p>
10448 From Stage 2 processing in 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, p8 and 9 (the
10449 original text or the text corrected by the proposed resolution of
10450 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#221">221</a>) it seems clear that no whitespace is allowed
10451 within a number, but 22.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a>, p2, which gives the
10452 format for integer and floating point values, says that whitespace is
10453 optional between a plusminus and a sign.
10454 </p>
10455
10456 <p>
10457 The text needs to be clarified to either consistently allow or
10458 disallow whitespace between a plusminus and a sign. It might be
10459 worthwhile to consider the fact that the C library stdio facility does
10460 not permit whitespace embedded in numbers and neither does the C or
10461 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/papers/2005/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/papers/2005/lex.html#lex.fcon"> [lex.fcon]</a> of the C++ standard).
10462 </p>
10463 <p><b>Proposed resolution:</b></p>
10464 <p>Change the first part of 22.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a> paragraph 2 from:</p>
10465 <blockquote>
10466 <p>
10467 The syntax for number formats is as follows, where <tt>digit</tt>
10468 represents the radix set specified by the <tt>fmtflags</tt> argument
10469 value, <tt>whitespace</tt> is as determined by the facet
10470 <tt>ctype&lt;charT&gt;</tt> (22.2.1.1), and <tt>thousands-sep</tt> and
10471 <tt>decimal-point</tt> are the results of corresponding
10472 <tt>numpunct&lt;charT&gt;</tt> members.  Integer values have the
10473 format:
10474 </p>
10475 <pre>  integer   ::= [sign] units
10476   sign      ::= plusminus [whitespace]
10477   plusminus ::= '+' | '-'
10478   units     ::= digits [thousands-sep units]
10479   digits    ::= digit [digits]
10480 </pre>
10481 </blockquote>
10482 <p>to:</p>
10483 <blockquote>
10484 <p>
10485 The syntax for number formats is as follows, where <tt>digit</tt>
10486 represents the radix set specified by the <tt>fmtflags</tt> argument
10487 value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
10488 results of corresponding <tt>numpunct&lt;charT&gt;</tt> members.
10489 Integer values have the format:
10490 </p>
10491 <pre>  integer   ::= [sign] units
10492   sign      ::= plusminus
10493   plusminus ::= '+' | '-'
10494   units     ::= digits [thousands-sep units]
10495   digits    ::= digit [digits]
10496 </pre>
10497 </blockquote>
10498 <p><b>Rationale:</b></p>
10499 <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/papers/2005/lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a> paragraph 2 has any normative weight: nothing in the
10500 standard says how, or whether, it's used.  However, there's no reason
10501 for it to differ gratuitously from the very specific description of
10502 numeric processing in 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>.  The proposed
10503 resolution removes all mention of "whitespace" from that format.</p>
10504 <hr>
10505 <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/papers/2005/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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 September 2001</p>
10506 <p>
10507 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/papers/2005/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a> with p1 then stating that it is a bitmask type, most
10508 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/papers/2005/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>, p1. However, the said definition only applies to
10509 clause 27, making the reference in 22.2.1 somewhat dubious.
10510 </p>
10511 <p><b>Proposed resolution:</b></p>
10512 <p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
10513     <blockquote>
10514     Several types defined in clause 27 are bitmask types. Each bitmask type
10515     can be implemented as an enumerated type that overloads certain operators,
10516     as an integer type, or as a bitset (23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>).
10517     </blockquote>
10518 <p>to read</p>
10519     <blockquote>
10520     Several types defined in clauses lib.language.support through
10521     lib.input.output and Annex D are bitmask types. Each bitmask type can
10522     be implemented as an enumerated type that overloads certain operators,
10523     as an integer  type, or as a bitset (lib.template.bitset).
10524     </blockquote>
10525
10526 <p>
10527 Additionally, change the definition in 22.2.1 to adopt the same
10528 convention as in clause 27 by replacing the existing text with the
10529 following (note, in particluar, the cross-reference to 17.3.2.1.2 in
10530 22.2.1, p1):
10531 </p>
10532
10533 <blockquote>
10534 <p>22.2.1 The ctype category [lib.category.ctype]</p>
10535 <pre>namespace std {
10536     class ctype_base {
10537     public:
10538         typedef <b><i>T</i></b> mask;
10539
10540         // numeric values are for exposition only.
10541         static const mask space = 1 &lt;&lt; 0;
10542         static const mask print = 1 &lt;&lt; 1;
10543         static const mask cntrl = 1 &lt;&lt; 2;
10544         static const mask upper = 1 &lt;&lt; 3;
10545         static const mask lower = 1 &lt;&lt; 4;
10546         static const mask alpha = 1 &lt;&lt; 5;
10547         static const mask digit = 1 &lt;&lt; 6;
10548         static const mask punct = 1 &lt;&lt; 7;
10549         static const mask xdigit = 1 &lt;&lt; 8;
10550         static const mask alnum = alpha | digit;
10551         static const mask graph = alnum | punct;
10552     };
10553 }
10554 </pre>
10555
10556 <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/papers/2005/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>).</p>
10557 </blockquote>
10558
10559 <p><i>[Curaçao: The LWG notes that T above should be bold-italics to be
10560 consistent with the rest of the standard.]</i></p>
10561
10562 <hr>
10563 <a name="340"><h3>340.&nbsp;interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt>
10564 </h3></a><p><b>Section:</b>&nbsp;22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2001</p>
10565 <p>
10566 It's unclear whether 22.1.1.1.1, p3 says that
10567 <tt>has_facet&lt;Facet&gt;(loc)</tt> returns true for any <tt>Facet</tt>
10568 from Table 51 or whether it includes Table 52 as well:
10569 </p>
10570
10571 <blockquote>
10572 For any locale <tt>loc</tt> either constructed, or returned by
10573 locale::classic(), and any facet <tt>Facet</tt> that is a member of a
10574 standard category, <tt>has_facet&lt;Facet&gt;(loc)</tt> is true. Each
10575 locale member function which takes a <tt>locale::category</tt>
10576 argument operates on the corresponding set of facets.
10577 </blockquote>
10578
10579 <p>
10580 It seems that it comes down to which facets are considered to be members of a
10581 standard category. Intuitively, I would classify all the facets in Table 52 as
10582 members of their respective standard categories, but there are an unbounded set
10583 of them...
10584 </p>
10585
10586 <p>
10587 The paragraph implies that, for instance, <tt>has_facet&lt;num_put&lt;C,
10588 OutputIterator&gt; &gt;(loc)</tt> must always return true. I don't think that's
10589 possible. If it were, then <tt>use_facet&lt;num_put&lt;C, OutputIterator&gt;
10590 &gt;(loc)</tt> would have to return a reference to a distinct object for each
10591 valid specialization of <tt>num_put&lt;C, OutputIteratory&gt;</tt>, which is
10592 clearly impossible.
10593 </p>
10594
10595 <p>
10596 On the other hand, if none of the facets in Table 52 is a member of a standard
10597 category then none of the locale member functions that operate on entire
10598 categories of facets will work properly.
10599 </p>
10600
10601 <p>
10602 It seems that what p3 should mention that it's required (permitted?)
10603 to hold only for specializations of <tt>Facet</tt> from Table 52 on
10604 <tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
10605 <tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
10606 {
10607 {i,o}<tt>streambuf_iterator</tt>&lt;{<tt>char</tt>,<tt>wchar_t</tt>}<tt>&gt;</tt>
10608 }.
10609 </p>
10610 <p><b>Proposed resolution:</b></p>
10611 <p>In 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, paragraph 3, change
10612 "that is a member of a standard category" to "shown in Table 51".</p>
10613 <p><b>Rationale:</b></p>
10614 <p>The facets in Table 52 are an unbounded set.  Locales should not be
10615 required to contain an infinite number of facets.</p>
10616
10617 <p>It's not necessary to talk about which values of InputIterator and
10618 OutputIterator must be supported.  Table 51 already contains a
10619 complete list of the ones we need.</p>
10620 <hr>
10621 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;27 Sep 2001</p>
10622 <p>It is a common idiom to reduce the capacity of a vector by swapping it with
10623 an empty one:</p>
10624 <pre>  std::vector&lt;SomeType&gt; vec;
10625   // fill vec with data
10626   std::vector&lt;SomeType&gt;().swap(vec);
10627   // vec is now empty, with minimal capacity
10628 </pre>
10629
10630 <p>However, the wording of 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>paragraph 5 prevents
10631 the capacity of a vector being reduced, following a call to
10632 reserve(). This invalidates the idiom, as swap() is thus prevented
10633 from reducing the capacity. The proposed wording for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#329">329</a> does not affect this.  Consequently, the example above
10634 requires the temporary to be expanded to cater for the contents of
10635 vec, and the contents be copied across. This is a linear-time
10636 operation.</p>
10637
10638 <p>However, the container requirements state that swap must have constant
10639 complexity (23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> note to table 65).</p>
10640
10641 <p>This is an important issue, as reallocation affects the validity of
10642 references and iterators.</p>
10643
10644 <p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
10645 references and iterators remain valid after a call to swap, if they refer to
10646 an element before the new end() of the vector into which they originally
10647 pointed, in which case they refer to the element at the same index position.
10648 Iterators and references that referred to an element whose index position
10649 was beyond the new end of the vector are invalidated.</p>
10650
10651 <p>If the note to table 65 is taken as the desired intent, then there are two
10652 possibilities with regard to iterators and references:</p>
10653
10654 <ol>
10655 <li>All Iterators and references into both vectors are invalidated.</li>
10656 <li>Iterators and references into either vector remain valid, and remain
10657 pointing to the same element. Consequently iterators and references that
10658 referred to one vector now refer to the other, and vice-versa.</li>
10659 </ol>
10660 <p><b>Proposed resolution:</b></p>
10661 <p>Add a new paragraph after 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> paragraph 5:</p>
10662 <blockquote>
10663 <pre>  void swap(vector&lt;T,Allocator&gt;&amp; x);
10664 </pre>
10665 <p><b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
10666 with that of <tt>x</tt>.</p>
10667 <p><b>Complexity:</b> Constant time.</p>
10668 </blockquote>
10669
10670 <p><i>[This solves the problem reported for this issue.  We may also
10671 have a problem with a circular definition of swap() for other
10672 containers.]</i></p>
10673
10674 <p><b>Rationale:</b></p>
10675 <p>
10676 swap should be constant time.  The clear intent is that it should just
10677 do pointer twiddling, and that it should exchange all properties of
10678 the two vectors, including their reallocation guarantees.
10679 </p>
10680 <hr>
10681 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Clark Nelson&nbsp; <b>Date:</b>&nbsp;19 Oct 2001</p>
10682 <p>
10683 C99, and presumably amendment 1 to C90, specify that &lt;wchar.h&gt;
10684 declares struct tm as an incomplete type. However, table 48 in 21.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.c.strings"> [lib.c.strings]</a> does not mention the type tm as being declared in
10685 &lt;cwchar&gt;. Is this omission intentional or accidental?
10686 </p>
10687 <p><b>Proposed resolution:</b></p>
10688 <p>In section 21.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.c.strings"> [lib.c.strings]</a>, add "tm" to table 48.</p>
10689 <hr>
10690 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Jeremy Siek&nbsp; <b>Date:</b>&nbsp;20 Oct 2001</p>
10691 <p>Iterator member functions and operators that do not change the state
10692 of the iterator should be defined as const member functions or as
10693 functions that take iterators either by const reference or by
10694 value. The standard does not explicitly state which functions should
10695 be const.  Since this a fairly common mistake, the following changes
10696 are suggested to make this explicit.</p>
10697
10698 <p>The tables almost indicate constness properly through naming: r
10699 for non-const and a,b for const iterators. The following changes
10700 make this more explicit and also fix a couple problems.</p>
10701 <p><b>Proposed resolution:</b></p>
10702 <p>In 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> Change the first section of p9 from
10703 "In the following sections, a and b denote values of X..." to
10704 "In the following sections, a and b denote values of type const X...".</p>
10705
10706 <p>In Table 73, change</p>
10707 <pre>    a-&gt;m   U&amp;         ...
10708 </pre>
10709
10710 <p>to</p>
10711
10712 <pre>    a-&gt;m   const U&amp;   ...
10713     r-&gt;m   U&amp;         ...
10714 </pre>
10715
10716 <p>In Table 73 expression column, change</p>
10717
10718 <pre>    *a = t
10719 </pre>
10720
10721 <p>to</p>
10722
10723 <pre>    *r = t
10724 </pre>
10725
10726 <p><i>[Redmond: The container requirements should be reviewed to see if
10727 the same problem appears there.]</i></p>
10728
10729 <hr>
10730 <a name="347"></a><h3><a name="347">347.&nbsp;locale::category and bitmask requirements</a></h3><p><b>Section:</b>&nbsp;22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/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>
10731 <p>
10732 In 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> paragraph 1, the category members
10733 are described as bitmask elements.  In fact, the bitmask requirements
10734 in 17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a> don't seem quite right: <tt>none</tt>
10735 and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
10736
10737 <p>In particular, the requirements for <tt>none</tt> interact poorly
10738 with the requirement that the LC_* constants from the C library must
10739 be recognizable as C++ locale category constants.  LC_* values should
10740 not be mixed with these values to make category values.</p>
10741
10742 <p>We have two options for the proposed resolution.  Informally:
10743 option 1 removes the requirement that LC_* values be recognized as
10744 category arguments.  Option 2 changes the category type so that this
10745 requirement is implementable, by allowing <tt>none</tt> to be some
10746 value such as 0x1000 instead of 0.</p>
10747
10748 <p>Nathan writes: "I believe my proposed resolution [Option 2] merely
10749 re-expresses the status quo more clearly, without introducing any
10750 changes beyond resolving the DR.</p>
10751
10752 <p><b>Proposed resolution:</b></p>
10753 <p>Replace the first two paragraphs of 22.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.types"> [lib.locale.types]</a> with:</p>
10754 <blockquote>
10755 <pre>    typedef int category;
10756 </pre>
10757
10758 <p>Valid category values include the <tt>locale</tt> member bitmask
10759 elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
10760 <tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
10761 represents a single locale category. In addition, <tt>locale</tt> member
10762 bitmask constant <tt>none</tt> is defined as zero and represents no
10763 category. And locale member bitmask constant <tt>all</tt> is defined such that
10764 the expression</p>
10765 <pre>    (collate | ctype | monetary | numeric | time | messages | all) == all
10766 </pre>
10767 <p>
10768 is <tt>true</tt>, and represents the union of all categories.  Further
10769 the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
10770 represent a single category, represents the union of the two
10771 categories.
10772 </p>
10773
10774 <p>
10775 <tt>locale</tt> member functions expecting a <tt>category</tt>
10776 argument require one of the <tt>category</tt> values defined above, or
10777 the union of two or more such values. Such a <tt>category</tt>
10778 argument identifies a set of locale categories. Each locale category,
10779 in turn, identifies a set of locale facets, including at least those
10780 shown in Table 51:
10781 </p>
10782 </blockquote>
10783 <p><i>[Curaçao: need input from locale experts.]</i></p>
10784
10785 <p><b>Rationale:</b></p>
10786
10787 <p>The LWG considered, and rejected, an alternate proposal (described
10788   as "Option 2" in the discussion).  The main reason for rejecting it
10789   was that library implementors were concerened about implementation
10790   difficult, given that getting a C++ library to work smoothly with a
10791   separately written C library is already a delicate business.  Some
10792   library implementers were also concerned about the issue of adding
10793   extra locale categories.</p>
10794
10795 <blockquote>
10796 <p><b>Option 2:</b> <br>
10797 Replace the first paragraph of 22.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.types"> [lib.locale.types]</a> with:</p>
10798 <blockquote>
10799 <p>
10800 Valid category values include the enumerated values.  In addition, the
10801 result of applying commutative operators | and &amp; to any two valid
10802 values is valid, and results in the setwise union and intersection,
10803 respectively, of the argument categories.  The values <tt>all</tt> and
10804 <tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
10805 expressions <tt>(cat | all == all)</tt>, <tt>(cat &amp; all == cat)</tt>,
10806 <tt>(cat | none == cat)</tt> and <tt>(cat &amp; none == none)</tt> are
10807 true.  For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
10808 remaining enumerated values, <tt>(cat1 &amp; cat2 == none)</tt> is true.
10809 For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
10810 of <tt>(cat1 &amp; ~cat2)</tt> is valid, and equals the setwise union of
10811 those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
10812 [Footnote: it is not required that <tt>all</tt> equal the setwise union
10813 of the other enumerated values; implementations may add extra categories.]
10814 </p>
10815 </blockquote>
10816 </blockquote>
10817 <hr>
10818 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;24 Oct 2001</p>
10819 <p>24.5.2 [lib.ostream.iterator] states:</p>
10820 <pre>    [...]
10821
10822     private:
10823     // basic_ostream&lt;charT,traits&gt;* out_stream; exposition only
10824     // const char* delim; exposition only
10825 </pre>
10826
10827 <p>Whilst it's clearly marked "exposition only", I suspect 'delim'
10828 should be of type 'const charT*'.</p>
10829 <p><b>Proposed resolution:</b></p>
10830 <p>
10831 In 24.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterator]</a>, replace <tt>const char* delim</tt> with
10832 <tt>const charT* delim</tt>.
10833 </p>
10834 <hr>
10835 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;2 Dec 2001</p>
10836 <p>
10837 <i>(1)</i>
10838 There are no requirements on the <tt>stateT</tt> template parameter of
10839 <tt>fpos</tt> listed in 27.4.3. The interface appears to require that
10840 the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
10841 and I think also DefaultConstructible (to implement the operations in
10842 Table 88).
10843 </p>
10844 <p>
10845 21.1.2, p3, however, only requires that
10846 <tt>char_traits&lt;charT&gt;::state_type</tt> meet the requirements of
10847 CopyConstructible types.
10848 </p>
10849 <p>
10850 <i>(2)</i>
10851 Additionally, the <tt>stateT</tt> template argument has no
10852 corresponding typedef in fpos which might make it difficult to use in
10853 generic code.
10854 </p>
10855 <p><b>Proposed resolution:</b></p>
10856 <p>
10857 Modify 21.1.2, p4 from
10858 </p>
10859 <p>
10860     Requires: <tt>state_type</tt> shall meet the requirements of
10861               CopyConstructible types (20.1.3).
10862 </p>
10863 <p>
10864     Requires: state_type shall meet the requirements of Assignable
10865               (23.1, p4), CopyConstructible (20.1.3), and
10866               DefaultConstructible  (20.1.4) types.
10867 </p>
10868
10869 <p><b>Rationale:</b></p>
10870 <p>The LWG feels this is two issues, as indicated above. The first is
10871 a defect---std::basic_fstream is unimplementable without these
10872 additional requirements---and the proposed resolution fixes it.  The
10873 second is questionable; who would use that typedef?  The class
10874 template fpos is used only in a very few places, all of which know the
10875 state type already.  Unless motivation is provided, the second should
10876 be considered NAD.</p>
10877 <hr>
10878 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Aberg&nbsp; <b>Date:</b>&nbsp;17 Dec 2001</p>
10879 <p>
10880 Discussions in the thread "Associative container lower/upper bound
10881 requirements" on comp.std.c++ suggests that there is a defect in the
10882 C++ standard, Table 69 of section 23.1.2, "Associative containers",
10883 [lib.associative.reqmts].  It currently says:</p>
10884
10885 <blockquote>
10886 <p>
10887 a.find(k): returns an iterator pointing to an element with the key equivalent to
10888 k, or a.end() if such an element is not found.
10889 </p>
10890
10891 <p>
10892 a.lower_bound(k): returns an iterator pointing to the first element with
10893 key not less than k.
10894 </p>
10895
10896 <p>
10897 a.upper_bound(k): returns an iterator pointing to the first element with
10898 key greater than k.
10899 </p>
10900 </blockquote>
10901
10902 <p>
10903 We have "or a.end() if such an element is not found" for
10904 <tt>find</tt>, but not for <tt>upper_bound</tt> or
10905 <tt>lower_bound</tt>.  As the text stands, one would be forced to
10906 insert a new element into the container and return an iterator to that
10907 in case the sought iterator does not exist, which does not seem to be
10908 the intention (and not possible with the "const" versions).
10909 </p>
10910 <p><b>Proposed resolution:</b></p>
10911
10912 <p>Change Table 69 of section 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> indicated entries
10913 to:</p>
10914
10915 <blockquote>
10916 <p>
10917 a.lower_bound(k): returns an iterator pointing to the first element with
10918 key not less than k, or a.end() if such an element is not found.
10919 </p>
10920
10921 <p>
10922 a.upper_bound(k): returns an iterator pointing to the first element with
10923 key greater than k, or a.end() if such an element is not found.
10924 </p>
10925 </blockquote>
10926
10927 <p><i>[Curaçao: LWG reviewed PR.]</i></p>
10928
10929 <hr>
10930 <a name="355"><h3>355.&nbsp;Operational semantics for a.back()</h3></a><p><b>Section:</b>&nbsp;23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Yaroslav Mironov&nbsp; <b>Date:</b>&nbsp;23 Jan 2002</p>
10931
10932 <p>Table 68 "Optional Sequence Operations" in 23.1.1/12
10933 specifies operational semantics for "a.back()" as
10934 "*--a.end()", which may be ill-formed <i>[because calling
10935 operator-- on a temporary (the return) of a built-in type is
10936 ill-formed]</i>, provided a.end() returns a simple pointer rvalue
10937 (this is almost always the case for std::vector::end(), for
10938 example). Thus, the specification is not only incorrect, it
10939 demonstrates a dangerous construct: "--a.end()" may
10940 successfully compile and run as intended, but after changing the type
10941 of the container or the mode of compilation it may produce
10942 compile-time error. </p>
10943
10944 <p><b>Proposed resolution:</b></p>
10945 <p>Change the specification in table 68 "Optional Sequence
10946 Operations" in 23.1.1/12 for "a.back()" from</p>
10947
10948
10949 <blockquote>
10950 *--a.end()
10951 </blockquote>
10952
10953 <p>to</p>
10954
10955 <blockquote>
10956   { iterator tmp = a.end(); --tmp; return *tmp; }
10957 </blockquote>
10958
10959 <p>and the specification for "a.pop_back()" from</p>
10960
10961 <blockquote>
10962 a.erase(--a.end())
10963 </blockquote>
10964
10965 <p>to</p>
10966
10967 <blockquote>
10968   { iterator tmp = a.end(); --tmp; a.erase(tmp); }
10969 </blockquote>
10970
10971 <p><i>[Curaçao: LWG changed PR from "{ X::iterator tmp =
10972 a.end(); return *--tmp; }" to "*a.rbegin()", and from
10973 "{ X::iterator tmp = a.end(); a.erase(--tmp); }" to
10974 "a.erase(rbegin())".]</i></p>
10975
10976 <p><i>[There is a second possible defect; table 68 "Optional
10977 Sequence Operations" in the "Operational Semantics"
10978 column uses operations present only in the "Reversible
10979 Container" requirements, yet there is no stated dependency
10980 between these separate requirements tables. Ask in Santa Cruz if the
10981 LWG would like a new issue opened.]</i></p>
10982
10983 <p><i>[Santa Cruz: the proposed resolution is even worse than what's in
10984   the current standard: erase is undefined for reverse iterator.  If
10985   we're going to make the change, we need to define a temporary and
10986   use operator--.  Additionally, we don't know how prevalent this is:
10987   do we need to make this change in more than one place?  Martin has
10988   volunteered to review the standard and see if this problem occurs
10989   elsewhere.]</i></p>
10990
10991 <p><i>[Oxford: Matt provided new wording to address the concerns raised
10992   in Santa Cruz.  It does not appear that this problem appears
10993   anywhere else in clauses 23 or 24.]</i></p>
10994
10995 <p><i>[Kona: In definition of operational semantics of back(), change
10996 "*tmp" to "return *tmp;"]</i></p>
10997
10998 <hr>
10999 <a name="358"><h3>358.&nbsp;interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt>
11000 </h3></a><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
11001 <p>
11002 I don't think <tt>thousands_sep</tt> is being treated correctly after
11003 decimal_point has been seen. Since grouping applies only to the
11004 integral part of the number, the first such occurrence should, IMO,
11005 terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
11006 and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
11007 interpreted in the fractional part of a number.)
11008 </p>
11009
11010 <p>
11011 The easiest change I can think of that resolves this issue would be
11012 something like below.
11013 </p>
11014 <p><b>Proposed resolution:</b></p>
11015 <p>
11016 Change the first sentence of 22.2.2.1.2, p9 from
11017 </p>
11018
11019 <blockquote>
11020     If discard is true then the position of the character is
11021     remembered, but the character is otherwise ignored. If it is not
11022     discarded, then a check is made to determine if c is allowed as
11023     the next character of an input field of the conversion specifier
11024     returned by stage 1. If so it is accumulated.
11025 </blockquote>
11026
11027 <p>to</p>
11028
11029 <blockquote>
11030     If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
11031     accumulated, then the position of the character is remembered, but
11032     the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
11033     already been accumulated, the character is discarded and Stage 2
11034      terminates. ...
11035 </blockquote>
11036
11037 <p><b>Rationale:</b></p>
11038 <p>We believe this reflects the intent of the Standard.  Thousands sep
11039   characters after the decimal point are not useful in any locale.
11040   Some formatting conventions do group digits that follow the decimal
11041   point, but they usually introduce a different grouping character
11042   instead of reusing the thousand sep character.  If we want to add
11043   support for such conventions, we need to do so explicitly.</p>
11044
11045 <hr>
11046 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
11047 <p>22.2.2.2.1, p1:</p>
11048
11049     <pre>    iter_type put (iter_type out, ios_base&amp; str, char_type fill,
11050                    bool val) const;
11051     ...
11052
11053     1   Returns: do_put (out, str, fill, val).
11054     </pre>
11055
11056 <p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
11057 however, 22.2.2.2.2, p23:</p>
11058
11059 <blockquote>
11060 <pre>iter_type put (iter_type out, ios_base&amp; str, char_type fill,
11061                bool val) const;
11062 </pre>
11063
11064
11065         Effects: If (str.flags() &amp; ios_base::boolalpha) == 0 then do
11066              out = do_put(out, str, fill, (int)val)
11067            Otherwise do
11068 <pre>             string_type s =
11069                  val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
11070                      : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
11071 </pre>
11072            and then insert the characters of s into out. <i>out</i>.
11073 </blockquote>
11074
11075 <p>
11076 This means that the bool overload of <tt>do_put()</tt> will never be called,
11077 which contradicts the first paragraph. Perhaps the declaration
11078 should read <tt>do_put()</tt>, and not <tt>put()</tt>?
11079 </p>
11080
11081 <p>
11082 Note also that there is no <b>Returns</b> clause for this function, which
11083 should probably be corrected, just as should the second occurrence
11084 of <i>"out."</i> in the text.
11085 </p>
11086
11087 <p>
11088 I think the least invasive change to fix it would be something like
11089 the following:
11090 </p>
11091 <p><b>Proposed resolution:</b></p>
11092 <p>In 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, just above paragraph 1, remove
11093   the <tt>bool</tt> overload.</p>
11094
11095 <p>
11096 In 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, p23, make the following changes
11097 </p>
11098
11099 <blockquote>
11100      Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
11101      of the member function.
11102 </blockquote>
11103
11104 <blockquote>
11105     Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
11106     avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
11107     do_put (..., bool))</tt>
11108     like so:
11109 </blockquote>
11110
11111 <blockquote>
11112     23   <b>Returns</b>: If <tt>(str.flags() &amp;
11113          ios_base::boolalpha) == 0</tt> then
11114          <tt>do_put (out, str, fill, (long)val)</tt>
11115          Otherwise the function obtains a string <tt>s</tt> as if by
11116 <pre>             string_type s =
11117                 val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
11118                     : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
11119 </pre>
11120          and then inserts each character <tt>c</tt> of s into out via
11121            <tt>*out++ = c</tt>
11122          and returns <tt>out</tt>.
11123 </blockquote>
11124
11125 <p><b>Rationale:</b></p>
11126 <p>
11127 This fixes a couple of obvious typos, and also fixes what appears to
11128 be a requirement of gratuitous inefficiency.
11129 </p>
11130 <hr>
11131 <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/papers/2005/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
11132 <p>
11133 22.1.1, p7 (copied below) allows iostream formatters and extractors
11134 to make assumptions about the values returned from facet members.
11135 However, such assumptions are apparently not guaranteed to hold
11136 in other cases (e.g., when the facet members are being called directly
11137 rather than as a result of iostream calls, or between successive
11138 calls to the same iostream functions with no interevening calls to
11139 <tt>imbue()</tt>, or even when the facet member functions are called
11140 from other member functions of other facets). This restriction
11141 prevents locale from being implemented efficiently.
11142 </p>
11143 <p><b>Proposed resolution:</b></p>
11144 <p>Change the first sentence in 22.1.1, p7 from</p>
11145 <blockquote>
11146     In successive calls to a locale facet member function during
11147     a call to an iostream inserter or extractor or a streambuf member
11148     function, the returned result shall be identical. [Note: This
11149     implies that such results may safely be reused without calling
11150     the locale facet member function again, and that member functions
11151     of iostream classes cannot safely call <tt>imbue()</tt>
11152     themselves, except as specified elsewhere. --end note]
11153 </blockquote>
11154
11155 <p>to</p>
11156
11157 <blockquote>
11158     In successive calls to a locale facet member function on a facet
11159     object installed in the same locale, the returned result shall be
11160     identical. ...
11161 </blockquote>
11162
11163 <p><b>Rationale:</b></p>
11164 <p>This change is reasonable becuase it clarifies the intent of this
11165   part of the standard.</p>
11166 <hr>
11167 <a name="363"></a><h3><a name="363">363.&nbsp;Missing exception specification in 27.4.2.1.1</a></h3><p><b>Section:</b>&nbsp;27.4.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/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>
11168 <p>
11169 The destructor of ios_base::failure should have an empty throw
11170 specification, because the destructor of its base class, exception, is
11171 declared in this way.
11172 </p>
11173 <p><b>Proposed resolution:</b></p>
11174 <p>Change the destructor to</p>
11175 <pre>  virtual ~failure() throw();
11176 </pre>
11177 <p><b>Rationale:</b></p>
11178 <p>Fixes an obvious glitch.  This is almost editorial.</p>
11179 <hr>
11180 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown, Marc Paterno&nbsp; <b>Date:</b>&nbsp;10 May 2002</p>
11181 <p>
11182 27.5.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a> paragraph 1 is inconsistent with the Effects
11183 clause for seekoff.
11184 </p>
11185 <p><b>Proposed resolution:</b></p>
11186 <p>
11187 Make this paragraph, the Effects clause for setbuf, consistent in wording
11188 with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
11189 to indicate the purpose of setbuf:
11190 </p>
11191
11192 <p>Original text:</p>
11193
11194 <blockquote>
11195 1 Effects: Performs an operation that is defined separately for each
11196 class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
11197 </blockquote>
11198
11199 <p>Proposed text:</p>
11200
11201 <blockquote>
11202 1 Effects: Influences stream buffering in a way that is defined separately
11203 for each class derived from basic_streambuf in this clause
11204 (27.7.1.3, 27.8.1.4).
11205 </blockquote>
11206
11207 <p><b>Rationale:</b></p>
11208 <p>The LWG doesn't believe there is any normative difference between
11209   the existing wording and what's in the proposed resolution, but the
11210   change may make the intent clearer.</p>
11211 <hr>
11212 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown, Marc Paterno&nbsp; <b>Date:</b>&nbsp;10 May 2002</p>
11213 <p>
11214 Some stream and streambuf member functions are declared non-const,
11215 even thought they appear only to report information rather than to
11216 change an object's logical state.  They should be declared const.  See
11217 document N1360 for details and rationale.
11218 </p>
11219
11220 <p>The list of member functions under discussion: <tt>in_avail</tt>,
11221 <tt>showmanyc</tt>, <tt>tellg</tt>, <tt>tellp</tt>, <tt>is_open</tt>.</p>
11222
11223 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#73">73</a></p>
11224
11225 <p><b>Proposed resolution:</b></p>
11226 <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>
11227 <p>Replace</p>
11228 <pre>  bool is_open();
11229 </pre>
11230 <p>with</p>
11231 <pre>  bool is_open() const;
11232 </pre>
11233 <p><b>Rationale:</b></p>
11234 <p>Of the changes proposed in N1360, the only one that is safe is
11235 changing the filestreams' is_open to const.  The LWG believed that
11236 this was NAD the first time it considered this issue (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#73">73</a>), but now thinks otherwise.  The corresponding streambuf
11237 member function, after all,is already const.</p>
11238
11239 <p>The other proposed changes are less safe, because some streambuf
11240 functions that appear merely to report a value do actually perform
11241 mutating operations.  It's not even clear that they should be
11242 considered "logically const", because streambuf has two interfaces, a
11243 public one and a protected one.  These functions may, and often do,
11244 change the state as exposed by the protected interface, even if the
11245 state exposed by the public interface is unchanged.</p>
11246
11247 <p>Note that implementers can make this change in a binary compatible
11248 way by providing both overloads; this would be a conforming extension.</p>
11249
11250 <hr>
11251 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;15 Jul 2002</p>
11252 <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/papers/2005/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), paragraph 15. The description for the get function
11253 with the following signature:</p>
11254
11255 <pre>  basic_istream&lt;charT,traits&gt;&amp; get(basic_streambuf&lt;char_type,traits&gt;&amp;
11256   sb);
11257 </pre>
11258
11259 <p>is incorrect. It reads</p>
11260
11261 <blockquote>
11262   Effects: Calls get(s,n,widen('\n'))
11263 </blockquote>
11264
11265 <p>which I believe should be:</p>
11266
11267 <blockquote>
11268   Effects: Calls get(sb,widen('\n'))
11269 </blockquote>
11270 <p><b>Proposed resolution:</b></p>
11271 <p>Change the <b>Effects</b> paragraph to:</p>
11272 <blockquote>
11273   Effects: Calls get(sb,this-&gt;widen('\n'))
11274 </blockquote>
11275
11276 <p><i>[Pre-Oxford: Minor correction from Howard: replaced 'widen'
11277       with 'this-&gt;widen'.]</i></p>
11278
11279 <p><b>Rationale:</b></p>
11280 <p>Fixes an obvious typo.</p>
11281 <hr>
11282 <a name="373"><h3>373.&nbsp;Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</h3></a><p><b>Section:</b>&nbsp;27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Keith Baker&nbsp; <b>Date:</b>&nbsp;23 Jul 2002</p>
11283
11284 <p>
11285 In 27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>
11286 (exception()&amp;badbit) != 0 is used in testing for rethrow, yet
11287 exception() is the constructor to class std::exception in 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.exception"> [lib.exception]</a> that has no return type. Should member function
11288 exceptions() found in 27.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ios"> [lib.ios]</a> be used instead?
11289 </p>
11290
11291 <p><b>Proposed resolution:</b></p>
11292 <p>
11293 In 27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>, change
11294 "(exception()&amp;badbit) != 0" to "(exceptions()&amp;badbit) != 0".
11295 </p>
11296 <p><b>Rationale:</b></p>
11297 <p>Fixes an obvious typo.</p>
11298 <hr>
11299 <a name="375"><h3>375.&nbsp;basic_ios should be ios_base in 27.7.1.3</h3></a><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
11300 <p>
11301 In Section 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>: Table 90, Table 91, and paragraph
11302 14 all contain references to "basic_ios::" which should be
11303 "ios_base::".
11304 </p>
11305 <p><b>Proposed resolution:</b></p>
11306 <p>
11307 Change all references to "basic_ios" in Table 90, Table 91, and
11308 paragraph 14 to "ios_base".
11309 </p>
11310 <p><b>Rationale:</b></p>
11311 <p>Fixes an obvious typo.</p>
11312 <hr>
11313 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
11314 <p>
11315 The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
11316 </p>
11317 <pre>  charT do_widen (char c) const;
11318
11319   -11- Effects: Applies the simplest reasonable transformation from
11320        a char value or sequence of char values to the corresponding
11321        charT value or values. The only characters for which unique
11322        transformations are required are those in the basic source
11323        character set (2.2). For any named ctype category with a
11324        ctype&lt;charT&gt; facet ctw and valid ctype_base::mask value
11325        M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
11326 </pre>
11327 <p>
11328 Shouldn't the last sentence instead read
11329 </p>
11330 <pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
11331        and valid ctype_base::mask value M
11332        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
11333 </pre>
11334 <p>
11335 I.e., if the narrow character c is not a member of a class of
11336 characters then neither is the widened form of c. (To paraphrase
11337 footnote 224.)
11338 </p>
11339 <p><b>Proposed resolution:</b></p>
11340 <p>
11341 Replace the last sentence of 22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>, p11 with the
11342 following text:
11343 </p>
11344 <pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
11345        and valid ctype_base::mask value M,
11346        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
11347 </pre>
11348
11349 <p><i>[Kona: Minor edit. Added a comma after the <i>M</i> for clarity.]</i></p>
11350
11351 <p><b>Rationale:</b></p>
11352 <p>The LWG believes this is just a typo, and that this is the correct fix.</p>
11353 <hr>
11354 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
11355 <p>
11356 Tables 53 and 54 in 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> are both titled "convert
11357 result values," when surely "do_in/do_out result values" must have
11358 been intended for Table 53 and "do_unshift result values" for Table
11359 54.
11360 </p>
11361 <p>
11362 Table 54, row 3 says that the meaning of partial is "more characters
11363 needed to be supplied to complete termination." The function is not
11364 supplied any characters, it is given a buffer which it fills with
11365 characters or, more precisely, destination elements (i.e., an escape
11366 sequence). So partial means that space for more than (to_limit - to)
11367 destination elements was needed to terminate a sequence given the
11368 value of state.
11369 </p>
11370 <p><b>Proposed resolution:</b></p>
11371 <p>
11372 Change the title of Table 53 to "do_in/do_out result values" and
11373 the title of Table 54 to "do_unshift result values."
11374 </p>
11375 <p>
11376 Change the text in Table 54, row 3 (the <b>partial</b> row), under the
11377 heading Meaning, to "space for more than (to_limit - to) destination
11378 elements was needed to terminate a sequence given the value of state."
11379 </p>
11380 <hr>
11381 <a name="381"><h3>381.&nbsp;detection of invalid mbstate_t in codecvt</h3></a><p><b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
11382 <p>
11383 All but one codecvt member functions that take a state_type argument
11384 list as one of their preconditions that the state_type argument have
11385 a valid value. However, according to 22.2.1.5.2, p6,
11386 codecvt::do_unshift() is the only codecvt member that is supposed to
11387 return error if the state_type object is invalid.
11388 </p>
11389
11390 <p>
11391 It seems to me that the treatment of state_type by all codecvt member
11392 functions should be the same and the current requirements should be
11393 changed. Since the detection of invalid state_type values may be
11394 difficult in general or computationally expensive in some specific
11395 cases, I propose the following:
11396 </p>
11397 <p><b>Proposed resolution:</b></p>
11398 <p>
11399 Add a new paragraph before 22.2.1.5.2, p5, and after the function
11400 declaration below
11401 </p>
11402 <pre>    result do_unshift(stateT&amp; state,
11403     externT* to, externT* to_limit, externT*&amp; to_next) const;
11404 </pre>
11405 <p>
11406 as follows:
11407 </p>
11408 <pre>    Requires: (to &lt;= to_end) well defined and true; state initialized,
11409     if at the beginning of a sequence, or else equal to the result of
11410     converting the preceding characters in the sequence.
11411 </pre>
11412 <p>
11413 and change the text in Table 54, row 4, the <b>error</b> row, under
11414 the heading Meaning, from
11415 </p>
11416 <pre>    state has invalid value
11417 </pre>
11418 <p>
11419 to
11420 </p>
11421 <pre>    an unspecified error has occurred
11422 </pre>
11423 <p><b>Rationale:</b></p>
11424 <p>The intent is that implementations should not be required to detect
11425 invalid state values; such a requirement appears nowhere else.  An
11426 invalid state value is a precondition violation, <i>i.e.</i> undefined
11427 behavior.  Implementations that do choose to detect invalid state
11428 values, or that choose to detect any other kind of error, may return
11429 <b>error</b> as an indication.</p>
11430 <hr>
11431 <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/papers/2005/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/papers/2005/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>
11432 <p>
11433 Following a discussion on the boost list regarding end iterators and
11434 the possibility of performing operator--() on them, it seems to me
11435 that there is a typo in the standard.  This typo has nothing to do
11436 with that discussion.
11437 </p>
11438
11439 <p>
11440 I have checked this newsgroup, as well as attempted a search of the
11441 Active/Defect/Closed Issues List on the site for the words "s is
11442 derefer" so I believe this has not been proposed before.  Furthermore,
11443 the "Lists by Index" mentions only DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#299">299</a> on section
11444 24.1.4, and DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#299">299</a> is not related to this issue.
11445 </p>
11446
11447 <p>
11448 The standard makes the following assertion on bidirectional iterators,
11449 in section 24.1.4 [lib.bidirectional.iterators], Table 75:
11450 </p>
11451
11452 <pre>                         operational  assertion/note
11453 expression  return type   semantics    pre/post-condition
11454
11455 --r          X&amp;                        pre: there exists s such
11456                                        that r == ++s.
11457                                        post: s is dereferenceable.
11458                                        --(++r) == r.
11459                                        --r == --s implies r == s.
11460                                        &amp;r == &amp;--r.
11461 </pre>
11462
11463 <p>
11464 (See <a href="http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763">http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763</a>.)
11465 </p>
11466
11467 <p>
11468 In particular, "s is dereferenceable" seems to be in error.  It seems
11469 that the intention was to say "r is dereferenceable".
11470 </p>
11471
11472 <p>
11473 If it were to say "r is dereferenceable" it would
11474 make perfect sense.  Since s must be dereferenceable prior to
11475 operator++, then the natural result of operator-- (to undo operator++)
11476 would be to make r dereferenceable.  Furthermore, without other
11477 assertions, and basing only on precondition and postconditions, we
11478 could not otherwise know this.  So it is also interesting information.
11479 </p>
11480
11481 <p><b>Proposed resolution:</b></p>
11482 <p>
11483 Change the guarantee to "postcondition: r is dereferenceable."
11484 </p>
11485 <p><b>Rationale:</b></p>
11486 <p>Fixes an obvious typo</p>
11487 <hr>
11488 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Gabriel Dos Reis&nbsp; <b>Date:</b>&nbsp;8 Nov 2002</p>
11489 <p>Consider the following program:</p>
11490 <pre>    #include &lt;iostream&gt;
11491     #include &lt;ostream&gt;
11492     #include &lt;vector&gt;
11493     #include &lt;valarray&gt;
11494     #include &lt;algorithm&gt;
11495     #include &lt;iterator&gt;
11496     template&lt;typename Array&gt;
11497     void print(const Array&amp; a)
11498     {
11499     using namespace std;
11500     typedef typename Array::value_type T;
11501     copy(&amp;a[0], &amp;a[0] + a.size(),
11502     ostream_iterator&lt;T&gt;(std::cout, " "));
11503     }
11504     template&lt;typename T, unsigned N&gt;
11505     unsigned size(T(&amp;)[N]) { return N; }
11506     int main()
11507     {
11508     double array[] = { 0.89, 9.3, 7, 6.23 };
11509     std::vector&lt;double&gt; v(array, array + size(array));
11510     std::valarray&lt;double&gt; w(array, size(array));
11511     print(v); // #1
11512     std::cout &lt;&lt; std::endl;
11513     print(w); // #2
11514     std::cout &lt;&lt; std::endl;
11515     }
11516 </pre>
11517
11518 <p>While the call numbered #1 succeeds, the call numbered #2 fails
11519 because the const version of the member function
11520 valarray&lt;T&gt;::operator[](size_t) returns a value instead of a
11521 const-reference. That seems to be so for no apparent reason, no
11522 benefit. Not only does that defeats users' expectation but it also
11523 does hinder existing software (written either in C or Fortran)
11524 integration within programs written in C++.  There is no reason why
11525 subscripting an expression of type valarray&lt;T&gt; that is const-qualified
11526 should not return a const T&amp;.</p>
11527 <p><b>Proposed resolution:</b></p>
11528 <p>In the class synopsis in 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a>, and in
11529 26.3.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a> just above paragraph 1, change</p>
11530 <pre>  T operator[](size_t const);
11531 </pre>
11532 <p>to</p>
11533 <pre>  const T&amp; operator[](size_t const);
11534 </pre>
11535
11536 <p><i>[Kona: fixed a minor typo: put semicolon at the end of the line
11537   wehre it belongs.]</i></p>
11538
11539 <p><b>Rationale:</b></p>
11540 <p>Return by value seems to serve no purpose.  Valaray was explicitly
11541 designed to have a specified layout so that it could easily be
11542 integrated with libraries in other languages, and return by value
11543 defeats that purpose.  It is believed that this change will have no
11544 impact on allowable optimizations.</p>
11545 <hr>
11546 <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/papers/2005/lib-locales.html#lib.conversions"> [lib.conversions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;10 Dec 2002</p>
11547 <p>
11548 The specifications of toupper and tolower both specify the functions as
11549 const, althought they are not member functions, and are not specified as
11550 const in the header file synopsis in section 22.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locales"> [lib.locales]</a>.
11551 </p>
11552 <p><b>Proposed resolution:</b></p>
11553 <p>In 22.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.conversions"> [lib.conversions]</a>, remove <tt>const</tt> from the function
11554   declarations of std::toupper and std::tolower</p>
11555 <p><b>Rationale:</b></p>
11556 <p>Fixes an obvious typo</p>
11557 <hr>
11558 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;3 Jan 2003</p>
11559 <p>
11560 In 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.c.math"> [lib.c.math]</a>, the C++ standard refers to the C standard for the
11561 definition of rand(); in the C standard, it is written that "The
11562 implementation shall behave as if no library function calls the rand
11563 function."
11564 </p>
11565
11566 <p>
11567 In 25.2.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.random.shuffle"> [lib.alg.random.shuffle]</a>, there is no specification as to
11568 how the two parameter version of the function generates its random
11569 value.  I believe that all current implementations in fact call rand()
11570 (in contradiction with the requirement avove); if an implementation does
11571 not call rand(), there is the question of how whatever random generator
11572 it does use is seeded.  Something is missing.
11573 </p>
11574
11575 <p><b>Proposed resolution:</b></p>
11576 <p>
11577 In [lib.c.math], add a paragraph specifying that the C definition of
11578 rand shal be modified to say that "Unless otherwise specified, the
11579 implementation shall behave as if no library function calls the rand
11580 function."
11581 </p>
11582
11583 <p>
11584 In [lib.alg.random.shuffle], add a sentence to the effect that "In
11585 the two argument form of the function, the underlying source of
11586 random numbers is implementation defined. [Note: in particular, an
11587 implementation is permitted to use <tt>rand</tt>.]
11588 </p>
11589 <p><b>Rationale:</b></p>
11590 <p>The original proposed resolution proposed requiring the
11591   two-argument from of <tt>random_shuffle</tt> to
11592   use <tt>rand</tt>. We don't want to do that, because some existing
11593   implementations already use something else: gcc
11594   uses <tt>lrand48</tt>, for example.  Using <tt>rand</tt> presents a
11595   problem if the number of elements in the sequence is greater than
11596   RAND_MAX.</p>
11597 <hr>
11598 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;27 Feb 2003</p>
11599 <p>
11600 20.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> allocator members, contains
11601 the following 3 lines:
11602 </p>
11603
11604 <pre>  12 Returns: new((void *) p) T( val)
11605      void destroy(pointer p);
11606   13 Returns: ((T*) p)-&gt;~T()
11607 </pre>
11608
11609 <p>
11610 The type cast "(T*) p" in the last line is redundant cause
11611 we know that std::allocator&lt;T&gt;::pointer is a typedef for T*.
11612 </p>
11613 <p><b>Proposed resolution:</b></p>
11614 <p>
11615 Replace "((T*) p)" with "p".
11616 </p>
11617 <p><b>Rationale:</b></p>
11618 <p>Just a typo, this is really editorial.</p>
11619 <hr>
11620 <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/papers/2005/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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;27 Feb 2003</p>
11621 <p>
11622 This applies to the new expression that is contained in both par12 of
11623 20.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>.
11624 I think this new expression is wrong, involving unintended side
11625 effects.
11626 </p>
11627
11628
11629 <p>20.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a>  contains the following 3 lines:</p>
11630
11631 <pre>  11 Returns: the largest value N for which the call allocate(N,0) might succeed.
11632      void construct(pointer p, const_reference val);
11633   12 Returns: new((void *) p) T( val)
11634 </pre>
11635
11636
11637 <p>20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> in table 32 has the following line:</p>
11638 <pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
11639 </pre>
11640
11641 <p>
11642 .... with the prerequisits coming from the preceding two paragraphs,
11643 especially from table 31:
11644 </p>
11645
11646 <pre>  alloc&lt;T&gt;             a     ;// an allocator for T
11647   alloc&lt;T&gt;::pointer    p     ;// random access iterator
11648                               // (may be different from T*)
11649   alloc&lt;T&gt;::reference  r = *p;// T&amp;
11650   T const&amp;             t     ;
11651 </pre>
11652
11653 <p>
11654 Cause of using "new" but not "::new", any existing "T::operator new"
11655 function will hide the global placement new function. When there is no
11656 "T::operator new" with adequate signature,
11657 every_alloc&lt;T&gt;::construct(..) is ill-formed, and most
11658 std::container&lt;T,every_alloc&lt;T&gt;&gt; use it; a workaround
11659 would be adding placement new and delete functions with adequate
11660 signature and semantic to class T, but class T might come from another
11661 party. Maybe even worse is the case when T has placement new and
11662 delete functions with adequate signature but with "unknown" semantic:
11663 I dont like to speculate about it, but whoever implements
11664 any_container&lt;T,any_alloc&gt; and wants to use construct(..)
11665 probably must think about it.
11666 </p>
11667 <p><b>Proposed resolution:</b></p>
11668 <p>
11669 Replace "new" with "::new" in both cases.
11670 </p>
11671 <hr>
11672 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;25 Mar 2003</p>
11673
11674 <p>
11675 std::basic_string, 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> paragraph 2 says that
11676 basic_string "conforms to the requirements of a Sequence, as specified
11677 in (23.1.1)." The sequence requirements specified in (23.1.1) to not
11678 include any prohibition on swap members throwing exceptions.
11679 </p>
11680
11681 <p>
11682 Section 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10 does limit conditions under
11683 which exceptions may be thrown, but applies only to "all container
11684 types defined in this clause" and so excludes basic_string::swap
11685 because it is defined elsewhere.
11686 </p>
11687
11688 <p>
11689 Eric Niebler points out that 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> paragraph 5 explicitly
11690 permits basic_string::swap to invalidates iterators, which is
11691 disallowed by 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10. Thus the standard would
11692 be contradictory if it were read or extended to read as having
11693 basic_string meet 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10 requirements.
11694 </p>
11695
11696 <p>
11697 Yet several LWG members have expressed the belief that the original
11698 intent was that basic_string::swap should not throw exceptions as
11699 specified by 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10, and that the standard is
11700 unclear on this issue. The complexity of basic_string::swap is
11701 specified as "constant time", indicating the intent was to avoid
11702 copying (which could cause a bad_alloc or other exception). An
11703 important use of swap is to ensure that exceptions are not thrown in
11704 exception-safe code.
11705 </p>
11706
11707 <p>
11708 Note: There remains long standing concern over whether or not it is
11709 possible to reasonably meet the 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10 swap
11710 requirements when allocators are unequal. The specification of
11711 basic_string::swap exception requirements is in no way intended to
11712 address, prejudice, or otherwise impact that concern.
11713 </p>
11714
11715
11716
11717
11718
11719 <p><b>Proposed resolution:</b></p>
11720 <p>
11721 In 21.3.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string::swap"> [lib.string::swap]</a>, add a throws clause:
11722 </p>
11723
11724 <p>
11725 Throws: Shall not throw exceptions.
11726 </p>
11727 <hr>
11728 <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/papers/2005/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a>, 18.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;24 Apr 2003</p>
11729 <p>
11730 The eight basic dynamic memory allocation functions (single-object
11731 and array versions of ::operator new and ::operator delete, in the
11732 ordinary and nothrow forms) are replaceable.  A C++ program may
11733 provide an alternative definition for any of them, which will be used
11734 in preference to the implementation's definition.
11735 </p>
11736
11737 <p>
11738 Three different parts of the standard mention requirements on
11739 replacement functions: 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a>
11740 and 18.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/basic.html#basic.stc.dynamic"> [basic.stc.dynamic]</a>.
11741 </p>
11742
11743 <p>None of these three places say whether a replacement function may
11744   be declared inline.  18.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> paragraph 2 specifies a
11745   signature for the replacement function, but that's not enough:
11746   the <tt>inline</tt> specifier is not part of a function's signature.
11747   One might also reason from 7.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/dcl.html#dcl.fct.spec"> [dcl.fct.spec]</a> paragraph 2, which
11748   requires that "an inline function shall be defined in every
11749   translation unit in which it is used," but this may not be quite
11750   specific enough either.  We should either explicitly allow or
11751   explicitly forbid inline replacement memory allocation
11752   functions.</p>
11753 <p><b>Proposed resolution:</b></p>
11754 <p>
11755 Add a new sentence to the end of 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 3:
11756 "The program's definitions shall not be specified as <tt>inline</tt>.
11757 No diagnostic is required."
11758 </p>
11759
11760 <p><i>[Kona: added "no diagnostic is required"]</i></p>
11761
11762 <p><b>Rationale:</b></p>
11763 <p>
11764 The fact that <tt>inline</tt> isn't mentioned appears to have been
11765 nothing more than an oversight.  Existing implementations do not
11766 permit inline functions as replacement memory allocation functions.
11767 Providing this functionality would be difficult in some cases, and is
11768 believed to be of limited value.
11769 </p>
11770 <hr>
11771 <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/papers/2005/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/papers/2005/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;08 Apr 2003</p>
11772 <p>
11773 Section 25.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a> describes bsearch and qsort, from the C
11774 standard library. Paragraph 4 does not list any restrictions on qsort,
11775 but it should limit the base parameter to point to POD.  Presumably,
11776 qsort sorts the array by copying bytes, which requires POD.
11777 </p>
11778 <p><b>Proposed resolution:</b></p>
11779 <p>
11780 In 25.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a> paragraph 4, just after the declarations and
11781 before the nonnormative note, add these words: "both of which have the
11782 same behavior as the original declaration.  The behavior is undefined
11783 unless the objects in the array pointed to by <i>base</i> are of POD
11784 type."
11785 </p>
11786
11787 <p><i>[Something along these lines is clearly necessary.  Matt
11788   provided wording.]</i></p>
11789 <hr>
11790 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;3 June 2003</p>
11791 <p>
11792 Clause 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>, paragraph 5, says that the only expression
11793 that is defined for a singular iterator is "an assignment of a
11794 non-singular value to an iterator that holds a singular value".  This
11795 means that destroying a singular iterator (e.g. letting an automatic
11796 variable go out of scope) is technically undefined behavior.  This
11797 seems overly strict, and probably unintentional.
11798 </p>
11799 <p><b>Proposed resolution:</b></p>
11800 <p>
11801 Change the sentence in question to "... the only exceptions are
11802 destroying an iterator that holds a singular value, or the assignment
11803 of a non-singular value to an iterator that holds a singular value."
11804 </p>
11805 <hr>
11806 <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/papers/2005/lib-containers.html#lib.queue"> [lib.queue]</a>, 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.stack"> [lib.stack]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Bos&nbsp; <b>Date:</b>&nbsp;7 Jun 2003</p>
11807 <p>
11808 Sections 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.queue"> [lib.queue]</a> and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.stack"> [lib.stack]</a> list
11809 comparison operators (==, !=, &lt;, &lt;=, &gt;, =&gt;) for queue and
11810 stack.  Only the semantics for queue::operator== (23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lib-containers.html#lib.queue"> [lib.queue]</a>
11811 par3) are defined.
11812 </p>
11813 <p><b>Proposed resolution:</b></p>
11814
11815 <p>Add the following new paragraphs after 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.queue"> [lib.queue]</a>
11816   paragraph 3:</p>
11817
11818 <blockquote>
11819
11820 <pre>  operator!=
11821 </pre>
11822 <p>Returns: <tt>x.c != y.c</tt></p>
11823
11824 <pre>  operator&gt;
11825 </pre>
11826 <p>Returns: <tt>x.c &gt; y.c</tt></p>
11827
11828 <pre>  operator&lt;=
11829 </pre>
11830 <p>Returns: <tt>x.c &lt;= y.c</tt></p>
11831
11832 <pre>  operator&gt;=
11833 </pre>
11834 <p>Returns: <tt>x.c &gt;= y.c</tt></p>
11835
11836 </blockquote>
11837
11838 <p>Add the following paragraphs at the end of 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.stack"> [lib.stack]</a>:</p>
11839
11840 <blockquote>
11841
11842 <pre>  operator==
11843 </pre>
11844 <p>Returns: <tt>x.c == y.c</tt></p>
11845
11846 <pre>  operator&lt;
11847 </pre>
11848 <p>Returns: <tt>x.c &lt; y.c</tt></p>
11849
11850 <pre>  operator!=
11851 </pre>
11852 <p>Returns: <tt>x.c != y.c</tt></p>
11853
11854 <pre>  operator&gt;
11855 </pre>
11856 <p>Returns: <tt>x.c &gt; y.c</tt></p>
11857
11858 <pre>  operator&lt;=
11859 </pre>
11860 <p>Returns: <tt>x.c &lt;= y.c</tt></p>
11861
11862 <pre>  operator&gt;=
11863 </pre>
11864 <p>Returns: <tt>x.c &gt;= y.c</tt></p>
11865
11866 </blockquote>
11867
11868
11869 <p><i>[Kona: Matt provided wording.]</i></p>
11870
11871 <p><b>Rationale:</b></p>
11872 There isn't any real doubt about what these operators are
11873 supposed to do, but we ought to spell it out.
11874 <hr>
11875 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Daniel Frey&nbsp; <b>Date:</b>&nbsp;9 Jul 2003</p>
11876 <p>
11877 25.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.set.operations"> [lib.alg.set.operations]</a> paragraph 1 reads:
11878 "The semantics of the set operations are generalized to multisets in a
11879 standard way by defining union() to contain the maximum number of
11880 occurrences of every element, intersection() to contain the minimum, and
11881 so on."
11882 </p>
11883
11884 <p>
11885 This is wrong.  The name of the functions are set_union() and
11886 set_intersection(), not union() and intersection().
11887 </p>
11888 <p><b>Proposed resolution:</b></p>
11889 <p>Change that sentence to use the correct names.</p>
11890 <hr>
11891 <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/papers/2005/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/papers/2005/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;10 Jul 2003</p>
11892 <p>
11893 The Effects clause in 27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> paragraph 5 says that the
11894 function only throws if the respective bits are already set prior to
11895 the function call. That's obviously not the intent. The typo ought to
11896 be corrected and the text reworded as: "If (<i>state</i> &amp;
11897 exceptions()) == 0, returns. ..."
11898 </p>
11899 <p><b>Proposed resolution:</b></p>
11900 <p>
11901 In 27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> paragraph 5, replace "If (rdstate() &amp;
11902 exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
11903 &amp; exceptions()) == 0".
11904 </p>
11905
11906 <p><i>[Kona: the original proposed resolution wasn't quite right.  We
11907   really do mean rdstate(); the ambiguity is that the wording in the
11908   standard doesn't make it clear whether we mean rdstate() before
11909   setting the new state, or rdsate() after setting it.  We intend the
11910   latter, of course. Post-Kona: Martin provided wording.]</i></p>
11911
11912 <hr>
11913 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Aug 2003</p>
11914 <p>
11915 Consider the following code fragment:
11916 </p>
11917 <blockquote>
11918 <pre>int A[8] = { 1,3,5,7,9,8,4,2 };
11919 std::vector&lt;int&gt; v(A, A+8);
11920
11921 std::vector&lt;int&gt;::iterator i1 = v.begin() + 3;
11922 std::vector&lt;int&gt;::iterator i2 = v.begin() + 4;
11923 v.erase(i1);
11924 </pre>
11925 </blockquote>
11926
11927 <p>
11928 Which iterators are invalidated by <tt>v.erase(i1)</tt>: i1, i2,
11929 both, or neither?
11930 </p>
11931
11932 <p>
11933 On all existing implementations that I know of, the status of i1 and
11934 i2 is the same: both of them will be iterators that point to some
11935 elements of the vector (albeit not the same elements they did
11936 before).  You won't get a crash if you use them.  Depending on
11937 exactly what you mean by "invalidate", you might say that neither one
11938 has been invalidated because they still point to <i>something</i>,
11939 or you might say that both have been invalidated because in both
11940 cases the elements they point to have been changed out from under the
11941 iterator.
11942 </p>
11943
11944 <p>
11945 The standard doesn't say either of those things.  It says that erase
11946 invalidates all iterators and references "after the point of the
11947 erase".  This doesn't include i1, since it's at the point of the
11948 erase instead of after it.  I can't think of any sensible definition
11949 of invalidation by which one can say that i2 is invalidated but i1
11950 isn't.
11951 </p>
11952
11953 <p>
11954 (This issue is important if you try to reason about iterator validity
11955 based only on the guarantees in the standard, rather than reasoning
11956 from typical implementation techniques.  Strict debugging modes,
11957 which some programmers find useful, do not use typical implementation
11958 techniques.)
11959 </p>
11960 <p><b>Proposed resolution:</b></p>
11961 <p>
11962 In 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> paragraph 3, change "Invalidates all the
11963 iterators and references after the point of the erase" to
11964 "Invalidates iterators and references at or after the point of the
11965 erase".
11966 </p>
11967 <p><b>Rationale:</b></p>
11968 <p>I believe this was essentially a typographical error, and that it
11969   was taken for granted that erasing an element invalidates iterators
11970   that point to it.  The effects clause in question treats iterators
11971   and references in parallel, and it would seem counterintuitive to
11972   say that a reference to an erased value remains valid.</p>
11973 <hr>
11974 <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/papers/2005/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/papers/2005/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
11975 <p>
11976 According to 27.6.1.4, the ws() manipulator is not required to construct
11977 the sentry object. The manipulator is also not a member function so the
11978 text in 27.6.1, p1 through 4 that describes the exception policy for
11979 istream member functions does not apply. That seems inconsistent with
11980 the rest of extractors and all the other input functions (i.e., ws will
11981 not cause a tied stream to be flushed before extraction, it doesn't check
11982 the stream's exceptions or catch exceptions thrown during input, and it
11983 doesn't affect the stream's gcount).
11984 </p>
11985 <p><b>Proposed resolution:</b></p>
11986 <p>
11987 Add to 27.6.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream.manip"> [lib.istream.manip]</a>, immediately before the first sentence
11988 of paragraph 1, the following text:
11989 </p>
11990
11991     <blockquote>
11992     Behaves as an unformatted input function (as described in
11993     27.6.1.3, paragraph 1), except that it does not count the number
11994     of characters extracted and does not affect the value returned by
11995     subsequent calls to is.gcount(). After constructing a sentry
11996     object...
11997     </blockquote>
11998
11999 <p><i>[Post-Kona: Martin provided wording]</i></p>
12000
12001 <hr>
12002 <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/papers/2005/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
12003 <p>
12004 7.19.1, p2, of C99 requires that the FILE type only be declared in
12005 &lt;stdio.h&gt;.  None of the (implementation-defined) members of the
12006 struct is mentioned anywhere for obvious reasons.
12007 </p>
12008
12009 <p>
12010 C++ says in 27.8.1, p2 that FILE is a type that's defined in &lt;cstdio&gt;. Is
12011 it really the intent that FILE be a complete type or is an implementation
12012 allowed to just declare it without providing a full definition?
12013 </p>
12014 <p><b>Proposed resolution:</b></p>
12015 <p>In the first sentence of 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> paragraph 2, change
12016   "defined" to "declared".</p>
12017 <p><b>Rationale:</b></p>
12018 <p>We don't want to impose any restrictions beyond what the C standard
12019   already says. We don't want to make anything implementation defined,
12020   because that imposes new requirements in implementations.</p>
12021 <hr>
12022 <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/papers/2005/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/papers/2005/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
12023 <p>
12024 The standard is not clear about the requirements on the value returned from
12025 a call to get_temporary_buffer(0). In particular, it fails to specify whether
12026 the call should return a distinct pointer each time it is called (like
12027 operator new), or whether the value is unspecified (as if returned by
12028 malloc). The standard also fails to mention what the required behavior
12029 is when the argument is less than 0.
12030 </p>
12031 <p><b>Proposed resolution:</b></p>
12032 <p>Change 20.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.temporary.buffer"> [lib.temporary.buffer]</a> paragraph 2 from "...or a pair of 0
12033 values if no storage can be obtained" to "...or a pair of 0 values if
12034 no storage can be obtained or if <i>n</i> &lt;= 0."</p>
12035 <p><i>[Kona: Matt provided wording]</i></p>
12036 <hr>
12037 <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/papers/2005/lib-algorithms.html#lib.alg.search"> [lib.alg.search]</a>, 25.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a>, 25.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/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/papers/2005/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
12038 <p>
12039 The complexity requirements for these function templates are incorrect
12040 (or don't even make sense) for negative n:</p>
12041
12042 <p>25.1.9, p7 (search_n):
12043 <br>
12044 Complexity: At most (last1 - first1) * count applications
12045 of the corresponding predicate.</p>
12046
12047 <p>25.2.5, p3 (fill_n):
12048 <br>
12049 Complexity: Exactly last - first (or n) assignments.</p>
12050 <br>
12051
12052 <p>25.2.6, p3 (generate_n):
12053 <br>
12054 Complexity: Exactly last - first (or n) assignments.</p>
12055
12056 <p>
12057 In addition, the Requirements or the Effects clauses for the latter two
12058 templates don't say anything about the behavior when n is negative.
12059 </p>
12060 <p><b>Proposed resolution:</b></p>
12061 <p>Change 25.1.9, p7 to</p>
12062
12063 <blockquote>
12064 Complexity: At most (last1 - first1) * count applications
12065 of the corresponding predicate if count is positive,
12066 or 0 otherwise.
12067 </blockquote>
12068
12069 <p>Change 25.2.5, p2 to</p>
12070 <blockquote>
12071 Effects: Assigns value through all the iterators in the range [first,
12072 last), or [first, first + n) if n is positive, none otherwise.
12073 </blockquote>
12074
12075 <p>Change 25.2.5, p3 to:</p>
12076 <blockquote>
12077 Complexity: Exactly last - first (or n if n is positive,
12078 or 0 otherwise) assignments.
12079 </blockquote>
12080
12081 <p>
12082 Change 25.2.6, p1
12083 to (notice the correction for the misspelled "through"):
12084 </p>
12085 <blockquote>
12086 Effects: Invokes the function object genand assigns the return
12087 value of gen through all the iterators in the range [first, last),
12088 or [first, first + n) if n is positive, or [first, first)
12089 otherwise.
12090 </blockquote>
12091
12092 <p>Change 25.2.6, p3 to:</p>
12093 <blockquote>
12094 Complexity: Exactly last - first (or n if n is positive,
12095 or 0 otherwise) assignments.
12096 </blockquote>
12097 <p><b>Rationale:</b></p>
12098 <p>Informally, we want to say that whenever we see a negative number
12099   we treat it the same as if it were zero.  We believe the above
12100   changes do that (although they may not be the minimal way of saying
12101   so).  The LWG considered and rejected the alternative of saying that
12102   negative numbers are undefined behavior.</p>
12103 <hr>
12104 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
12105 <p>
12106 23.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q)
12107 that q must be a valid dereferenceable iterator into the sequence a.
12108 </p>
12109
12110 <p>
12111 However, 21.3.5.5, p5 describing string::erase(p) only requires that
12112 p be a valid iterator.
12113 </p>
12114
12115 <p>
12116 This may be interepreted as a relaxation of the general requirement,
12117 which is most likely not the intent.
12118 </p>
12119 <p><b>Proposed resolution:</b></p>
12120 <p>Remove 21.3.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string::erase"> [lib.string::erase]</a> paragraph 5.</p>
12121 <p><b>Rationale:</b></p>
12122 <p>The LWG considered two options: changing the string requirements to
12123   match the general container requirements, or just removing the
12124   erroneous string requirements altogether.  The LWG chose the latter
12125   option, on the grounds that duplicating text always risks the
12126   possibility that it might be duplicated incorrectly.</p>
12127 <hr>
12128 <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/papers/2005/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/papers/2005/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Christian W Brock&nbsp; <b>Date:</b>&nbsp;24 Sep 2003</p>
12129 <p>27.7.1.3 par 8 says:</p>
12130 <blockquote>
12131 Notes: The function can make a write position available only if
12132     ( mode &amp; ios_base::out) != 0. To make a write position
12133     available, the function reallocates (or initially allocates) an
12134     array object with a sufficient number of elements to hold the
12135     current array object (if any), plus one additional write position.
12136     If ( mode &amp; ios_base::in) != 0, the function alters the read end
12137     pointer egptr() to point just past the new write position (as
12138     does the write end pointer epptr()).
12139 </blockquote>
12140
12141 <p>
12142 The sentences "plus one additional write position." and especially
12143     "(as does the write end pointer epptr())" COULD by interpreted
12144     (and is interpreted by at least my library vendor) as:
12145 </p>
12146
12147 <blockquote>
12148     post-condition: epptr() == pptr()+1
12149 </blockquote>
12150
12151 <p>
12152 This WOULD force sputc() to call the virtual overflow() each time.
12153 </p>
12154
12155 <p>The proposed change also affects Defect Report 169.</p>
12156
12157 <p><b>Proposed resolution:</b></p>
12158 <p>27.7.1.1/2 Change:</p>
12159
12160 <blockquote>
12161 2- Notes: The function allocates no array object.
12162 </blockquote>
12163
12164 <p>
12165 to:
12166 </p>
12167
12168 <blockquote>
12169 2- Postcondition: str() == "".
12170 </blockquote>
12171
12172 <p>
12173 27.7.1.1/3 Change:
12174 </p>
12175
12176 <blockquote>
12177 <p>
12178 -3- Effects: Constructs an object of class basic_stringbuf,
12179 initializing the base class with basic_streambuf()
12180 (lib.streambuf.cons), and initializing mode with which . Then copies
12181 the content of str into the basic_stringbuf underlying character
12182 sequence and initializes the input and output sequences according to
12183 which. If which &amp; ios_base::out is true, initializes the output
12184 sequence with the underlying sequence. If which &amp; ios_base::in is
12185 true, initializes the input sequence with the underlying sequence.
12186 </p>
12187 </blockquote>
12188
12189 <p>to:</p>
12190
12191 <blockquote>
12192 <p>
12193 -3- Effects: Constructs an object of class basic_stringbuf,
12194 initializing the base class with basic_streambuf()
12195 (lib.streambuf.cons), and initializing mode with which. Then copies
12196 the content of str into the basic_stringbuf underlying character
12197 sequence. If which &amp; ios_base::out is true, initializes the output
12198 sequence such that pbase() points to the first underlying character,
12199 epptr() points one past the last underlying character, and if (which &amp;
12200 ios_base::ate) is true, pptr() is set equal to
12201 epptr() else pptr() is set equal to pbase(). If which &amp; ios_base::in
12202 is true, initializes the input sequence such that eback() and gptr()
12203 point to the first underlying character and egptr() points one past
12204 the last underlying character.
12205 </p>
12206 </blockquote>
12207
12208 <p>27.7.1.2/1 Change:</p>
12209
12210 <blockquote>
12211 <p>
12212 -1- Returns: A basic_string object whose content is equal to the
12213 basic_stringbuf underlying character sequence. If the buffer is only
12214 created in input mode, the underlying character sequence is equal to
12215 the input sequence; otherwise, it is equal to the output sequence. In
12216 case of an empty underlying character sequence, the function returns
12217 basic_string&lt;charT,traits,Allocator&gt;().
12218 </p>
12219 </blockquote>
12220
12221 <p>to:</p>
12222
12223 <blockquote>
12224 <p>
12225 -1- Returns: A basic_string object whose content is equal to the
12226 basic_stringbuf underlying character sequence. If the basic_stringbuf
12227 was created only in input mode, the resultant basic_string contains
12228 the character sequence in the range [eback(), egptr()).  If the
12229 basic_stringbuf was created with (which &amp; ios_base::out) being true
12230 then the resultant basic_string contains the character sequence in the
12231 range [pbase(), high_mark) where high_mark represents the position one
12232 past the highest initialized character in the buffer.  Characters can
12233 be initialized either through writing to the stream, or by
12234 constructing the basic_stringbuf with a basic_string, or by calling
12235 the str(basic_string) member function.  In the case of calling the
12236 str(basic_string) member function, all characters initialized prior to
12237 the call are now considered uninitialized (except for those
12238 characters re-initialized by the new basic_string).  Otherwise the
12239 basic_stringbuf has been created in neither input nor output mode and
12240 a zero length basic_string is returned.
12241 </p>
12242 </blockquote>
12243
12244 <p>
12245 27.7.1.2/2 Change:
12246 </p>
12247
12248 <blockquote>
12249 <p>
12250 -2- Effects: If the basic_stringbuf's underlying character sequence is
12251 not empty, deallocates it. Then copies the content of s into the
12252 basic_stringbuf underlying character sequence and initializes the
12253 input and output sequences according to the mode stored when creating
12254 the basic_stringbuf object. If (mode&amp;ios_base::out) is true, then
12255 initializes the output sequence with the underlying sequence. If
12256 (mode&amp;ios_base::in) is true, then initializes the input sequence with
12257 the underlying sequence.
12258 </p>
12259 </blockquote>
12260
12261 <p>to:</p>
12262
12263 <blockquote>
12264 <p>
12265 -2- Effects: Copies the content of s into the basic_stringbuf
12266 underlying character sequence. If mode &amp; ios_base::out is true,
12267 initializes the output sequence such that pbase() points to the first
12268 underlying character, epptr() points one past the last underlying
12269 character, and if (mode &amp; ios_base::ate) is true,
12270 pptr() is set equal to epptr() else pptr() is set equal to pbase(). If
12271 mode &amp; ios_base::in is true, initializes the input sequence such that
12272 eback() and gptr() point to the first underlying character and egptr()
12273 points one past the last underlying character.
12274 </p>
12275 </blockquote>
12276
12277 <p>Remove 27.2.1.2/3.  (Same rationale as issue 238: incorrect and unnecessary.)</p>
12278
12279 <p>27.7.1.3/1 Change:</p>
12280
12281 <blockquote>
12282 <p>
12283 1- Returns: If the input sequence has a read position available,
12284 returns traits::to_int_type(*gptr()).  Otherwise, returns
12285 traits::eof().
12286 </p>
12287 </blockquote>
12288
12289 <p>to:</p>
12290
12291 <blockquote>
12292 <p>
12293 1- Returns: If the input sequence has a read position available,
12294 returns traits::to_int_type(*gptr()).  Otherwise, returns
12295 traits::eof().  Any character in the underlying buffer which has been
12296 initialized is considered to be part of the input sequence.
12297 </p>
12298 </blockquote>
12299
12300 <p>27.7.1.3/9 Change:</p>
12301
12302 <blockquote>
12303 <p>
12304 -9- Notes: The function can make a write position available only if (
12305 mode &amp; ios_base::out) != 0. To make a write position available, the
12306 function reallocates (or initially allocates) an array object with a
12307 sufficient number of elements to hold the current array object (if
12308 any), plus one additional write position. If ( mode &amp; ios_base::in) !=
12309 0, the function alters the read end pointer egptr() to point just past
12310 the new write position (as does the write end pointer epptr()).
12311 </p>
12312 </blockquote>
12313
12314 <p>to:</p>
12315
12316 <blockquote>
12317 <p>
12318 -9- The function can make a write position available only if ( mode &amp;
12319 ios_base::out) != 0. To make a write position available, the function
12320 reallocates (or initially allocates) an array object with a sufficient
12321 number of elements to hold the current array object (if any), plus one
12322 additional write position. If ( mode &amp; ios_base::in) != 0, the
12323 function alters the read end pointer egptr() to point just past the
12324 new write position.
12325 </p>
12326 </blockquote>
12327
12328 <p>27.7.1.3/12 Change:</p>
12329
12330 <blockquote>
12331 <p>
12332 -12- _ If (newoff + off) &lt; 0, or (xend - xbeg) &lt; (newoff + off), the
12333 positioning operation fails. Otherwise, the function assigns xbeg +
12334 newoff + off to the next pointer xnext .
12335 </p>
12336 </blockquote>
12337
12338 <p>to:</p>
12339
12340 <blockquote>
12341 <p>
12342 -12- _ If (newoff + off) &lt; 0, or if (newoff + off) refers to an
12343 uninitialized character (as defined in 27.7.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.stringbuf.members"> [lib.stringbuf.members]</a>
12344 paragraph 1), the positioning operation fails. Otherwise, the function
12345 assigns xbeg + newoff + off to the next pointer xnext .
12346 </p>
12347 </blockquote>
12348
12349 <p><i>[post-Kona: Howard provided wording.  At Kona the LWG agreed that
12350   something along these lines was a good idea, but the original
12351   proposed resolution didn't say enough about the effect of various
12352   member functions on the underlying character sequences.]</i></p>
12353
12354 <p><b>Rationale:</b></p>
12355 <p>The current basic_stringbuf description is over-constrained in such
12356 a way as to prohibit vendors from making this the high-performance
12357 in-memory stream it was meant to be.  The fundamental problem is that
12358 the pointers: eback(), gptr(), egptr(), pbase(), pptr(), epptr() are
12359 observable from a derived client, and the current description
12360 restricts the range [pbase(), epptr()) from being grown geometrically.
12361 This change allows, but does not require, geometric growth of this
12362 range.</p>
12363
12364 <p>Backwards compatibility issues: These changes will break code that
12365 derives from basic_stringbuf, observes epptr(), and depends upon
12366 [pbase(), epptr()) growing by one character on each call to overflow()
12367 (i.e. test suites).  Otherwise there are no backwards compatibility
12368 issues.</p>
12369
12370 <p>27.7.1.1/2: The non-normative note is non-binding, and if it were
12371 binding, would be over specification.  The recommended change focuses
12372 on the important observable fact.</p>
12373
12374 <p>27.7.1.1/3: This change does two things: 1.  It describes exactly
12375 what must happen in terms of the sequences.  The terms "input
12376 sequence" and "output sequence" are not well defined.  2.  It
12377 introduces a common extension: open with app or ate mode.  I concur
12378 with issue 238 that paragraph 4 is both wrong and unnecessary.</p>
12379
12380 <p>27.7.1.2/1: This change is the crux of the efficiency issue.  The
12381 resultant basic_string is not dependent upon epptr(), and thus
12382 implementors are free to grow the underlying buffer geometrically
12383 during overflow() *and* place epptr() at the end of that buffer.</p>
12384
12385 <p>27.7.1.2/2:  Made consistent with the proposed 27.7.1.1/3.</p>
12386
12387 <p>27.7.1.3/1: Clarifies that characters written to the stream beyond
12388 the initially specified string are available for reading in an i/o
12389 basic_streambuf.</p>
12390
12391 <p>27.7.1.3/9: Made normative by removing "Notes:", and removed the
12392 trailing parenthetical comment concerning epptr().</p>
12393
12394 <p>27.7.1.3/12: Restricting the positioning to [xbeg, xend) is no
12395 longer allowable since [pbase(), epptr()) may now contain
12396 uninitialized characters.  Positioning is only allowable over the
12397 initialized range.</p>
12398 <hr>
12399 <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/papers/2005/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/papers/2005/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2003</p>
12400
12401 <p>
12402 It has been pointed out that the proposed resolution in DR 25 may not be
12403 quite up to snuff: <br>
12404 http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html
12405 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#25<br>
12406 </p>
12407
12408 <p>
12409 It looks like Petur is right. The complete corrected text is copied below.
12410 I think we may have have been confused by the reference to 22.2.2.2.2 and
12411 the subsequent description of `n' which actually talks about the second
12412 argument to sputn(), not about the number of fill characters to pad with.
12413 </p>
12414
12415 <p>
12416 So the question is: was the original text correct? If the intent was to
12417 follow classic iostreams then it most likely wasn't, since setting width()
12418 to less than the length of the string doesn't truncate it on output. This
12419 is also the behavior of most implementations (except for SGI's standard
12420 iostreams where the operator does truncate).
12421 </p>
12422 <p><b>Proposed resolution:</b></p>
12423 <p>Change the text in 21.3.7.9, p4 from</p>
12424     <blockquote>
12425     If bool(k) is true, inserts characters as if by calling
12426     os.rdbuf()-&gt;sputn(str.data(), n), padding as described in stage 3
12427     of lib.facet.num.put.virtuals, where n is the larger of os.width()
12428     and str.size();
12429     </blockquote>
12430 <p>to</p>
12431     <blockquote>
12432     If bool(k) is true, determines padding as described in
12433     lib.facet.num.put.virtuals, and then inserts the resulting
12434     sequence of characters <tt>seq</tt> as if by calling
12435     <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where <tt>n</tt> is the larger of
12436     <tt>os.width()</tt> and <tt>str.size()</tt>;
12437      </blockquote>
12438
12439 <p><i>[Kona: it appears that neither the original wording, DR25, nor the
12440   proposed resolution, is quite what we want.  We want to say that
12441   the string will be output, padded to os.width() if necessary.  We
12442   don't want to duplicate the padding rules in clause 22, because
12443   they're complicated, but we need to be careful because they weren't
12444   quite written with quite this case in mind.  We need to say what
12445   the character sequence is, and then defer to clause 22.  Post-Kona:
12446   Benjamin provided wording.]</i></p>
12447
12448 <hr>
12449 <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/papers/2005/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/papers/2005/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2003</p>
12450 <p>
12451 Is "const std::ctype&lt;char&gt;" a valid template argument to has_facet, use_facet,
12452 and the locale template ctor? And if so, does it designate the same Facet as
12453 the non-const "std::ctype&lt;char&gt;?" What about "volatile std::ctype&lt;char&gt;?"
12454 Different implementations behave differently: some fail to compile, others
12455 accept such types but behave inconsistently.
12456 </p>
12457 <p><b>Proposed resolution:</b></p>
12458 <p>Change 22.1.1.1.2, p1 to read:</p>
12459
12460 <p>Template parameters in this clause which are required to be facets
12461 are those named Facet in declarations. A program that passes a type
12462 that is not a facet, or a type that refers to volatile-qualified
12463 facet, as an (explicit or deduced) template parameter to a locale
12464 function expecting a facet, is ill-formed.  A const-qualified facet is
12465 a valid template argument to any locale function that expects a Facet
12466 template parameter.</p>
12467
12468 <p><i>[Kona: changed the last sentence from a footnote to normative
12469 text.]</i></p>
12470
12471 <hr>
12472 <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/papers/2005/lib-iostreams.html#lib.fpos"> [lib.fpos]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;17 Nov 2003</p>
12473 <p>
12474 In section 27.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.fpos.members"> [lib.fpos.members]</a> fpos&lt;stateT&gt;::state() is declared
12475 non const, but in section 27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.fpos"> [lib.fpos]</a> it is declared const.
12476 </p>
12477 <p><b>Proposed resolution:</b></p>
12478 <p>
12479 In section 27.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.fpos.members"> [lib.fpos.members]</a>, change the declaration of
12480 <tt>fpos&lt;stateT&gt;::state()</tt> to const.
12481 </p>
12482 <hr>
12483 <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/papers/2005/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/papers/2005/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;18 Nov 2003</p>
12484 <p>
12485 In section 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> paragraph 4, in description part
12486 basic_ostream&lt;charT, traits&gt;::sentry::operator bool() is declared
12487 as non const, but in section 27.6.2.3, in synopsis it is declared
12488 const.
12489 </p>
12490 <p><b>Proposed resolution:</b></p>
12491 <p>
12492 In section 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> paragraph 4, change the declaration
12493 of <tt>sentry::operator bool()</tt> to const.
12494 </p>
12495 <hr>
12496 <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/papers/2005/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/papers/2005/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;20 Nov 2003</p>
12497 <p>
12498 In section 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> par6, in effects description of
12499 basic_filebuf&lt;charT, traits&gt;::close(), overflow(EOF) is used twice;
12500 should be overflow(traits::eof()).
12501 </p>
12502 <p><b>Proposed resolution:</b></p>
12503 <p>
12504 Change overflow(EOF) to overflow(traits::eof()).
12505 </p>
12506 <hr>
12507 <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/papers/2005/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/papers/2005/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;7 Jan 2004</p>
12508 <p>
12509 Table 76, the random access iterator requirement table, says that the
12510 return type of a[n] must be "convertible to T".  When an iterator's
12511 value_type T is an abstract class, nothing is convertible to T.
12512 Surely this isn't an intended restriction?
12513 </p>
12514 <p><b>Proposed resolution:</b></p>
12515 <p>
12516 Change the return type to "convertible to T const&amp;".
12517 </p>
12518 <hr>
12519 <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/papers/2005/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/papers/2005/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;15 Jan 2004</p>
12520 <p>Original text:</p>
12521 <blockquote>
12522 The macro offsetof accepts a restricted set of type arguments in this
12523 International Standard. type shall be a POD structure or a POD union
12524 (clause 9). The result of applying the offsetof macro to a field that
12525 is a static data member or a function member is undefined."
12526 </blockquote>
12527
12528 <p>Revised text:</p>
12529 <blockquote>
12530 "If type is not a POD structure or a POD union the results are undefined."
12531 </blockquote>
12532
12533 <p>
12534 Looks to me like the revised text should have replaced only the second
12535 sentence. It doesn't make sense standing alone.
12536 </p>
12537
12538 <p><b>Proposed resolution:</b></p>
12539 <p>Change 18.1, paragraph 5, to:</p>
12540
12541 <blockquote>
12542 The macro offsetof accepts a restricted set of type arguments in this
12543 International Standard.  If type is not a POD structure or a POD union
12544 the results are undefined.  The result of applying the offsetof macro
12545 to a field that is a static data member or a function member is
12546 undefined."
12547 </blockquote>
12548 <p>----- End of document -----</p>
12549 </body></html>