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"><html><head><title>C++ Standard Library Defect Report List</title></head>
   2
   3 <body text="#000000" bgcolor="#ffffff">
   4 <table>
   5 <tbody><tr>
   6 <td align="left">Doc. no.</td>
   7 <td align="left">N1516 = 03-0099</td>
   8 </tr>
   9 <tr>
  10 <td align="left">Date:</td>
  11 <td align="left">20 Sep 2003</td>
  12 </tr>
  13 <tr>
  14 <td align="left">Project:</td>
  15 <td align="left">Programming Language C++</td>
  16 </tr>
  17 <tr>
  18 <td align="left">Reply to:</td>
  19 <td align="left">Matt Austern &lt;austern@apple.com&gt;</td>
  20 </tr>
  21 </tbody></table>
  22 <h1>C++ Standard Library Defect Report List (Revision 27)</h1>
  23   <p>Reference ISO/IEC IS 14882:1998(E)</p>
  24   <p>Also see:</p>
  25     <ul>
  26       <li>
  27 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
  28       <li>
  29 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
  30       <li>
  31 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
  32       <li><a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li>
  33       <li><a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
  34     </ul>
  35   <p>This document contains only library issues which have been closed
  36   by the Library Working Group (LWG) after being found to be defects
  37   in the standard.  That is, issues which have a status of <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>, or <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a>. See the
  38   <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues closed as non-defects.  See the
  39   <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> for active issues and more information.  The
  40   introductory material in that document also applies to this
  41   document.</p>
  42 <h2>Revision History</h2>
  43 <ul>
  44 <li>R27:
  45 Pre-Kona mailing.  Added new issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#404">404</a>-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
  46 </li>
  47 <li>R26:
  48 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
  49 All issues in Ready status were voted into DR status.  All issues in
  50 DR status were voted into WP status.
  51 </li>
  52 <li>R25:
  53 Pre-Oxford mailing.  Added new issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#402">402</a>.
  54 </li>
  55 <li>R24:
  56 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
  57 meeting.  All Ready issues from R23 with the exception of <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#253">253</a>, which has been given a new proposed resolution, were
  58 moved to DR status.  Added new issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#389">389</a>.  (Issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#389">389</a> were discussed
  59 at the meeting.)  Made progress on issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#226">226</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>: <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining
  60 concerns with <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#226">226</a> involve wording.
  61 </li>
  62 <li>R23:
  63 Pre-Santa Cruz mailing.  Added new issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#367">367</a>-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#382">382</a>.
  64 Moved issues in the TC to TC status.
  65 </li>
  66 <li>R22:
  67 Post-Curaçao mailing.  Added new issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#366">366</a>.
  68 </li>
  69 <li>R21:
  70 Pre-Curaçao mailing.  Added new issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>.
  71 </li>
  72 <li>R20:
  73 Post-Redmond mailing; reflects actions taken in Redmond.  Added
  74 new issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, of which issues
  75 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#347">347</a>-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a> were added since Redmond, hence
  76 not discussed at the meeting.
  77
  78 All Ready issues were moved to DR status, with the exception of issues
  79 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, and <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
  80
  81 Noteworthy issues discussed at Redmond include
  82 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#120">120</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#226">226</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#233">233</a>,
  83 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#253">253</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#254">254</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.
  84 </li>
  85 <li>R19:
  86 Pre-Redmond mailing.  Added new issues
  87 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>.
  88 </li>
  89 <li>R18:
  90 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
  91 Added new issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, and discussed
  92 new issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>.
  93
  94 Changed status of issues
  95 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>
  96 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a>
  97 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>
  98 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a>
  99 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a>
 100 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>
 101 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
 102 to DR.
 103
 104 Changed status of issues
 105 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>  <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>
 106 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>
 107 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>
 108 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>
 109 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a>
 110 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a>
 111 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a>
 112 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a>
 113 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>
 114 to Ready.
 115
 116 Closed issues
 117 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a>
 118 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#289">289</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#293">293</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#302">302</a> <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#313">313</a>
 119 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
 120 as NAD.
 121
 122 </li>
 123 <li>R17:
 124 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 125 resolutions for issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
 126 Added new issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>.
 127 </li>
 128 <li>R16:
 129 post-Toronto mailing; reflects actions taken in Toronto. Added new
 130 issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a>.  Changed status of issues
 131 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>,
 132 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>,
 133 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>,
 134 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>,
 135 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>,
 136 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>,
 137 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>,
 138 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>,
 139 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>,
 140 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>,
 141 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>,
 142 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>,
 143 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR".  Reopened issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>. Reopened
 144 issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>. Changed issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#2">2</a> and
 145 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>. Fixed
 146 issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
 147 appears. Fixed issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix
 148 the bug in enough places.
 149 </li>
 150 <li>R15:
 151 pre-Toronto mailing. Added issues
 152 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#233">233</a>-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>. Some small HTML formatting
 153 changes so that we pass Weblint tests.
 154 </li>
 155 <li>R14:
 156 post-Tokyo II mailing; reflects committee actions taken in
 157 Tokyo. Added issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> to <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>. (00-0019R1/N1242)
 158 </li>
 159 <li>R13:
 160 pre-Tokyo II updated: Added issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a> to <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.
 161 </li>
 162 <li>R12:
 163 pre-Tokyo II mailing: Added issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
 164 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
 165 of issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
 166 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
 167 </li>
 168 <li>R11:
 169 post-Kona mailing: Updated to reflect LWG and full committee actions
 170 in Kona (99-0048/N1224). Note changed resolution of issues
 171 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> and <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>. Added issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a>
 172 to <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
 173 "closed" documents.  Changed the proposed resolution of issue
 174 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
 175 of issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
 176 </li>
 177 <li>R10:
 178 pre-Kona updated.  Added proposed resolutions <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 179 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#92">92</a>,
 180 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a> to
 181 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 182 </li>
 183 <li>R9:
 184 pre-Kona mailing.  Added issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
 185 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
 186 "closed" documents. (99-0030/N1206, 25 Aug 99)
 187 </li>
 188 <li>R8:
 189 post-Dublin mailing. Updated to reflect LWG and full committee actions
 190 in Dublin. (99-0016/N1193, 21 Apr 99)
 191 </li>
 192 <li>R7:
 193 pre-Dublin updated: Added issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#130">130</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>,
 194 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>,
 195 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>,
 196 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
 197 </li>
 198 <li>R6:
 199 pre-Dublin mailing. Added issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>,
 200 and <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 201 </li>
 202 <li>R5:
 203 update issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>; added issues
 204 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a> to <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>. Format revisions to prepare
 205 for making list public. (30 Dec 98)
 206 </li>
 207 <li>R4:
 208 post-Santa Cruz II updated: Issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
 209 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
 210 issues corrected. (22 Oct 98)
 211 </li>
 212 <li>R3:
 213 post-Santa Cruz II: Issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#94">94</a> to <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>
 214 added, many issues updated to reflect LWG consensus (12 Oct 98)
 215 </li>
 216 <li>R2:
 217 pre-Santa Cruz II: Issues <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a> to <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#93">93</a> added,
 218 issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
 219 </li>
 220 <li>R1:
 221 Correction to issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a> resolution, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> code
 222 format, <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
 223 </li>
 224 </ul>
 225 <h2>Defect Reports</h2>
 226 <hr>
 227 <a name="1"><h3>1.&nbsp;C library linkage editing oversight</h3></a><p>
 228 <b>Section:</b>&nbsp;17.4.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;16 Nov 1997</p>
 229 <p>The change specified in the proposed resolution below did not make
 230 it into the Standard. This change was accepted in principle at the
 231 London meeting, and the exact wording below was accepted at the
 232 Morristown meeting.</p>
 233 <p><b>Proposed resolution:</b></p>
 234 <p>Change 17.4.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a> paragraph 2
 235 from:</p>
 236
 237 <blockquote>
 238   <p>It is unspecified whether a name from the Standard C library
 239   declared with external linkage has either extern "C" or
 240   extern "C++" linkage.</p>
 241 </blockquote>
 242
 243 <p>to:</p>
 244
 245 <blockquote>
 246   <p>Whether a name from the Standard C library declared with external
 247   linkage has extern "C" or extern "C++" linkage
 248   is implementation defined. It is recommended that an implementation
 249   use extern "C++" linkage for this purpose.</p>
 250 </blockquote>
 251 <hr>
 252 <a name="3"><h3>3.&nbsp;Atexit registration during atexit() call is not described</h3></a><p>
 253 <b>Section:</b>&nbsp;18.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.support.start.term"> [lib.support.start.term]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;12 Dec 1997</p>
 254 <p>We appear not to have covered all the possibilities of
 255  exit processing with respect to
 256 atexit registration. <br>
 257 <br>
 258 Example 1: (C and C++)</p>
 259
 260 <pre>    #include &lt;stdlib.h&gt;
 261     void f1() { }
 262     void f2() { atexit(f1); }
 263
 264     int main()
 265     {
 266         atexit(f2); // the only use of f2
 267         return 0; // for C compatibility
 268     }</pre>
 269
 270 <p>At program exit, f2 gets called due to its registration in
 271 main. Running f2 causes f1 to be newly registered during the exit
 272 processing. Is this a valid program? If so, what are its
 273 semantics?</p>
 274
 275 <p>
 276 Interestingly, neither the C standard, nor the C++ draft standard nor
 277 the forthcoming C9X Committee Draft says directly whether you can
 278 register a function with atexit during exit processing.</p>
 279
 280 <p>
 281 All 3 standards say that functions are run in reverse order of their
 282 registration. Since f1 is registered last, it ought to be run first,
 283 but by the time it is registered, it is too late to be first.</p>
 284
 285 <p>If the program is valid, the standards are self-contradictory about
 286 its semantics.</p>
 287
 288 <p>Example 2: (C++ only)</p>
 289
 290 <pre>
 291     void F() { static T t; } // type T has a destructor
 292
 293     int main()
 294     {
 295         atexit(F); // the only use of F
 296     }
 297 </pre>
 298
 299 <p>Function F registered with atexit has a local static variable t,
 300 and F is called for the first time during exit processing. A local
 301 static object is initialized the first time control flow passes
 302 through its definition, and all static objects are destroyed during
 303 exit processing. Is the code valid? If so, what are its semantics?</p>
 304
 305 <p>
 306 Section 18.3 "Start and termination" says that if a function
 307 F is registered with atexit before a static object t is initialized, F
 308 will not be called until after t's destructor completes.</p>
 309
 310 <p>
 311 In example 2, function F is registered with atexit before its local
 312 static object O could possibly be initialized. On that basis, it must
 313 not be called by exit processing until after O's destructor
 314 completes. But the destructor cannot be run until after F is called,
 315 since otherwise the object could not be constructed in the first
 316 place.</p>
 317
 318 <p>If the program is valid, the standard is self-contradictory about
 319 its semantics.</p>
 320
 321 <p>I plan to submit Example 1 as a public comment on the C9X CD, with
 322 a recommendation that the results be undefined. (Alternative: make it
 323 unspecified. I don't think it is worthwhile to specify the case where
 324 f1 itself registers additional functions, each of which registers
 325 still more functions.)</p>
 326
 327 <p>I think we should resolve the situation in the whatever way the C
 328 committee decides. </p>
 329
 330 <p>For Example 2, I recommend we declare the results undefined.</p>
 331
 332 <p><i>[See reflector message lib-6500 for further discussion.]</i></p>
 333
 334 <p><b>Proposed resolution:</b></p>
 335 <p>Change section 18.3/8 from:</p>
 336 <blockquote>
 337   First, objects with static storage duration are destroyed and
 338   functions registered by calling atexit are called. Objects with
 339   static storage duration are destroyed in the reverse order of the
 340   completion of their constructor.  (Automatic objects are not
 341   destroyed as a result of calling exit().) Functions registered with
 342   atexit are called in the reverse order of their registration.  A
 343   function registered with atexit before an object obj1 of static
 344   storage duration is initialized will not be called until obj1's
 345   destruction has completed. A function registered with atexit after
 346   an object obj2 of static storage duration is initialized will be
 347   called before obj2's destruction starts.
 348 </blockquote>
 349 <p>to:</p>
 350 <blockquote>
 351   First, objects with static storage duration are destroyed and
 352   functions registered by calling atexit are called. Non-local objects
 353   with static storage duration are destroyed in the reverse order of
 354   the completion of their constructor. (Automatic objects are not
 355   destroyed as a result of calling exit().) Functions registered with
 356   atexit are called in the reverse order of their registration, except
 357   that a function is called after any previously registered functions
 358   that had already been called at the time it was registered. A
 359   function registered with atexit before a non-local object obj1 of
 360   static storage duration is initialized will not be called until
 361   obj1's destruction has completed. A function registered with atexit
 362   after a non-local object obj2 of static storage duration is
 363   initialized will be called before obj2's destruction starts. A local
 364   static object obj3 is destroyed at the same time it would be if a
 365   function calling the obj3 destructor were registered with atexit at
 366   the completion of the obj3 constructor.
 367 </blockquote>
 368 <p><b>Rationale:</b></p>
 369 <p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
 370 supporting to the proposed resolution.</p>
 371 <hr>
 372 <a name="5"><h3>5.&nbsp;String::compare specification questionable</h3></a><p>
 373 <b>Section:</b>&nbsp;21.3.6.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::compare"> [lib.string::compare]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jack Reeves&nbsp; <b>Date:</b>&nbsp;11 Dec 1997</p>
 374 <p>At the very end of the basic_string class definition is the signature: int
 375 compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
 376 following text this is defined as: returns
 377 basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
 378 basic_string&lt;charT,traits,Allocator&gt;(s,n2); </p>
 379
 380 <p>Since the constructor basic_string(const charT* s, size_type n, const Allocator&amp; a
 381 = Allocator()) clearly requires that s != NULL and n &lt; npos and further states that it
 382 throws length_error if n == npos, it appears the compare() signature above should always
 383 throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
 384 null terminated character array. </p>
 385
 386 <p>This appears to be a typo since the obvious intent is to allow either the call above or
 387 something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
 388
 389 <p>This would imply that what was really intended was two signatures int compare(size_type
 390 pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
 391 charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
 392 <p><b>Proposed resolution:</b></p>
 393 <p>Replace the compare signature in 21.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>
 394 (at the very end of the basic_string synopsis) which reads:</p>
 395
 396 <blockquote>
 397   <p><tt>int compare(size_type pos1, size_type n1,<br>
 398   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
 399   size_type n2 = npos) const;</tt></p>
 400 </blockquote>
 401
 402 <p>with:</p>
 403
 404 <blockquote>
 405   <p><tt>int compare(size_type pos1, size_type n1,<br>
 406   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s) const;<br>
 407   int compare(size_type pos1, size_type n1,<br>
 408   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
 409   size_type n2) const;</tt></p>
 410 </blockquote>
 411
 412 <p>Replace the portion of 21.3.6.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::compare"> [lib.string::compare]</a>
 413 paragraphs 5 and 6 which read:</p>
 414
 415 <blockquote>
 416   <p>
 417 <tt>int compare(size_type pos, size_type n1,<br>
 418   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; charT * s, size_type n2
 419   = npos) const;<br>
 420   </tt>Returns:<tt><br>
 421   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 422   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 423   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt>
 424 </p>
 425 </blockquote>
 426
 427 <p>with:</p>
 428
 429 <blockquote>
 430   <p>
 431 <tt>int compare(size_type pos, size_type n1,<br>
 432   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s) const;<br>
 433   </tt>Returns:<tt><br>
 434   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 435   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 436   basic_string&lt;charT,traits,Allocator&gt;( s ))<br>
 437   <br>
 438   int compare(size_type pos, size_type n1,<br>
 439   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s,
 440   size_type n2) const;<br>
 441   </tt>Returns:<tt><br>
 442   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 443   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 444   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt>
 445 </p>
 446 </blockquote>
 447
 448 <p>Editors please note that in addition to splitting the signature, the third argument
 449 becomes const, matching the existing synopsis.</p>
 450 <p><b>Rationale:</b></p>
 451 <p>While the LWG dislikes adding signatures, this is a clear defect in
 452 the Standard which must be fixed.&nbsp; The same problem was also
 453 identified in issues 7 (item 5) and 87.</p>
 454 <hr>
 455 <a name="7"></a><h3><a name="7">7.&nbsp;String clause minor problems</a></h3><p>
 456 <b>Section:</b>&nbsp;21 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.strings"> [lib.strings]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;15 Dec 1997</p>
 457 <p>(1) In 21.3.5.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, the description of template
 458 &lt;class InputIterator&gt; insert(iterator, InputIterator,
 459 InputIterator) makes no sense. It refers to a member function that
 460 doesn't exist. It also talks about the return value of a void
 461 function. </p>
 462
 463 <p>(2) Several versions of basic_string::replace don't appear in the
 464 class synopsis. </p>
 465
 466 <p>(3) basic_string::push_back appears in the synopsis, but is never
 467 described elsewhere.  In the synopsis its argument is const charT,
 468 which doesn't makes much sense; it should probably be charT, or
 469 possible const charT&amp;. </p>
 470
 471 <p>(4) basic_string::pop_back is missing. </p>
 472
 473 <p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
 474 = npos) make no sense. First, it's const charT* in the synopsis and
 475 charT* in the description. Second, given what it says in RETURNS,
 476 leaving out the final argument will always result in an exception
 477 getting thrown. This is paragraphs 5 and 6 of
 478 21.3.6.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::compare"> [lib.string::compare]</a>
 479 </p>
 480
 481 <p>(6) In table 37, in section 21.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>,
 482 there's a note for X::move(s, p, n). It says "Copies correctly
 483 even where p is in [s, s+n)". This is correct as far as it goes,
 484 but it doesn't go far enough; it should also guarantee that the copy
 485 is correct even where s in in [p, p+n). These are two orthogonal
 486 guarantees, and neither one follows from the other. Both guarantees
 487 are necessary if X::move is supposed to have the same sort of
 488 semantics as memmove (which was clearly the intent), and both
 489 guarantees are necessary if X::move is actually supposed to be
 490 useful. </p>
 491 <p><b>Proposed resolution:</b></p>
 492 <p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
 493 <br>
 494 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
 495 <br>
 496 ITEM 2:&nbsp; Not a defect; the Standard is clear.. There are ten versions of replace() in
 497 the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
 498 <br>
 499 ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
 500 [lib.basic.string]) from:</p>
 501
 502 <p>&nbsp;&nbsp;&nbsp;&nbsp; void push_back(const charT)<br>
 503 <br>
 504 to<br>
 505 <br>
 506 &nbsp;&nbsp;&nbsp;&nbsp; void push_back(charT)<br>
 507 <br>
 508 Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
 509 <br>
 510 &nbsp;&nbsp;&nbsp; void basic_string::push_back(charT c);<br>
 511 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to append(static_cast&lt;size_type&gt;(1), c);<br>
 512 <br>
 513 ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
 514 <br>
 515 ITEM 5: Duplicate; see issue 5 (and 87).<br>
 516 <br>
 517 ITEM 6: In table 37, Replace:<br>
 518 <br>
 519 &nbsp;&nbsp;&nbsp; "Copies correctly even where p is in [s, s+n)."<br>
 520 <br>
 521 with:<br>
 522 <br>
 523 &nbsp;&nbsp;&nbsp;&nbsp; "Copies correctly even where the ranges [p, p+n) and [s,
 524 s+n) overlap."</p>
 525 <hr>
 526 <a name="8"><h3>8.&nbsp;Locale::global lacks guarantee</h3></a><p>
 527 <b>Section:</b>&nbsp;22.1.1.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;24 Dec 1997</p>
 528 <p>It appears there's an important guarantee missing from clause
 529 22. We're told that invoking locale::global(L) sets the C locale if L
 530 has a name. However, we're not told whether or not invoking
 531 setlocale(s) sets the global C++ locale. </p>
 532
 533 <p>The intent, I think, is that it should not, but I can't find any
 534 such words anywhere. </p>
 535 <p><b>Proposed resolution:</b></p>
 536 <p>Add a sentence at the end of 22.1.1.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a>,
 537 paragraph 2:&nbsp; </p>
 538
 539 <blockquote>
 540   <p>No library function other than <tt>locale::global()</tt> shall affect
 541   the value returned by <tt>locale()</tt>. </p>
 542
 543 </blockquote>
 544 <hr>
 545 <a name="9"><h3>9.&nbsp;Operator new(0) calls should not yield the same pointer</h3></a><p>
 546 <b>Section:</b>&nbsp;18.4.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete"> [lib.new.delete]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;4 Jan 1998</p>
 547 <p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
 548 section 3.7.3.1 of CD2 seems to allow for the possibility that all
 549 calls to operator new(0) yield the same pointer, an implementation
 550 technique specifically prohibited by ARM 5.3.3.Was this prohibition
 551 really lifted? Does the FDIS agree with CD2 in the regard? [Issues
 552 list maintainer's note: the IS is the same.]</p>
 553 <p><b>Proposed resolution:</b></p>
 554 <p>Change the last paragraph of 3.7.3 from:</p>
 555 <blockquote>
 556   <p>Any allocation and/or deallocation functions defined in a C++ program shall
 557   conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
 558 </blockquote>
 559 <p>to:</p>
 560 <blockquote>
 561   <p>Any allocation and/or deallocation functions defined in a C++ program,
 562   including the default versions in the library, shall conform to the semantics
 563   specified in 3.7.3.1 and 3.7.3.2.</p>
 564 </blockquote>
 565 <p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
 566 <blockquote>
 567   <p>If the size of the space requested is zero, the value returned shall not be
 568   a null pointer value (4.10).</p>
 569 </blockquote>
 570 <p>to:</p>
 571 <blockquote>
 572   <p>Even if the size of the space requested is zero, the request can fail. If
 573   the request succeeds, the value returned shall be a non-null pointer value
 574   (4.10) p0 different from any previously returned value p1, unless that value
 575   p1 was since passed to an operator delete.</p>
 576 </blockquote>
 577 <p>5.3.4/7 currently reads:</p>
 578 <blockquote>
 579   <p>When the value of the expression in a direct-new-declarator is zero, the
 580   allocation function is called to allocate an array with no elements. The
 581   pointer returned by the new-expression is non-null. [Note: If the library
 582   allocation function is called, the pointer returned is distinct from the
 583   pointer to any other object.]</p>
 584 </blockquote>
 585 <p>Retain the first sentence, and delete the remainder.</p>
 586 <p>18.4.1 currently has no text. Add the following:</p>
 587 <blockquote>
 588   <p>Except where otherwise specified, the provisions of 3.7.3 apply to the
 589   library versions of operator new and operator delete.</p>
 590 </blockquote>
 591 <p>To 18.4.1.3, add the following text:</p>
 592 <blockquote>
 593   <p>The provisions of 3.7.3 do not apply to these reserved placement forms of
 594   operator new and operator delete.</p>
 595 </blockquote>
 596 <p><b>Rationale:</b></p>
 597 <p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
 598 supporting to the proposed resolution.</p>
 599 <hr>
 600 <a name="11"><h3>11.&nbsp;Bitset minor problems</h3></a><p>
 601 <b>Section:</b>&nbsp;23.3.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;22 Jan 1998</p>
 602 <p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is
 603 not documented in 23.3.5.2. </p>
 604
 605 <p>(2) The class synopsis only gives a single signature for bitset&lt;&gt;::operator[],
 606 reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
 607 on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
 608
 609 <p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
 610 trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
 611 go in the Effects clause.</p>
 612 <p><b>Proposed resolution:</b></p>
 613 <p>ITEMS 1 AND 2:<br>
 614 <br>
 615 In the bitset synopsis (23.3.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>),
 616 replace the member function <br>
 617 <br>
 618 <tt>&nbsp;&nbsp;&nbsp; reference operator[](size_t pos);<br>
 619 </tt><br>
 620 with the two member functions<br>
 621 <br>
 622 <tt>&nbsp;&nbsp;&nbsp; bool operator[](size_t pos) const; <br>
 623 &nbsp;&nbsp;&nbsp; reference operator[](size_t pos); <br>
 624 </tt><br>
 625 Add the following text at the end of 23.3.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>,
 626 immediately after paragraph 45:</p>
 627
 628 <blockquote>
 629   <p>
 630 <tt>bool operator[](size_t pos) const;</tt><br>
 631   Requires: pos is valid<br>
 632   Throws: nothing<br>
 633   Returns: <tt>test(pos)</tt><br>
 634   <br>
 635   <tt>bitset&lt;N&gt;::reference operator[](size_t pos);</tt> <br>
 636   Requires: pos is valid<br>
 637   Throws: nothing<br>
 638   Returns: An object of type <tt>bitset&lt;N&gt;::reference</tt> such that <tt>(*this)[pos]
 639   == this-&gt;test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this-&gt;set(pos,
 640   val);</tt>
 641 </p>
 642 </blockquote>
 643 <p><b>Rationale:</b></p>
 644 <p>The LWG believes Item 3 is not a defect. "Formatted
 645 input" implies the desired semantics. See 27.6.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted"> [lib.istream.formatted]</a>.
 646 </p>
 647 <hr>
 648 <a name="13"><h3>13.&nbsp;Eos refuses to die</h3></a><p>
 649 <b>Section:</b>&nbsp;27.6.1.2.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;William M. Miller&nbsp; <b>Date:</b>&nbsp;3 Mar 1998</p>
 650 <p>In 27.6.1.2.3, there is a reference to "eos", which is
 651 the only one in the whole draft (at least using Acrobat search), so
 652 it's undefined. </p>
 653 <p><b>Proposed resolution:</b></p>
 654 <p>In 27.6.1.2.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, replace "eos" with
 655 "charT()"</p>
 656 <hr>
 657 <a name="14"><h3>14.&nbsp;Locale::combine should be const</h3></a><p>
 658 <b>Section:</b>&nbsp;22.1.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.members"> [lib.locale.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 659 <p>locale::combine is the only member function of locale (other than constructors and
 660 destructor) that is not const. There is no reason for it not to be const, and good reasons
 661 why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
 662 paragraph 6: "An instance of a locale is immutable." </p>
 663
 664 <p>History: this member function originally was a constructor. it happened that the
 665 interface it specified had no corresponding language syntax, so it was changed to a member
 666 function. As constructors are never const, there was no "const" in the interface
 667 which was transformed into member "combine". It should have been added at that
 668 time, but the omission was not noticed. </p>
 669 <p><b>Proposed resolution:</b></p>
 670 <p>In 22.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> and also in 22.1.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.members"> [lib.locale.members]</a>, add
 671 "const" to the declaration of member combine: </p>
 672 <blockquote>
 673   <pre>template &lt;class Facet&gt; locale combine(const locale&amp; other) const; </pre>
 674 </blockquote>
 675 <hr>
 676 <a name="15"><h3>15.&nbsp;Locale::name requirement inconsistent</h3></a><p>
 677 <b>Section:</b>&nbsp;22.1.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.members"> [lib.locale.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 678 <p>locale::name() is described as returning a string that can be passed to a locale
 679 constructor, but there is no matching constructor. </p>
 680 <p><b>Proposed resolution:</b></p>
 681 <p>In 22.1.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.members"> [lib.locale.members]</a>, paragraph 5, replace
 682 "<tt>locale(name())</tt>" with
 683 "<tt>locale(name().c_str())</tt>".
 684 </p>
 685 <hr>
 686 <a name="16"><h3>16.&nbsp;Bad ctype_byname&lt;char&gt; decl</h3></a><p>
 687 <b>Section:</b>&nbsp;22.2.1.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 688 <p>The new virtual members ctype_byname&lt;char&gt;::do_widen and do_narrow did not get
 689 edited in properly. Instead, the member do_widen appears four times, with wrong argument
 690 lists. </p>
 691 <p><b>Proposed resolution:</b></p>
 692 <p>The correct declarations for the overloaded members
 693 <tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
 694 from 22.2.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.special"> [lib.facet.ctype.special]</a>.</p>
 695 <hr>
 696 <a name="17"><h3>17.&nbsp;Bad bool parsing</h3></a><p>
 697 <b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 698 <p>This section describes the process of parsing a text boolean value from the input
 699 stream. It does not say it recognizes either of the sequences "true" or
 700 "false" and returns the corresponding bool value; instead, it says it recognizes
 701 only one of those sequences, and chooses which according to the received value of a
 702 reference argument intended for returning the result, and reports an error if the other
 703 sequence is found. (!) Furthermore, it claims to get the names from the ctype&lt;&gt;
 704 facet rather than the numpunct&lt;&gt; facet, and it examines the "boolalpha"
 705 flag wrongly; it doesn't define the value "loc"; and finally, it computes
 706 wrongly whether to use numeric or "alpha" parsing.<br>
 707 <br>
 708 I believe the correct algorithm is "as if": </p>
 709
 710 <pre>  // in, err, val, and str are arguments.
 711   err = 0;
 712   const numpunct&lt;charT&gt;&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(str.getloc());
 713   const string_type t = np.truename(), f = np.falsename();
 714   bool tm = true, fm = true;
 715   size_t pos = 0;
 716   while (tm &amp;&amp; pos &lt; t.size() || fm &amp;&amp; pos &lt; f.size()) {
 717     if (in == end) { err = str.eofbit; }
 718     bool matched = false;
 719     if (tm &amp;&amp; pos &lt; t.size()) {
 720       if (!err &amp;&amp; t[pos] == *in) matched = true;
 721       else tm = false;
 722     }
 723     if (fm &amp;&amp; pos &lt; f.size()) {
 724       if (!err &amp;&amp; f[pos] == *in) matched = true;
 725       else fm = false;
 726     }
 727     if (matched) { ++in; ++pos; }
 728     if (pos &gt; t.size()) tm = false;
 729     if (pos &gt; f.size()) fm = false;
 730   }
 731   if (tm == fm || pos == 0) { err |= str.failbit; }
 732   else                      { val = tm; }
 733   return in;</pre>
 734
 735 <p>Notice this works reasonably when the candidate strings are both empty, or equal, or
 736 when one is a substring of the other. The proposed text below captures the logic of the
 737 code above.</p>
 738 <p><b>Proposed resolution:</b></p>
 739 <p>In 22.2.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, in the first line of paragraph 14,
 740 change "&amp;&amp;" to "&amp;".</p>
 741
 742 <p>Then, replace paragraphs 15 and 16 as follows:</p>
 743
 744 <blockquote>
 745
 746   <p>Otherwise target sequences are determined "as if" by
 747   calling the members <tt>falsename()</tt> and
 748   <tt>truename()</tt> of the facet obtained by
 749   <tt>use_facet&lt;numpunct&lt;charT&gt;&nbsp;&gt;(str.getloc())</tt>.
 750   Successive characters in the range <tt>[in,end)</tt> (see
 751   [lib.sequence.reqmts]) are obtained and matched against
 752   corresponding positions in the target sequences only as necessary to
 753   identify a unique match. The input iterator <tt>in</tt> is
 754   compared to <tt>end</tt> only when necessary to obtain a
 755   character. If and only if a target sequence is uniquely matched,
 756   <tt>val</tt> is set to the corresponding value.</p>
 757
 758 </blockquote>
 759
 760 <blockquote>
 761   <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
 762   successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
 763   <tt>str.eofbit</tt> if, when seeking another character to match, it is found that
 764   <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
 765   <tt>(str.failbit|str.eofbit)</tt>if
 766   the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
 767   <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
 768   <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
 769   <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
 770   <tt>true</tt>:"1"
 771   and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
 772   and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
 773   <tt>err==str.failbit</tt>. --end example]</p>
 774 </blockquote>
 775 <hr>
 776 <a name="18"><h3>18.&nbsp;Get(...bool&amp;) omitted</h3></a><p>
 777 <b>Section:</b>&nbsp;22.2.2.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 778 <p>In the list of num_get&lt;&gt; non-virtual members on page 22-23, the member
 779 that parses bool values was omitted from the list of definitions of non-virtual
 780 members, though it is listed in the class definition and the corresponding
 781 virtual is listed everywhere appropriate. </p>
 782 <p><b>Proposed resolution:</b></p>
 783 <p>Add at the beginning of 22.2.2.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>
 784 another get member for bool&amp;, copied from the entry in
 785 22.2.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.num.get"> [lib.locale.num.get]</a>.</p>
 786 <hr>
 787 <a name="19"><h3>19.&nbsp;"Noconv" definition too vague</h3></a><p>
 788 <b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 789 <p>
 790 In the definitions of codecvt&lt;&gt;::do_out and do_in, they are
 791 specified to return noconv if "no conversion is
 792 needed". This definition is too vague, and does not say
 793 normatively what is done with the buffers.
 794 </p>
 795 <p><b>Proposed resolution:</b></p>
 796 <p>
 797 Change the entry for noconv in the table under paragraph 4 in section
 798 22.2.1.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> to read:
 799 </p>
 800 <blockquote>
 801   <p>
 802 <tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
 803   and input sequence is identical to converted sequence.</p>
 804 </blockquote>
 805 <p>Change the Note in paragraph 2 to normative text as follows:</p>
 806 <blockquote>
 807   <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
 808   same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
 809   <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
 810   unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
 811 </blockquote>
 812 <hr>
 813 <a name="20"><h3>20.&nbsp;Thousands_sep returns wrong type</h3></a><p>
 814 <b>Section:</b>&nbsp;22.2.3.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 815 <p>The synopsis for numpunct&lt;&gt;::do_thousands_sep, and the
 816 definition of numpunct&lt;&gt;::thousands_sep which calls it, specify
 817 that it returns a value of type char_type. Here it is erroneously
 818 described as returning a "string_type". </p>
 819 <p><b>Proposed resolution:</b></p>
 820 <p>In 22.2.3.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>, above paragraph 2, change
 821 "string_type" to "char_type". </p>
 822 <hr>
 823 <a name="21"><h3>21.&nbsp;Codecvt_byname&lt;&gt; instantiations</h3></a><p>
 824 <b>Section:</b>&nbsp;22.1.1.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 825 <p>In the second table in the section, captioned "Required
 826 instantiations", the instantiations for codecvt_byname&lt;&gt;
 827 have been omitted. These are necessary to allow users to construct a
 828 locale by name from facets. </p>
 829 <p><b>Proposed resolution:</b></p>
 830 <p>Add in 22.1.1.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> to the table captioned
 831 "Required instantiations", in the category "ctype"
 832 the lines </p>
 833
 834 <blockquote>
 835   <pre>codecvt_byname&lt;char,char,mbstate_t&gt;,
 836 codecvt_byname&lt;wchar_t,char,mbstate_t&gt; </pre>
 837 </blockquote>
 838 <hr>
 839 <a name="22"><h3>22.&nbsp;Member open vs. flags</h3></a><p>
 840 <b>Section:</b>&nbsp;27.8.1.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 841 <p>The description of basic_istream&lt;&gt;::open leaves unanswered questions about how it
 842 responds to or changes flags in the error status for the stream. A strict reading
 843 indicates that it ignores the bits and does not change them, which confuses users who do
 844 not expect eofbit and failbit to remain set after a successful open. There are three
 845 reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
 846 and eofbit on call to open(). </p>
 847 <p><b>Proposed resolution:</b></p>
 848 <p>In 27.8.1.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> paragraph 3, <i>and</i> in 27.8.1.10 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a> paragraph 3, under open() effects, add a footnote:
 849 </p>
 850
 851 <blockquote>
 852   <p>A successful open does not change the error state.</p>
 853 </blockquote>
 854 <p><b>Rationale:</b></p>
 855 <p>This may seem surprising to some users, but it's just an instance
 856 of a general rule: error flags are never cleared by the
 857 implementation. The only way error flags are are ever cleared is if
 858 the user explicitly clears them by hand.</p>
 859
 860 <p>The LWG believed that preserving this general rule was
 861 important enough so that an exception shouldn't be made just for this
 862 one case.  The resolution of this issue clarifies what the LWG
 863 believes to have been the original intent.</p>
 864
 865 <hr>
 866 <a name="24"><h3>24.&nbsp;"do_convert" doesn't exist</h3></a><p>
 867 <b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 868 <p>The description of codecvt&lt;&gt;::do_out and do_in mentions a
 869 symbol "do_convert" which is not defined in the
 870 standard. This is a leftover from an edit, and should be "do_in
 871 and do_out". </p>
 872 <p><b>Proposed resolution:</b></p>
 873 <p>In 22.2.1.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>, paragraph 3, change
 874 "do_convert" to "do_in or do_out". Also, in 22.2.1.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, change "do_convert()" to "do_in
 875 or do_out". </p>
 876 <hr>
 877 <a name="25"><h3>25.&nbsp;String operator&lt;&lt; uses width() value wrong</h3></a><p>
 878 <b>Section:</b>&nbsp;21.3.7.9 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 879 <p>In the description of operator&lt;&lt; applied to strings, the standard says that uses
 880 the smaller of os.width() and str.size(), to pad "as described in stage 3"
 881 elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
 882 <p><b>Proposed resolution:</b></p>
 883 <p>Change 21.3.7.9 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>  paragraph 4 from:<br>
 884 <br>
 885 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
 886 ..."<br>
 887 <br>
 888 to: <br>
 889 <br>
 890 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
 891 ..."</p>
 892 <hr>
 893 <a name="26"><h3>26.&nbsp;Bad sentry example</h3></a><p>
 894 <b>Section:</b>&nbsp;27.6.1.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 895 <p>In paragraph 6, the code in the example: </p>
 896
 897 <pre>  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
 898   basic_istream&lt;charT,traits&gt;::sentry(
 899            basic_istream&lt;charT,traits&gt;&amp; is, bool noskipws = false) {
 900       ...
 901       int_type c;
 902       typedef ctype&lt;charT&gt; ctype_type;
 903       const ctype_type&amp; ctype = use_facet&lt;ctype_type&gt;(is.getloc());
 904       while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
 905         if (ctype.is(ctype.space,c)==0) {
 906           is.rdbuf()-&gt;sputbackc (c);
 907           break;
 908         }
 909       }
 910       ...
 911    }</pre>
 912
 913 <p>fails to demonstrate correct use of the facilities described. In
 914 particular, it fails to use traits operators, and specifies incorrect
 915 semantics. (E.g. it specifies skipping over the first character in the
 916 sequence without examining it.) </p>
 917 <p><b>Proposed resolution:</b></p>
 918 <p>Remove the example above from 27.6.1.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>
 919 paragraph 6.</p>
 920 <p><b>Rationale:</b></p>
 921 <p>The originally proposed replacement code for the example was not
 922 correct. The LWG tried in Kona and again in Tokyo to correct it
 923 without success. In Tokyo, an implementor reported that actual working
 924 code ran over one page in length and was quite complicated. The LWG
 925 decided that it would be counter-productive to include such a lengthy
 926 example, which might well still contain errors.</p>
 927 <hr>
 928 <a name="27"><h3>27.&nbsp;String::erase(range) yields wrong iterator</h3></a><p>
 929 <b>Section:</b>&nbsp;21.3.5.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::erase"> [lib.string::erase]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 930 <p>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://anubis.dkuug.dk/jtc1/sc22/wg21/docs/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"></a><h3><a name="28">28.&nbsp;Ctype&lt;char&gt;is ambiguous</a></h3><p>
 950 <b>Section:</b>&nbsp;22.2.1.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 951 <p>The description of the vector form of ctype&lt;char&gt;::is can be interpreted to mean
 952 something very different from what was intended. Paragraph 4 says </p>
 953
 954 <blockquote>
 955   <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
 956   table()[(unsigned char)*p]. </p>
 957 </blockquote>
 958
 959 <p>This is intended to copy the value indexed from table()[] into the place identified in
 960 vec[]. </p>
 961 <p><b>Proposed resolution:</b></p>
 962 <p>Change 22.2.1.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a>, paragraph 4, to read </p>
 963
 964 <blockquote>
 965   <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
 966   the value table()[(unsigned char)*p]. </p>
 967 </blockquote>
 968 <hr>
 969 <a name="29"><h3>29.&nbsp;Ios_base::init doesn't exist</h3></a><p>
 970 <b>Section:</b>&nbsp;27.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 971 <p>Sections 27.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> and 27.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.wide.stream.objects"> [lib.wide.stream.objects]</a> mention
 972 a function ios_base::init, which is not defined. Probably they mean
 973 basic_ios&lt;&gt;::init, defined in 27.4.4.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>,
 974 paragraph 3. </p>
 975 <p><b>Proposed resolution:</b></p>
 976 <p>[R12: modified to include paragraph 5.]</p>
 977
 978 <p>In 27.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> paragraph 2 and 5, change </p>
 979
 980 <blockquote>
 981   <p>ios_base::init </p>
 982 </blockquote>
 983
 984 <p>to </p>
 985
 986 <blockquote>
 987   <p>basic_ios&lt;char&gt;::init </p>
 988 </blockquote>
 989
 990 <p>Also, make a similar change in 27.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.wide.stream.objects"> [lib.wide.stream.objects]</a> except it
 991 should read </p>
 992
 993 <blockquote>
 994   <p>basic_ios&lt;wchar_t&gt;::init </p>
 995 </blockquote>
 996 <hr>
 997 <a name="30"><h3>30.&nbsp;Wrong header for LC_*</h3></a><p>
 998 <b>Section:</b>&nbsp;22.1.1.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 999 <p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in &lt;cctype&gt;,
1000 where they are in fact defined elsewhere to appear in &lt;clocale&gt;. </p>
1001 <p><b>Proposed resolution:</b></p>
1002 <p>In 22.1.1.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, paragraph 2, change
1003 "&lt;cctype&gt;" to read "&lt;clocale&gt;". </p>
1004 <hr>
1005 <a name="31"><h3>31.&nbsp;Immutable locale values</h3></a><p>
1006 <b>Section:</b>&nbsp;22.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1007 <p>Paragraph 6, says "An instance of <tt>locale</tt> is
1008 <i>immutable</i>; once a facet reference is obtained from it,
1009 ...". This has caused some confusion, because locale variables
1010 are manifestly assignable. </p>
1011 <p><b>Proposed resolution:</b></p>
1012 <p>In 22.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> replace paragraph 6</p>
1013
1014 <blockquote>
1015   <p>An instance of <tt>locale</tt> is immutable; once a facet
1016   reference is obtained from it, that reference remains usable as long
1017   as the locale value itself exists.</p>
1018 </blockquote>
1019
1020 <p>with</p>
1021
1022 <blockquote>
1023   <p>Once a facet reference is obtained from a locale object by
1024   calling use_facet&lt;&gt;, that reference remains usable, and the
1025   results from member functions of it may be cached and re-used, as
1026   long as some locale object refers to that facet.</p>
1027 </blockquote>
1028 <hr>
1029 <a name="32"><h3>32.&nbsp;Pbackfail description inconsistent</h3></a><p>
1030 <b>Section:</b>&nbsp;27.5.2.4.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1031 <p>The description of the required state before calling virtual member
1032 basic_streambuf&lt;&gt;::pbackfail requirements is inconsistent with the conditions
1033 described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
1034 Specifically, the latter says it calls pbackfail if: </p>
1035
1036 <p>&nbsp;&nbsp;&nbsp; traits::eq(c,gptr()[-1]) is false </p>
1037
1038 <p>where pbackfail claims to require: </p>
1039
1040 <p>&nbsp;&nbsp;&nbsp; traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
1041
1042 <p>It appears that the pbackfail description is wrong. </p>
1043 <p><b>Proposed resolution:</b></p>
1044 <p>In 27.5.2.4.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a>, paragraph 1, change:</p>
1045
1046 <blockquote>
1047   <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
1048 </blockquote>
1049
1050 <p>to </p>
1051
1052 <blockquote>
1053   <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
1054   </p>
1055 </blockquote>
1056 <p><b>Rationale:</b></p>
1057 <p>Note deliberate reordering of arguments for clarity in addition to the correction of
1058 the argument value.</p>
1059 <hr>
1060 <a name="33"><h3>33.&nbsp;Codecvt&lt;&gt; mentions from_type</h3></a><p>
1061 <b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1062 <p>In the table defining the results from do_out and do_in, the specification for the
1063 result <i>error</i> says </p>
1064
1065 <blockquote>
1066   <p>encountered a from_type character it could not convert </p>
1067 </blockquote>
1068
1069 <p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
1070 an internT for do_out. </p>
1071 <p><b>Proposed resolution:</b></p>
1072 <p>In 22.2.1.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 4, replace the definition
1073 in the table for the case of _error_ with </p>
1074
1075 <blockquote>
1076   <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
1077 </blockquote>
1078 <hr>
1079 <a name="34"><h3>34.&nbsp;True/falsename() not in ctype&lt;&gt;</h3></a><p>
1080 <b>Section:</b>&nbsp;22.2.2.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1081 <p>In paragraph 19, Effects:, members truename() and falsename are used from facet
1082 ctype&lt;charT&gt;, but it has no such members. Note that this is also a problem in
1083 22.2.2.1.2, addressed in (4). </p>
1084 <p><b>Proposed resolution:</b></p>
1085 <p>In 22.2.2.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, paragraph 19, in the Effects:
1086 clause for member put(...., bool), replace the initialization of the
1087 string_type value s as follows: </p>
1088
1089 <blockquote>
1090   <pre>const numpunct&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(loc);
1091 string_type s = val ? np.truename() : np.falsename(); </pre>
1092 </blockquote>
1093 <hr>
1094 <a name="35"><h3>35.&nbsp;No manipulator unitbuf in synopsis</h3></a><p>
1095 <b>Section:</b>&nbsp;27.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1096 <p>In 27.4.5.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fmtflags.manip"> [lib.fmtflags.manip]</a>, we have a definition for a manipulator
1097 named "unitbuf". Unlike other manipulators, it's not listed
1098 in synopsis. Similarly for "nounitbuf". </p>
1099 <p><b>Proposed resolution:</b></p>
1100 <p>Add to the synopsis for &lt;ios&gt; in 27.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a>, after
1101 the entry for "nouppercase", the prototypes: </p>
1102
1103 <blockquote>
1104   <pre>ios_base&amp; unitbuf(ios_base&amp; str);
1105 ios_base&amp; nounitbuf(ios_base&amp; str); </pre>
1106 </blockquote>
1107 <hr>
1108 <a name="36"><h3>36.&nbsp;Iword &amp; pword storage lifetime omitted</h3></a><p>
1109 <b>Section:</b>&nbsp;27.4.2.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1110 <p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
1111 specified badly, so that an implementation which only keeps the last value stored appears
1112 to conform. In particular, it says: </p>
1113
1114 <p>The reference returned may become invalid after another call to the object's iword
1115 member with a different index ... </p>
1116
1117 <p>This is not idle speculation; at least one implementation was done this way. </p>
1118 <p><b>Proposed resolution:</b></p>
1119 <p>Add in 27.4.2.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a>, in both paragraph 2 and also in
1120 paragraph 4, replace the sentence: </p>
1121
1122 <blockquote>
1123   <p>The reference returned may become invalid after another call to the object's iword
1124   [pword] member with a different index, after a call to its copyfmt member, or when the
1125   object is destroyed. </p>
1126 </blockquote>
1127
1128 <p>with: </p>
1129
1130 <blockquote>
1131   <p>The reference returned is invalid after any other operations on the object. However,
1132   the value of the storage referred to is retained, so that until the next call to copyfmt,
1133   calling iword [pword] with the same index yields another reference to the same value. </p>
1134 </blockquote>
1135
1136 <p>substituting "iword" or "pword" as appropriate. </p>
1137 <hr>
1138 <a name="37"><h3>37.&nbsp;Leftover "global" reference</h3></a><p>
1139 <b>Section:</b>&nbsp;22.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1140 <p>In the overview of locale semantics, paragraph 4, is the sentence </p>
1141
1142 <blockquote>
1143   <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
1144   the standard exception bad_cast. </p>
1145 </blockquote>
1146
1147 <p>This is not supported by the definition of use_facet&lt;&gt;, and represents semantics
1148 from an old draft. </p>
1149 <p><b>Proposed resolution:</b></p>
1150 <p>In 22.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>, paragraph 4, delete the parenthesized
1151 expression </p>
1152
1153 <blockquote>
1154   <p>(or, failing that, in the global locale) </p>
1155 </blockquote>
1156 <hr>
1157 <a name="38"><h3>38.&nbsp;Facet definition incomplete</h3></a><p>
1158 <b>Section:</b>&nbsp;22.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1159 <p>It has been noticed by Esa Pulkkinen that the definition of
1160 "facet" is incomplete. In particular, a class derived from
1161 another facet, but which does not define a member <i>id</i>, cannot
1162 safely serve as the argument <i>F</i> to use_facet&lt;F&gt;(loc),
1163 because there is no guarantee that a reference to the facet instance
1164 stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
1165 <p><b>Proposed resolution:</b></p>
1166 <p>In the definition of std::use_facet&lt;&gt;(), replace the text in paragraph 1 which
1167 reads: </p>
1168
1169 <blockquote>
1170   <p>Get a reference to a facet of a locale. </p>
1171 </blockquote>
1172
1173 <p>with: </p>
1174
1175 <blockquote>
1176   <p>Requires: <tt>Facet</tt> is a facet class whose definition
1177   contains the public static member <tt>id</tt> as defined in 22.1.1.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.facet"> [lib.locale.facet]</a>. </p>
1178 </blockquote>
1179
1180 <p><i>[
1181 Kona: strike as overspecification the text "(not inherits)"
1182 from the original resolution, which read "... whose definition
1183 contains (not inherits) the public static member
1184 <tt>id</tt>..."
1185 ]</i></p>
1186
1187 <hr>
1188 <a name="39"><h3>39.&nbsp;istreambuf_iterator&lt;&gt;::operator++(int) definition garbled</h3></a><p>
1189 <b>Section:</b>&nbsp;24.5.3.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::op%2B%2B"> [lib.istreambuf.iterator::op++]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1190 <p>Following the definition of istreambuf_iterator&lt;&gt;::operator++(int) in paragraph
1191 3, the standard contains three lines of garbage text left over from a previous edit. </p>
1192
1193 <blockquote>
1194   <pre>istreambuf_iterator&lt;charT,traits&gt; tmp = *this;
1195 sbuf_-&gt;sbumpc();
1196 return(tmp); </pre>
1197 </blockquote>
1198 <p><b>Proposed resolution:</b></p>
1199 <p>In 24.5.3.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::op%2B%2B"> [lib.istreambuf.iterator::op++]</a>, delete the three lines of code at the
1200 end of paragraph 3. </p>
1201 <hr>
1202 <a name="40"><h3>40.&nbsp;Meaningless normative paragraph in examples</h3></a><p>
1203 <b>Section:</b>&nbsp;22.2.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1204 <p>Paragraph 3 of the locale examples is a description of part of an
1205 implementation technique that has lost its referent, and doesn't mean
1206 anything. </p>
1207 <p><b>Proposed resolution:</b></p>
1208 <p>Delete 22.2.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 3 which begins "This
1209 initialization/identification system depends...", or (at the
1210 editor's option) replace it with a place-holder to keep the paragraph
1211 numbering the same. </p>
1212 <hr>
1213 <a name="41"><h3>41.&nbsp;Ios_base needs clear(), exceptions()</h3></a><p>
1214 <b>Section:</b>&nbsp;27.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1215 <p>The description of ios_base::iword() and pword() in 27.4.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>, say that if they fail, they "set badbit,
1216 which may throw an exception". However, ios_base offers no
1217 interface to set or to test badbit; those interfaces are defined in
1218 basic_ios&lt;&gt;. </p>
1219 <p><b>Proposed resolution:</b></p>
1220 <p>Change the description in 27.4.2.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a> in
1221 paragraph 2, and also in paragraph 4, as follows. Replace</p>
1222
1223 <blockquote>
1224   <p>If the function fails it sets badbit, which may throw an exception.</p>
1225 </blockquote>
1226
1227 <p>with</p>
1228
1229 <blockquote>
1230   <p>If the function fails, and <tt>*this</tt> is a base sub-object of
1231   a <tt>basic_ios&lt;&gt;</tt> object or sub-object, the effect is
1232   equivalent to calling <tt>basic_ios&lt;&gt;::setstate(badbit)</tt>
1233   on the derived object (which may throw <tt>failure</tt>).</p>
1234 </blockquote>
1235
1236 <p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
1237 setstate(badbit).]</i></p>
1238
1239 <hr>
1240 <a name="42"><h3>42.&nbsp;String ctors specify wrong default allocator</h3></a><p>
1241 <b>Section:</b>&nbsp;21.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1242 <p>The basic_string&lt;&gt; copy constructor: </p>
1243
1244 <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1245              size_type n = npos, const Allocator&amp; a = Allocator()); </pre>
1246
1247 <p>specifies an Allocator argument default value that is
1248 counter-intuitive. The natural choice for a the allocator to copy from
1249 is str.get_allocator(). Though this cannot be expressed in
1250 default-argument notation, overloading suffices. </p>
1251
1252 <p>Alternatively, the other containers in Clause 23 (deque, list,
1253 vector) do not have this form of constructor, so it is inconsistent,
1254 and an evident source of confusion, for basic_string&lt;&gt; to have
1255 it, so it might better be removed. </p>
1256 <p><b>Proposed resolution:</b></p>
1257 <p> In 21.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, replace the declaration of the copy
1258 constructor as follows: </p>
1259
1260 <blockquote>
1261   <pre>basic_string(const basic_string&amp; str);
1262 basic_string(const basic_string&amp; str, size_type pos, size_type n = npos,
1263              const Allocator&amp; a = Allocator());</pre>
1264 </blockquote>
1265
1266 <p>In 21.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace the copy constructor declaration
1267 as above. Add to paragraph 5, Effects:</p>
1268
1269 <blockquote>
1270   <p>In the first form, the Allocator value used is copied from
1271   <tt>str.get_allocator()</tt>.</p>
1272 </blockquote>
1273 <p><b>Rationale:</b></p>
1274 <p>The LWG believes the constructor is actually broken, rather than
1275 just an unfortunate design choice.</p>
1276
1277 <p>The LWG considered two other possible resolutions:</p>
1278
1279 <p>A. In 21.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, replace the declaration of the copy
1280 constructor as follows:</p>
1281
1282 <blockquote>
1283   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1284              size_type n = npos);
1285 basic_string(const basic_string&amp; str, size_type pos,
1286              size_type n, const Allocator&amp; a); </pre>
1287 </blockquote>
1288
1289 <p>In 21.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace the copy constructor declaration
1290 as above. Add to paragraph 5, Effects: </p>
1291
1292 <blockquote>
1293   <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
1294   value <tt>str.get_allocator()</tt>. </p>
1295 </blockquote>
1296
1297 <p>B. In 21.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, and also in 21.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace
1298 the declaration of the copy constructor as follows: </p>
1299
1300 <blockquote>
1301   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1302              size_type n = npos); </pre>
1303 </blockquote>
1304
1305 <p>The proposed resolution reflects the original intent of the LWG. It
1306 was also noted by Pete Becker that this fix "will cause
1307 a small amount of existing code to now work correctly."</p>
1308
1309 <p><i>[
1310 Kona: issue editing snafu fixed - the proposed resolution now correctly
1311 reflects the LWG consensus.
1312 ]</i></p>
1313 <hr>
1314 <a name="46"></a><h3><a name="46">46.&nbsp;Minor Annex D errors</a></h3><p>
1315 <b>Section:</b>&nbsp;D.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.str.strstreams"> [depr.str.strstreams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Brendan Kehoe&nbsp; <b>Date:</b>&nbsp; 1 Jun 1998</p>
1316 <p>See lib-6522 and edit-814.</p>
1317 <p><b>Proposed resolution:</b></p>
1318 <p>Change D.7.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf"> [depr.strstreambuf]</a> (since streambuf is a typedef of
1319 basic_streambuf&lt;char&gt;) from:</p>
1320
1321 <pre>         virtual streambuf&lt;char&gt;* setbuf(char* s, streamsize n);</pre>
1322
1323 <p>to:</p>
1324
1325 <pre>         virtual streambuf* setbuf(char* s, streamsize n);</pre>
1326
1327 <p>In D.7.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.strstream"> [depr.strstream]</a> insert the semicolon now missing after
1328 int_type:</p>
1329
1330 <pre>     namespace std {
1331        class strstream
1332          : public basic_iostream&lt;char&gt; {
1333        public:
1334          // Types
1335          typedef char                                char_type;
1336          typedef typename char_traits&lt;char&gt;::int_type int_type
1337          typedef typename char_traits&lt;char&gt;::pos_type pos_type;</pre>
1338 <hr>
1339 <a name="47"><h3>47.&nbsp;Imbue() and getloc() Returns clauses swapped</h3></a><p>
1340 <b>Section:</b>&nbsp;27.4.2.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
1341 <p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
1342 section has two RETURNS clauses, and they make no sense as
1343 stated. They make perfect sense, though, if you swap them. Am I
1344 correct in thinking that paragraphs 2 and 4 just got mixed up by
1345 accident?</p>
1346 <p><b>Proposed resolution:</b></p>
1347 <p>In 27.4.2.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> swap paragraphs 2 and 4.</p>
1348 <hr>
1349 <a name="48"><h3>48.&nbsp;Use of non-existent exception constructor</h3></a><p>
1350 <b>Section:</b>&nbsp;27.4.2.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
1351 <p>27.4.2.1.1, paragraph 2, says that class failure initializes the
1352 base class, exception, with exception(msg). Class exception (see
1353 18.6.1) has no such constructor.</p>
1354 <p><b>Proposed resolution:</b></p>
1355 <p>Replace 27.4.2.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>, paragraph 2, with</p>
1356
1357 <blockquote>
1358   <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
1359 </blockquote>
1360 <hr>
1361 <a name="49"><h3>49.&nbsp;Underspecification of ios_base::sync_with_stdio</h3></a><p>
1362 <b>Section:</b>&nbsp;27.4.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
1363 <p>Two problems</p>
1364
1365 <p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
1366 returns. Does it return f, or does it return the previous
1367 synchronization state? My guess is the latter, but the standard
1368 doesn't say so.</p>
1369
1370 <p>(2) 27.4.2.4 doesn't say what it means for streams to be
1371 synchronized with stdio.  Again, of course, I can make some
1372 guesses. (And I'm unhappy about the performance implications of those
1373 guesses, but that's another matter.)</p>
1374 <p><b>Proposed resolution:</b></p>
1375 <p>Change the following sentence in 27.4.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>
1376 returns clause from:</p>
1377
1378 <blockquote>
1379   <p>
1380 <tt>true</tt> if the standard iostream objects (27.3) are
1381   synchronized and otherwise returns <tt>false</tt>.</p>
1382 </blockquote>
1383
1384 <p>to:</p>
1385
1386 <blockquote>
1387   <p>
1388 <tt>true</tt> if the previous state of the standard iostream
1389   objects (27.3) was synchronized and otherwise returns
1390   <tt>false</tt>.</p>
1391 </blockquote>
1392
1393 <p>Add the following immediately after 27.4.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>,
1394 paragraph 2:</p>
1395
1396 <blockquote>
1397 <p>When a standard iostream object str is <i>synchronized</i> with a
1398 standard stdio stream f, the effect of inserting a character c by</p>
1399 <pre>  fputc(f, c);
1400 </pre>
1401
1402 <p>is the same as the effect of</p>
1403 <pre>  str.rdbuf()-&gt;sputc(c);
1404 </pre>
1405
1406 <p>for any sequence of characters; the effect of extracting a
1407 character c by</p>
1408 <pre>  c = fgetc(f);
1409 </pre>
1410
1411 <p>is the same as the effect of:</p>
1412 <pre>  c = str.rdbuf()-&gt;sbumpc(c);
1413 </pre>
1414
1415 <p>for any sequences of characters; and the effect of pushing
1416 back a character c by</p>
1417 <pre>  ungetc(c, f);
1418 </pre>
1419
1420 <p>is the same as the effect of</p>
1421 <pre>  str.rdbuf()-&gt;sputbackc(c);
1422 </pre>
1423
1424 <p>for any sequence of characters.  [<i>Footnote</i>: This implies
1425 that operations on a standard iostream object can be mixed arbitrarily
1426 with operations on the corresponding stdio stream.  In practical
1427 terms, synchronization usually means that a standard iostream object
1428 and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
1429 </blockquote>
1430
1431 <p><i>[pre-Copenhagen: PJP and Matt contributed the definition
1432 of "synchronization"]</i></p>
1433
1434 <p><i>[post-Copenhagen: proposed resolution was revised slightly:
1435 text was added in the non-normative footnote to say that operations
1436 on the two streams can be mixed arbitrarily.]</i></p>
1437 <hr>
1438 <a name="50"><h3>50.&nbsp;Copy constructor and assignment operator of ios_base</h3></a><p>
1439 <b>Section:</b>&nbsp;27.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
1440 <p>As written, ios_base has a copy constructor and an assignment
1441 operator. (Nothing in the standard says it doesn't have one, and all
1442 classes have copy constructors and assignment operators unless you
1443 take specific steps to avoid them.) However, nothing in 27.4.2 says
1444 what the copy constructor and assignment operator do. </p>
1445
1446 <p>My guess is that this was an oversight, that ios_base is, like
1447 basic_ios, not supposed to have a copy constructor or an assignment
1448 operator.</p>
1449
1450 <p>
1451 Jerry Schwarz comments: Yes, its an oversight, but in the opposite
1452 sense to what you're suggesting. At one point there was a definite
1453 intention that you could copy ios_base. It's an easy way to save the
1454 entire state of a stream for future use. As you note, to carry out
1455 that intention would have required a explicit description of the
1456 semantics (e.g. what happens to the iarray and parray stuff).
1457 </p>
1458 <p><b>Proposed resolution:</b></p>
1459 <p>In 27.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>, class ios_base, specify the copy
1460 constructor and operator= members as being private.</p>
1461 <p><b>Rationale:</b></p>
1462 <p>The LWG believes the difficulty of specifying correct semantics
1463 outweighs any benefit of allowing ios_base objects to be copyable.</p>
1464 <hr>
1465 <a name="51"><h3>51.&nbsp;Requirement to not invalidate iterators missing</h3></a><p>
1466 <b>Section:</b>&nbsp;23.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;David Vandevoorde&nbsp; <b>Date:</b>&nbsp;23 Jun 1998</p>
1467 <p>The std::sort algorithm can in general only sort a given sequence
1468 by moving around values. The list&lt;&gt;::sort() member on the other
1469 hand could move around values or just update internal pointers. Either
1470 method can leave iterators into the list&lt;&gt; dereferencable, but
1471 they would point to different things. </p>
1472
1473 <p>Does the FDIS mandate anywhere which method should be used for
1474 list&lt;&gt;::sort()?</p>
1475
1476 <p>Matt Austern comments:</p>
1477
1478 <p>I think you've found an omission in the standard. </p>
1479
1480 <p>The library working group discussed this point, and there was
1481 supposed to be a general requirement saying that list, set, map,
1482 multiset, and multimap may not invalidate iterators, or change the
1483 values that iterators point to, except when an operation does it
1484 explicitly. So, for example, insert() doesn't invalidate any iterators
1485 and erase() and remove() only invalidate iterators pointing to the
1486 elements that are being erased. </p>
1487
1488 <p>I looked for that general requirement in the FDIS, and, while I
1489 found a limited form of it for the sorted associative containers, I
1490 didn't find it for list. It looks like it just got omitted. </p>
1491
1492 <p>The intention, though, is that list&lt;&gt;::sort does not
1493 invalidate any iterators and does not change the values that any
1494 iterator points to. There would be no reason to have the member
1495 function otherwise.</p>
1496 <p><b>Proposed resolution:</b></p>
1497 <p>Add a new paragraph at the end of 23.1:</p>
1498
1499 <blockquote>
1500   <p>Unless otherwise specified (either explicitly or by defining a function in terms of
1501   other functions), invoking a container member function or passing a container as an
1502   argument to a library function shall not invalidate iterators to, or change the values of,
1503   objects within that container. </p>
1504 </blockquote>
1505 <p><b>Rationale:</b></p>
1506 <p>This was US issue CD2-23-011; it was accepted in London but the
1507 change was not made due to an editing oversight. The wording in the
1508 proposed resolution below is somewhat updated from CD2-23-011,
1509 particularly the addition of the phrase "or change the values
1510 of"</p>
1511 <hr>
1512 <a name="52"><h3>52.&nbsp;Small I/O problems</h3></a><p>
1513 <b>Section:</b>&nbsp;27.4.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Jun 1998</p>
1514 <p>First, 27.4.4.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>, table 89. This is pretty obvious:
1515 it should be titled "basic_ios&lt;&gt;() effects", not
1516 "ios_base() effects". </p>
1517
1518 <p>[The second item is a duplicate; see issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#6">6</a> for
1519 resolution.]</p>
1520
1521 <p>Second, 27.4.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a> table 88 . There are a couple
1522 different things wrong with it, some of which I've already discussed
1523 with Jerry, but the most obvious mechanical sort of error is that it
1524 uses expressions like P(i) and p(i), without ever defining what sort
1525 of thing "i" is.
1526 </p>
1527
1528 <p>(The other problem is that it requires support for streampos
1529 arithmetic. This is impossible on some systems, i.e. ones where file
1530 position is a complicated structure rather than just a number. Jerry
1531 tells me that the intention was to require syntactic support for
1532 streampos arithmetic, but that it wasn't actually supposed to do
1533 anything meaningful except on platforms, like Unix, where genuine
1534 arithmetic is possible.) </p>
1535 <p><b>Proposed resolution:</b></p>
1536 <p>Change 27.4.4.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> table 89 title from
1537 "ios_base() effects" to "basic_ios&lt;&gt;()
1538 effects". </p>
1539 <hr>
1540 <a name="53"><h3>53.&nbsp;Basic_ios destructor unspecified</h3></a><p>
1541 <b>Section:</b>&nbsp;27.4.4.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Jun 1998</p>
1542 <p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
1543 The important question is whether basic_ios::~basic_ios() destroys
1544 rdbuf().</p>
1545 <p><b>Proposed resolution:</b></p>
1546 <p>Add after 27.4.4.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> paragraph 2:</p>
1547
1548 <blockquote>
1549   <p><tt>virtual ~basic_ios();</tt></p>
1550   <p>
1551 <b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
1552 </blockquote>
1553 <p><b>Rationale:</b></p>
1554 <p>The LWG reviewed the additional question of whether or not
1555 <tt>rdbuf(0)</tt> may set <tt>badbit</tt>.  The answer is
1556 clearly yes; it may be set via <tt>clear()</tt>.  See 27.4.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a>, paragraph 6.  This issue was reviewed at length
1557 by the LWG, which removed from the original proposed resolution a
1558 footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
1559 <tt>badbit</tt>".</p>
1560 <hr>
1561 <a name="54"><h3>54.&nbsp;Basic_streambuf's destructor</h3></a><p>
1562 <b>Section:</b>&nbsp;27.5.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;25 Jun 1998</p>
1563 <p>The class synopsis for basic_streambuf shows a (virtual)
1564 destructor, but the standard doesn't say what that destructor does. My
1565 assumption is that it does nothing, but the standard should say so
1566 explicitly. </p>
1567 <p><b>Proposed resolution:</b></p>
1568 <p>Add after 27.5.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a> paragraph 2:</p>
1569
1570 <blockquote>
1571   <p><tt>virtual&nbsp; ~basic_streambuf();</tt></p>
1572   <p>
1573 <b>Effects</b>: None.</p>
1574 </blockquote>
1575 <hr>
1576 <a name="55"><h3>55.&nbsp;Invalid stream position is undefined</h3></a><p>
1577 <b>Section:</b>&nbsp;27 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;26 Jun 1998</p>
1578 <p>Several member functions in clause 27 are defined in certain
1579 circumstances to return an "invalid stream position", a term
1580 that is defined nowhere in the standard. Two places (27.5.2.4.2,
1581 paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
1582 a definition in _lib.iostreams.definitions_, a nonexistent
1583 section. </p>
1584
1585 <p>I suspect that the invalid stream position is just supposed to be
1586 pos_type(-1).  Probably best to say explicitly in (for example)
1587 27.5.2.4.2 that the return value is pos_type(-1), rather than to use
1588 the term "invalid stream position", define that term
1589 somewhere, and then put in a cross-reference. </p>
1590
1591 <p>The phrase "invalid stream position" appears ten times in
1592 the C++ Standard.  In seven places it refers to a return value, and it
1593 should be changed. In three places it refers to an argument, and it
1594 should not be changed. Here are the three places where "invalid
1595 stream position" should not be changed:</p>
1596
1597 <blockquote>
1598   <p>27.7.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, paragraph 14<br>
1599   27.8.1.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 14<br>
1600   D.7.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 17
1601   </p>
1602 </blockquote>
1603 <p><b>Proposed resolution:</b></p>
1604 <p>In 27.5.2.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 4, change "Returns an
1605 object of class pos_type that stores an invalid stream position
1606 (_lib.iostreams.definitions_)" to "Returns
1607 <tt>pos_type(off_type(-1))</tt>".
1608 </p>
1609
1610 <p>In 27.5.2.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 6, change "Returns
1611 an object of class pos_type that stores an invalid stream
1612 position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
1613
1614 <p>In 27.7.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, paragraph 13, change "the object
1615 stores an invalid stream position" to "the return value is
1616 <tt>pos_type(off_type(-1))</tt>". </p>
1617
1618 <p>In 27.8.1.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 13, change "returns an
1619 invalid stream position (27.4.3)" to "returns
1620 <tt>pos_type(off_type(-1))</tt>" </p>
1621
1622 <p>In 27.8.1.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 15, change "Otherwise
1623 returns an invalid stream position (_lib.iostreams.definitions_)"
1624 to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
1625 </p>
1626
1627 <p>In D.7.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 15, change "the object
1628 stores an invalid stream position" to "the return value is
1629 <tt>pos_type(off_type(-1))</tt>" </p>
1630
1631 <p>In D.7.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 18, change "the object
1632 stores an invalid stream position" to "the return value is
1633 <tt>pos_type(off_type(-1))</tt>"</p>
1634 <hr>
1635 <a name="56"><h3>56.&nbsp;Showmanyc's return type</h3></a><p>
1636 <b>Section:</b>&nbsp;27.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;29 Jun 1998</p>
1637 <p>The class summary for basic_streambuf&lt;&gt;, in 27.5.2, says that
1638 showmanyc has return type int. However, 27.5.2.4.3 says that its
1639 return type is streamsize. </p>
1640 <p><b>Proposed resolution:</b></p>
1641 <p>Change <tt>showmanyc</tt>'s return type in the
1642 27.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> class summary to <tt>streamsize</tt>.</p>
1643 <hr>
1644 <a name="57"><h3>57.&nbsp;Mistake in char_traits</h3></a><p>
1645 <b>Section:</b>&nbsp;21.1.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;1 Jul 1998</p>
1646 <p>21.1.3.2, paragraph 3, says "The types streampos and
1647 wstreampos may be different if the implementation supports no shift
1648 encoding in narrow-oriented iostreams but supports one or more shift
1649 encodings in wide-oriented streams". </p>
1650
1651 <p>That's wrong: the two are the same type. The &lt;iosfwd&gt; summary
1652 in 27.2 says that streampos and wstreampos are, respectively, synonyms
1653 for fpos&lt;char_traits&lt;char&gt;::state_type&gt; and
1654 fpos&lt;char_traits&lt;wchar_t&gt;::state_type&gt;, and, flipping back
1655 to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
1656 char_traits&lt;char&gt;::state_type and
1657 char_traits&lt;wchar_t&gt;::state_type must both be mbstate_t. </p>
1658 <p><b>Proposed resolution:</b></p>
1659 <p>Remove the sentence in 21.1.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a> paragraph 3 which
1660 begins "The types streampos and wstreampos may be
1661 different..." . </p>
1662 <hr>
1663 <a name="59"><h3>59.&nbsp;Ambiguity in specification of gbump</h3></a><p>
1664 <b>Section:</b>&nbsp;27.5.2.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;28 Jul 1998</p>
1665 <p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
1666 next pointer for the input sequence by n." </p>
1667
1668 <p>The straightforward interpretation is that it is just gptr() +=
1669 n. An alternative interpretation, though, is that it behaves as if it
1670 calls sbumpc n times. (The issue, of course, is whether it might ever
1671 call underflow.) There is a similar ambiguity in the case of
1672 pbump. </p>
1673
1674 <p>(The "classic" AT&amp;T implementation used the
1675 former interpretation.)</p>
1676 <p><b>Proposed resolution:</b></p>
1677 <p>Change 27.5.2.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</a> paragraph 4 gbump effects from:</p>
1678
1679 <blockquote>
1680   <p>Effects: Advances the next pointer for the input sequence by n.</p>
1681 </blockquote>
1682
1683 <p>to:</p>
1684
1685 <blockquote>
1686   <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
1687 </blockquote>
1688
1689 <p>Make the same change to 27.5.2.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.put.area"> [lib.streambuf.put.area]</a> paragraph 4 pbump
1690 effects.</p>
1691 <hr>
1692 <a name="60"><h3>60.&nbsp;What is a formatted input function?</h3></a><p>
1693 <b>Section:</b>&nbsp;27.6.1.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;3 Aug 1998</p>
1694 <p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
1695 formatted input functions. Some of the functions defined in section
1696 27.6.1.2 explicitly say that those requirements apply ("Behaves
1697 like a formatted input member (as described in 27.6.1.2.1)"), but
1698 others don't. The question: is 27.6.1.2.1 supposed to apply to
1699 everything in 27.6.1.2, or only to those member functions that
1700 explicitly say "behaves like a formatted input member"? Or
1701 to put it differently: are we to assume that everything that appears
1702 in a section called "Formatted input functions" really is a
1703 formatted input function? I assume that 27.6.1.2.1 is intended to
1704 apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
1705 is not intended to apply to extractors like </p>
1706
1707 <pre>    basic_istream&amp; operator&gt;&gt;(basic_istream&amp; (*pf)(basic_istream&amp;));</pre>
1708
1709 <p>and </p>
1710
1711 <pre>    basic_istream&amp; operator&gt;&gt;(basic_streammbuf*);</pre>
1712
1713 <p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
1714 output. </p>
1715
1716 <p>Comments from Judy Ward: It seems like the problem is that the
1717 basic_istream and basic_ostream operator &lt;&lt;()'s that are used
1718 for the manipulators and streambuf* are in the wrong section and
1719 should have their own separate section or be modified to make it clear
1720 that the "Common requirements" listed in section 27.6.1.2.1
1721 (for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
1722 apply to them. </p>
1723
1724 <p>Additional comments from Dietmar Kühl: It appears to be somewhat
1725 nonsensical to consider the functions defined in 27.6.1.2.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> paragraphs 1 to 5 to be "Formatted input
1726 function" but since these functions are defined in a section
1727 labeled "Formatted input functions" it is unclear to me
1728 whether these operators are considered formatted input functions which
1729 have to conform to the "common requirements" from 27.6.1.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>: If this is the case, all manipulators, not
1730 just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
1731 set (... but setting <tt>noskipws</tt> using the manipulator syntax
1732 would also skip whitespace :-)</p> <p>It is not clear which functions
1733 are to be considered unformatted input functions. As written, it seems
1734 that all functions in 27.6.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> are unformatted input
1735 functions. However, it does not really make much sense to construct a
1736 sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
1737 unclear what happens to the <tt>gcount()</tt> if
1738 eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
1739 <tt>sync()</tt> is called: These functions don't extract characters,
1740 some of them even "unextract" a character. Should this still
1741 be reflected in <tt>gcount()</tt>? Of course, it could be read as if
1742 after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
1743 (the last unformatted input function, <tt>gcount()</tt>, didn't
1744 extract any character) and after a call to <tt>putback()</tt>
1745 <tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
1746 function <tt>putback()</tt> did "extract" back into the
1747 stream). Correspondingly for <tt>unget()</tt>. Is this what is
1748 intended?  If so, this should be clarified. Otherwise, a corresponding
1749 clarification should be used.</p>
1750 <p><b>Proposed resolution:</b></p>
1751 <p>
1752 In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
1753 Change the beginning of the second sentence from "The conversion
1754 occurs" to "These extractors behave as formatted input functions (as
1755 described in 27.6.1.2.1).  After a sentry object is constructed,
1756 the conversion occurs"
1757 </p>
1758
1759 <p>
1760 In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
1761 Add an effects clause.  "Effects: None.  This extractor does
1762 not behave as a formatted input function (as described in
1763 27.6.1.2.1).
1764 </p>
1765
1766 <p>
1767 In 27.6.1.2.3, [lib.istream::extractors], paragraph 2.  Change the
1768 effects clause to "Effects: Calls pf(*this).  This extractor does not
1769 behave as a formatted input function (as described in 27.6.1.2.1).
1770 </p>
1771
1772 <p>
1773 In 27.6.1.2.3, [lib.istream::extractors], paragraph 4.  Change the
1774 effects clause to "Effects: Calls pf(*this).  This extractor does not
1775 behave as a formatted input function (as described in 27.6.1.2.1).
1776 </p>
1777
1778 <p>
1779 In 27.6.1.2.3, [lib.istream::extractors], paragraph 12.  Change the
1780 first two sentences from "If sb is null, calls setstate(failbit),
1781 which may throw ios_base::failure (27.4.4.3).  Extracts characters
1782 from *this..." to "Behaves as a formatted input function (as described
1783 in 27.6.1.2.1).  If sb is null, calls setstate(failbit), which may
1784 throw ios_base::failure (27.4.4.3).  After a sentry object is
1785 constructed, extracts characters from *this...".
1786 </p>
1787
1788 <p>
1789 In 27.6.1.3, [lib.istream.unformatted], before paragraph 2.  Add an
1790 effects clause.  "Effects: none. This member function does not behave
1791 as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
1792 </p>
1793
1794 <p>
1795 In 27.6.1.3, [lib.istream.unformatted], paragraph 3.  Change the
1796 beginning of the first sentence of the effects clause from "Extracts a
1797 character" to "Behaves as an unformatted input function (as described
1798 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
1799 character"
1800 </p>
1801
1802 <p>
1803 In 27.6.1.3, [lib.istream.unformatted], paragraph 5.  Change the
1804 beginning of the first sentence of the effects clause from "Extracts a
1805 character" to "Behaves as an unformatted input function (as described
1806 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
1807 character"
1808 </p>
1809
1810 <p>
1811 In 27.6.1.3, [lib.istream.unformatted], paragraph 5.  Change the
1812 beginning of the first sentence of the effects clause from "Extracts
1813 characters" to "Behaves as an unformatted input function (as described
1814 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
1815 characters"
1816 </p>
1817
1818 <p>
1819 [No change needed in paragraph 10, because it refers to paragraph 7.]
1820 </p>
1821
1822 <p>
1823 In 27.6.1.3, [lib.istream.unformatted], paragraph 12.  Change the
1824 beginning of the first sentence of the effects clause from "Extracts
1825 characters" to "Behaves as an unformatted input function (as described
1826 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
1827 characters"
1828 </p>
1829
1830 <p>
1831 [No change needed in paragraph 15.]
1832 </p>
1833
1834 <p>
1835 In 27.6.1.3, [lib.istream.unformatted], paragraph 17.  Change the
1836 beginning of the first sentence of the effects clause from "Extracts
1837 characters" to "Behaves as an unformatted input function (as described
1838 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
1839 characters"
1840 </p>
1841
1842 <p>
1843 [No change needed in paragraph 23.]
1844 </p>
1845
1846 <p>
1847 In 27.6.1.3, [lib.istream.unformatted], paragraph 24.  Change the
1848 beginning of the first sentence of the effects clause from "Extracts
1849 characters" to "Behaves as an unformatted input function (as described
1850 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
1851 characters"
1852 </p>
1853
1854 <p>
1855 In 27.6.1.3, [lib.istream.unformatted], before paragraph 27.  Add an
1856 Effects clause: "Effects: Behaves as an unformatted input function (as
1857 described in 27.6.1.3, paragraph 1).  After constructing a sentry
1858 object, reads but does not extract the current input character."
1859 </p>
1860
1861 <p>
1862 In 27.6.1.3, [lib.istream.unformatted], paragraph 28.  Change the
1863 first sentence of the Effects clause from "If !good() calls" to
1864 Behaves as an unformatted input function (as described in 27.6.1.3,
1865 paragraph 1).  After constructing a sentry object, if !good() calls"
1866 </p>
1867
1868 <p>
1869 In 27.6.1.3, [lib.istream.unformatted], paragraph 30.  Change the
1870 first sentence of the Effects clause from "If !good() calls" to
1871 "Behaves as an unformatted input function (as described in 27.6.1.3,
1872 paragraph 1).  After constructing a sentry object, if !good() calls"
1873 </p>
1874
1875 <p>
1876 In 27.6.1.3, [lib.istream.unformatted], paragraph 32.  Change the
1877 first sentence of the Effects clause from "If !good() calls..." to
1878 "Behaves as an unformatted input function (as described in 27.6.1.3,
1879 paragraph 1).  After constructing a sentry object, if !good()
1880 calls..."  Add a new sentence to the end of the Effects clause:
1881 "[Note: this function extracts no characters, so the value returned
1882 by the next call to gcount() is 0.]"
1883 </p>
1884
1885 <p>
1886 In 27.6.1.3, [lib.istream.unformatted], paragraph 34.  Change the
1887 first sentence of the Effects clause from "If !good() calls" to
1888 "Behaves as an unformatted input function (as described in 27.6.1.3,
1889 paragraph 1).  After constructing a sentry object, if !good() calls".
1890 Add a new sentence to the end of the Effects clause: "[Note: this
1891 function extracts no characters, so the value returned by the next
1892 call to gcount() is 0.]"
1893 </p>
1894
1895 <p>
1896 In 27.6.1.3, [lib.istream.unformatted], paragraph 36.  Change the
1897 first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
1898 as an unformatted input function (as described in 27.6.1.3, paragraph
1899 1), except that it does not count the number of characters extracted
1900 and does not affect the value returned by subsequent calls to
1901 gcount().  After constructing a sentry object, if rdbuf() is"
1902 </p>
1903
1904 <p>
1905 In 27.6.1.3, [lib.istream.unformatted], before paragraph 37.  Add an
1906 Effects clause: "Effects: Behaves as an unformatted input function (as
1907 described in 27.6.1.3, paragraph 1), except that it does not count the
1908 number of characters extracted and does not affect the value returned
1909 by subsequent calls to gcount()."  Change the first sentence of
1910 paragraph 37 from "if fail()" to "after constructing a sentry object,
1911 if fail()".
1912 </p>
1913
1914 <p>
1915 In 27.6.1.3, [lib.istream.unformatted], paragraph 38.  Change the
1916 first sentence of the Effects clause from "If fail()" to "Behaves
1917 as an unformatted input function (as described in 27.6.1.3, paragraph
1918 1), except that it does not count the number of characters extracted
1919 and does not affect the value returned by subsequent calls to
1920 gcount().  After constructing a sentry object, if fail()
1921 </p>
1922
1923 <p>
1924 In 27.6.1.3, [lib.istream.unformatted], paragraph 40.  Change the
1925 first sentence of the Effects clause from "If fail()" to "Behaves
1926 as an unformatted input function (as described in 27.6.1.3, paragraph
1927 1), except that it does not count the number of characters extracted
1928 and does not affect the value returned by subsequent calls to
1929 gcount().  After constructing a sentry object, if fail()
1930 </p>
1931
1932 <p>
1933 In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1.  Change
1934 the beginning of the third sentence from "The formatting conversion"
1935 to "These extractors behave as formatted output functions (as
1936 described in 27.6.2.5.1).  After the sentry object is constructed, the
1937 conversion occurs".
1938 </p>
1939
1940 <p>
1941 In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1.  Add an
1942 effects clause: "Effects: None. Does not behave as a formatted output
1943 function (as described in 27.6.2.5.1).".
1944 </p>
1945
1946 <p>
1947 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2.  Change the
1948 effects clause to "Effects: calls pf(*this).  This extractor does not
1949 behave as a formatted output function (as described in 27.6.2.5.1).".
1950 </p>
1951
1952 <p>
1953 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4.  Change the
1954 effects clause to "Effects: calls pf(*this).  This extractor does not
1955 behave as a formatted output function (as described in 27.6.2.5.1).".
1956 </p>
1957
1958 <p>
1959 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6.  Change the first
1960 sentence from "If sb" to "Behaves as a formatted output function (as
1961 described in 27.6.2.5.1).  After the sentry object is constructed, if
1962 sb".
1963 </p>
1964
1965 <p>
1966 In 27.6.2.6 [lib.ostream.unformatted], paragraph 2.  Change the first
1967 sentence from "Inserts the character" to "Behaves as an unformatted
1968 output function (as described in 27.6.2.6, paragraph 1).  After
1969 constructing a sentry object, inserts the character".
1970 </p>
1971
1972 <p>
1973 In 27.6.2.6 [lib.ostream.unformatted], paragraph 5.  Change the first
1974 sentence from "Obtains characters" to "Behaves as an unformatted
1975 output function (as described in 27.6.2.6, paragraph 1).  After
1976 constructing a sentry object, obtains characters".
1977 </p>
1978
1979 <p>
1980 In 27.6.2.6 [lib.ostream.unformatted], paragraph 7.  Add a new
1981 sentence at the end of the paragraph: "Does not behave as an
1982 unformatted output function (as described in 27.6.2.6, paragraph 1)."
1983 </p>
1984 <p><b>Rationale:</b></p>
1985 <p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
1986 by Judy Ward and Matt Austern.  This proposed resolution is section
1987 VI of that paper.</p>
1988 <hr>
1989 <a name="61"><h3>61.&nbsp;Ambiguity in iostreams exception policy</h3></a><p>
1990 <b>Section:</b>&nbsp;27.6.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1991 <p>The introduction to the section on unformatted input (27.6.1.3)
1992 says that every unformatted input function catches all exceptions that
1993 were thrown during input, sets badbit, and then conditionally rethrows
1994 the exception. That seems clear enough. Several of the specific
1995 functions, however, such as get() and read(), are documented in some
1996 circumstances as setting eofbit and/or failbit. (The standard notes,
1997 correctly, that setting eofbit or failbit can sometimes result in an
1998 exception being thrown.) The question: if one of these functions
1999 throws an exception triggered by setting failbit, is this an exception
2000 "thrown during input" and hence covered by 27.6.1.3, or does
2001 27.6.1.3 only refer to a limited class of exceptions? Just to make
2002 this concrete, suppose you have the following snippet. </p>
2003
2004 <pre>
2005   char buffer[N];
2006   istream is;
2007   ...
2008   is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
2009   is.read(buffer, N);</pre>
2010
2011 <p>Now suppose we reach EOF before we've read N characters. What
2012 iostate bits can we expect to be set, and what exception (if any) will
2013 be thrown? </p>
2014 <p><b>Proposed resolution:</b></p>
2015 <p>
2016 In 27.6.1.3, paragraph 1, after the sentence that begins
2017 "If an exception is thrown...", add the following
2018 parenthetical comment: "(Exceptions thrown from
2019 <tt>basic_ios&lt;&gt;::clear()</tt> are not caught or rethrown.)"
2020 </p>
2021 <p><b>Rationale:</b></p>
2022 <p>The LWG looked to two alternative wordings, and choose the proposed
2023 resolution as better standardese.</p>
2024 <hr>
2025 <a name="62"></a><h3><a name="62">62.&nbsp;<tt>Sync</tt>'s return value</a></h3><p>
2026 <b>Section:</b>&nbsp;27.6.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
2027 <p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
2028 "calls rdbuf()-&gt;pubsync() and, if that function returns -1
2029 ... returns traits::eof()." </p>
2030
2031 <p>That looks suspicious, because traits::eof() is of type
2032 traits::int_type while the return type of sync() is int. </p>
2033 <p><b>Proposed resolution:</b></p>
2034 <p>In 27.6.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, paragraph 36, change "returns
2035 <tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
2036 </p>
2037 <hr>
2038 <a name="63"><h3>63.&nbsp;Exception-handling policy for unformatted output</h3></a><p>
2039 <b>Section:</b>&nbsp;27.6.2.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;11 Aug 1998</p>
2040 <p>Clause 27 details an exception-handling policy for formatted input,
2041 unformatted input, and formatted output. It says nothing for
2042 unformatted output (27.6.2.6). 27.6.2.6 should either include the same
2043 kind of exception-handling policy as in the other three places, or
2044 else it should have a footnote saying that the omission is
2045 deliberate. </p>
2046 <p><b>Proposed resolution:</b></p>
2047 <p>
2048 In 27.6.2.6, paragraph 1, replace the last sentence ("In any
2049 case, the unformatted output function ends by destroying the sentry
2050 object, then returning the value specified for the formatted output
2051 function.") with the following text:
2052 </p>
2053 <blockquote>
2054 If an exception is thrown during output, then <tt>ios::badbit</tt> is
2055 turned on [Footnote: without causing an <tt>ios::failure</tt> to be
2056 thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &amp;
2057 badbit) != 0</tt> then the exception is rethrown.  In any case, the
2058 unformatted output function ends by destroying the sentry object,
2059 then, if no exception was thrown, returning the value specified for
2060 the formatted output function.
2061 </blockquote>
2062 <p><b>Rationale:</b></p>
2063 <p>
2064 This exception-handling policy is consistent with that of formatted
2065 input, unformatted input, and formatted output.
2066 </p>
2067 <hr>
2068 <a name="64"><h3>64.&nbsp;Exception handling in <tt>basic_istream::operator&gt;&gt;(basic_streambuf*)</tt>
2069 </h3></a><p>
2070 <b>Section:</b>&nbsp;27.6.1.2.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;11 Aug 1998 </p>
2071 <p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
2072 different ways, depending on whether the second sentence is read as an
2073 elaboration of the first. </p>
2074 <p><b>Proposed resolution:</b></p>
2075 <p>Replace 27.6.1.2.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, paragraph 13, which begins
2076 "If the function inserts no characters ..." with:</p>
2077
2078 <blockquote>
2079   <p>If the function inserts no characters, it calls
2080   <tt>setstate(failbit)</tt>, which may throw
2081   <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
2082   because it caught an exception thrown while extracting characters
2083   from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
2084   (27.4.4.3), then the caught exception is rethrown. </p>
2085 </blockquote>
2086 <hr>
2087 <a name="66"><h3>66.&nbsp;Strstreambuf::setbuf</h3></a><p>
2088 <b>Section:</b>&nbsp;D.7.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;18 Aug 1998</p>
2089 <p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
2090 "Performs an operation that is defined separately for each class
2091 derived from strstreambuf". This is obviously an incorrect
2092 cut-and-paste from basic_streambuf. There are no classes derived from
2093 strstreambuf. </p>
2094 <p><b>Proposed resolution:</b></p>
2095 <p>D.7.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 19, replace the setbuf effects
2096 clause which currently says "Performs an operation that is
2097 defined separately for each class derived from strstreambuf"
2098 with:</p>
2099
2100 <blockquote>
2101   <p>
2102 <b>Effects</b>: implementation defined, except that
2103   <tt>setbuf(0,0)</tt> has no effect.</p>
2104 </blockquote>
2105 <hr>
2106 <a name="68"><h3>68.&nbsp;Extractors for char* should store null at end</h3></a><p>
2107 <b>Section:</b>&nbsp;27.6.1.2.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;14 Jul 1998</p>
2108 <p>Extractors for char* (27.6.1.2.3) do not store a null character
2109 after the extracted character sequence whereas the unformatted
2110 functions like get() do. Why is this?</p>
2111
2112 <p>Comment from Jerry Schwarz: There is apparently an editing
2113 glitch. You'll notice that the last item of the list of what stops
2114 extraction doesn't make any sense. It was supposed to be the line that
2115 said a null is stored.</p>
2116 <p><b>Proposed resolution:</b></p>
2117 <p>27.6.1.2.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, paragraph 7, change the last list
2118 item from:</p>
2119
2120 <blockquote>
2121   A null byte (<tt>charT()</tt>) in the next position, which may be
2122   the first position if no characters were extracted.
2123 </blockquote>
2124
2125 <p>to become a new paragraph which reads:</p>
2126
2127 <blockquote>
2128   Operator&gt;&gt; then stores a null byte (<tt>charT()</tt>) in the
2129   next position, which may be the first position if no characters were
2130   extracted.
2131 </blockquote>
2132 <hr>
2133 <a name="69"><h3>69.&nbsp;Must elements of a vector be contiguous?</h3></a><p>
2134 <b>Section:</b>&nbsp;23.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;29 Jul 1998</p>
2135 <p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
2136
2137 <p>(Please note that this is entirely separate from the question of
2138 whether a vector iterator is required to be a pointer; the answer to
2139 that question is clearly "no," as it would rule out
2140 debugging implementations)</p>
2141 <p><b>Proposed resolution:</b></p>
2142 <p>Add the following text to the end of 23.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>,
2143 paragraph 1. </p>
2144
2145 <blockquote>
2146   <p>The elements of a vector are stored contiguously, meaning that if
2147   v is a <tt>vector&lt;T, Allocator&gt;</tt> where T is some type
2148   other than <tt>bool</tt>, then it obeys the identity <tt>&amp;v[n]
2149   == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt; v.size()</tt>.</p>
2150 </blockquote>
2151 <p><b>Rationale:</b></p>
2152 <p>The LWG feels that as a practical matter the answer is clearly
2153 "yes".  There was considerable discussion as to the best way
2154 to express the concept of "contiguous", which is not
2155 directly defined in the standard.  Discussion included:</p>
2156
2157 <ul>
2158   <li>An operational definition similar to the above proposed resolution is
2159     already used for valarray (26.3.2.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a>).</li>
2160   <li>There is no need to explicitly consider a user-defined operator&amp;
2161     because elements must be copyconstructible (23.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> para 3)
2162     and copyconstructible (20.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>) specifies
2163     requirements for operator&amp;.</li>
2164   <li>There is no issue of one-past-the-end because of language rules.</li>
2165 </ul>
2166 <hr>
2167 <a name="70"><h3>70.&nbsp;Uncaught_exception() missing throw() specification</h3></a><p>
2168 <b>Section:</b>&nbsp;18.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.support.exception"> [lib.support.exception]</a>, 18.6.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.uncaught"> [lib.uncaught]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;Unknown</p>
2169 <p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
2170
2171 <p>uncaught_exception() doesn't have a throw specification.</p>
2172
2173 <p>It is intentional ? Does it means that one should be prepared to
2174 handle exceptions thrown from uncaught_exception() ?</p>
2175
2176 <p>uncaught_exception() is called in exception handling contexts where
2177 exception safety is very important.</p>
2178 <p><b>Proposed resolution:</b></p>
2179 <p>In 15.5.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/except.html#except.uncaught"> [except.uncaught]</a>, paragraph 1, 18.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.support.exception"> [lib.support.exception]</a>, and 18.6.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.uncaught"> [lib.uncaught]</a>, add "throw()" to uncaught_exception().</p>
2180 <hr>
2181 <a name="71"><h3>71.&nbsp;Do_get_monthname synopsis missing argument</h3></a><p>
2182 <b>Section:</b>&nbsp;22.2.5.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;13 Aug 1998</p>
2183 <p>The locale facet member <tt>time_get&lt;&gt;::do_get_monthname</tt>
2184 is described in 22.2.5.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.virtuals]</a> with five arguments,
2185 consistent with do_get_weekday and with its specified use by member
2186 get_monthname. However, in the synopsis, it is specified instead with
2187 four arguments. The missing argument is the "end" iterator
2188 value.</p>
2189 <p><b>Proposed resolution:</b></p>
2190 <p>In 22.2.5.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a>, add an "end" argument to
2191 the declaration of member do_monthname as follows:</p>
2192
2193 <pre>  virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&amp;,
2194                                      ios_base::iostate&amp; err, tm* t) const;</pre>
2195 <hr>
2196 <a name="74"><h3>74.&nbsp;Garbled text for <tt>codecvt::do_max_length</tt>
2197 </h3></a><p>
2198 <b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;8 Sep 1998</p>
2199 <p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
2200 clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
2201 parentheses and a spurious <b>n</b>.</p>
2202 <p><b>Proposed resolution:</b></p>
2203 <p>Replace 22.2.1.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 11 with the
2204 following:</p>
2205
2206 <blockquote>
2207   <b>Returns</b>: The maximum value that
2208   <tt>do_length(state, from, from_end, 1)</tt> can return for any
2209   valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
2210   <tt>state</tt>. The specialization <tt>codecvt&lt;char, char,
2211   mbstate_t&gt;::do_max_length()</tt> returns 1.
2212 </blockquote>
2213 <hr>
2214 <a name="75"><h3>75.&nbsp;Contradiction in <tt>codecvt::length</tt>'s argument types</h3></a><p>
2215 <b>Section:</b>&nbsp;22.2.1.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp; Matt
2216 Austern&nbsp; <b>Date:</b>&nbsp; 18 Sep 1998</p>
2217 <p>The class synopses for classes <tt>codecvt&lt;&gt;</tt> (22.2.1.5)
2218 and <tt>codecvt_byname&lt;&gt;</tt> (22.2.1.6) say that the first
2219 parameter of the member functions <tt>length</tt> and
2220 <tt>do_length</tt> is of type <tt>const stateT&amp;</tt>. The member
2221 function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
2222 paragraph 9) say that the type is <tt>stateT&amp;</tt>.  Either the
2223 synopsis or the summary must be changed. </p>
2224
2225 <p>If (as I believe) the member function descriptions are correct,
2226 then we must also add text saying how <tt>do_length</tt> changes its
2227 <tt>stateT</tt> argument. </p>
2228 <p><b>Proposed resolution:</b></p>
2229 <p>In 22.2.1.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>, and also in 22.2.1.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>,
2230 change the <tt>stateT</tt> argument type on both member
2231 <tt>length()</tt> and member <tt>do_length()</tt> from </p>
2232
2233 <blockquote>
2234   <p><tt>const stateT&amp;</tt></p>
2235 </blockquote>
2236
2237 <p>to</p>
2238
2239 <blockquote>
2240   <p><tt>stateT&amp;</tt></p>
2241 </blockquote>
2242
2243 <p>In 22.2.1.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, add to the definition for member
2244 <tt>do_length</tt> a paragraph:</p>
2245
2246 <blockquote>
2247   <p>Effects: The effect on the <tt>state</tt> argument is ``as if''
2248   it called <tt>do_in(state, from, from_end, from, to, to+max,
2249   to)</tt> for <tt>to</tt> pointing to a buffer of at least
2250   <tt>max</tt> elements.</p>
2251 </blockquote>
2252 <hr>
2253 <a name="76"><h3>76.&nbsp;Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3></a><p>
2254 <b>Section:</b>&nbsp;22.2.1.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;25 Sep 1998</p>
2255 <p>This issue concerns the requirements on classes derived from
2256 <tt>codecvt</tt>, including user-defined classes. What are the
2257 restrictions on the conversion from external characters
2258 (e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
2259 Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
2260 the I/O library make? </p>
2261
2262 <p>The question is whether it's possible to convert from internal
2263 characters to external characters one internal character at a time,
2264 and whether, given a valid sequence of external characters, it's
2265 possible to pick off internal characters one at a time. Or, to put it
2266 differently: given a sequence of external characters and the
2267 corresponding sequence of internal characters, does a position in the
2268 internal sequence correspond to some position in the external
2269 sequence? </p>
2270
2271 <p>To make this concrete, suppose that <tt>[first, last)</tt> is a
2272 sequence of <i>M</i> external characters and that <tt>[ifirst,
2273 ilast)</tt> is the corresponding sequence of <i>N</i> internal
2274 characters, where <i>N &gt; 1</i>. That is, <tt>my_encoding.in()</tt>,
2275 applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
2276 ilast)</tt>. Now the question: does there necessarily exist a
2277 subsequence of external characters, <tt>[first, last_1)</tt>, such
2278 that the corresponding sequence of internal characters is the single
2279 character <tt>*ifirst</tt>?
2280 </p>
2281
2282 <p>(What a "no" answer would mean is that
2283 <tt>my_encoding</tt> translates sequences only as blocks. There's a
2284 sequence of <i>M</i> external characters that maps to a sequence of
2285 <i>N</i> internal characters, but that external sequence has no
2286 subsequence that maps to <i>N-1</i> internal characters.) </p>
2287
2288 <p>Some of the wording in the standard, such as the description of
2289 <tt>codecvt::do_max_length</tt> (22.2.1.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>,
2290 paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.8.1.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 3) suggests that it must always be
2291 possible to pick off internal characters one at a time from a sequence
2292 of external characters. However, this is never explicitly stated one
2293 way or the other. </p>
2294
2295 <p>This issue seems (and is) quite technical, but it is important if
2296 we expect users to provide their own encoding facets. This is an area
2297 where the standard library calls user-supplied code, so a well-defined
2298 set of requirements for the user-supplied code is crucial. Users must
2299 be aware of the assumptions that the library makes. This issue affects
2300 positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
2301 and several of <tt>codecvt</tt>'s member functions. </p>
2302 <p><b>Proposed resolution:</b></p>
2303 <p>Add the following text as a new paragraph, following 22.2.1.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 2:</p>
2304
2305 <blockquote>
2306 <p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
2307 (27.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>) must have the property that if</p>
2308 <pre>    do_out(state, from, from_end, from_next, to, to_lim, to_next)
2309 </pre>
2310 would return <tt>ok</tt>, where <tt>from != from_end</tt>, then
2311 <pre>    do_out(state, from, from + 1, from_next, to, to_end, to_next)
2312 </pre>
2313 must also return <tt>ok</tt>, and that if
2314 <pre>    do_in(state, from, from_end, from_next, to, to_lim, to_next)
2315 </pre>
2316 would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then
2317 <pre>    do_in(state, from, from_end, from_next, to, to + 1, to_next)
2318 </pre>
2319 <p>must also return <tt>ok</tt>.  [<i>Footnote:</i> Informally, this
2320 means that <tt>basic_filebuf</tt> assumes that the mapping from
2321 internal to external characters is 1 to N: a <tt>codecvt</tt> that is
2322 used by <tt>basic_filebuf</tt> must be able to translate characters
2323 one internal character at a time.  <i>--End Footnote</i>]</p>
2324 </blockquote>
2325
2326 <p><i>[Redmond: Minor change in proposed resolution.  Original
2327 proposed resolution talked about "success", with a parenthetical
2328 comment that success meant returning <tt>ok</tt>.  New wording
2329 removes all talk about "success", and just talks about the
2330 return value.]</i></p>
2331
2332 <p><b>Rationale:</b></p>
2333
2334   <p>The proposed resoluion says that conversions can be performed one
2335   internal character at a time.  This rules out some encodings that
2336   would otherwise be legal.  The alternative answer would mean there
2337   would be some internal positions that do not correspond to any
2338   external file position.</p>
2339   <p>
2340   An example of an encoding that this rules out is one where the
2341   <tt>internT</tt> and <tt>externT</tt> are of the same type, and
2342   where the internal sequence <tt>c1 c2</tt> corresponds to the
2343   external sequence <tt>c2 c1</tt>.
2344   </p>
2345   <p>It was generally agreed that <tt>basic_filebuf</tt> relies
2346   on this property: it was designed under the assumption that
2347   the external-to-internal mapping is N-to-1, and it is not clear
2348   that <tt>basic_filebuf</tt> is implementable without that
2349   restriction.
2350   </p>
2351   <p>
2352   The proposed resolution is expressed as a restriction on
2353   <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
2354   than a blanket restriction on all <tt>codecvt</tt> facets,
2355   because <tt>basic_filebuf</tt> is the only other part of the
2356   library that uses <tt>codecvt</tt>.  If a user wants to define
2357   a <tt>codecvt</tt> facet that implements a more general N-to-M
2358   mapping, there is no reason to prohibit it, so long as the user
2359   does not expect <tt>basic_filebuf</tt> to be able to use it.
2360   </p>
2361 <hr>
2362 <a name="78"><h3>78.&nbsp;Typo: event_call_back</h3></a><p>
2363 <b>Section:</b>&nbsp;27.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2364 <p>typo: event_call_back should be event_callback &nbsp; </p>
2365 <p><b>Proposed resolution:</b></p>
2366 <p>In the 27.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> synopsis change
2367 "event_call_back" to "event_callback". </p>
2368 <hr>
2369 <a name="79"><h3>79.&nbsp;Inconsistent declaration of polar()</h3></a><p>
2370 <b>Section:</b>&nbsp;26.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2371 <p>In 26.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> polar is declared as follows:</p>
2372 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;); </pre>
2373
2374 <p>In 26.2.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> it is declared as follows:</p>
2375 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
2376
2377 <p>Thus whether the second parameter is optional is not clear. </p>
2378 <p><b>Proposed resolution:</b></p>
2379 <p>In 26.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> change:</p>
2380 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;);</pre>
2381
2382 <p>to:</p>
2383 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
2384 <hr>
2385 <a name="80"><h3>80.&nbsp;Global Operators of complex declared twice</h3></a><p>
2386 <b>Section:</b>&nbsp;26.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2387 <p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
2388 class complex. This redundancy should be removed.</p>
2389 <p><b>Proposed resolution:</b></p>
2390 <p>Reduce redundancy according to the general style of the standard. </p>
2391 <hr>
2392 <a name="83"><h3>83.&nbsp;String::npos vs. string::max_size()</h3></a><p>
2393 <b>Section:</b>&nbsp;21.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2394 <p>Many string member functions throw if size is getting or exceeding
2395 npos. However, I wonder why they don't throw if size is getting or
2396 exceeding max_size() instead of npos.  May be npos is known at compile
2397 time, while max_size() is known at runtime. However, what happens if
2398 size exceeds max_size() but not npos, then? It seems the standard
2399 lacks some clarifications here.</p>
2400 <p><b>Proposed resolution:</b></p>
2401 <p>After 21.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> paragraph 4 ("The functions
2402 described in this clause...") add a new paragraph:</p>
2403
2404 <blockquote>
2405   <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
2406   <tt> max_size()</tt> then
2407   the operation throws <tt>length_error</tt>.</p>
2408 </blockquote>
2409 <p><b>Rationale:</b></p>
2410 <p>The LWG believes length_error is the correct exception to throw.</p>
2411 <hr>
2412 <a name="86"><h3>86.&nbsp;String constructors don't describe exceptions</h3></a><p>
2413 <b>Section:</b>&nbsp;21.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2414 <p>The constructor from a range:</p>
2415
2416 <pre>template&lt;class InputIterator&gt;
2417          basic_string(InputIterator begin, InputIterator end,
2418                       const Allocator&amp; a = Allocator());</pre>
2419
2420 <p>lacks a throws clause. However, I would expect that it throws
2421 according to the other constructors if the numbers of characters in
2422 the range equals npos (or exceeds max_size(), see above). </p>
2423 <p><b>Proposed resolution:</b></p>
2424 <p>In 21.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, Strike throws paragraphs for
2425 constructors which say "Throws: length_error if n ==
2426 npos."</p>
2427 <p><b>Rationale:</b></p>
2428 <p>Throws clauses for length_error if n == npos are no longer needed
2429 because they are subsumed by the general wording added by the
2430 resolution for issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
2431 <hr>
2432 <a name="90"><h3>90.&nbsp;Incorrect description of operator &gt;&gt; for strings</h3></a><p>
2433 <b>Section:</b>&nbsp;21.3.7.9 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2434 <p>The effect of operator &gt;&gt; for strings contain the following item:</p>
2435
2436 <p>&nbsp;&nbsp;&nbsp; <tt>isspace(c,getloc())</tt> is true for the next available input
2437 character c.</p>
2438
2439 <p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
2440 <p><b>Proposed resolution:</b></p>
2441 <p>In 21.3.7.9 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 1 Effects clause replace:</p>
2442
2443 <blockquote>
2444   <p>
2445 <tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
2446 </blockquote>
2447
2448 <p>with:</p>
2449
2450 <blockquote>
2451   <p>
2452 <tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
2453 </blockquote>
2454 <hr>
2455 <a name="91"><h3>91.&nbsp;Description of operator&gt;&gt; and getline() for string&lt;&gt; might cause endless loop</h3></a><p>
2456 <b>Section:</b>&nbsp;21.3.7.9 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2457 <p>Operator &gt;&gt; and getline() for strings read until eof()
2458 in the input stream is true. However, this might never happen, if the
2459 stream can't read anymore without reaching EOF. So shouldn't it be
2460 changed into that it reads until !good() ? </p>
2461 <p><b>Proposed resolution:</b></p>
2462 <p>In 21.3.7.9 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>, paragraph 1, replace:</p>
2463 <blockquote>
2464 Effects: Begins by constructing a sentry object k as if k were
2465 constructed by typename basic_istream&lt;charT,traits&gt;::sentry k( is). If
2466 bool( k) is true, it calls str.erase() and then extracts characters
2467 from is and appends them to str as if by calling str.append(1, c). If
2468 is.width() is greater than zero, the maximum number n of characters
2469 appended is is.width(); otherwise n is str.max_size(). Characters are
2470 extracted and appended until any of the following occurs:
2471 </blockquote>
2472 <p>with:</p>
2473 <blockquote>
2474 Effects: Behaves as a formatted input function (27.6.1.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>).  After constructing a sentry object, if the
2475 sentry converts to true, calls str.erase() and then extracts
2476 characters from is and appends them to str as if by calling
2477 str.append(1,c). If is.width() is greater than zero, the maximum
2478 number n of characters appended is is.width(); otherwise n is
2479 str.max_size(). Characters are extracted and appended until any of the
2480 following occurs:
2481 </blockquote>
2482
2483 <p>In 21.3.7.9 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>, paragraph 6, replace</p>
2484 <blockquote>
2485 Effects: Begins by constructing a sentry object k as if by typename
2486 basic_istream&lt;charT,traits&gt;::sentry k( is, true). If bool( k) is true,
2487 it calls str.erase() and then extracts characters from is and appends
2488 them to str as if by calling str.append(1, c) until any of the
2489 following occurs:
2490 </blockquote>
2491 <p>with:</p>
2492 <blockquote>
2493 Effects: Behaves as an unformatted input function (27.6.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), except that it does not affect the value returned
2494 by subsequent calls to basic_istream&lt;&gt;::gcount().  After
2495 constructing a sentry object, if the sentry converts to true, calls
2496 str.erase() and then extracts characters from is and appends them to
2497 str as if by calling str.append(1,c) until any of the following
2498 occurs:
2499 </blockquote>
2500
2501 <p><i>[Redmond: Made changes in proposed resolution.  <tt>operator&gt;&gt;</tt>
2502 should be a formatted input function, not an unformatted input function.
2503 <tt>getline</tt> should not be required to set <tt>gcount</tt>, since
2504 there is no mechanism for <tt>gcount</tt> to be set except by one of
2505 <tt>basic_istream</tt>'s member functions.]</i></p>
2506
2507 <p><i>[Curaçao: Nico agrees with proposed resolution.]</i></p>
2508
2509 <p><b>Rationale:</b></p>
2510 <p>The real issue here is whether or not these string input functions
2511 get their characters from a streambuf, rather than by calling an
2512 istream's member functions, a streambuf signals failure either by
2513 returning eof or by throwing an exception; there are no other
2514 possibilities.  The proposed resolution makes it clear that these two
2515 functions do get characters from a streambuf.</p>
2516 <hr>
2517 <a name="103"></a><h3><a name="103">103.&nbsp;set::iterator is required to be modifiable, but this allows modification of keys</a></h3><p>
2518 <b>Section:</b>&nbsp;23.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
2519 <p>Set::iterator is described as implementation-defined with a
2520 reference to the container requirement; the container requirement says
2521 that const_iterator is an iterator pointing to const T and iterator an
2522 iterator pointing to T.</p>
2523
2524 <p>23.1.2 paragraph 2 implies that the keys should not be modified to
2525 break the ordering of elements. But that is not clearly
2526 specified. Especially considering that the current standard requires
2527 that iterator for associative containers be different from
2528 const_iterator. Set, for example, has the following: </p>
2529
2530 <p><tt>typedef implementation defined iterator;<br>
2531 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // See _lib.container.requirements_</tt></p>
2532
2533 <p>23.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> actually requires that iterator type pointing
2534 to T (table 65). Disallowing user modification of keys by changing the
2535 standard to require an iterator for associative container to be the
2536 same as const_iterator would be overkill since that will unnecessarily
2537 significantly restrict the usage of associative container. A class to
2538 be used as elements of set, for example, can no longer be modified
2539 easily without either redesigning the class (using mutable on fields
2540 that have nothing to do with ordering), or using const_cast, which
2541 defeats requiring iterator to be const_iterator. The proposed solution
2542 goes in line with trusting user knows what he is doing. </p>
2543
2544 <p>
2545 <b>Other Options Evaluated:</b> </p>
2546
2547 <p>Option A.&nbsp;&nbsp; In 23.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, paragraph 2, after
2548 first sentence, and before "In addition,...", add one line:
2549 </p>
2550
2551 <blockquote>
2552   <p>Modification of keys shall not change their strict weak ordering. </p>
2553 </blockquote>
2554
2555 <p>Option B.&nbsp;Add three new sentences to 23.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>:</p>
2556
2557 <blockquote>
2558   <p>At the end of paragraph 5: "Keys in an associative container
2559   are immutable." At the end of paragraph 6: "For
2560   associative containers where the value type is the same as the key
2561   type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
2562   constant iterators. It is unspecified whether or not
2563   <tt>iterator</tt> and <tt>const_iterator</tt> are the same
2564   type."</p>
2565 </blockquote>
2566
2567 <p>Option C.&nbsp;To 23.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, paragraph 3, which
2568 currently reads:</p>
2569
2570 <blockquote>
2571   <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
2572   comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
2573   container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
2574   == false &amp;&amp; comp(k2, k1) == false.</p>
2575 </blockquote>
2576
2577 <p>&nbsp; add the following:</p>
2578
2579 <blockquote>
2580   <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
2581   value whenever it is evaluated. [Note: If k2 is removed from the container and later
2582   reinserted, comp(k1, k2) must still return a consistent value but this value may be
2583   different than it was the first time k1 and k2 were in the same container. This is
2584   intended to allow usage like a string key that contains a filename, where comp compares
2585   file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
2586   reinserted, comp(k1, k2) must again return a consistent value but this value may be
2587   different than it was the previous time k2 was in the container.]</p>
2588 </blockquote>
2589 <p><b>Proposed resolution:</b></p>
2590 <p>Add the following to 23.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> at
2591 the indicated location:</p>
2592
2593 <blockquote>
2594   <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
2595   calling comp(k1, k2) shall always return the same
2596   value."</p>
2597   <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
2598   <p>At the end of paragraph 6: "For associative containers where the value type is the
2599   same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
2600   iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
2601   are the same type."</p>
2602 </blockquote>
2603 <p><b>Rationale:</b></p>
2604 <p>Several arguments were advanced for and against allowing set elements to be
2605 mutable as long as the ordering was not effected. The argument which swayed the
2606 LWG was one of safety; if elements were mutable, there would be no compile-time
2607 way to detect of a simple user oversight which caused ordering to be
2608 modified.  There was a report that this had actually happened in practice,
2609 and had been painful to diagnose.  If users need to modify elements,
2610 it is possible to use mutable members or const_cast.</p>
2611
2612 <p>Simply requiring that keys be immutable is not sufficient, because the comparison
2613 object may indirectly (via pointers) operate on values outside of the keys.</p>
2614
2615 <p>
2616 The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
2617 to be different types to allow for potential future work in which some
2618 member functions might be overloaded between the two types.  No such
2619 member functions exist now, and the LWG believes that user functionality
2620 will not be impaired by permitting the two types to be the same.  A
2621 function that operates on both iterator types can be defined for
2622 <tt>const_iterator</tt> alone, and can rely on the automatic
2623 conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
2624 </p>
2625
2626 <p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
2627 <hr>
2628 <a name="106"><h3>106.&nbsp;Numeric library private members are implementation defined</h3></a><p>
2629 <b>Section:</b>&nbsp;26.3.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
2630 <p>This is the only place in the whole standard where the implementation has to document
2631 something private.</p>
2632 <p><b>Proposed resolution:</b></p>
2633 <p>
2634 Remove the comment which says "// remainder implementation defined" from:
2635 </p>
2636
2637 <ul>
2638   <li>26.3.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>
2639 </li>
2640   <li>26.3.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a>
2641 </li>
2642   <li>26.3.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a>
2643 </li>
2644   <li>26.3.9 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
2645 </li>
2646 </ul>
2647 <hr>
2648 <a name="108"><h3>108.&nbsp;Lifetime of exception::what() return unspecified</h3></a><p>
2649 <b>Section:</b>&nbsp;18.6.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.exception"> [lib.exception]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
2650 <p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
2651 exception::what() is left unspecified. This issue has implications
2652 with exception safety of exception handling: some exceptions should
2653 not throw bad_alloc.</p>
2654 <p><b>Proposed resolution:</b></p>
2655 <p>Add to 18.6.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.exception"> [lib.exception]</a> paragraph 9 (exception::what notes
2656 clause) the sentence:</p>
2657
2658 <blockquote>
2659   <p>The return value remains valid until the exception object from which it is obtained is
2660   destroyed or a non-const member function of the exception object is called.</p>
2661 </blockquote>
2662 <p><b>Rationale:</b></p>
2663 <p>If an exception object has non-const members, they may be used
2664 to set internal state that should affect the contents of the string
2665 returned by <tt>what()</tt>.
2666 </p>
2667 <hr>
2668 <a name="109"></a><h3><a name="109">109.&nbsp;Missing binders for non-const sequence elements</a></h3><p>
2669 <b>Section:</b>&nbsp;20.3.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binders"> [lib.binders]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Bjarne Stroustrup&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
2670
2671 <p>There are no versions of binders that apply to non-const elements
2672 of a sequence. This makes examples like for_each() using bind2nd() on
2673 page 521 of "The C++ Programming Language (3rd)"
2674 non-conforming. Suitable versions of the binders need to be added.</p>
2675
2676 <p>Further discussion from Nico:</p>
2677
2678 <p>What is probably meant here is shown in the following example:</p>
2679
2680 <pre>class Elem {
2681   public:
2682     void print (int i) const { }
2683     void modify (int i) { }
2684 }; </pre>
2685 <pre>int main()
2686 {
2687     vector&lt;Elem&gt; coll(2);
2688     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::print),42));    // OK
2689     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::modify),42));   // ERROR
2690 }</pre>
2691
2692 <p>The error results from the fact that bind2nd() passes its first
2693 argument (the argument of the sequence) as constant reference. See the
2694 following typical implementation:</p>
2695
2696 <blockquote>
2697   <pre>template &lt;class Operation&gt;
2698 class binder2nd
2699   : public unary_function&lt;typename Operation::first_argument_type,
2700                           typename Operation::result_type&gt; {
2701 protected:
2702   Operation op;
2703   typename Operation::second_argument_type value;
2704 public:
2705   binder2nd(const Operation&amp; o,
2706             const typename Operation::second_argument_type&amp; v)
2707       : op(o), value(v) {} </pre>
2708   <pre> typename Operation::result_type
2709   operator()(const typename Operation::first_argument_type&amp; x) const {
2710     return op(x, value);
2711   }
2712 };</pre>
2713 </blockquote>
2714
2715 <p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
2716
2717 <blockquote>
2718   <pre>template &lt;class Operation&gt;
2719 class binder2nd
2720   : public unary_function&lt;typename Operation::first_argument_type,
2721                           typename Operation::result_type&gt; {
2722 protected:
2723   Operation op;
2724   typename Operation::second_argument_type value;
2725 public:
2726   binder2nd(const Operation&amp; o,
2727             const typename Operation::second_argument_type&amp; v)
2728       : op(o), value(v) {} </pre>
2729   <pre> typename Operation::result_type
2730   operator()(const typename Operation::first_argument_type&amp; x) const {
2731     return op(x, value);
2732   }
2733   typename Operation::result_type
2734   operator()(typename Operation::first_argument_type&amp; x) const {
2735     return op(x, value);
2736   }
2737 };</pre>
2738 </blockquote>
2739 <p><b>Proposed resolution:</b></p>
2740
2741 <p>
2742 <b>Howard believes there is a flaw</b> in this resolution.
2743 See c++std-lib-9127.  We may need to reopen this issue.</p>
2744
2745 <p>In 20.3.6.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binder.1st"> [lib.binder.1st]</a> in the declaration of binder1st after:</p>
2746 <blockquote>
2747   <p><tt>typename Operation::result_type<br>
2748   &nbsp;operator()(const typename Operation::second_argument_type&amp; x) const;</tt></p>
2749 </blockquote>
2750 <p>insert:</p>
2751 <blockquote>
2752   <p><tt>typename Operation::result_type<br>
2753   &nbsp;operator()(typename Operation::second_argument_type&amp; x) const;</tt></p>
2754 </blockquote>
2755 <p>In 20.3.6.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binder.2nd"> [lib.binder.2nd]</a> in the declaration of binder2nd after:</p>
2756 <blockquote>
2757   <p><tt>typename Operation::result_type<br>
2758   &nbsp;operator()(const typename Operation::first_argument_type&amp; x) const;</tt></p>
2759 </blockquote>
2760 <p>insert:</p>
2761 <blockquote>
2762   <p><tt>typename Operation::result_type<br>
2763   &nbsp;operator()(typename Operation::first_argument_type&amp; x) const;</tt></p>
2764 </blockquote>
2765
2766 <p><i>[Kona: The LWG discussed this at some length.It was agreed that
2767 this is a mistake in the design, but there was no consensus on whether
2768 it was a defect in the Standard.  Straw vote: NAD - 5.  Accept
2769 proposed resolution - 3.  Leave open - 6.]</i></p>
2770
2771 <p><i>[Copenhagen: It was generally agreed that this was a defect.
2772 Strap poll: NAD - 0.  Accept proposed resolution - 10.
2773 Leave open - 1.]</i></p>
2774
2775 <hr>
2776 <a name="110"><h3>110.&nbsp;istreambuf_iterator::equal not const</h3></a><p>
2777 <b>Section:</b>&nbsp;24.5.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, 24.5.3.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;15 Oct 1998</p>
2778 <p>Member istreambuf_iterator&lt;&gt;::equal is not declared
2779 "const", yet 24.5.3.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::op=="> [lib.istreambuf.iterator::op==]</a> says that operator==,
2780 which is const, calls it. This is contradictory. </p>
2781 <p><b>Proposed resolution:</b></p>
2782 <p>In 24.5.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a> and also in 24.5.3.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a>,
2783 replace:</p>
2784
2785 <blockquote>
2786   <pre>bool equal(istreambuf_iterator&amp; b);</pre>
2787 </blockquote>
2788
2789 <p>with:</p>
2790
2791 <blockquote>
2792   <pre>bool equal(const istreambuf_iterator&amp; b) const;</pre>
2793 </blockquote>
2794 <hr>
2795 <a name="112"><h3>112.&nbsp;Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3></a><p>
2796 <b>Section:</b>&nbsp;24.5.4.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Oct 1998</p>
2797 <p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
2798 constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
2799 reads "<i>s</i> is not null". However, <i>s</i> is a
2800 reference, and references can't be null. </p>
2801 <p><b>Proposed resolution:</b></p>
2802 <p>In 24.5.4.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a>:</p>
2803
2804 <p>Move the current paragraph 1, which reads "Requires: s is not
2805 null.", from the first constructor to the second constructor.</p>
2806
2807 <p>Insert a new paragraph 1 Requires clause for the first constructor
2808 reading:</p>
2809
2810 <blockquote>
2811   <p>
2812 <b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
2813 </blockquote>
2814 <hr>
2815 <a name="114"><h3>114.&nbsp;Placement forms example in error twice</h3></a><p>
2816 <b>Section:</b>&nbsp;18.4.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;28 Oct 1998</p>
2817 <p>Section 18.4.1.3 contains the following example: </p>
2818
2819 <pre>[Example: This can be useful for constructing an object at a known address:
2820         char place[sizeof(Something)];
2821         Something* p = new (place) Something();
2822  -end example]</pre>
2823
2824 <p>First code line: "place" need not have any special alignment, and the
2825 following constructor could fail due to misaligned data.</p>
2826
2827 <p>Second code line: Aren't the parens on Something() incorrect?&nbsp; [Dublin: the LWG
2828 believes the () are correct.]</p>
2829
2830 <p>Examples are not normative, but nevertheless should not show code that is invalid or
2831 likely to fail.</p>
2832 <p><b>Proposed resolution:</b></p>
2833 <p>Replace the <u> first line of code</u> in the example in
2834 18.4.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> with:
2835 </p>
2836
2837 <blockquote>
2838   <pre>void* place = operator new(sizeof(Something));</pre>
2839 </blockquote>
2840 <hr>
2841 <a name="115"><h3>115.&nbsp;Typo in strstream constructors</h3></a><p>
2842 <b>Section:</b>&nbsp;D.7.4.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.strstream.cons"> [depr.strstream.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;2 Nov 1998</p>
2843 <p>D.7.4.1 strstream constructors paragraph 2 says: </p>
2844
2845 <blockquote>
2846   <p>Effects: Constructs an object of class strstream, initializing the base class with
2847   iostream(&amp; sb) and initializing sb with one of the two constructors: </p>
2848   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
2849   elements. The constructor is strstreambuf(s, n, s). </p>
2850   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
2851   elements that contains an NTBS whose first element is designated by s. The constructor is
2852   strstreambuf(s, n, s+std::strlen(s)).</p>
2853 </blockquote>
2854
2855 <p>Notice the second condition is the same as the first. I think the second condition
2856 should be "If mode&amp;app==app", or "mode&amp;app!=0", meaning that
2857 the append bit is set.</p>
2858 <p><b>Proposed resolution:</b></p>
2859 <p>In D.7.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.ostrstream.cons"> [depr.ostrstream.cons]</a> paragraph 2 and D.7.4.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.strstream.cons"> [depr.strstream.cons]</a>
2860 paragraph 2, change the first condition to <tt>(mode&amp;app)==0</tt>
2861 and the second condition to <tt>(mode&amp;app)!=0</tt>.</p>
2862 <hr>
2863 <a name="117"><h3>117.&nbsp;<tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</h3></a><p>
2864 <b>Section:</b>&nbsp;27.6.2.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.arithmetic"> [lib.ostream.inserters.arithmetic]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Nov 1998</p>
2865 <p>The <b>effects</b> clause for numeric inserters says that
2866 insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
2867 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
2868 int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
2869 <tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
2870 delegated to <tt>num_put</tt>, and that insertion is performed as if
2871 through the following code fragment: </p>
2872
2873 <pre>bool failed = use_facet&lt;
2874    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
2875    &gt;(getloc()).put(*this, *this, fill(), val). failed();</pre>
2876
2877 <p>This doesn't work, because <tt>num_put&lt;&gt;</tt>::put is only
2878 overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
2879 long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
2880 void*</tt>. That is, the code fragment in the standard is incorrect
2881 (it is diagnosed as ambiguous at compile time) for the types
2882 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
2883 int</tt>, and <tt>float</tt>. </p>
2884
2885 <p>We must either add new member functions to <tt>num_put</tt>, or
2886 else change the description in <tt>ostream</tt> so that it only calls
2887 functions that are actually there. I prefer the latter. </p>
2888 <p><b>Proposed resolution:</b></p>
2889 <p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
2890
2891 <blockquote>
2892 <p>
2893 The classes num_get&lt;&gt; and num_put&lt;&gt; handle localedependent numeric
2894 formatting and parsing.  These inserter functions use the imbued
2895 locale value to perform numeric formatting.  When val is of type bool,
2896 long, unsigned long, double, long double, or const void*, the
2897 formatting conversion occurs as if it performed the following code
2898 fragment:
2899 </p>
2900
2901 <pre>bool failed = use_facet&lt;
2902    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
2903    &gt;(getloc()).put(*this, *this, fill(), val). failed();
2904 </pre>
2905
2906 <p>
2907 When val is of type short the formatting conversion occurs as if it
2908 performed the following code fragment:
2909 </p>
2910
2911 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
2912 bool failed = use_facet&lt;
2913    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
2914    &gt;(getloc()).put(*this, *this, fill(),
2915       baseflags == ios_base::oct || baseflags == ios_base::hex
2916          ? static_cast&lt;long&gt;(static_cast&lt;unsigned short&gt;(val))
2917          : static_cast&lt;long&gt;(val)). failed();
2918 </pre>
2919
2920 <p>
2921 When val is of type int the formatting conversion occurs as if it performed
2922 the following code fragment:
2923 </p>
2924
2925 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
2926 bool failed = use_facet&lt;
2927    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
2928    &gt;(getloc()).put(*this, *this, fill(),
2929       baseflags == ios_base::oct || baseflags == ios_base::hex
2930          ? static_cast&lt;long&gt;(static_cast&lt;unsigned int&gt;(val))
2931          : static_cast&lt;long&gt;(val)). failed();
2932 </pre>
2933
2934 <p>
2935 When val is of type unsigned short or unsigned int the formatting conversion
2936 occurs as if it performed the following code fragment:
2937 </p>
2938
2939 <pre>bool failed = use_facet&lt;
2940    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
2941    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;unsigned long&gt;(val)).
2942 failed();
2943 </pre>
2944
2945 <p>
2946 When val is of type float the formatting conversion occurs as if it
2947 performed the following code fragment:
2948 </p>
2949
2950 <pre>bool failed = use_facet&lt;
2951    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
2952    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;double&gt;(val)).
2953 failed();
2954 </pre>
2955
2956 </blockquote>
2957
2958 <p><i>[post-Toronto: This differs from the previous proposed
2959 resolution; PJP provided the new wording.  The differences are in
2960 signed short and int output.]</i></p>
2961 <p><b>Rationale:</b></p>
2962 <p>The original proposed resolution was to cast int and short to long,
2963 unsigned int and unsigned short to unsigned long, and float to double,
2964 thus ensuring that we don't try to use nonexistent num_put&lt;&gt;
2965 member functions.  The current proposed resolution is more
2966 complicated, but gives more expected results for hex and octal output
2967 of signed short and signed int.  (On a system with 16-bit short, for
2968 example, printing short(-1) in hex format should yield 0xffff.)</p>
2969 <hr>
2970 <a name="118"><h3>118.&nbsp;<tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3></a><p>
2971 <b>Section:</b>&nbsp;27.6.1.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Nov 1998</p>
2972 <p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
2973 <tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
2974 <tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
2975 formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
2976
2977 <pre>typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
2978 iostate err = 0;
2979 use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, val);
2980 setstate(err);</pre>
2981
2982 <p>According to section 22.2.2.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>, however,
2983 <tt>num_get&lt;&gt;::get()</tt> is only overloaded for the types
2984 <tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
2985 int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
2986 <tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
2987 <tt>void*</tt>. Comparing the lists from the two sections, we find
2988 that 27.6.1.2.2 is using a nonexistent function for types
2989 <tt>short</tt> and <tt>int</tt>. </p>
2990 <p><b>Proposed resolution:</b></p>
2991 <p>In 27.6.1.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> Arithmetic Extractors, remove the
2992 two lines (1st and 3rd) which read:</p>
2993 <blockquote>
2994   <pre>operator&gt;&gt;(short&amp; val);
2995 ...
2996 operator&gt;&gt;(int&amp; val);</pre>
2997 </blockquote>
2998
2999 <p>And add the following at the end of that section (27.6.1.2.2) :</p>
3000
3001 <blockquote>
3002   <pre>operator&gt;&gt;(short&amp; val);</pre>
3003   <p>The conversion occurs as if performed by the following code fragment (using
3004   the same notation as for the preceding code fragment):</p>
3005   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3006   iostate err = 0;
3007   long lval;
3008   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
3009         if (err == 0
3010                 &amp;&amp; (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval))
3011                 err = ios_base::failbit;
3012   setstate(err);</pre>
3013   <pre>operator&gt;&gt;(int&amp; val);</pre>
3014   <p>The conversion occurs as if performed by the following code fragment (using
3015   the same notation as for the preceding code fragment):</p>
3016   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3017   iostate err = 0;
3018   long lval;
3019   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
3020         if (err == 0
3021                 &amp;&amp; (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval))
3022                 err = ios_base::failbit;
3023   setstate(err);</pre>
3024 </blockquote>
3025
3026 <p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
3027 <hr>
3028 <a name="119"><h3>119.&nbsp;Should virtual functions be allowed to strengthen the exception specification?</h3></a><p>
3029 <b>Section:</b>&nbsp;17.4.4.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3030 <p>Section 17.4.4.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> states: </p>
3031
3032 <p>"An implementation may strengthen the exception-specification
3033 for a function by removing listed exceptions." </p>
3034
3035 <p>The problem is that if an implementation is allowed to do this for
3036 virtual functions, then a library user cannot write a class that
3037 portably derives from that class. </p>
3038
3039 <p>For example, this would not compile if ios_base::failure::~failure
3040 had an empty exception specification: </p>
3041
3042 <pre>#include &lt;ios&gt;
3043 #include &lt;string&gt;
3044
3045 class D : public std::ios_base::failure {
3046 public:
3047         D(const std::string&amp;);
3048         ~D(); // error - exception specification must be compatible with
3049               // overridden virtual function ios_base::failure::~failure()
3050 };</pre>
3051 <p><b>Proposed resolution:</b></p>
3052 <p>Change Section 17.4.4.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> from:</p>
3053
3054 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
3055 exception-specification for a function"</p>
3056
3057 <p>to:</p>
3058
3059 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
3060 exception-specification for a non-virtual function". </p>
3061 <hr>
3062 <a name="122"><h3>122.&nbsp;streambuf/wstreambuf description should not say they are specializations</h3></a><p>
3063 <b>Section:</b>&nbsp;27.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3064 <p>Section 27.5.2 describes the streambuf classes this way: </p>
3065
3066 <blockquote>
3067
3068 <p>The class streambuf is a specialization of the template class basic_streambuf
3069 specialized for the type char. </p>
3070
3071 <p>The class wstreambuf is a specialization of the template class basic_streambuf
3072 specialized for the type wchar_t. </p>
3073
3074 </blockquote>
3075
3076 <p>This implies that these classes must be template specializations, not typedefs. </p>
3077
3078 <p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
3079 <p><b>Proposed resolution:</b></p>
3080 <p>Remove 27.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> paragraphs 2 and 3 (the above two
3081 sentences). </p>
3082 <p><b>Rationale:</b></p>
3083 <p>The <tt>streambuf</tt>  synopsis already has a declaration for the
3084 typedefs and that is sufficient. </p>
3085 <hr>
3086 <a name="123"><h3>123.&nbsp;Should valarray helper arrays fill functions be const?</h3></a><p>
3087 <b>Section:</b>&nbsp;26.3.5.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a>, 26.3.7.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a>, 26.3.8.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a>, 26.3.9.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998 </p>
3088 <p>One of the operator= in the valarray helper arrays is const and one
3089 is not. For example, look at slice_array. This operator= in Section
3090 26.3.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> is const: </p>
3091
3092 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const valarray&lt;T&gt;&amp;) const;</tt> </p>
3093
3094 <p>but this one in Section 26.3.5.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> is not: </p>
3095
3096 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const T&amp;); </tt>
3097 </p>
3098
3099 <p>The description of the semantics for these two functions is similar. </p>
3100 <p><b>Proposed resolution:</b></p>
3101
3102 <p>26.3.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> Template class slice_array</p>
3103 <blockquote>
3104
3105    <p>In the class template definition for slice_array, replace the member
3106    function declaration</p>
3107     <pre>      void operator=(const T&amp;);
3108     </pre>
3109    <p>with</p>
3110     <pre>      void operator=(const T&amp;) const;
3111     </pre>
3112 </blockquote>
3113
3114 <p>26.3.5.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> slice_array fill function</p>
3115 <blockquote>
3116
3117    <p>Change the function declaration</p>
3118     <pre>      void operator=(const T&amp;);
3119     </pre>
3120    <p>to</p>
3121     <pre>      void operator=(const T&amp;) const;
3122     </pre>
3123 </blockquote>
3124
3125 <p>26.3.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> Template class gslice_array</p>
3126 <blockquote>
3127
3128    <p>In the class template definition for gslice_array, replace the member
3129    function declaration</p>
3130     <pre>      void operator=(const T&amp;);
3131     </pre>
3132    <p>with</p>
3133     <pre>      void operator=(const T&amp;) const;
3134     </pre>
3135 </blockquote>
3136
3137 <p>26.3.7.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a> gslice_array fill function</p>
3138 <blockquote>
3139
3140    <p>Change the function declaration</p>
3141     <pre>      void operator=(const T&amp;);
3142     </pre>
3143    <p>to</p>
3144     <pre>      void operator=(const T&amp;) const;
3145     </pre>
3146 </blockquote>
3147
3148 <p>26.3.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> Template class mask_array</p>
3149 <blockquote>
3150
3151    <p>In the class template definition for mask_array, replace the member
3152    function declaration</p>
3153     <pre>      void operator=(const T&amp;);
3154     </pre>
3155    <p>with</p>
3156     <pre>      void operator=(const T&amp;) const;
3157     </pre>
3158 </blockquote>
3159
3160 <p>26.3.8.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a> mask_array fill function</p>
3161 <blockquote>
3162
3163    <p>Change the function declaration</p>
3164     <pre>      void operator=(const T&amp;);
3165     </pre>
3166    <p>to</p>
3167     <pre>      void operator=(const T&amp;) const;
3168     </pre>
3169 </blockquote>
3170
3171 <p>26.3.9 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a> Template class indirect_array</p>
3172 <blockquote>
3173
3174    <p>In the class template definition for indirect_array, replace the member
3175    function declaration</p>
3176     <pre>      void operator=(const T&amp;);
3177     </pre>
3178    <p>with</p>
3179     <pre>      void operator=(const T&amp;) const;
3180     </pre>
3181 </blockquote>
3182
3183 <p>26.3.9.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a> indirect_array fill function</p>
3184 <blockquote>
3185
3186    <p>Change the function declaration</p>
3187     <pre>      void operator=(const T&amp;);
3188     </pre>
3189    <p>to</p>
3190     <pre>      void operator=(const T&amp;) const;
3191     </pre>
3192 </blockquote>
3193
3194
3195 <p><i>[Redmond: Robert provided wording.]</i></p>
3196
3197 <p><b>Rationale:</b></p>
3198 <p>There's no good reason for one version of operator= being const and
3199 another one not.  Because of issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#253">253</a>, this now
3200 matters: these functions are now callable in more circumstances.  In
3201 many existing implementations, both versions are already const.</p>
3202 <hr>
3203 <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>
3204 <b>Section:</b>&nbsp;22.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3205 <p>In Section 22.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>
3206 ctype_byname&lt;charT&gt;::do_scan_is() and do_scan_not() are declared
3207 to return a const char* not a const charT*. </p>
3208 <p><b>Proposed resolution:</b></p>
3209 <p>Change Section 22.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a> <tt>do_scan_is()</tt> and
3210 <tt>do_scan_not()</tt> to return a <tt> const
3211 charT*</tt>. </p>
3212 <hr>
3213 <a name="125"><h3>125.&nbsp;valarray&lt;T&gt;::operator!() return type is inconsistent</h3></a><p>
3214 <b>Section:</b>&nbsp;26.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3215 <p>In Section 26.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> valarray&lt;T&gt;::operator!() is
3216 declared to return a valarray&lt;T&gt;, but in Section 26.3.2.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.unary"> [lib.valarray.unary]</a> it is declared to return a valarray&lt;bool&gt;. The
3217 latter appears to be correct. </p>
3218 <p><b>Proposed resolution:</b></p>
3219 <p>Change in Section 26.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> the declaration of
3220 <tt>operator!()</tt> so that the return type is
3221 <tt>valarray&lt;bool&gt;</tt>. </p>
3222 <hr>
3223 <a name="126"></a><h3><a name="126">126.&nbsp;typos in Effects clause of ctype::do_narrow()</a></h3><p>
3224 <b>Section:</b>&nbsp;22.2.1.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3225 <p>Typos in 22.2.1.1.2 need to be fixed.</p>
3226 <p><b>Proposed resolution:</b></p>
3227 <p>In Section 22.2.1.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> change: </p>
3228
3229 <pre>   do_widen(do_narrow(c),0) == c</pre>
3230
3231 <p>to:</p>
3232
3233 <pre>   do_widen(do_narrow(c,0)) == c</pre>
3234
3235 <p>and change:</p>
3236
3237 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
3238
3239 <p>to:</p>
3240
3241 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
3242 <hr>
3243 <a name="127"><h3>127.&nbsp;auto_ptr&lt;&gt; conversion issues</h3></a><p>
3244 <b>Section:</b>&nbsp;20.4.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Colvin&nbsp; <b>Date:</b>&nbsp;17 Feb 1999</p>
3245 <p>There are two problems with the current <tt>auto_ptr</tt> wording
3246 in the standard: </p>
3247
3248 <p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
3249 because <tt>auto_ptr&lt;Derived&gt;::auto_ptr_ref</tt> is unrelated to
3250 <tt>auto_ptr&lt;Base&gt;::auto_ptr_ref</tt>.  <i>Also submitted by
3251 Nathan Myers, with the same proposed resolution.</i>
3252 </p>
3253
3254 <p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
3255 <tt>auto_ptr_ref</tt> argument. </p>
3256
3257 <p>I have discussed these problems with my proposal coauthor, Bill
3258 Gibbons, and with some compiler and library implementors, and we
3259 believe that these problems are not desired or desirable implications
3260 of the standard. </p>
3261
3262 <p>25 Aug 1999: The proposed resolution now reflects changes suggested
3263 by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
3264 "assignment operator" to "public assignment
3265 operator", 2) changed effects to specify use of release(), 3)
3266 made the conversion to auto_ptr_ref const. </p>
3267
3268 <p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
3269 states that the conversion from auto_ptr to auto_ptr_ref should
3270 be const.  This is not acceptable, because it would allow
3271 initialization and assignment from _any_ const auto_ptr!  It also
3272 introduces an implementation difficulty in writing this conversion
3273 function -- namely, somewhere along the line, a const_cast will be
3274 necessary to remove that const so that release() may be called.  This
3275 may result in undefined behavior [7.1.5.1/4]. The conversion
3276 operator does not have to be const, because a non-const implicit
3277 object parameter may be bound to an rvalue [13.3.3.1.4/3]
3278 [13.3.1/5]. </p>
3279
3280   <p>Tokyo: The LWG removed the following from the proposed resolution:</p>
3281
3282   <p>In 20.4.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, and 20.4.5.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr.conv"> [lib.auto.ptr.conv]</a>,
3283   paragraph 2, make the conversion to auto_ptr_ref const:</p>
3284   <blockquote>
3285     <pre>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() const throw();</pre>
3286   </blockquote>
3287 <p><b>Proposed resolution:</b></p>
3288 <p>In 20.4.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, move
3289 the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
3290
3291 <p>In 20.4.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, add
3292 a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
3293
3294 <blockquote>
3295   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</pre>
3296 </blockquote>
3297
3298 <p>Also add the assignment operator to 20.4.5.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr.conv"> [lib.auto.ptr.conv]</a>: </p>
3299
3300 <blockquote>
3301   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw()</pre>
3302
3303   <b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
3304   p</tt> that <tt>r</tt> holds a reference to.<br>
3305   <b>Returns: </b><tt>*this</tt>.
3306
3307 </blockquote>
3308 <hr>
3309 <a name="129"><h3>129.&nbsp;Need error indication from seekp() and seekg()</h3></a><p>
3310 <b>Section:</b>&nbsp;27.6.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, 27.6.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;22 Feb 1999</p>
3311 <p>Currently, the standard does not specify how seekg() and seekp()
3312 indicate failure. They are not required to set failbit, and they can't
3313 return an error indication because they must return *this, i.e. the
3314 stream. Hence, it is undefined what happens if they fail. And they
3315 <i>can</i> fail, for instance, when a file stream is disconnected from the
3316 underlying file (is_open()==false) or when a wide character file
3317 stream must perform a state-dependent code conversion, etc. </p>
3318
3319 <p>The stream functions seekg() and seekp() should set failbit in the
3320 stream state in case of failure.</p>
3321 <p><b>Proposed resolution:</b></p>
3322 <p>Add to the Effects: clause of&nbsp; seekg() in
3323 27.6.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> and to the Effects: clause of seekp() in
3324 27.6.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a>: </p>
3325
3326 <blockquote>
3327   <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
3328   </p>
3329 </blockquote>
3330 <p><b>Rationale:</b></p>
3331 <p>Setting failbit is the usual error reporting mechanism for streams</p>
3332 <hr>
3333 <a name="132"><h3>132.&nbsp;list::resize description uses random access iterators</h3></a><p>
3334 <b>Section:</b>&nbsp;23.2.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.capacity"> [lib.list.capacity]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3335 <p>The description reads:</p>
3336
3337 <p>-1- Effects:</p>
3338
3339 <pre>         if (sz &gt; size())
3340            insert(end(), sz-size(), c);
3341          else if (sz &lt; size())
3342            erase(begin()+sz, end());
3343          else
3344            ;                           //  do nothing</pre>
3345
3346 <p>Obviously list::resize should not be specified in terms of random access iterators.</p>
3347 <p><b>Proposed resolution:</b></p>
3348 <p>Change 23.2.2.2 paragraph 1 to:</p>
3349
3350 <p>Effects:</p>
3351
3352 <pre>         if (sz &gt; size())
3353            insert(end(), sz-size(), c);
3354          else if (sz &lt; size())
3355          {
3356            iterator i = begin();
3357            advance(i, sz);
3358            erase(i, end());
3359          }</pre>
3360
3361 <p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
3362 with David Abrahams. They had a discussion and believe there is
3363 no issue of exception safety with the proposed resolution.]</i></p>
3364 <hr>
3365 <a name="133"><h3>133.&nbsp;map missing get_allocator()</h3></a><p>
3366 <b>Section:</b>&nbsp;23.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3367 <p>The title says it all.</p>
3368 <p><b>Proposed resolution:</b></p>
3369 <p>Insert in 23.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
3370 after operator= in the map declaration:</p>
3371
3372 <pre>    allocator_type get_allocator() const;</pre>
3373 <hr>
3374 <a name="134"><h3>134.&nbsp;vector constructors over specified</h3></a><p>
3375 <b>Section:</b>&nbsp;23.2.4.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3376 <p>The complexity description says: "It does at most 2N calls to the copy constructor
3377 of T and logN reallocations if they are just input iterators ...".</p>
3378
3379 <p>This appears to be overly restrictive, dictating the precise memory/performance
3380 tradeoff for the implementor.</p>
3381 <p><b>Proposed resolution:</b></p>
3382 <p>Change 23.2.4.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a>, paragraph 1 to:</p>
3383
3384 <p>-1- Complexity: The constructor template &lt;class
3385 InputIterator&gt; vector(InputIterator first, InputIterator last)
3386 makes only N calls to the copy constructor of T (where N is the
3387 distance between first and last) and no reallocations if iterators
3388 first and last are of forward, bidirectional, or random access
3389 categories. It makes order N calls to the copy constructor of T and
3390 order logN reallocations if they are just input iterators.
3391 </p>
3392 <p><b>Rationale:</b></p>
3393 <p>"at most 2N calls" is correct only if the growth factor
3394 is greater than or equal to 2.
3395 </p>
3396 <hr>
3397 <a name="136"><h3>136.&nbsp;seekp, seekg setting wrong streams?</h3></a><p>
3398 <b>Section:</b>&nbsp;27.6.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3399 <p>I may be misunderstanding the intent, but should not seekg set only
3400 the input stream and seekp set only the output stream? The description
3401 seems to say that each should set both input and output streams. If
3402 that's really the intent, I withdraw this proposal.</p>
3403 <p><b>Proposed resolution:</b></p>
3404 <p>In section 27.6.1.3 change:</p>
3405
3406 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
3407 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
3408
3409 <p>To:</p>
3410
3411 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
3412 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::in). </pre>
3413
3414 <p>In section 27.6.1.3 change:</p>
3415
3416 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
3417 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
3418
3419 <p>To:</p>
3420
3421 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
3422 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::in). </pre>
3423
3424 <p>In section 27.6.2.4, paragraph 2 change:</p>
3425
3426 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
3427
3428 <p>To:</p>
3429
3430 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::out). </pre>
3431
3432 <p>In section 27.6.2.4, paragraph 4 change:</p>
3433
3434 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
3435
3436 <p>To:</p>
3437
3438 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::out). </pre>
3439
3440 <p><i>[Dublin: Dietmar Kühl thinks this is probably correct, but would
3441 like the opinion of more iostream experts before taking action.]</i></p>
3442
3443 <p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
3444 incorrect, his implementation already implements the Proposed
3445 Resolution.]</i></p>
3446
3447 <p><i>[Post-Tokyo: Matt Austern comments:<br>
3448 Is it a problem with basic_istream and basic_ostream, or is it a problem
3449 with basic_stringbuf?
3450 We could resolve the issue either by changing basic_istream and
3451 basic_ostream, or by changing basic_stringbuf. I prefer the latter
3452 change (or maybe both changes): I don't see any reason for the standard to
3453 require that std::stringbuf s(std::string("foo"), std::ios_base::in);
3454 s.pubseekoff(0, std::ios_base::beg); must fail.<br>
3455 This requirement is a bit weird. There's no similar requirement
3456 for basic_streambuf&lt;&gt;::seekpos, or for basic_filebuf&lt;&gt;::seekoff or
3457 basic_filebuf&lt;&gt;::seekpos.]</i></p>
3458 <hr>
3459 <a name="137"><h3>137.&nbsp;Do use_facet and has_facet look in the global locale?</h3></a><p>
3460 <b>Section:</b>&nbsp;22.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;17 Mar 1999</p>
3461 <p>Section 22.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> says:</p>
3462
3463 <p>-4- In the call to use_facet&lt;Facet&gt;(loc), the type argument
3464 chooses a facet, making available all members of the named type. If
3465 Facet is not present in a locale (or, failing that, in the global
3466 locale), it throws the standard exception bad_cast. A C++ program can
3467 check if a locale implements a particular facet with the template
3468 function has_facet&lt;Facet&gt;(). </p>
3469
3470 <p>This contradicts the specification given in section
3471 22.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a>:
3472 <br><br>
3473 template &lt;class&nbsp; Facet&gt; const&nbsp; Facet&amp; use_facet(const
3474 locale&amp;&nbsp; loc); <br>
3475 <br>
3476 -1- Get a reference to a facet of a locale. <br>
3477 -2- Returns: a reference to the corresponding facet of loc, if present. <br>
3478 -3- Throws: bad_cast if has_facet&lt;Facet&gt;(loc) is false. <br>
3479 -4- Notes: The reference returned remains valid at least as long as any copy of loc exists
3480 </p>
3481 <p><b>Proposed resolution:</b></p>
3482 <p>Remove the phrase "(or, failing that, in the global locale)"
3483 from section 22.1.1. </p>
3484 <p><b>Rationale:</b></p>
3485 <p>Needed for consistency with the way locales are handled elsewhere
3486 in the standard.</p>
3487 <hr>
3488 <a name="139"><h3>139.&nbsp;Optional sequence operation table description unclear</h3></a><p>
3489 <b>Section:</b>&nbsp;23.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;30 Mar 1999</p>
3490 <p>The sentence introducing the Optional sequence operation table
3491 (23.1.1 paragraph 12) has two problems:</p>
3492
3493 <p>A. It says ``The operations in table 68 are provided only for the containers for which
3494 they take constant time.''<br>
3495 <br>
3496 That could be interpreted in two ways, one of them being ``Even though table 68 shows
3497 particular operations as being provided, implementations are free to omit them if they
3498 cannot implement them in constant time.''<br>
3499 <br>
3500 B. That paragraph says nothing about amortized constant time, and it should.&nbsp;</p>
3501 <p><b>Proposed resolution:</b></p>
3502 <p>Replace the wording in 23.1.1 paragraph 12&nbsp; which begins ``The operations in table 68 are provided only..."
3503 with:</p>
3504
3505 <blockquote>
3506   <p>Table 68 lists sequence operations that are provided for some types of sequential
3507   containers but not others. An implementation shall provide these operations for all
3508   container types shown in the ``container'' column, and shall implement them so as to take
3509   amortized constant time.</p>
3510 </blockquote>
3511 <hr>
3512 <a name="141"><h3>141.&nbsp;basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3></a><p>
3513 <b>Section:</b>&nbsp;21.3.6.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::find.last.of"> [lib.string::find.last.of]</a>, 21.3.6.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::find.last.not.of"> [lib.string::find.last.not.of]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Arch Robison&nbsp; <b>Date:</b>&nbsp;28 Apr 1999</p>
3514 <p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
3515 say:<br>
3516 <br>
3517 &#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();</tt>
3518 </p>
3519
3520 <p>Surely the document meant to say ``<tt>xpos &lt; size()</tt>'' in both places.</p>
3521
3522 <p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
3523 proposed resolution.]</i></p>
3524 <p><b>Proposed resolution:</b></p>
3525 <p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
3526 <br>
3527 &#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();<br>
3528 <br>
3529 </tt>to:<br>
3530 <tt><br>
3531 </tt>&#8212; <tt>xpos &lt;= pos</tt> and <tt>xpos &lt; size();</tt>
3532 </p>
3533 <hr>
3534 <a name="142"><h3>142.&nbsp;lexicographical_compare complexity wrong</h3></a><p>
3535 <b>Section:</b>&nbsp;25.3.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;20 Jun 1999</p>
3536 <p>The lexicographical_compare complexity is specified as:<br>
3537 <br>
3538 &nbsp;&nbsp;&nbsp;&nbsp; "At most min((last1 - first1), (last2 - first2))
3539 applications of the corresponding comparison."<br>
3540 <br>
3541 The best I can do is twice that expensive.</p>
3542
3543 <p>Nicolai Josuttis comments in lib-6862: You mean, to check for
3544 equality you have to check both &lt; and &gt;? Yes, IMO you are
3545 right! (and Matt states this complexity in his book)</p>
3546
3547 <p><b>Proposed resolution:</b></p>
3548 <p>Change 25.3.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a> complexity to:</p>
3549     <blockquote>
3550     At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
3551     applications of the corresponding comparison.
3552     </blockquote>
3553
3554 <p>Change the example at the end of paragraph 3 to read:</p>
3555     <blockquote>
3556     [Example:<br>
3557     <br>
3558     &nbsp;&nbsp;&nbsp; for ( ; first1 != last1 &amp;&amp; first2 != last2 ;
3559     ++first1, ++first2) {<br>
3560     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first1 &lt; *first2) return true;<br>
3561     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first2 &lt; *first1) return false;<br>
3562     &nbsp;&nbsp;&nbsp; }<br>
3563     &nbsp;&nbsp;&nbsp; return first1 == last1 &amp;&amp; first2 != last2;<br>
3564     &nbsp;&nbsp;&nbsp;<br>
3565     --end example]
3566     </blockquote>
3567 <hr>
3568 <a name="144"><h3>144.&nbsp;Deque constructor complexity wrong </h3></a><p>
3569 <b>Section:</b>&nbsp;23.2.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.cons"> [lib.deque.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Herb Sutter&nbsp; <b>Date:</b>&nbsp;9 May 1999</p>
3570 <p>In 23.2.1.1 paragraph 6, the deque ctor that takes an iterator range appears
3571 to have complexity requirements which are incorrect, and which contradict the
3572 complexity requirements for insert(). I suspect that the text in question,
3573 below, was taken from vector:</p>
3574 <blockquote>
3575   <p>Complexity: If the iterators first and last are forward iterators,
3576   bidirectional iterators, or random access iterators the constructor makes only
3577   N calls to the copy constructor, and performs no reallocations, where N is
3578   last - first.</p>
3579 </blockquote>
3580 <p>The word "reallocations" does not really apply to deque. Further,
3581 all of the following appears to be spurious:</p>
3582 <blockquote>
3583   <p>It makes at most 2N calls to the copy constructor of T and log N
3584   reallocations if they are input iterators.1)</p>
3585   <p>1) The complexity is greater in the case of input iterators because each
3586   element must be added individually: it is impossible to determine the distance
3587   between first abd last before doing the copying.</p>
3588 </blockquote>
3589 <p>This makes perfect sense for vector, but not for deque. Why should deque gain
3590 an efficiency advantage from knowing in advance the number of elements to
3591 insert?</p>
3592 <p><b>Proposed resolution:</b></p>
3593 <p>In 23.2.1.1 paragraph 6, replace the Complexity description, including the
3594 footnote, with the following text (which also corrects the "abd"
3595 typo):</p>
3596 <blockquote>
3597   <p>Complexity: Makes last - first calls to the copy constructor of T.</p>
3598 </blockquote>
3599 <hr>
3600 <a name="146"><h3>146.&nbsp;complex&lt;T&gt; Inserter and Extractor need sentries</h3></a><p>
3601 <b>Section:</b>&nbsp;26.2.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;12 May 1999</p>
3602 <p>The <u> extractor</u> for complex numbers is specified as:&nbsp;</p>
3603
3604 <blockquote>
3605
3606 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
3607      basic_istream&lt;charT, traits&gt;&amp;&nbsp;<br>
3608      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;  is, complex&lt;T&gt;&amp;  x);<br>
3609 &nbsp;<br>
3610 Effects: Extracts a complex number x of the form: u, (u), or (u,v),
3611 where u is the real part and v is the imaginary part
3612 (lib.istream.formatted).&nbsp;<br>
3613 Requires: The input values be convertible to T. If bad input is
3614 encountered, calls is.setstate(ios::failbit) (which may throw
3615 ios::failure (lib.iostate.flags).&nbsp;<br>
3616 Returns: is .</p>
3617
3618 </blockquote>
3619 <p>Is it intended that the extractor for complex numbers does not skip
3620 whitespace, unlike all other extractors in the standard library do?
3621 Shouldn't a sentry be used?&nbsp;<br>
3622 <br>
3623 The <u>inserter</u> for complex numbers is specified as:</p>
3624
3625 <blockquote>
3626
3627 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
3628      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
3629      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;  o, const complex&lt;T&gt;&amp;  x);<br>
3630 <br>
3631 Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
3632 <br>
3633      template&lt;class T, class charT, class traits&gt;&nbsp;<br>
3634      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
3635      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; o, const complex&lt;T&gt;&amp; x)&nbsp;<br>
3636      {&nbsp;<br>
3637              basic_ostringstream&lt;charT, traits&gt; s;&nbsp;<br>
3638              s.flags(o.flags());&nbsp;<br>
3639              s.imbue(o.getloc());&nbsp;<br>
3640              s.precision(o.precision());&nbsp;<br>
3641              s &lt;&lt; '(' &lt;&lt; x.real() &lt;&lt; "," &lt;&lt; x.imag() &lt;&lt; ')';&nbsp;<br>
3642              return o &lt;&lt; s.str();&nbsp;<br>
3643      }</p>
3644
3645 </blockquote>
3646
3647 <p>Is it intended that the inserter for complex numbers ignores the
3648 field width and does not do any padding? If, with the suggested
3649 implementation above, the field width were set in the stream then the
3650 opening parentheses would be adjusted, but the rest not, because the
3651 field width is reset to zero after each insertion.</p>
3652
3653 <p>I think that both operations should use sentries, for sake of
3654 consistency with the other inserters and extractors in the
3655 library. Regarding the issue of padding in the inserter, I don't know
3656 what the intent was.&nbsp;</p>
3657 <p><b>Proposed resolution:</b></p>
3658 <p>After 26.2.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> paragraph 14 (operator&gt;&gt;), add a
3659 Notes clause:</p>
3660
3661 <blockquote>
3662
3663 <p>Notes: This extraction is performed as a series of simpler
3664 extractions. Therefore, the skipping of whitespace is specified to be the
3665 same for each of the simpler extractions.</p>
3666
3667 </blockquote>
3668 <p><b>Rationale:</b></p>
3669 <p>For extractors, the note is added to make it clear that skipping whitespace
3670 follows an "all-or-none" rule.</p>
3671
3672 <p>For inserters, the LWG believes there is no defect; the standard is correct
3673 as written.</p>
3674 <hr>
3675 <a name="147"><h3>147.&nbsp;Library Intro refers to global functions that aren't global</h3></a><p>
3676 <b>Section:</b>&nbsp;17.4.4.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Lois Goldthwaite&nbsp; <b>Date:</b>&nbsp;4 Jun 1999</p>
3677 <p>The library had many global functions until 17.4.1.1 [lib.contents]
3678 paragraph 2 was added: </p>
3679
3680 <blockquote>
3681
3682 <p>All library entities except macros, operator new and operator
3683 delete are defined within the namespace std or namespaces nested
3684 within namespace std. </p>
3685
3686 </blockquote>
3687
3688 <p>It appears "global function" was never updated in the following: </p>
3689
3690 <blockquote>
3691
3692 <p>17.4.4.3 - Global functions [lib.global.functions]<br>
3693 <br>
3694 -1- It is unspecified whether any global functions in the C++ Standard
3695 Library are defined as inline (dcl.fct.spec).<br>
3696 <br>
3697 -2- A call to a global function signature described in Clauses
3698 lib.language.support through lib.input.output behaves the same as if
3699 the implementation declares no additional global function
3700 signatures.*<br>
3701 <br>
3702     [Footnote: A valid C++ program always calls the expected library
3703     global function. An implementation may also define additional
3704     global functions that would otherwise not be called by a valid C++
3705     program. --- end footnote]<br>
3706 <br>
3707 -3- A global function cannot be declared by the implementation as
3708 taking additional default arguments.&nbsp;<br>
3709 <br>
3710 17.4.4.4 - Member functions [lib.member.functions]<br>
3711 <br>
3712 -2- An implementation can declare additional non-virtual member
3713 function signatures within a class: </p>
3714
3715   <blockquote>
3716
3717 <p>-- by adding arguments with default values to a member function
3718 signature; The same latitude does not extend to the implementation of
3719 virtual or global functions, however. </p>
3720
3721   </blockquote>
3722 </blockquote>
3723 <p><b>Proposed resolution:</b></p>
3724 <p>     Change "global" to "global or non-member" in:</p>
3725 <blockquote>
3726   <p>17.4.4.3 [lib.global.functions] section title,<br>
3727   17.4.4.3 [lib.global.functions] para 1,<br>
3728   17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2
3729            places in the footnote,<br>
3730   17.4.4.3 [lib.global.functions] para 3,<br>
3731   17.4.4.4 [lib.member.functions] para 2</p>
3732 </blockquote>
3733 <p><b>Rationale:</b></p>
3734 <p>
3735 Because operator new and delete are global, the proposed resolution
3736 was changed from "non-member" to "global or non-member.
3737 </p>
3738 <hr>
3739 <a name="148"><h3>148.&nbsp;Functions in the example facet BoolNames should be const</h3></a><p>
3740 <b>Section:</b>&nbsp;22.2.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jeremy Siek&nbsp; <b>Date:</b>&nbsp;3 Jun 1999</p>
3741 <p>In 22.2.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, the do_truename() and
3742 do_falsename() functions in the example facet BoolNames should be
3743 const. The functions they are overriding in
3744 numpunct_byname&lt;char&gt; are const. </p>
3745 <p><b>Proposed resolution:</b></p>
3746 <p>In 22.2.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, insert "const" in
3747 two places:</p>
3748 <blockquote>
3749   <p><tt>string do_truename() const { return "Oui Oui!"; }<br>
3750   string do_falsename() const { return "Mais Non!"; }</tt></p>
3751 </blockquote>
3752 <hr>
3753 <a name="150"><h3>150.&nbsp;Find_first_of says integer instead of iterator </h3></a><p>
3754 <b>Section:</b>&nbsp;25.1.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt McClure&nbsp; <b>Date:</b>&nbsp;30 Jun 1999</p>
3755 <p><b>Proposed resolution:</b></p>
3756 <p>Change 25.1.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> paragraph 2 from:</p>
3757
3758 <blockquote>
3759 <p>Returns: The first iterator i in the range [first1, last1) such
3760 that for some <u>integer</u> j in the range [first2, last2) ...</p>
3761 </blockquote>
3762
3763 <p>to:</p>
3764
3765 <blockquote>
3766 <p>Returns: The first iterator i in the range [first1, last1) such
3767 that for some iterator j in the range [first2, last2) ...</p>
3768 </blockquote>
3769 <hr>
3770 <a name="151"><h3>151.&nbsp;Can't currently clear() empty container</h3></a><p>
3771 <b>Section:</b>&nbsp;23.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Ed Brey&nbsp; <b>Date:</b>&nbsp;21 Jun 1999</p>
3772 <p>For both sequences and associative containers, a.clear() has the
3773 semantics of erase(a.begin(),a.end()), which is undefined for an empty
3774 container since erase(q1,q2) requires that q1 be dereferenceable
3775 (23.1.1,3 and 23.1.2,7).  When the container is empty, a.begin() is
3776 not dereferenceable.<br>
3777 <br>
3778 The requirement that q1 be unconditionally dereferenceable causes many
3779 operations to be intuitively undefined, of which clearing an empty
3780 container is probably the most dire.<br>
3781 <br>
3782 Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
3783 q2) is required to be a valid range, stating that q1 and q2 must be
3784 iterators or certain kinds of iterators is unnecessary.
3785 </p>
3786 <p><b>Proposed resolution:</b></p>
3787 <p>In 23.1.1, paragraph 3, change:</p>
3788 <blockquote>
3789   <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>
3790 </blockquote>
3791 <p>to:</p>
3792 <blockquote>
3793   <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range<u>
3794   in a</u>
3795 </p>
3796 </blockquote>
3797 <p>In 23.1.2, paragraph 7, change:</p>
3798 <blockquote>
3799   <p>p and q2 are valid iterators to a, q <u> and q1</u> are valid dereferenceable
3800   iterators to a, [q1, q2) is a valid range</p>
3801 </blockquote>
3802 <p>to</p>
3803 <blockquote>
3804   <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
3805   <u>into a</u>
3806 </p>
3807 </blockquote>
3808 <hr>
3809 <a name="152"></a><h3><a name="152">152.&nbsp;Typo in <tt>scan_is()</tt> semantics</a></h3><p>
3810 <b>Section:</b>&nbsp;22.2.1.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
3811 <p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
3812 because there is no function <tt>is()</tt> which only takes a character as
3813 argument. Also, in the effects clause (paragraph 3), the semantic is also kept
3814 vague.</p>
3815 <p><b>Proposed resolution:</b></p>
3816 <p>In 22.2.1.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> paragraphs 4 and 6, change the returns
3817 clause from:</p>
3818 <blockquote>
3819   <p>"... such that <tt>is(*p)</tt>
3820 would..."</p>
3821 </blockquote>
3822 <p>to:&nbsp; "... such that <tt>is(m, *p)</tt>
3823  would...."</p>
3824 <hr>
3825 <a name="153"><h3>153.&nbsp;Typo in <tt>narrow()</tt> semantics</h3></a><p>
3826 <b>Section:</b>&nbsp;22.2.1.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
3827 <p>The description of the array version of <tt>narrow()</tt> (in
3828 paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
3829 takes only three arguments because in addition to the range a default
3830 character is needed.</p>
3831
3832 <p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
3833 two signatures followed by a <b>Returns</b> clause that only addresses
3834 one of them.</p>
3835
3836 <p><b>Proposed resolution:</b></p>
3837 <p>Change the returns clause in 22.2.1.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a>
3838 paragraph 10 from:</p>
3839 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
3840
3841 <p>to:</p>
3842 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to),
3843 respectively.</p>
3844
3845 <p>Change 22.2.1.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> paragraph 10 and 11 from:</p>
3846 <pre>        char        narrow(char c, char /*dfault*/) const;
3847         const char* narrow(const char* low, const char* high,
3848                            char /*dfault*/, char* to) const;</pre>
3849 <pre>        Returns: do_narrow(low, high, to).</pre>
3850 <p>to:</p>
3851 <pre>        char        narrow(char c, char dfault) const;
3852         const char* narrow(const char* low, const char* high,
3853                            char dfault, char* to) const;</pre>
3854 <pre>        Returns: do_narrow(c, dfault) or
3855                  do_narrow(low, high, dfault, to), respectively.</pre>
3856
3857 <p><i>[Kona: 1) the problem occurs in additional places, 2) a user
3858 defined version could be different.]</i></p>
3859
3860 <p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
3861 the LWG. He could find no other places the problem occurred. He
3862 asks for clarification of the Kona "a user defined
3863 version..." comment above.  Perhaps it was a circuitous way of
3864 saying "dfault" needed to be uncommented?]</i></p>
3865
3866 <p><i>[Post-Toronto: the issues list maintainer has merged in the
3867 proposed resolution from issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a>, which addresses the
3868 same paragraphs.]</i></p>
3869 <hr>
3870 <a name="154"><h3>154.&nbsp;Missing <tt>double</tt> specifier for <tt>do_get()</tt>
3871 </h3></a><p>
3872 <b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
3873 <p>The table in paragraph 7 for the length modifier does not list the length
3874 modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
3875 standard asks the implementation to do undefined things when using <tt>scanf()</tt>
3876 (the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
3877 is actually a problem I found quite often in production code, too).</p>
3878 <p><b>Proposed resolution:</b></p>
3879 <p>In 22.2.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, paragraph 7, add a row in the Length
3880 Modifier table to say that for <tt>double</tt> a length modifier
3881 <tt>l</tt> is to be used.</p>
3882 <p><b>Rationale:</b></p>
3883 <p>The standard makes an embarrassing beginner's mistake.</p>
3884 <hr>
3885 <a name="155"><h3>155.&nbsp;Typo in naming the class defining the class <tt>Init</tt>
3886 </h3></a><p>
3887 <b>Section:</b>&nbsp;27.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
3888 <p>There are conflicting statements about where the class
3889 <tt>Init</tt> is defined. According to 27.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2
3890 it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> it is defined as <tt>ios_base::Init</tt>.</p>
3891 <p><b>Proposed resolution:</b></p>
3892 <p>Change 27.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2 from
3893 "<tt>basic_ios::Init"</tt> to
3894 "<tt>ios_base::Init"</tt>.</p>
3895 <p><b>Rationale:</b></p>
3896 <p>Although not strictly wrong, the standard was misleading enough to warrant
3897 the change.</p>
3898 <hr>
3899 <a name="156"></a><h3><a name="156">156.&nbsp;Typo in <tt>imbue()</tt> description</a></h3><p>
3900 <b>Section:</b>&nbsp;27.4.2.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
3901 <p>There is a small discrepancy between the declarations of
3902 <tt>imbue()</tt>: in 27.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> the argument is passed as
3903 <tt>locale const&amp;</tt> (correct), in 27.4.2.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> it
3904 is passed as <tt>locale const</tt> (wrong).</p>
3905 <p><b>Proposed resolution:</b></p>
3906 <p>In 27.4.2.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> change the <tt>imbue</tt> argument
3907 from "<tt>locale const" to "locale
3908 const&amp;".</tt>
3909 </p>
3910 <hr>
3911 <a name="158"><h3>158.&nbsp;Underspecified semantics for <tt>setbuf()</tt>
3912 </h3></a><p>
3913 <b>Section:</b>&nbsp;27.5.2.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
3914 <p>The default behavior of <tt>setbuf()</tt> is described only for the
3915 situation that <tt>gptr() != 0 &amp;&amp; gptr() != egptr()</tt>:
3916 namely to do nothing.  What has to be done in other situations&nbsp;
3917 is not described although there is actually only one reasonable
3918 approach, namely to do nothing, too.</p>
3919
3920 <p>Since changing the buffer would almost certainly mess up most
3921 buffer management of derived classes unless these classes do it
3922 themselves, the default behavior of <tt>setbuf()</tt> should always be
3923 to do nothing.</p>
3924 <p><b>Proposed resolution:</b></p>
3925 <p>Change 27.5.2.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 3, Default behavior,
3926 to: "Default behavior: Does nothing. Returns this."</p>
3927 <hr>
3928 <a name="159"><h3>159.&nbsp;Strange use of <tt>underflow()</tt>
3929 </h3></a><p>
3930 <b>Section:</b>&nbsp;27.5.2.4.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
3931 <p>The description of the meaning of the result of
3932 <tt>showmanyc()</tt> seems to be rather strange: It uses calls to
3933 <tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
3934 this function only reads the current character but does not extract
3935 it, <tt>uflow()</tt> would extract the current character. This should
3936 be fixed to use <tt>sbumpc()</tt> instead.</p>
3937 <p><b>Proposed resolution:</b></p>
3938 <p>Change 27.5.2.4.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a> paragraph 1,
3939 <tt>showmanyc()</tt>returns clause, by replacing the word
3940 "supplied" with the words "extracted from the
3941 stream".</p>
3942 <hr>
3943 <a name="160"><h3>160.&nbsp;Typo: Use of non-existing function <tt>exception()</tt>
3944 </h3></a><p>
3945 <b>Section:</b>&nbsp;27.6.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
3946 <p>The paragraph 4 refers to the function <tt>exception()</tt> which
3947 is not defined. Probably, the referred function is
3948 <tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>
3949 <p><b>Proposed resolution:</b></p>
3950 <p>In 27.6.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a>, 27.6.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, paragraph 1,
3951 27.6.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, paragraph 3, and 27.6.2.5.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>,
3952 paragraph 1, change "<tt>exception()" to
3953 "exceptions()"</tt>.</p>
3954
3955 <p><i>[Note to Editor: "exceptions" with an "s"
3956 is the correct spelling.]</i></p>
3957 <hr>
3958 <a name="161"><h3>161.&nbsp;Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt>
3959 </h3></a><p>
3960 <b>Section:</b>&nbsp;27.6.1.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
3961 <p>The note in the second paragraph pretends that the first argument
3962 is an object of type <tt>istream_iterator</tt>. This is wrong: It is
3963 an object of type <tt>istreambuf_iterator</tt>.</p>
3964 <p><b>Proposed resolution:</b></p>
3965 <p>Change 27.6.1.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> from:</p>
3966 <blockquote>
3967   <p>The first argument provides an object of the istream_iterator class...</p>
3968 </blockquote>
3969 <p>to</p>
3970 <blockquote>
3971   <p>The first argument provides an object of the istreambuf_iterator class...</p>
3972 </blockquote>
3973 <hr>
3974 <a name="164"><h3>164.&nbsp;do_put() has apparently unused fill argument</h3></a><p>
3975 <b>Section:</b>&nbsp;22.2.5.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
3976 <p>In 22.2.5.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> the do_put() function is specified
3977 as taking a fill character as an argument, but the description of the
3978 function does not say whether the character is used at all and, if so,
3979 in which way. The same holds for any format control parameters that
3980 are accessible through the ios_base&amp; argument, such as the
3981 adjustment or the field width. Is strftime() supposed to use the fill
3982 character in any way? In any case, the specification of
3983 time_put.do_put() looks inconsistent to me.<br> <br> Is the
3984 signature of do_put() wrong, or is the effects clause incomplete?</p>
3985 <p><b>Proposed resolution:</b></p>
3986 <p>Add the following note after 22.2.5.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a>
3987 paragraph 2:</p>
3988 <blockquote>
3989   <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
3990   for this argument. --end Note]</p>
3991 </blockquote>
3992 <p><b>Rationale:</b></p>
3993 <p>The LWG felt that while the normative text was correct,
3994 users need some guidance on what to pass for the <tt>fill</tt>
3995 argument since the standard doesn't say how it's used.</p>
3996 <hr>
3997 <a name="165"><h3>165.&nbsp;<tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3></a><p>
3998 <b>Section:</b>&nbsp;27.6.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
3999 <p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
4000 functions falling into one of the groups "formatted output functions"
4001 and "unformatted output functions" calls any stream buffer function
4002 which might call a virtual function other than <tt>overflow()</tt>. Basically
4003 this is fine but this implies that <tt>sputn()</tt> (this function would call
4004 the virtual function <tt>xsputn()</tt>) is never called by any of the standard
4005 output functions. Is this really intended? At minimum it would be convenient to
4006 call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
4007 is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
4008 with the definition of <tt>flush()</tt> which calls <tt>rdbuf()-&gt;pubsync()</tt>
4009 and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
4010 under "unformatted output functions").</p>
4011 <p>In addition, I guess that the sentence starting with "They may use other
4012 public members of <tt>basic_ostream</tt> ..." probably was intended to
4013 start with "They may use other public members of <tt>basic_streamuf</tt>..."
4014 although the problem with the virtual members exists in both cases.</p>
4015 <p>I see two obvious resolutions:</p>
4016 <ol>
4017   <li>state in a footnote that this means that <tt>xsputn()</tt> will never be
4018     called by any ostream member and that this is intended.</li>
4019   <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
4020     Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
4021 </ol>
4022 <p><b>Proposed resolution:</b></p>
4023 <p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
4024 <blockquote>
4025   <p>They may use other public members of basic_ostream except that they do not
4026   invoke any virtual members of rdbuf() except overflow().</p>
4027 </blockquote>
4028 <p>to:</p>
4029 <blockquote>
4030   <p>They may use other public members of basic_ostream except that they shall
4031   not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
4032   sync().</p>
4033 </blockquote>
4034
4035 <p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
4036 PJP why the standard is written this way.]</i></p>
4037
4038 <p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
4039 LWG. He comments: The rules can be made a little bit more specific if
4040 necessary be explicitly spelling out what virtuals are allowed to be
4041 called from what functions and eg to state specifically that flush()
4042 is allowed to call sync() while other functions are not.]</i></p>
4043 <hr>
4044 <a name="168"><h3>168.&nbsp;Typo: formatted vs. unformatted</h3></a><p>
4045 <b>Section:</b>&nbsp;27.6.2.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4046 <p>The first paragraph begins with a descriptions what has to be done
4047 in <i>formatted</i> output functions. Probably this is a typo and the
4048 paragraph really want to describe unformatted output functions...</p>
4049 <p><b>Proposed resolution:</b></p>
4050 <p>In 27.6.2.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> paragraph 1, the first and last
4051 sentences, change the word "formatted" to
4052 "unformatted":</p>
4053 <blockquote>
4054   <p>"Each <b>unformatted </b> output function begins ..."<br>
4055   "... value specified for the <b>unformatted </b>  output
4056   function."</p>
4057 </blockquote>
4058 <hr>
4059 <a name="169"><h3>169.&nbsp;Bad efficiency of <tt>overflow()</tt> mandated</h3></a><p>
4060 <b>Section:</b>&nbsp;27.7.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4061 <p>Paragraph 8, Notes, of this section seems to mandate an extremely
4062 inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
4063 especially in view of the restriction that <tt>basic_ostream</tt>
4064 member functions are not allowed to use <tt>xsputn()</tt> (see 27.6.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>): For each character to be inserted, a new buffer
4065 is to be created.</p>
4066 <p>Of course, the resolution below requires some handling of
4067 simultaneous input and output since it is no longer possible to update
4068 <tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
4069 solution is to handle this in <tt>underflow()</tt>.</p>
4070 <p><b>Proposed resolution:</b></p>
4071 <p>In 27.7.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> paragraph 8, Notes, insert the words
4072 "at least" as in the following:</p>
4073 <blockquote>
4074   <p>To make a write position available, the function reallocates (or initially
4075   allocates) an array object with a sufficient number of elements to hold the
4076   current array object (if any), plus <b>at least</b> one additional write
4077   position.</p>
4078 </blockquote>
4079 <hr>
4080 <a name="170"><h3>170.&nbsp;Inconsistent definition of <tt>traits_type</tt>
4081 </h3></a><p>
4082 <b>Section:</b>&nbsp;27.7.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4083 <p>The classes <tt>basic_stringstream</tt> (27.7.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>),
4084 <tt>basic_istringstream</tt> (27.7.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istringstream"> [lib.istringstream]</a>), and
4085 <tt>basic_ostringstream</tt> (27.7.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) are inconsistent
4086 in their definition of the type <tt>traits_type</tt>: For
4087 <tt>istringstream</tt>, this type is defined, for the other two it is
4088 not. This should be consistent.</p>
4089 <p><b>Proposed resolution:</b></p>
4090 <p><b>Proposed resolution:</b></p> <p>To the declarations of
4091 <tt>basic_ostringstream</tt> (27.7.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) and
4092 <tt>basic_stringstream</tt> (27.7.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>) add:</p>
4093 <blockquote>
4094 <pre>typedef traits traits_type;</pre>
4095 </blockquote>
4096 <hr>
4097 <a name="171"><h3>171.&nbsp;Strange <tt>seekpos()</tt> semantics due to joint position</h3></a><p>
4098 <b>Section:</b>&nbsp;27.8.1.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4099 <p>Overridden virtual functions, seekpos()</p> <p>In 27.8.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> paragraph 3, it is stated that a joint input and
4100 output position is maintained by <tt>basic_filebuf</tt>. Still, the
4101 description of <tt>seekpos()</tt> seems to talk about different file
4102 positions. In particular, it is unclear (at least to me) what is
4103 supposed to happen to the output buffer (if there is one) if only the
4104 input position is changed. The standard seems to mandate that the
4105 output buffer is kept and processed as if there was no positioning of
4106 the output position (by changing the input position). Of course, this
4107 can be exactly what you want if the flag <tt>ios_base::ate</tt> is
4108 set. However, I think, the standard should say something like
4109 this:</p>
4110 <ul>
4111   <li>If <tt>(which &amp; mode) == 0</tt> neither read nor write position is
4112     changed and the call fails. Otherwise, the joint read and write position is
4113     altered to correspond to <tt>sp</tt>.</li>
4114   <li>If there is an output buffer, the output sequences is updated and any
4115     unshift sequence is written before the position is altered.</li>
4116   <li>If there is an input buffer, the input sequence is updated after the
4117     position is altered.</li>
4118 </ul>
4119 <p>Plus the appropriate error handling, that is...</p>
4120 <p><b>Proposed resolution:</b></p>
4121 <p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
4122 paragraph 14 from:</p>
4123 <blockquote>
4124   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
4125   ios_base::out);</p>
4126   <p>Alters the file position, if possible, to correspond to the position stored
4127   in sp (as described below).</p>
4128   <p>- if (which&amp;ios_base::in)!=0, set the file position to sp, then update
4129   the input sequence</p>
4130   <p>- if (which&amp;ios_base::out)!=0, then update the output sequence, write
4131   any unshift sequence, and set the file position to sp.</p>
4132 </blockquote>
4133 <p>to:</p>
4134 <blockquote>
4135   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
4136   ios_base::out);</p>
4137   <p>Alters the file position, if possible, to correspond to the position stored
4138   in sp (as described below). Altering the file position performs as follows:</p>
4139   <p>1. if (om &amp; ios_base::out)!=0, then update the output sequence and
4140   write any unshift sequence;</p>
4141   <p>2. set the file position to sp;</p>
4142   <p>3. if (om &amp; ios_base::in)!=0, then update the input sequence;</p>
4143   <p>where om is the open mode passed to the last call to open(). The operation
4144   fails if is_open() returns false.</p>
4145 </blockquote>
4146
4147 <p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
4148 <p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
4149 <hr>
4150 <a name="172"><h3>172.&nbsp;Inconsistent types for <tt>basic_istream::ignore()</tt>
4151 </h3></a><p>
4152 <b>Section:</b>&nbsp;27.6.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Comeau, Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4153 <p>In 27.6.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a> the function
4154 <tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
4155 argument. However, in 27.6.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>
4156 paragraph 23 the first argument is of type <tt>int.</tt>
4157 </p>
4158
4159 <p>As far as I can see this is not really a contradiction because
4160 everything is consistent if <tt>streamsize</tt> is typedef to be
4161 <tt>int</tt>. However, this is almost certainly not what was
4162 intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
4163 as described in issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>.</p>
4164
4165 <p>Darin Adler also
4166 submitted this issue, commenting: Either 27.6.1.1 should be modified
4167 to show a first parameter of type int, or 27.6.1.3 should be modified
4168 to show a first parameter of type streamsize and use
4169 numeric_limits&lt;streamsize&gt;::max.</p>
4170 <p><b>Proposed resolution:</b></p>
4171 <p>In 27.6.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> paragraph 23 and 24, change both uses
4172 of <tt>int</tt> in the description of <tt>ignore()</tt> to
4173 <tt>streamsize</tt>.</p>
4174 <hr>
4175 <a name="173"><h3>173.&nbsp;Inconsistent types for <tt>basic_filebuf::setbuf()</tt>
4176 </h3></a><p>
4177 <b>Section:</b>&nbsp;27.8.1.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Comeau, Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4178
4179 <p>
4180 In 27.8.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> the function <tt>setbuf()</tt> gets an
4181 object of type <tt>streamsize</tt> as second argument. However, in
4182 27.8.1.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> paragraph 9 the second argument is of type
4183 <tt>int</tt>.
4184 </p>
4185
4186 <p>
4187 As far as I can see this is not really a contradiction because
4188 everything is consistent if <tt>streamsize</tt> is typedef to be
4189 <tt>int</tt>. However, this is almost certainly not what was
4190 intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
4191 as described in issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>.
4192 </p>
4193
4194 <p><b>Proposed resolution:</b></p>
4195 <p>In 27.8.1.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> paragraph 9, change all uses of
4196 <tt>int</tt> in the description of <tt>setbuf()</tt> to
4197 <tt>streamsize</tt>.</p>
4198 <hr>
4199 <a name="174"><h3>174.&nbsp;Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt>
4200 </h3></a><p>
4201 <b>Section:</b>&nbsp;D.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4202 <p>According to paragraph 1 of this section, <tt>streampos</tt> is the
4203 type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
4204 paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt>
4205 </p>
4206 <p><b>Proposed resolution:</b></p>
4207 <p>Change D.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 1 from "<tt>typedef
4208 OFF_T streampos;</tt>" to "<tt>typedef POS_T
4209 streampos;</tt>"</p>
4210 <hr>
4211 <a name="175"><h3>175.&nbsp;Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3></a><p>
4212 <b>Section:</b>&nbsp;D.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4213 <p>According to paragraph 8 of this section, the methods
4214 <tt>basic_streambuf::pubseekpos()</tt>,
4215 <tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
4216 "may" be overloaded by a version of this function taking the
4217 type <tt>ios_base::open_mode</tt> as last argument argument instead of
4218 <tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
4219 in this section to be an alias for one of the integral types). The
4220 clause specifies, that the last argument has a default argument in
4221 three cases.  However, this generates an ambiguity with the overloaded
4222 version because now the arguments are absolutely identical if the last
4223 argument is not specified.</p>
4224 <p><b>Proposed resolution:</b></p>
4225 <p>In D.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, remove the default arguments for
4226 <tt>basic_streambuf::pubseekpos()</tt>,
4227 <tt>basic_ifstream::open()</tt>, and
4228 <tt>basic_ofstream::open().</tt>
4229 </p>
4230 <hr>
4231 <a name="176"><h3>176.&nbsp;<tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3></a><p>
4232 <b>Section:</b>&nbsp;D.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4233 <p>The "overload" for the function <tt>exceptions()</tt> in
4234 paragraph 8 gives the impression that there is another function of
4235 this function defined in class <tt>ios_base</tt>. However, this is not
4236 the case. Thus, it is hard to tell how the semantics (paragraph 9) can
4237 be implemented: "Call the corresponding member function specified
4238 in clause 27 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>."</p>
4239 <p><b>Proposed resolution:</b></p>
4240 <p>In D.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, move the declaration of the
4241 function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
4242 <hr>
4243 <a name="179"><h3>179.&nbsp;Comparison of const_iterators to iterators doesn't work</h3></a><p>
4244 <b>Section:</b>&nbsp;23.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;2 Jul 1998</p>
4245 <p>Currently the following will not compile on two well-known standard
4246 library implementations:</p>
4247
4248 <blockquote>
4249   <pre>#include &lt;set&gt;
4250 using namespace std;
4251
4252 void f(const set&lt;int&gt; &amp;s)
4253 {
4254   set&lt;int&gt;::iterator i;
4255   if (i==s.end()); // s.end() returns a const_iterator
4256 }</pre>
4257 </blockquote>
4258
4259 <p>
4260 The reason this doesn't compile is because operator== was implemented
4261 as a member function of the nested classes set:iterator and
4262 set::const_iterator, and there is no conversion from const_iterator to
4263 iterator. Surprisingly, (s.end() == i) does work, though, because of
4264 the conversion from iterator to const_iterator.
4265 </p>
4266
4267 <p>
4268 I don't see a requirement anywhere in the standard that this must
4269 work. Should there be one?  If so, I think the requirement would need
4270 to be added to the tables in section 24.1.1. I'm not sure about the
4271 wording.  If this requirement existed in the standard, I would think
4272 that implementors would have to make the comparison operators
4273 non-member functions.</p>
4274
4275 <p>This issues was also raised on comp.std.c++ by Darin
4276 Adler.&nbsp; The example given was:</p>
4277
4278 <blockquote>
4279   <pre>bool check_equal(std::deque&lt;int&gt;::iterator i,
4280 std::deque&lt;int&gt;::const_iterator ci)
4281 {
4282 return i == ci;
4283 }</pre>
4284 </blockquote>
4285
4286 <p>Comment from John Potter:</p>
4287 <blockquote>
4288     <p>
4289     In case nobody has noticed, accepting it will break reverse_iterator.
4290     </p>
4291
4292     <p>
4293     The fix is to make the comparison operators templated on two types.
4294     </p>
4295
4296     <pre>    template &lt;class Iterator1, class Iterator2&gt;
4297     bool operator== (reverse_iterator&lt;Iterator1&gt; const&amp; x,
4298                      reverse_iterator&lt;Iterator2&gt; const&amp; y);
4299     </pre>
4300
4301     <p>
4302     Obviously:  return x.base() == y.base();
4303     </p>
4304
4305     <p>
4306     Currently, no reverse_iterator to const_reverse_iterator compares are
4307     valid.
4308     </p>
4309
4310     <p>
4311     BTW, I think the issue is in support of bad code.  Compares should be
4312     between two iterators of the same type.  All std::algorithms require
4313     the begin and end iterators to be of the same type.
4314     </p>
4315 </blockquote>
4316 <p><b>Proposed resolution:</b></p>
4317 <p>Insert this paragraph after 23.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 7:</p>
4318 <blockquote>
4319   <p>In the expressions</p>
4320   <pre>    i == j
4321     i != j
4322     i &lt; j
4323     i &lt;= j
4324     i &gt;= j
4325     i &gt; j
4326     i - j
4327   </pre>
4328   <p>Where i and j denote objects of a container's iterator type,
4329   either or both may be replaced by an object of the container's
4330   const_iterator type referring to the same element with no
4331   change in semantics.</p>
4332 </blockquote>
4333
4334 <p><i>[post-Toronto: Judy supplied a proposed resolution saying that
4335 <tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
4336 iterator comparison and difference operations.]</i></p>
4337
4338 <p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
4339 explicitly listed expressions; there was concern that the previous
4340 proposed resolution was too informal.]</i></p>
4341 <p><b>Rationale:</b></p>
4342 <p>
4343 The LWG believes it is clear that the above wording applies only to
4344 the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
4345 where <tt>X</tt> is a container.  There is no requirement that
4346 <tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
4347 can be mixed.  If mixing them is considered important, that's a
4348 separate issue.  (Issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#280">280</a>.)
4349 </p>
4350 <hr>
4351 <a name="181"><h3>181.&nbsp;make_pair() unintended behavior</h3></a><p>
4352 <b>Section:</b>&nbsp;20.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;3 Aug 1999</p>
4353 <p>The claim has surfaced in Usenet that expressions such as<br>
4354 <br>
4355 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>make_pair("abc", 3)</tt><br>
4356 <br>
4357 are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
4358 parameter to <tt> const char (&amp;)[4]</tt>, which type is uncopyable.<br>
4359 <br>
4360 I doubt anyone intended that behavior...
4361 </p>
4362 <p><b>Proposed resolution:</b></p>
4363 <p>In 20.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.utility"> [lib.utility]</a>, paragraph 1 change the following
4364 declaration of make_pair():</p>
4365 <blockquote>
4366   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(const T1&amp;, const T2&amp;);</pre>
4367 </blockquote>
4368 <p>to:</p>
4369 <blockquote>
4370   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(T1, T2);</pre>
4371 </blockquote>
4372 <p>  In 20.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a> paragraph 7 and the line before, change:</p>
4373 <blockquote>
4374 <pre>template &lt;class T1, class T2&gt;
4375 pair&lt;T1, T2&gt; make_pair(const T1&amp; x, const T2&amp; y);</pre>
4376 </blockquote>
4377 <p>to:</p>
4378 <blockquote>
4379 <pre>template &lt;class T1, class T2&gt;
4380 pair&lt;T1, T2&gt; make_pair(T1 x, T2 y);</pre>
4381 </blockquote>
4382 <p>and add the following footnote to the effects clause:</p>
4383 <blockquote>
4384   <p> According to 12.8 [class.copy], an implementation is permitted
4385   to not perform a copy of an argument, thus avoiding unnecessary
4386   copies.</p>
4387 </blockquote>
4388 <p><b>Rationale:</b></p>
4389 <p>Two potential fixes were suggested by Matt Austern and Dietmar
4390 Kühl, respectively, 1) overloading with array arguments, and 2) use of
4391 a reference_traits class with a specialization for arrays.  Andy
4392 Koenig suggested changing to pass by value. In discussion, it appeared
4393 that this was a much smaller change to the standard that the other two
4394 suggestions, and any efficiency concerns were more than offset by the
4395 advantages of the solution. Two implementors reported that the
4396 proposed resolution passed their test suites.</p>
4397 <hr>
4398 <a name="182"><h3>182.&nbsp;Ambiguous references to size_t</h3></a><p>
4399 <b>Section:</b>&nbsp;17 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Al Stevens&nbsp; <b>Date:</b>&nbsp;15 Aug 1999</p>
4400 <p>Many references to <tt> size_t</tt> throughout the document
4401 omit the <tt> std::</tt> namespace qualification.</p> <p>For
4402 example, 17.4.3.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2:</p>
4403 <blockquote>
4404 <pre>&#8212; operator new(size_t)
4405 &#8212; operator new(size_t, const std::nothrow_t&amp;)
4406 &#8212; operator new[](size_t)
4407 &#8212; operator new[](size_t, const std::nothrow_t&amp;)</pre>
4408 </blockquote>
4409 <p><b>Proposed resolution:</b></p>
4410 <p>   In 17.4.3.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2: replace:</p>
4411 <blockquote>
4412 <p><tt>     - operator new(size_t)<br>
4413      - operator new(size_t, const std::nothrow_t&amp;)<br>
4414      - operator new[](size_t)<br>
4415      - operator new[](size_t, const std::nothrow_t&amp;)</tt></p>
4416 </blockquote>
4417 <p>    by:</p>
4418 <blockquote>
4419 <pre>- operator new(std::size_t)
4420 - operator new(std::size_t, const std::nothrow_t&amp;)
4421 - operator new[](std::size_t)
4422 - operator new[](std::size_t, const std::nothrow_t&amp;)</pre>
4423 </blockquote>
4424 <p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
4425 <blockquote>
4426   <p>The typedef members pointer, const_pointer, size_type, and difference_type
4427   are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
4428 </blockquote>
4429 <p>&nbsp;by:</p>
4430 <blockquote>
4431   <p>The typedef members pointer, const_pointer, size_type, and difference_type
4432   are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
4433   respectively.</p>
4434 </blockquote>
4435 <p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
4436 <blockquote>
4437   <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
4438   <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
4439   is unspecified when or how often this function is called. The use of hint is
4440   unspecified, but intended as an aid to locality if an implementation so
4441   desires.</p>
4442 </blockquote>
4443 <p>by:</p>
4444 <blockquote>
4445   <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
4446   <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
4447   it is unspecified when or how often this function is called. The use of hint
4448   is unspecified, but intended as an aid to locality if an implementation so
4449   desires.</p>
4450 </blockquote>
4451 <p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
4452 <blockquote>
4453   <p>In Table 37, X denotes a Traits class defining types and functions for the
4454   character container type CharT; c and d denote values of type CharT; p and q
4455   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
4456   j denote values of type size_t; e and f denote values of type X::int_type; pos
4457   denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
4458 </blockquote>
4459 <p>by:</p>
4460 <blockquote>
4461   <p>In Table 37, X denotes a Traits class defining types and functions for the
4462   character container type CharT; c and d denote values of type CharT; p and q
4463   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
4464   j denote values of type std::size_t; e and f denote values of type X::int_type;
4465   pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
4466 </blockquote>
4467 <p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
4468 X::length(p): "size_t" by "std::size_t".</p>
4469 <p>   In [lib.std.iterator.tags] 24.3.3, paragraph 2:    replace:<br>
4470 &nbsp;&nbsp;&nbsp; typedef ptrdiff_t difference_type;<br>
4471     by:<br>
4472 &nbsp;&nbsp;&nbsp; typedef std::ptrdiff_t difference_type;</p>
4473 <p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the
4474 declaration of template &lt;class charT&gt; class ctype.<br>
4475 <br>
4476    In [lib.iterator.traits] 24.3.1, paragraph 2    put namespace std { ...} around the declaration of:<br>
4477 <br>
4478 &nbsp;&nbsp;&nbsp; template&lt;class Iterator&gt; struct iterator_traits<br>
4479 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;T*&gt;<br>
4480 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;const T*&gt;</p>
4481 <p><b>Rationale:</b></p>
4482 <p>The LWG believes correcting names like <tt>size_t</tt> and
4483 <tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
4484 to be essentially editorial.  There there can't be another size_t or
4485 ptrdiff_t meant anyway because, according to 17.4.3.1.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.extern.types"> [lib.extern.types]</a>,</p>
4486
4487 <blockquote>
4488 For each type T from the Standard C library, the types ::T and std::T
4489 are reserved to the implementation and, when defined, ::T shall be
4490 identical to std::T.
4491 </blockquote>
4492
4493 <p>The issue is treated as a Defect Report to make explicit the Project
4494 Editor's authority to make this change.</p>
4495
4496 <p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
4497 request of the LWG.]</i></p>
4498
4499 <p><i>[Toronto: This is tangentially related to issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>, but only tangentially: the intent of this issue is to
4500 address use of the name <tt>size_t</tt> in contexts outside of
4501 namespace std, such as in the description of <tt>::operator new</tt>.
4502 The proposed changes should be reviewed to make sure they are
4503 correct.]</i></p>
4504
4505 <p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
4506 them to be correct.]</i></p>
4507
4508 <hr>
4509 <a name="183"><h3>183.&nbsp;I/O stream manipulators don't work for wide character streams</h3></a><p>
4510 <b>Section:</b>&nbsp;27.6.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;7 Jul 1999</p>
4511 <p>27.6.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> paragraph 3 says (clause numbering added for
4512 exposition):</p>
4513 <blockquote>
4514 <p>Returns: An object s of unspecified type such that if [1] out is an (instance
4515 of) basic_ostream then the expression out&lt;&lt;s behaves as if f(s) were
4516 called, and if [2] in is an (instance of) basic_istream then the expression
4517 in&gt;&gt;s behaves as if f(s) were called. Where f can be defined as: ios_base&amp;
4518 f(ios_base&amp; str, ios_base::fmtflags mask) { // reset specified flags
4519 str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
4520 out&lt;&lt;s has type ostream&amp; and value out. [4] The expression in&gt;&gt;s
4521 has type istream&amp; and value in.</p>
4522 </blockquote>
4523 <p>Given the definitions [1] and [2] for out and in, surely [3] should read:
4524 "The expression out &lt;&lt; s has type basic_ostream&amp; ..." and
4525 [4] should read: "The expression in &gt;&gt; s has type basic_istream&amp;
4526 ..."</p>
4527 <p>If the wording in the standard is correct, I can see no way of implementing
4528 any of the manipulators so that they will work with wide character streams.</p>
4529 <p>e.g. wcout &lt;&lt; setbase( 16 );</p>
4530 <p>Must have value 'wcout' (which makes sense) and type 'ostream&amp;' (which
4531 doesn't).</p>
4532 <p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
4533 8. In addition, Para 6 [setfill] has a similar error, but relates only to
4534 ostreams.</p>
4535 <p>I'd be happier if there was a better way of saying this, to make it clear
4536 that the value of the expression is "the same specialization of
4537 basic_ostream as out"&amp;</p>
4538 <p><b>Proposed resolution:</b></p>
4539 <p>Replace section 27.6.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> except paragraph 1 with the
4540 following:</p>
4541 <blockquote>
4542 <p>2- The type designated smanip in each of the following function
4543 descriptions is implementation-specified and may be different for each
4544 function.<br>
4545 <br>
4546 <tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
4547 <br>
4548 -3- Returns: An object s of unspecified type such that if out is an
4549 instance of basic_ostream&lt;charT,traits&gt; then the expression
4550 out&lt;&lt;s behaves
4551 as if f(s, mask) were called, or if in is an instance of
4552 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
4553 behaves as if
4554 f(s, mask) were called. The function f can be defined as:*<br>
4555 <br>
4556 [Footnote: The expression cin &gt;&gt; resetiosflags(ios_base::skipws)
4557 clears ios_base::skipws in the format flags stored in the
4558 basic_istream&lt;charT,traits&gt; object cin (the same as cin &gt;&gt;
4559 noskipws), and the expression cout &lt;&lt;
4560 resetiosflags(ios_base::showbase) clears
4561 ios_base::showbase in the format flags stored in the
4562 basic_ostream&lt;charT,traits&gt; object cout (the same as cout
4563 &lt;&lt;
4564 noshowbase). --- end footnote]<br>
4565 <br>
4566 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
4567 &nbsp;&nbsp; {<br>
4568 &nbsp;&nbsp; //  reset specified flags<br>
4569 &nbsp;&nbsp; str.setf(ios_base::fmtflags(0), mask);<br>
4570 &nbsp;&nbsp; return str;<br>
4571 &nbsp;&nbsp; }<br>
4572 </tt><br>
4573 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
4574 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
4575 <br>
4576 &nbsp;<tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
4577 <br>
4578 -4- Returns: An object s of unspecified type such that if out is an
4579 instance of basic_ostream&lt;charT,traits&gt; then the expression
4580 out&lt;&lt;s behaves
4581 as if f(s, mask) were called, or if in is an instance of
4582 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
4583 behaves as if f(s,
4584 mask) were called. The function f can be defined as:<br>
4585 <br>
4586 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
4587 &nbsp;&nbsp; {<br>
4588 &nbsp;&nbsp; //  set specified flags<br>
4589 &nbsp;&nbsp; str.setf(mask);<br>
4590 &nbsp;&nbsp; return str;<br>
4591 &nbsp;&nbsp; }<br>
4592 </tt><br>
4593 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
4594 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
4595 <br>
4596 <tt>smanip setbase(int base);</tt><br>
4597 <br>
4598 -5- Returns: An object s of unspecified type such that if out is an
4599 instance of basic_ostream&lt;charT,traits&gt; then the expression
4600 out&lt;&lt;s behaves
4601 as if f(s, base) were called, or if in is an instance of
4602 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
4603 behaves as if f(s,
4604 base) were called. The function f can be defined as:<br>
4605 <br>
4606 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int base)<br>
4607 &nbsp;&nbsp; {<br>
4608 &nbsp;&nbsp; //  set  basefield<br>
4609 &nbsp;&nbsp; str.setf(base ==  8 ? ios_base::oct :<br>
4610 &nbsp;&nbsp; base == 10 ? ios_base::dec :<br>
4611 &nbsp;&nbsp; base == 16 ? ios_base::hex :<br>
4612 &nbsp;&nbsp; ios_base::fmtflags(0), ios_base::basefield);<br>
4613 &nbsp;&nbsp; return str;<br>
4614 &nbsp;&nbsp; }<br>
4615 </tt><br>
4616 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
4617 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
4618 <br>
4619 <tt>smanip setfill(char_type c);<br>
4620 </tt><br>
4621 -6- Returns: An object s of unspecified type such that if out is (or is
4622 derived from) basic_ostream&lt;charT,traits&gt; and c has type charT
4623 then the
4624 expression out&lt;&lt;s behaves as if f(s, c) were called. The function
4625 f can be
4626 defined as:<br>
4627 <br>
4628 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>template&lt;class charT, class traits&gt;<br>
4629 &nbsp;&nbsp; basic_ios&lt;charT,traits&gt;&amp; f(basic_ios&lt;charT,traits&gt;&amp; str, charT c)<br>
4630 &nbsp;&nbsp; {<br>
4631 &nbsp;&nbsp; //  set fill character<br>
4632 &nbsp;&nbsp; str.fill(c);<br>
4633 &nbsp;&nbsp; return str;<br>
4634 &nbsp;&nbsp; }<br>
4635 </tt><br>
4636 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.<br>
4637 <br>
4638 <tt>smanip setprecision(int n);</tt><br>
4639 <br>
4640 -7- Returns: An object s of unspecified type such that if out is an
4641 instance of basic_ostream&lt;charT,traits&gt; then the expression
4642 out&lt;&lt;s behaves
4643 as if f(s, n) were called, or if in is an instance of
4644 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
4645 behaves as if f(s, n)
4646 were called. The function f can be defined as:<br>
4647 <br>
4648 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
4649 &nbsp;&nbsp; {<br>
4650 &nbsp;&nbsp; //  set precision<br>
4651 &nbsp;&nbsp; str.precision(n);<br>
4652 &nbsp;&nbsp; return str;<br>
4653 &nbsp;&nbsp; }<br>
4654 </tt><br>
4655 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
4656 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in<br>
4657 .<br>
4658 <tt>smanip setw(int n);<br>
4659 </tt><br>
4660 -8- Returns: An object s of unspecified type such that if out is an
4661 instance of basic_ostream&lt;charT,traits&gt; then the expression
4662 out&lt;&lt;s behaves
4663 as if f(s, n) were called, or if in is an instance of
4664 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
4665 behaves as if f(s, n)
4666 were called. The function f can be defined as:<br>
4667 <br>
4668 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
4669 &nbsp;&nbsp; {<br>
4670 &nbsp;&nbsp; //  set width<br>
4671 &nbsp;&nbsp; str.width(n);<br>
4672 &nbsp;&nbsp; return str;<br>
4673 &nbsp;&nbsp; }<br>
4674 </tt><br>
4675 The expression out&lt;&lt;s has type
4676 basic_ostream&lt;charT,traits&gt;&amp; and value out.  The expression
4677 in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value
4678 in.
4679 </p>
4680 </blockquote>
4681
4682 <p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
4683 the proposed resolution.]</i></p>
4684
4685 <p><i>[Tokyo - The LWG noted that issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> involves
4686 the same paragraphs.]</i></p>
4687
4688 <p><i>[Post-Tokyo: The issues list maintainer combined the proposed
4689 resolution of this issue with the proposed resolution for issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> as they both involved the same paragraphs, and were so
4690 intertwined that dealing with them separately appear fraught with
4691 error.  The full text was supplied by Bill Plauger; it was cross
4692 checked against changes supplied by Andy Sawyer. It should be further
4693 checked by the LWG.]</i></p>
4694 <hr>
4695 <a name="184"><h3>184.&nbsp;numeric_limits&lt;bool&gt; wording problems</h3></a><p>
4696 <b>Section:</b>&nbsp;18.2.1.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.special"> [lib.numeric.special]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Gabriel Dos Reis&nbsp; <b>Date:</b>&nbsp;21 Jul 1999</p>
4697 <p>bools are defined by the standard to be of integer types, as per
4698 3.9.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/basic.html#basic.fundamental"> [basic.fundamental]</a> paragraph 7.  However "integer types"
4699 seems to have a special meaning for the author of 18.2. The net effect
4700 is an unclear and confusing specification for
4701 numeric_limits&lt;bool&gt; as evidenced below.</p>
4702
4703 <p>18.2.1.2/7 says numeric_limits&lt;&gt;::digits is, for built-in integer
4704 types, the number of non-sign bits in the representation.</p>
4705
4706 <p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
4707 arithmetical value converts to true.</p>
4708
4709 <p>I don't think it makes sense at all to require
4710 numeric_limits&lt;bool&gt;::digits and numeric_limits&lt;bool&gt;::digits10 to
4711 be meaningful.</p>
4712
4713 <p>The standard defines what constitutes a signed (resp. unsigned) integer
4714 types. It doesn't categorize bool as being signed or unsigned. And the set of
4715 values of bool type has only two elements.</p>
4716
4717 <p>I don't think it makes sense to require numeric_limits&lt;bool&gt;::is_signed
4718 to be meaningful.</p>
4719
4720 <p>18.2.1.2/18 for numeric_limits&lt;integer_type&gt;::radix&nbsp; says:</p>
4721 <blockquote>
4722   <p>For integer types, specifies the base of the representation.186)</p>
4723 </blockquote>
4724
4725 <p>This disposition is at best misleading and confusing for the standard
4726 requires a "pure binary numeration system" for integer types as per
4727 3.9.1/7</p>
4728
4729 <p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
4730 BCD)."&nbsp; This also erroneous as the standard never defines any integer
4731 types with base representation other than 2.</p>
4732
4733 <p>Furthermore, numeric_limits&lt;bool&gt;::is_modulo and
4734 numeric_limits&lt;bool&gt;::is_signed have similar problems.</p>
4735 <p><b>Proposed resolution:</b></p>
4736 <p>Append to the end of 18.2.1.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.special"> [lib.numeric.special]</a>:</p>
4737 <blockquote>
4738   <p>The specialization for bool shall be provided as follows:</p>
4739   <pre>    namespace std {
4740        template&lt;&gt; class numeric_limits&lt;bool&gt; {
4741        public:
4742          static const bool is_specialized = true;
4743          static bool min() throw() { return false; }
4744          static bool max() throw() { return true; }
4745
4746          static const int  digits = 1;
4747          static const int  digits10 = 0;
4748          static const bool is_signed = false;
4749          static const bool is_integer = true;
4750          static const bool is_exact = true;
4751          static const int  radix = 2;
4752          static bool epsilon() throw() { return 0; }
4753          static bool round_error() throw() { return 0; }
4754
4755          static const int  min_exponent = 0;
4756          static const int  min_exponent10 = 0;
4757          static const int  max_exponent = 0;
4758          static const int  max_exponent10 = 0;
4759
4760          static const bool has_infinity = false;
4761          static const bool has_quiet_NaN = false;
4762          static const bool has_signaling_NaN = false;
4763          static const float_denorm_style has_denorm = denorm_absent;
4764          static const bool has_denorm_loss = false;
4765          static bool infinity() throw() { return 0; }
4766          static bool quiet_NaN() throw() { return 0; }
4767          static bool signaling_NaN() throw() { return 0; }
4768          static bool denorm_min() throw() { return 0; }
4769
4770          static const bool is_iec559 = false;
4771          static const bool is_bounded = true;
4772          static const bool is_modulo = false;
4773
4774          static const bool traps = false;
4775          static const bool tinyness_before = false;
4776          static const float_round_style round_style = round_toward_zero;
4777        };
4778      }</pre>
4779 </blockquote>
4780
4781 <p><i>[Tokyo:&nbsp; The LWG desires wording that specifies exact values
4782 rather than more general wording in the original proposed
4783 resolution.]</i></p>
4784
4785 <p><i>[Post-Tokyo:&nbsp; At the request of the LWG in Tokyo, Nico
4786 Josuttis provided the above wording.]</i></p>
4787 <hr>
4788 <a name="185"><h3>185.&nbsp;Questionable use of term "inline"</h3></a><p>
4789 <b>Section:</b>&nbsp;20.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;UK Panel&nbsp; <b>Date:</b>&nbsp;26 Jul 1999</p>
4790 <p>Paragraph 4 of 20.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> says:</p>
4791 <blockquote>
4792   <p>&nbsp;[Example: To negate every element of a: transform(a.begin(), a.end(),
4793   a.begin(), negate&lt;double&gt;()); The corresponding functions will inline
4794   the addition and the negation. end example]</p>
4795 </blockquote>
4796 <p>(Note: The "addition" referred to in the above is in para 3) we can
4797 find no other wording, except this (non-normative) example which suggests that
4798 any "inlining" will take place in this case.</p>
4799 <p>Indeed both:</p>
4800 <blockquote>
4801   <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
4802   unspecified whether any global functions in the C++ Standard Library
4803   are defined as inline (7.1.2).</p>
4804 </blockquote>
4805 <p>and</p>
4806 <blockquote>
4807   <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
4808   unspecified whether any member functions in the C++ Standard Library
4809   are defined as inline (7.1.2).</p>
4810 </blockquote>
4811 <p>take care to state that this may indeed NOT be the case.</p>
4812 <p>Thus the example "mandates" behavior that is explicitly
4813 not required elsewhere.</p>
4814 <p><b>Proposed resolution:</b></p>
4815 <p>In 20.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 1, remove the sentence:</p>
4816 <blockquote>
4817 <p>They are important for the effective use of the library.</p>
4818 </blockquote>
4819 <p>Remove 20.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 2, which reads:</p>
4820 <blockquote>
4821   <p> Using function objects together with function templates
4822   increases the expressive power of the library as well as making the
4823   resulting code much more efficient.</p>
4824 </blockquote>
4825 <p>In 20.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 4, remove the sentence:</p>
4826 <blockquote>
4827   <p>The corresponding functions will inline the addition and the
4828   negation.</p>
4829 </blockquote>
4830
4831 <p><i>[Kona: The LWG agreed there was a defect.]</i></p>
4832 <p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
4833 <hr>
4834 <a name="186"><h3>186.&nbsp;bitset::set() second parameter should be bool</h3></a><p>
4835 <b>Section:</b>&nbsp;23.3.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Darin Adler&nbsp; <b>Date:</b>&nbsp;13 Aug 1999</p>
4836 <p>In section 23.3.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>, paragraph 13 defines the
4837 bitset::set operation to take a second parameter of type int. The
4838 function tests whether this value is non-zero to determine whether to
4839 set the bit to true or false. The type of this second parameter should
4840 be bool. For one thing, the intent is to specify a Boolean value. For
4841 another, the result type from test() is bool. In addition, it's
4842 possible to slice an integer that's larger than an int. This can't
4843 happen with bool, since conversion to bool has the semantic of
4844 translating 0 to false and any non-zero value to true.</p>
4845 <p><b>Proposed resolution:</b></p>
4846 <p>In 23.3.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> Para 1 Replace:</p>
4847 <blockquote>
4848 <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = true ); </pre>
4849 </blockquote>
4850 <p>With:</p>
4851 <blockquote>
4852   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
4853 </blockquote>
4854 <p>In 23.3.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> Para 12(.5) Replace:</p>
4855 <blockquote>
4856   <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = 1 );</pre>
4857 </blockquote>
4858 <p>With:</p>
4859 <blockquote>
4860   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
4861 </blockquote>
4862
4863 <p><i>[Kona: The LWG agrees with the description.&nbsp; Andy Sawyer will work
4864 on better P/R wording.]</i></p>
4865 <p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
4866 <p><b>Rationale:</b></p>
4867 <p>
4868 <tt>bool</tt> is a better choice.  It is believed that binary
4869 compatibility is not an issue, because this member function is
4870 usually implemented as <tt>inline</tt>, and because it is already
4871 the case that users cannot rely on the type of a pointer to a
4872 nonvirtual member of a standard library class.</p>
4873 <hr>
4874 <a name="187"><h3>187.&nbsp;iter_swap underspecified</h3></a><p>
4875 <b>Section:</b>&nbsp;25.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;14 Aug 1999</p>
4876 <p>The description of iter_swap in 25.2.2 paragraph 7,says that it
4877 ``exchanges the values'' of the objects to which two iterators
4878 refer.<br> <br> What it doesn't say is whether it does so using swap
4879 or using the assignment operator and copy constructor.<br> <br> This
4880 question is an important one to answer, because swap is specialized to
4881 work efficiently for standard containers.<br> For example:</p>
4882 <blockquote>
4883 <pre>vector&lt;int&gt; v1, v2;
4884 iter_swap(&amp;v1, &amp;v2);</pre>
4885 </blockquote>
4886 <p>Is this call to iter_swap equivalent to calling swap(v1, v2)?&nbsp;
4887 Or is it equivalent to</p>
4888 <blockquote>
4889 <pre>{
4890 vector&lt;int&gt; temp = v1;
4891 v1 = v2;
4892 v2 = temp;
4893 }</pre>
4894 </blockquote>
4895 <p>The first alternative is O(1); the second is O(n).</p>
4896 <p>A LWG member, Dave Abrahams, comments:</p>
4897 <blockquote>
4898 <p>Not an objection necessarily, but I want to point out the cost of
4899 that requirement:</p>
4900   <blockquote>
4901 <p><tt>iter_swap(list&lt;T&gt;::iterator, list&lt;T&gt;::iterator)</tt></p>
4902   </blockquote>
4903 <p>can currently be specialized to be more efficient than
4904 iter_swap(T*,T*) for many T (by using splicing). Your proposal would
4905 make that optimization illegal.&nbsp;</p>
4906 </blockquote>
4907
4908 <p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
4909 which are no longer permitted.]</i></p>
4910 <p><b>Proposed resolution:</b></p>
4911 <p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
4912 <blockquote>
4913 <p>Exchanges the values pointed to by the two iterators a and b.</p>
4914 </blockquote>
4915 <p>to</p>
4916 <blockquote>
4917 <p>
4918 <tt>swap(*a, *b)</tt>.</p>
4919 </blockquote>
4920
4921 <p><b>Rationale:</b></p>
4922 <p>It's useful to say just what <tt>iter_swap</tt> does.  There may be
4923   some iterators for which we want to specialize <tt>iter_swap</tt>,
4924   but the fully general version should have a general specification.</p>
4925
4926 <p>Note that in the specific case of <tt>list&lt;T&gt;::iterator</tt>,
4927 iter_swap should not be specialized as suggested above.  That would do
4928 much more than exchanging the two iterators' values: it would change
4929 predecessor/successor relationships, possibly moving the iterator from
4930 one list to another.  That would surely be inappropriate.</p>
4931 <hr>
4932 <a name="189"><h3>189.&nbsp;setprecision() not specified correctly</h3></a><p>
4933 <b>Section:</b>&nbsp;27.4.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;25 Aug 1999</p>
4934 <p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
4935 and includes a parenthetical note saying that it is the number of
4936 digits after the decimal point.<br>
4937 <br>
4938 This claim is not strictly correct.  For example, in the default
4939 floating-point output format, setprecision sets the number of
4940 significant digits printed, not the number of digits after the decimal
4941 point.<br>
4942 <br>
4943 I would like the committee to look at the definition carefully and
4944 correct the statement in 27.4.2.2</p>
4945 <p><b>Proposed resolution:</b></p>
4946 <p>Remove from 27.4.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a>, paragraph 9, the text
4947 "(number of digits after the decimal point)".</p>
4948 <hr>
4949 <a name="193"><h3>193.&nbsp;Heap operations description incorrect</h3></a><p>
4950 <b>Section:</b>&nbsp;25.3.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;24 Sep 1999</p>
4951 <p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
4952 is<br>
4953 <br>
4954 &nbsp;&nbsp;&nbsp; `"(1) *a is the largest element"<br>
4955 <br>
4956 I think this is incorrect and should be changed to the wording in the proposed
4957 resolution.</p>
4958 <p>Actually there are two independent changes:</p>
4959 <blockquote>
4960   <p>A-"part of largest equivalence class" instead of "largest", cause 25.3
4961   [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
4962   <p>B-Take
4963 'an oldest' from that equivalence class, otherwise the heap functions
4964 could not be used for a priority queue as explained in 23.2.3.2.2
4965 [lib.priqueue.members] (where I assume that a "priority queue" respects
4966 priority AND time).</p>
4967 </blockquote>
4968 <p><b>Proposed resolution:</b></p>
4969 <p>Change 25.3.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a> property (1) from:</p>
4970 <blockquote>
4971   <p>(1) *a is the largest element</p>
4972 </blockquote>
4973 <p>to:</p>
4974 <blockquote>
4975   <p>(1) There is no element greater than <tt>*a</tt>
4976 </p>
4977 </blockquote>
4978 <hr>
4979 <a name="195"><h3>195.&nbsp;Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3></a><p>
4980 <b>Section:</b>&nbsp;27.6.1.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;13 Oct 1999</p>
4981 <p>Suppose that <tt>is.flags() &amp; ios_base::skipws</tt> is nonzero.
4982 What should <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor do if it
4983 reaches eof while skipping whitespace?  27.6.1.1.2/5 suggests it
4984 should set failbit. Should it set eofbit as well?  The standard
4985 doesn't seem to answer that question.</p>
4986
4987 <p>On the one hand, nothing in 27.6.1.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> says that
4988 <tt>basic_istream&lt;&gt;::sentry</tt> should ever set eofbit.  On the
4989 other hand, 27.6.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a> paragraph 4 says that if
4990 extraction from a <tt>streambuf</tt> "returns
4991 <tt>traits::eof()</tt>, then the input function, except as explicitly
4992 noted otherwise, completes its actions and does
4993 <tt>setstate(eofbit)"</tt>.  So the question comes down to
4994 whether <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor is an
4995 input function.</p>
4996
4997 <p>Comments from Jerry Schwarz:</p>
4998 <blockquote>
4999 <p>It was always my intention that eofbit should be set any time that a
5000 virtual returned something to indicate eof, no matter what reason
5001 iostream code had for calling the virtual.</p>
5002 <p>
5003 The motivation for this is that I did not want to require streambufs
5004 to behave consistently if their virtuals are called after they have
5005 signaled eof.</p>
5006 <p>
5007 The classic case is a streambuf reading from a UNIX file.  EOF isn't
5008 really a state for UNIX file descriptors.  The convention is that a
5009 read on UNIX returns 0 bytes to indicate "EOF", but the file
5010 descriptor isn't shut down in any way and future reads do not
5011 necessarily also return 0 bytes.  In particular, you can read from
5012 tty's on UNIX even after they have signaled "EOF".  (It
5013 isn't always understood that a ^D on UNIX is not an EOF indicator, but
5014 an EOL indicator.  By typing a "line" consisting solely of
5015 ^D you cause a read to return 0 bytes, and by convention this is
5016 interpreted as end of file.)</p>
5017 </blockquote>
5018 <p><b>Proposed resolution:</b></p>
5019 <p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
5020 <blockquote>
5021 <p>If <tt>is.rdbuf()-&gt;sbumpc()</tt> or <tt>is.rdbuf()-&gt;sgetc()</tt>
5022 returns <tt>traits::eof()</tt>, the function calls
5023 <tt>setstate(failbit | eofbit)</tt> (which may throw
5024 <tt>ios_base::failure</tt>).
5025 </p>
5026 </blockquote>
5027 <hr>
5028 <a name="198"><h3>198.&nbsp;Validity of pointers and references unspecified after iterator destruction</h3></a><p>
5029 <b>Section:</b>&nbsp;24.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;3 Nov 1999</p>
5030 <p>
5031 Is a pointer or reference obtained from an iterator still valid after
5032 destruction of the iterator?
5033 </p>
5034 <p>
5035 Is a pointer or reference obtained from an iterator still valid after the value
5036 of the iterator changes?
5037 </p>
5038 <blockquote>
5039 <pre>#include &lt;iostream&gt;
5040 #include &lt;vector&gt;
5041 #include &lt;iterator&gt;
5042
5043 int main()
5044 {
5045     typedef std::vector&lt;int&gt; vec_t;
5046     vec_t v;
5047     v.push_back( 1 );
5048
5049     // Is a pointer or reference obtained from an iterator still
5050     // valid after destruction of the iterator?
5051     int * p = &amp;*v.begin();
5052     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
5053
5054     // Is a pointer or reference obtained from an iterator still
5055     // valid after the value of the iterator changes?
5056     vec_t::iterator iter( v.begin() );
5057     p = &amp;*iter++;
5058     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
5059
5060     return 0;
5061 }
5062 </pre>
5063 </blockquote>
5064
5065 <p>The standard doesn't appear to directly address these
5066 questions. The standard needs to be clarified. At least two real-world
5067 cases have been reported where library implementors wasted
5068 considerable effort because of the lack of clarity in the
5069 standard. The question is important because requiring pointers and
5070 references to remain valid has the effect for practical purposes of
5071 prohibiting iterators from pointing to cached rather than actual
5072 elements of containers.</p>
5073
5074 <p>The standard itself assumes that pointers and references obtained
5075 from an iterator are still valid after iterator destruction or
5076 change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a>, which returns a reference, defines
5077 effects:</p>
5078
5079 <blockquote>
5080   <pre>Iterator tmp = current;
5081 return *--tmp;</pre>
5082 </blockquote>
5083 <p>The definition of reverse_iterator::operator-&gt;(), 24.4.1.3.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.opref"> [lib.reverse.iter.opref]</a>, which returns a pointer, defines effects:</p>
5084 <blockquote>
5085   <pre>return &amp;(operator*());</pre>
5086 </blockquote>
5087
5088 <p>Because the standard itself assumes pointers and references remain
5089 valid after iterator destruction or change, the standard should say so
5090 explicitly. This will also reduce the chance of user code breaking
5091 unexpectedly when porting to a different standard library
5092 implementation.</p>
5093 <p><b>Proposed resolution:</b></p>
5094 <p>Add a new paragraph to 24.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>:</p>
5095 <blockquote>
5096 Destruction of an iterator may invalidate pointers and references
5097 previously obtained from that iterator.
5098 </blockquote>
5099
5100 <p>Replace paragraph 1 of 24.4.1.3.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a> with:</p>
5101
5102 <blockquote>
5103 <p><b>Effects:</b></p>
5104 <pre>  this-&gt;tmp = current;
5105   --this-&gt;tmp;
5106   return *this-&gt;tmp;
5107 </pre>
5108
5109 <p>
5110 [<i>Note:</i> This operation must use an auxiliary member variable,
5111 rather than a temporary variable, to avoid returning a reference that
5112 persists beyond the lifetime of its associated iterator.  (See
5113 24.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>.)  The name of this member variable is shown for
5114 exposition only.  <i>--end note</i>]
5115 </p>
5116 </blockquote>
5117
5118 <p><i>[Post-Tokyo: The issue has been reformulated purely
5119 in terms of iterators.]</i></p>
5120
5121 <p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
5122 assumption by reverse_iterator. The issue and proposed resolution was
5123 reformulated yet again to reflect this reality.]</i></p>
5124
5125 <p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
5126 assumes its underlying iterator has persistent pointers and
5127 references.  Andy Koenig pointed out that it is possible to rewrite
5128 reverse_iterator so that it no longer makes such an assupmption.
5129 However, this issue is related to issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>.  If we
5130 decide it is intentional that <tt>p[n]</tt> may return by value
5131 instead of reference when <tt>p</tt> is a Random Access Iterator,
5132 other changes in reverse_iterator will be necessary.]</i></p>
5133 <p><b>Rationale:</b></p>
5134 <p>This issue has been discussed extensively.  Note that it is
5135 <i>not</i> an issue about the behavior of predefined iterators.  It is
5136 asking whether or not user-defined iterators are permitted to have
5137 transient pointers and references.  Several people presented examples
5138 of useful user-defined iterators that have such a property; examples
5139 include a B-tree iterator, and an "iota iterator" that doesn't point
5140 to memory.  Library implementors already seem to be able to cope with
5141 such iterators: they take pains to avoid forming references to memory
5142 that gets iterated past.  The only place where this is a problem is
5143 <tt>reverse_iterator</tt>, so this issue changes
5144 <tt>reverse_iterator</tt> to make it work.</p>
5145
5146 <p>This resolution does not weaken any guarantees provided by
5147 predefined iterators like <tt>list&lt;int&gt;::iterator</tt>.
5148 Clause 23 should be reviewed to make sure that guarantees for
5149 predefined iterators are as strong as users expect.</p>
5150
5151 <hr>
5152 <a name="199"><h3>199.&nbsp;What does <tt>allocate(0)</tt> return?</h3></a><p>
5153 <b>Section:</b>&nbsp;20.1.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Nov 1999</p>
5154 <p>
5155 Suppose that <tt>A</tt> is a class that conforms to the
5156 Allocator requirements of Table 32, and <tt>a</tt> is an
5157 object of class <tt>A</tt>  What should be the return
5158 value of <tt>a.allocate(0)</tt>?  Three reasonable
5159 possibilities: forbid the argument <tt>0</tt>, return
5160 a null pointer, or require that the return value be a
5161 unique non-null pointer.
5162 </p>
5163 <p><b>Proposed resolution:</b></p>
5164 <p>
5165 Add a note to the <tt>allocate</tt> row of Table 32:
5166 "[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
5167 <p><b>Rationale:</b></p>
5168 <p>A key to understanding this issue is that the ultimate use of
5169 allocate() is to construct an iterator, and that iterator for zero
5170 length sequences must be the container's past-the-end
5171 representation.  Since this already implies special case code, it
5172 would be over-specification to mandate the return value.
5173 </p>
5174 <hr>
5175 <a name="200"><h3>200.&nbsp;Forward iterator requirements don't allow constant iterators</h3></a><p>
5176 <b>Section:</b>&nbsp;24.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Nov 1999</p>
5177 <p>
5178 In table 74, the return type of the expression <tt>*a</tt> is given
5179 as <tt>T&amp;</tt>, where <tt>T</tt> is the iterator's value type.
5180 For constant iterators, however, this is wrong.  ("Value type"
5181 is never defined very precisely, but it is clear that the value type
5182 of, say, <tt>std::list&lt;int&gt;::const_iterator</tt> is supposed to be
5183 <tt>int</tt>, not <tt>const int</tt>.)
5184 </p>
5185 <p><b>Proposed resolution:</b></p>
5186 <p>
5187 In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
5188 return type from "<tt>T&amp;</tt>" to "<tt>T&amp;</tt>
5189 if <tt>X</tt> is mutable, otherwise <tt>const T&amp;</tt>".
5190 In the <tt>a-&gt;m</tt> row, change the return type from
5191 "<tt>U&amp;</tt>" to "<tt>U&amp;</tt> if <tt>X</tt> is mutable,
5192 otherwise <tt>const U&amp;</tt>".
5193 </p>
5194
5195 <p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
5196 there are multiple const problems with the STL portion of the library
5197 and that these should be addressed as a single package.&nbsp; Note
5198 that issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#180">180</a> has already been declared NAD Future for
5199 that very reason.]</i></p>
5200
5201 <p><i>[Redmond: the LWG thinks this is separable from other constness
5202 issues.  This issue is just cleanup; it clarifies language that was
5203 written before we had iterator_traits.  Proposed resolution was
5204 modified: the original version only discussed *a.  It was pointed out
5205 that we also need to worry about *r++ and a-&gt;m.]</i></p>
5206
5207 <hr>
5208 <a name="202"><h3>202.&nbsp;unique() effects unclear when predicate not an equivalence relation</h3></a><p>
5209 <b>Section:</b>&nbsp;25.2.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;13 Jan 2000</p>
5210 <p>
5211 What should unique() do if you give it a predicate that is not an
5212 equivalence relation?  There are at least two plausible answers:
5213 </p>
5214
5215 <blockquote>
5216
5217 <p>
5218    1. You can't, because 25.2.8 says that it it "eliminates all but
5219    the first element from every consecutive group of equal
5220    elements..." and it wouldn't make sense to interpret "equal" as
5221    meaning anything but an equivalence relation.  [It also doesn't
5222    make sense to interpret "equal" as meaning ==, because then there
5223    would never be any sense in giving a predicate as an argument at
5224    all.]
5225 </p>
5226
5227 <p>
5228    2. The word "equal" should be interpreted to mean whatever the
5229    predicate says, even if it is not an equivalence relation
5230    (and in particular, even if it is not transitive).
5231 </p>
5232
5233 </blockquote>
5234
5235 <p>
5236 The example that raised this question is from Usenet:
5237 </p>
5238
5239 <blockquote>
5240
5241 <pre>int f[] = { 1, 3, 7, 1, 2 };
5242 int* z = unique(f, f+5, greater&lt;int&gt;());</pre>
5243
5244 </blockquote>
5245
5246 <p>
5247 If one blindly applies the definition using the predicate
5248 greater&lt;int&gt;, and ignore the word "equal", you get:
5249 </p>
5250
5251 <blockquote>
5252
5253 <p>
5254     Eliminates all but the first element from every consecutive group
5255     of elements referred to by the iterator i in the range [first, last)
5256     for which *i &gt; *(i - 1).
5257 </p>
5258
5259 </blockquote>
5260
5261 <p>
5262 The first surprise is the order of the comparison.  If we wanted to
5263 allow for the predicate not being an equivalence relation, then we
5264 should surely compare elements the other way: pred(*(i - 1), *i).  If
5265 we do that, then the description would seem to say: "Break the
5266 sequence into subsequences whose elements are in strictly increasing
5267 order, and keep only the first element of each subsequence".  So the
5268 result would be 1, 1, 2.  If we take the description at its word, it
5269 would seem to call for strictly DEcreasing order, in which case the
5270 result should be 1, 3, 7, 2.<br>
5271 <br>
5272 In fact, the SGI implementation of unique() does neither: It yields 1,
5273 3, 7.
5274 </p>
5275 <p><b>Proposed resolution:</b></p>
5276 <p>Change 25.2.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> paragraph 1 to:</p>
5277 <blockquote>
5278 For a nonempty range, eliminates all but the first element from every
5279 consecutive group of equivalent elements referred to by the iterator
5280 <tt>i</tt> in the range [first+1, last) for which the following
5281 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
5282 false</tt>.
5283 </blockquote>
5284
5285 <p>
5286 Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
5287 comparison function must be an equivalence relation."
5288 </p>
5289
5290 <p><i>[Redmond: discussed arguments for and against requiring the
5291 comparison function to be an equivalence relation.  Straw poll:
5292 14-2-5.  First number is to require that it be an equivalence
5293 relation, second number is to explicitly not require that it be an
5294 equivalence relation, third number is people who believe they need
5295 more time to consider the issue.  A separate issue: Andy Sawyer
5296 pointed out that "i-1" is incorrect, since "i" can refer to the first
5297 iterator in the range.  Matt provided wording to address this
5298 problem.]</i></p>
5299
5300 <p><i>[Curaçao: The LWG changed "... the range (first,
5301 last)..." to "...  the range [first+1, last)..." for
5302 clarity. They considered this change close enough to editorial to not
5303 require another round of review.]</i></p>
5304
5305 <p><b>Rationale:</b></p>
5306 <p>The LWG also considered an alternative resolution: change
5307 25.2.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> paragraph 1 to:</p>
5308
5309 <blockquote>
5310 For a nonempty range, eliminates all but the first element from every
5311 consecutive group of elements referred to by the iterator
5312 <tt>i</tt> in the range (first, last) for which the following
5313 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
5314 false</tt>.
5315 </blockquote>
5316
5317 <p>
5318 Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
5319 comparison function need not be an equivalence relation."
5320 </p>
5321
5322
5323 <p>Informally: the proposed resolution imposes an explicit requirement
5324 that the comparison function be an equivalence relation.  The
5325 alternative resolution does not, and it gives enough information so
5326 that the behavior of unique() for a non-equivalence relation is
5327 specified.  Both resolutions are consistent with the behavior of
5328 existing implementations.</p>
5329 <hr>
5330 <a name="208"><h3>208.&nbsp;Unnecessary restriction on past-the-end iterators</h3></a><p>
5331 <b>Section:</b>&nbsp;24.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Stephen Cleary&nbsp; <b>Date:</b>&nbsp;02 Feb 2000</p>
5332 <p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
5333 past-the-end values are always non-singular."</p>
5334 <p>This places an unnecessary restriction on past-the-end iterators for
5335 containers with forward iterators (for example, a singly-linked list). If the
5336 past-the-end value on such a container was a well-known singular value, it would
5337 still satisfy all forward iterator requirements.</p>
5338 <p>Removing this restriction would allow, for example, a singly-linked list
5339 without a "footer" node.</p>
5340 <p>This would have an impact on existing code that expects past-the-end
5341 iterators obtained from different (generic) containers being not equal.</p>
5342 <p><b>Proposed resolution:</b></p>
5343 <p>Change 24.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> paragraph 5, the last sentence, from:</p>
5344 <blockquote>
5345 <p>Dereferenceable and past-the-end values are always non-singular.</p>
5346 </blockquote>
5347 <p>to:</p>
5348 <blockquote>
5349 <p>Dereferenceable values are always non-singular.&nbsp;</p>
5350 </blockquote>
5351 <p><b>Rationale:</b></p>
5352 <p>For some kinds of containers, including singly linked lists and
5353 zero-length vectors, null pointers are perfectly reasonable past-the-end
5354 iterators.  Null pointers are singular.
5355 </p>
5356 <hr>
5357 <a name="209"><h3>209.&nbsp;basic_string declarations inconsistent</h3></a><p>
5358 <b>Section:</b>&nbsp;21.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Igor Stauder&nbsp; <b>Date:</b>&nbsp;11 Feb 2000</p>
5359 <p>In Section 21.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> the basic_string member function
5360 declarations use a consistent style except for the following functions:</p>
5361 <blockquote>
5362   <pre>void push_back(const charT);
5363 basic_string&amp; assign(const basic_string&amp;);
5364 void swap(basic_string&lt;charT,traits,Allocator&gt;&amp;);</pre>
5365 </blockquote>
5366 <p>- push_back, assign, swap: missing argument name&nbsp;<br>
5367 - push_back: use of const with charT (i.e. POD type passed by value
5368 not by reference - should be charT or const charT&amp; )<br>
5369 - swap: redundant use of template parameters in argument
5370 basic_string&lt;charT,traits,Allocator&gt;&amp;</p>
5371 <p><b>Proposed resolution:</b></p>
5372 <p>In Section 21.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> change the basic_string member
5373 function declarations push_back, assign, and swap to:</p>
5374 <blockquote>
5375   <pre>void push_back(charT c);
5376
5377 basic_string&amp; assign(const basic_string&amp; str);
5378 void swap(basic_string&amp; str);</pre>
5379 </blockquote>
5380 <p><b>Rationale:</b></p>
5381 <p>Although the standard is in general not consistent in declaration
5382 style, the basic_string declarations are consistent other than the
5383 above.  The LWG felt that this was sufficient reason to merit the
5384 change.
5385 </p>
5386 <hr>
5387 <a name="210"><h3>210.&nbsp;distance first and last confused</h3></a><p>
5388 <b>Section:</b>&nbsp;25 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;15 Feb 2000</p>
5389 <p>In paragraph 9 of section 25 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>, it is written:</p>
5390 <blockquote>
5391   <p>      In the description of the algorithms operators + and - are used
5392            for some of the iterator categories for which they do not have to
5393            be defined. In these cases the semantics of [...] a-b is the same
5394            as of<br>
5395   <br>
5396   &nbsp;&nbsp;&nbsp;&nbsp; <tt>return distance(a, b);</tt>
5397 </p>
5398 </blockquote>
5399 <p><b>Proposed resolution:</b></p>
5400 <p>On the last line of paragraph 9 of section 25 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> change
5401 <tt>"a-b"</tt> to <tt>"b-a".</tt>
5402 </p>
5403 <p><b>Rationale:</b></p>
5404 <p>There are two ways to fix the defect; change the description to b-a
5405 or change the return to distance(b,a).  The LWG preferred the
5406 former for consistency.</p>
5407 <hr>
5408 <a name="211"><h3>211.&nbsp;operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</h3></a><p>
5409 <b>Section:</b>&nbsp;21.3.7.9 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Scott Snyder&nbsp; <b>Date:</b>&nbsp;4 Feb 2000</p>
5410 <p>The description of the stream extraction operator for std::string (section
5411 21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
5412 the case that the operator fails to extract any characters from the input
5413 stream.</p>
5414 <p>This implies that the typical construction</p>
5415 <blockquote>
5416   <pre>std::istream is;
5417 std::string str;
5418 ...
5419 while (is &gt;&gt; str) ... ;</pre>
5420 </blockquote>
5421 <p>(which tests failbit) is not required to terminate at EOF.</p>
5422 <p>Furthermore, this is inconsistent with other extraction operators,
5423 which do include this requirement. (See sections 27.6.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted"> [lib.istream.formatted]</a> and 27.6.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), where this
5424 requirement is present, either explicitly or implicitly, for the
5425 extraction operators. It is also present explicitly in the description
5426 of getline (istream&amp;, string&amp;, charT) in section 21.3.7.9 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 8.)</p>
5427 <p><b>Proposed resolution:</b></p>
5428 <p>Insert new paragraph after paragraph 2 in section 21.3.7.9 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>:</p>
5429 <blockquote>
5430
5431 <p>If the function extracts no characters, it calls
5432 is.setstate(ios::failbit) which may throw ios_base::failure
5433 (27.4.4.3).</p>
5434 </blockquote>
5435 <hr>
5436 <a name="212"><h3>212.&nbsp;Empty range behavior unclear for several algorithms</h3></a><p>
5437 <b>Section:</b>&nbsp;25.3.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;26 Feb 2000</p>
5438 <p>The standard doesn't specify what min_element() and max_element() shall
5439 return if the range is empty (first equals last). The usual implementations
5440 return last. This problem seems also apply to partition(), stable_partition(),
5441 next_permutation(), and prev_permutation().</p>
5442 <p><b>Proposed resolution:</b></p>
5443 <p>In 25.3.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> - Minimum and maximum, paragraphs 7 and
5444 9, append: Returns last if first==last.</p>
5445 <p><b>Rationale:</b></p>
5446 <p>The LWG looked in some detail at all of the above mentioned
5447 algorithms, but believes that except for min_element() and
5448 max_element() it is already clear that last is returned if first ==
5449 last.</p>
5450 <hr>
5451 <a name="214"><h3>214.&nbsp;set::find() missing const overload</h3></a><p>
5452 <b>Section:</b>&nbsp;23.3.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.set"> [lib.set]</a>, 23.3.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.multiset"> [lib.multiset]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;28 Feb 2000</p>
5453 <p>The specification for the associative container requirements in
5454 Table 69 state that the find member function should "return
5455 iterator; const_iterator for constant a". The map and multimap
5456 container descriptions have two overloaded versions of find, but set
5457 and multiset do not, all they have is:</p>
5458 <blockquote>
5459   <pre>iterator find(const key_type &amp; x) const;</pre>
5460 </blockquote>
5461 <p><b>Proposed resolution:</b></p>
5462 <p>Change the prototypes for find(), lower_bound(), upper_bound(), and
5463 equal_range() in section 23.3.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.set"> [lib.set]</a> and section 23.3.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.multiset"> [lib.multiset]</a> to each have two overloads:</p>
5464 <blockquote>
5465   <pre>iterator find(const key_type &amp; x);
5466 const_iterator find(const key_type &amp; x) const;</pre>
5467   <pre>iterator lower_bound(const key_type &amp; x);
5468 const_iterator lower_bound(const key_type &amp; x) const;</pre>
5469   <pre>iterator upper_bound(const key_type &amp; x);
5470 const_iterator upper_bound(const key_type &amp; x) const;</pre>
5471   <pre>pair&lt;iterator, iterator&gt; equal_range(const key_type &amp; x);
5472 pair&lt;const_iterator, const_iterator&gt; equal_range(const key_type &amp; x) const;</pre>
5473 </blockquote>
5474
5475 <p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
5476 extending the proposed resolution to lower_bound, upper_bound, and
5477 equal_range.]</i></p>
5478 <hr>
5479 <a name="217"><h3>217.&nbsp;Facets example (Classifying Japanese characters) contains errors</h3></a><p>
5480 <b>Section:</b>&nbsp;22.2.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;29 Feb 2000</p>
5481 <p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
5482 <p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
5483 must be const in order for it to be callable on a const object (a reference to
5484 which which is what std::use_facet&lt;&gt;() returns).</p>
5485 <p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
5486 name of the namespace `My'.</p>
5487 <p>3) In the definition of `loc' and subsequently in the call to use_facet&lt;&gt;()
5488 in main(), the name of the facet is misspelled: it should read `My::JCtype'
5489 rather than `My::JCType'.</p>
5490 <p><b>Proposed resolution:</b></p>
5491 <p>Replace the "Classifying Japanese characters" example in 22.2.8,
5492 paragraph 11 with the following:</p>
5493 <pre>#include &lt;locale&gt;</pre>
5494 <pre>namespace My {
5495     using namespace std;
5496     class JCtype : public locale::facet {
5497     public:
5498         static locale::id id;     //  required for use as a new locale facet
5499         bool is_kanji (wchar_t c) const;
5500         JCtype() {}
5501     protected:
5502         ~JCtype() {}
5503     };
5504 }</pre>
5505 <pre>//  file:  filt.C
5506 #include &lt;iostream&gt;
5507 #include &lt;locale&gt;
5508 #include "jctype"                 //  above
5509 std::locale::id My::JCtype::id;   //  the static  JCtype  member
5510 declared above.</pre>
5511 <pre>int main()
5512 {
5513     using namespace std;
5514     typedef ctype&lt;wchar_t&gt; wctype;
5515     locale loc(locale(""),              //  the user's preferred locale...
5516                new My::JCtype);         //  and a new feature ...
5517     wchar_t c = use_facet&lt;wctype&gt;(loc).widen('!');
5518     if (!use_facet&lt;My::JCtype&gt;(loc).is_kanji(c))
5519         cout &lt;&lt; "no it isn't!" &lt;&lt; endl;
5520     return 0;
5521 }</pre>
5522 <hr>
5523 <a name="220"><h3>220.&nbsp;~ios_base() usage valid?</h3></a><p>
5524 <b>Section:</b>&nbsp;27.4.2.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.cons"> [lib.ios.base.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jonathan Schilling, Howard Hinnant&nbsp; <b>Date:</b>&nbsp;13 Mar 2000</p>
5525 <p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
5526 paragraph 2:</p>
5527 <blockquote>
5528   <p>Effects: Destroys an object of class ios_base. Calls each registered
5529   callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
5530   time that any ios_base member function called from within fn has well defined
5531   results.</p>
5532 </blockquote>
5533 <p>But what is not clear is: If no callback functions were ever registered, does
5534 it matter whether the ios_base members were ever initialized?</p>
5535 <p>For instance, does this program have defined behavior:</p>
5536 <blockquote>
5537   <pre>#include &lt;ios&gt;</pre>
5538   <pre>class D : public std::ios_base { };</pre>
5539   <pre>int main() { D d; }</pre>
5540 </blockquote>
5541 <p>It seems that registration of a callback function would surely affect the
5542 state of an ios_base. That is, when you register a callback function with an
5543 ios_base, the ios_base must record that fact somehow.</p>
5544 <p>But if after construction the ios_base is in an indeterminate state, and that
5545 state is not made determinate before the destructor is called, then how would
5546 the destructor know if any callbacks had indeed been registered? And if the
5547 number of callbacks that had been registered is indeterminate, then is not the
5548 behavior of the destructor undefined?</p>
5549 <p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
5550 it explicit that destruction before initialization results in undefined
5551 behavior.</p>
5552 <p><b>Proposed resolution:</b></p>
5553 <p>Modify 27.4.2.7 paragraph 1 from</p>
5554 <blockquote>
5555   <p>Effects: Each ios_base member has an indeterminate value after
5556   construction.</p>
5557 </blockquote>
5558 <p>to</p>
5559 <blockquote>
5560   <p>Effects: Each ios_base member has an indeterminate
5561 value after construction. These members must be initialized by calling
5562 basic_ios::init. If an ios_base object is destroyed before these
5563 initializations have taken place, the behavior is undefined.</p>
5564 </blockquote>
5565 <hr>
5566 <a name="221"><h3>221.&nbsp;num_get&lt;&gt;::do_get stage 2 processing broken</h3></a><p>
5567 <b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;14 Mar 2000</p>
5568 <p>Stage 2 processing of numeric conversion is broken.</p>
5569
5570 <p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
5571 conversion specifier is %i. A %i specifier determines a number's base
5572 by its prefix (0 for octal, 0x for hex), so the intention is clearly
5573 that a 0x prefix is allowed.  Paragraph 8 in the same section,
5574 however, describes very precisely how characters are processed. (It
5575 must be done "as if" by a specified code fragment.) That
5576 description does not allow a 0x prefix to be recognized.</p>
5577
5578 <p>Very roughly, stage 2 processing reads a char_type ct. It converts
5579 ct to a char, not by using narrow but by looking it up in a
5580 translation table that was created by widening the string literal
5581 "0123456789abcdefABCDEF+-". The character "x" is
5582 not found in that table, so it can't be recognized by stage 2
5583 processing.</p>
5584 <p><b>Proposed resolution:</b></p>
5585 <p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
5586 <blockquote>
5587   <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
5588 </blockquote>
5589 <p>with the line:</p>
5590 <blockquote>
5591   <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
5592 </blockquote>
5593 <p><b>Rationale:</b></p>
5594 <p>If we're using the technique of widening a string literal, the
5595 string literal must contain every character we wish to recognize.
5596 This technique has the consequence that alternate representations
5597 of digits will not be recognized.  This design decision was made
5598 deliberately, with full knowledge of that limitation.</p>
5599 <hr>
5600 <a name="222"><h3>222.&nbsp;Are throw clauses necessary if a throw is already implied by the effects clause?</h3></a><p>
5601 <b>Section:</b>&nbsp;17.3.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;17 Mar 2000</p>
5602 <p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
5603 <blockquote>
5604   <pre>21.3.6.8 - basic_string::compare [lib.string::compare]
5605
5606 int compare(size_type pos1, size_type n1,
5607                 const basic_string&lt;charT,traits,Allocator&gt;&amp;  str ,
5608                 size_type  pos2 , size_type  n2 ) const;
5609
5610 -4- Returns:
5611
5612     basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
5613                  basic_string&lt;charT,traits,Allocator&gt;(str,pos2,n2)) .</pre>
5614 </blockquote>
5615 <p>and the constructor that's implicitly called by the above is
5616 defined to throw an out-of-range exception if pos &gt; str.size(). See
5617 section 21.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a> paragraph 4.</p>
5618
5619 <p>On the other hand, the compare function descriptions themselves don't have
5620 "Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
5621 that do not apply to a function are omitted.</p>
5622 <p>So it seems there is an inconsistency in the standard -- are the
5623 "Effects" clauses correct, or are the "Throws" clauses
5624 missing?</p>
5625 <p><b>Proposed resolution:</b></p>
5626 <p>In 17.3.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> paragraph 3, the footnote 148 attached to
5627 the sentence "Descriptions of function semantics contain the
5628 following elements (as appropriate):", insert the word
5629 "further" so that the foot note reads:</p>
5630 <blockquote>
5631   <p>To save space, items that do not apply to a function are
5632   omitted. For example, if a function does not specify any further
5633   preconditions, there will be no "Requires" paragraph.</p>
5634 </blockquote>
5635 <p><b>Rationale:</b></p>
5636 <p>The standard is somewhat inconsistent, but a failure to note a
5637 throw condition in a throws clause does not grant permission not to
5638 throw.  The inconsistent wording is in a footnote, and thus
5639 non-normative. The proposed resolution from the LWG clarifies the
5640 footnote.</p>
5641 <hr>
5642 <a name="223"></a><h3><a name="223">223.&nbsp;reverse algorithm should use iter_swap rather than swap</a></h3><p>
5643 <b>Section:</b>&nbsp;25.2.9 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;21 Mar 2000</p>
5644 <p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
5645 <p><b>Proposed resolution:</b></p>
5646 <p>In 25.2.9 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a>, replace:</p>
5647   <blockquote>
5648   Effects: For each non-negative integer i &lt;= (last - first)/2,
5649   applies swap to all pairs of iterators first + i, (last - i) - 1.
5650   </blockquote>
5651 <p>with:</p>
5652   <blockquote>
5653   Effects: For each non-negative integer i &lt;= (last - first)/2,
5654   applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
5655   </blockquote>
5656 <hr>
5657 <a name="224"><h3>224.&nbsp;clear() complexity for associative containers refers to undefined N</h3></a><p>
5658 <b>Section:</b>&nbsp;23.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Ed Brey&nbsp; <b>Date:</b>&nbsp;23 Mar 2000</p>
5659 <p>In the associative container requirements table in 23.1.2 paragraph 7,
5660 a.clear() has complexity "log(size()) + N". However, the meaning of N
5661 is not defined.</p>
5662 <p><b>Proposed resolution:</b></p>
5663 <p>In the associative container requirements table in 23.1.2 paragraph
5664 7, the complexity of a.clear(), change "log(size()) + N" to
5665 "linear in <tt>size()</tt>".</p>
5666 <p><b>Rationale:</b></p>
5667 <p>It's the "log(size())", not the "N", that is in
5668 error: there's no difference between <i>O(N)</i> and <i>O(N +
5669 log(N))</i>.  The text in the standard is probably an incorrect
5670 cut-and-paste from the range version of <tt>erase</tt>.</p>
5671 <hr>
5672 <a name="225"><h3>225.&nbsp;std:: algorithms use of other unqualified algorithms</h3></a><p>
5673 <b>Section:</b>&nbsp;17.4.4.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
5674 <p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
5675 user namespaces might be found through Koenig lookup?</p>
5676 <p>For example, a popular standard library implementation includes this
5677 implementation of std::unique:</p>
5678 <blockquote>
5679 <pre>namespace std {
5680     template &lt;class _ForwardIter&gt;
5681     _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
5682       __first = adjacent_find(__first, __last);
5683       return unique_copy(__first, __last, __first);
5684     }
5685     }</pre>
5686 </blockquote>
5687 <p>Imagine two users on opposite sides of town, each using unique on his own
5688 sequences bounded by my_iterators . User1 looks at his standard library
5689 implementation and says, "I know how to implement a more efficient
5690 unique_copy for my_iterators", and writes:</p>
5691 <blockquote>
5692 <pre>namespace user1 {
5693     class my_iterator;
5694     // faster version for my_iterator
5695     my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
5696     }</pre>
5697 </blockquote>
5698 <p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
5699 <p>User2 has other needs, and writes:</p>
5700 <blockquote>
5701 <pre>namespace user2 {
5702     class my_iterator;
5703     // Returns true iff *c is a unique copy of *a and *b.
5704     bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
5705     }</pre>
5706 </blockquote>
5707 <p>User2 is shocked to find later that his fully-qualified use of
5708 std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
5709 compile (if he's lucky). Looking in the standard, he sees the following Effects
5710 clause for unique():</p>
5711 <blockquote>
5712   <p>Effects: Eliminates all but the first element from every consecutive group
5713   of equal elements referred to by the iterator i in the range [first, last) for
5714   which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
5715   *(i - 1)) != false</p>
5716 </blockquote>
5717 <p>The standard gives user2 absolutely no reason to think he can interfere with
5718 std::unique by defining names in namespace user2. His standard library has been
5719 built with the template export feature, so he is unable to inspect the
5720 implementation. User1 eventually compiles his code with another compiler, and
5721 his version of unique_copy silently stops being called. Eventually, he realizes
5722 that he was depending on an implementation detail of his library and had no
5723 right to expect his unique_copy() to be called portably.</p>
5724 <p>On the face of it, and given above scenario, it may seem obvious that the
5725 implementation of unique() shown is non-conforming because it uses unique_copy()
5726 rather than ::std::unique_copy(). Most standard library implementations,
5727 however, seem to disagree with this notion.</p>
5728 <p> <i>[Tokyo:&nbsp; Steve Adamczyk from
5729 the core working group indicates that "std::" is sufficient;&nbsp;
5730 leading "::" qualification is not required because any namespace
5731 qualification is sufficient to suppress Koenig lookup.]</i>
5732 </p>
5733 <p><b>Proposed resolution:</b></p>
5734 <p>Add a paragraph and a note at the end of
5735 17.4.4.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a>:</p>
5736 <blockquote>
5737
5738 <p>Unless otherwise specified, no global or non-member function in the
5739 standard library shall use a function from another namespace which is
5740 found through <i>argument-dependent name lookup</i> (3.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/basic.html#basic.lookup.koenig"> [basic.lookup.koenig]</a>).</p>
5741
5742 <p>[Note: the phrase "unless otherwise specified" is intended to
5743 allow Koenig lookup in cases like that of ostream_iterators:<br>
5744
5745 <br>
5746   Effects:</p>
5747   <blockquote>
5748 <p>*out_stream &lt;&lt; value;<br>
5749       if(delim != 0) *out_stream &lt;&lt; delim;<br>
5750       return (*this);</p>
5751     <p>--end note]</p>
5752   </blockquote>
5753 </blockquote>
5754
5755 <p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
5756 is as yet unsure if the proposed resolution is the best
5757 solution. Furthermore, the LWG believes that the same problem of
5758 unqualified library names applies to wording in the standard itself,
5759 and has opened issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> accordingly. Any resolution of
5760 issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be coordinated with the resolution of
5761 issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>.]</i></p>
5762
5763 <p><i>[Toronto: The LWG is not sure if this is a defect in the
5764 standard.  Most LWG members believe that an implementation of
5765 <tt>std::unique</tt> like the one quoted in this issue is already
5766 illegal, since, under certain circumstances, its semantics are not
5767 those specified in the standard.  The standard's description of
5768 <tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
5769 should have any effect.]</i></p>
5770
5771 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
5772 225, 226, and 229.  Their conclusion was that the issues should be
5773 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
5774 EWG portion (Dave will write a proposal). The LWG and EWG had
5775 (separate) discussions of this plan the next day.  The proposed
5776 resolution for this issue is in accordance with Howard's paper.]</i></p>
5777
5778 <p><b>Rationale:</b></p>
5779 <p>It could be argued that this proposed isn't strictly necessary,
5780   that the Standard doesn't grant implementors license to write a
5781   standard function that behaves differently than specified in the
5782   Standard just because of an unrelated user-defined name in some
5783   other namespace.  However, this is at worst a clarification.  It is
5784   surely right that algorithsm shouldn't pick up random names, that
5785   user-defined names should have no effect unless otherwise specified.
5786   Issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#226">226</a> deals with the question of when it is
5787   appropriate for the standard to explicitly specify otherwise.</p>
5788 <hr>
5789 <a name="227"><h3>227.&nbsp;std::swap() should require CopyConstructible or DefaultConstructible arguments</h3></a><p>
5790 <b>Section:</b>&nbsp;25.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;09 Apr 2000</p>
5791 <p>25.2.2 reads:</p>
5792 <blockquote>
5793   <p>
5794 <tt>  template&lt;class T&gt; void swap(T&amp; a, T&amp; b);</tt><br>
5795   <br>
5796   Requires:    Type T is Assignable (_lib.container.requirements_).<br>
5797   Effects:    Exchanges values stored in two locations.</p>
5798 </blockquote>
5799 <p>The only reasonable** generic implementation of swap requires construction of a
5800    new temporary copy of one of its arguments:</p>
5801 <blockquote>
5802 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
5803   {
5804       T tmp(a);
5805       a = b;
5806       b = tmp;
5807   }</pre>
5808 </blockquote>
5809 <p>But a type which is only Assignable cannot be swapped by this implementation.</p>
5810 <p>**Yes, there's also an unreasonable implementation which would require T to be
5811    DefaultConstructible instead of CopyConstructible. I don't think this is worthy
5812    of consideration:</p>
5813 <blockquote>
5814 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
5815 {
5816     T tmp;
5817     tmp = a;
5818     a = b;
5819     b = tmp;
5820 }</pre>
5821 </blockquote>
5822 <p><b>Proposed resolution:</b></p>
5823 <p>Change 25.2.2 paragraph 1 from:</p>
5824 <blockquote>
5825 <p>  Requires: Type T is Assignable (23.1).</p>
5826 </blockquote>
5827 <p>to:</p>
5828 <blockquote>
5829 <p>  Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
5830 </blockquote>
5831 <hr>
5832 <a name="228"><h3>228.&nbsp;Incorrect specification of "..._byname" facets</h3></a><p>
5833 <b>Section:</b>&nbsp;22.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Apr 2000</p>
5834 <p>The sections 22.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>, 22.2.1.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a>,
5835 22.2.1.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>, 22.2.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct.byname"> [lib.locale.numpunct.byname]</a>, 22.2.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.collate.byname"> [lib.locale.collate.byname]</a>, 22.2.5.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.put.byname"> [lib.locale.time.put.byname]</a>, 22.2.6.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.byname"> [lib.locale.moneypunct.byname]</a>, and 22.2.7.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.messages.byname"> [lib.locale.messages.byname]</a> overspecify the
5836 definitions of the "..._byname" classes by listing a bunch
5837 of virtual functions. At the same time, no semantics of these
5838 functions are defined. Real implementations do not define these
5839 functions because the functional part of the facets is actually
5840 implemented in the corresponding base classes and the constructor of
5841 the "..._byname" version just provides suitable date used by
5842 these implementations. For example, the 'numpunct' methods just return
5843 values from a struct. The base class uses a statically initialized
5844 struct while the derived version reads the contents of this struct
5845 from a table.  However, no virtual function is defined in
5846 'numpunct_byname'.</p>
5847
5848 <p>For most classes this does not impose a problem but specifically
5849 for 'ctype' it does: The specialization for 'ctype_byname&lt;char&gt;'
5850 is required because otherwise the semantics would change due to the
5851 virtual functions defined in the general version for 'ctype_byname':
5852 In 'ctype&lt;char&gt;' the method 'do_is()' is not virtual but it is
5853 made virtual in both 'ctype&lt;cT&gt;' and 'ctype_byname&lt;cT&gt;'.
5854 Thus, a class derived from 'ctype_byname&lt;char&gt;' can tell whether
5855 this class is specialized or not under the current specification:
5856 Without the specialization, 'do_is()' is virtual while with
5857 specialization it is not virtual.</p>
5858 <p><b>Proposed resolution:</b></p>
5859 <p>&nbsp; Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
5860 <pre>     namespace std {
5861        template &lt;class charT&gt;
5862        class ctype_byname : public ctype&lt;charT&gt; {
5863        public:
5864          typedef ctype&lt;charT&gt;::mask mask;
5865          explicit ctype_byname(const char*, size_t refs = 0);
5866        protected:
5867         ~ctype_byname();             //  virtual
5868        };
5869      }</pre>
5870 <p>&nbsp; Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
5871 <pre>    namespace std {
5872       template &lt;class internT, class externT, class stateT&gt;
5873       class codecvt_byname : public codecvt&lt;internT, externT, stateT&gt; {
5874       public:
5875        explicit codecvt_byname(const char*, size_t refs = 0);
5876       protected:
5877       ~codecvt_byname();             //  virtual
5878        };
5879      }
5880 </pre>
5881 <p>&nbsp; Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
5882 <pre>     namespace std {
5883        template &lt;class charT&gt;
5884        class numpunct_byname : public numpunct&lt;charT&gt; {
5885      //  this class is specialized for  char  and  wchar_t.
5886        public:
5887          typedef charT                char_type;
5888          typedef basic_string&lt;charT&gt;  string_type;
5889          explicit numpunct_byname(const char*, size_t refs = 0);
5890        protected:
5891         ~numpunct_byname();          //  virtual
5892        };
5893      }</pre>
5894 <p>&nbsp; Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
5895 <pre>     namespace std {
5896        template &lt;class charT&gt;
5897        class collate_byname : public collate&lt;charT&gt; {
5898        public:
5899          typedef basic_string&lt;charT&gt; string_type;
5900          explicit collate_byname(const char*, size_t refs = 0);
5901        protected:
5902         ~collate_byname();           //  virtual
5903        };
5904      }</pre>
5905 <p>&nbsp; Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
5906 <pre>     namespace std {
5907        template &lt;class charT, class InputIterator = istreambuf_iterator&lt;charT&gt; &gt;
5908        class time_get_byname : public time_get&lt;charT, InputIterator&gt; {
5909        public:
5910          typedef time_base::dateorder dateorder;
5911          typedef InputIterator        iter_type</pre>
5912 <pre>         explicit time_get_byname(const char*, size_t refs = 0);
5913        protected:
5914         ~time_get_byname();          //  virtual
5915        };
5916      }</pre>
5917 <p>&nbsp; Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
5918 <pre>     namespace std {
5919        template &lt;class charT, class OutputIterator = ostreambuf_iterator&lt;charT&gt; &gt;
5920        class time_put_byname : public time_put&lt;charT, OutputIterator&gt;
5921        {
5922        public:
5923          typedef charT          char_type;
5924          typedef OutputIterator iter_type;</pre>
5925 <pre>         explicit time_put_byname(const char*, size_t refs = 0);
5926        protected:
5927         ~time_put_byname();          //  virtual
5928        };
5929      }"</pre>
5930 <p>&nbsp; Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
5931 <pre>     namespace std {
5932        template &lt;class charT, bool Intl = false&gt;
5933        class moneypunct_byname : public moneypunct&lt;charT, Intl&gt; {
5934        public:
5935          typedef money_base::pattern pattern;
5936          typedef basic_string&lt;charT&gt; string_type;</pre>
5937 <pre>         explicit moneypunct_byname(const char*, size_t refs = 0);
5938        protected:
5939         ~moneypunct_byname();        //  virtual
5940        };
5941      }</pre>
5942 <p>&nbsp; Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
5943 <pre>     namespace std {
5944        template &lt;class charT&gt;
5945        class messages_byname : public messages&lt;charT&gt; {
5946        public:
5947          typedef messages_base::catalog catalog;
5948          typedef basic_string&lt;charT&gt;    string_type;</pre>
5949 <pre>         explicit messages_byname(const char*, size_t refs = 0);
5950        protected:
5951         ~messages_byname();          //  virtual
5952        };
5953      }</pre>
5954 <p>Remove section 22.2.1.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a> completely (because in
5955 this case only those members are defined to be virtual which are
5956 defined to be virtual in 'ctype&lt;cT&gt;'.)</p>
5957
5958 <p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of
5959 the LWG to solve the underlying problems raised by issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>.]</i></p>
5960
5961 <p><i>[Copenhagen: proposed resolution was revised slightly, to remove
5962 three last virtual functions from <tt>messages_byname</tt>.]</i></p>
5963
5964 <hr>
5965 <a name="229"><h3>229.&nbsp;Unqualified references of other library entities</h3></a><p>
5966 <b>Section:</b>&nbsp;17.4.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.contents"> [lib.contents]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;19 Apr 2000</p>
5967 <p>Throughout the library chapters, the descriptions of library entities refer
5968 to other library entities without necessarily qualifying the names.</p>
5969
5970 <p>For example, section 25.2.2 "Swap" describes the effect of
5971 swap_ranges in terms of the unqualified name "swap". This section
5972 could reasonably be interpreted to mean that the library must be implemented so
5973 as to do a lookup of the unqualified name "swap", allowing users to
5974 override any ::std::swap function when Koenig lookup applies.</p>
5975
5976 <p>Although it would have been best to use explicit qualification with
5977 "::std::" throughout, too many lines in the standard would have to be
5978 adjusted to make that change in a Technical Corrigendum.</p>
5979
5980 <p>Issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, which addresses qualification of
5981 <tt>size_t</tt>, is a special case of this.
5982 </p>
5983 <p><b>Proposed resolution:</b></p>
5984 <p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p>
5985 <blockquote>
5986   <p>Whenever a name x defined in the standard library is mentioned, the name x
5987   is assumed to be fully qualified as ::std::x, unless explicitly described
5988   otherwise. For example, if the Effects section for library function F is
5989   described as calling library function G, the function ::std::G is meant.</p>
5990 </blockquote>
5991
5992 <p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
5993 the LWG to solve a problem in the standard itself similar to the
5994 problem within implementations of library identified by issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>.  Any resolution of issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be
5995 coordinated with the resolution of this issue.]</i></p>
5996
5997 <p><i>[post-Toronto: Howard is undecided about whether it is
5998 appropriate for all standard library function names referred to in
5999 other standard library functions to be explicitly qualified by
6000 <tt>std</tt>: it is common advice that users should define global
6001 functions that operate on their class in the same namespace as the
6002 class, and this requires argument-dependent lookup if those functions
6003 are intended to be called by library code.  Several LWG members are
6004 concerned that valarray appears to require argument-dependent lookup,
6005 but that the wording may not be clear enough to fall under
6006 "unless explicitly described otherwise".]</i></p>
6007
6008 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
6009 225, 226, and 229.  Their conclusion was that the issues should be
6010 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6011 EWG portion (Dave will write a proposal). The LWG and EWG had
6012 (separate) discussions of this plan the next day.  This paper resolves
6013 issues 225 and 226.  In light of that resolution, the proposed
6014 resolution for the current issue makes sense.]</i></p>
6015
6016 <hr>
6017 <a name="230"><h3>230.&nbsp;Assignable specified without also specifying CopyConstructible</h3></a><p>
6018 <b>Section:</b>&nbsp;17 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;26 Apr 2000</p>
6019 <p>Issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> identified an instance (std::swap) where
6020 Assignable was specified without also specifying
6021 CopyConstructible. The LWG asked that the standard be searched to
6022 determine if the same defect existed elsewhere.</p>
6023
6024 <p>There are a number of places (see proposed resolution below) where
6025 Assignable is specified without also specifying
6026 CopyConstructible. There are also several cases where both are
6027 specified. For example, 26.4.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p>
6028 <p><b>Proposed resolution:</b></p>
6029 <p>In  23.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> table 65 for value_type:
6030 change "T is Assignable" to "T is CopyConstructible and
6031 Assignable"
6032 </p>
6033
6034 <p>In 23.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> table 69 X::key_type; change
6035 "Key is Assignable" to "Key is
6036 CopyConstructible and Assignable"<br>
6037 </p>
6038
6039 <p>In 24.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a> paragraph 1, change:
6040 </p>
6041 <blockquote>
6042 <p> A class or a built-in type X satisfies the requirements of an
6043 output iterator if X is an Assignable type (23.1) and also the
6044 following expressions are valid, as shown in Table 73:
6045 </p>
6046 </blockquote>
6047 <p>to:
6048 </p>
6049 <blockquote>
6050 <p> A class or a built-in type X satisfies the requirements of an
6051 output iterator if X is a CopyConstructible (20.1.3) and Assignable
6052 type (23.1) and also the following expressions are valid, as shown in
6053 Table 73:
6054 </p>
6055 </blockquote>
6056
6057 <p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
6058 the LWG.  He asks that the 25.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> and 25.2.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a> changes be studied carefully, as it is not clear that
6059 CopyConstructible is really a requirement and may be
6060 overspecification.]</i></p>
6061 <p><b>Rationale:</b></p>
6062 <p>The original proposed resolution also included changes to input
6063 iterator, fill, and replace.  The LWG believes that those changes are
6064 not necessary.  The LWG considered some blanket statement, where an
6065 Assignable type was also required to be Copy Constructible, but
6066 decided against this because fill and replace really don't require the
6067 Copy Constructible property.</p>
6068 <hr>
6069 <a name="231"><h3>231.&nbsp;Precision in iostream?</h3></a><p>
6070 <b>Section:</b>&nbsp;22.2.2.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze, Stephen Clamage&nbsp; <b>Date:</b>&nbsp; 25 Apr 2000</p>
6071 <p>What is the following program supposed to output?</p>
6072 <pre>#include &lt;iostream&gt;
6073
6074     int
6075     main()
6076     {
6077         std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
6078         std::cout.precision( 0 ) ;
6079         std::cout &lt;&lt; 1.00 &lt;&lt; '\n' ;
6080         return 0 ;
6081     }</pre>
6082 <p>From my C experience, I would expect "1e+00"; this is what
6083 <tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs
6084 "1.000000e+00".</p>
6085
6086 <p>The only indication I can find in the standard is 22.2.2.2.2/11,
6087 where it says "For conversion from a floating-point type, if
6088 (flags &amp; fixed) != 0 or if str.precision() &gt; 0, then
6089 str.precision() is specified in the conversion specification."
6090 This is an obvious error, however, fixed is not a mask for a field,
6091 but a value that a multi-bit field may take -- the results of and'ing
6092 fmtflags with ios::fixed are not defined, at least not if
6093 ios::scientific has been set. G++'s behavior corresponds to what might
6094 happen if you do use (flags &amp; fixed) != 0 with a typical
6095 implementation (floatfield == 3 &lt;&lt; something, fixed == 1
6096 &lt;&lt; something, and scientific == 2 &lt;&lt; something).</p>
6097
6098 <p>Presumably, the intent is either (flags &amp; floatfield) != 0, or
6099 (flags &amp; floatfield) == fixed; the first gives something more or
6100 less like the effect of precision in a printf floating point
6101 conversion. Only more or less, of course. In order to implement printf
6102 formatting correctly, you must know whether the precision was
6103 explicitly set or not. Say by initializing it to -1, instead of 6, and
6104 stating that for floating point conversions, if precision &lt; -1, 6
6105 will be used, for fixed point, if precision &lt; -1, 1 will be used,
6106 etc. Plus, of course, if precision == 0 and flags &amp; floatfield ==
6107 0, 1 should be = used. But it probably isn't necessary to emulate all
6108 of the anomalies of printf:-).</p>
6109 <p><b>Proposed resolution:</b></p>
6110 <p>
6111 Replace 22.2.2.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, paragraph 11, with the following
6112 sentence:
6113 </p>
6114 <blockquote>
6115 For conversion from a floating-point type,
6116 <tt><i>str</i>.precision()</tt> is specified in the conversion
6117 specification.
6118 </blockquote>
6119 <p><b>Rationale:</b></p>
6120 <p>The floatfield determines whether numbers are formatted as if
6121 with %f, %e, or %g.  If the <tt>fixed</tt> bit is set, it's %f,
6122 if <tt>scientific</tt> it's %e, and if both bits are set, or
6123 neither, it's %g.</p>
6124 <p>Turning to the C standard, a precision of 0 is meaningful
6125 for %f and %e.  For %g, precision 0 is taken to be the same as
6126 precision 1.</p>
6127 <p>The proposed resolution has the effect that if neither
6128 <tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
6129 specifying a precision of 0, which will be internally
6130 turned into 1.  There's no need to call it out as a special
6131 case.</p>
6132 <p>The output of the above program will be "1e+00".</p>
6133
6134 <p><i>[Post-Curaçao: Howard provided improved wording covering the case
6135 where precision is 0 and mode is %g.]</i></p>
6136
6137 <hr>
6138 <a name="232"><h3>232.&nbsp;"depends" poorly defined in 17.4.3.1</h3></a><p>
6139 <b>Section:</b>&nbsp;17.4.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;18 Apr 2000</p>
6140 <p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
6141 specializations of standard templates to those that "depend on a
6142 user-defined name of external linkage."</p>
6143 <p>This term, however, is not adequately defined, making it possible to
6144 construct a specialization that is, I believe, technically legal according to
6145 17.4.3.1/1, but that specializes a standard template for a built-in type such as
6146 'int'.</p>
6147 <p>The following code demonstrates the problem:</p>
6148 <blockquote>
6149   <pre>#include &lt;algorithm&gt;</pre>
6150   <pre>template&lt;class T&gt; struct X
6151 {
6152  typedef T type;
6153 };</pre>
6154   <pre>namespace std
6155 {
6156  template&lt;&gt; void swap(::X&lt;int&gt;::type&amp; i, ::X&lt;int&gt;::type&amp; j);
6157 }</pre>
6158 </blockquote>
6159 <p><b>Proposed resolution:</b></p>
6160 <p>Change "user-defined name" to "user-defined
6161 type".</p>
6162 <p><b>Rationale:</b></p>
6163 <p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
6164 Programming Language</i>.  It disallows the example in the issue,
6165 since the underlying type itself is not user-defined.  The only
6166 possible problem I can see is for non-type templates, but there's no
6167 possible way for a user to come up with a specialization for bitset,
6168 for example, that might not have already been specialized by the
6169 implementor?</p>
6170
6171 <p><i>[Toronto: this may be related to issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#120">120</a>.]</i></p>
6172
6173 <p><i>[post-Toronto: Judy provided the above proposed resolution and
6174 rationale.]</i></p>
6175 <hr>
6176 <a name="234"><h3>234.&nbsp;Typos in allocator definition</h3></a><p>
6177 <b>Section:</b>&nbsp;20.4.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;24 Apr 2000</p>
6178 <p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
6179 <tt>destruct()</tt> are described as returns but the functions actually
6180 return <tt>void</tt>.</p>
6181 <p><b>Proposed resolution:</b></p>
6182 <p>Substitute "Returns" by "Effect".</p>
6183 <hr>
6184 <a name="235"><h3>235.&nbsp;No specification of default ctor for reverse_iterator</h3></a><p>
6185 <b>Section:</b>&nbsp;24.4.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;24 Apr 2000</p>
6186 <p>The declaration of <tt>reverse_iterator</tt> lists a default
6187 constructor.  However, no specification is given what this constructor
6188 should do.</p>
6189 <p><b>Proposed resolution:</b></p>
6190   <p>In section 24.4.1.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.cons"> [lib.reverse.iter.cons]</a> add the following
6191   paragraph:</p>
6192       <blockquote>
6193       <p><tt>reverse_iterator()</tt></p>
6194
6195       <p>Default initializes <tt>current</tt>. Iterator operations
6196       applied to the resulting iterator have defined behavior if and
6197       only if the corresponding operations are defined on a default
6198       constructed iterator of type <tt>Iterator</tt>.</p>
6199       </blockquote>
6200   <p><i>[pre-Copenhagen: Dietmar provide wording for proposed
6201   resolution.]</i></p>
6202 <hr>
6203 <a name="237"><h3>237.&nbsp;Undefined expression in complexity specification</h3></a><p>
6204 <b>Section:</b>&nbsp;23.2.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;24 Apr 2000</p>
6205 <p>The complexity specification in paragraph 6 says that the complexity
6206 is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
6207 defined on iterators this term is in general undefined because it
6208 would have to be <tt>last - first</tt>.</p>
6209 <p><b>Proposed resolution:</b></p>
6210   <p>Change paragraph 6 from</p>
6211      <blockquote>Linear in <i>first - last</i>.</blockquote>
6212   <p>to become</p>
6213      <blockquote>Linear in <i>distance(first, last)</i>.</blockquote>
6214 <hr>
6215 <a name="238"><h3>238.&nbsp;Contradictory results of stringbuf initialization.</h3></a><p>
6216 <b>Section:</b>&nbsp;27.7.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.cons"> [lib.stringbuf.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;11 May 2000</p>
6217 <p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
6218 'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
6219 that far but consider this code:</p>
6220
6221 <pre>  std::basic_stringbuf&lt;char&gt; sbuf("hello, world", std::ios_base::openmode(0));
6222   std::cout &lt;&lt; "'" &lt;&lt; sbuf.str() &lt;&lt; "'\n";
6223 </pre>
6224
6225 <p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
6226 the output sequence nor the input sequence is initialized and
6227 paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
6228 returns the input or the output sequence. None of them is initialized,
6229 ie. both are empty, in which case the return from <tt>str()</tt> is
6230 defined to be <tt>basic_string&lt;cT&gt;()</tt>.</p>
6231
6232 <p>However, probably only test cases in some testsuites will detect this
6233 "problem"...</p>
6234 <p><b>Proposed resolution:</b></p>
6235 <p>Remove 27.7.1.1 paragraph 4.</p>
6236 <p><b>Rationale:</b></p>
6237 <p>We could fix 27.7.1.1 paragraph 4, but there would be no point.  If
6238 we fixed it, it would say just the same thing as text that's already
6239 in the standard.</p>
6240 <hr>
6241 <a name="239"><h3>239.&nbsp;Complexity of unique() and/or unique_copy incorrect</h3></a><p>
6242 <b>Section:</b>&nbsp;25.2.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
6243 <p>The complexity of unique and unique_copy are inconsistent with each
6244 other and inconsistent with the implementations.&nbsp; The standard
6245 specifies:</p>
6246
6247 <p>for unique():</p>
6248
6249 <blockquote>-3- Complexity: If the range (last - first) is not empty, exactly
6250 (last - first) - 1 applications of the corresponding predicate, otherwise
6251 no applications of the predicate.</blockquote>
6252
6253 <p>for unique_copy():</p>
6254
6255 <blockquote>-7- Complexity: Exactly last - first applications of the corresponding
6256 predicate.</blockquote>
6257
6258 <p>
6259 The implementations do it the other way round: unique() applies the
6260 predicate last-first times and unique_copy() applies it last-first-1
6261 times.</p>
6262
6263 <p>As both algorithms use the predicate for pair-wise comparison of
6264 sequence elements I don't see a justification for unique_copy()
6265 applying the predicate last-first times, especially since it is not
6266 specified to which pair in the sequence the predicate is applied
6267 twice.</p>
6268 <p><b>Proposed resolution:</b></p>
6269 <p>Change both complexity sections in 25.2.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> to:</p>
6270
6271 <blockquote>Complexity: For nonempty ranges, exactly last - first - 1
6272 applications of the corresponding predicate.</blockquote>
6273
6274 <hr>
6275 <a name="240"><h3>240.&nbsp;Complexity of adjacent_find() is meaningless</h3></a><p>
6276 <b>Section:</b>&nbsp;25.1.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
6277 <p>The complexity section of adjacent_find is defective:</p>
6278
6279 <blockquote>
6280 <pre>template &lt;class ForwardIterator&gt;
6281 ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
6282                               BinaryPredicate pred);
6283 </pre>
6284
6285 <p>-1- Returns: The first iterator i such that both i and i + 1 are in
6286 the range [first, last) for which the following corresponding
6287 conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
6288 last if no such iterator is found.</p>
6289
6290 <p>-2- Complexity: Exactly find(first, last, value) - first applications
6291 of the corresponding predicate.
6292 </p>
6293 </blockquote>
6294
6295 <p>In the Complexity section, it is not defined what "value"
6296 is supposed to mean. My best guess is that "value" means an
6297 object for which one of the conditions pred(*i,value) or
6298 pred(value,*i) is true, where i is the iterator defined in the Returns
6299 section. However, the value type of the input sequence need not be
6300 equality-comparable and for this reason the term find(first, last,
6301 value) - first is meaningless.</p>
6302
6303 <p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
6304 find_if(first, last, bind1st(pred,*i)) - first might come closer to
6305 the intended specification.  Binders can only be applied to function
6306 objects that have the function call operator declared const, which is
6307 not required of predicates because they can have non-const data
6308 members. For this reason, a specification using a binder could only be
6309 an "as-if" specification.</p>
6310 <p><b>Proposed resolution:</b></p>
6311 <p>Change the complexity section in 25.1.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a> to:</p>
6312 <blockquote>
6313 For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
6314 (<i>last</i> - <i>first</i>) - 1)</tt> applications of the
6315 corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
6316 return value.
6317 </blockquote>
6318
6319 <p><i>[Copenhagen: the original resolution specified an upper
6320 bound.  The LWG preferred an exact count.]</i></p>
6321
6322 <hr>
6323 <a name="241"><h3>241.&nbsp;Does unique_copy() require CopyConstructible and Assignable?</h3></a><p>
6324 <b>Section:</b>&nbsp;25.2.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
6325
6326 <p>Some popular implementations of unique_copy() create temporary
6327 copies of values in the input sequence, at least if the input iterator
6328 is a pointer.  Such an implementation is built on the assumption that
6329 the value type is CopyConstructible and Assignable.</p>
6330
6331 <p>It is common practice in the standard that algorithms explicitly
6332 specify any additional requirements that they impose on any of the
6333 types used by the algorithm. An example of an algorithm that creates
6334 temporary copies and correctly specifies the additional requirements
6335 is accumulate(), 26.4.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p>
6336
6337 <p>Since the specifications of unique() and unique_copy() do not
6338 require CopyConstructible and Assignable of the InputIterator's value
6339 type the above mentioned implementations are not standard-compliant. I
6340 cannot judge whether this is a defect in the standard or a defect in
6341 the implementations.</p>
6342 <p><b>Proposed resolution:</b></p>
6343 <p>In 25.2.8 change:</p>
6344
6345 <blockquote>
6346 -4- Requires: The ranges [first, last) and [result, result+(last-first))
6347 shall not overlap.
6348 </blockquote>
6349
6350 <p>to:</p>
6351
6352 <blockquote>
6353   <p>-4- Requires: The ranges [first, last) and [result,
6354   result+(last-first)) shall not overlap. The expression *result =
6355   *first must be valid. If neither InputIterator nor OutputIterator
6356   meets the requirements of forward iterator then the value type of
6357   InputIterator must be copy constructible. Otherwise copy
6358   constructible is not required. </p>
6359 </blockquote>
6360
6361 <p><i>[Redmond: the original proposed resolution didn't impose an
6362 explicit requirement that the iterator's value type must be copy
6363 constructible, on the grounds that an input iterator's value type must
6364 always be copy constructible.  Not everyone in the LWG thought that
6365 this requirement was clear from table 72.  It has been suggested that
6366 it might be possible to implement <tt>unique_copy</tt> without
6367 requiring assignability, although current implementations do impose
6368 that requirement.  Howard provided new wording.]</i></p>
6369
6370 <p><i>[
6371 Curaçao: The LWG changed the PR editorially to specify
6372 "neither...nor...meet..." as clearer than
6373 "both...and...do not meet...". Change believed to be so
6374 minor as not to require re-review.
6375 ]</i></p>
6376
6377 <hr>
6378 <a name="242"><h3>242.&nbsp;Side effects of function objects</h3></a><p>
6379 <b>Section:</b>&nbsp;25.2.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.transform"> [lib.alg.transform]</a>, 26.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numeric.ops"> [lib.numeric.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
6380 <p>The algorithms transform(), accumulate(), inner_product(),
6381 partial_sum(), and adjacent_difference() require that the function
6382 object supplied to them shall not have any side effects.</p>
6383
6384 <p>The standard defines a side effect in 1.9 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/intro.html#intro.execution"> [intro.execution]</a> as:</p>
6385 <blockquote>-7- Accessing an object designated by a volatile lvalue (basic.lval),
6386 modifying an object, calling a library I/O function, or calling a function
6387 that does any of those operations are all side effects, which are changes
6388 in the state of the execution environment.</blockquote>
6389
6390 <p>As a consequence, the function call operator of a function object supplied
6391 to any of the algorithms listed above cannot modify data members, cannot
6392 invoke any function that has a side effect, and cannot even create and
6393 modify temporary objects.&nbsp; It is difficult to imagine a function object
6394 that is still useful under these severe limitations. For instance, any
6395 non-trivial transformator supplied to transform() might involve creation
6396 and modification of temporaries, which is prohibited according to the current
6397 wording of the standard.</p>
6398
6399 <p>On the other hand, popular implementations of these algorithms exhibit
6400 uniform and predictable behavior when invoked with a side-effect-producing
6401 function objects. It looks like the strong requirement is not needed for
6402 efficient implementation of these algorithms.</p>
6403
6404 <p>The requirement of&nbsp; side-effect-free function objects could be
6405 replaced by a more relaxed basic requirement (which would hold for all
6406 function objects supplied to any algorithm in the standard library):</p>
6407 <blockquote>A function objects supplied to an algorithm shall not invalidate
6408 any iterator or sequence that is used by the algorithm. Invalidation of
6409 the sequence includes destruction of the sorting order if the algorithm
6410 relies on the sorting order (see section 25.3 - Sorting and related operations
6411 [lib.alg.sorting]).</blockquote>
6412
6413 <p>I can't judge whether it is intended that the function objects supplied
6414 to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
6415 shall not modify sequence elements through dereferenced iterators.</p>
6416
6417 <p>It is debatable whether this issue is a defect or a change request.
6418 Since the consequences for user-supplied function objects are drastic and
6419 limit the usefulness of the algorithms significantly I would consider it
6420 a defect.</p>
6421 <p><b>Proposed resolution:</b></p>
6422
6423 <p><i>Things to notice about these changes:</i></p>
6424
6425 <ol>
6426 <li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
6427      are intentional. we want to prevent side-effects from
6428      invalidating the end iterators.</i>
6429 </li>
6430
6431 <li> <i>That has the unintentional side-effect of prohibiting
6432      modification of the end element as a side-effect. This could
6433      conceivably be significant in some cases.</i>
6434 </li>
6435
6436 <li> <i>The wording also prevents side-effects from modifying elements
6437      of the output sequence. I can't imagine why anyone would want
6438      to do this, but it is arguably a restriction that implementors
6439      don't need to place on users.</i>
6440 </li>
6441
6442 <li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
6443      and simple, but would require more verbiage.</i>
6444 </li>
6445 </ol>
6446
6447 <p>Change 25.2.3/2 from:</p>
6448
6449 <blockquote>
6450    -2- Requires: op and binary_op shall not have any side effects.
6451 </blockquote>
6452
6453 <p>to:</p>
6454
6455 <blockquote>
6456   -2- Requires: in the ranges [first1, last1], [first2, first2 +
6457   (last1 - first1)] and [result, result + (last1- first1)], op and
6458   binary_op shall neither modify elements nor invalidate iterators or
6459   subranges.
6460   [Footnote: The use of fully closed ranges is intentional --end footnote]
6461 </blockquote>
6462
6463
6464 <p>Change 25.2.3/2 from:</p>
6465
6466 <blockquote>
6467    -2- Requires: op and binary_op shall not have any side effects.
6468 </blockquote>
6469
6470 <p>to:</p>
6471
6472 <blockquote>
6473   -2- Requires: op and binary_op shall not invalidate iterators or
6474    subranges, or modify elements in the ranges [first1, last1],
6475    [first2, first2 + (last1 - first1)], and [result, result + (last1
6476    - first1)].
6477   [Footnote: The use of fully closed ranges is intentional --end footnote]
6478 </blockquote>
6479
6480
6481 <p>Change 26.4.1/2 from:</p>
6482
6483 <blockquote>
6484   -2- Requires: T must meet the requirements of CopyConstructible
6485    (lib.copyconstructible) and Assignable (lib.container.requirements)
6486    types. binary_op shall not cause side effects.
6487 </blockquote>
6488
6489 <p>to:</p>
6490
6491 <blockquote>
6492   -2- Requires: T must meet the requirements of CopyConstructible
6493    (lib.copyconstructible) and Assignable
6494    (lib.container.requirements) types. In the range [first, last],
6495    binary_op shall neither modify elements nor invalidate iterators
6496    or subranges.
6497   [Footnote: The use of a fully closed range is intentional --end footnote]
6498 </blockquote>
6499
6500 <p>Change 26.4.2/2 from:</p>
6501
6502 <blockquote>
6503   -2- Requires: T must meet the requirements of CopyConstructible
6504    (lib.copyconstructible) and Assignable (lib.container.requirements)
6505    types. binary_op1 and binary_op2 shall not cause side effects.
6506 </blockquote>
6507
6508 <p>to:</p>
6509
6510 <blockquote>
6511   -2- Requires: T must meet the requirements of CopyConstructible
6512    (lib.copyconstructible) and Assignable (lib.container.requirements)
6513    types. In the ranges [first, last] and [first2, first2 + (last -
6514    first)], binary_op1 and binary_op2 shall neither modify elements
6515    nor invalidate iterators or subranges.
6516   [Footnote: The use of fully closed ranges is intentional --end footnote]
6517 </blockquote>
6518
6519
6520 <p>Change 26.4.3/4 from:</p>
6521
6522 <blockquote>
6523   -4- Requires: binary_op is expected not to have any side effects.
6524 </blockquote>
6525
6526 <p>to:</p>
6527
6528 <blockquote>
6529   -4- Requires: In the ranges [first, last] and [result, result +
6530    (last - first)], binary_op shall neither modify elements nor
6531    invalidate iterators or subranges.
6532   [Footnote: The use of fully closed ranges is intentional --end footnote]
6533 </blockquote>
6534
6535 <p>Change 26.4.4/2 from:</p>
6536
6537 <blockquote>
6538   -2- Requires: binary_op shall not have any side effects.
6539 </blockquote>
6540
6541 <p>to:</p>
6542
6543 <blockquote>
6544   -2- Requires: In the ranges [first, last] and [result, result +
6545    (last - first)], binary_op shall neither modify elements nor
6546    invalidate iterators or subranges.
6547   [Footnote: The use of fully closed ranges is intentional --end footnote]
6548 </blockquote>
6549
6550 <p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
6551
6552 <p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
6553 added footnotes pointing out that the use of closed ranges was
6554 intentional.]</i></p>
6555
6556 <hr>
6557 <a name="243"><h3>243.&nbsp;<tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3></a><p>
6558 <b>Section:</b>&nbsp;27.6.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
6559 <p>basic_istream&lt;&gt;::get(), and basic_istream&lt;&gt;::getline(),
6560 are unclear with respect to the behavior and side-effects of the named
6561 functions in case of an error.</p>
6562
6563 <p>27.6.1.3, p1 states that "... If the sentry object returns
6564 true, when converted to a value of type bool, the function endeavors
6565 to obtain the requested input..." It is not clear from this (or
6566 the rest of the paragraph) what precisely the behavior should be when
6567 the sentry ctor exits by throwing an exception or when the sentry
6568 object returns false.  In particular, what is the number of characters
6569 extracted that gcount() returns supposed to be?</p>
6570
6571 <p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
6572 "...  In any case, it then stores a null character (using
6573 charT()) into the next successive location of the array." Is not
6574 clear whether this sentence applies if either of the conditions above
6575 holds (i.e., when sentry fails).</p>
6576 <p><b>Proposed resolution:</b></p>
6577 <p>Add to 27.6.1.3, p1 after the sentence</p>
6578
6579 <blockquote>
6580 "... If the sentry object returns true, when converted to a value of
6581 type bool, the function endeavors to obtain the requested input."
6582 </blockquote>
6583
6584 <p>the following</p>
6585
6586
6587 <blockquote>
6588 "Otherwise, if the sentry constructor exits by throwing an exception or
6589 if the sentry object returns false, when converted to a value of type
6590 bool, the function returns without attempting to obtain any input. In
6591 either case the number of extracted characters is set to 0; unformatted
6592 input functions taking a character array of non-zero size as an argument
6593 shall also store a null character (using charT()) in the first location
6594 of the array."
6595 </blockquote>
6596 <p><b>Rationale:</b></p>
6597 <p>Although the general philosophy of the input functions is that the
6598 argument should not be modified upon failure, <tt>getline</tt>
6599 historically added a terminating null unconditionally.  Most
6600 implementations still do that.  Earlier versions of the draft standard
6601 had language that made this an unambiguous requirement; those words
6602 were moved to a place where their context made them less clear.  See
6603 Jerry Schwarz's message c++std-lib-7618.</p>
6604 <hr>
6605 <a name="248"></a><h3><a name="248">248.&nbsp;time_get fails to set eofbit</a></h3><p>
6606 <b>Section:</b>&nbsp;22.2.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.time"> [lib.category.time]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;22 June 2000</p>
6607 <p>There is no requirement that any of time_get member functions set
6608 ios::eofbit when they reach the end iterator while parsing their input.
6609 Since members of both the num_get and money_get facets are required to
6610 do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
6611 should follow the same requirement for consistency.</p>
6612 <p><b>Proposed resolution:</b></p>
6613 <p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
6614
6615 <blockquote>
6616 If the end iterator is reached during parsing by any of the get()
6617 member functions, the member sets ios_base::eofbit in err.
6618 </blockquote>
6619 <p><b>Rationale:</b></p>
6620 <p>Two alternative resolutions were proposed.  The LWG chose this one
6621 because it was more consistent with the way eof is described for other
6622 input facets.</p>
6623 <hr>
6624 <a name="250"><h3>250.&nbsp;splicing invalidates iterators</h3></a><p>
6625 <b>Section:</b>&nbsp;23.2.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Brian Parker &nbsp; <b>Date:</b>&nbsp;14 Jul 2000</p>
6626 <p>
6627 Section 23.2.2.4 [lib.list.ops] states that
6628 </p>
6629 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
6630 </pre>
6631 <p>
6632 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
6633 </p>
6634
6635 <p>
6636 This is unnecessary and defeats an important feature of splice. In
6637 fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
6638 after <tt>splice</tt>.
6639 </p>
6640 <p><b>Proposed resolution:</b></p>
6641
6642 <p>Add a footnote to 23.2.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, paragraph 1:</p>
6643 <blockquote>
6644 [<i>Footnote:</i> As specified in 20.1.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, paragraphs
6645 4-5, the semantics described in this clause applies only to the case
6646 where allocators compare equal.  --end footnote]
6647 </blockquote>
6648
6649 <p>In 23.2.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 4 with:</p>
6650 <blockquote>
6651 Effects: Inserts the contents of x before position and x becomes
6652 empty.  Pointers and references to the moved elements of x now refer to
6653 those same elements but as members of *this.  Iterators referring to the
6654 moved elements will continue to refer to their elements, but they now
6655 behave as iterators into *this, not into x.
6656 </blockquote>
6657
6658 <p>In 23.2.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 7 with:</p>
6659 <blockquote>
6660 Effects: Inserts an element pointed to by i from list x before
6661 position and removes the element from x. The result is unchanged if
6662 position == i or position == ++i.  Pointers and references to *i continue
6663 to refer to this same element but as a member of *this.  Iterators to *i
6664 (including i itself) continue to refer to the same element, but now
6665 behave as iterators into *this, not into x.
6666 </blockquote>
6667
6668 <p>In 23.2.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 12 with:</p>
6669 <blockquote>
6670 Requires: [first, last) is a valid range in x. The result is
6671 undefined if position is an iterator in the range [first, last).
6672 Pointers and references to the moved elements of x now refer to those
6673 same elements but as members of *this.  Iterators referring to the moved
6674 elements will continue to refer to their elements, but they now behave as
6675 iterators into *this, not into x.
6676 </blockquote>
6677
6678 <p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
6679 <p><b>Rationale:</b></p>
6680 <p>The original proposed resolution said that iterators and references
6681 would remain "valid".  The new proposed resolution clarifies what that
6682 means.  Note that this only applies to the case of equal allocators.
6683 From 20.1.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> paragraph 4, the behavior of list when
6684 allocators compare nonequal is outside the scope of the standard.</p>
6685 <hr>
6686 <a name="251"><h3>251.&nbsp;basic_stringbuf missing allocator_type</h3></a><p>
6687 <b>Section:</b>&nbsp;27.7.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf"> [lib.stringbuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jul 2000</p>
6688 <p>The synopsis for the template class <tt>basic_stringbuf</tt>
6689 doesn't list a typedef for the template parameter
6690 <tt>Allocator</tt>. This makes it impossible to determine the type of
6691 the allocator at compile time. It's also inconsistent with all other
6692 template classes in the library that do provide a typedef for the
6693 <tt>Allocator</tt> parameter.</p>
6694 <p><b>Proposed resolution:</b></p>
6695 <p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
6696 basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and
6697 basic_stringstream (27.7.4) the typedef:</p>
6698 <pre>  typedef Allocator allocator_type;
6699 </pre>
6700 <hr>
6701 <a name="252"><h3>252.&nbsp;missing casts/C-style casts used in iostreams</h3></a><p>
6702 <b>Section:</b>&nbsp;27.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jul 2000</p>
6703 <p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
6704 const_cast&lt;&gt; in the Returns clause for basic_istringstream&lt;&gt;::rdbuf().
6705 The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
6706 D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
6707 the cast altogether.</p>
6708
6709 <p>C-style casts have not been deprecated, so the first part of this
6710 issue is stylistic rather than a matter of correctness.</p>
6711 <p><b>Proposed resolution:</b></p>
6712 <p>In 27.7.2.2, p1 replace </p>
6713 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
6714
6715 <p>with</p>
6716 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
6717
6718
6719 <p>In 27.7.3.2, p1 replace</p>
6720 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
6721
6722 <p>with</p>
6723 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
6724
6725 <p>In 27.7.6, p1, replace</p>
6726 <pre>  -1- Returns: &amp;sb</pre>
6727
6728 <p>with</p>
6729 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
6730
6731 <p>In D.7.2.2, p1 replace</p>
6732 <pre>  -2- Returns: &amp;sb. </pre>
6733
6734 <p>with</p>
6735 <pre>  -2- Returns: const_cast&lt;strstreambuf*&gt;(&amp;sb).</pre>
6736 <hr>
6737 <a name="256"><h3>256.&nbsp;typo in 27.4.4.2, p17: copy_event does not exist</h3></a><p>
6738 <b>Section:</b>&nbsp;27.4.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;21 Aug 2000</p>
6739 <p>
6740 27.4.4.2, p17 says
6741 </p>
6742
6743 <blockquote>
6744 -17- Before copying any parts of rhs, calls each registered callback
6745 pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
6746 exceptions() have been replaced, calls each callback pair that was
6747 copied from rhs as (*fn)(copy_event,*this,index).
6748 </blockquote>
6749
6750 <p>
6751 The name copy_event isn't defined anywhere. The intended name was
6752 copyfmt_event.
6753 </p>
6754 <p><b>Proposed resolution:</b></p>
6755 <p>Replace copy_event with copyfmt_event in the named paragraph.</p>
6756 <hr>
6757 <a name="259"><h3>259.&nbsp;<tt>basic_string::operator[]</tt> and const correctness</h3></a><p>
6758 <b>Section:</b>&nbsp;21.3.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.access"> [lib.string.access]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Chris Newton &nbsp; <b>Date:</b>&nbsp;27 Aug 2000</p>
6759 <p>
6760 <i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
6761 </p>
6762
6763 <p>
6764 The standard's description of <tt>basic_string&lt;&gt;::operator[]</tt>
6765 seems to violate const correctness.
6766 </p>
6767
6768 <p>
6769 The standard (21.3.4/1) says that "If <tt>pos &lt; size()</tt>,
6770 returns <tt>data()[pos]</tt>." The types don't work.  The
6771 return value of <tt>data()</tt> is <tt>const charT*</tt>, but
6772 <tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
6773 </p>
6774 <p><b>Proposed resolution:</b></p>
6775 <p>
6776 In section 21.3.4, paragraph 1, change
6777 "<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
6778 <i>pos</i>)</tt>".
6779 </p>
6780 <hr>
6781 <a name="260"><h3>260.&nbsp;Inconsistent return type of <tt>istream_iterator::operator++(int)</tt>
6782 </h3></a><p>
6783 <b>Section:</b>&nbsp;24.5.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Aug 2000</p>
6784 <p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
6785 it as returning the iterator by value. 24.5.1.2, p5 shows the same
6786 operator as returning the iterator by reference. That's incorrect
6787 given the Effects clause below (since a temporary is returned). The
6788 `&amp;' is probably just a typo.</p>
6789 <p><b>Proposed resolution:</b></p>
6790 <p>Change the declaration in 24.5.1.2, p5 from</p>
6791  <pre> istream_iterator&lt;T,charT,traits,Distance&gt;&amp; operator++(int);
6792  </pre>
6793 <p>to</p>
6794  <pre> istream_iterator&lt;T,charT,traits,Distance&gt; operator++(int);
6795  </pre>
6796 <p>(that is, remove the `&amp;').</p>
6797 <hr>
6798 <a name="261"></a><h3><a name="261">261.&nbsp;Missing description of <tt>istream_iterator::operator!=</tt>
6799 </a></h3><p>
6800 <b>Section:</b>&nbsp;24.5.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Aug 2000</p>
6801 <p>
6802 24.5.1, p3 lists the synopsis for
6803 </p>
6804
6805 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
6806         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
6807                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
6808 </pre>
6809
6810 <p>
6811 but there is no description of what the operator does (i.e., no Effects
6812 or Returns clause) in 24.5.1.2.
6813 </p>
6814 <p><b>Proposed resolution:</b></p>
6815 <p>
6816 Add paragraph 7 to the end of section 24.5.1.2 with the following text:
6817 </p>
6818
6819 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
6820         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
6821                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
6822 </pre>
6823
6824 <p>-7- Returns: !(x == y).</p>
6825 <hr>
6826 <a name="262"></a><h3><a name="262">262.&nbsp;Bitmask operator ~ specified incorrectly</a></h3><p>
6827 <b>Section:</b>&nbsp;17.3.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;03 Sep 2000</p>
6828 <p>
6829 The ~ operation should be applied after the cast to int_type.
6830 </p>
6831 <p><b>Proposed resolution:</b></p>
6832 <p>
6833 Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
6834 </p>
6835
6836 <pre>   bitmask operator~ ( bitmask X )
6837      { return static_cast&lt; bitmask&gt;(static_cast&lt;int_type&gt;(~ X)); }
6838 </pre>
6839
6840 <p>
6841 to:
6842 </p>
6843
6844 <pre>   bitmask operator~ ( bitmask X )
6845      { return static_cast&lt; bitmask&gt;(~static_cast&lt;int_type&gt;(X)); }
6846 </pre>
6847 <hr>
6848 <a name="263"><h3>263.&nbsp;Severe restriction on <tt>basic_string</tt> reference counting</h3></a><p>
6849 <b>Section:</b>&nbsp;21.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Kevlin Henney&nbsp; <b>Date:</b>&nbsp;04 Sep 2000</p>
6850 <p>
6851 The note in paragraph 6 suggests that the invalidation rules for
6852 references, pointers, and iterators in paragraph 5 permit a reference-
6853 counted implementation (actually, according to paragraph 6, they permit
6854 a "reference counted implementation", but this is a minor editorial fix).
6855 </p>
6856
6857 <p>
6858 However, the last sub-bullet is so worded as to make a reference-counted
6859 implementation unviable. In the following example none of the
6860 conditions for iterator invalidation are satisfied:
6861 </p>
6862
6863 <pre>    // first example: "*******************" should be printed twice
6864     string original = "some arbitrary text", copy = original;
6865     const string &amp; alias = original;
6866
6867     string::const_iterator i = alias.begin(), e = alias.end();
6868     for(string::iterator j = original.begin(); j != original.end(); ++j)
6869         *j = '*';
6870     while(i != e)
6871         cout &lt;&lt; *i++;
6872     cout &lt;&lt; endl;
6873     cout &lt;&lt; original &lt;&lt; endl;
6874 </pre>
6875
6876 <p>
6877 Similarly, in the following example:
6878 </p>
6879
6880 <pre>    // second example: "some arbitrary text" should be printed out
6881     string original = "some arbitrary text", copy = original;
6882     const string &amp; alias = original;
6883
6884     string::const_iterator i = alias.begin();
6885     original.begin();
6886     while(i != alias.end())
6887         cout &lt;&lt; *i++;
6888 </pre>
6889
6890 <p>
6891 I have tested this on three string implementations, two of which were
6892 reference counted. The reference-counted implementations gave
6893 "surprising behavior" because they invalidated iterators on
6894 the first call to non-const begin since construction. The current
6895 wording does not permit such invalidation because it does not take
6896 into account the first call since construction, only the first call
6897 since various member and non-member function calls.
6898 </p>
6899 <p><b>Proposed resolution:</b></p>
6900 <p>
6901 Change the following sentence in 21.3 paragraph 5 from
6902 </p>
6903
6904 <blockquote>
6905     Subsequent to any of the above uses except the forms of insert() and
6906     erase() which return iterators, the first call to non-const member
6907     functions operator[](), at(), begin(), rbegin(), end(), or rend().
6908 </blockquote>
6909
6910 <p>to</p>
6911
6912 <blockquote>
6913     Following construction or any of the above uses, except the forms of
6914     insert() and erase() that return iterators, the first call to non-
6915     const member functions operator[](), at(), begin(), rbegin(), end(),
6916     or rend().
6917 </blockquote>
6918 <hr>
6919 <a name="264"><h3>264.&nbsp;Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3></a><p>
6920 <b>Section:</b>&nbsp;23.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;John Potter&nbsp; <b>Date:</b>&nbsp;07 Sep 2000</p>
6921 <p>
6922 Table 69 requires linear time if [i, j) is sorted.  Sorted is necessary but not sufficient.
6923 Consider inserting a sorted range of even integers into a set&lt;int&gt; containing the odd
6924 integers in the same range.
6925 </p>
6926
6927 <p><i>Related issue: <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></i></p>
6928 <p><b>Proposed resolution:</b></p>
6929 <p>
6930 In Table 69, in section 23.1.2, change the complexity clause for
6931 insertion of a range from "N log(size() + N) (N is the distance
6932 from i to j) in general; linear if [i, j) is sorted according to
6933 value_comp()" to "N log(size() + N), where N is the distance
6934 from i to j".
6935 </p>
6936
6937 <p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
6938 parens in the revised wording.]</i></p>
6939
6940 <p><b>Rationale:</b></p>
6941 <p>
6942 Testing for valid insertions could be less efficient than simply
6943 inserting the elements when the range is not both sorted and between
6944 two adjacent existing elements; this could be a QOI issue.
6945 </p>
6946
6947 <p>
6948 The LWG considered two other options: (a) specifying that the
6949 complexity was linear if [i, j) is sorted according to value_comp()
6950 and between two adjacent existing elements; or (b) changing to
6951 Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
6952 number of elements which do not insert immediately after the previous
6953 element from [i, j) including the first).  The LWG felt that, since
6954 we can't guarantee linear time complexity whenever the range to be
6955 inserted is sorted, it's more trouble than it's worth to say that it's
6956 linear in some special cases.
6957 </p>
6958 <hr>
6959 <a name="265"><h3>265.&nbsp;std::pair::pair() effects overly restrictive</h3></a><p>
6960 <b>Section:</b>&nbsp;20.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;11 Sep 2000</p>
6961 <p>
6962 I don't see any requirements on the types of the elements of the
6963 std::pair container in 20.2.2. From the descriptions of the member
6964 functions it appears that they must at least satisfy the requirements of
6965 20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
6966 the case of the [in]equality operators also the requirements of 20.1.1
6967 [lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
6968 </p>
6969
6970 <p>
6971 I believe that the the CopyConstructible requirement is unnecessary in
6972 the case of 20.2.2, p2.
6973 </p>
6974 <p><b>Proposed resolution:</b></p>
6975 <p>Change the Effects clause in 20.2.2, p2 from</p>
6976
6977 <blockquote>
6978 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
6979 first(T1()), second(T2()) {} </tt>
6980 </blockquote>
6981
6982 <p>to</p>
6983
6984 <blockquote>
6985 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
6986 first(), second() {} </tt>
6987 </blockquote>
6988 <p><b>Rationale:</b></p>
6989 <p>The existing specification of pair's constructor appears to be a
6990 historical artifact: there was concern that pair's members be properly
6991 zero-initialized when they are built-in types.  At one time there was
6992 uncertainty about whether they would be zero-initialized if the
6993 default constructor was written the obvious way.  This has been
6994 clarified by core issue 178, and there is no longer any doubt that
6995 the straightforward implementation is correct.</p>
6996 <hr>
6997 <a name="266"><h3>266.&nbsp;bad_exception::~bad_exception() missing Effects clause</h3></a><p>
6998 <b>Section:</b>&nbsp;18.6.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.exception"> [lib.bad.exception]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;24 Sep 2000</p>
6999 <p>
7000 The synopsis for std::bad_exception lists the function ~bad_exception()
7001 but there is no description of what the function does (the Effects
7002 clause is missing).
7003 </p>
7004 <p><b>Proposed resolution:</b></p>
7005 <p>
7006 Remove the destructor from the class synopses of
7007 <tt>bad_alloc</tt> (18.4.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.alloc"> [lib.bad.alloc]</a>),
7008 <tt>bad_cast</tt> (18.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.cast"> [lib.bad.cast]</a>),
7009 <tt>bad_typeid</tt> (18.5.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.typeid"> [lib.bad.typeid]</a>),
7010 and <tt>bad_exception</tt> (18.6.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.exception"> [lib.bad.exception]</a>).
7011 </p>
7012 <p><b>Rationale:</b></p>
7013 <p>
7014 This is a general problem with the exception classes in clause 18.
7015 The proposed resolution is to remove the destructors from the class
7016 synopses, rather than to document the destructors' behavior, because
7017 removing them is more consistent with how exception classes are
7018 described in clause 19.
7019 </p>
7020 <hr>
7021 <a name="268"><h3>268.&nbsp;Typo in locale synopsis</h3></a><p>
7022 <b>Section:</b>&nbsp;22.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Oct 2000</p>
7023 <p>The synopsis of the class std::locale in 22.1.1 contains two typos:
7024 the semicolons after the declarations of the default ctor
7025 locale::locale() and the copy ctor locale::locale(const locale&amp;)
7026 are missing.</p>
7027 <p><b>Proposed resolution:</b></p>
7028 <p>Add the missing semicolons, i.e., change</p>
7029
7030 <pre>    //  construct/copy/destroy:
7031         locale() throw()
7032         locale(const locale&amp; other) throw()
7033 </pre>
7034
7035 <p>in the synopsis in 22.1.1 to</p>
7036
7037 <pre>    //  construct/copy/destroy:
7038         locale() throw();
7039         locale(const locale&amp; other) throw();
7040 </pre>
7041 <hr>
7042 <a name="270"><h3>270.&nbsp;Binary search requirements overly strict</h3></a><p>
7043 <b>Section:</b>&nbsp;25.3.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.binary.search"> [lib.alg.binary.search]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;18 Oct 2000</p>
7044 <p>
7045 Each of the four binary search algorithms (lower_bound, upper_bound,
7046 equal_range, binary_search) has a form that allows the user to pass a
7047 comparison function object.  According to 25.3, paragraph 2, that
7048 comparison function object has to be a strict weak ordering.
7049 </p>
7050
7051 <p>
7052 This requirement is slightly too strict.  Suppose we are searching
7053 through a sequence containing objects of type X, where X is some
7054 large record with an integer key.  We might reasonably want to look
7055 up a record by key, in which case we would want to write something
7056 like this:
7057 </p>
7058 <pre>    struct key_comp {
7059       bool operator()(const X&amp; x, int n) const {
7060         return x.key() &lt; n;
7061       }
7062     }
7063
7064     std::lower_bound(first, last, 47, key_comp());
7065 </pre>
7066
7067 <p>
7068 key_comp is not a strict weak ordering, but there is no reason to
7069 prohibit its use in lower_bound.
7070 </p>
7071
7072 <p>
7073 There's no difficulty in implementing lower_bound so that it allows
7074 the use of something like key_comp.  (It will probably work unless an
7075 implementor takes special pains to forbid it.)  What's difficult is
7076 formulating language in the standard to specify what kind of
7077 comparison function is acceptable.  We need a notion that's slightly
7078 more general than that of a strict weak ordering, one that can encompass
7079 a comparison function that involves different types.  Expressing that
7080 notion may be complicated.
7081 </p>
7082
7083 <p><i>Additional questions raised at the Toronto meeting:</i></p>
7084 <ul>
7085 <li> Do we really want to specify what ordering the implementor must
7086      use when calling the function object?  The standard gives
7087      specific expressions when describing these algorithms, but it also
7088      says that other expressions (with different argument order) are
7089      equivalent.</li>
7090 <li> If we are specifying ordering, note that the standard uses both
7091      orderings when describing <tt>equal_range</tt>.</li>
7092 <li> Are we talking about requiring these algorithms to work properly
7093      when passed a binary function object whose two argument types
7094      are not the same, or are we talking about requirements when
7095      they are passed a binary function object with several overloaded
7096      versions of <tt>operator()</tt>?</li>
7097 <li> The definition of a strict weak ordering does not appear to give
7098      any guidance on issues of overloading; it only discusses expressions,
7099      and all of the values in these expressions are of the same type.
7100      Some clarification would seem to be in order.</li>
7101 </ul>
7102
7103 <p><i>Additional discussion from Copenhagen:</i></p>
7104 <ul>
7105 <li>It was generally agreed that there is a real defect here: if
7106 the predicate is merely required to be a Strict Weak Ordering, then
7107 it's possible to pass in a function object with an overloaded
7108 operator(), where the version that's actually called does something
7109 completely inappropriate.  (Such as returning a random value.)</li>
7110
7111 <li>An alternative formulation was presented in a paper distributed by
7112 David Abrahams at the meeting, "Binary Search with Heterogeneous
7113 Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
7114 predicate as a Strict Weak Ordering acting on a sorted sequence, view
7115 the predicate/value pair as something that partitions a sequence.
7116 This is almost equivalent to saying that we should view binary search
7117 as if we are given a unary predicate and a sequence, such that f(*p)
7118 is true for all p below a specific point and false for all p above it.
7119 The proposed resolution is based on that alternative formulation.</li>
7120 </ul>
7121 <p><b>Proposed resolution:</b></p>
7122
7123 <p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
7124
7125 <blockquote>
7126   3 For all algorithms that take Compare, there is a version that uses
7127   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i &lt;
7128   *j != false. For the algorithms to work correctly, comp has to
7129   induce a strict weak ordering on the values.
7130 </blockquote>
7131
7132 <p>to:</p>
7133
7134 <blockquote>
7135   3 For all algorithms that take Compare, there is a version that uses
7136   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i
7137   &lt; *j != false. For algorithms other than those described in
7138   lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
7139   a strict weak ordering on the values.
7140 </blockquote>
7141
7142 <p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
7143
7144 <blockquote>
7145   -6- A sequence [start, finish) is partitioned with respect to an
7146   expression f(e) if there exists an integer n such that
7147   for all 0 &lt;= i &lt; distance(start, finish), f(*(begin+i)) is true if
7148   and only if i &lt; n.
7149 </blockquote>
7150
7151 <p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
7152
7153 <blockquote>
7154   -1- All of the algorithms in this section are versions of binary
7155    search and assume that the sequence being searched is in order
7156    according to the implied or explicit comparison function. They work
7157    on non-random access iterators minimizing the number of
7158    comparisons, which will be logarithmic for all types of
7159    iterators. They are especially appropriate for random access
7160    iterators, because these algorithms do a logarithmic number of
7161    steps through the data structure. For non-random access iterators
7162    they execute a linear number of steps.
7163 </blockquote>
7164
7165 <p>to:</p>
7166
7167 <blockquote>
7168    -1- All of the algorithms in this section are versions of binary
7169     search and assume that the sequence being searched is partitioned
7170     with respect to an expression formed by binding the search key to
7171     an argument of the implied or explicit comparison function. They
7172     work on non-random access iterators minimizing the number of
7173     comparisons, which will be logarithmic for all types of
7174     iterators. They are especially appropriate for random access
7175     iterators, because these algorithms do a logarithmic number of
7176     steps through the data structure. For non-random access iterators
7177     they execute a linear number of steps.
7178 </blockquote>
7179
7180 <p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
7181
7182 <blockquote>
7183    -1- Requires: Type T is LessThanComparable
7184     (lib.lessthancomparable).
7185 </blockquote>
7186
7187 <p>to:</p>
7188
7189 <blockquote>
7190    -1- Requires: The elements e of [first, last) are partitioned with
7191    respect to the expression e &lt; value or comp(e, value)
7192 </blockquote>
7193
7194
7195 <p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
7196
7197 <blockquote>
7198    -2- Effects: Finds the first position into which value can be
7199     inserted without violating the ordering.
7200 </blockquote>
7201
7202 <p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
7203
7204 <blockquote>
7205   -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
7206 </blockquote>
7207
7208 <p>to:</p>
7209
7210 <blockquote>
7211    -1- Requires: The elements e of [first, last) are partitioned with
7212    respect to the expression !(value &lt; e) or !comp(value, e)
7213 </blockquote>
7214
7215 <p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
7216
7217 <blockquote>
7218    -2- Effects: Finds the furthermost position into which value can be
7219     inserted without violating the ordering.
7220 </blockquote>
7221
7222 <p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
7223
7224 <blockquote>
7225    -1- Requires: Type T is LessThanComparable
7226     (lib.lessthancomparable).
7227 </blockquote>
7228
7229 <p>to:</p>
7230
7231 <blockquote>
7232    -1- Requires: The elements e of [first, last) are partitioned with
7233    respect to the expressions e &lt; value and !(value &lt; e) or
7234    comp(e, value) and !comp(value, e).  Also, for all elements e of
7235    [first, last), e &lt; value implies !(value &lt; e) or comp(e,
7236    value) implies !comp(value, e)
7237 </blockquote>
7238
7239 <p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
7240
7241 <blockquote>
7242    -2- Effects: Finds the largest subrange [i, j) such that the value
7243     can be inserted at any iterator k in it without violating the
7244     ordering. k satisfies the corresponding conditions: !(*k &lt; value)
7245     &amp;&amp; !(value &lt; *k) or comp(*k, value) == false &amp;&amp; comp(value, *k) ==
7246     false.
7247 </blockquote>
7248
7249 <p>to:</p>
7250
7251 <pre>   -2- Returns:
7252          make_pair(lower_bound(first, last, value),
7253                    upper_bound(first, last, value))
7254        or
7255          make_pair(lower_bound(first, last, value, comp),
7256                    upper_bound(first, last, value, comp))
7257 </pre>
7258
7259 <p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
7260
7261 <blockquote>
7262    -1- Requires: Type T is LessThanComparable
7263     (lib.lessthancomparable).
7264 </blockquote>
7265
7266 <p>to:</p>
7267
7268 <blockquote>
7269    -1- Requires: The elements e of [first, last) are partitioned with
7270    respect to the expressions e &lt; value and !(value &lt; e) or comp(e,
7271    value) and !comp(value, e). Also, for all elements e of [first,
7272    last), e &lt; value implies !(value &lt; e) or comp(e, value) implies
7273    !comp(value, e)
7274 </blockquote>
7275
7276 <p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
7277
7278 <p><i>[Redmond: Minor changes in wording.  (Removed "non-negative", and
7279 changed the "other than those described in" wording.) Also, the LWG
7280 decided to accept the "optional" part.]</i></p>
7281
7282 <p><b>Rationale:</b></p>
7283 <p>The proposed resolution reinterprets binary search. Instead of
7284 thinking about searching for a value in a sorted range, we view that
7285 as an important special case of a more general algorithm: searching
7286 for the partition point in a partitioned range.</p>
7287
7288 <p>We also add a guarantee that the old wording did not: we ensure
7289 that the upper bound is no earlier than the lower bound, that
7290 the pair returned by equal_range is a valid range, and that the first
7291 part of that pair is the lower bound.</p>
7292 <hr>
7293 <a name="271"><h3>271.&nbsp;basic_iostream missing typedefs</h3></a><p>
7294 <b>Section:</b>&nbsp;27.6.1.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
7295 <p>
7296 Class template basic_iostream has no typedefs.  The typedefs it
7297 inherits from its base classes can't be used, since (for example)
7298 basic_iostream&lt;T&gt;::traits_type is ambiguous.
7299 </p>
7300 <p><b>Proposed resolution:</b></p>
7301
7302 <p>Add the following to basic_iostream's class synopsis in
7303 27.6.1.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a>, immediately after <tt>public</tt>:</p>
7304
7305 <pre>  // types:
7306   typedef charT                     char_type;
7307   typedef typename traits::int_type int_type;
7308   typedef typename traits::pos_type pos_type;
7309   typedef typename traits::off_type off_type;
7310   typedef traits                    traits_type;
7311 </pre>
7312 <hr>
7313 <a name="272"><h3>272.&nbsp;Missing parentheses around subexpression</h3></a><p>
7314 <b>Section:</b>&nbsp;27.4.4.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
7315 <p>
7316 27.4.4.3, p4 says about the postcondition of the function: If
7317 rdbuf()!=0 then state == rdstate(); otherwise
7318 rdstate()==state|ios_base::badbit.
7319 </p>
7320
7321 <p>
7322 The expression on the right-hand-side of the operator==() needs to be
7323 parenthesized in order for the whole expression to ever evaluate to
7324 anything but non-zero.
7325 </p>
7326 <p><b>Proposed resolution:</b></p>
7327 <p>
7328 Add parentheses like so: rdstate()==(state|ios_base::badbit).
7329 </p>
7330 <hr>
7331 <a name="273"><h3>273.&nbsp;Missing ios_base qualification on members of a dependent class</h3></a><p>
7332 <b>Section:</b>&nbsp;27 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
7333 <p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
7334 27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
7335 That's incorrect since the names are members of a dependent base
7336 class (14.6.2 [temp.dep]) and thus not visible.</p>
7337 <p><b>Proposed resolution:</b></p>
7338 <p>Qualify the names with the name of the class of which they are
7339 members, i.e., ios_base.</p>
7340 <hr>
7341 <a name="274"><h3>274.&nbsp;a missing/impossible allocator requirement</h3></a><p>
7342 <b>Section:</b>&nbsp;20.1.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
7343 <p>
7344 I see that table 31 in 20.1.5, p3 allows T in std::allocator&lt;T&gt; to be of
7345 any type. But the synopsis in 20.4.1 calls for allocator&lt;&gt;::address() to
7346 be overloaded on reference and const_reference, which is ill-formed for
7347 all T = const U. In other words, this won't work:
7348 </p>
7349
7350 <p>
7351 template class std::allocator&lt;const int&gt;;
7352 </p>
7353
7354 <p>
7355 The obvious solution is to disallow specializations of allocators on
7356 const types. However, while containers' elements are required to be
7357 assignable (which rules out specializations on const T's), I think that
7358 allocators might perhaps be potentially useful for const values in other
7359 contexts. So if allocators are to allow const types a partial
7360 specialization of std::allocator&lt;const T&gt; would probably have to be
7361 provided.
7362 </p>
7363 <p><b>Proposed resolution:</b></p>
7364 <p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
7365
7366     <blockquote>
7367     any type
7368     </blockquote>
7369
7370 <p>to</p>
7371     <blockquote>
7372     any non-const, non-reference type
7373     </blockquote>
7374
7375 <p><i>[Redmond: previous proposed resolution was "any non-const,
7376 non-volatile, non-reference type".  Got rid of the "non-volatile".]</i></p>
7377
7378 <p><b>Rationale:</b></p>
7379 <p>
7380 Two resolutions were originally proposed: one that partially
7381 specialized std::allocator for const types, and one that said an
7382 allocator's value type may not be const.  The LWG chose the second.
7383 The first wouldn't be appropriate, because allocators are intended for
7384 use by containers, and const value types don't work in containers.
7385 Encouraging the use of allocators with const value types would only
7386 lead to unsafe code.
7387 </p>
7388 <p>
7389 The original text for proposed resolution 2 was modified so that it
7390 also forbids volatile types and reference types.
7391 </p>
7392
7393 <p><i>[Curaçao: LWG double checked and believes volatile is correctly
7394 excluded from the PR.]</i></p>
7395
7396 <hr>
7397 <a name="275"><h3>275.&nbsp;Wrong type in num_get::get() overloads</h3></a><p>
7398 <b>Section:</b>&nbsp;22.2.2.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
7399 <p>
7400 In 22.2.2.1.1, we have a list of overloads for num_get&lt;&gt;::get().
7401 There are eight overloads, all of which are identical except for the
7402 last parameter.  The overloads are:
7403 </p>
7404 <ul>
7405 <li> long&amp; </li>
7406 <li> unsigned short&amp; </li>
7407 <li> unsigned int&amp; </li>
7408 <li> unsigned long&amp; </li>
7409 <li> short&amp; </li>
7410 <li> double&amp; </li>
7411 <li> long double&amp; </li>
7412 <li> void*&amp; </li>
7413 </ul>
7414
7415 <p>
7416 There is a similar list, in 22.2.2.1.2, of overloads for
7417 num_get&lt;&gt;::do_get().  In this list, the last parameter has
7418 the types:
7419 </p>
7420 <ul>
7421 <li> long&amp; </li>
7422 <li> unsigned short&amp; </li>
7423 <li> unsigned int&amp; </li>
7424 <li> unsigned long&amp; </li>
7425 <li> float&amp; </li>
7426 <li> double&amp; </li>
7427 <li> long double&amp; </li>
7428 <li> void*&amp; </li>
7429 </ul>
7430
7431 <p>
7432 These two lists are not identical.  They should be, since
7433 <tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
7434 the arguments it was given.
7435 </p>
7436 <p><b>Proposed resolution:</b></p>
7437 <p>In 22.2.2.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>, change</p>
7438 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
7439                 ios_base::iostate&amp; err, short&amp; val) const;
7440 </pre>
7441 <p>to</p>
7442 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
7443                 ios_base::iostate&amp; err, float&amp; val) const;
7444 </pre>
7445 <hr>
7446 <a name="276"><h3>276.&nbsp;Assignable requirement for container value type overly strict</h3></a><p>
7447 <b>Section:</b>&nbsp;23.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;07 Nov 2000</p>
7448 <p>
7449 23.1/3 states that the objects stored in a container must be
7450 Assignable.  23.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
7451 states that map satisfies all requirements for a container, while in
7452 the same time defining value_type as pair&lt;const Key, T&gt; - a type
7453 that is not Assignable.
7454 </p>
7455
7456 <p>
7457 It should be noted that there exists a valid and non-contradictory
7458 interpretation of the current text. The wording in 23.1/3 avoids
7459 mentioning value_type, referring instead to "objects stored in a
7460 container." One might argue that map does not store objects of
7461 type map::value_type, but of map::mapped_type instead, and that the
7462 Assignable requirement applies to map::mapped_type, not
7463 map::value_type.
7464 </p>
7465
7466 <p>
7467 However, this makes map a special case (other containers store objects of
7468 type value_type) and the Assignable requirement is needlessly restrictive in
7469 general.
7470 </p>
7471
7472 <p>
7473 For example, the proposed resolution of active library issue
7474 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> is to make set::iterator a constant iterator; this
7475 means that no set operations can exploit the fact that the stored
7476 objects are Assignable.
7477 </p>
7478
7479 <p>
7480 This is related to, but slightly broader than, closed issue
7481 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>.
7482 </p>
7483 <p><b>Proposed resolution:</b></p>
7484 <p>23.1/3: Strike the trailing part of the sentence:</p>
7485     <blockquote>
7486     , and the additional requirements of Assignable types from 23.1/3
7487     </blockquote>
7488 <p>so that it reads:</p>
7489     <blockquote>
7490     -3- The type of objects stored in these components must meet the
7491     requirements of CopyConstructible types (lib.copyconstructible).
7492     </blockquote>
7493
7494 <p>23.1/4: Modify to make clear that this requirement is not for all
7495 containers.  Change to:</p>
7496
7497 <blockquote>
7498 -4- Table 64 defines the Assignable requirement.  Some containers
7499 require this property of the types to be stored in the container.  T is
7500 the type used to instantiate the container. t is a value of T, and u is
7501 a value of (possibly const) T.
7502 </blockquote>
7503
7504 <p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
7505 CopyConstructible".</p>
7506
7507 <p>23.2.1/2: Add sentence for Assignable requirement.  Change to:</p>
7508
7509 <blockquote>
7510 -2- A deque satisfies all of the requirements of a container and of a
7511 reversible container (given in tables in lib.container.requirements) and
7512 of a sequence, including the optional sequence requirements
7513 (lib.sequence.reqmts).  In addition to the requirements on the stored
7514 object described in 23.1[lib.container.requirements], the stored object
7515 must also meet the requirements of Assignable.  Descriptions are
7516 provided here only for operations on deque that are not described in one
7517 of these tables or for operations where there is additional semantic
7518 information.
7519 </blockquote>
7520
7521 <p>23.2.2/2:  Add Assignable requirement to specific methods of list.
7522 Change to:</p>
7523
7524 <blockquote>
7525 <p>-2- A list satisfies all of the requirements of a container and of a
7526 reversible container (given in two tables in lib.container.requirements)
7527 and of a sequence, including most of the the optional sequence
7528 requirements (lib.sequence.reqmts). The exceptions are the operator[]
7529 and at member functions, which are not provided.
7530
7531 [Footnote: These member functions are only provided by containers whose
7532 iterators are random access iterators. --- end foonote]
7533 </p>
7534
7535 <p>list does not require the stored type T to be Assignable unless the
7536 following methods are instantiated:
7537
7538 [Footnote: Implementors are permitted but not required to take advantage
7539 of T's Assignable properties for these methods. -- end foonote]
7540 </p>
7541 <pre>     list&lt;T,Allocator&gt;&amp; operator=(const list&lt;T,Allocator&gt;&amp;  x );
7542      template &lt;class InputIterator&gt;
7543        void assign(InputIterator first, InputIterator last);
7544      void assign(size_type n, const T&amp; t);
7545 </pre>
7546
7547
7548 <p>Descriptions are provided here only for operations on list that are not
7549 described in one of these tables or for operations where there is
7550 additional semantic information.</p>
7551 </blockquote>
7552
7553 <p>23.2.4/2:   Add sentence for Assignable requirement.  Change to:</p>
7554
7555 <blockquote>
7556 -2- A vector satisfies all of the requirements of a container and of a
7557 reversible container (given in two tables in lib.container.requirements)
7558 and of a sequence, including most of the optional sequence requirements
7559 (lib.sequence.reqmts). The exceptions are the push_front and pop_front
7560 member functions, which are not provided.  In addition to the
7561 requirements on the stored object described in
7562 23.1[lib.container.requirements], the stored object must also meet the
7563 requirements of Assignable.  Descriptions are provided here only for
7564 operations on vector that are not described in one of these tables or
7565 for operations where there is additional semantic information.
7566 </blockquote>
7567 <p><b>Rationale:</b></p>
7568 <p>list, set, multiset, map, multimap are able to store non-Assignables.
7569 However, there is some concern about <tt>list&lt;T&gt;</tt>:
7570 although in general there's no reason for T to be Assignable, some
7571 implementations of the member functions <tt>operator=</tt> and
7572 <tt>assign</tt> do rely on that requirement.  The LWG does not want
7573 to forbid such implementations.</p>
7574
7575 <p>Note that the type stored in a standard container must still satisfy
7576 the requirements of the container's allocator; this rules out, for
7577 example, such types as "const int".  See issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#274">274</a>
7578 for more details.
7579 </p>
7580
7581 <p>In principle we could also relax the "Assignable" requirement for
7582 individual <tt>vector</tt> member functions, such as
7583 <tt>push_back</tt>.  However, the LWG did not see great value in such
7584 selective relaxation.  Doing so would remove implementors' freedom to
7585 implement <tt>vector::push_back</tt> in terms of
7586 <tt>vector::insert</tt>.</p>
7587
7588 <hr>
7589 <a name="278"><h3>278.&nbsp;What does iterator validity mean?</h3></a><p>
7590 <b>Section:</b>&nbsp;23.2.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;P.J. Plauger&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
7591 <p>
7592 Section 23.2.2.4 [lib.list.ops] states that
7593 </p>
7594 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
7595 </pre>
7596 <p>
7597 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
7598 </p>
7599
7600 <p>
7601 But what does the C++ Standard mean by "invalidate"?  You
7602 can still dereference the iterator to a spliced list element, but
7603 you'd better not use it to delimit a range within the original
7604 list. For the latter operation, it has definitely lost some of its
7605 validity.
7606 </p>
7607
7608 <p>
7609 If we accept the proposed resolution to issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>,
7610 then we'd better clarify that a "valid" iterator need no
7611 longer designate an element within the same container as it once did.
7612 We then have to clarify what we mean by invalidating a past-the-end
7613 iterator, as when a vector or string grows by reallocation. Clearly,
7614 such an iterator has a different kind of validity. Perhaps we should
7615 introduce separate terms for the two kinds of "validity."
7616 </p>
7617 <p><b>Proposed resolution:</b></p>
7618 <p>Add the following text to the end of section 24.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>,
7619 after paragraph 5:</p>
7620 <blockquote>
7621 An <i>invalid</i> iterator is an iterator that may be
7622 singular. [Footnote: This definition applies to pointers, since
7623 pointers are iterators. The effect of dereferencing an iterator that
7624 has been invalidated is undefined.]
7625 </blockquote>
7626
7627 <p><i>[post-Copenhagen: Matt provided wording.]</i></p>
7628
7629 <p><i>[Redmond: General agreement with the intent, some objections to
7630 the wording.  Dave provided new wording.]</i></p>
7631 <p><b>Rationale:</b></p>
7632 <p>This resolution simply defines a term that the Standard uses but
7633   never defines, "invalid", in terms of a term that is defined,
7634   "singular".</p>
7635
7636 <p>Why do we say "may be singular", instead of "is singular"?  That's
7637   becuase a valid iterator is one that is known to be nonsingular.
7638   Invalidating an iterator means changing it in such a way that it's
7639   no longer known to be nonsingular.  An example: inserting an
7640   element into the middle of a vector is correctly said to invalidate
7641   all iterators pointing into the vector.  That doesn't necessarily
7642   mean they all become singular.</p>
7643 <hr>
7644 <a name="281"><h3>281.&nbsp;std::min() and max() requirements overly restrictive</h3></a><p>
7645 <b>Section:</b>&nbsp;25.3.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Dec 2000</p>
7646 <p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
7647 requirements of <tt>LessThanComparable</tt> (20.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>)
7648 and <tt>CopyConstructible</tt> (20.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>).
7649 Since the functions take and return their arguments and result by
7650 const reference, I believe the <tt>CopyConstructible</tt> requirement
7651 is unnecessary.
7652 </p>
7653 <p><b>Proposed resolution:</b></p>
7654 <p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
7655 25.3.7, p1 with</p>
7656 <p>
7657 <b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt>
7658 (20.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
7659 </p>
7660 <p>and replace 25.3.7, p4 with</p>
7661 <p>
7662 <b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt>
7663 (20.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
7664 </p>
7665 <hr>
7666 <a name="282"><h3>282.&nbsp;What types does numpunct grouping refer to?</h3></a><p>
7667 <b>Section:</b>&nbsp;22.2.2.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;5 Dec 2000</p>
7668 <p>
7669 Paragraph 16 mistakenly singles out integral types for inserting
7670 thousands_sep() characters.  This conflicts with the syntax for floating
7671 point numbers described under 22.2.3.1/2.
7672 </p>
7673 <p><b>Proposed resolution:</b></p>
7674 <p>Change paragraph 16 from:</p>
7675
7676 <blockquote>
7677 For integral types, punct.thousands_sep() characters are inserted into
7678 the sequence as determined by the value returned by punct.do_grouping()
7679 using the method described in 22.2.3.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>.
7680 </blockquote>
7681
7682 <p>To:</p>
7683
7684 <blockquote>
7685 For arithmetic types, punct.thousands_sep() characters are inserted into
7686 the sequence as determined by the value returned by punct.do_grouping()
7687 using the method described in 22.2.3.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>.
7688 </blockquote>
7689
7690 <p><i>[
7691 Copenhagen: Opinions were divided about whether this is actually an
7692 inconsistency, but at best it seems to have been unintentional.  This
7693 is only an issue for floating-point output: The standard is
7694 unambiguous that implementations must parse thousands_sep characters
7695 when performing floating-point.  The standard is also unambiguous that
7696 this requirement does not apply to the "C" locale.
7697 ]</i></p>
7698
7699 <p><i>[
7700 A survey of existing practice is needed; it is believed that some
7701 implementations do insert thousands_sep characters for floating-point
7702 output and others fail to insert thousands_sep characters for
7703 floating-point input even though this is unambiguously required by the
7704 standard.
7705 ]</i></p>
7706
7707 <p><i>[Post-Curaçao: the above proposed resolution is the consensus of
7708 Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
7709
7710 <hr>
7711 <a name="284"><h3>284.&nbsp;unportable example in 20.3.7, p6</h3></a><p>
7712 <b>Section:</b>&nbsp;20.3.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;26 Dec 2000</p>
7713 <p>The example in 20.3.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a>, p6 shows how to use the C
7714 library function <tt>strcmp()</tt> with the function pointer adapter
7715 <tt>ptr_fun()</tt>. But since it's unspecified whether the C library
7716 functions have <tt>extern "C"</tt> or <tt>extern
7717 "C++"</tt> linkage [17.4.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a>], and since
7718 function pointers with different the language linkage specifications
7719 (7.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/dcl.html#dcl.link"> [dcl.link]</a>) are incompatible, whether this example is
7720 well-formed is unspecified.
7721 </p>
7722 <p><b>Proposed resolution:</b></p>
7723 <p>Change 20.3.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a> paragraph 6 from:</p>
7724 <blockquote>
7725   <p>[<i>Example:</i>
7726 </p>
7727   <pre>    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
7728   </pre>
7729   <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
7730 </blockquote>
7731
7732
7733 <p>to:</p>
7734 <blockquote>
7735   <p>[<i>Example:</i>
7736 </p>
7737   <pre>    int compare(const char*, const char*);
7738     replace_if(v.begin(), v.end(),
7739                not1(bind2nd(ptr_fun(compare), "abc")), "def");
7740   </pre>
7741   <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
7742 </blockquote>
7743
7744 <p>Also, remove footnote 215 in that same paragraph.</p>
7745
7746 <p><i>[Copenhagen: Minor change in the proposed resolution.  Since this
7747 issue deals in part with C and C++ linkage, it was believed to be too
7748 confusing for the strings in the example to be "C" and "C++".
7749 ]</i></p>
7750
7751 <p><i>[Redmond: More minor changes.  Got rid of the footnote (which
7752 seems to make a sweeping normative requirement, even though footnotes
7753 aren't normative), and changed the sentence after the footnote so that
7754 it corresponds to the new code fragment.]</i></p>
7755
7756 <hr>
7757 <a name="285"><h3>285.&nbsp;minor editorial errors in fstream ctors</h3></a><p>
7758 <b>Section:</b>&nbsp;27.8.1.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.cons"> [lib.ifstream.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;31 Dec 2000</p>
7759 <p>27.8.1.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.cons"> [lib.ifstream.cons]</a>, p2, 27.8.1.9 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.cons"> [lib.ofstream.cons]</a>, p2, and
7760 27.8.1.12 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.cons"> [lib.fstream.cons]</a>, p2 say about the effects of each constructor:
7761 </p>
7762
7763 <p>... If that function returns a null pointer, calls
7764 <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
7765 </p>
7766
7767 <p>The parenthetical note doesn't apply since the ctors cannot throw an
7768 exception due to the requirement in 27.4.4.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>, p3
7769 that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
7770 </p>
7771 <p><b>Proposed resolution:</b></p>
7772 <p>
7773 Strike the parenthetical note from the Effects clause in each of the
7774 paragraphs mentioned above.
7775 </p>
7776 <hr>
7777 <a name="286"><h3>286.&nbsp;&lt;cstdlib&gt; requirements missing size_t typedef</h3></a><p>
7778 <b>Section:</b>&nbsp;25.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;30 Dec 2000</p>
7779 <p>
7780 The &lt;cstdlib&gt; header file contains prototypes for bsearch and
7781 qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
7782 prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
7783 require the typedef size_t. Yet size_t is not listed in the
7784 &lt;cstdlib&gt; synopsis table 78 in section 25.4.
7785 </p>
7786 <p><b>Proposed resolution:</b></p>
7787 <p>
7788 Add the type size_t to Table 78 (section 25.4) and add
7789 the type size_t &lt;cstdlib&gt; to Table 97 (section C.2).
7790 </p>
7791 <p><b>Rationale:</b></p>
7792 <p>Since size_t is in &lt;stdlib.h&gt;, it must also be in &lt;cstdlib&gt;.</p>
7793 <hr>
7794 <a name="288"><h3>288.&nbsp;&lt;cerrno&gt; requirements missing macro EILSEQ</h3></a><p>
7795 <b>Section:</b>&nbsp;19.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.errno"> [lib.errno]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;30 Dec 2000</p>
7796 <p>
7797 ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
7798 of macros defined in &lt;errno.h&gt; is adjusted to include a new
7799 macro, EILSEQ"
7800 </p>
7801
7802 <p>
7803 ISO/IEC 14882:1998(E) section 19.3 does not refer
7804 to the above amendment.
7805 </p>
7806
7807 <p><b>Proposed resolution:</b></p>
7808 <p>
7809 Update Table 26 (section 19.3) "Header  &lt;cerrno&gt; synopsis"
7810 and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
7811 </p>
7812 <hr>
7813 <a name="292"><h3>292.&nbsp;effects of a.copyfmt (a)</h3></a><p>
7814 <b>Section:</b>&nbsp;27.4.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;05 Jan 2001</p>
7815 <p>The Effects clause of the member function <tt>copyfmt()</tt> in
7816 27.4.4.2, p15 doesn't consider the case where the left-hand side
7817 argument is identical to the argument on the right-hand side, that is
7818 <tt>(this == &amp;rhs)</tt>.  If the two arguments are identical there
7819 is no need to copy any of the data members or call any callbacks
7820 registered with <tt>register_callback()</tt>.  Also, as Howard Hinnant
7821 points out in message c++std-lib-8149 it appears to be incorrect to
7822 allow the object to fire <tt>erase_event</tt> followed by
7823 <tt>copyfmt_event</tt> since the callback handling the latter event
7824 may inadvertently attempt to access memory freed by the former.
7825 </p>
7826 <p><b>Proposed resolution:</b></p>
7827 <p>Change the Effects clause in 27.4.4.2, p15 from</p>
7828
7829 <blockquote>
7830 <b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
7831 the corresponding member objects of <tt>rhs</tt>, except that...
7832 </blockquote>
7833
7834 <p>to</p>
7835
7836 <blockquote>
7837 <b>-15- Effects:</b>If <tt>(this == &amp;rhs)</tt> does nothing. Otherwise
7838 assigns to the member objects of <tt>*this</tt> the corresponding member
7839 objects of <tt>rhs</tt>, except that...
7840 </blockquote>
7841 <hr>
7842 <a name="295"><h3>295.&nbsp;Is abs defined in &lt;cmath&gt;?</h3></a><p>
7843 <b>Section:</b>&nbsp;26.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Jens Maurer&nbsp; <b>Date:</b>&nbsp;12 Jan 2001</p>
7844 <p>
7845 Table 80 lists the contents of the &lt;cmath&gt; header.  It does not
7846 list <tt>abs()</tt>.  However, 26.5, paragraph 6, which lists added
7847 signatures present in &lt;cmath&gt;, does say that several overloads
7848 of <tt>abs()</tt> should be defined in &lt;cmath&gt;.
7849 </p>
7850 <p><b>Proposed resolution:</b></p>
7851 <p>
7852 Add <tt>abs</tt> to Table 80.  Also, remove the parenthetical list
7853 of functions "(abs(), div(), rand(), srand())" from 26.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a>,
7854 paragraph 1.
7855 </p>
7856
7857 <p><i>[Copenhagen: Modified proposed resolution so that it also gets
7858 rid of that vestigial list of functions in paragraph 1.]</i></p>
7859
7860 <p><b>Rationale:</b></p>
7861 <p>All this DR does is fix a typo; it's uncontroversial.  A
7862 separate question is whether we're doing the right thing in
7863 putting some overloads in &lt;cmath&gt; that we aren't also
7864 putting in &lt;cstdlib&gt;.  That's issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</p>
7865 <hr>
7866 <a name="297"><h3>297.&nbsp;const_mem_fun_t&lt;&gt;::argument_type should be const T*</h3></a><p>
7867 <b>Section:</b>&nbsp;20.3.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.member.pointer.adaptors"> [lib.member.pointer.adaptors]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Jan 2001</p>
7868 <p>The class templates <tt>const_mem_fun_t</tt> in 20.3.8, p8 and
7869 <tt>const_mem_fun1_t</tt>
7870 in 20.3.8, p9 derive from <tt>unary_function&lt;T*, S&gt;</tt>, and
7871 <tt>binary_function&lt;T*,
7872 A, S&gt;</tt>, respectively. Consequently, their <tt>argument_type</tt>, and
7873 <tt>first_argument_type</tt>
7874 members, respectively, are both defined to be <tt>T*</tt> (non-const).
7875 However, their function call member operator takes a <tt>const T*</tt>
7876 argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
7877 T*</tt> instead, so that one can easily refer to it in generic code. The
7878 example below derived from existing code fails to compile due to the
7879 discrepancy:
7880 </p>
7881
7882 <p>
7883 <tt>template &lt;class T&gt;</tt>
7884 <br><tt>void foo (typename T::argument_type arg)&nbsp;&nbsp; // #1</tt>
7885 <br><tt>{</tt>
7886 <br><tt>&nbsp;&nbsp;&nbsp; typename T::result_type (T::*pf) (typename
7887 T::argument_type)
7888 const =&nbsp;&nbsp; // #2</tt>
7889 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;T::operator();</tt>
7890 <br><tt>}</tt>
7891 </p>
7892
7893 <p><tt>struct X { /* ... */ };</tt></p>
7894
7895 <p>
7896 <tt>int main ()</tt>
7897 <br><tt>{</tt>
7898 <br><tt>&nbsp;&nbsp;&nbsp; const X x;</tt>
7899 <br><tt>&nbsp;&nbsp;&nbsp; foo&lt;std::const_mem_fun_t&lt;void, X&gt;
7900 &gt;(&amp;x);&nbsp;&nbsp;
7901 // #3</tt>
7902 <br><tt>}</tt>
7903 </p>
7904
7905 <p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
7906 <br>#2 the type of the pointer is incompatible with the type of the member
7907 function
7908 <br>#3 the address of a constant being passed to a function taking a non-const
7909 <tt>X*</tt>
7910 </p>
7911 <p><b>Proposed resolution:</b></p>
7912 <p>Replace the top portion of the definition of the class template
7913 const_mem_fun_t in 20.3.8, p8
7914 </p>
7915 <p>
7916 <tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
7917 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
7918 unary_function&lt;T*, S&gt; {</tt>
7919 </p>
7920 <p>with</p>
7921 <p>
7922 <tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
7923 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
7924 unary_function&lt;<b>const</b> T*, S&gt; {</tt>
7925 </p>
7926 <p>Also replace the top portion of the definition of the class template
7927 const_mem_fun1_t in 20.3.8, p9</p>
7928 <p>
7929 <tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
7930 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
7931 binary_function&lt;T*, A, S&gt; {</tt>
7932 </p>
7933 <p>with</p>
7934 <p>
7935 <tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
7936 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
7937 binary_function&lt;<b>const</b> T*, A, S&gt; {</tt>
7938 </p>
7939 <p><b>Rationale:</b></p>
7940 <p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
7941 and the argument type itself, are not the same.</p>
7942 <hr>
7943 <a name="298"><h3>298.&nbsp;::operator delete[] requirement incorrect/insufficient</h3></a><p>
7944 <b>Section:</b>&nbsp;18.4.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;John A. Pedretti&nbsp; <b>Date:</b>&nbsp;10 Jan 2001</p>
7945 <p>
7946 The default behavior of <tt>operator delete[]</tt> described in 18.4.1.2, p12 -
7947 namely that for non-null value of <i>ptr</i>, the operator reclaims storage
7948 allocated by the earlier call to the default <tt>operator new[]</tt> - is not
7949 correct in all cases. Since the specified <tt>operator new[]</tt> default
7950 behavior is to call <tt>operator new</tt> (18.4.1.2, p4, p8), which can be
7951 replaced, along with <tt>operator delete</tt>, by the user, to implement their
7952 own memory management, the specified default behavior of<tt> operator
7953 delete[]</tt> must be to call <tt>operator delete</tt>.
7954 </p>
7955 <p><b>Proposed resolution:</b></p>
7956 <p>Change 18.4.1.2, p12 from</p>
7957 <blockquote>
7958 <b>-12-</b> <b>Default behavior:</b>
7959 <ul>
7960 <li>
7961 For a null value of <i><tt>ptr</tt></i> , does nothing.
7962 </li>
7963 <li>
7964 Any other value of <i><tt>ptr</tt></i> shall be a value returned
7965 earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
7966 [Footnote: The value must not have been invalidated by an intervening
7967 call to <tt>operator delete[](void*)</tt> (17.4.3.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.arguments"> [lib.res.on.arguments]</a>).
7968 --- end footnote]
7969 For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
7970 allocated by the earlier call to the default <tt>operator new[]</tt>.
7971 </li>
7972 </ul>
7973 </blockquote>
7974
7975 <p>to</p>
7976
7977 <blockquote>
7978 <b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
7979 delete(</tt><i>ptr</i>)
7980 or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
7981 </blockquote>
7982 <p>and expunge paragraph 13.</p>
7983 <hr>
7984 <a name="300"><h3>300.&nbsp;list::merge() specification incomplete</h3></a><p>
7985 <b>Section:</b>&nbsp;23.2.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;John Pedretti&nbsp; <b>Date:</b>&nbsp;23 Jan 2001</p>
7986 <p>
7987 The "Effects" clause for list::merge() (23.2.2.4, p23)
7988 appears to be incomplete: it doesn't cover the case where the argument
7989 list is identical to *this (i.e., this == &amp;x). The requirement in the
7990 note in p24 (below) is that x be empty after the merge which is surely
7991 unintended in this case.
7992 </p>
7993 <p><b>Proposed resolution:</b></p>
7994 <p>In 23.2.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraps 23-25 with:</p>
7995 <blockquote>
7996 <p>
7997 23 Effects: if (&amp;x == this) does nothing; otherwise, merges the two
7998 sorted ranges [begin(), end()) and [x.begin(), x.end()).  The result
7999 is a range in which the elements will be sorted in non-decreasing
8000 order according to the ordering defined by comp; that is, for every
8001 iterator i in the range other than the first, the condition comp(*i,
8002 *(i - 1)) will be false.
8003 </p>
8004
8005 <p>
8006 24 Notes: Stable: if (&amp;x != this), then for equivalent elements in the
8007 two original ranges, the elements from the original range [begin(),
8008 end()) always precede the elements from the original range [x.begin(),
8009 x.end()).  If (&amp;x != this) the range [x.begin(), x.end()) is empty
8010 after the merge.
8011 </p>
8012
8013 <p>
8014 25 Complexity: At most size() + x.size() - 1 applications of comp if
8015 (&amp;x !  = this); otherwise, no applications of comp are performed.  If
8016 an exception is thrown other than by a comparison there are no
8017 effects.
8018 </p>
8019
8020 </blockquote>
8021
8022 <p><i>[Copenhagen: The original proposed resolution did not fix all of
8023 the problems in 23.2.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, p22-25.  Three different
8024 paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
8025 Changing p23, without changing the other two, appears to introduce
8026 contradictions.  Additionally, "merges the argument list into the
8027 list" is excessively vague.]</i></p>
8028
8029 <p><i>[Post-Curaçao: Robert Klarer provided new wording.]</i></p>
8030
8031 <hr>
8032 <a name="301"><h3>301.&nbsp;basic_string template ctor effects clause omits allocator argument</h3></a><p>
8033 <b>Section:</b>&nbsp;21.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Jan 2001</p>
8034 <p>
8035 The effects clause for the basic_string template ctor in 21.3.1, p15
8036 leaves out the third argument of type Allocator. I believe this to be
8037 a mistake.
8038 </p>
8039 <p><b>Proposed resolution:</b></p>
8040 <p>Replace</p>
8041
8042 <blockquote>
8043     <p>
8044 <b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
8045     type, equivalent to</p>
8046
8047     <blockquote><tt>basic_string(static_cast&lt;size_type&gt;(begin),
8048     static_cast&lt;value_type&gt;(end))</tt></blockquote>
8049 </blockquote>
8050
8051 <p>with</p>
8052
8053 <blockquote>
8054     <p>
8055 <b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
8056     type, equivalent to</p>
8057
8058     <blockquote><tt>basic_string(static_cast&lt;size_type&gt;(begin),
8059     static_cast&lt;value_type&gt;(end), <b>a</b>)</tt></blockquote>
8060 </blockquote>
8061 <hr>
8062 <a name="303"><h3>303.&nbsp;Bitset input operator underspecified</h3></a><p>
8063 <b>Section:</b>&nbsp;23.3.5.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.operators"> [lib.bitset.operators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;5 Feb 2001</p>
8064 <p>
8065 In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
8066 "Extracts up to <i>N</i> (single-byte) characters from
8067 <i>is</i>.", where <i>is</i> is a stream of type
8068 <tt>basic_istream&lt;charT, traits&gt;</tt>.
8069 </p>
8070
8071 <p>
8072 The standard does not say what it means to extract single byte
8073 characters from a stream whose character type, <tt>charT</tt>, is in
8074 general not a single-byte character type.  Existing implementations
8075 differ.
8076 </p>
8077
8078 <p>
8079 A reasonable solution will probably involve <tt>widen()</tt> and/or
8080 <tt>narrow()</tt>, since they are the supplied mechanism for
8081 converting a single character between <tt>char</tt> and
8082 arbitrary <tt>charT</tt>.
8083 </p>
8084
8085 <p>Narrowing the input characters is not the same as widening the
8086 literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
8087 locales in which more than one wide character maps to the narrow
8088 character <tt>'0'</tt>.  Narrowing means that alternate
8089 representations may be used for bitset input, widening means that
8090 they may not be.</p>
8091
8092 <p>Note that for numeric input, <tt>num_get&lt;&gt;</tt>
8093 (22.2.2.1.2/8) compares input characters to widened version of narrow
8094 character literals.</p>
8095
8096 <p>From Pete Becker, in c++std-lib-8224:</p>
8097 <blockquote>
8098 <p>
8099 Different writing systems can have different representations for the
8100 digits that represent 0 and 1. For example, in the Unicode representation
8101 of the Devanagari script (used in many of the Indic languages) the digit 0
8102 is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
8103 into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
8104 0x0031 for for the Latin representations of '0' and '1', as well as code
8105 points for the same numeric values in several other scripts (Tamil has no
8106 character for 0, but does have the digits 1-9), and any of these values
8107 would also be narrowed to '0' and '1'.
8108 </p>
8109
8110 <p>...</p>
8111
8112 <p>
8113 It's fairly common to intermix both native and Latin
8114 representations of numbers in a document. So I think the rule has to be
8115 that if a wide character represents a digit whose value is 0 then the bit
8116 should be cleared; if it represents a digit whose value is 1 then the bit
8117 should be set; otherwise throw an exception. So in a Devanagari locale,
8118 both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
8119 would set it. Widen can't do that. It would pick one of those two values,
8120 and exclude the other one.
8121 </p>
8122
8123 </blockquote>
8124
8125 <p>From Jens Maurer, in c++std-lib-8233:</p>
8126
8127 <blockquote>
8128 <p>
8129 Whatever we decide, I would find it most surprising if
8130 bitset conversion worked differently from int conversion
8131 with regard to alternate local representations of
8132 numbers.
8133 </p>
8134
8135 <p>Thus, I think the options are:</p>
8136 <ul>
8137  <li> Have a new defect issue for 22.2.2.1.2/8 so that it will
8138 require the use of narrow().</li>
8139
8140  <li> Have a defect issue for bitset() which describes clearly
8141 that widen() is to be used.</li>
8142 </ul>
8143 </blockquote>
8144 <p><b>Proposed resolution:</b></p>
8145
8146     <p>Replace the first two sentences of paragraph 5 with:</p>
8147
8148     <blockquote>
8149     Extracts up to <i>N</i> characters from <i>is</i>. Stores these
8150     characters in a temporary object <i>str</i> of type
8151     <tt>basic_string&lt;charT, traits&gt;</tt>, then evaluates the
8152     expression <tt><i>x</i> = bitset&lt;N&gt;(<i>str</i>)</tt>.
8153     </blockquote>
8154
8155     <p>Replace the third bullet item in paragraph 5 with:</p>
8156     <ul><li>
8157     the next input character is neither <tt><i>is</i>.widen(0)</tt>
8158     nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
8159     is not extracted).
8160     </li></ul>
8161
8162 <p><b>Rationale:</b></p>
8163 <p>Input for <tt>bitset</tt> should work the same way as numeric
8164 input.  Using <tt>widen</tt> does mean that alternative digit
8165 representations will not be recognized, but this was a known
8166 consequence of the design choice.</p>
8167 <hr>
8168 <a name="305"><h3>305.&nbsp;Default behavior of codecvt&lt;wchar_t, char, mbstate_t&gt;::length()</h3></a><p>
8169 <b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;24 Jan 2001</p>
8170 <p>22.2.1.5/3 introduces codecvt in part with:</p>
8171
8172 <blockquote>
8173   codecvt&lt;wchar_t,char,mbstate_t&gt; converts between the native
8174   character sets for tiny and wide characters. Instantiations on
8175   mbstate_t perform conversion between encodings known to the library
8176   implementor.
8177 </blockquote>
8178
8179 <p>But 22.2.1.5.2/10 describes do_length in part with:</p>
8180
8181 <blockquote>
8182   ... codecvt&lt;wchar_t, char, mbstate_t&gt; ... return(s) the lesser of max and
8183   (from_end-from).
8184 </blockquote>
8185
8186 <p>
8187 The semantics of do_in and do_length are linked.  What one does must
8188 be consistent with what the other does.  22.2.1.5/3 leads me to
8189 believe that the vendor is allowed to choose the algorithm that
8190 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in performs so that it makes
8191 his customers happy on a given platform.  But 22.2.1.5.2/10 explicitly
8192 says what codecvt&lt;wchar_t,char,mbstate_t&gt;::do_length must
8193 return.  And thus indirectly specifies the algorithm that
8194 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in must perform.  I believe
8195 that this is not what was intended and is a defect.
8196 </p>
8197
8198 <p>Discussion from the -lib reflector:
8199
8200 <br>This proposal would have the effect of making the semantics of
8201 all of the virtual functions in <tt>codecvt&lt;wchar_t, char,
8202 mbstate_t&gt;</tt> implementation specified.  Is that what we want, or
8203 do we want to mandate specific behavior for the base class virtuals
8204 and leave the implementation specified behavior for the codecvt_byname
8205 derived class?  The tradeoff is that former allows implementors to
8206 write a base class that actually does something useful, while the
8207 latter gives users a way to get known and specified---albeit
8208 useless---behavior, and is consistent with the way the standard
8209 handles other facets.  It is not clear what the original intention
8210 was.</p>
8211
8212 <p>
8213 Nathan has suggest a compromise: a character that is a widened version
8214 of the characters in the basic execution character set must be
8215 converted to a one-byte sequence, but there is no such requirement
8216 for characters that are not part of the basic execution character set.
8217 </p>
8218 <p><b>Proposed resolution:</b></p>
8219 <p>
8220 Change 22.2.1.5.2/5 from:
8221 </p>
8222 <p>
8223 The instantiations required in Table 51 (lib.locale.category), namely
8224 codecvt&lt;wchar_t,char,mbstate_t&gt; and
8225 codecvt&lt;char,char,mbstate_t&gt;, store no characters. Stores no more
8226 than (to_limit-to) destination elements. It always leaves the to_next
8227 pointer pointing one beyond the last element successfully stored.
8228 </p>
8229 <p>
8230 to:
8231 </p>
8232 <p>
8233 Stores no more than (to_limit-to) destination elements, and leaves the
8234 to_next pointer pointing one beyond the last element successfully
8235 stored.  codecvt&lt;char,char,mbstate_t&gt; stores no characters.
8236 </p>
8237
8238 <p>Change 22.2.1.5.2/10 from:</p>
8239
8240 <blockquote>
8241 -10- Returns: (from_next-from) where from_next is the largest value in
8242 the range [from,from_end] such that the sequence of values in the
8243 range [from,from_next) represents max or fewer valid complete
8244 characters of type internT. The instantiations required in Table 51
8245 (21.1.1.1.1), namely codecvt&lt;wchar_t, char, mbstate_t&gt; and
8246 codecvt&lt;char, char, mbstate_t&gt;, return the lesser of max and
8247 (from_end-from).
8248 </blockquote>
8249
8250 <p>to:</p>
8251
8252 <blockquote>
8253 -10- Returns: (from_next-from) where from_next is the largest value in
8254 the range [from,from_end] such that the sequence of values in the range
8255 [from,from_next) represents max or fewer valid complete characters of
8256 type internT. The instantiation codecvt&lt;char, char, mbstate_t&gt; returns
8257 the lesser of max and (from_end-from).
8258 </blockquote>
8259
8260 <p><i>[Redmond: Nathan suggested an alternative resolution: same as
8261 above, but require that, in the default encoding, a character from the
8262 basic execution character set would map to a single external
8263 character.  The straw poll was 8-1 in favor of the proposed
8264 resolution.]</i></p>
8265
8266 <p><b>Rationale:</b></p>
8267 <p>The default encoding should be whatever users of a given platform
8268 would expect to be the most natural.  This varies from platform to
8269 platform.  In many cases there is a preexisting C library, and users
8270 would expect the default encoding to be whatever C uses in the default
8271 "C" locale.  We could impose a guarantee like the one Nathan suggested
8272 (a character from the basic execution character set must map to a
8273 single external character), but this would rule out important
8274 encodings that are in common use: it would rule out JIS, for
8275 example, and it would rule out a fixed-width encoding of UCS-4.</p>
8276
8277 <p><i>[Curaçao: fixed rationale typo at the request of Ichiro Koshida;
8278 "shift-JIS" changed to "JIS".]</i></p>
8279
8280 <hr>
8281 <a name="306"><h3>306.&nbsp;offsetof macro and non-POD types</h3></a><p>
8282 <b>Section:</b>&nbsp;18.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.support.types"> [lib.support.types]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;21 Feb 2001</p>
8283 <p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
8284
8285 <p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
8286 accepts a restricted set of <i>type</i> arguments in this
8287 International Standard. <i>type</i> shall be a POD structure or a POD
8288 union (clause 9). The result of applying the offsetof macro to a field
8289 that is a static data member or a function member is
8290 undefined."</p>
8291
8292 <p>For the POD requirement, it doesn't say "no diagnostic
8293 required" or "undefined behavior". I read 1.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/intro.html#intro.compliance"> [intro.compliance]</a>, paragraph 1, to mean that a diagnostic is required.
8294 It's not clear whether this requirement was intended.  While it's
8295 possible to provide such a diagnostic, the extra complication doesn't
8296 seem to add any value.
8297 </p>
8298 <p><b>Proposed resolution:</b></p>
8299 <p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
8300 structure or a POD union the results are undefined."</p>
8301
8302 <p><i>[Copenhagen: straw poll was 7-4 in favor.  It was generally
8303 agreed that requiring a diagnostic was inadvertent, but some LWG
8304 members thought that diagnostics should be required whenever
8305 possible.]</i></p>
8306
8307 <hr>
8308 <a name="307"><h3>307.&nbsp;Lack of reference typedefs in container adaptors</h3></a><p>
8309 <b>Section:</b>&nbsp;23.2.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;13 Mar 2001</p>
8310
8311 <p>From reflector message c++std-lib-8330.  See also lib-8317.</p>
8312
8313 <p>
8314 The standard is currently inconsistent in 23.2.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a>
8315 paragraph 1 and 23.2.3.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> paragraph 1.
8316 23.2.3.3/1, for example, says:
8317 </p>
8318
8319 <blockquote>
8320 -1- Any sequence supporting operations back(), push_back() and pop_back()
8321 can be used to instantiate stack. In particular, vector (lib.vector), list
8322 (lib.list) and deque (lib.deque) can be used.
8323 </blockquote>
8324
8325 <p>But this is false: vector&lt;bool&gt; can not be used, because the
8326 container adaptors return a T&amp; rather than using the underlying
8327 container's reference type.</p>
8328
8329 <p>This is a contradiction that can be fixed by:</p>
8330
8331 <ol>
8332 <li>Modifying these paragraphs to say that vector&lt;bool&gt;
8333     is an exception.</li>
8334 <li>Removing the vector&lt;bool&gt; specialization.</li>
8335 <li>Changing the return types of stack and priority_queue to use
8336     reference typedef's.</li>
8337 </ol>
8338
8339 <p>
8340 I propose 3.  This does not preclude option 2 if we choose to do it
8341 later (see issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>); the issues are independent.  Option
8342 3 offers a small step towards support for proxied containers.  This
8343 small step fixes a current contradiction, is easy for vendors to
8344 implement, is already implemented in at least one popular lib, and
8345 does not break any code.
8346 </p>
8347
8348 <p><b>Proposed resolution:</b></p>
8349 <p>Summary: Add reference and const_reference typedefs to queue,
8350 priority_queue and stack.  Change return types of "value_type&amp;" to
8351 "reference".  Change return types of "const value_type&amp;" to
8352 "const_reference".  Details:</p>
8353
8354 <p>Change 23.2.3.1/1 from:</p>
8355
8356 <pre>  namespace std {
8357     template &lt;class T, class Container = deque&lt;T&gt; &gt;
8358     class queue {
8359     public:
8360       typedef typename Container::value_type            value_type;
8361       typedef typename Container::size_type             size_type;
8362       typedef          Container                        container_type;
8363     protected:
8364       Container c;
8365
8366     public:
8367       explicit queue(const Container&amp; = Container());
8368
8369       bool      empty() const             { return c.empty(); }
8370       size_type size()  const             { return c.size(); }
8371       value_type&amp;       front()           { return c.front(); }
8372       const value_type&amp; front() const     { return c.front(); }
8373       value_type&amp;       back()            { return c.back(); }
8374       const value_type&amp; back() const      { return c.back(); }
8375       void push(const value_type&amp; x)      { c.push_back(x); }
8376       void pop()                          { c.pop_front(); }
8377     };
8378 </pre>
8379
8380 <p>to:</p>
8381
8382 <pre>  namespace std {
8383     template &lt;class T, class Container = deque&lt;T&gt; &gt;
8384     class queue {
8385     public:
8386       typedef typename Container::value_type            value_type;
8387       typedef typename Container::reference             reference;
8388       typedef typename Container::const_reference       const_reference;
8389       typedef typename Container::value_type            value_type;
8390       typedef typename Container::size_type             size_type;
8391       typedef          Container                        container_type;
8392     protected:
8393       Container c;
8394
8395     public:
8396       explicit queue(const Container&amp; = Container());
8397
8398       bool      empty() const             { return c.empty(); }
8399       size_type size()  const             { return c.size(); }
8400       reference         front()           { return c.front(); }
8401       const_reference   front() const     { return c.front(); }
8402       reference         back()            { return c.back(); }
8403       const_reference   back() const      { return c.back(); }
8404       void push(const value_type&amp; x)      { c.push_back(x); }
8405       void pop()                          { c.pop_front(); }
8406     };
8407 </pre>
8408
8409 <p>Change 23.2.3.2/1 from:</p>
8410
8411 <pre>  namespace std {
8412     template &lt;class T, class Container = vector&lt;T&gt;,
8413               class Compare = less&lt;typename Container::value_type&gt; &gt;
8414     class priority_queue {
8415     public:
8416       typedef typename Container::value_type            value_type;
8417       typedef typename Container::size_type             size_type;
8418       typedef          Container                        container_type;
8419     protected:
8420       Container c;
8421       Compare comp;
8422
8423     public:
8424       explicit priority_queue(const Compare&amp; x = Compare(),
8425                               const Container&amp; = Container());
8426       template &lt;class InputIterator&gt;
8427         priority_queue(InputIterator first, InputIterator last,
8428                        const Compare&amp; x = Compare(),
8429                        const Container&amp; = Container());
8430
8431       bool      empty() const       { return c.empty(); }
8432       size_type size()  const       { return c.size(); }
8433       const value_type&amp; top() const { return c.front(); }
8434       void push(const value_type&amp; x);
8435       void pop();
8436     };
8437                                   //  no equality is provided
8438   }
8439 </pre>
8440
8441 <p>to:</p>
8442
8443 <pre>  namespace std {
8444     template &lt;class T, class Container = vector&lt;T&gt;,
8445               class Compare = less&lt;typename Container::value_type&gt; &gt;
8446     class priority_queue {
8447     public:
8448       typedef typename Container::value_type            value_type;
8449       typedef typename Container::reference             reference;
8450       typedef typename Container::const_reference       const_reference;
8451       typedef typename Container::size_type             size_type;
8452       typedef          Container                        container_type;
8453     protected:
8454       Container c;
8455       Compare comp;
8456
8457     public:
8458       explicit priority_queue(const Compare&amp; x = Compare(),
8459                               const Container&amp; = Container());
8460       template &lt;class InputIterator&gt;
8461         priority_queue(InputIterator first, InputIterator last,
8462                        const Compare&amp; x = Compare(),
8463                        const Container&amp; = Container());
8464
8465       bool      empty() const       { return c.empty(); }
8466       size_type size()  const       { return c.size(); }
8467       const_reference   top() const { return c.front(); }
8468       void push(const value_type&amp; x);
8469       void pop();
8470     };
8471                                   //  no equality is provided
8472   }
8473 </pre>
8474
8475 <p>And change 23.2.3.3/1 from:</p>
8476
8477 <pre>  namespace std {
8478     template &lt;class T, class Container = deque&lt;T&gt; &gt;
8479     class stack {
8480     public:
8481       typedef typename Container::value_type            value_type;
8482       typedef typename Container::size_type             size_type;
8483       typedef          Container                        container_type;
8484     protected:
8485       Container c;
8486
8487     public:
8488       explicit stack(const Container&amp; = Container());
8489
8490       bool      empty() const             { return c.empty(); }
8491       size_type size()  const             { return c.size(); }
8492       value_type&amp;       top()             { return c.back(); }
8493       const value_type&amp; top() const       { return c.back(); }
8494       void push(const value_type&amp; x)      { c.push_back(x); }
8495       void pop()                          { c.pop_back(); }
8496     };
8497
8498     template &lt;class T, class Container&gt;
8499       bool operator==(const stack&lt;T, Container&gt;&amp; x,
8500                       const stack&lt;T, Container&gt;&amp; y);
8501     template &lt;class T, class Container&gt;
8502       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
8503                       const stack&lt;T, Container&gt;&amp; y);
8504     template &lt;class T, class Container&gt;
8505       bool operator!=(const stack&lt;T, Container&gt;&amp; x,
8506                       const stack&lt;T, Container&gt;&amp; y);
8507     template &lt;class T, class Container&gt;
8508       bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
8509                       const stack&lt;T, Container&gt;&amp; y);
8510     template &lt;class T, class Container&gt;
8511       bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
8512                       const stack&lt;T, Container&gt;&amp; y);
8513     template &lt;class T, class Container&gt;
8514       bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
8515                       const stack&lt;T, Container&gt;&amp; y);
8516   }
8517 </pre>
8518
8519 <p>to:</p>
8520
8521 <pre>  namespace std {
8522     template &lt;class T, class Container = deque&lt;T&gt; &gt;
8523     class stack {
8524     public:
8525       typedef typename Container::value_type            value_type;
8526       typedef typename Container::reference             reference;
8527       typedef typename Container::const_reference       const_reference;
8528       typedef typename Container::size_type             size_type;
8529       typedef          Container                        container_type;
8530     protected:
8531       Container c;
8532
8533     public:
8534       explicit stack(const Container&amp; = Container());
8535
8536       bool      empty() const             { return c.empty(); }
8537       size_type size()  const             { return c.size(); }
8538       reference         top()             { return c.back(); }
8539       const_reference   top() const       { return c.back(); }
8540       void push(const value_type&amp; x)      { c.push_back(x); }
8541       void pop()                          { c.pop_back(); }
8542     };
8543
8544     template &lt;class T, class Container&gt;
8545       bool operator==(const stack&lt;T, Container&gt;&amp; x,
8546                       const stack&lt;T, Container&gt;&amp; y);
8547     template &lt;class T, class Container&gt;
8548       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
8549                       const stack&lt;T, Container&gt;&amp; y);
8550     template &lt;class T, class Container&gt;
8551       bool operator!=(const stack&lt;T, Container&gt;&amp; x,
8552                       const stack&lt;T, Container&gt;&amp; y);
8553     template &lt;class T, class Container&gt;
8554       bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
8555                       const stack&lt;T, Container&gt;&amp; y);
8556     template &lt;class T, class Container&gt;
8557       bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
8558                       const stack&lt;T, Container&gt;&amp; y);
8559     template &lt;class T, class Container&gt;
8560       bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
8561                       const stack&lt;T, Container&gt;&amp; y);
8562   }
8563 </pre>
8564
8565 <p><i>[Copenhagen: This change was discussed before the IS was released
8566 and it was deliberately not adopted.  Nevertheless, the LWG believes
8567 (straw poll: 10-2) that it is a genuine defect.]</i></p>
8568
8569 <hr>
8570 <a name="308"><h3>308.&nbsp;Table 82 mentions unrelated headers</h3></a><p>
8571 <b>Section:</b>&nbsp;27 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Mar 2001</p>
8572 <p>
8573 Table 82 in section 27 mentions the header &lt;cstdlib&gt; for String
8574 streams (27.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a>) and the headers &lt;cstdio&gt; and
8575 &lt;cwchar&gt; for File streams (27.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>). It's not clear
8576 why these headers are mentioned in this context since they do not
8577 define any of the library entities described by the
8578 subclauses. According to 17.4.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.contents"> [lib.contents]</a>, only such headers
8579 are to be listed in the summary.
8580 </p>
8581 <p><b>Proposed resolution:</b></p>
8582 <p>Remove &lt;cstdlib&gt; and &lt;cwchar&gt; from
8583 Table 82.</p>
8584
8585 <p><i>[Copenhagen: changed the proposed resolution slightly.  The
8586 original proposed resolution also said to remove &lt;cstdio&gt; from
8587 Table 82.  However, &lt;cstdio&gt; is mentioned several times within
8588 section 27.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>, including 27.8.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.c.files"> [lib.c.files]</a>.]</i></p>
8589
8590 <hr>
8591 <a name="310"><h3>310.&nbsp;Is errno a macro?</h3></a><p>
8592 <b>Section:</b>&nbsp;17.4.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a>, 19.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.errno"> [lib.errno]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;21 Mar 2001</p>
8593   <p>
8594   Exactly how should errno be declared in a conforming C++ header?
8595   </p>
8596
8597   <p>
8598   The C standard says in 7.1.4 that it is unspecified whether errno is a
8599   macro or an identifier with external linkage.  In some implementations
8600   it can be either, depending on compile-time options.  (E.g., on
8601   Solaris in multi-threading mode, errno is a macro that expands to a
8602   function call, but is an extern int otherwise.  "Unspecified" allows
8603   such variability.)
8604   </p>
8605
8606   <p>The C++ standard:</p>
8607   <ul>
8608   <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
8609   <li>17.4.3.1.3 footnote 166 says errno is reserved as an external
8610       name (true), and implies that it is an identifier.</li>
8611   <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
8612       on to say that the contents of of C++ &lt;errno.h&gt; are the
8613       same as in C, begging the question.</li>
8614   <li>C.2, table 95 lists errno as a macro, without comment.</li>
8615   </ul>
8616
8617   <p>I find no other references to errno.</p>
8618
8619   <p>We should either explicitly say that errno must be a macro, even
8620   though it need not be a macro in C, or else explicitly leave it
8621   unspecified.  We also need to say something about namespace std.
8622   A user who includes &lt;cerrno&gt; needs to know whether to write
8623   <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
8624   else &lt;cerrno&gt; is useless.</p>
8625
8626   <p>Two acceptable fixes:</p>
8627   <ul>
8628     <li><p>errno must be a macro. This is trivially satisfied by adding<br>
8629         &nbsp;&nbsp;#define errno (::std::errno)<br>
8630         to the headers if errno is not already a macro. You then always
8631         write errno without any scope qualification, and it always expands
8632         to a correct reference. Since it is always a macro, you know to
8633         avoid using errno as a local identifer.</p></li>
8634     <li><p>errno is in the global namespace. This fix is inferior, because
8635         ::errno is not guaranteed to be well-formed.</p></li>
8636   </ul>
8637
8638   <p><i>[
8639     This issue was first raised in 1999, but it slipped through
8640     the cracks.
8641   ]</i></p>
8642 <p><b>Proposed resolution:</b></p>
8643   <p>Change the Note in section 17.4.1.2p5 from</p>
8644
8645     <blockquote>
8646     Note: the names defined as macros in C include the following:
8647     assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
8648     </blockquote>
8649
8650   <p>to</p>
8651
8652     <blockquote>
8653     Note: the names defined as macros in C include the following:
8654     assert, offsetof, setjmp, va_arg, va_end, and va_start.
8655     </blockquote>
8656
8657   <p>In section 19.3, change paragraph 2 from</p>
8658
8659     <blockquote>
8660     The contents are the same as the Standard C library header
8661     &lt;errno.h&gt;.
8662     </blockquote>
8663
8664   <p>to</p>
8665
8666     <blockquote>
8667     The contents are the same as the Standard C library header
8668     &lt;errno.h&gt;, except that errno shall be defined as a macro.
8669     </blockquote>
8670 <p><b>Rationale:</b></p>
8671 <p>C++ must not leave it up to the implementation to decide whether or
8672 not a name is a macro; it must explicitly specify exactly which names
8673 are required to be macros.  The only one that really works is for it
8674 to be a macro.</p>
8675
8676 <p><i>[Curaçao: additional rationale added.]</i></p>
8677
8678 <hr>
8679 <a name="311"><h3>311.&nbsp;Incorrect wording in basic_ostream class synopsis</h3></a><p>
8680 <b>Section:</b>&nbsp;27.6.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;21 Mar 2001</p>
8681
8682 <p>In 27.6.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, the synopsis of class basic_ostream says:</p>
8683
8684 <pre>  // partial specializationss
8685   template&lt;class traits&gt;
8686     basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;( basic_ostream&lt;char,traits&gt;&amp;,
8687                                             const char * );
8688 </pre>
8689
8690 <p>Problems:</p>
8691 <ul>
8692 <li>Too many 's's at the end of "specializationss" </li>
8693 <li>This is an overload, not a partial specialization</li>
8694 </ul>
8695
8696 <p><b>Proposed resolution:</b></p>
8697 <p>In the synopsis in 27.6.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, remove the
8698 <i>// partial specializationss</i> comment.  Also remove the same
8699 comment (correctly spelled, but still incorrect) from the synopsis in
8700 27.6.2.5.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a>.
8701 </p>
8702
8703 <p><i>[
8704 Pre-Redmond: added 27.6.2.5.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> because of Martin's
8705 comment in c++std-lib-8939.
8706 ]</i></p>
8707
8708 <hr>
8709 <a name="312"></a><h3><a name="312">312.&nbsp;Table 27 is missing headers</a></h3><p>
8710 <b>Section:</b>&nbsp;20 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.utilities"> [lib.utilities]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;29 Mar 2001</p>
8711 <p>Table 27 in section 20 lists the header &lt;memory&gt; (only) for
8712 Memory (lib.memory) but neglects to mention the headers
8713 &lt;cstdlib&gt; and &lt;cstring&gt; that are discussed in 20.4.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-utilities.html#lib.c.malloc"> [lib.c.malloc]</a>.</p>
8714 <p><b>Proposed resolution:</b></p>
8715 <p>Add &lt;cstdlib&gt; and &lt;cstring&gt; to Table 27, in the same row
8716 as &lt;memory&gt;.</p>
8717 <hr>
8718 <a name="315"><h3>315.&nbsp;Bad "range" in list::unique complexity</h3></a><p>
8719 <b>Section:</b>&nbsp;23.2.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;1 May 2001</p>
8720 <p>
8721 23.2.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, Para 21 describes the complexity of
8722 list::unique as: "If the range (last - first) is not empty, exactly
8723 (last - first) -1 applications of the corresponding predicate,
8724 otherwise no applications of the predicate)".
8725 </p>
8726
8727 <p>
8728 "(last - first)" is not a range.
8729 </p>
8730 <p><b>Proposed resolution:</b></p>
8731 <p>
8732 Change the "range" from (last - first) to [first, last).
8733 </p>
8734 <hr>
8735 <a name="316"><h3>316.&nbsp;Vague text in Table 69</h3></a><p>
8736 <b>Section:</b>&nbsp;23.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;4 May 2001</p>
8737 <p>Table 69 says this about a_uniq.insert(t):</p>
8738
8739 <blockquote>
8740 inserts t if and only if there is no element in the container with key
8741 equivalent to the key of t. The bool component of the returned pair
8742 indicates whether the insertion takes place and the iterator component of the
8743 pair points to the element with key equivalent to the key of t.
8744 </blockquote>
8745
8746 <p>The description should be more specific about exactly how the bool component
8747 indicates whether the insertion takes place.</p>
8748 <p><b>Proposed resolution:</b></p>
8749 <p>Change the text in question to</p>
8750
8751 <blockquote>
8752 ...The bool component of the returned pair is true if and only if the insertion
8753 takes place...
8754 </blockquote>
8755 <hr>
8756 <a name="317"><h3>317.&nbsp;Instantiation vs. specialization of facets</h3></a><p>
8757 <b>Section:</b>&nbsp;22 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.localization"> [lib.localization]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;4 May 2001</p>
8758 <p>
8759 The localization section of the standard refers to specializations of
8760 the facet templates as instantiations even though the required facets
8761 are typically specialized rather than explicitly (or implicitly)
8762 instantiated. In the case of ctype&lt;char&gt; and
8763 ctype_byname&lt;char&gt; (and the wchar_t versions), these facets are
8764 actually required to be specialized. The terminology should be
8765 corrected to make it clear that the standard doesn't mandate explicit
8766 instantiation (the term specialization encompasses both explicit
8767 instantiations and specializations).
8768 </p>
8769 <p><b>Proposed resolution:</b></p>
8770 <p>
8771 In the following paragraphs, replace all occurrences of the word
8772 instantiation or instantiations with specialization or specializations,
8773 respectively:
8774 </p>
8775
8776 <blockquote>
8777 22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
8778 22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3,
8779 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
8780 Footnote 242.
8781 </blockquote>
8782
8783 <p>And change the text in 22.1.1.1.1, p4 from</p>
8784
8785 <blockquote>
8786     An implementation is required to provide those instantiations
8787     for facet templates identified as members of a category, and
8788     for those shown in Table 52:
8789 </blockquote>
8790
8791 <p>to</p>
8792
8793 <blockquote>
8794     An implementation is required to provide those specializations...
8795 </blockquote>
8796
8797 <p><i>[Nathan will review these changes, and will look for places where
8798 explicit specialization is necessary.]</i></p>
8799
8800 <p><b>Rationale:</b></p>
8801 <p>This is a simple matter of outdated language.  The language to
8802 describe templates was clarified during the standardization process,
8803 but the wording in clause 22 was never updated to reflect that
8804 change.</p>
8805 <hr>
8806 <a name="318"><h3>318.&nbsp;Misleading comment in definition of numpunct_byname</h3></a><p>
8807 <b>Section:</b>&nbsp;22.2.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct.byname"> [lib.locale.numpunct.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 May 2001</p>
8808 <p>The definition of the numpunct_byname template contains the following
8809 comment:</p>
8810
8811 <pre>    namespace std {
8812         template &lt;class charT&gt;
8813         class numpunct_byname : public numpunct&lt;charT&gt; {
8814     // this class is specialized for char and wchar_t.
8815         ...
8816 </pre>
8817
8818 <p>There is no documentation of the specializations and it seems
8819 conceivable that an implementation will not explicitly specialize the
8820 template at all, but simply provide the primary template.</p>
8821 <p><b>Proposed resolution:</b></p>
8822 <p>Remove the comment from the text in 22.2.3.2 and from the proposed
8823 resolution of library issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
8824 <hr>
8825 <a name="319"></a><h3><a name="319">319.&nbsp;Storage allocation wording confuses "Required behavior", "Requires"</a></h3><p>
8826 <b>Section:</b>&nbsp;18.4.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a>, 18.4.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;15 May 2001</p>
8827 <p>The standard specifies 17.3.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that "Required
8828 behavior" elements describe "the semantics of a function definition
8829 provided by either the implementation or a C++ program."</p>
8830
8831 <p>The standard specifies 17.3.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that "Requires"
8832 elements describe "the preconditions for calling the function."</p>
8833
8834 <p>In the sections noted below, the current wording specifies
8835 "Required Behavior" for what are actually preconditions, and thus
8836 should be specified as "Requires".</p>
8837
8838 <p><b>Proposed resolution:</b></p>
8839
8840 <p>In 18.4.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> Para 12 Change:</p>
8841 <blockquote>
8842   <p>Required behavior: accept a value of ptr that is null or that was
8843   returned by an earlier call ...</p>
8844 </blockquote>
8845 <p>to:</p>
8846 <blockquote>
8847   <p>Requires: the value of ptr is null or the value returned by an
8848   earlier call ...</p>
8849 </blockquote>
8850
8851 <p>In 18.4.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> Para 11 Change:</p>
8852 <blockquote>
8853   <p>Required behavior: accept a value of ptr that is null or that was
8854   returned by an earlier call ...</p>
8855 </blockquote>
8856 <p>to:</p>
8857 <blockquote>
8858   <p>Requires: the value of ptr is null or the value returned by an
8859   earlier call ...</p>
8860 </blockquote>
8861
8862 <hr>
8863 <a name="320"><h3>320.&nbsp;list::assign overspecified</h3></a><p>
8864 <b>Section:</b>&nbsp;23.2.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
8865 <p>
8866 Section 23.2.2.1, paragraphs 6-8 specify that list assign (both forms) have
8867 the "effects" of a call to erase followed by a call to insert.
8868 </p>
8869
8870 <p>
8871 I would like to document that implementers have the freedom to implement
8872 assign by other methods, as long as the end result is the same and the
8873 exception guarantee is as good or better than the basic guarantee.
8874 </p>
8875
8876 <p>
8877 The motivation for this is to use T's assignment operator to recycle
8878 existing nodes in the list instead of erasing them and reallocating
8879 them with new values.  It is also worth noting that, with careful
8880 coding, most common cases of assign (everything but assignment with
8881 true input iterators) can elevate the exception safety to strong if
8882 T's assignment has a nothrow guarantee (with no extra memory cost).
8883 Metrowerks does this.  However I do not propose that this subtlety be
8884 standardized.  It is a QoI issue.  </p>
8885
8886 <p>Existing practise:
8887 Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
8888 </p>
8889 <p><b>Proposed resolution:</b></p>
8890 <p>Change 23.2.2.1/7 from:</p>
8891
8892 <blockquote>
8893 <p>Effects:</p>
8894
8895 <pre>   erase(begin(), end());
8896    insert(begin(), first, last);
8897 </pre>
8898 </blockquote>
8899
8900 <p>to:</p>
8901
8902 <blockquote>
8903 <p>Effects: Replaces the contents of the list with the range [first, last).</p>
8904 </blockquote>
8905
8906 <p>In 23.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>, in Table 67 (sequence requirements),
8907 add two new rows:</p>
8908 <pre>      a.assign(i,j)     void      pre: i,j are not iterators into a.
8909                                   Replaces elements in a with a copy
8910                                   of [i, j).
8911
8912       a.assign(n,t)     void      pre: t is not a reference into a.
8913                                   Replaces elements in a with n copies
8914                                   of t.
8915 </pre>
8916
8917 <p>Change 23.2.2.1/8 from:</p>
8918
8919 <blockquote>
8920 <p>Effects:</p>
8921 <pre>   erase(begin(), end());
8922    insert(begin(), n, t);
8923 </pre>
8924 </blockquote>
8925 <p>to:</p>
8926
8927 <blockquote>
8928 <p>Effects: Replaces the contents of the list with n copies of t.</p>
8929 </blockquote>
8930
8931 <p><i>[Redmond: Proposed resolution was changed slightly.  Previous
8932 version made explicit statement about exception safety, which wasn't
8933 consistent with the way exception safety is expressed elsewhere.
8934 Also, the change in the sequence requirements is new.  Without that
8935 change, the proposed resolution would have required that assignment of
8936 a subrange would have to work.  That too would have been
8937 overspecification; it would effectively mandate that assignment use a
8938 temporary.  Howard provided wording.
8939 ]</i></p>
8940
8941 <p><i>[Curaçao: Made editorial improvement in wording; changed
8942 "Replaces elements in a with copies of elements in [i, j)."
8943 with "Replaces the elements of a with a copy of [i, j)."
8944 Changes not deemed serious enough to requre rereview.]</i></p>
8945
8946 <hr>
8947 <a name="321"><h3>321.&nbsp;Typo in num_get</h3></a><p>
8948 <b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Kevin Djang&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
8949 <p>
8950 Section 22.2.2.1.2 at p7 states that "A length specifier is added to
8951 the conversion function, if needed, as indicated in Table 56."
8952 However, Table 56 uses the term "length modifier", not "length
8953 specifier".
8954 </p>
8955 <p><b>Proposed resolution:</b></p>
8956 <p>
8957 In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
8958 to be "A length modifier is added ..."
8959 </p>
8960 <p><b>Rationale:</b></p>
8961 <p>C uses the term "length modifier".  We should be consistent.</p>
8962 <hr>
8963 <a name="322"><h3>322.&nbsp;iterator and const_iterator should have the same value type</h3></a><p>
8964 <b>Section:</b>&nbsp;23.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
8965 <p>
8966 It's widely assumed that, if X is a container,
8967 iterator_traits&lt;X::iterator&gt;::value_type and
8968 iterator_traits&lt;X::const_iterator&gt;::value_type should both be
8969 X::value_type.  However, this is nowhere stated.  The language in
8970 Table 65 is not precise about the iterators' value types (it predates
8971 iterator_traits), and could even be interpreted as saying that
8972 iterator_traits&lt;X::const_iterator&gt;::value_type should be "const
8973 X::value_type".
8974 </p>
8975
8976 <p>Related issue: <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a>.</p>
8977 <p><b>Proposed resolution:</b></p>
8978 <p>In Table 65 ("Container Requirements"), change the return type for
8979 X::iterator to "iterator type whose value type is T".  Change the
8980 return type for X::const_iterator to "constant iterator type whose
8981 value type is T".</p>
8982 <p><b>Rationale:</b></p>
8983 <p>
8984 This belongs as a container requirement, rather than an iterator
8985 requirement, because the whole notion of iterator/const_iterator
8986 pairs is specific to containers' iterator.
8987 </p>
8988 <p>
8989 It is existing practice that (for example)
8990 iterator_traits&lt;list&lt;int&gt;::const_iterator&gt;::value_type
8991 is "int", rather than "const int".  This is consistent with
8992 the way that const pointers are handled: the standard already
8993 requires that iterator_traits&lt;const int*&gt;::value_type is int.
8994 </p>
8995 <hr>
8996 <a name="324"><h3>324.&nbsp;Do output iterators have value types?</h3></a><p>
8997 <b>Section:</b>&nbsp;24.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;7 June 2001</p>
8998
8999 <p>Table 73 suggests that output iterators have value types.  It
9000 requires the expression "*a = t".  Additionally, although Table 73
9001 never lists "a = t" or "X(a) = t" in the "expressions" column, it
9002 contains a note saying that "a = t" and "X(a) = t" have equivalent
9003 (but nowhere specified!) semantics.</p>
9004
9005 <p>According to 24.1/9, t is supposed to be "a value of value type
9006 T":</p>
9007
9008     <blockquote>
9009     In the following sections, a and b denote values of X, n denotes a
9010     value of the difference type Distance, u, tmp, and m denote
9011     identifiers, r denotes a value of X&amp;, t denotes a value of
9012     value type T.
9013     </blockquote>
9014
9015 <p>Two other parts of the standard that are relevant to whether
9016 output iterators have value types:</p>
9017
9018 <ul>
9019     <li>24.1/1 says "All iterators i support the expression *i,
9020     resulting in a value of some class, enumeration, or built-in type
9021     T, called the value type of the iterator".</li>
9022
9023     <li>
9024     24.3.1/1, which says "In the case of an output iterator, the types
9025     iterator_traits&lt;Iterator&gt;::difference_type
9026     iterator_traits&lt;Iterator&gt;::value_type are both defined as void."
9027     </li>
9028 </ul>
9029
9030 <p>The first of these passages suggests that "*i" is supposed to
9031 return a useful value, which contradicts the note in 24.1.2/2 saying
9032 that the only valid use of "*i" for output iterators is in an
9033 expression of the form "*i = t".  The second of these passages appears
9034 to contradict Table 73, because it suggests that "*i"'s return value
9035 should be void.  The second passage is also broken in the case of a an
9036 iterator type, like non-const pointers, that satisfies both the output
9037 iterator requirements and the forward iterator requirements.</p>
9038
9039 <p>What should the standard say about <tt>*i</tt>'s return value when
9040 i is an output iterator, and what should it say about that t is in the
9041 expression "*i = t"?  Finally, should the standard say anything about
9042 output iterators' pointer and reference types?</p>
9043
9044 <p><b>Proposed resolution:</b></p>
9045 <p>24.1 p1, change</p>
9046
9047 <blockquote>
9048 <p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
9049 in a value of some class, enumeration, or built-in type <tt>T</tt>,
9050 called the value type of the iterator.</p>
9051 </blockquote>
9052
9053 <p>to</p>
9054
9055 <blockquote>
9056 <p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
9057 resulting in a value of some class, enumeration, or built-in type
9058 <tt>T</tt>, called the value type of the iterator. All output
9059 iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
9060 value of some type that is in the set of types that are <i>writable</i> to
9061 the particular iterator type of <tt>i</tt>.
9062 </p>
9063 </blockquote>
9064
9065 <p>24.1 p9, add</p>
9066
9067 <blockquote>
9068 <p>
9069 <tt>o</tt> denotes a value of some type that is writable to the
9070 output iterator.
9071 </p>
9072 </blockquote>
9073
9074 <p>Table 73, change</p>
9075
9076 <blockquote>
9077 <pre>*a = t
9078 </pre>
9079 </blockquote>
9080
9081 <p>to</p>
9082
9083 <blockquote>
9084 <pre>*r = o
9085 </pre>
9086 </blockquote>
9087
9088 <p>and change</p>
9089
9090 <blockquote>
9091 <pre>*r++ = t
9092 </pre>
9093 </blockquote>
9094
9095 <p>to</p>
9096
9097 <blockquote>
9098 <pre>*r++ = o
9099 </pre>
9100 </blockquote>
9101
9102 <p><i>[post-Redmond: Jeremy provided wording]</i></p>
9103
9104 <p><b>Rationale:</b></p>
9105 <p>The LWG considered two options: change all of the language that
9106 seems to imply that output iterators have value types, thus making it
9107 clear that output iterators have no value types, or else define value
9108 types for output iterator consistently.  The LWG chose the former
9109 option, because it seems clear that output iterators were never
9110 intended to have value types.  This was a deliberate design decision,
9111 and any language suggesting otherwise is simply a mistake.</p>
9112
9113 <p>A future revision of the standard may wish to revisit this design
9114 decision.</p>
9115 <hr>
9116 <a name="325"><h3>325.&nbsp;Misleading text in moneypunct&lt;&gt;::do_grouping</h3></a><p>
9117 <b>Section:</b>&nbsp;22.2.6.3.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Jul 2001</p>
9118 <p>The Returns clause in 22.2.6.3.2, p3 says about
9119 moneypunct&lt;charT&gt;::do_grouping()
9120 </p>
9121
9122 <blockquote>
9123     Returns: A pattern defined identically as the result of
9124     numpunct&lt;charT&gt;::do_grouping().241)
9125 </blockquote>
9126
9127 <p>Footnote 241 then reads</p>
9128
9129 <blockquote>
9130     This is most commonly the value "\003" (not "3").
9131 </blockquote>
9132
9133 <p>
9134 The returns clause seems to imply that the two member functions must
9135 return an identical value which in reality may or may not be true,
9136 since the facets are usually implemented in terms of struct std::lconv
9137 and return the value of the grouping and mon_grouping, respectively.
9138 The footnote also implies that the member function of the moneypunct
9139 facet (rather than the overridden virtual functions in moneypunct_byname)
9140 most commonly return "\003", which contradicts the C standard which
9141 specifies the value of "" for the (most common) C locale.
9142 </p>
9143
9144 <p><b>Proposed resolution:</b></p>
9145 <p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>
9146
9147 <blockquote>
9148     Returns: A pattern defined identically as, but not necessarily
9149     equal to, the result of numpunct&lt;charT&gt;::do_grouping().241)
9150 </blockquote>
9151
9152 <p>and replace the text in Footnote 241 with the following:</p>
9153
9154 <blockquote>
9155     To specify grouping by 3s the value is "\003", not "3".
9156 </blockquote>
9157 <p><b>Rationale:</b></p>
9158 <p>
9159 The fundamental problem is that the description of the locale facet
9160 virtuals serves two purposes: describing the behavior of the base
9161 class, and describing the meaning of and constraints on the behavior
9162 in arbitrary derived classes.  The new wording makes that separation a
9163 little bit clearer.  The footnote (which is nonnormative) is not
9164 supposed to say what the grouping is in the "C" locale or in any other
9165 locale. It is just a reminder that the values are interpreted as small
9166 integers, not ASCII characters.
9167 </p>
9168 <hr>
9169 <a name="327"><h3>327.&nbsp;Typo in time_get facet in table 52</h3></a><p>
9170 <b>Section:</b>&nbsp;22.1.1.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Tiki Wan&nbsp; <b>Date:</b>&nbsp;06 Jul 2001</p>
9171 <p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
9172 <tt>time_get_byname</tt> are listed incorrectly in table 52,
9173 required instantiations.  In both cases the second template
9174 parameter is given as OutputIterator.  It should instead be
9175 InputIterator, since these are input facets.</p>
9176 <p><b>Proposed resolution:</b></p>
9177 <p>
9178 In table 52, required instantiations, in
9179 22.1.1.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, change</p>
9180 <pre>    time_get&lt;wchar_t, OutputIterator&gt;
9181     time_get_byname&lt;wchar_t, OutputIterator&gt;
9182 </pre>
9183 <p>to</p>
9184 <pre>    time_get&lt;wchar_t, InputIterator&gt;
9185     time_get_byname&lt;wchar_t, InputIterator&gt;
9186 </pre>
9187
9188 <p><i>[Redmond: Very minor change in proposed resolution.  Original had
9189 a typo, wchart instead of wchar_t.]</i></p>
9190
9191 <hr>
9192 <a name="328"><h3>328.&nbsp;Bad sprintf format modifier in money_put&lt;&gt;::do_put()</h3></a><p>
9193 <b>Section:</b>&nbsp;22.2.6.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.money.put.virtuals"> [lib.locale.money.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;07 Jul 2001</p>
9194 <p>The sprintf format string , "%.01f" (that's the digit one), in the
9195 description of the do_put() member functions of the money_put facet in
9196 22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
9197 for values of type long double, and second, the precision of 01
9198 doesn't seem to make sense. What was most likely intended was
9199 "%.0Lf"., that is a precision of zero followed by the L length
9200 modifier.</p>
9201 <p><b>Proposed resolution:</b></p>
9202 <p>Change the format string to "%.0Lf".</p>
9203 <p><b>Rationale:</b></p>
9204 <p>Fixes an obvious typo</p>
9205 <hr>
9206 <a name="329"><h3>329.&nbsp;vector capacity, reserve and reallocation</h3></a><p>
9207 <b>Section:</b>&nbsp;23.2.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>, 23.2.4.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;13 Jul 2001</p>
9208 <p>
9209 There is an apparent contradiction about which circumstances can cause
9210 a reallocation of a vector in Section 23.2.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> and
9211 section 23.2.4.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>.
9212 </p>
9213
9214 <p>23.2.4.2p5 says:</p>
9215 <blockquote>
9216 Notes: Reallocation invalidates all the references, pointers, and iterators
9217 referring to the elements in the sequence. It is guaranteed that no
9218 reallocation takes place during insertions that happen after a call to
9219 reserve() until the time when an insertion would make the size of the vector
9220 greater than the size specified in the most recent call to reserve().
9221 </blockquote>
9222
9223 <p>Which implies if I do</p>
9224
9225 <pre>  std::vector&lt;int&gt; vec;
9226   vec.reserve(23);
9227   vec.reserve(0);
9228   vec.insert(vec.end(),1);
9229 </pre>
9230
9231 <p>then the implementation may reallocate the vector for the insert,
9232 as the size specified in the previous call to reserve was zero.</p>
9233
9234 <p>However, the previous paragraphs (23.2.4.2, p1-2) state:</p>
9235 <blockquote>
9236 <p>
9237 (capacity) Returns: The total number of elements the vector
9238 can hold without requiring reallocation
9239 </p>
9240 <p>
9241 ...After reserve(), capacity() is greater or equal to the
9242 argument of reserve if reallocation happens; and equal to the previous value
9243 of capacity() otherwise...
9244 </p>
9245 </blockquote>
9246
9247 <p>
9248 This implies that vec.capacity() is still 23, and so the insert()
9249 should not require a reallocation, as vec.size() is 0. This is backed
9250 up by 23.2.4.3p1:
9251 </p>
9252 <blockquote>
9253 (insert) Notes: Causes reallocation if the new size is greater than the old
9254 capacity.
9255 </blockquote>
9256
9257 <p>
9258 Though this doesn't rule out reallocation if the new size is less
9259 than the old capacity, I think the intent is clear.
9260 </p>
9261
9262 <p><b>Proposed resolution:</b></p>
9263 <p>Change the wording of 23.2.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> paragraph 5 to:</p>
9264
9265 <blockquote>
9266 Notes: Reallocation invalidates all the references, pointers, and
9267 iterators referring to the elements in the sequence. It is guaranteed
9268 that no reallocation takes place during insertions that happen after a
9269 call to reserve() until the time when an insertion would make the size
9270 of the vector greater than the value of capacity().
9271 </blockquote>
9272
9273 <p><i>[Redmond: original proposed resolution was modified slightly.  In
9274 the original, the guarantee was that there would be no reallocation
9275 until the size would be greater than the value of capacity() after the
9276 most recent call to reserve().  The LWG did not believe that the
9277 "after the most recent call to reserve()" added any useful
9278 information.]</i></p>
9279
9280 <p><b>Rationale:</b></p>
9281 <p>There was general agreement that, when reserve() is called twice in
9282 succession and the argument to the second invocation is smaller than
9283 the argument to the first, the intent was for the second invocation to
9284 have no effect.  Wording implying that such cases have an effect on
9285 reallocation guarantees was inadvertant.</p>
9286 <hr>
9287 <a name="331"><h3>331.&nbsp;bad declaration of destructor for ios_base::failure</h3></a><p>
9288 <b>Section:</b>&nbsp;27.4.2.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;PremAnand M. Rao&nbsp; <b>Date:</b>&nbsp;23 Aug 2001</p>
9289 <p>
9290 With the change in 17.4.4.8 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> to state
9291    "An implementation may strengthen the exception-specification for a
9292     non-virtual function by removing listed exceptions."
9293 (issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>)
9294 and the following declaration of ~failure() in ios_base::failure
9295 </p>
9296 <pre>    namespace std {
9297        class ios_base::failure : public exception {
9298        public:
9299            ...
9300            virtual ~failure();
9301            ...
9302        };
9303      }
9304 </pre>
9305 <p>the class failure cannot be implemented since in 18.6.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.exception"> [lib.exception]</a> the destructor of class exception has an empty
9306 exception specification:</p>
9307 <pre>    namespace std {
9308        class exception {
9309        public:
9310          ...
9311          virtual ~exception() throw();
9312          ...
9313        };
9314      }
9315 </pre>
9316 <p><b>Proposed resolution:</b></p>
9317 <p>Remove the declaration of ~failure().</p>
9318 <p><b>Rationale:</b></p>
9319 <p>The proposed resolution is consistent with the way that destructors
9320 of other classes derived from <tt>exception</tt> are handled.</p>
9321 <hr>
9322 <a name="333"><h3>333.&nbsp;does endl imply synchronization with the device?</h3></a><p>
9323 <b>Section:</b>&nbsp;27.6.2.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;PremAnand M. Rao&nbsp; <b>Date:</b>&nbsp;27 Aug 2001</p>
9324 <p>A footnote in 27.6.2.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a> states:</p>
9325 <blockquote>
9326     [Footnote: The effect of executing cout &lt;&lt; endl is to insert a
9327      newline character in the output sequence controlled by cout, then
9328      synchronize it with any external file with which it might be
9329      associated. --- end foonote]
9330 </blockquote>
9331
9332 <p>
9333 Does the term "file" here refer to the external device?
9334 This leads to some implementation ambiguity on systems with fully
9335 buffered files where a newline does not cause a flush to the device.
9336 </p>
9337
9338 <p>
9339 Choosing to sync with the device leads to significant performance
9340 penalties for each call to endl, while not sync-ing leads to
9341 errors under special circumstances.
9342 </p>
9343
9344 <p>
9345 I could not find any other statement that explicitly defined
9346 the behavior one way or the other.
9347 </p>
9348 <p><b>Proposed resolution:</b></p>
9349 <p>Remove footnote 300 from section 27.6.2.7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a>.</p>
9350 <p><b>Rationale:</b></p>
9351 <p>We already have normative text saying what <tt>endl</tt> does: it
9352 inserts a newline character and calls <tt>flush</tt>.  This footnote
9353 is at best redundant, at worst (as this issue says) misleading,
9354 because it appears to make promises about what <tt>flush</tt>
9355 does.</p>
9356 <hr>
9357 <a name="334"><h3>334.&nbsp;map::operator[] specification forces inefficient implementation</h3></a><p>
9358 <b>Section:</b>&nbsp;23.3.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.map.access"> [lib.map.access]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andrea Griffini&nbsp; <b>Date:</b>&nbsp;02 Sep 2001</p>
9359 <p>
9360 The current standard describes map::operator[] using a
9361 code example. That code example is however quite
9362 inefficient because it requires several useless copies
9363 of both the passed key_type value and of default
9364 constructed mapped_type instances.
9365 My opinion is that was not meant by the comitee to
9366 require all those temporary copies.
9367 </p>
9368
9369 <p>Currently map::operator[] behaviour is specified as: </p>
9370 <pre>  Returns:
9371     (*((insert(make_pair(x, T()))).first)).second.
9372 </pre>
9373
9374 <p>
9375 This specification however uses make_pair that is a
9376 template function of which parameters in this case
9377 will be deduced being of type const key_type&amp; and
9378 const T&amp;. This will create a pair&lt;key_type,T&gt; that
9379 isn't the correct type expected by map::insert so
9380 another copy will be required using the template
9381 conversion constructor available in pair to build
9382 the required pair&lt;const key_type,T&gt; instance.
9383 </p>
9384
9385 <p>If we consider calling of key_type copy constructor
9386 and mapped_type default constructor and copy
9387 constructor as observable behaviour (as I think we
9388 should) then the standard is in this place requiring
9389 two copies of a key_type element plus a default
9390 construction and two copy construction of a mapped_type
9391 (supposing the addressed element is already present
9392 in the map; otherwise at least another copy
9393 construction for each type).
9394 </p>
9395
9396 <p>A simple (half) solution would be replacing the description with:</p>
9397 <pre>  Returns:
9398     (*((insert(value_type(x, T()))).first)).second.
9399 </pre>
9400
9401 <p>This will remove the wrong typed pair construction that
9402 requires one extra copy of both key and value.</p>
9403
9404 <p>However still the using of map::insert requires temporary
9405 objects while the operation, from a logical point of view,
9406 doesn't require any. </p>
9407
9408 <p>I think that a better solution would be leaving free an
9409 implementer to use a different approach than map::insert
9410 that, because of its interface, forces default constructed
9411 temporaries and copies in this case.
9412 The best solution in my opinion would be just requiring
9413 map::operator[] to return a reference to the mapped_type
9414 part of the contained element creating a default element
9415 with the specified key if no such an element is already
9416 present in the container. Also a logarithmic complexity
9417 requirement should be specified for the operation.
9418 </p>
9419
9420 <p>
9421 This would allow library implementers to write alternative
9422 implementations not using map::insert and reaching optimal
9423 performance in both cases of the addressed element being
9424 present or absent from the map (no temporaries at all and
9425 just the creation of a new pair inside the container if
9426 the element isn't present).
9427 Some implementer has already taken this option but I think
9428 that the current wording of the standard rules that as
9429 non-conforming.
9430 </p>
9431
9432 <p><b>Proposed resolution:</b></p>
9433
9434 <p>
9435 Replace 23.3.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.map.access"> [lib.map.access]</a> paragraph 1 with
9436 </p>
9437 <blockquote>
9438 <p>
9439 -1- Effects:  If there is no key equivalent to x in the map, inserts
9440 value_type(x, T()) into the map.
9441 </p>
9442 <p>
9443 -2- Returns: A reference to the mapped_type corresponding to x in *this.
9444 </p>
9445 <p>
9446 -3- Complexity: logarithmic.
9447 </p>
9448 </blockquote>
9449
9450 <p><i>[This is the second option mentioned above.  Howard provided
9451 wording.  We may also wish to have a blanket statement somewhere in
9452 clause 17 saying that we do not intend the semantics of sample code
9453 fragments to be interpreted as specifing exactly how many copies are
9454 made.  See issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#98">98</a> for a similar problem.]</i></p>
9455
9456 <p><b>Rationale:</b></p>
9457 <p>
9458 This is the second solution described above; as noted, it is
9459 consistent with existing practice.
9460 </p>
9461
9462 <p>Note that we now need to specify the complexity explicitly, because
9463 we are no longer defining <tt>operator[]</tt> in terms of
9464 <tt>insert</tt>.</p>
9465 <hr>
9466 <a name="335"><h3>335.&nbsp;minor issue with char_traits, table 37</h3></a><p>
9467 <b>Section:</b>&nbsp;21.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;06 Sep 2001</p>
9468 <p>
9469 Table 37, in 21.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>, descibes char_traits::assign
9470 as:
9471 </p>
9472 <pre>  X::assign(c,d)   assigns c = d.
9473 </pre>
9474
9475 <p>And para 1 says:</p>
9476
9477 <blockquote>
9478  [...] c and d denote values of type CharT [...]
9479 </blockquote>
9480
9481 <p>
9482 Naturally, if c and d are <i>values</i>, then the assignment is
9483 (effectively) meaningless. It's clearly intended that (in the case of
9484 assign, at least), 'c' is intended to be a reference type.
9485 </p>
9486
9487 <p>I did a quick survey of the four implementations I happened to have
9488 lying around, and sure enough they all have signatures:</p>
9489 <pre>    assign( charT&amp;, const charT&amp; );
9490 </pre>
9491
9492 <p>(or the equivalent). It's also described this way in Nico's book.
9493 (Not to mention the synopses of char_traits&lt;char&gt; in 21.1.3.1
9494 and char_traits&lt;wchar_t&gt; in 21.1.3.2...)
9495 </p>
9496 <p><b>Proposed resolution:</b></p>
9497 <p>Add the following to 21.1.1 para 1:</p>
9498 <blockquote>
9499  r denotes an lvalue of CharT
9500 </blockquote>
9501
9502 <p>and change the description of assign in the table to:</p>
9503 <pre>  X::assign(r,d)   assigns r = d
9504 </pre>
9505 <hr>
9506 <a name="336"><h3>336.&nbsp;Clause 17 lack of references to deprecated headers</h3></a><p>
9507 <b>Section:</b>&nbsp;17 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Detlef Vollmann&nbsp; <b>Date:</b>&nbsp;05 Sep 2001</p>
9508 <p>From c++std-edit-873:</p>
9509
9510 <p>17.4.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a>, Table 11.  In this table, the header
9511 &lt;strstream&gt; is missing.</p>
9512
9513 <p>This shows a general problem: The whole clause 17 refers quite
9514 often to clauses 18 through 27, but D.7 is also a part of the standard
9515 library (though a deprecated one).</p>
9516
9517 <p><b>Proposed resolution:</b></p>
9518
9519 <p>To 17.4.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> Table 11, C++ Library Headers, add
9520 "&lt;strstream&gt;".</p>
9521
9522 <p>In the following places, change "clauses 17 through 27" to "clauses
9523 17 through 27 and Annex D":</p>
9524
9525 <ul>
9526 <li>1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/intro.html#intro.refs"> [intro.refs]</a> Normative references/1/footnote 1</li>
9527 <li>1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/intro.html#intro.defs"> [intro.defs]</a> Definitions/1</li>
9528 <li>7 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/dcl.html#dcl.dcl"> [dcl.dcl]</a> Library introduction/9</li>
9529 <li>17.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.description"> [lib.description]</a> Method of description (Informative)/1</li>
9530 <li>17.3.2.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.character.seq"> [lib.character.seq]</a> Character sequences/1/bullet 2</li>
9531 <li>17.3.2.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.functions.within.classes"> [lib.functions.within.classes]</a> Functions within classes/1</li>
9532 <li>17.3.2.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.objects.within.classes"> [lib.objects.within.classes]</a> Private members/1/(2 places)</li>
9533 <li>17.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.requirements"> [lib.requirements]</a> Library-wide requirements/1</li>
9534 <li>17.4.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> Headers/4</li>
9535 <li>17.4.3.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> Replacement functions/1</li>
9536 <li>17.4.4.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a> Global or non-member functions/2</li>
9537 <li>17.4.4.6 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.protection.within.classes"> [lib.protection.within.classes]</a> Protection within classes/1</li>
9538 </ul>
9539
9540
9541 <hr>
9542 <a name="337"><h3>337.&nbsp;replace_copy_if's template parameter should be InputIterator</h3></a><p>
9543 <b>Section:</b>&nbsp;25.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Detlef Vollmann&nbsp; <b>Date:</b>&nbsp;07 Sep 2001</p>
9544 <p>From c++std-edit-876:</p>
9545
9546 <p>
9547 In section 25.2.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> before p4: The name of the first
9548 parameter of template replace_copy_if should be "InputIterator"
9549 instead of "Iterator".  According to 17.3.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a> p1 the
9550 parameter name conveys real normative meaning.
9551 </p>
9552 <p><b>Proposed resolution:</b></p>
9553 <p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
9554 <hr>
9555 <a name="338"><h3>338.&nbsp; is whitespace allowed between `-' and a digit?</h3></a><p>
9556 <b>Section:</b>&nbsp;22.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 Sep 2001</p>
9557 <p>
9558 From Stage 2 processing in 22.2.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, p8 and 9 (the
9559 original text or the text corrected by the proposed resolution of
9560 issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>) it seems clear that no whitespace is allowed
9561 within a number, but 22.2.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a>, p2, which gives the
9562 format for integer and floating point values, says that whitespace is
9563 optional between a plusminus and a sign.
9564 </p>
9565
9566 <p>
9567 The text needs to be clarified to either consistently allow or
9568 disallow whitespace between a plusminus and a sign. It might be
9569 worthwhile to consider the fact that the C library stdio facility does
9570 not permit whitespace embedded in numbers and neither does the C or
9571 C++ core language (the syntax of integer-literals is given in 2.13.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lex.html#lex.icon"> [lex.icon]</a>, that of floating-point-literals in 2.13.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lex.html#lex.fcon"> [lex.fcon]</a> of the C++ standard).
9572 </p>
9573 <p><b>Proposed resolution:</b></p>
9574 <p>Change the first part of 22.2.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a> paragraph 2 from:</p>
9575 <blockquote>
9576 <p>
9577 The syntax for number formats is as follows, where <tt>digit</tt>
9578 represents the radix set specified by the <tt>fmtflags</tt> argument
9579 value, <tt>whitespace</tt> is as determined by the facet
9580 <tt>ctype&lt;charT&gt;</tt> (22.2.1.1), and <tt>thousands-sep</tt> and
9581 <tt>decimal-point</tt> are the results of corresponding
9582 <tt>numpunct&lt;charT&gt;</tt> members.  Integer values have the
9583 format:
9584 </p>
9585 <pre>  integer   ::= [sign] units
9586   sign      ::= plusminus [whitespace]
9587   plusminus ::= '+' | '-'
9588   units     ::= digits [thousands-sep units]
9589   digits    ::= digit [digits]
9590 </pre>
9591 </blockquote>
9592 <p>to:</p>
9593 <blockquote>
9594 <p>
9595 The syntax for number formats is as follows, where <tt>digit</tt>
9596 represents the radix set specified by the <tt>fmtflags</tt> argument
9597 value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
9598 results of corresponding <tt>numpunct&lt;charT&gt;</tt> members.
9599 Integer values have the format:
9600 </p>
9601 <pre>  integer   ::= [sign] units
9602   sign      ::= plusminus
9603   plusminus ::= '+' | '-'
9604   units     ::= digits [thousands-sep units]
9605   digits    ::= digit [digits]
9606 </pre>
9607 </blockquote>
9608 <p><b>Rationale:</b></p>
9609 <p>It's not clear whether the format described in 22.2.3.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a> paragraph 2 has any normative weight: nothing in the
9610 standard says how, or whether, it's used.  However, there's no reason
9611 for it to differ gratuitously from the very specific description of
9612 numeric processing in 22.2.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>.  The proposed
9613 resolution removes all mention of "whitespace" from that format.</p>
9614 <hr>
9615 <a name="339"><h3>339.&nbsp;definition of bitmask type restricted to clause 27</h3></a><p>
9616 <b>Section:</b>&nbsp;22.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, 17.3.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 September 2001</p>
9617 <p>
9618 The ctype_category::mask type is declared to be an enum in 22.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a> with p1 then stating that it is a bitmask type, most
9619 likely referring to the definition of bitmask type in 17.3.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>, p1. However, the said definition only applies to
9620 clause 27, making the reference in 22.2.1 somewhat dubious.
9621 </p>
9622 <p><b>Proposed resolution:</b></p>
9623 <p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
9624     <blockquote>
9625     Several types defined in clause 27 are bitmask types. Each bitmask type
9626     can be implemented as an enumerated type that overloads certain operators,
9627     as an integer type, or as a bitset (23.3.5 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>).
9628     </blockquote>
9629 <p>to read</p>
9630     <blockquote>
9631     Several types defined in clauses lib.language.support through
9632     lib.input.output and Annex D are bitmask types. Each bitmask type can
9633     be implemented as an enumerated type that overloads certain operators,
9634     as an integer  type, or as a bitset (lib.template.bitset).
9635     </blockquote>
9636
9637 <p>
9638 Additionally, change the definition in 22.2.1 to adopt the same
9639 convention as in clause 27 by replacing the existing text with the
9640 following (note, in particluar, the cross-reference to 17.3.2.1.2 in
9641 22.2.1, p1):
9642 </p>
9643
9644 <blockquote>
9645 <p>22.2.1 The ctype category [lib.category.ctype]</p>
9646 <pre>namespace std {
9647     class ctype_base {
9648     public:
9649         typedef <b><i>T</i></b> mask;
9650
9651         // numeric values are for exposition only.
9652         static const mask space = 1 &lt;&lt; 0;
9653         static const mask print = 1 &lt;&lt; 1;
9654         static const mask cntrl = 1 &lt;&lt; 2;
9655         static const mask upper = 1 &lt;&lt; 3;
9656         static const mask lower = 1 &lt;&lt; 4;
9657         static const mask alpha = 1 &lt;&lt; 5;
9658         static const mask digit = 1 &lt;&lt; 6;
9659         static const mask punct = 1 &lt;&lt; 7;
9660         static const mask xdigit = 1 &lt;&lt; 8;
9661         static const mask alnum = alpha | digit;
9662         static const mask graph = alnum | punct;
9663     };
9664 }
9665 </pre>
9666
9667 <p>The type <tt>mask</tt> is a bitmask type (17.3.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>).</p>
9668 </blockquote>
9669
9670 <p><i>[Curaçao: The LWG notes that T above should be bold-italics to be
9671 consistent with the rest of the standard.]</i></p>
9672
9673 <hr>
9674 <a name="340"><h3>340.&nbsp;interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt>
9675 </h3></a><p>
9676 <b>Section:</b>&nbsp;22.1.1.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2001</p>
9677 <p>
9678 It's unclear whether 22.1.1.1.1, p3 says that
9679 <tt>has_facet&lt;Facet&gt;(loc)</tt> returns true for any <tt>Facet</tt>
9680 from Table 51 or whether it includes Table 52 as well:
9681 </p>
9682
9683 <blockquote>
9684 For any locale <tt>loc</tt> either constructed, or returned by
9685 locale::classic(), and any facet <tt>Facet</tt> that is a member of a
9686 standard category, <tt>has_facet&lt;Facet&gt;(loc)</tt> is true. Each
9687 locale member function which takes a <tt>locale::category</tt>
9688 argument operates on the corresponding set of facets.
9689 </blockquote>
9690
9691 <p>
9692 It seems that it comes down to which facets are considered to be members of a
9693 standard category. Intuitively, I would classify all the facets in Table 52 as
9694 members of their respective standard categories, but there are an unbounded set
9695 of them...
9696 </p>
9697
9698 <p>
9699 The paragraph implies that, for instance, <tt>has_facet&lt;num_put&lt;C,
9700 OutputIterator&gt; &gt;(loc)</tt> must always return true. I don't think that's
9701 possible. If it were, then <tt>use_facet&lt;num_put&lt;C, OutputIterator&gt;
9702 &gt;(loc)</tt> would have to return a reference to a distinct object for each
9703 valid specialization of <tt>num_put&lt;C, OutputIteratory&gt;</tt>, which is
9704 clearly impossible.
9705 </p>
9706
9707 <p>
9708 On the other hand, if none of the facets in Table 52 is a member of a standard
9709 category then none of the locale member functions that operate on entire
9710 categories of facets will work properly.
9711 </p>
9712
9713 <p>
9714 It seems that what p3 should mention that it's required (permitted?)
9715 to hold only for specializations of <tt>Facet</tt> from Table 52 on
9716 <tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
9717 <tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
9718 {
9719 {i,o}<tt>streambuf_iterator</tt>&lt;{<tt>char</tt>,<tt>wchar_t</tt>}<tt>&gt;</tt>
9720 }.
9721 </p>
9722 <p><b>Proposed resolution:</b></p>
9723 <p>In 22.1.1.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, paragraph 3, change
9724 "that is a member of a standard category" to "shown in Table 51".</p>
9725 <p><b>Rationale:</b></p>
9726 <p>The facets in Table 52 are an unbounded set.  Locales should not be
9727 required to contain an infinite number of facets.</p>
9728
9729 <p>It's not necessary to talk about which values of InputIterator and
9730 OutputIterator must be supported.  Table 51 already contains a
9731 complete list of the ones we need.</p>
9732 <hr>
9733 <a name="341"><h3>341.&nbsp;Vector reallocation and swap</h3></a><p>
9734 <b>Section:</b>&nbsp;23.2.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;27 Sep 2001</p>
9735 <p>It is a common idiom to reduce the capacity of a vector by swapping it with
9736 an empty one:</p>
9737 <pre>  std::vector&lt;SomeType&gt; vec;
9738   // fill vec with data
9739   std::vector&lt;SomeType&gt;().swap(vec);
9740   // vec is now empty, with minimal capacity
9741 </pre>
9742
9743 <p>However, the wording of 23.2.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>paragraph 5 prevents
9744 the capacity of a vector being reduced, following a call to
9745 reserve(). This invalidates the idiom, as swap() is thus prevented
9746 from reducing the capacity. The proposed wording for issue <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a> does not affect this.  Consequently, the example above
9747 requires the temporary to be expanded to cater for the contents of
9748 vec, and the contents be copied across. This is a linear-time
9749 operation.</p>
9750
9751 <p>However, the container requirements state that swap must have constant
9752 complexity (23.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> note to table 65).</p>
9753
9754 <p>This is an important issue, as reallocation affects the validity of
9755 references and iterators.</p>
9756
9757 <p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
9758 references and iterators remain valid after a call to swap, if they refer to
9759 an element before the new end() of the vector into which they originally
9760 pointed, in which case they refer to the element at the same index position.
9761 Iterators and references that referred to an element whose index position
9762 was beyond the new end of the vector are invalidated.</p>
9763
9764 <p>If the note to table 65 is taken as the desired intent, then there are two
9765 possibilities with regard to iterators and references:</p>
9766
9767 <ol>
9768 <li>All Iterators and references into both vectors are invalidated.</li>
9769 <li>Iterators and references into either vector remain valid, and remain
9770 pointing to the same element. Consequently iterators and references that
9771 referred to one vector now refer to the other, and vice-versa.</li>
9772 </ol>
9773 <p><b>Proposed resolution:</b></p>
9774 <p>Add a new paragraph after 23.2.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> paragraph 5:</p>
9775 <blockquote>
9776 <pre>  void swap(vector&lt;T,Allocator&gt;&amp; x);
9777 </pre>
9778 <p>
9779 <b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
9780 with that of <tt>x</tt>.</p>
9781 <p>
9782 <b>Complexity:</b> Constant time.</p>
9783 </blockquote>
9784
9785 <p><i>[This solves the problem reported for this issue.  We may also
9786 have a problem with a circular definition of swap() for other
9787 containers.]</i></p>
9788
9789 <p><b>Rationale:</b></p>
9790 <p>
9791 swap should be constant time.  The clear intent is that it should just
9792 do pointer twiddling, and that it should exchange all properties of
9793 the two vectors, including their reallocation guarantees.
9794 </p>
9795 <hr>
9796 <a name="345"><h3>345.&nbsp;type tm in &lt;cwchar&gt;</h3></a><p>
9797 <b>Section:</b>&nbsp;21.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.c.strings"> [lib.c.strings]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Clark Nelson&nbsp; <b>Date:</b>&nbsp;19 Oct 2001</p>
9798 <p>
9799 C99, and presumably amendment 1 to C90, specify that &lt;wchar.h&gt;
9800 declares struct tm as an incomplete type. However, table 48 in 21.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.c.strings"> [lib.c.strings]</a> does not mention the type tm as being declared in
9801 &lt;cwchar&gt;. Is this omission intentional or accidental?
9802 </p>
9803 <p><b>Proposed resolution:</b></p>
9804 <p>In section 21.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-strings.html#lib.c.strings"> [lib.c.strings]</a>, add "tm" to table 48.</p>
9805 <hr>
9806 <a name="346"><h3>346.&nbsp;Some iterator member functions should be const</h3></a><p>
9807 <b>Section:</b>&nbsp;24.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Jeremy Siek&nbsp; <b>Date:</b>&nbsp;20 Oct 2001</p>
9808 <p>Iterator member functions and operators that do not change the state
9809 of the iterator should be defined as const member functions or as
9810 functions that take iterators either by const reference or by
9811 value. The standard does not explicitly state which functions should
9812 be const.  Since this a fairly common mistake, the following changes
9813 are suggested to make this explicit.</p>
9814
9815 <p>The tables almost indicate constness properly through naming: r
9816 for non-const and a,b for const iterators. The following changes
9817 make this more explicit and also fix a couple problems.</p>
9818 <p><b>Proposed resolution:</b></p>
9819 <p>In 24.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> Change the first section of p9 from
9820 "In the following sections, a and b denote values of X..." to
9821 "In the following sections, a and b denote values of type const X...".</p>
9822
9823 <p>In Table 73, change</p>
9824 <pre>    a-&gt;m   U&amp;         ...
9825 </pre>
9826
9827 <p>to</p>
9828
9829 <pre>    a-&gt;m   const U&amp;   ...
9830     r-&gt;m   U&amp;         ...
9831 </pre>
9832
9833 <p>In Table 73 expression column, change</p>
9834
9835 <pre>    *a = t
9836 </pre>
9837
9838 <p>to</p>
9839
9840 <pre>    *r = t
9841 </pre>
9842
9843 <p><i>[Redmond: The container requirements should be reviewed to see if
9844 the same problem appears there.]</i></p>
9845
9846 <hr>
9847 <a name="349"><h3>349.&nbsp;Minor typographical error in ostream_iterator</h3></a><p>
9848 <b>Section:</b>&nbsp;24.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterator]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;24 Oct 2001</p>
9849 <p>24.5.2 [lib.ostream.iterator] states:</p>
9850 <pre>    [...]
9851
9852     private:
9853     // basic_ostream&lt;charT,traits&gt;* out_stream; exposition only
9854     // const char* delim; exposition only
9855 </pre>
9856
9857 <p>Whilst it's clearly marked "exposition only", I suspect 'delim'
9858 should be of type 'const charT*'.</p>
9859 <p><b>Proposed resolution:</b></p>
9860 <p>
9861 In 24.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterator]</a>, replace <tt>const char* delim</tt> with
9862 <tt>const charT* delim</tt>.
9863 </p>
9864 <hr>
9865 <a name="354"><h3>354.&nbsp;Associative container lower/upper bound requirements</h3></a><p>
9866 <b>Section:</b>&nbsp;23.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Aberg&nbsp; <b>Date:</b>&nbsp;17 Dec 2001</p>
9867 <p>
9868 Discussions in the thread "Associative container lower/upper bound
9869 requirements" on comp.std.c++ suggests that there is a defect in the
9870 C++ standard, Table 69 of section 23.1.2, "Associative containers",
9871 [lib.associative.reqmts].  It currently says:</p>
9872
9873 <blockquote>
9874 <p>
9875 a.find(k): returns an iterator pointing to an element with the key equivalent to
9876 k, or a.end() if such an element is not found.
9877 </p>
9878
9879 <p>
9880 a.lower_bound(k): returns an iterator pointing to the first element with
9881 key not less than k.
9882 </p>
9883
9884 <p>
9885 a.upper_bound(k): returns an iterator pointing to the first element with
9886 key greater than k.
9887 </p>
9888 </blockquote>
9889
9890 <p>
9891 We have "or a.end() if such an element is not found" for
9892 <tt>find</tt>, but not for <tt>upper_bound</tt> or
9893 <tt>lower_bound</tt>.  As the text stands, one would be forced to
9894 insert a new element into the container and return an iterator to that
9895 in case the sought iterator does not exist, which does not seem to be
9896 the intention (and not possible with the "const" versions).
9897 </p>
9898 <p><b>Proposed resolution:</b></p>
9899
9900 <p>Change Table 69 of section 23.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> indicated entries
9901 to:</p>
9902
9903 <blockquote>
9904 <p>
9905 a.lower_bound(k): returns an iterator pointing to the first element with
9906 key not less than k, or a.end() if such an element is not found.
9907 </p>
9908
9909 <p>
9910 a.upper_bound(k): returns an iterator pointing to the first element with
9911 key greater than k, or a.end() if such an element is not found.
9912 </p>
9913 </blockquote>
9914
9915 <p><i>[Curaçao: LWG reviewed PR.]</i></p>
9916
9917 <hr>
9918 <a name="358"><h3>358.&nbsp;interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt>
9919 </h3></a><p>
9920 <b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
9921 <p>
9922 I don't think <tt>thousands_sep</tt> is being treated correctly after
9923 decimal_point has been seen. Since grouping applies only to the
9924 integral part of the number, the first such occurrence should, IMO,
9925 terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
9926 and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
9927 interpreted in the fractional part of a number.)
9928 </p>
9929
9930 <p>
9931 The easiest change I can think of that resolves this issue would be
9932 something like below.
9933 </p>
9934 <p><b>Proposed resolution:</b></p>
9935 <p>
9936 Change the first sentence of 22.2.2.1.2, p9 from
9937 </p>
9938
9939 <blockquote>
9940     If discard is true then the position of the character is
9941     remembered, but the character is otherwise ignored. If it is not
9942     discarded, then a check is made to determine if c is allowed as
9943     the next character of an input field of the conversion specifier
9944     returned by stage 1. If so it is accumulated.
9945 </blockquote>
9946
9947 <p>to</p>
9948
9949 <blockquote>
9950     If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
9951     accumulated, then the position of the character is remembered, but
9952     the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
9953     already been accumulated, the character is discarded and Stage 2
9954      terminates. ...
9955 </blockquote>
9956
9957 <p><b>Rationale:</b></p>
9958 <p>We believe this reflects the intent of the Standard.  Thousands sep
9959   characters after the decimal point are not useful in any locale.
9960   Some formatting conventions do group digits that follow the decimal
9961   point, but they usually introduce a different grouping character
9962   instead of reusing the thousand sep character.  If we want to add
9963   support for such conventions, we need to do so explicitly.</p>
9964
9965 <hr>
9966 <a name="360"><h3>360.&nbsp;locale mandates inefficient implementation</h3></a><p>
9967 <b>Section:</b>&nbsp;22.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
9968 <p>
9969 22.1.1, p7 (copied below) allows iostream formatters and extractors
9970 to make assumptions about the values returned from facet members.
9971 However, such assumptions are apparently not guaranteed to hold
9972 in other cases (e.g., when the facet members are being called directly
9973 rather than as a result of iostream calls, or between successive
9974 calls to the same iostream functions with no interevening calls to
9975 <tt>imbue()</tt>, or even when the facet member functions are called
9976 from other member functions of other facets). This restriction
9977 prevents locale from being implemented efficiently.
9978 </p>
9979 <p><b>Proposed resolution:</b></p>
9980 <p>Change the first sentence in 22.1.1, p7 from</p>
9981 <blockquote>
9982     In successive calls to a locale facet member function during
9983     a call to an iostream inserter or extractor or a streambuf member
9984     function, the returned result shall be identical. [Note: This
9985     implies that such results may safely be reused without calling
9986     the locale facet member function again, and that member functions
9987     of iostream classes cannot safely call <tt>imbue()</tt>
9988     themselves, except as specified elsewhere. --end note]
9989 </blockquote>
9990
9991 <p>to</p>
9992
9993 <blockquote>
9994     In successive calls to a locale facet member function on a facet
9995     object installed in the same locale, the returned result shall be
9996     identical. ...
9997 </blockquote>
9998
9999 <p><b>Rationale:</b></p>
10000 <p>This change is reasonable becuase it clarifies the intent of this
10001   part of the standard.</p>
10002 <hr>
10003 <a name="363"><h3>363.&nbsp;Missing exception specification in 27.4.2.1.1</h3></a><p>
10004 <b>Section:</b>&nbsp;27.4.2.1.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown and Marc Paterno&nbsp; <b>Date:</b>&nbsp;20 May 2002</p>
10005 <p>
10006 The destructor of ios_base::failure should have an empty throw
10007 specification, because the destructor of its base class, exception, is
10008 declared in this way.
10009 </p>
10010 <p><b>Proposed resolution:</b></p>
10011 <p>Change the destructor to</p>
10012 <pre>  virtual ~failure() throw();
10013 </pre>
10014 <p><b>Rationale:</b></p>
10015 <p>Fixes an obvious glitch.  This is almost editorial.</p>
10016 <hr>
10017 <a name="364"><h3>364.&nbsp;Inconsistent wording in 27.5.2.4.2</h3></a><p>
10018 <b>Section:</b>&nbsp;27.5.2.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown, Marc Paterno&nbsp; <b>Date:</b>&nbsp;10 May 2002</p>
10019 <p>
10020 27.5.2.4.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a> paragraph 1 is inconsistent with the Effects
10021 clause for seekoff.
10022 </p>
10023 <p><b>Proposed resolution:</b></p>
10024 <p>
10025 Make this paragraph, the Effects clause for setbuf, consistent in wording
10026 with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
10027 to indicate the purpose of setbuf:
10028 </p>
10029
10030 <p>Original text:</p>
10031
10032 <blockquote>
10033 1 Effects: Performs an operation that is defined separately for each
10034 class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
10035 </blockquote>
10036
10037 <p>Proposed text:</p>
10038
10039 <blockquote>
10040 1 Effects: Influences stream buffering in a way that is defined separately
10041 for each class derived from basic_streambuf in this clause
10042 (27.7.1.3, 27.8.1.4).
10043 </blockquote>
10044
10045 <p><b>Rationale:</b></p>
10046 <p>The LWG doesn't believe there is any normative difference between
10047   the existing wording and what's in the proposed resolution, but the
10048   change may make the intent clearer.</p>
10049 <hr>
10050 <a name="370"><h3>370.&nbsp;Minor error in basic_istream::get</h3></a><p>
10051 <b>Section:</b>&nbsp;27.6.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;15 Jul 2002</p>
10052 <p>Defect report for description of basic_istream::get (section 27.6.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), paragraph 15. The description for the get function
10053 with the following signature:</p>
10054
10055 <pre>  basic_istream&lt;charT,traits&gt;&amp; get(basic_streambuf&lt;char_type,traits&gt;&amp;
10056   sb);
10057 </pre>
10058
10059 <p>is incorrect. It reads</p>
10060
10061 <blockquote>
10062   Effects: Calls get(s,n,widen('\n'))
10063 </blockquote>
10064
10065 <p>which I believe should be:</p>
10066
10067 <blockquote>
10068   Effects: Calls get(sb,widen('\n'))
10069 </blockquote>
10070 <p><b>Proposed resolution:</b></p>
10071 <p>Change the <b>Effects</b> paragraph to:</p>
10072 <blockquote>
10073   Effects: Calls get(sb,this-&gt;widen('\n'))
10074 </blockquote>
10075
10076 <p><i>[Pre-Oxford: Minor correction from Howard: replaced 'widen'
10077       with 'this-&gt;widen'.]</i></p>
10078
10079 <p><b>Rationale:</b></p>
10080 <p>Fixes an obvious typo.</p>
10081 <hr>
10082 <a name="373"><h3>373.&nbsp;Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</h3></a><p>
10083 <b>Section:</b>&nbsp;27.6.1.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>, 27.6.2.5.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Keith Baker&nbsp; <b>Date:</b>&nbsp;23 Jul 2002</p>
10084
10085 <p>
10086 In 27.6.1.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> and 27.6.2.5.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>
10087 (exception()&amp;badbit) != 0 is used in testing for rethrow, yet
10088 exception() is the constructor to class std::exception in 18.6.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-support.html#lib.exception"> [lib.exception]</a> that has no return type. Should member function
10089 exceptions() found in 27.4.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios"> [lib.ios]</a> be used instead?
10090 </p>
10091
10092 <p><b>Proposed resolution:</b></p>
10093 <p>
10094 In 27.6.1.2.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> and 27.6.2.5.1 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>, change
10095 "(exception()&amp;badbit) != 0" to "(exceptions()&amp;badbit) != 0".
10096 </p>
10097 <p><b>Rationale:</b></p>
10098 <p>Fixes an obvious typo.</p>
10099 <hr>
10100 <a name="375"><h3>375.&nbsp;basic_ios should be ios_base in 27.7.1.3</h3></a><p>
10101 <b>Section:</b>&nbsp;27.7.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
10102 <p>
10103 In Section 27.7.1.3 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>: Table 90, Table 91, and paragraph
10104 14 all contain references to "basic_ios::" which should be
10105 "ios_base::".
10106 </p>
10107 <p><b>Proposed resolution:</b></p>
10108 <p>
10109 Change all references to "basic_ios" in Table 90, Table 91, and
10110 paragraph 14 to "ios_base".
10111 </p>
10112 <p><b>Rationale:</b></p>
10113 <p>Fixes an obvious typo.</p>
10114 <hr>
10115 <a name="380"><h3>380.&nbsp;typos in codecvt tables 53 and 54</h3></a><p>
10116 <b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
10117 <p>
10118 Tables 53 and 54 in 22.2.1.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> are both titled "convert
10119 result values," when surely "do_in/do_out result values" must have
10120 been intended for Table 53 and "do_unshift result values" for Table
10121 54.
10122 </p>
10123 <p>
10124 Table 54, row 3 says that the meaning of partial is "more characters
10125 needed to be supplied to complete termination." The function is not
10126 supplied any characters, it is given a buffer which it fills with
10127 characters or, more precisely, destination elements (i.e., an escape
10128 sequence). So partial means that space for more than (to_limit - to)
10129 destination elements was needed to terminate a sequence given the
10130 value of state.
10131 </p>
10132 <p><b>Proposed resolution:</b></p>
10133 <p>
10134 Change the title of Table 53 to "do_in/do_out result values" and
10135 the title of Table 54 to "do_unshift result values."
10136 </p>
10137 <p>
10138 Change the text in Table 54, row 3 (the <b>partial</b> row), under the
10139 heading Meaning, to "space for more than (to_limit - to) destination
10140 elements was needed to terminate a sequence given the value of state."
10141 </p>
10142 <hr>
10143 <a name="381"><h3>381.&nbsp;detection of invalid mbstate_t in codecvt</h3></a><p>
10144 <b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
10145 <p>
10146 All but one codecvt member functions that take a state_type argument
10147 list as one of their preconditions that the state_type argument have
10148 a valid value. However, according to 22.2.1.5.2, p6,
10149 codecvt::do_unshift() is the only codecvt member that is supposed to
10150 return error if the state_type object is invalid.
10151 </p>
10152
10153 <p>
10154 It seems to me that the treatment of state_type by all codecvt member
10155 functions should be the same and the current requirements should be
10156 changed. Since the detection of invalid state_type values may be
10157 difficult in general or computationally expensive in some specific
10158 cases, I propose the following:
10159 </p>
10160 <p><b>Proposed resolution:</b></p>
10161 <p>
10162 Add a new paragraph before 22.2.1.5.2, p5, and after the function
10163 declaration below
10164 </p>
10165 <pre>    result do_unshift(stateT&amp; state,
10166     externT* to, externT* to_limit, externT*&amp; to_next) const;
10167 </pre>
10168 <p>
10169 as follows:
10170 </p>
10171 <pre>    Requires: (to &lt;= to_end) well defined and true; state initialized,
10172     if at the beginning of a sequence, or else equal to the result of
10173     converting the preceding characters in the sequence.
10174 </pre>
10175 <p>
10176 and change the text in Table 54, row 4, the <b>error</b> row, under
10177 the heading Meaning, from
10178 </p>
10179 <pre>    state has invalid value
10180 </pre>
10181 <p>
10182 to
10183 </p>
10184 <pre>    an unspecified error has occurred
10185 </pre>
10186 <p><b>Rationale:</b></p>
10187 <p>The intent is that implementations should not be required to detect
10188 invalid state values; such a requirement appears nowhere else.  An
10189 invalid state value is a precondition violation, <i>i.e.</i> undefined
10190 behavior.  Implementations that do choose to detect invalid state
10191 values, or that choose to detect any other kind of error, may return
10192 <b>error</b> as an indication.</p>
10193 <hr>
10194 <a name="383"><h3>383.&nbsp;Bidirectional iterator assertion typo</h3></a><p>
10195 <b>Section:</b>&nbsp;24.1.4 <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;ysapir (submitted via comp.std.c++)&nbsp; <b>Date:</b>&nbsp;17 Oct 2002</p>
10196 <p>
10197 Following a discussion on the boost list regarding end iterators and
10198 the possibility of performing operator--() on them, it seems to me
10199 that there is a typo in the standard.  This typo has nothing to do
10200 with that discussion.
10201 </p>
10202
10203 <p>
10204 I have checked this newsgroup, as well as attempted a search of the
10205 Active/Defect/Closed Issues List on the site for the words "s is
10206 derefer" so I believe this has not been proposed before.  Furthermore,
10207 the "Lists by Index" mentions only DR <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a> on section
10208 24.1.4, and DR <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a> is not related to this issue.
10209 </p>
10210
10211 <p>
10212 The standard makes the following assertion on bidirectional iterators,
10213 in section 24.1.4 [lib.bidirectional.iterators], Table 75:
10214 </p>
10215
10216 <pre>                         operational  assertion/note
10217 expression  return type   semantics    pre/post-condition
10218
10219 --r          X&amp;                        pre: there exists s such
10220                                        that r == ++s.
10221                                        post: s is dereferenceable.
10222                                        --(++r) == r.
10223                                        --r == --s implies r == s.
10224                                        &amp;r == &amp;--r.
10225 </pre>
10226
10227 <p>
10228 (See <a href="http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763">http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763</a>.)
10229 </p>
10230
10231 <p>
10232 In particular, "s is dereferenceable" seems to be in error.  It seems
10233 that the intention was to say "r is dereferenceable".
10234 </p>
10235
10236 <p>
10237 If it were to say "r is dereferenceable" it would
10238 make perfect sense.  Since s must be dereferenceable prior to
10239 operator++, then the natural result of operator-- (to undo operator++)
10240 would be to make r dereferenceable.  Furthermore, without other
10241 assertions, and basing only on precondition and postconditions, we
10242 could not otherwise know this.  So it is also interesting information.
10243 </p>
10244
10245 <p><b>Proposed resolution:</b></p>
10246 <p>
10247 Change the guarantee to "postcondition: r is dereferenceable."
10248 </p>
10249 <p><b>Rationale:</b></p>
10250 <p>Fixes an obvious typo</p>
10251 <p>----- End of document -----</p>
10252 </body></html>