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

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
   2 <html><head><title>C++ Standard Library Active Issues List</title></head>
   3
   4 <body bgcolor="#ffffff" text="#000000">
   5 <table>
   6 <tbody><tr>
   7 <td align="left">Doc. no.</td>
   8 <td align="left">N1753=05-0013</td>
   9 </tr>
  10 <tr>
  11 <td align="left">Date:</td>
  12 <td align="left">2005-01-17</td>
  13 </tr>
  14 <tr>
  15 <td align="left">Project:</td>
  16 <td align="left">Programming Language C++</td>
  17 </tr>
  18 <tr>
  19 <td align="left">Reply to:</td>
  20 <td align="left">Matt Austern &lt;austern@apple.com&gt;</td>
  21 </tr>
  22 </tbody></table>
  23 <h1>C++ Standard Library Active Issues List (Revision 34)</h1>
  24   <p>Reference ISO/IEC IS 14882:1998(E)</p>
  25   <p>Also see:</p>
  26   <ul>
  27       <li>
  28 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-toc.html">Table of Contents</a> for all library issues.</li>
  29       <li>
  30 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-index.html">Index by Section</a> for all library issues.</li>
  31       <li>
  32 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-status.html">Index by Status</a> for all library issues.</li>
  33       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html">Library Defect Reports List</a></li>
  34       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html">Library Closed Issues List</a></li>
  35   </ul>
  36   <p>The purpose of this document is to record the status of issues
  37   which have come before the Library Working Group (LWG) of the ANSI
  38   (J16) and ISO (WG21) C++ Standards Committee. Issues represent
  39   potential defects in the ISO/IEC IS 14882:1998(E) document.  Issues
  40   are not to be used to request new features. </p>
  41
  42   <p>This document contains only library issues which are actively being
  43   considered by the Library Working Group. That is, issues which have a
  44   status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>,
  45   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Review">Review</a>. See
  46   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html">Library Defect Reports List</a> for issues considered defects and
  47   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</p>
  48
  49   <p>The issues in these lists are not necessarily formal ISO Defect
  50   Reports (DR's). While some issues will eventually be elevated to
  51   official Defect Report status, other issues will be disposed of in
  52   other ways. See <a href="#Status">Issue Status</a>.</p>
  53
  54   <p>This document is in an experimental format designed for both
  55   viewing via a world-wide web browser and hard-copy printing. It
  56   is available as an HTML file for browsing or PDF file for
  57   printing.</p>
  58
  59   <p>Prior to Revision 14, library issues lists existed in two slightly
  60   different versions; a Committee Version and a Public
  61   Version. Beginning with Revision 14 the two versions were combined
  62   into a single version.</p>
  63
  64   <p>This document includes <i>[bracketed italicized notes]</i> as a
  65   reminder to the LWG of current progress on issues. Such notes are
  66   strictly unofficial and should be read with caution as they may be
  67   incomplete or incorrect. Be aware that LWG support for a particular
  68   resolution can quickly change if new viewpoints or killer examples are
  69   presented in subsequent discussions.</p>
  70
  71   <p>For the most current official version of this document see
  72   <a href="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21/</a>.
  73   Requests for further information about this document should include
  74   the document number above, reference ISO/IEC 14882:1998(E), and be
  75   submitted to Information Technology Industry Council (ITI), 1250 Eye
  76   Street NW, Washington, DC 20005.</p>
  77
  78   <p>Public information as to how to obtain a copy of the C++ Standard,
  79   join the standards committee, submit an issue, or comment on an issue
  80   can be found in the comp.std.c++ FAQ.
  81   Public discussion of C++ Standard related issues occurs on <a href="news://comp.std.c++/">news:comp.std.c++</a>.
  82   </p>
  83
  84  <p>For committee members, files available on the committee's private
  85   web site include the HTML version of the Standard itself. HTML
  86   hyperlinks from this issues list to those files will only work for
  87   committee members who have downloaded them into the same disk
  88   directory as the issues list files.  </p>
  89 <h2>Revision History</h2>
  90 <ul>
  91 <li>R34:
  92 2005-01 mid-term mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#494">494</a>.
  93 </li>
  94 <li>R33:
  95 2004-11 post-Redmond mailing.  Reflections actions taken in Redmond.
  96 </li>
  97 <li>R32:
  98 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
  99 new issues received after the 2004-07 mailing.  Added
 100 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#481">481</a>.
 101 </li>
 102 <li>R31:
 103 2004-07 mid-term mailing: reflects new proposed resolutions and
 104 new issues received after the post-Sydney mailing.  Added
 105 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#478">478</a>.
 106 </li>
 107 <li>R30:
 108 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 109 Voted all "Ready" issues from R29 into the working paper.
 110 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#462">462</a>.
 111 </li>
 112 <li>R29:
 113 Pre-Sydney mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#457">457</a>.
 114 </li>
 115 <li>R28:
 116 Post-Kona mailing: reflects decisions made at the Kona meeting.
 117 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#432">432</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#440">440</a>.
 118 </li>
 119 <li>R27:
 120 Pre-Kona mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#431">431</a>.
 121 </li>
 122 <li>R26:
 123 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
 124 All issues in Ready status were voted into DR status.  All issues in
 125 DR status were voted into WP status.
 126 </li>
 127 <li>R25:
 128 Pre-Oxford mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#390">390</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#402">402</a>.
 129 </li>
 130 <li>R24:
 131 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
 132 meeting.  All Ready issues from R23 with the exception of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#253">253</a>, which has been given a new proposed resolution, were
 133 moved to DR status.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#389">389</a>.  (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#389">389</a> were discussed
 134 at the meeting.)  Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#225">225</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining
 135 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#226">226</a> involve wording.
 136 </li>
 137 <li>R23:
 138 Pre-Santa Cruz mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#367">367</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#382">382</a>.
 139 Moved issues in the TC to TC status.
 140 </li>
 141 <li>R22:
 142 Post-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#366">366</a>.
 143 </li>
 144 <li>R21:
 145 Pre-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#361">361</a>.
 146 </li>
 147 <li>R20:
 148 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 149 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#336">336</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#350">350</a>, of which issues
 150 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#347">347</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#350">350</a> were added since Redmond, hence
 151 not discussed at the meeting.
 152
 153 All Ready issues were moved to DR status, with the exception of issues
 154 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#241">241</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#267">267</a>.
 155
 156 Noteworthy issues discussed at Redmond include
 157 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#120">120</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#233">233</a>,
 158 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#323">323</a>.
 159 </li>
 160 <li>R19:
 161 Pre-Redmond mailing.  Added new issues
 162 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#323">323</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#335">335</a>.
 163 </li>
 164 <li>R18:
 165 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
 166 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#312">312</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#317">317</a>, and discussed
 167 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#271">271</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#314">314</a>.
 168
 169 Changed status of issues
 170 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#103">103</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#118">118</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#136">136</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#153">153</a>
 171 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#165">165</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#171">171</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#183">183</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#184">184</a>
 172 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#185">185</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#186">186</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#214">214</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#221">221</a>
 173 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#234">234</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#237">237</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#243">243</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#248">248</a>
 174 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#251">251</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#252">252</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#256">256</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#260">260</a>
 175 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#261">261</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#262">262</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#263">263</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#265">265</a>
 176 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#268">268</a>
 177 to DR.
 178
 179 Changed status of issues
 180 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#49">49</a>  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#109">109</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#117">117</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#182">182</a>
 181 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#228">228</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#230">230</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#232">232</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#235">235</a>
 182 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#238">238</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#241">241</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#242">242</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#250">250</a>
 183 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#259">259</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#264">264</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#266">266</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#267">267</a>
 184 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#271">271</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#272">272</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#273">273</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#275">275</a>
 185 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#281">281</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#284">284</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#285">285</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#286">286</a>
 186 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#288">288</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#292">292</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#295">295</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#297">297</a>
 187 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#298">298</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#301">301</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#303">303</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#306">306</a>
 188 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#307">307</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#308">308</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#312">312</a>
 189 to Ready.
 190
 191 Closed issues
 192 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#111">111</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#287">287</a>
 193 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#289">289</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#293">293</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#302">302</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#313">313</a>
 194 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#314">314</a>
 195 as NAD.
 196
 197 </li>
 198 <li>R17:
 199 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 200 resolutions for issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#267">267</a>.
 201 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#278">278</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#311">311</a>.
 202 </li>
 203 <li>R16:
 204 post-Toronto mailing; reflects actions taken in Toronto. Added new
 205 issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#265">265</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#277">277</a>.  Changed status of issues
 206 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#19">19</a>,
 207 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#61">61</a>,
 208 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#108">108</a>,
 209 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#115">115</a>,
 210 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#129">129</a>,
 211 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#142">142</a>,
 212 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#147">147</a>,
 213 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#170">170</a>,
 214 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#208">208</a>,
 215 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#211">211</a>,
 216 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#220">220</a>,
 217 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#224">224</a>,
 218 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#227">227</a> to "DR".  Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#23">23</a>. Reopened
 219 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#2">2</a> and
 220 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#17">17</a>. Fixed
 221 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#70">70</a>: signature should be changed both places it
 222 appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#160">160</a>: previous version didn't fix
 223 the bug in enough places.
 224 </li>
 225 <li>R15:
 226 pre-Toronto mailing. Added issues
 227 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#233">233</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#264">264</a>. Some small HTML formatting
 228 changes so that we pass Weblint tests.
 229 </li>
 230 <li>R14:
 231 post-Tokyo II mailing; reflects committee actions taken in
 232 Tokyo. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#228">228</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#232">232</a>. (00-0019R1/N1242)
 233 </li>
 234 <li>R13:
 235 pre-Tokyo II updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#212">212</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#227">227</a>.
 236 </li>
 237 <li>R12:
 238 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#199">199</a> to
 239 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
 240 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#29">29</a>.  Add further rationale to issue
 241 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#178">178</a>.
 242 </li>
 243 <li>R11:
 244 post-Kona mailing: Updated to reflect LWG and full committee actions
 245 in Kona (99-0048/N1224). Note changed resolution of issues
 246 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#4">4</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#38">38</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#196">196</a>
 247 to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
 248 "closed" documents.  Changed the proposed resolution of issue
 249 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
 250 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#38">38</a>.
 251 </li>
 252 <li>R10:
 253 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#83">83</a>,
 254 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#92">92</a>,
 255 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#190">190</a> to
 256 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 257 </li>
 258 <li>R9:
 259 pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#140">140</a> to
 260 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
 261 "closed" documents. (99-0030/N1206, 25 Aug 99)
 262 </li>
 263 <li>R8:
 264 post-Dublin mailing. Updated to reflect LWG and full committee actions
 265 in Dublin. (99-0016/N1193, 21 Apr 99)
 266 </li>
 267 <li>R7:
 268 pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#131">131</a>,
 269 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#134">134</a>,
 270 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#137">137</a>,
 271 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#139">139</a> (31 Mar 99)
 272 </li>
 273 <li>R6:
 274 pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#128">128</a>,
 275 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 276 </li>
 277 <li>R5:
 278 update issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#112">112</a>; added issues
 279 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#114">114</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#126">126</a>. Format revisions to prepare
 280 for making list public. (30 Dec 98)
 281 </li>
 282 <li>R4:
 283 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#110">110</a>,
 284 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#113">113</a> added, several
 285 issues corrected. (22 Oct 98)
 286 </li>
 287 <li>R3:
 288 post-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#94">94</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#109">109</a>
 289 added, many issues updated to reflect LWG consensus (12 Oct 98)
 290 </li>
 291 <li>R2:
 292 pre-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#73">73</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#93">93</a> added,
 293 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#17">17</a> updated. (29 Sep 98)
 294 </li>
 295 <li>R1:
 296 Correction to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#55">55</a> resolution, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#60">60</a> code
 297 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#64">64</a> title. (17 Sep 98)
 298 </li>
 299 </ul>
 300 <h2>
 301 <a name="Status"></a>Issue Status</h2>
 302   <p><b><a name="New">New</a></b> - The issue has not yet been
 303   reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a
 304   suggestion from the issue submitter, and should not be construed as
 305   the view of LWG.</p>
 306
 307   <p><b><a name="Open">Open</a></b> - The LWG has discussed the issue
 308   but is not yet ready to move the issue forward. There are several
 309   possible reasons for open status:</p>
 310      <ul>
 311         <li>Consensus may have not yet have been reached as to how to deal
 312             with the issue.</li>
 313         <li>Informal consensus may have been reached, but the LWG awaits
 314             exact <b>Proposed Resolution</b> wording for review.</li>
 315         <li>The LWG wishes to consult additional technical experts before
 316             proceeding.</li>
 317         <li>The issue may require further study.</li>
 318      </ul>
 319
 320   <p>A <b>Proposed Resolution</b> for an open issue is still not be
 321   construed as the view of LWG. Comments on the current state of
 322   discussions are often given at the end of open issues in an italic
 323   font. Such comments are for information only and should not be given
 324   undue importance.</p>
 325
 326   <p><b><a name="Dup">Dup</a></b> - The LWG has reached consensus that
 327   the issue is a duplicate of another issue, and will not be further
 328   dealt with. A <b>Rationale</b> identifies the duplicated issue's
 329   issue number.  </p>
 330
 331   <p><b><a name="NAD">NAD</a></b> - The LWG has reached consensus that
 332   the issue is not a defect in the Standard, and the issue is ready to
 333   forward to the full committee as a proposed record of response. A
 334   <b>Rationale</b> discusses the LWG's reasoning.</p>
 335
 336   <p><b><a name="Review">Review</a></b> - Exact wording of a
 337   <b>Proposed Resolution</b> is now available for review on an issue
 338   for which the LWG previously reached informal consensus.</p>
 339
 340   <p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus
 341   that the issue is a defect in the Standard, the <b>Proposed
 342   Resolution</b> is correct, and the issue is ready to forward to the
 343   full committee for further action as a Defect Report (DR).</p>
 344
 345   <p><b><a name="DR">DR</a></b> - (Defect Report) - The full J16
 346   committee has voted to forward the issue to the Project Editor to be
 347   processed as a Potential Defect Report. The Project Editor reviews
 348   the issue, and then forwards it to the WG21 Convenor, who returns it
 349   to the full committee for final disposition. This issues list
 350   accords the status of DR to all these Defect Reports regardless of
 351   where they are in that process.</p>
 352
 353   <p><b><a name="TC">TC</a></b> - (Technical Corrigenda) - The full
 354   WG21 committee has voted to accept the Defect Report's Proposed
 355   Resolution as a Technical Corrigenda.  Action on this issue is thus
 356   complete and no further action is possible under ISO rules.</p>
 357
 358   <p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed
 359   resolution has not been accepted as a Technical Corrigendum, but
 360   the full WG21 committee has voted to apply the Defect Report's Proposed
 361   Resolution to the working paper.</p>
 362
 363   <p><b><a name="RR">RR</a></b> - (Record of Response) - The full WG21
 364   committee has determined that this issue is not a defect in the
 365   Standard. Action on this issue is thus complete and no further
 366   action is possible under ISO rules.</p>
 367
 368   <p><b><a name="Future">Future</a></b> - In addition to the regular
 369   status, the LWG believes that this issue should be revisited at the
 370   next revision of the standard.  It is usually paired with NAD.</p>
 371
 372   <p>Issues are always given the status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a> when
 373   they first appear on the issues list. They may progress to
 374   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a> or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Review">Review</a> while the LWG
 375   is actively working on them. When the LWG has reached consensus on
 376   the disposition of an issue, the status will then change to
 377   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Dup">Dup</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#NAD">NAD</a>, or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a> as appropriate.  Once the full J16 committee votes to
 378   forward Ready issues to the Project Editor, they are given the
 379   status of Defect Report ( <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#DR">DR</a>). These in turn may
 380   become the basis for Technical Corrigenda (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#TC">TC</a>),
 381   or are closed without action other than a Record of Response
 382   (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#RR">RR</a> ). The intent of this LWG process is that
 383   only issues which are truly defects in the Standard move to the
 384   formal ISO DR status.
 385   </p>
 386
 387 <h2>Active Issues</h2>
 388 <hr>
 389 <a name="23"><h3>23.&nbsp;Num_get overflow result</h3></a><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 390 <p>The current description of numeric input does not account for the
 391 possibility of overflow. This is an implicit result of changing the
 392 description to rely on the definition of scanf() (which fails to
 393 report overflow), and conflicts with the documented behavior of
 394 traditional and current implementations. </p>
 395
 396 <p>Users expect, when reading a character sequence that results in a
 397 value unrepresentable in the specified type, to have an error
 398 reported. The standard as written does not permit this. </p>
 399
 400 <p><b>Further comments from Dietmar:</b></p>
 401
 402 <p>
 403 I don't feel comfortable with the proposed resolution to issue 23: It
 404 kind of simplifies the issue to much. Here is what is going on:
 405 </p>
 406
 407 <p>
 408 Currently, the behavior of numeric overflow is rather counter intuitive
 409 and hard to trace, so I will describe it briefly:
 410 </p>
 411
 412 <ul>
 413   <li>
 414     According to 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>
 415     paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
 416     return an input error; otherwise a value is converted to the rules
 417     of <tt>scanf</tt>.
 418   </li>
 419   <li>
 420     <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>.
 421   </li>
 422   <li>
 423     <tt>fscanf()</tt> returns an input failure if during conversion no
 424     character matching the conversion specification could be extracted
 425     before reaching EOF. This is the only reason for <tt>fscanf()</tt>
 426     to fail due to an input error and clearly does not apply to the case
 427     of overflow.
 428   </li>
 429   <li>
 430     Thus, the conversion is performed according to the rules of
 431     <tt>fscanf()</tt> which basically says that <tt>strtod</tt>,
 432     <tt>strtol()</tt>, etc. are to be used for the conversion.
 433   </li>
 434   <li>
 435     The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as
 436     many matching characters as there are and on overflow continue to
 437     consume matching characters but also return a value identical to
 438     the maximum (or minimum for signed types if there was a leading minus)
 439     value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>.
 440   </li>
 441   <li>
 442     Thus, according to the current wording in the standard, overflows
 443     can be detected! All what is to be done is to check <tt>errno</tt>
 444     after reading an element and, of course, clearing <tt>errno</tt>
 445     before trying a conversion. With the current wording, it can be
 446     detected whether the overflow was due to a positive or negative
 447     number for signed types.
 448   </li>
 449 </ul>
 450
 451 <p><b>Further discussion from Redmond:</b></p>
 452
 453 <p>The basic problem is that we've defined our behavior,
 454 including our error-reporting behavior, in terms of C90.  However,
 455 C90's method of reporting overflow in scanf is not technically an
 456 "input error".  The <tt>strto_*</tt> functions are more precise.</p>
 457
 458 <p>There was general consensus that <tt>failbit</tt> should be set
 459 upon overflow.  We considered three options based on this:</p>
 460 <ol>
 461 <li>Set failbit upon conversion error (including overflow), and
 462     don't store any value.</li>
 463 <li>Set failbit upon conversion error, and also set <tt>errno</tt> to
 464     indicated the precise nature of the error.</li>
 465 <li>Set failbit upon conversion error.  If the error was due to
 466     overflow, store +-numeric_limits&lt;T&gt;::max() as an
 467     overflow indication.</li>
 468 </ol>
 469
 470 <p>Straw poll: (1) 5; (2) 0; (3) 8.</p>
 471
 472 <p><b>Further discussion from Santa Cruz:</b></p>
 473
 474 <p>There was some discussion of what the intent of our error
 475   reporting mechanism was.  There was general agreement on the
 476   following principles:</p>
 477 <ul>
 478 <li>We want to convert strings to numbers in the same way as the
 479     C <tt>strto*</tt> functions do.  The same things that those
 480     functions would consider errors, we consider errors.</li>
 481 <li>Overflow is an error.  Floating-point underflow is not an error.
 482     1.e-9999999, for example, should be treated as 0.  (A negative
 483     number whose magnitude is too large is still overflow, and is just
 484     the same error as a positive number whose magnitude is too large.
 485     Finally, <tt>strtoul</tt> already specifies what happens if you
 486     try to convert a sequence beginning with a minus sign into an
 487     unsigned value.)</li>
 488 <li>Our mechanism for reporting errors is to set failbit.  Our
 489     mechanism is not errno.  Nothing in the standard should
 490     require or imply that streams or facets ever set errno.
 491     (Even if some implementations might have that effect.) </li>
 492 </ul>
 493
 494 <p>The crux of the disagreement was that some people, but not all,
 495    believed that the design was also based on a fourth principle:
 496    whenever converstion fails and failbit is set, nothing is to be
 497    extracted and the value of the variable being extracted into is
 498    guaranteed to be unchanged.</p>
 499
 500 <p>Some people believe that upon overflow, an implementation should
 501   "extract" a special value that allows the user to tell that it was
 502   overflow instead of some other kind of error.  Straw poll: 1 person
 503   believed the standard should require that, 2 thought it should
 504   forbid it, and 6 thought the standard should allow but not require
 505   it.</p>
 506
 507 <p><b>Proposed resolution:</b></p>
 508 <p>typo: 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, para 2, bullet 3. Strike "in." from
 509 the end.</p>
 510
 511 <p>Change 22.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.nm.put"> [lib.locale.nm.put]</a>, para 11, bullet 2 from:</p>
 512 <blockquote>
 513 The sequence of chars accumulated in stage 2 would have
 514 caused scanf to report an input failure. ios_base::failbit is
 515 assigned to err.
 516 </blockquote>
 517
 518 <p>to:</p>
 519 <blockquote>
 520 The sequence of chars accumulated in stage 2 would have
 521 caused scanf to report an input failure or to store a value
 522 outside the range representable by val. ios_base::failbit is
 523 assigned to err.
 524 </blockquote>
 525
 526 <p><i>[PJP provided wording. this treats overflow or underflow the same
 527 as an ill-formed field. It's not exactly the consensus from Santa
 528 Cruz, but he thinks it's the simplest and most robust rule and that it
 529 corresponds to widespread common practice.]</i></p>
 530
 531 <p><i>[Kona: Wording here still isn't quite right, partly because it
 532 refers to scanf and the scanf description of error conditions is
 533 murky.  The LWG had to do a very close reading of scanf in an attempt
 534 to figure out what this proposed resolution means.  General agreement
 535 that the correct solution: (1) should not refer to scanf behavior, (2)
 536 should not set errno, (3) should allow users who care to figure out
 537 what kind of error happened. Martin will provide wording, Howard may
 538 help.]</i></p>
 539
 540 <hr>
 541 <a name="96"><h3>96.&nbsp;Vector&lt;bool&gt; is not a container</h3></a><p><b>Section:</b>&nbsp;23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
 542 <p><tt>vector&lt;bool&gt;</tt> is not a container as its reference and
 543 pointer types are not references and pointers. </p>
 544
 545 <p>Also it forces everyone to have a space optimization instead of a
 546 speed one.</p>
 547
 548 <p><b>See also:</b> 99-0008 == N1185 Vector&lt;bool&gt; is
 549 Nonconforming, Forces Optimization Choice.</p>
 550 <p><b>Proposed resolution:</b></p>
 551
 552 <p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>
 553
 554 <p><i>[In Dublin many present felt that failure to meet Container
 555 requirements was a defect. There was disagreement as to whether
 556 or not the optimization requirements constituted a defect.]</i></p>
 557
 558 <p><i>[The LWG looked at the following resolutions in some detail:
 559 <br>
 560 &nbsp;&nbsp;&nbsp;&nbsp; * Not A Defect.<br>
 561 &nbsp;&nbsp;&nbsp;&nbsp; * Add a note explaining that vector&lt;bool&gt; does not meet
 562 Container requirements.<br>
 563 &nbsp;&nbsp;&nbsp;&nbsp; * Remove vector&lt;bool&gt;.<br>
 564 &nbsp;&nbsp;&nbsp;&nbsp; * Add a new category of container requirements which
 565 vector&lt;bool&gt; would meet.<br>
 566 &nbsp;&nbsp;&nbsp;&nbsp; * Rename vector&lt;bool&gt;.<br>
 567 <br>
 568 No alternative had strong, wide-spread, support and every alternative
 569 had at least one "over my dead body" response.<br>
 570 <br>
 571 There was also mention of a transition scheme something like (1) add
 572 vector_bool and deprecate vector&lt;bool&gt; in the next standard. (2)
 573 Remove vector&lt;bool&gt; in the following standard.]</i></p>
 574
 575 <p><i>[Modifying container requirements to permit returning proxies
 576 (thus allowing container requirements conforming vector&lt;bool&gt;)
 577 was also discussed.]</i></p>
 578
 579 <p><i>[It was also noted that there is a partial but ugly workaround in
 580 that vector&lt;bool&gt; may be further specialized with a customer
 581 allocator.]</i></p>
 582
 583 <p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
 584 vector&lt;bool&gt;: More Problems, Better Solutions. Much discussion
 585 of a two step approach: a) deprecate, b) provide replacement under a
 586 new name.  LWG straw vote on that: 1-favor, 11-could live with, 2-over
 587 my dead body.  This resolution was mentioned in the LWG report to the
 588 full committee, where several additional committee members indicated
 589 over-my-dead-body positions.]</i></p>
 590
 591 <p><i>[Tokyo: Not discussed by the full LWG; no one claimed new
 592 insights and so time was more productively spent on other issues. In
 593 private discussions it was asserted that requirements for any solution
 594 include 1) Increasing the full committee's understanding of the
 595 problem, and 2) providing compiler vendors, authors, teachers, and of
 596 course users with specific suggestions as to how to apply the eventual
 597 solution.]</i></p>
 598
 599 <p><i>[Redmond: briefly discussed, since there are options for C++0x
 600   that weren't reasonable for TC1.  Two options were discussed. (1)
 601   deprecate std::vector&lt;bool&gt; and introduce std::bit_vector.  Then
 602   gradually, over a period of years, we could reintroduce
 603   std::vector&lt;bool&gt; but this time as an ordinary vector. (2) Change
 604   iterarator and container requirements so that vector&lt;bool&gt; will
 605   be a fully conforming container.  These options are not mutually
 606   exclusive.]</i></p>
 607 <hr>
 608 <a name="130"><h3>130.&nbsp;Return type of container::erase(iterator) differs for associative containers</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;2 Mar 1999</p>
 609 <p>Table 67 (23.1.1) says that container::erase(iterator) returns an
 610 iterator. Table 69 (23.1.2) says that in addition to this requirement,
 611 associative containers also say that container::erase(iterator)
 612 returns void.  That's not an addition; it's a change to the
 613 requirements, which has the effect of making associative containers
 614 fail to meet the requirements for containers.</p>
 615 <p><b>Proposed resolution:</b></p>
 616
 617 <p>
 618 In 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in Table 69 Associative container
 619 requirements, change the return type of <tt>a.erase(q)</tt> from
 620 <tt>void</tt> to <tt>iterator</tt>.  Change the
 621 assertion/not/pre/post-condition from "erases the element pointed to
 622 by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>.
 623 Returns an iterator pointing to the element immediately following q
 624 prior to the element being erased. If no such element exists, a.end()
 625 is returned."
 626 </p>
 627
 628 <p>
 629 In 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in Table 69 Associative container
 630 requirements, change the return type of <tt>a.erase(q1, q2)</tt>
 631 from <tt>void</tt> to <tt>iterator</tt>.  Change the
 632 assertion/not/pre/post-condition from "erases the elements in the
 633 range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1,
 634 q2)</tt>.  Returns q2."
 635 </p>
 636
 637 <p>
 638 In 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.map"> [lib.map]</a>, in the <tt>map</tt> class synopsis; and
 639 in 23.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.multimap"> [lib.multimap]</a>, in the <tt>multimap</tt> class synopsis; and
 640 in 23.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.set"> [lib.set]</a>, in the <tt>set</tt> class synopsis; and
 641 in 23.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.multiset"> [lib.multiset]</a>, in the <tt>multiset</tt> class synopsis:
 642 change the signature of the first <tt>erase</tt> overload to
 643 </p>
 644 <pre>   iterator erase(iterator position);
 645 </pre>
 646 <p>and change the signature of the third <tt>erase</tt> overload to</p>
 647 <pre>  iterator erase(iterator first, iterator last);
 648 </pre>
 649
 650
 651 <p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p>
 652
 653 <p><i>[Post-Kona: the LWG agrees the return type should be
 654 <tt>iterator</tt>, not <tt>void</tt>.  (Alex Stepanov agrees too.)
 655 Matt provided wording.]</i></p>
 656
 657 <p><i>[
 658  Sydney: the proposed wording went in the right direction, but it
 659  wasn't good enough. We want to return an iterator from the range form
 660  of erase as well as the single-iterator form. Also, the wording is
 661  slightly different from the wording we have for sequences; there's no
 662  good reason for having a difference.  Matt provided new wording,
 663  which we will review at the next meeting.
 664 ]</i></p>
 665
 666 <hr>
 667 <a name="197"><h3>197.&nbsp;max_size() underspecified</h3></a><p><b>Section:</b>&nbsp;20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;21 Oct 1999</p>
 668 <p>Must the value returned by max_size() be unchanged from call to call? </p>
 669
 670 <p>Must the value returned from max_size() be meaningful? </p>
 671
 672 <p>Possible meanings identified in lib-6827: </p>
 673
 674 <p>1) The largest container the implementation can support given "best
 675 case" conditions - i.e. assume the run-time platform is "configured to
 676 the max", and no overhead from the program itself. This may possibly
 677 be determined at the point the library is written, but certainly no
 678 later than compile time.<br>
 679 <br>
 680 2) The largest container the program could create, given "best case"
 681 conditions - i.e. same platform assumptions as (1), but take into
 682 account any overhead for executing the program itself. (or, roughly
 683 "storage=storage-sizeof(program)"). This does NOT include any resource
 684 allocated by the program. This may (or may not) be determinable at
 685 compile time.<br>
 686 <br>
 687 3) The largest container the current execution of the program could
 688 create, given knowledge of the actual run-time platform, but again,
 689 not taking into account any currently allocated resource. This is
 690 probably best determined at program start-up.<br>
 691 <br>
 692 4) The largest container the current execution program could create at
 693 the point max_size() is called (or more correctly at the point
 694 max_size() returns :-), given it's current environment (i.e. taking
 695 into account the actual currently available resources). This,
 696 obviously, has to be determined dynamically each time max_size() is
 697 called. </p>
 698 <p><b>Proposed resolution:</b></p>
 699 <p>Change 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> table 32 max_size() wording from:<br>
 700 <br>
 701 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the largest value that can meaningfully be
 702 passed to X::allocate<br>
 703 to:<br>
 704 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the value of the largest constant expression
 705 (5.19 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/expr.html#expr.const"> [expr.const]</a>) that could ever meaningfully be passed to X::allocate</p>
 706
 707 <p>
 708 Change 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> table 65 max_size() wording from:<br>
 709 <br>
 710 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; size() of the largest possible container.<br>
 711 to:<br>
 712 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the value of the largest constant expression
 713 (5.19 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/expr.html#expr.const"> [expr.const]</a>) that could ever meaningfully be returned by X::size().
 714 </p>
 715
 716 <p><i>[Kona: The LWG informally discussed this and asked Andy Sawyer to submit
 717 an issue.]</i></p>
 718
 719 <p><i>[Tokyo: The LWG believes (1) above is the intended meaning.]</i></p>
 720
 721 <p><i>[Post-Tokyo: Beman Dawes supplied the above resolution at the
 722 request of the LWG. 21.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string.capacity"> [lib.string.capacity]</a> was not changed because it
 723 references max_size() in 23.1.  The term "compile-time" was
 724 avoided because it is not defined anywhere in the standard (even
 725 though it is used several places in the library clauses).]</i></p>
 726
 727 <p><i>[Copenhagen: Exactly what <tt>max_size</tt> means is still
 728 unclear.  It may have a different meaning as a container member
 729 function than as an allocator member function.  For the latter,
 730 it is probably best thought of as an architectural limit.
 731 Nathan will provide new wording.]</i></p>
 732 <hr>
 733 <a name="201"><h3>201.&nbsp;Numeric limits terminology wrong</h3></a><p><b>Section:</b>&nbsp;18.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.limits"> [lib.limits]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Stephen Cleary&nbsp; <b>Date:</b>&nbsp;21 Dec 1999</p>
 734 <p>
 735 In some places in this section, the terms "fundamental types" and
 736 "scalar types" are used when the term "arithmetic types" is intended.
 737 The current usage is incorrect because void is a fundamental type and
 738 pointers are scalar types, neither of which should have
 739 specializations of numeric_limits.
 740 </p>
 741 <p><b>Proposed resolution:</b></p>
 742 <p>Change 18.2 [lib.support.limits] para 1 from:</p>
 743 <blockquote>
 744
 745 <p> The headers &lt;limits&gt;, &lt;climits&gt;, and &lt;cfloat&gt;
 746 supply characteristics of implementation-dependent fundamental types
 747 (3.9.1).</p>
 748 </blockquote>
 749
 750 <p>to:</p>
 751 <blockquote>
 752
 753 <p> The headers &lt;limits&gt;, &lt;climits&gt;, and &lt;cfloat&gt;
 754 supply characteristics of implementation-dependent arithmetic types
 755 (3.9.1).</p>
 756 </blockquote>
 757
 758 <p>Change 18.2.1 [lib.limits] para 1 from:</p>
 759 <blockquote>
 760
 761 <p> The numeric_limits component provides a C++ program with
 762 information about various properties of the implementation's
 763 representation of the fundamental
 764 types.</p>
 765 </blockquote>
 766
 767 <p>to:</p>
 768 <blockquote>
 769
 770 <p> The numeric_limits component provides a C++ program with
 771 information about various properties of the implementation's
 772 representation of the arithmetic
 773 types.</p>
 774 </blockquote>
 775
 776 <p>Change 18.2.1 [lib.limits] para 2 from:</p>
 777 <blockquote>
 778
 779 <p>  Specializations shall be provided for each fundamental type. . .</p>
 780 </blockquote>
 781
 782 <p>to:</p>
 783 <blockquote>
 784
 785 <p>  Specializations shall be provided for each arithmetic type. . .</p>
 786 </blockquote>
 787
 788 <p>Change 18.2.1 [lib.limits] para 4 from:</p>
 789 <blockquote>
 790
 791 <p>  Non-fundamental standard types. . .</p>
 792 </blockquote>
 793
 794 <p>to:</p>
 795 <blockquote>
 796
 797 <p>  Non-arithmetic standard types. . .</p>
 798 </blockquote>
 799
 800 <p>Change 18.2.1.1 [lib.numeric.limits] para 1 from:</p>
 801 <blockquote>
 802
 803 <p> The member is_specialized makes it possible to distinguish between
 804 fundamental types, which have specializations, and non-scalar types,
 805 which
 806 do not.</p>
 807 </blockquote>
 808
 809 <p>to:</p>
 810 <blockquote>
 811
 812 <p> The member is_specialized makes it possible to distinguish between
 813 arithmetic types, which have specializations, and non-arithmetic types,
 814 which do not.</p>
 815 </blockquote>
 816
 817 <p><i>[post-Toronto: The opinion of the LWG is that the wording in the
 818 standard, as well as the wording of the proposed resolution, is
 819 flawed.  The term "arithmetic types" is well defined in C
 820 and C++, and it is not clear that the term is being used correctly.
 821 It is also not clear that the term "implementation
 822 dependent" has any useful meaning in this context.  The biggest
 823 problem is that numeric_limits seems to be intended both for built-in
 824 types and for user-defined types, and the standard doesn't make it
 825 clear how numeric_limits applies to each of those cases.  A wholesale
 826 review of numeric_limits is needed.  A paper would be welcome.]</i></p>
 827 <hr>
 828 <a name="233"><h3>233.&nbsp;Insertion hints in associative containers</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;30 Apr 2000</p>
 829 <p>
 830 If <tt>mm</tt> is a multimap and <tt>p</tt> is an iterator
 831 into the multimap, then <tt>mm.insert(p, x)</tt> inserts
 832 <tt>x</tt> into <tt>mm</tt> with <tt>p</tt> as a hint as
 833 to where it should go.  Table 69 claims that the execution time is
 834 amortized constant if the insert winds up taking place adjacent to
 835 <tt>p</tt>, but does not say when, if ever, this is guaranteed to
 836 happen.  All it says it that <tt>p</tt> is a hint as to where to
 837 insert.
 838 </p>
 839 <p>
 840 The question is whether there is any guarantee about the relationship
 841 between <tt>p</tt> and the insertion point, and, if so, what it
 842 is.
 843 </p>
 844 <p>
 845 I believe the present state is that there is no guarantee: The user
 846 can supply <tt>p</tt>, and the implementation is allowed to
 847 disregard it entirely.
 848 </p>
 849
 850 <p><b>Additional comments from Nathan:</b><br>
 851
 852 The vote [in Redmond] was on whether to elaborately specify the use of
 853 the hint, or to require behavior only if the value could be inserted
 854 adjacent to the hint.  I would like to ensure that we have a chance to
 855 vote for a deterministic treatment: "before, if possible, otherwise
 856 after, otherwise anywhere appropriate", as an alternative to the
 857 proposed "before or after, if possible, otherwise [...]".
 858 </p>
 859
 860
 861 <p><b>Proposed resolution:</b></p>
 862
 863 <p>In table 69 "Associative Container Requirements" in 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in the row for <tt>a.insert(p, t)</tt>,
 864 change</p>
 865
 866 <blockquote>
 867 iterator p is a hint pointing to where the insert
 868 should start to search.
 869 </blockquote>
 870
 871 <p>to</p>
 872
 873 <blockquote>
 874 insertion adjacent to iterator p is preferred if
 875 more than one insertion point is valid.
 876 </blockquote>
 877
 878 <p>and change</p>
 879
 880 <blockquote>
 881 logarithmic in general, but amortized constant if
 882 t is inserted right after p.
 883 </blockquote>
 884
 885 <p>to</p>
 886
 887 <blockquote>
 888 logarithmic in general, but amortized constant if
 889 t is inserted adjacent to iterator p.
 890 </blockquote>
 891
 892 <p><i>[Toronto: there was general agreement that this is a real defect:
 893 when inserting an element x into a multiset that already contains
 894 several copies of x, there is no way to know whether the hint will be
 895 used.  The proposed resolution was that the new element should always
 896 be inserted as close to the hint as possible.  So, for example, if
 897 there is a subsequence of equivalent values, then providing a.begin()
 898 as the hint means that the new element should be inserted before the
 899 subsequence even if a.begin() is far away.  JC van Winkel supplied
 900 precise wording for this proposed resolution, and also for an
 901 alternative resolution in which hints are only used when they are
 902 adjacent to the insertion point.]</i></p>
 903
 904 <p><i>[Copenhagen: the LWG agreed to the original proposed resolution,
 905 in which an insertion hint would be used even when it is far from the
 906 insertion point.  This was contingent on seeing a reference
 907 implementation showing that it is possible to implement this
 908 requirement without loss of efficiency.  John Potter provided such a
 909 reference implementation.]</i></p>
 910
 911 <p><i>[Redmond: The LWG was reluctant to adopt the proposal that
 912 emerged from Copenhagen: it seemed excessively complicated, and went
 913 beyond fixing the defect that we identified in Toronto.  PJP provided
 914 the new wording described in this issue.  Nathan agrees that we
 915 shouldn't adopt the more detailed semantics, and notes: "we know that
 916 you can do it efficiently enough with a red-black tree, but there are
 917 other (perhaps better) balanced tree techniques that might differ
 918 enough to make the detailed semantics hard to satisfy."]</i></p>
 919
 920 <p><i>[Curaçao: Nathan should give us the alternative wording he
 921 suggests so the LWG can decide between the two options.]</i></p>
 922
 923 <hr>
 924 <a name="247"><h3>247.&nbsp;<tt>vector</tt>, <tt>deque::insert</tt> complexity</h3></a><p><b>Section:</b>&nbsp;23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;06 June 2000</p>
 925 <p>Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity
 926 of <tt>vector::insert</tt>:</p>
 927
 928    <blockquote>
 929    Complexity: If first and last are forward iterators, bidirectional
 930    iterators, or random access iterators, the complexity is linear in
 931    the number of elements in the range [first, last) plus the distance
 932    to the end of the vector. If they are input iterators, the complexity
 933    is proportional to the number of elements in the range [first, last)
 934    times the distance to the end of the vector.
 935    </blockquote>
 936
 937 <p>First, this fails to address the non-iterator forms of
 938 <tt>insert</tt>.</p>
 939
 940 <p>Second, the complexity for input iterators misses an edge case --
 941 it requires that an arbitrary number of elements can be added at
 942 the end of a <tt>vector</tt> in constant time.</p>
 943
 944 <p>At the risk of strengthening the requirement, I suggest simply</p>
 945
 946    <blockquote>
 947    Complexity: The complexity is linear in the number of elements
 948    inserted plus the distance to the end of the vector.
 949    </blockquote>
 950
 951 <p>For input iterators, one may achieve this complexity by first
 952 inserting at the end of the <tt>vector</tt>, and then using
 953 <tt>rotate</tt>.</p>
 954
 955 <p>I looked to see if <tt>deque</tt> had a similar problem, and was
 956 surprised to find that <tt>deque</tt> places no requirement on the
 957 complexity of inserting multiple elements (23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>,
 958 paragraph 3):</p>
 959
 960    <blockquote>
 961    Complexity: In the worst case, inserting a single element into a
 962    deque takes time linear in the minimum of the distance from the
 963    insertion point to the beginning of the deque and the distance
 964    from the insertion point to the end of the deque. Inserting a
 965    single element either at the beginning or end of a deque always
 966    takes constant time and causes a single call to the copy constructor
 967    of T.
 968    </blockquote>
 969
 970 <p>I suggest:</p>
 971
 972    <blockquote>
 973    Complexity: The complexity is linear in the number of elements
 974    inserted plus the shorter of the distances to the beginning and
 975    end of the deque.  Inserting a single element at either the
 976    beginning or the end of a deque causes a single call to the copy
 977    constructor of T.
 978    </blockquote>
 979 <p><b>Proposed resolution:</b></p>
 980
 981 <p><i>[Toronto: It's agreed that there is a defect in complexity of
 982 multi-element insert for vector and deque.  For vector, the complexity
 983 should probably be something along the lines of <tt>c<sub>1</sub> * N
 984 + c<sub>2</sub> * distance(i, end())</tt>.  However, there is some
 985 concern about whether it is reasonable to amortize away the copies
 986 that we get from a reallocation whenever we exceed the vector's
 987 capacity.  For deque, the situation is somewhat less clear.  Deque is
 988 notoriously complicated, and we may not want to impose complexity
 989 requirements that would imply any implementation technique more
 990 complicated than a while loop whose body is a single-element
 991 insert.]</i></p>
 992 <hr>
 993 <a name="254"><h3>254.&nbsp;Exception types in clause 19 are constructed from <tt>std::string</tt>
 994 </h3></a><p><b>Section:</b>&nbsp;19.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-diagnostics.html#lib.std.exceptions"> [lib.std.exceptions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Aug 2000</p>
 995 <p>
 996 Many of the standard exception types which implementations are
 997 required to throw are constructed with a const std::string&amp;
 998 parameter. For example:
 999 </p>
1000
1001 <pre>     19.1.5  Class out_of_range                          [lib.out.of.range]
1002      namespace std {
1003        class out_of_range : public logic_error {
1004        public:
1005          explicit out_of_range(const string&amp; what_arg);
1006        };
1007      }
1008
1009    1 The class out_of_range defines the type of objects  thrown  as  excep-
1010      tions to report an argument value not in its expected range.
1011
1012      out_of_range(const string&amp; what_arg);
1013
1014      Effects:
1015        Constructs an object of class out_of_range.
1016      Postcondition:
1017        strcmp(what(), what_arg.c_str()) == 0.
1018 </pre>
1019
1020 <p>
1021 There are at least two problems with this:
1022 </p>
1023 <ol>
1024 <li>A program which is low on memory may end up throwing
1025 std::bad_alloc instead of out_of_range because memory runs out while
1026 constructing the exception object.</li>
1027 <li>An obvious implementation which stores a std::string data member
1028 may end up invoking terminate() during exception unwinding because the
1029 exception object allocates memory (or rather fails to) as it is being
1030 copied.</li>
1031 </ol>
1032
1033 <p>
1034 There may be no cure for (1) other than changing the interface to
1035 out_of_range, though one could reasonably argue that (1) is not a
1036 defect. Personally I don't care that much if out-of-memory is reported
1037 when I only have 20 bytes left, in the case when out_of_range would
1038 have been reported. People who use exception-specifications might care
1039 a lot, though.
1040 </p>
1041
1042 <p>
1043 There is a cure for (2), but it isn't completely obvious. I think a
1044 note for implementors should be made in the standard. Avoiding
1045 possible termination in this case shouldn't be left up to chance.  The
1046 cure is to use a reference-counted "string" implementation
1047 in the exception object. I am not necessarily referring to a
1048 std::string here; any simple reference-counting scheme for a NTBS
1049 would do.
1050 </p>
1051
1052 <p><b>Further discussion, in email:</b></p>
1053
1054 <p>
1055 ...I'm not so concerned about (1). After all, a library implementation
1056 can add const char* constructors as an extension, and users don't
1057 <i>need</i> to avail themselves of the standard exceptions, though this is
1058 a lame position to be forced into.  FWIW, std::exception and
1059 std::bad_alloc don't require a temporary basic_string.
1060 </p>
1061
1062 <p>
1063 ...I don't think the fixed-size buffer is a solution to the problem,
1064 strictly speaking, because you can't satisfy the postcondition
1065 <br>
1066     <tt>&nbsp;&nbsp;strcmp(what(), what_arg.c_str()) == 0</tt>
1067 <br>
1068 For all values of what_arg (i.e. very long values). That means that
1069 the only truly conforming solution requires a dynamic allocation.
1070 </p>
1071
1072 <p><b>Further discussion, from Redmond:</b></p>
1073
1074 <p>The most important progress we made at the Redmond meeting was
1075 realizing that there are two separable issues here: the const
1076 string&amp; constructor, and the copy constructor.  If a user writes
1077 something like <tt>throw std::out_of_range("foo")</tt>, the const
1078 string&amp; constructor is invoked before anything gets thrown.  The
1079 copy constructor is potentially invoked during stack unwinding.</p>
1080
1081 <p>The copy constructor is a more serious problem, becuase failure
1082 during stack unwinding invokes <tt>terminate</tt>.  The copy
1083 constructor must be nothrow. <i>Curaçao: Howard thinks this
1084 requirement may already be present.</i></p>
1085
1086 <p>The fundamental problem is that it's difficult to get the nothrow
1087 requirement to work well with the requirement that the exception
1088 objects store a string of unbounded size, particularly if you also try
1089 to make the const string&amp; constructor nothrow.  Options discussed
1090 include:</p>
1091
1092 <ul>
1093 <li>Limit the size of a string that exception objects are required to
1094 throw: change the postconditions of 19.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-diagnostics.html#lib.domain.error"> [lib.domain.error]</a> paragraph 3
1095 and 19.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-diagnostics.html#lib.runtime.error"> [lib.runtime.error]</a> paragraph 3 to something like this:
1096 "strncmp(what(), what_arg._str(), N) == 0, where N is an
1097 implementation defined constant no smaller than 256".</li>
1098 <li>Allow the const string&amp; constructor to throw, but not the
1099 copy constructor.  It's the implementor's responsibility to get it
1100 right.  (An implementor might use a simple refcount class.)</li>
1101 <li>Compromise between the two: an implementation is not allowed to
1102 throw if the string's length is less than some N, but, if it doesn't
1103 throw, the string must compare equal to the argument.</li>
1104 <li>Add a new constructor that takes a const char*</li>
1105 </ul>
1106
1107 <p>(Not all of these options are mutually exclusive.)</p>
1108
1109 <p><b>Proposed resolution:</b></p>
1110 <p><b>Rationale:</b></p>
1111
1112 <p>Throwing a bad_alloc while trying to construct a message for another
1113 exception-derived class is not necessarily a bad thing.  And the
1114 bad_alloc constructor already has a no throw spec on it (18.4.2.1).</p>
1115
1116 <p><b>Future:</b></p>
1117
1118 <p>All involved would like to see const char* constructors added, but
1119 this should probably be done for C++0X as opposed to a DR.</p>
1120
1121 <p>I believe the no throw specs currently decorating these functions
1122 could be improved by some kind of static no throw spec checking
1123 mechanism (in a future C++ language).  As they stand, the copy
1124 constructors might fail via a call to unexpected.  I think what is
1125 intended here is that the copy constructors can't fail.</p>
1126
1127 <p><i>[Pre-Sydney: reopened at the request of Howard Hinnant.
1128   Post-Redmond: James Kanze noticed that the copy constructors of
1129   exception-derived classes do not have nothrow clauses.  Those
1130   classes have no copy constructors declared, meaning the
1131   compiler-generated implicit copy constructors are used, and those
1132   compiler-generated constructors might in principle throw anything.]</i></p>
1133
1134 <hr>
1135 <a name="258"></a><h3><a name="258">258.&nbsp;Missing allocator requirement</a></h3><p><b>Section:</b>&nbsp;20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;22 Aug 2000</p>
1136 <p>
1137 From lib-7752:
1138 </p>
1139
1140 <p>
1141 I've been assuming (and probably everyone else has been assuming) that
1142 allocator instances have a particular property, and I don't think that
1143 property can be deduced from anything in Table 32.
1144 </p>
1145
1146 <p>
1147 I think we have to assume that allocator type conversion is a
1148 homomorphism.  That is, if x1 and x2 are of type X, where
1149 X::value_type is T, and if type Y is X::template
1150 rebind&lt;U&gt;::other, then Y(x1) == Y(x2) if and only if x1 == x2.
1151 </p>
1152
1153 <p>
1154 Further discussion: Howard Hinnant writes, in lib-7757:
1155 </p>
1156
1157 <p>
1158 I think I can prove that this is not provable by Table 32.  And I agree
1159 it needs to be true except for the "and only if".  If x1 != x2, I see no
1160 reason why it can't be true that Y(x1) == Y(x2).  Admittedly I can't
1161 think of a practical instance where this would happen, or be valuable.
1162 But I also don't see a need to add that extra restriction.  I think we
1163 only need:
1164 </p>
1165
1166 <blockquote>
1167      if (x1 == x2) then Y(x1) == Y(x2)
1168 </blockquote>
1169
1170 <p>
1171 If we decide that == on allocators is transitive, then I think I can
1172 prove the above.  But I don't think == is necessarily transitive on
1173 allocators.  That is:
1174 </p>
1175
1176 <p>
1177 Given x1 == x2  and x2 == x3, this does not mean x1 == x3.
1178 </p>
1179
1180 <p>Example:</p>
1181
1182 <blockquote>
1183 <p>
1184 x1 can deallocate pointers from:  x1, x2, x3    <br>
1185 x2 can deallocate pointers from:  x1, x2, x4    <br>
1186 x3 can deallocate pointers from:  x1, x3        <br>
1187 x4 can deallocate pointers from:  x2, x4
1188 </p>
1189
1190 <p>
1191 x1 == x2, and x2 == x4, but x1 != x4
1192 </p>
1193 </blockquote>
1194 <p><b>Proposed resolution:</b></p>
1195
1196 <p><i>[Toronto: LWG members offered multiple opinions.  One
1197 opinion is that it should not be required that <tt>x1 == x2</tt>
1198 implies <tt>Y(x1) == Y(x2)</tt>, and that it should not even be
1199 required that <tt>X(x1) == x1</tt>.  Another opinion is that
1200 the second line from the bottom in table 32 already implies the
1201 desired property.  This issue should be considered in light of
1202 other issues related to allocator instances.]</i></p>
1203 <hr>
1204 <a name="280"><h3>280.&nbsp;Comparison of reverse_iterator to const reverse_iterator</h3></a><p><b>Section:</b>&nbsp;24.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.reverse.iterators"> [lib.reverse.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Cleary&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
1205 <p>
1206 This came from an email from Steve Cleary to Fergus in reference to
1207 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#179">179</a>. The library working group briefly discussed
1208 this in Toronto and believed it should be a separate issue.  There was
1209 also some reservations about whether this was a worthwhile problem to
1210 fix.
1211 </p>
1212
1213 <p>
1214 Steve said: "Fixing reverse_iterator. std::reverse_iterator can
1215 (and should) be changed to preserve these additional
1216 requirements." He also said in email that it can be done without
1217 breaking user's code: "If you take a look at my suggested
1218 solution, reverse_iterator doesn't have to take two parameters; there
1219 is no danger of breaking existing code, except someone taking the
1220 address of one of the reverse_iterator global operator functions, and
1221 I have to doubt if anyone has ever done that. . .  <i>But</i>, just in
1222 case they have, you can leave the old global functions in as well --
1223 they won't interfere with the two-template-argument functions.  With
1224 that, I don't see how <i>any</i> user code could break."
1225 </p>
1226 <p><b>Proposed resolution:</b></p>
1227 <p>
1228 <b>Section:</b> 24.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a>
1229 add/change the following declarations:</p>
1230 <pre>  A) Add a templated assignment operator, after the same manner
1231         as the templated copy constructor, i.e.:
1232
1233   template &lt; class U &gt;
1234   reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
1235
1236   B) Make all global functions (except the operator+) have
1237   two template parameters instead of one, that is, for
1238   operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
1239
1240        template &lt; class Iterator &gt;
1241        typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
1242                  const reverse_iterator&lt; Iterator &gt;&amp; x,
1243                  const reverse_iterator&lt; Iterator &gt;&amp; y);
1244
1245   with:
1246
1247       template &lt; class Iterator1, class Iterator2 &gt;
1248       typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
1249                  const reverse_iterator &lt; Iterator1 &gt; &amp; x,
1250                  const reverse_iterator &lt; Iterator2 &gt; &amp; y);
1251 </pre>
1252 <p>
1253 Also make the addition/changes for these signatures in
1254 24.4.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.reverse.iter.ops"> [lib.reverse.iter.ops]</a>.
1255 </p>
1256
1257 <p><i>[
1258 Copenhagen: The LWG is concerned that the proposed resolution
1259 introduces new overloads.  Experience shows that introducing
1260 overloads is always risky, and that it would be inappropriate to
1261 make this change without implementation experience.  It may be
1262 desirable to provide this feature in a different way.
1263 ]</i></p>
1264
1265 <hr>
1266 <a name="290"><h3>290.&nbsp;Requirements to for_each and its function object</h3></a><p><b>Section:</b>&nbsp;25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;03 Jan 2001</p>
1267 <p>The specification of the for_each algorithm does not have a
1268 "Requires" section, which means that there are no
1269 restrictions imposed on the function object whatsoever. In essence it
1270 means that I can provide any function object with arbitrary side
1271 effects and I can still expect a predictable result. In particular I
1272 can expect that the function object is applied exactly last - first
1273 times, which is promised in the "Complexity" section.
1274 </p>
1275
1276 <p>I don't see how any implementation can give such a guarantee
1277 without imposing requirements on the function object.
1278 </p>
1279
1280 <p>Just as an example: consider a function object that removes
1281 elements from the input sequence.  In that case, what does the
1282 complexity guarantee (applies f exactly last - first times) mean?
1283 </p>
1284
1285 <p>One can argue that this is obviously a nonsensical application and
1286 a theoretical case, which unfortunately it isn't.  I have seen
1287 programmers shooting themselves in the foot this way, and they did not
1288 understand that there are restrictions even if the description of the
1289 algorithm does not say so.
1290 </p>
1291 <p><b>Proposed resolution:</b></p>
1292 <p>Add a "Requires" section to section 25.1.1 similar to those
1293 proposed for transform and the numeric algorithms (see issue
1294 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#242">242</a>):
1295 </p>
1296
1297 <blockquote>
1298     -2- <b>Requires</b>: In the range [first, last], f shall not invalidate
1299     iterators or subranges.
1300 </blockquote>
1301
1302 <p><i>[Copenhagen: The LWG agrees that a function object passed to an
1303 algorithm should not invalidate iterators in the range that the
1304 algorithm is operating on.  The LWG believes that this should be a
1305 blanket statement in Clause 25, not just a special requirement for
1306 <tt>for_each</tt>.
1307 ]</i></p>
1308
1309 <hr>
1310 <a name="294"><h3>294.&nbsp;User defined macros and standard headers</h3></a><p><b>Section:</b>&nbsp;17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;11 Jan 2001</p>
1311 <p>Paragraph 2 of 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> reads: "A
1312 translation unit that includes a header shall not contain any macros
1313 that define names declared in that header." As I read this, it
1314 would mean that the following program is legal:</p>
1315
1316 <pre>  #define npos 3.14
1317   #include &lt;sstream&gt;
1318 </pre>
1319
1320 <p>since npos is not defined in &lt;sstream&gt;.  It is, however, defined
1321 in &lt;string&gt;, and it is hard to imagine an implementation in
1322 which &lt;sstream&gt; didn't include &lt;string&gt;.</p>
1323
1324 <p>I think that this phrase was probably formulated before it was
1325 decided that a standard header may freely include other standard
1326 headers.  The phrase would be perfectly appropriate for C, for
1327 example.  In light of 17.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.res.on.headers"> [lib.res.on.headers]</a> paragraph 1, however,
1328 it isn't stringent enough.</p>
1329 <p><b>Proposed resolution:</b></p>
1330 <p>In paragraph 2 of 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>, change "A
1331 translation unit that includes a header shall not contain any macros
1332 that define names declared in that header." to "A
1333 translation unit that includes a header shall not contain any macros
1334 that define names declared in any standard header."</p>
1335
1336 <p><i>[Copenhagen: the general idea is clearly correct, but there is
1337 concern about making sure that the two paragraphs in 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> remain consistent.  Nathan will provide new
1338 wording.]</i></p>
1339
1340 <hr>
1341 <a name="299"><h3>299.&nbsp;Incorrect return types for iterator dereference</h3></a><p><b>Section:</b>&nbsp;24.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, 24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;John Potter&nbsp; <b>Date:</b>&nbsp;22 Jan 2001</p>
1342 <p>
1343 In section 24.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>,
1344 Table 75 gives the return type of *r-- as convertible to T.  This is
1345 not consistent with Table 74 which gives the return type of *r++ as
1346 T&amp;.  *r++ = t is valid while *r-- = t is invalid.
1347 </p>
1348
1349 <p>
1350 In section 24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>,
1351 Table 76 gives the return type of a[n] as convertible to T.  This is
1352 not consistent with the semantics of *(a + n) which returns T&amp; by
1353 Table 74.  *(a + n) = t is valid while a[n] = t is invalid.
1354 </p>
1355
1356 <p>
1357 Discussion from the Copenhagen meeting: the first part is
1358 uncontroversial.  The second part, operator[] for Random Access
1359 Iterators, requires more thought.  There are reasonable arguments on
1360 both sides.  Return by value from operator[] enables some potentially
1361 useful iterators, e.g. a random access "iota iterator" (a.k.a
1362 "counting iterator" or "int iterator").  There isn't any obvious way
1363 to do this with return-by-reference, since the reference would be to a
1364 temporary.  On the other hand, <tt>reverse_iterator</tt> takes an
1365 arbitrary Random Access Iterator as template argument, and its
1366 operator[] returns by reference.  If we decided that the return type
1367 in Table 76 was correct, we would have to change
1368 <tt>reverse_iterator</tt>.  This change would probably affect user
1369 code.
1370 </p>
1371
1372 <p>
1373 History: the contradiction between <tt>reverse_iterator</tt> and the
1374 Random Access Iterator requirements has been present from an early
1375 stage.  In both the STL proposal adopted by the committee
1376 (N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
1377 Stepanov and Lee), the Random Access Iterator requirements say that
1378 operator[]'s return value is "convertible to T".  In N0527
1379 reverse_iterator's operator[] returns by value, but in HPL-95-11
1380 (R.1), and in the STL implementation that HP released to the public,
1381 reverse_iterator's operator[] returns by reference.  In 1995, the
1382 standard was amended to reflect the contents of HPL-95-11 (R.1).  The
1383 original intent for operator[] is unclear.
1384 </p>
1385
1386 <p>
1387 In the long term it may be desirable to add more fine-grained
1388 iterator requirements, so that access method and traversal strategy
1389 can be decoupled.  (See "Improved Iterator Categories and
1390 Requirements", N1297 = 01-0011, by Jeremy Siek.)  Any decisions
1391 about issue 299 should keep this possibility in mind.
1392 </p>
1393
1394 <p>Further discussion: I propose a compromise between John Potter's
1395 resolution, which requires <tt>T&amp;</tt> as the return type of
1396 <tt>a[n]</tt>, and the current wording, which requires convertible to
1397 <tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt>
1398 for the return type of the expression <tt>a[n]</tt>, but to also add
1399 <tt>a[n] = t</tt> as a valid expression. This compromise "saves" the
1400 common case uses of random access iterators, while at the same time
1401 allowing iterators such as counting iterator and caching file
1402 iterators to remain random access iterators (iterators where the
1403 lifetime of the object returned by <tt>operator*()</tt> is tied to the
1404 lifetime of the iterator).
1405 </p>
1406
1407 <p>
1408 Note that the compromise resolution necessitates a change to
1409 <tt>reverse_iterator</tt>. It would need to use a proxy to support
1410 <tt>a[n] = t</tt>.
1411 </p>
1412
1413 <p>
1414 Note also there is one kind of mutable random access iterator that
1415 will no longer meet the new requirements. Currently, iterators that
1416 return an r-value from <tt>operator[]</tt> meet the requirements for a
1417 mutable random access iterartor, even though the expression <tt>a[n] =
1418 t</tt> will only modify a temporary that goes away. With this proposed
1419 resolution, <tt>a[n] = t</tt> will be required to have the same
1420 operational semantics as <tt>*(a + n) = t</tt>.
1421 </p>
1422
1423 <p><b>Proposed resolution:</b></p>
1424
1425 <p>
1426 In section 24.1.4 [lib.bidirectdional.iterators], change the return
1427 type in table 75 from "convertible to <tt>T</tt>" to
1428 <tt>T&amp;</tt>.
1429 </p>
1430
1431 <p>
1432 In section 24.1.5 [lib.random.access.iterators], change the
1433 operational semantics for <tt>a[n]</tt> to " the r-value of
1434 <tt>a[n]</tt> is equivalent to the r-value of <tt>*(a +
1435 n)</tt>". Add a new row in the table for the expression <tt>a[n] = t</tt>
1436 with a return type of convertible to <tt>T</tt> and operational semantics of
1437 <tt>*(a + n) = t</tt>.
1438 </p>
1439
1440 <hr>
1441 <a name="309"><h3>309.&nbsp;Does sentry catch exceptions?</h3></a><p><b>Section:</b>&nbsp;27.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.iostream.format"> [lib.iostream.format]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;19 Mar 2001</p>
1442 <p>
1443 The descriptions of the constructors of basic_istream&lt;&gt;::sentry
1444 (27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>) and basic_ostream&lt;&gt;::sentry
1445 (27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>) do not explain what the functions do in
1446 case an exception is thrown while they execute. Some current
1447 implementations allow all exceptions to propagate, others catch them
1448 and set ios_base::badbit instead, still others catch some but let
1449 others propagate.
1450 </p>
1451
1452 <p>
1453 The text also mentions that the functions may call setstate(failbit)
1454 (without actually saying on what object, but presumably the stream
1455 argument is meant).  That may have been fine for
1456 basic_istream&lt;&gt;::sentry prior to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#195">195</a>, since
1457 the function performs an input operation which may fail. However,
1458 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#195">195</a> amends 27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>, p2 to
1459 clarify that the function should actually call setstate(failbit |
1460 eofbit), so the sentence in p3 is redundant or even somewhat
1461 contradictory.
1462 </p>
1463
1464 <p>
1465 The same sentence that appears in 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>, p3
1466 doesn't seem to be very meaningful for basic_istream&lt;&gt;::sentry
1467 which performs no input. It is actually rather misleading since it
1468 would appear to guide library implementers to calling
1469 setstate(failbit) when os.tie()-&gt;flush(), the only called function,
1470 throws an exception (typically, it's badbit that's set in response to
1471 such an event).
1472 </p>
1473
1474 <p><b>Additional comments from Martin, who isn't comfortable with the
1475     current proposed resolution</b> (see c++std-lib-11530)</p>
1476
1477 <p>
1478 The istream::sentry ctor says nothing about how the function
1479 deals with exemptions (27.6.1.1.2, p1 says that the class is
1480 responsible for doing "exception safe"(*) prefix and suffix
1481 operations but it doesn't explain what level of exception
1482 safety the class promises to provide). The mockup example
1483 of a "typical implementation of the sentry ctor" given in
1484 27.6.1.1.2, p6, removed in ISO/IEC 14882:2003, doesn't show
1485 exception handling, either. Since the ctor is not classified
1486 as a formatted or unformatted input function, the text in
1487 27.6.1.1, p1 through p4 does not apply. All this would seem
1488 to suggest that the sentry ctor should not catch or in any
1489 way handle exceptions thrown from any functions it may call.
1490 Thus, the typical implementation of an istream extractor may
1491 look something like [1].
1492 </p>
1493
1494 <p>
1495 The problem with [1] is that while it correctly sets ios::badbit
1496 if an exception is thrown from one of the functions called from
1497 the sentry ctor, if the sentry ctor reaches EOF while extracting
1498 whitespace from a stream that has eofbit or failbit set in
1499 exceptions(), it will cause an ios::failure to be thrown, which
1500 will in turn cause the extractor to set ios::badbit.
1501 </p>
1502
1503 <p>
1504 The only straightforward way to prevent this behavior is to
1505 move the definition of the sentry object in the extractor
1506 above the try block (as suggested by the example in 22.2.8,
1507 p9 and also indirectly supported by 27.6.1.3, p1). See [2].
1508 But such an implementation will allow exceptions thrown from
1509 functions called from the ctor to freely propagate to the
1510 caller regardless of the setting of ios::badbit in the stream
1511 object's exceptions().
1512 </p>
1513
1514 <p>
1515 So since neither [1] nor [2] behaves as expected, the only
1516 possible solution is to have the sentry ctor catch exceptions
1517 thrown from called functions, set badbit, and propagate those
1518 exceptions if badbit is also set in exceptions(). (Another
1519 solution exists that deals with both kinds of sentries, but
1520 the code is non-obvious and cumbersome -- see [3].)
1521 </p>
1522
1523 <p>
1524 Please note that, as the issue points out, current libraries
1525 do not behave consistently, suggesting  that implementors are
1526 not quite clear on the exception handling in istream::sentry,
1527 despite the fact that some LWG members might feel otherwise.
1528 (As documented by the parenthetical comment here:
1529 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1480.html#309)
1530 </p>
1531
1532 <p>
1533 Also please note that those LWG members who in Copenhagen
1534 felt that "a sentry's constructor should not catch exceptions,
1535 because sentries should only be used within (un)formatted input
1536 functions and that exception handling is the responsibility of
1537 those functions, not of the sentries," as noted here
1538 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1310.html#309
1539 would in effect be either arguing for the behavior described
1540 in [1] or for extractors implemented along the lines of [3].
1541 </p>
1542
1543 <p>
1544 The original proposed resolution (Revision 25 of the issues
1545 list) clarifies the role of the sentry ctor WRT exception
1546 handling by making it clear that extractors (both library
1547 or user-defined) should be implemented along the lines of
1548 [2] (as opposed to [1]) and that no exception thrown from
1549 the callees should propagate out of either function unless
1550 badbit is also set in exceptions().
1551 </p>
1552
1553
1554 <p>[1] Extractor that catches exceptions thrown from sentry:</p>
1555
1556 <blockquote>
1557 <pre>struct S { long i; };
1558
1559 istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
1560 {
1561     ios::iostate err = ios::goodbit;
1562     try {
1563         const istream::sentry guard (strm, false);
1564         if (guard) {
1565             use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
1566                 .get (istreambuf_iterator&lt;char&gt;(strm),
1567                       istreambuf_iterator&lt;char&gt;(),
1568                       strm, err, s.i);
1569         }
1570     }
1571     catch (...) {
1572         bool rethrow;
1573         try {
1574             strm.setstate (ios::badbit);
1575             rethrow = false;
1576         }
1577         catch (...) {
1578             rethrow = true;
1579         }
1580         if (rethrow)
1581             throw;
1582     }
1583     if (err)
1584         strm.setstate (err);
1585     return strm;
1586 }
1587 </pre>
1588 </blockquote>
1589
1590 <p>[2] Extractor that propagates exceptions thrown from sentry:</p>
1591
1592 <blockquote>
1593 <pre>istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
1594 {
1595     istream::sentry guard (strm, false);
1596     if (guard) {
1597         ios::iostate err = ios::goodbit;
1598         try {
1599             use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
1600                 .get (istreambuf_iterator&lt;char&gt;(strm),
1601                       istreambuf_iterator&lt;char&gt;(),
1602                       strm, err, s.i);
1603         }
1604         catch (...) {
1605             bool rethrow;
1606             try {
1607                 strm.setstate (ios::badbit);
1608                 rethrow = false;
1609             }
1610             catch (...) {
1611                 rethrow = true;
1612             }
1613             if (rethrow)
1614                 throw;
1615         }
1616         if (err)
1617             strm.setstate (err);
1618     }
1619     return strm;
1620 }
1621 </pre>
1622 </blockquote>
1623
1624 <p>
1625 [3] Extractor that catches exceptions thrown from sentry
1626 but doesn't set badbit if the exception was thrown as a
1627 result of a call to strm.clear().
1628 </p>
1629
1630 <blockquote>
1631 <pre>istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
1632 {
1633     const ios::iostate state = strm.rdstate ();
1634     const ios::iostate except = strm.exceptions ();
1635     ios::iostate err = std::ios::goodbit;
1636     bool thrown = true;
1637     try {
1638         const istream::sentry guard (strm, false);
1639         thrown = false;
1640         if (guard) {
1641             use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
1642                 .get (istreambuf_iterator&lt;char&gt;(strm),
1643                       istreambuf_iterator&lt;char&gt;(),
1644                       strm, err, s.i);
1645         }
1646     }
1647     catch (...) {
1648         if (thrown &amp;&amp; state &amp; except)
1649             throw;
1650         try {
1651             strm.setstate (ios::badbit);
1652             thrown = false;
1653         }
1654         catch (...) {
1655             thrown = true;
1656         }
1657         if (thrown)
1658             throw;
1659     }
1660     if (err)
1661         strm.setstate (err);
1662
1663     return strm;
1664 }
1665 </pre>
1666 </blockquote>
1667
1668
1669 <p><b>Proposed resolution:</b></p>
1670 <p>Remove the last sentence of 27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> p5 (but not
1671   the footnote, which should be moved to the preceding sentence).</p>
1672 <p>Remove the last sentence of 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> p3 (but not
1673   the footnote, which should be moved to the preceding sentence).</p>
1674 <p><b>Rationale:</b></p>
1675 <p>The LWG feels that no clarification of EH policy is necessary: the
1676   standard is precise about which operations sentry's constructor
1677   performs, and about which of those operations can throw.  However, the
1678   sentence at the end should be removed because it's redundant.</p>
1679 <hr>
1680 <a name="342"><h3>342.&nbsp;seek and eofbit</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;09 Oct 201</p>
1681 <p>I think we have a defect.</p>
1682
1683 <p>According to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#60">60</a> which is now a dr, the
1684 description of seekg in 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> paragraph 38 now looks
1685 like:</p>
1686
1687 <blockquote>
1688 Behaves as an unformatted input function (as described in 27.6.1.3,
1689 paragraph 1), except that it does not count the number of characters
1690 extracted and does not affect the value returned by subsequent calls to
1691 gcount(). After constructing a sentry object, if fail() != true,
1692 executes rdbuf()&gt;pubseekpos( pos).
1693 </blockquote>
1694
1695 <p>And according to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#243">243</a> which is also now a dr,
1696 27.6.1.3, paragraph 1 looks like:</p>
1697
1698 <blockquote>
1699 Each unformatted input function begins execution by constructing an
1700 object of class sentry with the default argument noskipws (second)
1701 argument true. If the sentry object returns true, when converted to a
1702 value of type bool, the function endeavors to obtain the requested
1703 input.  Otherwise, if the sentry constructor exits by throwing an
1704 exception or if the sentry object returns false, when converted to a
1705 value of type bool, the function returns without attempting to obtain
1706 any input. In either case the number of extracted characters is set to
1707 0; unformatted input functions taking a character array of non-zero
1708 size as an argument shall also store a null character (using charT())
1709 in the first location of the array. If an exception is thrown during
1710 input then ios::badbit is turned on in *this'ss error state. If
1711 (exception()&amp;badbit)!= 0 then the exception is rethrown. It also counts
1712 the number of characters extracted. If no exception has been thrown it
1713 ends by storing the count in a member object and returning the value
1714 specified. In any event the sentry object is destroyed before leaving
1715 the unformatted input function.
1716 </blockquote>
1717
1718 <p>And finally 27.6.1.1.2/5 says this about sentry:</p>
1719
1720 <blockquote>
1721 If, after any preparation is completed, is.good() is true, ok_ != false
1722 otherwise, ok_ == false.
1723 </blockquote>
1724
1725 <p>
1726 So although the seekg paragraph says that the operation proceeds if
1727 !fail(), the behavior of unformatted functions says the operation
1728 proceeds only if good().  The two statements are contradictory when only
1729 eofbit is set.  I don't think the current text is clear which condition
1730 should be respected.
1731 </p>
1732
1733 <p><b>Further discussion from Redmond:</b></p>
1734
1735 <p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is
1736 "unformatted". That makes specific claims about sentry that
1737 aren't quite appropriate for seeking, which has less fragile failure
1738 modes than actual input.  If we do really mean that it's unformatted
1739 input, it should behave the same way as other unformatted input.  On
1740 the other hand, "principle of least surprise" is that seeking from EOF
1741 ought to be OK.</p>
1742
1743 <p>Dietmar: nothing should depend on eofbit.  Eofbit should only be
1744 examined by the user to determine why something failed.</p>
1745
1746 <p><i>[Taken from c++std-lib-8873, c++std-lib-8874, c++std-lib-8876]</i></p>
1747
1748 <p><b>Proposed resolution:</b></p>
1749
1750 <p><i>[Santa Cruz: On the one hand, it would clearly be silly to seek
1751   to a non-EOF position without resetting eofbit.  On the other hand,
1752   having seek clear eofbit explicitly would set a major precedent:
1753   there is currently <i>no</i> place where any of the flags are reset
1754   without the user explicitly asking for them to be.  This is the tip
1755   of a general problem, that the various flags are stickier than many
1756   users might expect.  Bill, Gaby, and Howard will discuss this issue
1757   and propose a resolution.]</i></p>
1758
1759 <hr>
1760 <a name="356"><h3>356.&nbsp;Meaning of ctype_base::mask enumerators</h3></a><p><b>Section:</b>&nbsp;22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Jan 2002</p>
1761
1762 <p>What should the following program print?</p>
1763
1764 <pre>  #include &lt;locale&gt;
1765   #include &lt;iostream&gt;
1766
1767   class my_ctype : public std::ctype&lt;char&gt;
1768   {
1769     typedef std::ctype&lt;char&gt; base;
1770   public:
1771     my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
1772     {
1773       std::copy(base::classic_table(), base::classic_table() + base::table_size,
1774                 my_table);
1775       my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space);
1776     }
1777   private:
1778     mask my_table[base::table_size];
1779   };
1780
1781   int main()
1782   {
1783     my_ctype ct;
1784     std::cout &lt;&lt; "isspace: " &lt;&lt; ct.is(std::ctype_base::space, '_') &lt;&lt; "    "
1785               &lt;&lt; "isalpha: " &lt;&lt; ct.is(std::ctype_base::alpha, '_') &lt;&lt; std::endl;
1786   }
1787 </pre>
1788
1789 <p>The goal is to create a facet where '_' is treated as whitespace.</p>
1790
1791 <p>On gcc 3.0, this program prints "isspace: 1 isalpha: 0".  On
1792 Microsoft C++ it prints "isspace: 1 isalpha: 1".</p>
1793
1794 <p>
1795 I believe that both implementations are legal, and the standard does not
1796 give enough guidance for users to be able to use std::ctype's
1797 protected interface portably.</p>
1798
1799 <p>
1800 The above program assumes that ctype_base::mask enumerators like
1801 <tt>space</tt> and <tt>print</tt> are disjoint, and that the way to
1802 say that a character is both a space and a printing character is to or
1803 those two enumerators together.  This is suggested by the "exposition
1804 only" values in 22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, but it is nowhere specified in
1805 normative text.  An alternative interpretation is that the more
1806 specific categories subsume the less specific.  The above program
1807 gives the results it does on the Microsoft compiler because, on that
1808 compiler, <tt>print</tt> has all the bits set for each specific
1809 printing character class.
1810 </p>
1811
1812 <p>From the point of view of std::ctype's public interface, there's no
1813 important difference between these two techniques.  From the point of
1814 view of the protected interface, there is.  If I'm defining a facet
1815 that inherits from std::ctype&lt;char&gt;, I'm the one who defines the
1816 value that table()['a'] returns.  I need to know what combination of
1817 mask values I should use.  This isn't so very esoteric: it's exactly
1818 why std::ctype has a protected interface.  If we care about users
1819 being able to write their own ctype facets, we have to give them a
1820 portable way to do it.
1821 </p>
1822
1823 <p>
1824 Related reflector messages:
1825 lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274,
1826 lib-9277, lib-9279.
1827 </p>
1828
1829 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#339">339</a> is related, but not identical.  The
1830 proposed resolution if issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#339">339</a> says that
1831 ctype_base::mask must be a bitmask type. It does not say that the
1832 ctype_base::mask elements are bitmask elements, so it doesn't
1833 directly affect this issue.</p>
1834
1835 <p>More comments from Benjamin Kosnik, who believes that
1836 that C99 compatibility essentially requires what we're
1837 calling option 1 below.</p>
1838
1839 <blockquote>
1840 <pre>I think the C99 standard is clear, that isspace -&gt; !isalpha.
1841 --------
1842
1843 #include &lt;locale&gt;
1844 #include &lt;iostream&gt;
1845
1846 class my_ctype : public std::ctype&lt;char&gt;
1847 {
1848 private:
1849   typedef std::ctype&lt;char&gt; base;
1850   mask my_table[base::table_size];
1851
1852 public:
1853   my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
1854   {
1855     std::copy(base::classic_table(), base::classic_table() + base::table_size,
1856               my_table);
1857     mask both = base::print | base::space;
1858     my_table[static_cast&lt;mask&gt;('_')] = both;
1859   }
1860 };
1861
1862 int main()
1863 {
1864   using namespace std;
1865   my_ctype ct;
1866   cout &lt;&lt; "isspace: " &lt;&lt; ct.is(ctype_base::space, '_') &lt;&lt; endl;
1867   cout &lt;&lt; "isprint: " &lt;&lt; ct.is(ctype_base::print, '_') &lt;&lt; endl;
1868
1869   // ISO C99, isalpha iff upper | lower set, and !space.
1870   // 7.5, p 193
1871   // -&gt; looks like g++ behavior is correct.
1872   // 356 -&gt; bitmask elements are required for ctype_base
1873   // 339 -&gt; bitmask type required for mask
1874   cout &lt;&lt; "isalpha: " &lt;&lt; ct.is(ctype_base::alpha, '_') &lt;&lt; endl;
1875 }
1876 </pre>
1877 </blockquote>
1878
1879 <p><b>Proposed resolution:</b></p>
1880 <p>Informally, we have three choices:</p>
1881 <ol>
1882 <li>Require that the enumerators are disjoint (except for alnum and
1883 graph)</li>
1884 <li>Require that the enumerators are not disjoint, and specify which
1885 of them subsume which others.  (e.g. mandate that lower includes alpha
1886 and print)</li>
1887 <li>Explicitly leave this unspecified, which the result that the above
1888 program is not portable.</li>
1889 </ol>
1890
1891 <p>Either of the first two options is just as good from the standpoint
1892 of portability.  Either one will require some implementations to
1893 change.</p>
1894
1895 <p><i>[
1896 More discussion is needed.  Nobody likes option 3.  Options 1 and 2
1897 are both controversial, 2 perhaps less so.  Benjamin thinks that
1898 option 1 is required for C99 compatibility.
1899 ]</i></p>
1900
1901 <hr>
1902 <a name="362"><h3>362.&nbsp;bind1st/bind2nd type safety</h3></a><p><b>Section:</b>&nbsp;20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Demkin&nbsp; <b>Date:</b>&nbsp;26 Apr 2002</p>
1903 <p>
1904 The definition of bind1st() (20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>) can result in
1905 the construction of an unsafe binding between incompatible pointer
1906 types. For example, given a function whose first parameter type is
1907 'pointer to T', it's possible without error to bind an argument of
1908 type 'pointer to U' when U does not derive from T:
1909 </p>
1910 <pre>   foo(T*, int);
1911
1912    struct T {};
1913    struct U {};
1914
1915    U u;
1916
1917    int* p;
1918    int* q;
1919
1920    for_each(p, q, bind1st(ptr_fun(foo), &amp;u));    // unsafe binding
1921 </pre>
1922
1923 <p>
1924 The definition of bind1st() includes a functional-style conversion to
1925 map its argument to the expected argument type of the bound function
1926 (see below):
1927 </p>
1928 <pre>  typename Operation::first_argument_type(x)
1929 </pre>
1930
1931 <p>
1932 A functional-style conversion (5.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/expr.html#expr.type.conv"> [expr.type.conv]</a>) is defined to be
1933 semantically equivalent to an explicit cast expression (5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/expr.html#expr.cast"> [expr.cast]</a>), which may (according to 5.4, paragraph 5) be interpreted
1934 as a reinterpret_cast, thus masking the error.
1935 </p>
1936
1937 <p>The problem and proposed change also apply to 20.3.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.bind.2nd"> [lib.bind.2nd]</a>.</p>
1938 <p><b>Proposed resolution:</b></p>
1939 <p>
1940 The simplest and most localized change to prevent such errors is to
1941 require bind1st() use a static_cast expression rather than the
1942 functional-style conversion; that is, have bind1st() return:
1943 </p>
1944 <pre>   binder1st&lt;Operation&gt;( op,
1945      static_cast&lt;typename Operation::first_argument_type&gt;(x)).
1946 </pre>
1947
1948 <p>
1949 A more agressive solution is to change the semantics of
1950 functional-style conversions to not permit a reinterpret_cast. For
1951 contexts that require the semantics of reinterpret_cast, the language
1952 may want to require the use of an explicit cast expression such as
1953 '(T) x' or 'reinterpret_cast&lt;T&gt;(x)' and limit the behavior of
1954 the functional notation to match statically-checked and standard
1955 conversions (as defined by 5.2.9 and 4.10, etc.).  Although changing
1956 the semantics of functional-style conversions may seem drastic and
1957 does have language-wide ramifications, it has the benefit of better
1958 unifying the conversion rules for user defined types and built-in
1959 types, which can be especially important for generic template
1960 programming.
1961 </p>
1962
1963 <p><i>[Santa Cruz: it's clear that a function-style cast is
1964   wrong. Maybe a static cast would be better, or maybe no cast at
1965   all.  Jeremy will check with the original author of this part
1966   of the Standard and will see what the original intent was.]</i></p>
1967 <hr>
1968 <a name="366"><h3>366.&nbsp;Excessive const-qualification</h3></a><p><b>Section:</b>&nbsp;27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown, Marc Paterno&nbsp; <b>Date:</b>&nbsp;10 May 2002</p>
1969 <p>
1970 The following member functions are declared const, yet return non-const
1971 pointers. We believe they are should be changed, because they allow code
1972 that may surprise the user. See document N1360 for details and
1973 rationale.
1974 </p>
1975
1976 <p><i>[Santa Cruz: the real issue is that we've got const member
1977 functions that return pointers to non-const, and N1360 proposes
1978 replacing them by overloaded pairs.  There isn't a consensus about
1979 whether this is a real issue, since we've never said what our
1980 constness policy is for iostreams.  N1360 relies on a distinction
1981 between physical constness and logical constness; that distinction, or
1982 those terms, does not appear in the standard.]</i></p>
1983
1984 <p><b>Proposed resolution:</b></p>
1985 <p>In 27.4.4 and 27.4.4.2</p>
1986 <p>Replace</p>
1987 <pre>  basic_ostream&lt;charT,traits&gt;* tie() const;
1988 </pre>
1989 <p>with</p>
1990 <pre>  basic_ostream&lt;charT,traits&gt;* tie();
1991   const basic_ostream&lt;charT,traits&gt;* tie() const;
1992 </pre>
1993
1994 <p>and replace</p>
1995 <pre>  basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
1996 </pre>
1997 <p>with</p>
1998 <pre>  basic_streambuf&lt;charT,traits&gt;* rdbuf();
1999   const basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
2000 </pre>
2001
2002 <p>In 27.5.2 and 27.5.2.3.1</p>
2003 <p>Replace</p>
2004 <pre>  char_type* eback() const;
2005 </pre>
2006 <p>with</p>
2007 <pre>  char_type* eback();
2008   const char_type* eback() const;
2009 </pre>
2010
2011 <p>Replace</p>
2012 <pre>  char_type gptr() const;
2013 </pre>
2014 <p>with</p>
2015 <pre>  char_type* gptr();
2016   const char_type* gptr() const;
2017 </pre>
2018
2019 <p>Replace</p>
2020 <pre>  char_type* egptr() const;
2021 </pre>
2022 <p>with</p>
2023 <pre>  char_type* egptr();
2024   const char_type* egptr() const;
2025 </pre>
2026
2027 <p>In 27.5.2 and 27.5.2.3.2</p>
2028 <p>Replace</p>
2029 <pre>  char_type* pbase() const;
2030 </pre>
2031 <p>with</p>
2032 <pre>  char_type* pbase();
2033   const char_type* pbase() const;
2034 </pre>
2035
2036 <p>Replace</p>
2037 <pre>  char_type* pptr() const;
2038 </pre>
2039 <p>with</p>
2040 <pre>  char_type* pptr();
2041   const char_type* pptr() const;
2042 </pre>
2043
2044 <p>Replace</p>
2045 <pre>  char_type* epptr() const;
2046 </pre>
2047 <p>with</p>
2048 <pre>  char_type* epptr();
2049   const char_type* epptr() const;
2050 </pre>
2051
2052 <p>In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6</p>
2053 <p>Replace</p>
2054 <pre>  basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
2055 </pre>
2056 <p>with</p>
2057 <pre>  basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf();
2058   const basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
2059 </pre>
2060
2061 <p>In  27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p>
2062 <p>Replace</p>
2063 <pre>  basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
2064 </pre>
2065 <p>with</p>
2066 <pre>  basic_filebuf&lt;charT,traits&gt;* rdbuf();
2067   const basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
2068 </pre>
2069 <hr>
2070 <a name="368"><h3>368.&nbsp;basic_string::replace has two "Throws" paragraphs</h3></a><p><b>Section:</b>&nbsp;21.3.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string::replace"> [lib.string::replace]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;3 Jun 2002</p>
2071 <p>
2072 21.3.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string::replace"> [lib.string::replace]</a> basic_string::replace, second
2073 signature, given in paragraph 1, has two "Throws" paragraphs (3 and
2074 5).
2075 </p>
2076
2077 <p>
2078 In addition, the second "Throws" paragraph (5) includes specification
2079 (beginning with "Otherwise, the function replaces ...") that should be
2080 part of the "Effects" paragraph.
2081 </p>
2082 <p><b>Proposed resolution:</b></p>
2083 <p><i>[This is a typo that escalated.  It's clear that what's in the
2084   Standard is wrong.  It's less clear what the fix ought to be.
2085   Someone who understands string replace well needs to work on
2086   this.]</i></p>
2087 <hr>
2088 <a name="369"><h3>369.&nbsp;io stream objects and static ctors</h3></a><p><b>Section:</b>&nbsp;27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Ruslan Abdikeev&nbsp; <b>Date:</b>&nbsp;8 Jul 2002</p>
2089 <p>
2090 Is it safe to use standard iostream objects from constructors of
2091 static objects?  Are standard iostream objects constructed and are
2092 their associations established at that time?
2093 </p>
2094
2095 <p>Surpisingly enough, Standard does NOT require that.</p>
2096
2097 <p>
2098 27.3/2 [lib.iostream.objects] guarantees that standard iostream
2099 objects are constructed and their associations are established before
2100 the body of main() begins execution.  It also refers to ios_base::Init
2101 class as the panacea for constructors of static objects.
2102 </p>
2103
2104 <p>
2105 However, there's nothing in 27.3 [lib.iostream.objects],
2106 in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
2107 that would require implementations to allow access to standard
2108 iostream objects from constructors of static objects.
2109 </p>
2110
2111 <p>Details:</p>
2112
2113 <p>Core text refers to some magic object ios_base::Init, which will
2114 be discussed below:</p>
2115
2116 <blockquote>
2117     "The [standard iostream] objects are constructed, and their
2118     associations are established at some time prior to or during
2119     first time an object of class basic_ios&lt;charT,traits&gt;::Init
2120     is constructed, and in any case before the body of main
2121     begins execution." (27.3/2 [lib.iostream.objects])
2122 </blockquote>
2123
2124 <p>
2125 The first <i>non-normative</i> footnote encourages implementations
2126 to initialize standard iostream objects earlier than required.
2127 </p>
2128
2129 <p>However, the second <i>non-normative</i> footnote makes an explicit
2130 and unsupported claim:</p>
2131
2132 <blockquote>
2133   "Constructors and destructors for static objects can access these
2134   [standard iostream] objects to read input from stdin or write output
2135   to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects])
2136 </blockquote>
2137
2138 <p>
2139 The only bit of magic is related to that ios_base::Init class.  AFAIK,
2140 the rationale behind ios_base::Init was to bring an instance of this
2141 class to each translation unit which #included &lt;iostream&gt; or
2142 related header.  Such an inclusion would support the claim of footnote
2143 quoted above, because in order to use some standard iostream object it
2144 is necessary to #include &lt;iostream&gt;.
2145 </p>
2146
2147 <p>
2148 However, while Standard explicitly describes ios_base::Init as
2149 an appropriate class for doing the trick, I failed to found a
2150 mention of an _instance_ of ios_base::Init in Standard.
2151 </p>
2152 <p><b>Proposed resolution:</b></p>
2153
2154 <p><i>[Redmond: This still isn't precise enough.  We need to give
2155   users some guarantees, i.e. "if you do X, then you are guaranteed
2156   that you will see behavior Y." We should guarantee that stream
2157   objects are constructed before a static constructor if (1)
2158   &lt;iostream&gt; is #included before the relevant static object; or
2159   (2) the user explicitly constructs an ios_base::Init object before
2160   calling that constuctor.]</i></p>
2161
2162 <p>Add to [lib.iostream.objects], p2, immediately before the last sentence
2163 of the paragraph, the following two sentences:</p>
2164 <blockquote>
2165 It is implementation-defined whether the header &lt;iostream&gt; defines
2166 an ios_base::Init object or not. If it does not, an implementation
2167 must specify the means of achieving safe access to the standard
2168 objects for input and output during program startup.
2169 </blockquote>
2170
2171 <p><i>[Santa Cruz: The LWG is leaning toward NAD.  There isn't any
2172 normative wording saying that the Init scheme will be used, but that
2173 is probably intentional.  Implementers use dirty tricks for iostream
2174 initialization, and doing it portably is somewhere between difficult
2175 and impossible.  Too much constraint in this area is dangerous, and if
2176 we are to make any changes it would probably be more appropriate
2177 for them to be nonnormative.  Summer '04 mid-meeting mailing: Martin
2178 provided wording for resolution and rationale.]</i></p>
2179 <p><b>Rationale:</b></p>
2180 <p>
2181 The original proposed resolution unconditionally required
2182 implementations to define an ios_base::Init object of some
2183 implementation-defined name in the header &lt;iostream&gt;. That's an
2184 overspecification. First, defining the object may be unnecessary
2185 and even detrimental to performance if an implementation can
2186 guarantee that the 8 standard iostream objects will be initialized
2187 before any other user-defined object in a program. Second, there
2188 is no need to require implementations to document the name of the
2189 object.</p>
2190
2191 <p>
2192 The new proposed resolution specifies that implementations may
2193 (but need not) define an ios_base::Init object, while requiring
2194 them to document whether they do or not, and if not, to document
2195 how portable programs achieve safe access to the 8 standard iostream
2196 objects during program startup (3.6)(*). The intent is that if an
2197 implementation documents that &lt;iostream&gt; defines an ios_base::Init
2198 object, it implies that the header must be #included before any
2199 references to the standard iostream objects. Otherwise, if an
2200 implementation does not define an ios_base::Init object in
2201 &lt;iostream&gt; it must either assure and document that the standard
2202 iostream objects are safely accessible at startup, or specify what
2203 a portable program must do to safely access them (e.g., it may
2204 require that a program define an ios_base::Init object before
2205 doing so, or that it call ios::sync_with_stdio(), etc.).
2206 </p>
2207
2208 <p>
2209 (*) Note that the term startup is broader than the term "Constructors
2210 and destructors for static objects" used in Footnote 265 since the
2211 former includes other functions besides constructors and destructors,
2212 including the following example:
2213 </p>
2214 <pre>    int foo () { return (std::cout &lt;&lt; "foo()\n").rdstate (); }
2215     int i = foo ();
2216     int main () { return i; }
2217 </pre>
2218 <hr>
2219 <a name="371"><h3>371.&nbsp;Stability of multiset and multimap member functions</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Frank Compagner&nbsp; <b>Date:</b>&nbsp;20 Jul 2002</p>
2220 <p>
2221 The requirements for multiset and multimap containers (23.1
2222 [lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
2223 23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
2224 the stability of the required (mutating) member functions. It appears
2225 the standard allows these functions to reorder equivalent elements of
2226 the container at will, yet the pervasive red-black tree implementation
2227 appears to provide stable behaviour.
2228 </p>
2229
2230 <p>This is of most concern when considering the behaviour of erase().
2231 A stability requirement would guarantee the correct working of the
2232 following 'idiom' that removes elements based on a certain predicate
2233 function.
2234 </p>
2235
2236 <pre>  multimap&lt;int, int&gt; m;
2237   multimap&lt;int, int&gt;::iterator i = m.begin();
2238   while (i != m.end()) {
2239       if (pred(i))
2240           m.erase (i++);
2241       else
2242           ++i;
2243   }
2244 </pre>
2245
2246 <p>
2247 Although clause 23.1.2/8 guarantees that i remains a valid iterator
2248 througout this loop, absence of the stability requirement could
2249 potentially result in elements being skipped. This would make
2250 this code incorrect, and, furthermore, means that there is no way
2251 of erasing these elements without iterating first over the entire
2252 container, and second over the elements to be erased. This would
2253 be unfortunate, and have a negative impact on both performance and
2254 code simplicity.
2255 </p>
2256
2257 <p>
2258 If the stability requirement is intended, it should be made explicit
2259 (probably through an extra paragraph in clause 23.1.2).
2260 </p>
2261 <p>
2262 If it turns out stability cannot be guaranteed, i'd argue that a
2263 remark or footnote is called for (also somewhere in clause 23.1.2) to
2264 warn against relying on stable behaviour (as demonstrated by the code
2265 above).  If most implementations will display stable behaviour, any
2266 problems emerging on an implementation without stable behaviour will
2267 be hard to track down by users. This would also make the need for an
2268 erase_if() member function that much greater.
2269 </p>
2270
2271 <p>This issue is somewhat related to LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#130">130</a>.</p>
2272
2273 <p><i>[Santa Cruz: More people need to look at this.  Much user code
2274   may assume stability.  On the other hand, it seems drastic to add a
2275   new requirement now.]</i></p>
2276
2277 <p><b>Proposed resolution:</b></p>
2278 <hr>
2279 <a name="376"><h3>376.&nbsp;basic_streambuf semantics</h3></a><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
2280 <p>
2281 In Section 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, Table 90, the implication is that
2282 the four conditions should be mutually exclusive, but they are not.
2283 The first two cases, as written, are subcases of the third. I think it
2284 would be clearer if the conditions were rewritten as follows:
2285 </p>
2286
2287 <blockquote>
2288 <p>
2289   (which &amp; (ios_base::in|ios_base::out)) == ios_base::in
2290 </p>
2291
2292 <p>
2293   (which &amp; (ios_base::in|ios_base::out)) == ios_base::out
2294 </p>
2295
2296 <p>
2297   (which &amp; (ios_base::in|ios_base::out)) ==
2298 (ios_base::in|ios_base::out)
2299    and way == either ios_base::beg or ios_base::end
2300 </p>
2301
2302 <p>Otherwise</p>
2303 </blockquote>
2304
2305 <p>
2306 As written, it is unclear what should be the result if cases 1 &amp; 2
2307 are true, but case 3 is false, e.g.,
2308 </p>
2309
2310 <blockquote>
2311   seekoff(0, ios_base::cur, ios_base::in | ios_base::out)
2312 </blockquote>
2313
2314 <p><i>[Santa Cruz: The ambiguity seems real.  We need to do a survey of
2315 implementations before we decide on a solution.]</i></p>
2316
2317 <p><b>Proposed resolution:</b></p>
2318 <hr>
2319 <a name="382"><h3>382.&nbsp;codecvt do_in/out result</h3></a><p><b>Section:</b>&nbsp;22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;30 Aug  2002</p>
2320 <p>
2321 It seems that the descriptions of codecvt do_in() and do_out() leave
2322 sufficient room for interpretation so that two implementations of
2323 codecvt may not work correctly with the same filebuf. Specifically,
2324 the following seems less than adequately specified:
2325 </p>
2326
2327 <ol>
2328 <li>
2329   the conditions under which the functions terminate
2330 </li>
2331 <li>
2332   precisely when the functions return ok
2333 </li>
2334 <li>
2335   precisely when the functions return partial
2336 </li>
2337 <li>
2338   the full set of conditions when the functions return error
2339 </li>
2340 </ol>
2341
2342 <ol>
2343 <li>
2344    22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p2 says this about the effects of the
2345    function: ...Stops if it encounters a character it cannot
2346    convert...  This assumes that there *is* a character to
2347    convert. What happens when there is a sequence that doesn't form a
2348    valid source character, such as an unassigned or invalid UNICODE
2349    character, or a sequence that cannot possibly form a character
2350    (e.g., the sequence "\xc0\xff" in UTF-8)?
2351 </li>
2352 <li>
2353    Table 53 says that the function returns codecvt_base::ok
2354    to indicate that the function(s) "completed the conversion."
2355    Suppose that the source sequence is "\xc0\x80" in UTF-8,
2356    with from pointing to '\xc0' and (from_end==from + 1).
2357    It is not clear whether the return value should be ok
2358    or partial (see below).
2359 </li>
2360 <li>
2361    Table 53 says that the function returns codecvt_base::partial
2362    if "not all source characters converted." With the from pointers
2363    set up the same way as above, it is not clear whether the return
2364    value should be partial or ok (see above).
2365 </li>
2366 <li>
2367    Table 53, in the row describing the meaning of error mistakenly
2368    refers to a "from_type" character, without the symbol from_type
2369    having been defined. Most likely, the word "source" character
2370    is intended, although that is not sufficient. The functions
2371    may also fail when they encounter an invalid source sequence
2372    that cannot possibly form a valid source character (e.g., as
2373    explained in bullet 1 above).
2374 </li>
2375 </ol>
2376 <p>
2377 Finally, the conditions described at the end of 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p4 don't seem to be possible:
2378 </p>
2379 <blockquote>
2380     "A return value of partial, if (from_next == from_end),
2381     indicates that either the destination sequence has not
2382     absorbed all the available destination elements, or that
2383     additional source elements are needed before another
2384     destination element can be produced."
2385 </blockquote>
2386 <p>
2387 If the value is partial, it's not clear to me that (from_next
2388 ==from_end) could ever hold if there isn't enough room
2389 in the destination buffer. In order for (from_next==from_end) to
2390 hold, all characters in that range must have been successfully
2391 converted (according to 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p2) and since there are no
2392 further source characters to convert, no more room in the
2393 destination buffer can be needed.
2394 </p>
2395 <p>
2396 It's also not clear to me that (from_next==from_end) could ever
2397 hold if additional source elements are needed to produce another
2398 destination character (not element as incorrectly stated in the
2399 text). partial is returned if "not all source characters have
2400 been converted" according to Table 53, which also implies that
2401 (from_next==from) does NOT hold.
2402 </p>
2403 <p>
2404 Could it be that the intended qualifying condition was actually
2405 (from_next != from_end), i.e., that the sentence was supposed
2406 to read
2407 </p>
2408 <blockquote>
2409     "A return value of partial, if (from_next != from_end),..."
2410 </blockquote>
2411 <p>
2412 which would make perfect sense, since, as far as I understand it,
2413 partial can only occur if (from_next != from_end)?
2414 </p>
2415 <p><b>Proposed resolution:</b></p>
2416 <p>
2417 To address these issues, I propose that paragraphs 2, 3, and 4
2418 be rewritten as follows. The proposal incorporates the accepted
2419 resolution of lwg issue 19.
2420 </p>
2421 <pre>-2- Effects: Converts characters in the range of source elements
2422     [from, from_end), placing the results in sequential positions
2423     starting at destination to. Converts no more than (from_end  from)
2424     source elements, and stores no more than (to_limit  to)
2425     destination elements.
2426
2427     Stops if it encounters a sequence of source elements it cannot
2428     convert to a valid destination character. It always leaves the
2429     from_next and to_next pointers pointing one beyond the last
2430     element successfully converted.
2431
2432     [Note: If returns noconv, internT and externT are the same type
2433     and the converted sequence is identical to the input sequence
2434     [from, from_next). to_next is set equal to to, the value of
2435     state is unchanged, and there are no changes to the values in
2436     [to, to_limit). --end note]
2437
2438 -3- Notes: Its operations on state are unspecified.
2439     [Note: This argument can be used, for example, to maintain shift
2440     state, to specify conversion options (such as count only), or to
2441     identify a cache of seek offsets. --end note]
2442
2443 -4- Returns: An enumeration value, as summarized in Table 53:
2444
2445     Table 53 -- do_in/do_out result values
2446
2447      Value      Meaning
2448     +---------+----------------------------------------------------+
2449     | ok      | successfully completed the conversion of all       |
2450     |         | complete characters in the source range            |
2451     +---------+----------------------------------------------------+
2452     | partial | the characters in the source range would, after    |
2453     |         | conversion, require space greater than that        |
2454     |         | available in the destination range                 |
2455     +---------+----------------------------------------------------+
2456     | error   | encountered either a sequence of elements in the   |
2457     |         | source range forming a valid source character that |
2458     |         | could not be converted to a destination character, |
2459     |         | or a sequence of elements in the source range that |
2460     |         | could not possibly form a valid source character   |
2461     +---------+----------------------------------------------------+
2462     | noconv  | internT and externT are the same type, and input   |
2463     |         | sequence is identical to converted sequence        |
2464     +---------+----------------------------------------------------+
2465
2466     A return value of partial, i.e., if (from_next != from_end),
2467     indicates that either the destination sequence has not absorbed
2468     all the available destination elements, or that additional
2469     source elements are needed before another destination character
2470     can be produced.
2471 </pre>
2472
2473 <p><i>[Santa Cruz: The LWG agrees that this is an important issue and
2474 that this general direction is probably correct.  Dietmar, Howard,
2475 PJP, and Matt will review this wording.]</i></p>
2476
2477 <p><i>[Kona: this isn't quite right.  (a) the description of noconv is
2478 too vague, both in the existing standard and in the current proposed
2479 resolution; (b) the description of what noconv means should be
2480 normative; (c) the phrase "partial, i.e. if from_next != from_end"
2481 isn't quite right, because those are two separate cases, it's possible
2482 to get partial either form insufficient input or from insufficient
2483 space in the output buffer.  The big problem is that the standard is
2484 written with the assumption of 1-&gt;N conversion in mind, not M-&gt;N.
2485 Bill, Howard, and Martin will provide new wording.
2486 ]</i></p>
2487 <hr>
2488 <a name="384"><h3>384.&nbsp;equal_range has unimplementable runtime complexity</h3></a><p><b>Section:</b>&nbsp;25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Bos&nbsp; <b>Date:</b>&nbsp;18 Oct 2002</p>
2489 <p>
2490 Section 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>
2491 states that at most 2 * log(last - first) + 1
2492 comparisons are allowed for equal_range.
2493 </p>
2494
2495 <p>It is not possible to implement equal_range with these constraints.</p>
2496
2497 <p>In a range of one element as in:</p>
2498 <pre>    int x = 1;
2499     equal_range(&amp;x, &amp;x + 1, 1)
2500 </pre>
2501
2502 <p>it is easy to see that at least 2 comparison operations are needed.</p>
2503
2504 <p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p>
2505
2506 <p>I have checked a few libraries and they all use the same (nonconforming)
2507 algorithm for equal_range that has a complexity of</p>
2508 <pre>     2* log(distance(first, last)) + 2.
2509 </pre>
2510 <p>I guess this is the algorithm that the standard assumes for equal_range.</p>
2511
2512 <p>
2513 It is easy to see that 2 * log(distance) + 2 comparisons are enough
2514 since equal range can be implemented with lower_bound and upper_bound
2515 (both log(distance) + 1).
2516 </p>
2517
2518 <p>
2519 I think it is better to require something like 2log(distance) + O(1)  (or
2520 even logarithmic as multiset::equal_range).
2521 Then an implementation has more room to optimize for certain cases (e.g.
2522 have log(distance) characteristics when at most match is found in the range
2523 but 2log(distance) + 4 for the worst case).
2524 </p>
2525
2526 <p><i>[Santa Cruz: The issue is real, but of greater scope than just
2527 equal_range: it affects all of the binary search algorithms.  What is
2528 the complexity supposed to be for ranges of 0 or 1 elements?  What
2529 base are we using for the logarithm?  Are these bounds supposed to be
2530 exact, or asymptotic?  (If the latter, of course, then none of the
2531 other questions matter.)]</i></p>
2532
2533 <p><b>Proposed resolution:</b></p>
2534 <hr>
2535 <a name="385"><h3>385.&nbsp;Does call by value imply the CopyConstructible requirement?</h3></a><p><b>Section:</b>&nbsp;17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Oct 2002</p>
2536 <p>
2537 Many function templates have parameters that are passed by value;
2538 a typical example is <tt>find_if</tt>'s <i>pred</i> parameter in
2539 25.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a>.  Are the corresponding template parameters
2540 (<tt>Predicate</tt> in this case) implicitly required to be
2541 CopyConstructible, or does that need to be spelled out explicitly?
2542 </p>
2543
2544 <p>
2545 This isn't quite as silly a question as it might seem to be at first
2546 sight.  If you call <tt>find_if</tt> in such a way that template
2547 argument deduction applies, then of course you'll get call by value
2548 and you need to provide a copy constructor.  If you explicitly provide
2549 the template arguments, however, you can force call by reference by
2550 writing something like <tt>find_if&lt;my_iterator,
2551 my_predicate&amp;&gt;</tt>.  The question is whether implementation
2552 are required to accept this, or whether this is ill-formed because
2553 my_predicate&amp; is not CopyConstructible.
2554 </p>
2555
2556 <p>
2557 The scope of this problem, if it is a problem, is unknown.  Function
2558 object arguments to generic algorithms in clauses 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>
2559 and 26 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.numerics"> [lib.numerics]</a> are obvious examples.  A review of the whole
2560 library is necessary.
2561 </p>
2562 <p><b>Proposed resolution:</b></p>
2563 <p><i>[
2564 This is really two issues.  First, predicates are typically passed by
2565 value but we don't say they must be Copy Constructible.  They should
2566 be. Second: is specialization allowed to transform value arguments
2567 into references? References aren't copy constructible, so this should
2568 not be allowed.
2569 ]</i></p>
2570 <hr>
2571 <a name="386"></a><h3><a name="386">386.&nbsp;Reverse iterator's operator[] has impossible return type</a></h3><p><b>Section:</b>&nbsp;24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Oct 2002</p>
2572 <p>In 24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a>, <tt>reverse_iterator&lt;&gt;::operator[]</tt>
2573 is specified as having a return type of <tt>reverse_iterator::reference</tt>,
2574 which is the same as <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.
2575 (Where <tt>Iterator</tt> is the underlying iterator type.)</p>
2576
2577 <p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't
2578   necessarily have a return type
2579   of <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.   Its
2580   return type is merely required to be convertible
2581   to <tt>Iterator</tt>'s value type.  The return type specified for
2582   reverse_iterator's operator[] would thus appear to be impossible.</p>
2583
2584 <p>With the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#299">299</a>, the type of
2585   <tt>a[n]</tt> will continue to be required (for random access
2586   iterators) to be convertible to the value type, and also <tt>a[n] =
2587   t</tt> will be a valid expression.  Implementations of
2588   <tt>reverse_iterator</tt> will likely need to return a proxy from
2589   <tt>operator[]</tt> to meet these requirements. As mentioned in the
2590   comment from Dave Abrahams, the simplest way to specify that
2591   <tt>reverse_iterator</tt> meet this requirement to just mandate
2592   it and leave the return type of <tt>operator[]</tt> unspecified.</p>
2593
2594 <p><b>Proposed resolution:</b></p>
2595
2596 <p>In 24.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.reverse.iter.requirements"> [lib.reverse.iter.requirements]</a> change:</p>
2597
2598 <blockquote>
2599 <pre>reference operator[](difference_type n) const;
2600 </pre>
2601 </blockquote>
2602
2603 <p>to:</p>
2604
2605 <blockquote>
2606 <pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see <font color="red">lib.random.access.iterators</font>
2607 </pre>
2608 </blockquote>
2609
2610
2611
2612
2613 <p><i>[
2614 Comments from Dave Abrahams: IMO we should resolve 386 by just saying
2615     that the return type of reverse_iterator's operator[] is
2616     unspecified, allowing the random access iterator requirements to
2617     impose an appropriate return type.  If we accept 299's proposed
2618     resolution (and I think we should), the return type will be
2619     readable and writable, which is about as good as we can do.
2620 ]</i></p>
2621 <hr>
2622 <a name="387"><h3>387.&nbsp;std::complex over-encapsulated</h3></a><p><b>Section:</b>&nbsp;26.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Gabriel Dos Reis&nbsp; <b>Date:</b>&nbsp;8 Nov 2002</p>
2623 <p>
2624 The absence of explicit description of std::complex&lt;T&gt; layout
2625 makes it imposible to reuse existing software developed in traditional
2626 languages like Fortran or C with unambigous and commonly accepted
2627 layout assumptions.  There ought to be a way for practitioners to
2628 predict with confidence the layout of std::complex&lt;T&gt; whenever T
2629 is a numerical datatype.  The absence of ways to access individual
2630 parts of a std::complex&lt;T&gt; object as lvalues unduly promotes
2631 severe pessimizations. For example, the only way to change,
2632 independently, the real and imaginary parts is to write something like
2633 </p>
2634
2635 <pre>complex&lt;T&gt; z;
2636 // ...
2637 // set the real part to r
2638 z = complex&lt;T&gt;(r, z.imag());
2639 // ...
2640 // set the imaginary part to i
2641 z = complex&lt;T&gt;(z.real(), i);
2642 </pre>
2643
2644 <p>
2645 At this point, it seems appropriate to recall that a complex number
2646 is, in effect, just a pair of numbers with no particular invariant to
2647 maintain.  Existing practice in numerical computations has it that a
2648 complex number datatype is usually represented by Cartesian
2649 coordinates. Therefore the over-encapsulation put in the specification
2650 of std::complex&lt;&gt; is not justified.
2651 </p>
2652
2653 <p><b>Proposed resolution:</b></p>
2654 <p>Add the following requirements to 26.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a> as 26.2/4:</p>
2655 <blockquote>
2656 <p>If z is an lvalue expression of type cv std::complex&lt;T&gt; then</p>
2657
2658 <ul>
2659 <li>the expression reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)
2660 is well-formed; and</li>
2661 <li>reinterpret_cast&lt;cvT(&amp;)[2]&gt;(z)[0]designates the
2662 real part of z; and</li>
2663 <li>reinterpret_cast&lt;cvT(&amp;)[2]&gt;(z)[1]designates the
2664 imaginary part of z.</li>
2665 </ul>
2666
2667 <p>
2668 Moreover, if a is an expression of pointer type cv complex&lt;T&gt;*
2669 and the expression a[i] is well-defined for an integer expression
2670 i then:
2671 </p>
2672
2673 <ul>
2674 <li>reinterpret_cast&lt;cvT*&gt;(a)[2+i] designates the real
2675 part of a[i]; and</li>
2676 <li>reinterpret_cast&lt;cv T*&gt;(a)[2+i+1] designates the
2677 imaginary part of a[i].</li>
2678 </ul>
2679 </blockquote>
2680
2681 <p>In the header synopsis in 26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, replace</p>
2682 <pre>  template&lt;class T&gt; T real(const complex&lt;T&gt;&amp;);
2683   template&lt;class T&gt; T imag(const complex&lt;T&gt;&amp;);
2684 </pre>
2685
2686 <p>with</p>
2687
2688 <pre>  template&lt;class T&gt; const T&amp; real(const complex&lt;T&gt;&amp;);
2689   template&lt;class T&gt;       T&amp; real(      complex&lt;T&gt;&amp;);
2690   template&lt;class T&gt; const T&amp; imag(const complex&lt;T&gt;&amp;);
2691   template&lt;class T&gt;       T&amp; imag(      complex&lt;T&gt;&amp;);
2692 </pre>
2693
2694 <p>In 26.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> paragraph 1, change</p>
2695 <pre>  template&lt;class T&gt; T real(const complex&lt;T&gt;&amp;);
2696 </pre>
2697 <p>to</p>
2698 <pre>  template&lt;class T&gt; const T&amp; real(const complex&lt;T&gt;&amp;);
2699   template&lt;class T&gt;       T&amp; real(      complex&lt;T&gt;&amp;);
2700 </pre>
2701 <p>and change the <b>Returns</b> clause to "<b>Returns:</b> The real
2702 part of <i>x</i></p>.
2703
2704 <p>In 26.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> paragraph 2, change</p>
2705 <pre>  template&lt;class T&gt; T imag(const complex&lt;T&gt;&amp;);
2706 </pre>
2707 <p>to</p>
2708 <pre>  template&lt;class T&gt; const T&amp; imag(const complex&lt;T&gt;&amp;);
2709   template&lt;class T&gt;       T&amp; imag(      complex&lt;T&gt;&amp;);
2710 </pre>
2711 <p>and change the <b>Returns</b> clause to "<b>Returns:</b> The imaginary
2712 part of <i>x</i></p>.
2713
2714 <p><i>[Kona: The layout guarantee is absolutely necessary for C
2715   compatibility.  However, there was disagreement about the other part
2716   of this proposal: retrieving elements of the complex number as
2717   lvalues.  An alternative: continue to have real() and imag() return
2718   rvalues, but add set_real() and set_imag().  Straw poll: return
2719   lvalues - 2, add setter functions - 5.  Related issue: do we want
2720   reinterpret_cast as the interface for converting a complex to an
2721   array of two reals, or do we want to provide a more explicit way of
2722   doing it?  Howard will try to resolve this issue for the next
2723   meeting.]</i></p>
2724
2725 <p><i>[pre-Sydney: Howard summarized the options in n1589.]</i></p>
2726
2727 <p><b>Rationale:</b></p>
2728 <p>The LWG believes that C99 compatibility would be enough
2729 justification for this change even without other considerations.  All
2730 existing implementations already have the layout proposed here.</p>
2731 <hr>
2732 <a name="394"><h3>394.&nbsp;behavior of formatted output on failure</h3></a><p><b>Section:</b>&nbsp;27.6.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Dec 2002</p>
2733 <p>
2734 There is a contradiction in Formatted output about what bit is
2735 supposed to be set if the formatting fails. On sentence says it's
2736 badbit and another that it's failbit.
2737 </p>
2738 <p>
2739 27.6.2.5.1, p1 says in the Common Requirements on Formatted output
2740 functions:
2741 </p><pre>     ... If the generation fails, then the formatted output function
2742      does setstate(ios::failbit), which might throw an exception.
2743 </pre>
2744 <p></p>
2745 <p>
2746 27.6.2.5.2, p1 goes on to say this about Arithmetic Inserters:
2747 </p>
2748 <p>
2749      ... The formatting conversion occurs as if it performed the
2750      following code fragment:
2751 </p>
2752 <p>
2753 </p><pre>     bool failed =
2754          use_facet&lt;num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt;
2755          &gt; &gt;
2756          (getloc()).put(*this, *this, fill(), val). failed();
2757
2758      ... If failed is true then does setstate(badbit) ...
2759 </pre>
2760 <p></p>
2761 <p>
2762 The original intent of the text, according to Jerry Schwarz (see
2763 c++std-lib-10500), is captured in the following paragraph:
2764 </p>
2765 <p>
2766 In general "badbit" should mean that the stream is unusable because
2767 of some underlying failure, such as disk full or socket closure;
2768 "failbit" should mean that the requested formatting wasn't possible
2769 because of some inconsistency such as negative widths.  So typically
2770 if you clear badbit and try to output something else you'll fail
2771 again, but if you clear failbit and try to output something else
2772 you'll succeed.
2773 </p>
2774 <p>
2775 In the case of the arithmetic inserters, since num_put cannot
2776 report failure by any means other than exceptions (in response
2777 to which the stream must set badbit, which prevents the kind of
2778 recoverable error reporting mentioned above), the only other
2779 detectable failure is if the iterator returned from num_put
2780 returns true from failed().
2781 </p>
2782 <p>
2783 Since that can only happen (at least with the required iostream
2784 specializations) under such conditions as the underlying failure
2785 referred to above (e.g., disk full), setting badbit would seem
2786 to be the appropriate response (indeed, it is required in
2787 27.6.2.5.2, p1). It follows that failbit can never be directly
2788 set by the arithmetic (it can only be set by the sentry object
2789 under some unspecified conditions).
2790 </p>
2791 <p>
2792 The situation is different for other formatted output functions
2793 which can fail as a result of the streambuf functions failing
2794 (they may do so by means other than exceptions), and which are
2795 then required to set failbit.
2796 </p>
2797 <p>
2798 The contradiction, then, is that ostream::operator&lt;&lt;(int) will
2799 set badbit if the disk is full, while operator&lt;&lt;(ostream&amp;,
2800 char) will set failbit under the same conditions. To make the behavior
2801 consistent, the Common requirements sections for the Formatted output
2802 functions should be changed as proposed below.
2803 </p>
2804 <p><b>Proposed resolution:</b></p>
2805
2806
2807 <p><i>[Kona: There's agreement that this is a real issue.  What we
2808   decided at Kona: 1. An error from the buffer (which can be detected
2809   either directly from streambuf's member functions or by examining a
2810   streambuf_iterator) should always result in badbit getting set.
2811   2. There should never be a circumstance where failbit gets set.
2812   That represents a formatting error, and there are no circumstances
2813   under which the output facets are specified as signaling a
2814   formatting error. (Even more so for string output that for numeric
2815   because there's nothing to format.)  If we ever decide to make it
2816   possible for formatting errors to exist then the facets can signal
2817   the error directly, and that should go in clause 22, not clause 27.
2818   3. The phrase "if generation fails" is unclear and should be
2819   eliminated.  It's not clear whether it's intended to mean a buffer
2820   error (e.g. a full disk), a formatting error, or something else.
2821   Most people thought it was supposed to refer to buffer errors; if
2822   so, we should say so.  Martin will provide wording.]</i></p>
2823
2824 <p><b>Rationale:</b></p>
2825
2826 <hr>
2827 <a name="396"></a><h3><a name="396">396.&nbsp;what are characters zero and one</a></h3><p><b>Section:</b>&nbsp;23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Jan 2003</p>
2828     <p>
2829 23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
2830 having the value of 0 or 1 but there is no definition of what
2831 that means for charT other than char and wchar_t. And even for
2832 those two types, the values 0 and 1 are not actually what is
2833 intended -- the values '0' and '1' are. This, along with the
2834 converse problem in the description of to_string() in 23.3.5.2,
2835 p33, looks like a defect remotely related to DR 303.
2836     </p>
2837     <p>
2838 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
2839     </p>
2840     <pre>23.3.5.1:
2841   -6-  An element of the constructed string has value zero if the
2842        corresponding character in str, beginning at position pos,
2843        is 0. Otherwise, the element has the value one.
2844     </pre>
2845     <pre>23.3.5.2:
2846   -33-  Effects: Constructs a string object of the appropriate
2847         type and initializes it to a string of length N characters.
2848         Each character is determined by the value of its
2849         corresponding bit position in *this. Character position N
2850         ?- 1 corresponds to bit position zero. Subsequent decreasing
2851         character positions correspond to increasing bit positions.
2852         Bit value zero becomes the character 0, bit value one becomes
2853         the character 1.
2854     </pre>
2855     <p>
2856 Also note the typo in 23.3.5.1, p6: the object under construction
2857 is a bitset, not a string.
2858     </p>
2859   <p><b>Proposed resolution:</b></p>
2860 <p>Change the constructor's function declaration immediately before
2861 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> p3 to:</p>
2862 <pre>    template &lt;class charT, class traits, class Allocator&gt;
2863     explicit
2864     bitset(const basic_string&lt;charT, traits, Allocator&gt;&amp; str,
2865            typename basic_string&lt;charT, traits, Allocator&gt;::size_type pos = 0,
2866            typename basic_string&lt;charT, traits, Allocator&gt;::size_type n =
2867              basic_string&lt;charT, traits, Allocator&gt;::npos,
2868            charT zero = charT('0'), charT one = charT('1'))
2869 </pre>
2870 <p>Change the first two sentences of 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> p6 to: "An
2871 element of the constructed string has value 0 if the corresponding
2872 character in <i>str</i>, beginning at position <i>pos</i>,
2873 is <i>zero</i>. Otherwise, the element has the value 1.</p>
2874
2875 <p>Change the text of the second sentence in 23.3.5.1, p5 to read:
2876     "The function then throws invalid_argument if any of the rlen
2877     characters in str beginning at position pos is other than <i>zero</i>
2878     or <i>one</i>. The function uses traits::eq() to compare the character
2879     values."
2880 </p>
2881
2882 <p>Change the declaration of the <tt>to_string</tt> member function
2883   immediately before 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> p33 to:</p>
2884 <pre>    template &lt;class charT, class traits, class Allocator&gt;
2885     basic_string&lt;charT, traits, Allocator&gt;
2886     to_string(charT zero = charT('0'), charT one = charT('1')) const;
2887 </pre>
2888 <p>Change the last sentence of 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> p33 to: "Bit
2889   value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the
2890   character <tt><i>one</i></tt>.</p>
2891 <p>Change 23.3.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.bitset.operators"> [lib.bitset.operators]</a> p8 to:</p>
2892 <p><b>Returns</b>:</p>
2893 <pre>  os &lt;&lt; x.template to_string&lt;charT,traits,allocator&lt;charT&gt; &gt;(
2894       use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('0'),
2895       use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('1'));
2896 </pre>
2897 <p><b>Rationale:</b></p>
2898 <p>There is a real problem here: we need the character values of '0'
2899   and '1', and we have no way to get them since strings don't have
2900   imbued locales. In principle the "right" solution would be to
2901   provide an extra object, either a ctype facet or a full locale,
2902   which would be used to widen '0' and '1'. However, there was some
2903   discomfort about using such a heavyweight mechanism.  The proposed
2904   resolution allows those users who care about this issue to get it
2905   right.</p>
2906 <p>We fix the inserter to use the new arguments.  Note that we already
2907   fixed the analogous problem with the extractor in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#303">303</a>.</p>
2908
2909 <hr>
2910 <a name="397"><h3>397.&nbsp;ostream::sentry dtor throws exceptions</h3></a><p><b>Section:</b>&nbsp;27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Jan 2003</p>
2911     <p>
2912 17.4.4.8, p3 prohibits library dtors from throwing exceptions.
2913     </p>
2914     <p>
2915 27.6.2.3, p4 says this about the ostream::sentry dtor:
2916     </p>
2917     <pre>    -4- If ((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception())
2918         is true, calls os.flush().
2919     </pre>
2920     <p>
2921 27.6.2.6, p7 that describes ostream::flush() says:
2922     </p>
2923     <pre>    -7- If rdbuf() is not a null pointer, calls rdbuf()-&gt;pubsync().
2924         If that function returns ?-1 calls setstate(badbit) (which
2925         may throw ios_base::failure (27.4.4.3)).
2926     </pre>
2927     <p>
2928 That seems like a defect, since both pubsync() and setstate() can
2929 throw an exception.
2930     </p>
2931   <p><b>Proposed resolution:</b></p>
2932 <p><i>[
2933 The contradiction is real.  Clause 17 says destructors may never
2934 throw exceptions, and clause 27 specifies a destructor that does
2935 throw.  In principle we might change either one.  We're leaning
2936 toward changing clause 17: putting in an "unless otherwise specified"
2937 clause, and then putting in a footnote saying the sentry destructor
2938 is the only one that can throw.  PJP suggests specifying that
2939 sentry::~sentry() should internally catch any exceptions it might cause.
2940 ]</i></p>
2941 <hr>
2942 <a name="398"><h3>398.&nbsp;effects of end-of-file on unformatted input functions</h3></a><p><b>Section:</b>&nbsp;27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Jan 2003</p>
2943     <p>
2944 While reviewing unformatted input member functions of istream
2945 for their behavior when they encounter end-of-file during input
2946 I found that the requirements vary, sometimes unexpectedly, and
2947 in more than one case even contradict established practice (GNU
2948 libstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC
2949 5.38, Rogue Wave libstd 3.1, and Classic Iostreams).
2950     </p>
2951     <p>
2952 The following unformatted input member functions set eofbit if they
2953 encounter an end-of-file (this is the expected behavior, and also
2954 the behavior of all major implementations):
2955     </p>
2956     <p>
2957     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
2958     get (char_type*, streamsize, char_type);
2959     </pre>
2960     <p></p>
2961     <p>
2962     Also sets failbit if it fails to extract any characters.
2963     </p>
2964     <p>
2965     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
2966     get (char_type*, streamsize);
2967     </pre>
2968     <p></p>
2969     <p>
2970     Also sets failbit if it fails to extract any characters.
2971     </p>
2972     <p>
2973     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
2974     getline (char_type*, streamsize, char_type);
2975     </pre>
2976     <p></p>
2977     <p>
2978     Also sets failbit if it fails to extract any characters.
2979     </p>
2980     <p>
2981     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
2982     getline (char_type*, streamsize);
2983     </pre>
2984     <p></p>
2985     <p>
2986     Also sets failbit if it fails to extract any characters.
2987     </p>
2988     <p>
2989     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
2990     ignore (int, int_type);
2991     </pre>
2992     <p></p>
2993     <p>
2994     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
2995     read (char_type*, streamsize);
2996     </pre>
2997     <p></p>
2998     <p>
2999     Also sets failbit if it encounters end-of-file.
3000     </p>
3001     <p>
3002     </p><pre>    streamsize readsome (char_type*, streamsize);
3003     </pre>
3004     <p></p>
3005
3006     <p>
3007 The following unformated input member functions set failbit but
3008 not eofbit if they encounter an end-of-file (I find this odd
3009 since the functions make it impossible to distinguish a general
3010 failure from a failure due to end-of-file; the requirement is
3011 also in conflict with all major implementation which set both
3012 eofbit and failbit):
3013     </p>
3014     <p>
3015     </p><pre>    int_type get();
3016     </pre>
3017     <p></p>
3018     <p>
3019     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
3020     get (char_type&amp;);
3021     </pre>
3022     <p></p>
3023     <p>
3024 These functions only set failbit of they extract no characters,
3025 otherwise they don't set any bits, even on failure (I find this
3026 inconsistency quite unexpected; the requirement is also in
3027 conflict with all major implementations which set eofbit
3028 whenever they encounter end-of-file):
3029     </p>
3030     <p>
3031     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
3032     get (basic_streambuf&lt;charT, traits&gt;&amp;, char_type);
3033     </pre>
3034     <p></p>
3035     <p>
3036     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
3037     get (basic_streambuf&lt;charT, traits&gt;&amp;);
3038     </pre>
3039     <p></p>
3040     <p>
3041 This function sets no bits (all implementations except for
3042 STLport and Classic Iostreams set eofbit when they encounter
3043 end-of-file):
3044     </p>
3045     <p>
3046     </p><pre>    int_type peek ();
3047     </pre>
3048     <p></p>
3049   <p><b>Proposed resolution:</b></p>
3050 <p>Informally, what we want is a global statement of intent saying
3051   that eofbit gets set if we trip across EOF, and then we can take
3052   away the specific wording for individual functions.  A full review
3053   is necessary.  The wording currently in the standard is a mishmash,
3054   and changing it on an individual basis wouldn't make things better.
3055   Dietmar will do this work.</p>
3056 <hr>
3057 <a name="401"><h3>401.&nbsp; incorrect type casts in table 32 in lib.allocator.requirements</h3></a><p><b>Section:</b>&nbsp;20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;27 Feb 2003</p>
3058 <p>
3059 I think that in par2 of 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> the last two
3060 lines of table 32 contain two incorrect type casts. The lines are ...
3061 </p>
3062
3063 <pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
3064   a.destroy(p)       Effect: ((T*)p)?-&gt;~T()
3065 </pre>
3066
3067 <p>
3068 .... with the prerequisits coming from the preceding two paragraphs, especially
3069 from table 31:
3070 </p>
3071
3072 <pre>  alloc&lt;T&gt;             a     ;// an allocator for T
3073   alloc&lt;T&gt;::pointer    p     ;// random access iterator
3074                               // (may be different from T*)
3075   alloc&lt;T&gt;::reference  r = *p;// T&amp;
3076   T const&amp;             t     ;
3077 </pre>
3078
3079 <p>
3080 For that two type casts ("(void*)p" and "(T*)p") to be well-formed
3081 this would require then conversions to T* and void* for all
3082 alloc&lt;T&gt;::pointer, so it would implicitely introduce extra
3083 requirements for alloc&lt;T&gt;::pointer, additionally to the only
3084 current requirement (being a random access iterator).
3085 </p>
3086 <p><b>Proposed resolution:</b></p>
3087 <p>
3088 "(void*)p" should be replaced with "(void*)&amp;*p" and that
3089 "((T*)p)?-&gt;" should be replaced with "(*p)." or with
3090 "(&amp;*p)-&gt;".
3091 </p>
3092
3093 <p>
3094 Note: Actually I would prefer to replace "((T*)p)?-&gt;dtor_name" with
3095 "p?-&gt;dtor_name", but AFAICS this is not possible cause of an omission
3096 in 13.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/over.html#over.ref"> [over.ref]</a> (for which I have filed another DR on 29.11.2002).
3097 </p>
3098
3099 <p><i>[Kona: The LWG thinks this is somewhere on the border between
3100   Open and NAD.  The intend is clear: <tt>construct</tt> constructs an
3101   object at the location <i>p</i>.  It's reading too much into the
3102   description to think that literally calling <tt>new</tt> is
3103   required.  Tweaking this description is low priority until we can do
3104   a thorough review of allocators, and, in particular, allocators with
3105   non-default pointer types.]</i></p>
3106
3107 <hr>
3108 <a name="406"><h3>406.&nbsp;vector::insert(s) exception safety</h3></a><p><b>Section:</b>&nbsp;23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;27 Apr 2003</p>
3109 <p>
3110 There is a possible defect in the standard: the standard text was
3111 never intended to prevent arbitrary ForwardIterators, whose operations
3112 may throw exceptions, from being passed, and it also wasn't intended
3113 to require a temporary buffer in the case where ForwardIterators were
3114 passed (and I think most implementations don't use one).  As is, the
3115 standard appears to impose requirements that aren't met by any
3116 existing implementation.
3117 </p>
3118 <p><b>Proposed resolution:</b></p>
3119 <p>Replace 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> paragraph 1 with:</p>
3120 <blockquote>
3121   1- Notes: Causes reallocation if the new size is greater than the
3122   old capacity. If no reallocation happens, all the iterators and
3123   references before the insertion point remain valid. If an exception
3124   is thrown other than by the copy constructor or assignment operator
3125   of T or by any InputIterator operation there are no effects.
3126 </blockquote>
3127
3128 <p><i>[We probably need to say something similar for deque.]</i></p>
3129
3130 <hr>
3131 <a name="408"><h3>408.&nbsp;Is vector&lt;reverse_iterator&lt;char*&gt; &gt; forbidden?</h3></a><p><b>Section:</b>&nbsp;24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;3 June 2003</p>
3132 <p>
3133 I've been discussing iterator semantics with Dave Abrahams, and a
3134 surprise has popped up.  I don't think this has been discussed before.
3135 </p>
3136
3137 <p>
3138 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> says that the only operation that can be performed on "singular"
3139 iterator values is to assign a non-singular value to them.  (It
3140 doesn't say they can be destroyed, and that's probably a defect.)
3141 Some implementations have taken this to imply that there is no need
3142 to initialize the data member of a reverse_iterator&lt;&gt; in the default
3143 constructor.  As a result, code like
3144 </p>
3145 <blockquote>
3146   std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt; v(7);
3147   v.reserve(1000);
3148 </blockquote>
3149 <p>
3150 invokes undefined behavior, because it must default-initialize the
3151 vector elements, and then copy them to other storage.  Of course many
3152 other vector operations on these adapters are also left undefined,
3153 and which those are is not reliably deducible from the standard.
3154 </p>
3155
3156 <p>
3157 I don't think that 24.1 was meant to make standard-library iterator
3158 types unsafe.  Rather, it was meant to restrict what operations may
3159 be performed by functions which take general user- and standard
3160 iterators as arguments, so that raw pointers would qualify as
3161 iterators.  However, this is not clear in the text, others have come
3162 to the opposite conclusion.
3163 </p>
3164
3165 <p>
3166 One question is whether the standard iterator adaptors have defined
3167 copy semantics.  Another is whether they have defined destructor
3168 semantics: is
3169 </p>
3170 <blockquote>
3171   { std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt;  v(7); }
3172 </blockquote>
3173 <p>
3174 undefined too?
3175 </p>
3176
3177 <p>
3178 Note this is not a question of whether algorithms are allowed to
3179 rely on copy semantics for arbitrary iterators, just whether the
3180 types we actually supply support those operations.  I believe the
3181 resolution must be expressed in terms of the semantics of the
3182 adapter's argument type.  It should make clear that, e.g., the
3183 reverse_iterator&lt;T&gt; constructor is actually required to execute
3184 T(), and so copying is defined if the result of T() is copyable.
3185 </p>
3186
3187 <p>
3188 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#235">235</a>, which defines reverse_iterator's default
3189 constructor more precisely, has some relevance to this issue.
3190 However, it is not the whole story.
3191 </p>
3192
3193 <p>
3194 The issue was whether
3195 </p>
3196 <blockquote>
3197   reverse_iterator() { }
3198 </blockquote>
3199 <p>
3200 is allowed, vs.
3201 </p>
3202 <blockquote>
3203   reverse_iterator() : current() { }
3204 </blockquote>
3205
3206 <p>
3207 The difference is when T is char*, where the first leaves the member
3208 uninitialized, and possibly equal to an existing pointer value, or
3209 (on some targets) may result in a hardware trap when copied.
3210 </p>
3211
3212 <p>
3213 8.5 paragraph 5 seems to make clear that the second is required to
3214 satisfy DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#235">235</a>, at least for non-class Iterator argument
3215 types.
3216 </p>
3217
3218 <p>
3219 But that only takes care of reverse_iterator, and doesn't establish
3220 a policy for all iterators.  (The reverse iterator adapter was just
3221 an example.)  In particular, does my function
3222 </p>
3223 <blockquote>
3224   template &lt;typename Iterator&gt;
3225     void f() { std::vector&lt;Iterator&gt;  v(7); }
3226 </blockquote>
3227 <p>
3228 evoke undefined behavior for some conforming iterator definitions?
3229 I think it does, now, because vector&lt;&gt; will destroy those singular
3230 iterator values, and that's explicitly disallowed.
3231 </p>
3232
3233 <p>
3234 24.1 shouldn't give blanket permission to copy all singular iterators,
3235 because then pointers wouldn't qualify as iterators.  However, it
3236 should allow copying of that subset of singular iterator values that
3237 are default-initialized, and it should explicitly allow destroying any
3238 iterator value, singular or not, default-initialized or not.
3239 </p>
3240
3241 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#407">407</a></p>
3242 <p><b>Proposed resolution:</b></p>
3243
3244 <p><i>[
3245 We don't want to require all singular iterators to be copyable,
3246 because that is not the case for pointers.  However, default
3247 construction may be a special case.  Issue: is it really default
3248 construction we want to talk about, or is it something like value
3249 initialization?  We need to check with core to see whether default
3250 constructed pointers are required to be copyable; if not, it would be
3251 wrong to impose so strict a requirement for iterators.
3252 ]</i></p>
3253
3254 <hr>
3255 <a name="409"><h3>409.&nbsp;Closing an fstream should clear error state</h3></a><p><b>Section:</b>&nbsp;27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a>, 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;3 June 2003</p>
3256 <p>
3257 A strict reading of 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> shows that opening or
3258 closing a basic_[io]fstream does not affect the error bits.  This
3259 means, for example, that if you read through a file up to EOF, and
3260 then close the stream and reopen it at the beginning of the file,
3261 the EOF bit in the stream's error state is still set.  This is
3262 counterintuitive.
3263 </p>
3264 <p>
3265 The LWG considered this issue once before, as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#22">22</a>,
3266 and put in a footnote to clarify that the strict reading was indeed
3267 correct.  We did that because we believed the standard was
3268 unambiguous and consistent, and that we should not make architectural
3269 changes in a TC.  Now that we're working on a new revision of the
3270 language, those considerations no longer apply.
3271 </p>
3272 <p><b>Proposed resolution:</b></p>
3273
3274 <p>Change 27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a>, para. 3 from:</p>
3275
3276 <blockquote>
3277 Calls rdbuf()-&gt;open(s,mode|in). If that function returns a null
3278 pointer, calls setstate(failbit) (which may throw ios_base::failure
3279 [Footnote: (lib.iostate.flags)].
3280 </blockquote>
3281
3282 <p>to:</p>
3283
3284 <blockquote>Calls rdbuf()-&gt;open(s,mode|in). If that function returns
3285 a null pointer, calls setstate(failbit) (which may throw
3286 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
3287 </blockquote>
3288
3289 <p>Change 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a>, para. 3 from:</p>
3290
3291 <blockquote>Calls rdbuf()-&gt;open(s,mode|out). If that function
3292 returns a null pointer, calls setstate(failbit) (which may throw
3293 ios_base::failure [Footnote: (lib.iostate.flags)).
3294 </blockquote>
3295
3296 <p>to:</p>
3297
3298 <blockquote>Calls rdbuf()-&gt;open(s,mode|out). If that function
3299 returns a null pointer, calls setstate(failbit) (which may throw
3300 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
3301 </blockquote>
3302
3303 <p>Change 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a>, para. 3 from:</p>
3304
3305 <blockquote>Calls rdbuf()-&gt;open(s,mode), If that function returns a
3306 null pointer, calls setstate(failbit), (which may throw
3307 ios_base::failure). (lib.iostate.flags) )
3308 </blockquote>
3309
3310 <p>to:</p>
3311
3312 <blockquote>Calls rdbuf()-&gt;open(s,mode), If that function returns a
3313 null pointer, calls setstate(failbit), (which may throw
3314 ios_base::failure). (lib.iostate.flags) ), else calls clear().
3315 </blockquote>
3316
3317
3318
3319 <p><i>[Kona: the LWG agrees this is a good idea.  Post-Kona: Bill
3320 provided wording.  He suggests having open, not close, clear the error
3321 flags.]</i></p>
3322
3323 <p><i>[Post-Sydney: Howard provided a new proposed resolution.  The
3324   old one didn't make sense because it proposed to fix this at the
3325   level of basic_filebuf, which doesn't have access to the stream's
3326   error state.  Howard's proposed resolution fixes this at the level
3327   of the three fstream class template instead.]</i></p>
3328
3329 <hr>
3330 <a name="413"></a><h3><a name="413">413.&nbsp;Proposed resolution to LDR#64 still wrong</a></h3><p><b>Section:</b>&nbsp;27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Bo Persson&nbsp; <b>Date:</b>&nbsp;13 Jul 2003</p>
3331 <p>
3332 The second sentence of the proposed resolution says:
3333 </p>
3334
3335 <p>
3336 "If it inserted no characters because it caught an exception thrown
3337 while extracting characters from sb and ..."
3338 </p>
3339
3340 <p>
3341 However, we are not extracting from sb, but extracting from the
3342 basic_istream (*this) and inserting into sb. I can't really tell if
3343 "extracting" or "sb" is a typo.
3344 </p>
3345
3346 <p><i>[
3347 Sydney: Definitely a real issue. We are, indeed, extracting characters
3348 from an istream and not from sb. The problem was there in the FDIS and
3349 wasn't fixed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#64">64</a>. Probably what was intended was
3350 to have *this instead of sb. We're talking about the exception flag
3351 state of a basic_istream object, and there's only one basic_istream
3352 object in this discussion, so that would be a consistent
3353 interpretation.  (But we need to be careful: the exception policy of
3354 this member function must be consistent with that of other
3355 extractors.)  PJP will provide wording.
3356 ]</i></p>
3357
3358 <p><b>Proposed resolution:</b></p>
3359 <p>Change the sentence from:</p>
3360
3361 <blockquote>
3362 If it inserted no characters because it caught an exception thrown
3363 while extracting characters from sb and failbit is on in exceptions(),
3364 then the caught exception is rethrown.
3365 </blockquote>
3366
3367 <p>to:</p>
3368
3369 <blockquote>
3370 If it inserted no characters because it caught an exception thrown
3371 while extracting characters from *this and failbit is on in exceptions(),
3372 then the caught exception is rethrown.
3373 </blockquote>
3374 <hr>
3375 <a name="416"><h3>416.&nbsp;definitions of XXX_MIN and XXX_MAX macros in climits</h3></a><p><b>Section:</b>&nbsp;18.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.c.limits"> [lib.c.limits]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
3376         <p>
3377
3378 Given two overloads of the function foo(), one taking an argument of type
3379 int and the other taking a long, which one will the call foo(LONG_MAX)
3380 resolve to? The expected answer should be foo(long), but whether that
3381 is true depends on the #defintion of the LONG_MAX macro, specifically
3382 its type. This issue is about the fact that the type of these macros
3383 is not actually required to be the same as the the type each respective
3384 limit.
3385 <br>
3386
3387 Section 18.2.2 of the C++ Standard does not specify the exact types of
3388 the XXX_MIN and XXX_MAX macros #defined in the &lt;climits&gt; and &lt;limits.h&gt;
3389 headers such as INT_MAX and LONG_MAX and instead defers to the C standard.
3390 <br>
3391
3392 Section 5.2.4.2.1, p1 of the C standard specifies that "The values [of
3393 these constants] shall be replaced by constant expressions suitable for use
3394 in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX,
3395 the following shall be replaced by expressions that have the same type as
3396 would an expression that is an object of the corresponding type converted
3397 according to the integer promotions."
3398 <br>
3399
3400 The "corresponding type converted according to the integer promotions" for
3401 LONG_MAX is, according to 6.4.4.1, p5 of the C standard, the type of long
3402 converted to the first of the following set of types that can represent it:
3403 int, long int, long long int. So on an implementation where (sizeof(long)
3404 == sizeof(int)) this type is actually int, while on an implementation where
3405 (sizeof(long) &gt; sizeof(int)) holds this type will be long.
3406 <br>
3407
3408 This is not an issue in C since the type of the macro cannot be detected
3409 by any conforming C program, but it presents a portability problem in C++
3410 where the actual type is easily detectable by overload resolution.
3411
3412         </p>
3413     <p><b>Proposed resolution:</b></p>
3414
3415 <p><i>[Kona: the LWG does not believe this is a defect.  The C macro
3416   definitions are what they are; we've got a better
3417   mechanism, <tt>std::numeric_limits</tt>, that is specified more
3418   precisely than the C limit macros.  At most we should add a
3419   nonnormative note recommending that users who care about the exact
3420   types of limit quantities should use &lt;limits&gt; instead of
3421   &lt;climits&gt;.]</i></p>
3422
3423 <hr>
3424 <a name="417"></a><h3><a name="417">417.&nbsp;what does ctype::do_widen() return on failure</a></h3><p><b>Section:</b>&nbsp;22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
3425 <p>
3426 The Effects and Returns clauses of the do_widen() member function of
3427 the ctype facet fail to specify the behavior of the function on failure.
3428 That the function may not be able to simply cast the narrow character
3429 argument to the type of the result since doing so may yield the wrong value
3430 for some wchar_t encodings. Popular implementations of ctype&lt;wchar_t&gt; that
3431 use mbtowc() and UTF-8 as the native encoding (e.g., GNU glibc) will fail
3432 when the argument's MSB is set. There is no way for the the rest of locale
3433 and iostream to reliably detect this failure.
3434 </p>
3435 <p><b>Proposed resolution:</b></p>
3436 <p><i>[Kona: This is a real problem.  Widening can fail.  It's unclear
3437   what the solution should be.  Returning WEOF works for the wchar_t
3438   specialization, but not in general.  One option might be to add a
3439   default, like <i>narrow</i>.  But that's an incompatible change.
3440   Using <i>traits::eof</i> might seem like a good idea, but facets
3441   don't have access to traits (a recurring problem).  We could
3442   have <i>widen</i> throw an exception, but that's a scary option;
3443   existing library components aren't written with the assumption
3444   that <i>widen</i> can throw.]</i></p>
3445 <hr>
3446 <a name="418"><h3>418.&nbsp;exceptions thrown during iostream cleanup</h3></a><p><b>Section:</b>&nbsp;27.4.2.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ios::Init"> [lib.ios::Init]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
3447 <p>
3448 The dtor of the ios_base::Init object is supposed to call flush() on the
3449 6 standard iostream objects cout, cerr, clog, wcout, wcerr, and wclog.
3450 This call may cause an exception to be thrown.
3451 </p>
3452
3453 <p>
3454 17.4.4.8, p3 prohibits all library destructors from throwing exceptions.
3455 </p>
3456
3457 <p>
3458 The question is: What should this dtor do if one or more of these calls
3459 to flush() ends up throwing an exception? This can happen quite easily
3460 if one of the facets installed in the locale imbued in the iostream
3461 object throws.
3462 </p>
3463 <p><b>Proposed resolution:</b></p>
3464 <p><i>[Kona: We probably can't do much better than what we've got, so
3465   the LWG is leaning toward NAD.  At the point where the standard
3466   stream objects are being cleaned up, the usual error reporting
3467   mechanism are all unavailable.  And exception from flush at this
3468   point will definitely cause problems.  A quality implementation
3469   might reasonably swallow the exception, or call abort, or do
3470   something even more drastic.]</i></p>
3471 <hr>
3472 <a name="419"><h3>419.&nbsp;istream extractors not setting failbit if eofbit is already set</h3></a><p><b>Section:</b>&nbsp;27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
3473         <p>
3474
3475 27.6.1.1.2, p2 says that istream::sentry ctor prepares for input if is.good()
3476 is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to
3477 true if the stream state is good after any preparation. 27.6.1.2.1, p1 then
3478 says that a formatted input function endeavors to obtain the requested input
3479 if the sentry's operator bool() returns true.
3480
3481 Given these requirements, no formatted extractor should ever set failbit if
3482 the initial stream rdstate() == eofbit. That is contrary to the behavior of
3483 all implementations I tested. The program below prints out
3484
3485 eof = 1, fail = 0
3486 eof = 1, fail = 1
3487
3488 on all of them.
3489         </p>
3490 <pre>
3491 #include &lt;sstream&gt;
3492 #include &lt;cstdio&gt;
3493
3494 int main()
3495 {
3496     std::istringstream strm ("1");
3497
3498     int i = 0;
3499
3500     strm &gt;&gt; i;
3501
3502     std::printf ("eof = %d, fail = %d\n",
3503                  !!strm.eof (), !!strm.fail ());
3504
3505     strm &gt;&gt; i;
3506
3507     std::printf ("eof = %d, fail = %d\n",
3508                  !!strm.eof (), !!strm.fail ());
3509 }
3510
3511 </pre>
3512         <p>
3513 <br>
3514
3515 Comments from Jerry Schwarz (c++std-lib-11373):
3516 <br>
3517
3518 Jerry Schwarz wrote:
3519 <br>
3520
3521 I don't know where (if anywhere) it says it in the standard, but the
3522 formatted extractors are supposed to set failbit if they don't extract
3523 any characters. If they didn't then simple loops like
3524 <br>
3525
3526 while (cin &gt;&gt; x);
3527 <br>
3528
3529 would loop forever.
3530 <br>
3531
3532 Further comments from Martin Sebor:
3533 <br>
3534
3535 The question is which part of the extraction should prevent this from happening
3536 by setting failbit when eofbit is already set. It could either be the sentry
3537 object or the extractor. It seems that most implementations have chosen to
3538 set failbit in the sentry [...] so that's the text that will need to be
3539 corrected.
3540
3541         </p>
3542     <p><b>Proposed resolution:</b></p>
3543 <p>Kona: Possibly NAD.  If eofbit is set then good() will return false.  We
3544   then set <i>ok</i> to false.  We believe that the sentry's
3545   constructor should always set failbit when <i>ok</i> is false, and
3546   we also think the standard already says that.  Possibly it could be
3547   clearer.</p>
3548
3549 <hr>
3550 <a name="421"><h3>421.&nbsp;is basic_streambuf copy-constructible?</h3></a><p><b>Section:</b>&nbsp;27.5.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
3551 <p>
3552 The reflector thread starting with c++std-lib-11346 notes that the class
3553 template basic_streambuf, along with basic_stringbuf and basic_filebuf,
3554 is copy-constructible but that the semantics of the copy constructors
3555 are not defined anywhere. Further, different implementations behave
3556 differently in this respect: some prevent copy construction of objects
3557 of these types by declaring their copy ctors and assignment operators
3558 private, others exhibit undefined behavior, while others still give
3559 these operations well-defined semantics.
3560 </p>
3561
3562 <p>
3563 Note that this problem doesn't seem to be isolated to just the three
3564 types mentioned above. A number of other types in the library section
3565 of the standard provide a compiler-generated copy ctor and assignment
3566 operator yet fail to specify their semantics.  It's believed that the
3567 only types for which this is actually a problem (i.e. types where the
3568 compiler-generated default may be inappropriate and may not have been
3569 intended) are locale facets.  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-closed.html#439">439</a>.
3570 </p>
3571 <p><b>Proposed resolution:</b></p>
3572 <p>
3573 27.5.2 [lib.streambuf]:  Add into the synopsis, public section, just above the destructor declaration:
3574 </p>
3575
3576 <blockquote>
3577 <pre>basic_streambuf(const basic_streambuf&amp; sb);
3578 basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
3579 </pre>
3580 </blockquote>
3581
3582 <p>Insert after 27.5.2.1, paragraph 2:</p>
3583 <blockquote>
3584 <pre>basic_streambuf(const basic_streambuf&amp; sb);
3585 </pre>
3586
3587 <p>Constructs a copy of sb.</p>
3588 <p>Postcondtions:</p>
3589 <pre>                eback() == sb.eback()
3590                 gptr()  == sb.gptr()
3591                 egptr() == sb.egptr()
3592                 pbase() == sb.pbase()
3593                 pptr()  == sb.pptr()
3594                 epptr() == sb.epptr()
3595                 getloc() == sb.getloc()
3596 </pre>
3597
3598 <pre>basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
3599 </pre>
3600
3601 <p>Assigns the data members of sb to this.</p>
3602
3603 <p>Postcondtions:</p>
3604 <pre>                eback() == sb.eback()
3605                 gptr()  == sb.gptr()
3606                 egptr() == sb.egptr()
3607                 pbase() == sb.pbase()
3608                 pptr()  == sb.pptr()
3609                 epptr() == sb.epptr()
3610                 getloc() == sb.getloc()
3611 </pre>
3612
3613 <p>Returns: *this.</p>
3614 </blockquote>
3615
3616 <p>27.7.1 [lib.stringbuf]:</p>
3617
3618 <b>Option A:</b>
3619
3620 <blockquote>
3621 <p>Insert into the basic_stringbuf synopsis in the private section:</p>
3622
3623 <pre>basic_stringbuf(const basic_stringbuf&amp;);             // not defined
3624 basic_stringbuf&amp; operator=(const basic_stringbuf&amp;);  // not defined
3625 </pre>
3626 </blockquote>
3627
3628 <b>Option B:</b>
3629
3630 <blockquote>
3631 <p>Insert into the basic_stringbuf synopsis in the public section:</p>
3632
3633 <pre>basic_stringbuf(const basic_stringbuf&amp; sb);
3634 basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);
3635 </pre>
3636
3637 <p>27.7.1.1, insert after paragraph 4:</p>
3638
3639 <pre>basic_stringbuf(const basic_stringbuf&amp; sb);</pre>
3640
3641 <p>
3642 Constructs an independent copy of sb as if with sb.str(), and with the openmode that sb was constructed with.
3643 </p>
3644
3645 <p>Postcondtions: </p>
3646 <pre>               str() == sb.str()
3647                gptr()  - eback() == sb.gptr()  - sb.eback()
3648                egptr() - eback() == sb.egptr() - sb.eback()
3649                pptr()  - pbase() == sb.pptr()  - sb.pbase()
3650                getloc() == sb.getloc()
3651 </pre>
3652
3653 <p>Note: The only requirement on epptr() is that it point beyond the
3654 initialized range if an output sequence exists. There is no requirement
3655 that epptr() - pbase() == sb.epptr() - sb.pbase().
3656 </p>
3657
3658 <pre>basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);</pre>
3659 <p>After assignment the basic_stringbuf has the same state as if it
3660 were initially copy constructed from sb, except that the
3661 basic_stringbuf is allowed to retain any excess capacity it might have,
3662 which may in turn effect the value of epptr().
3663 </p>
3664 </blockquote>
3665
3666 <p>27.8.1.1 [lib.filebuf]</p>
3667
3668 <p>Insert at the bottom of the basic_filebuf synopsis:</p>
3669
3670 <blockquote>
3671 <pre>private:
3672   basic_filebuf(const basic_filebuf&amp;);             // not defined
3673   basic_filebuf&amp; operator=(const basic_filebuf&amp;);  // not defined
3674 </pre>
3675 </blockquote>
3676 <p><i>[Kona: this is an issue for basic_streambuf itself and for its
3677   derived classes.  We are leaning toward allowing basic_streambuf to
3678   be copyable, and specifying its precise semantics.  (Probably the
3679   obvious: copying the buffer pointers.)  We are less sure whether
3680   the streambuf derived classes should be copyable.  Howard will
3681   write up a proposal.]</i></p>
3682
3683 <p><i>[Sydney: Dietmar presented a new argument against basic_streambuf
3684   being copyable: it can lead to an encapsulation violation. Filebuf
3685   inherits from streambuf. Now suppose you inhert a my_hijacking_buf
3686   from streambuf. You can copy the streambuf portion of a filebuf to a
3687   my_hijacking_buf, giving you access to the pointers into the
3688   filebuf's internal buffer. Perhaps not a very strong argument, but
3689   it was strong enough to make people nervous. There was weak
3690   preference for having streambuf not be copyable. There was weak
3691   preference for having stringbuf not be copyable even if streambuf
3692   is. Move this issue to open for now.
3693 ]</i></p>
3694
3695 <p><b>Rationale:</b></p>
3696 <p>
3697 27.5.2 [lib.streambuf]: The proposed basic_streambuf copy constructor
3698 and assignment operator are the same as currently implied by the lack
3699 of declarations: public and simply copies the data members.  This
3700 resolution is not a change but a clarification of the current
3701 standard.
3702 </p>
3703
3704 <p>
3705 27.7.1 [lib.stringbuf]: There are two reasonable options: A) Make
3706 basic_stringbuf not copyable.  This is likely the status-quo of
3707 current implementations.  B) Reasonable copy semantics of
3708 basic_stringbuf can be defined and implemented.  A copyable
3709 basic_streambuf is arguably more useful than a non-copyable one.  This
3710 should be considered as new functionality and not the fixing of a
3711 defect.  If option B is chosen, ramifications from issue 432 are taken
3712 into account.
3713 </p>
3714
3715 <p>
3716 27.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for
3717 basic_filebuf.
3718 </p>
3719
3720 <hr>
3721 <a name="422"><h3>422.&nbsp;explicit specializations of member functions of class templates</h3></a><p><b>Section:</b>&nbsp;17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
3722 <p>
3723 It has been suggested that 17.4.3.1, p1 may or may not allow programs to
3724 explicitly specialize members of standard templates on user-defined types.
3725 The answer to the question might have an impact where library requirements
3726 are given using the "as if" rule. I.e., if programs are allowed to specialize
3727 member functions they will be able to detect an implementation's strict
3728 conformance to Effects clauses that describe the behavior of the function
3729 in terms of the other member function (the one explicitly specialized by
3730 the program) by relying on the "as if" rule.
3731 </p>
3732 <p><b>Proposed resolution:</b></p>
3733
3734 <p>
3735   Add the following sentence immediately after the text of 17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>, p1:
3736 </p>
3737
3738 <blockquote>
3739     The behavior of a program that declares explicit specializations
3740     of any members of class templates or explicit specializations of
3741     any member templates of classes or class templates defined in
3742     this library is undefined.
3743 </blockquote>
3744
3745
3746 <p><i>[Kona: straw poll was 6-1 that user programs should not be
3747   allowed to specialize individual member functions of standard
3748   library class templates, and that doing so invokes undefined
3749   behavior. Post-Kona: Martin provided wording.]</i></p>
3750
3751 <p><i>[Sydney: The LWG agrees that the standard shouldn't permit users
3752 to specialize individual member functions unless they specialize the
3753 whole class, but we're not sure these words say what we want them to;
3754 they could be read as prohibiting the specialization of any standard
3755 library class templates. We need to consult with CWG to make sure we
3756 use the right wording.]</i></p>
3757
3758 <hr>
3759 <a name="423"><h3>423.&nbsp;effects of negative streamsize in iostreams</h3></a><p><b>Section:</b>&nbsp;27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
3760
3761 <p>
3762 A third party test suite tries to exercise istream::ignore(N) with
3763 a negative value of N and expects that the implementation will treat
3764 N as if it were 0. Our implementation asserts that (N &gt;= 0) holds and
3765 aborts the test.
3766 </p>
3767
3768 <p>
3769 I can't find anything in section 27 that prohibits such values but I don't
3770 see what the effects of such calls should be, either (this applies to
3771 a number of unformatted input functions as well as some member functions
3772 of the basic_streambuf template).
3773 </p>
3774 <p><b>Proposed resolution:</b></p>
3775 <p>
3776 I propose that we add to each function in clause 27 that takes an argument,
3777 say N, of type streamsize a Requires clause saying that "N &gt;= 0." The intent
3778 is to allow negative streamsize values in calls to precision() and width()
3779 but disallow it in calls to streambuf::sgetn(), istream::ignore(), or
3780 ostream::write().
3781 </p>
3782
3783 <p><i>[Kona: The LWG agreed that this is probably what we want.  However, we
3784   need a review to find all places where functions in clause 27 take
3785   arguments of type streamsize that shouldn't be allowed to go
3786   negative.  Martin will do that review.]</i></p>
3787
3788 <hr>
3789 <a name="424"><h3>424.&nbsp;normative notes</h3></a><p><b>Section:</b>&nbsp;17.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.structure.summary"> [lib.structure.summary]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
3790
3791 <p>
3792 The text in 17.3.1.1, p1 says:
3793 <br>
3794
3795 "Paragraphs labelled "Note(s):" or "Example(s):" are informative, other
3796 paragraphs are normative."
3797 <br>
3798
3799 The library section makes heavy use of paragraphs labeled "Notes(s),"
3800 some of which are clearly intended to be normative (see list 1), while
3801 some others are not (see list 2). There are also those where the intent
3802 is not so clear (see list 3).
3803 <br>
3804
3805 List 1 -- Examples of (presumably) normative Notes:
3806 <br>
3807
3808 20.4.1.1, p3, 20.4.1.1, p10, 21.3.1, p11, 22.1.1.2, p11, 23.2.1.3, p2,
3809 25.3.7, p3, 26.2.6, p14a, 27.5.2.4.3, p7.
3810 <br>
3811
3812 List 2 -- Examples of (presumably) informative Notes:
3813 <br>
3814
3815 18.4.1.3, p3, 21.3.5.6, p14, 22.2.1.5.2, p3, 25.1.1, p4, 26.2.5, p1,
3816 27.4.2.5, p6.
3817 <br>
3818
3819 List 3 -- Examples of Notes that are not clearly either normative
3820 or informative:
3821 <br>
3822
3823 22.1.1.2, p8, 22.1.1.5, p6, 27.5.2.4.5, p4.
3824 <br>
3825
3826 None of these lists is meant to be exhaustive.
3827 </p>
3828
3829 <p><b>Proposed resolution:</b></p>
3830
3831 <p><i>[Definitely a real problem.  The big problem is there's material
3832   that doesn't quite fit any of the named paragraph categories
3833   (e.g. <b>Effects</b>).  Either we need a new kind of named
3834   paragraph, or we need to put more material in unnamed paragraphs
3835   jsut after the signature.  We need to talk to the Project Editor
3836   about how to do this.
3837 ]</i></p>
3838
3839 <hr>
3840 <a name="427"><h3>427.&nbsp;stage 2 and rationale of DR 221</h3></a><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
3841 <p>
3842 The requirements specified in Stage 2 and reiterated in the rationale
3843 of DR 221 (and echoed again in DR 303) specify that num_get&lt;charT&gt;::
3844 do_get() compares characters on the stream against the widened elements
3845 of "012...abc...ABCX+-"
3846 </p>
3847
3848 <p>
3849 An implementation is required to allow programs to instantiate the num_get
3850 template on any charT that satisfies the requirements on a user-defined
3851 character type. These requirements do not include the ability of the
3852 character type to be equality comparable (the char_traits template must
3853 be used to perform tests for equality). Hence, the num_get template cannot
3854 be implemented to support any arbitrary character type. The num_get template
3855 must either make the assumption that the character type is equality-comparable
3856 (as some popular implementations do), or it may use char_traits&lt;charT&gt; to do
3857 the comparisons (some other popular implementations do that). This diversity
3858 of approaches makes it difficult to write portable programs that attempt to
3859 instantiate the num_get template on user-defined types.
3860 </p>
3861 <p><b>Proposed resolution:</b></p>
3862 <p><i>[Kona: the heart of the problem is that we're theoretically
3863   supposed to use traits classes for all fundamental character
3864   operations like assignment and comparison, but facets don't have
3865   traits parameters.  This is a fundamental design flaw and it
3866   appears all over the place, not just in this one place.  It's not
3867   clear what the correct solution is, but a thorough review of facets
3868   and traits is in order.  The LWG considered and rejected the
3869   possibility of changing numeric facets to use narrowing instead of
3870   widening.  This may be a good idea for other reasons (see issue
3871   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#459">459</a>), but it doesn't solve the problem raised by this
3872   issue.  Whether we use widen or narrow the <tt>num_get</tt> facet
3873   still has no idea which traits class the user wants to use for
3874   the comparison, because only streams, not facets, are passed traits
3875   classes.   The standard does not require that two different
3876   traits classes with the same <tt>char_type</tt> must necessarily
3877   have the same behavior.]</i></p>
3878
3879 <p>Informally, one possibility: require that some of the basic
3880 character operations, such as <tt>eq</tt>, <tt>lt</tt>,
3881 and <tt>assign</tt>, must behave the same way for all traits classes
3882 with the same <tt>char_type</tt>.  If we accept that limitation on
3883 traits classes, then the facet could reasonably be required to
3884 use <tt>char_traits&lt;charT&gt;</tt></p>.
3885
3886 <hr>
3887 <a name="430"><h3>430.&nbsp;valarray subset operations</h3></a><p><b>Section:</b>&nbsp;26.3.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-numerics.html#lib.valarray.sub"> [lib.valarray.sub]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
3888 <p>
3889 The standard fails to specify the behavior of valarray::operator[](slice)
3890 and other valarray subset operations when they are passed an "invalid"
3891 slice object, i.e., either a slice that doesn't make sense at all (e.g.,
3892 slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray
3893 object (e.g., slice (2, 1, 1) for a valarray of size 1).
3894 </p>
3895 <p><b>Proposed resolution:</b></p>
3896 <p><i>[Kona: the LWG believes that invalid slices should invoke
3897   undefined behavior.  Valarrays are supposed to be designed for high
3898   performance, so we don't want to require specific checking.  We
3899   need wording to express this decision.]</i></p>
3900 <hr>
3901 <a name="431"><h3>431.&nbsp;Swapping containers with unequal allocators</h3></a><p><b>Section:</b>&nbsp;20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Sep 2003</p>
3902 <p>Clause 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> paragraph 4 says that implementations
3903   are permitted to supply containers that are unable to cope with
3904   allocator instances and that container implementations may assume
3905   that all instances of an allocator type compare equal.  We gave
3906   implementers this latitude as a temporary hack, and eventually we
3907   want to get rid of it.  What happens when we're dealing with
3908   allocators that <i>don't</i> compare equal?
3909 </p>
3910
3911 <p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
3912   objects of type <tt>vector&lt;int, my_alloc&gt;</tt> and that
3913   <tt>v1.get_allocator() != v2.get_allocator()</tt>.  What happens if
3914   we write <tt>v1.swap(v2)</tt>?  Informally, three possibilities:</p>
3915
3916 <p>1. This operation is illegal.  Perhaps we could say that an
3917   implementation is required to check and to throw an exception, or
3918   perhaps we could say it's undefined behavior.</p>
3919 <p>2. The operation performs a slow swap (i.e. using three
3920   invocations of <tt>operator=</tt>, leaving each allocator with its
3921   original container.  This would be an O(N) operation.</p>
3922 <p>3. The operation swaps both the vectors' contents and their
3923   allocators.  This would be an O(1) operation. That is:</p>
3924   <blockquote>
3925   <pre>    my_alloc a1(...);
3926     my_alloc a2(...);
3927     assert(a1 != a2);
3928
3929     vector&lt;int, my_alloc&gt; v1(a1);
3930     vector&lt;int, my_alloc&gt; v2(a2);
3931     assert(a1 == v1.get_allocator());
3932     assert(a2 == v2.get_allocator());
3933
3934     v1.swap(v2);
3935     assert(a1 == v2.get_allocator());
3936     assert(a2 == v1.get_allocator());
3937   </pre>
3938   </blockquote>
3939
3940 <p><b>Proposed resolution:</b></p>
3941
3942 <p><i>[Kona: This is part of a general problem.  We need a paper
3943   saying how to deal with unequal allocators in general.]</i></p>
3944
3945 <p><i>[pre-Sydney: Howard argues for option 3 in n1599.]</i></p>
3946
3947 <hr>
3948 <a name="434"><h3>434.&nbsp;bitset::to_string() hard to use</h3></a><p><b>Section:</b>&nbsp;23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2003</p>
3949 <p>
3950 It has been pointed out a number of times that the bitset to_string() member
3951 function template is tedious to use since callers must explicitly specify the
3952 entire template argument list (3 arguments). At least two implementations
3953 provide a number of overloads of this template to make it easier to use.
3954 </p>
3955 <p><b>Proposed resolution:</b></p>
3956 <p>In order to allow callers to specify no template arguments at all, just the
3957 first one (charT), or the first 2 (charT and traits), in addition to all
3958 three template arguments, add the following three overloads to both the
3959 interface (declarations only) of the class template bitset as well as to
3960 section 23.3.5.2, immediately after p34, the Returns clause of the existing
3961 to_string() member function template:</p>
3962
3963 <pre>    template &lt;class charT, class traits&gt;
3964     basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
3965     to_string () const;
3966
3967     -34.1- Returns: to_string&lt;charT, traits, allocator&lt;charT&gt; &gt;().
3968
3969     template &lt;class charT&gt;
3970     basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
3971     to_string () const;
3972
3973     -34.2- Returns: to_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;().
3974
3975     basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
3976     to_string () const;
3977
3978     -34.3- Returns: to_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;().
3979 </pre>
3980
3981 <p><i>[Kona: the LWG agrees that this is an improvement over the
3982   status quo.  Dietmar thought about an alternative using a proxy
3983   object but now believes that the proposed resolution above is the
3984   right choice.
3985 ]</i></p>
3986
3987 <hr>
3988 <a name="438"><h3>438.&nbsp;Ambiguity in the "do the right thing" clause</h3></a><p><b>Section:</b>&nbsp;23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;20 Oct 2003</p>
3989
3990 <p>Section 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>, paragraphs 9-11, fixed up the problem
3991 noticed with statements like:</p>
3992 <pre>vector&lt;int&gt; v(10, 1);
3993 </pre>
3994
3995 <p>The intent of the above statement was to construct with:</p>
3996 <pre>vector(size_type, const value_type&amp;);
3997 </pre>
3998
3999 <p>but early implementations failed to compile as they bound to:</p>
4000 <pre>template &lt;class InputIterator&gt;
4001 vector(InputIterator f, InputIterator l);
4002 </pre>
4003 <p>instead.</p>
4004
4005 <p>Paragraphs 9-11 say that if InputIterator is an integral type, then the
4006 member template constructor will have the same effect as:</p>
4007 <pre>vector&lt;static_cast&lt;size_type&gt;(f), static_cast&lt;value_type&gt;(l));
4008 </pre>
4009 <p>(and similarly for the other member template functions of sequences).</p>
4010
4011 <p>There is also a note that describes one implementation technique:</p>
4012 <blockquote>
4013    One way that sequence implementors can satisfy this requirement is to
4014    specialize the member template for every integral type.
4015 </blockquote>
4016
4017 <p>This might look something like:</p>
4018 <blockquote>
4019 <pre>template &lt;class T&gt;
4020 struct vector
4021 {
4022      typedef unsigned size_type;
4023
4024      explicit vector(size_type) {}
4025      vector(size_type, const T&amp;) {}
4026
4027      template &lt;class I&gt;
4028      vector(I, I);
4029
4030      // ...
4031 };
4032
4033 template &lt;class T&gt;
4034 template &lt;class I&gt;
4035 vector&lt;T&gt;::vector(I, I) { ... }
4036
4037 template &lt;&gt;
4038 template &lt;&gt;
4039 vector&lt;int&gt;::vector(int, int) { ... }
4040
4041 template &lt;&gt;
4042 template &lt;&gt;
4043 vector&lt;int&gt;::vector(unsigned, unsigned) { ... }
4044
4045 //  ...
4046 </pre>
4047 </blockquote>
4048
4049 <p>Label this solution 'A'.</p>
4050
4051 <p>The standard also says:</p>
4052 <blockquote>
4053  Less cumbersome implementation techniques also exist.
4054 </blockquote>
4055 <p>
4056 A popular technique is to not specialize as above, but instead catch
4057 every call with the member template, detect the type of InputIterator,
4058 and then redirect to the correct logic.  Something like:
4059 </p>
4060 <blockquote>
4061 <pre>template &lt;class T&gt;
4062 template &lt;class I&gt;
4063 vector&lt;T&gt;::vector(I f, I l)
4064 {
4065      choose_init(f, l, int2type&lt;is_integral&lt;I&gt;::value&gt;());
4066 }
4067
4068 template &lt;class T&gt;
4069 template &lt;class I&gt;
4070 vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;false&gt;)
4071 {
4072     // construct with iterators
4073 }
4074
4075 template &lt;class T&gt;
4076 template &lt;class I&gt;
4077 vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;true&gt;)
4078 {
4079     size_type sz = static_cast&lt;size_type&gt;(f);
4080     value_type v = static_cast&lt;value_type&gt;(l);
4081     // construct with sz,v
4082 }
4083 </pre>
4084 </blockquote>
4085
4086 <p>Label this solution 'B'.</p>
4087
4088 <p>Both of these solutions solve the case the standard specifically
4089 mentions:</p>
4090 <pre>vector&lt;int&gt; v(10, 1);  // ok, vector size 10, initialized to 1
4091 </pre>
4092
4093 <p>
4094 However, (and here is the problem), the two solutions have different
4095 behavior in some cases where the value_type of the sequence is not an
4096 integral type.  For example consider:
4097 </p>
4098 <blockquote><pre>     pair&lt;char, char&gt;                     p('a', 'b');
4099      vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
4100 </pre></blockquote>
4101 <p>
4102 The second line of this snippet is likely an error.  Solution A catches
4103 the error and refuses to compile.  The reason is that there is no
4104 specialization of the member template constructor that looks like:
4105 </p>
4106 <pre>template &lt;&gt;
4107 template &lt;&gt;
4108 vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;::vector(char, char) { ... }
4109 </pre>
4110
4111 <p>
4112 So the expression binds to the unspecialized member template
4113 constructor, and then fails (compile time) because char is not an
4114 InputIterator.
4115 </p>
4116
4117 <p>
4118 Solution B compiles the above example though.  'a' is casted to an
4119 unsigned integral type and used to size the outer vector.  'b' is
4120 static casted to the inner vector using it's explicit constructor:
4121 </p>
4122
4123 <pre>explicit vector(size_type n);
4124 </pre>
4125
4126 <p>
4127 and so you end up with a static_cast&lt;size_type&gt;('a') by
4128 static_cast&lt;size_type&gt;('b') matrix.
4129 </p>
4130
4131 <p>
4132 It is certainly possible that this is what the coder intended.  But the
4133 explicit qualifier on the inner vector has been thwarted at any rate.
4134 </p>
4135
4136 <p>
4137 The standard is not clear whether the expression:
4138 </p>
4139
4140 <pre>     vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
4141 </pre>
4142
4143 <p>
4144 (and similar expressions) are:
4145 </p>
4146
4147 <ol>
4148 <li>  undefined behavior.</li>
4149 <li>  illegal and must be rejected.</li>
4150 <li>  legal and must be accepted.</li>
4151 </ol>
4152
4153 <p>My preference is listed in the order presented.</p>
4154
4155 <p>There are still other techniques for implementing the requirements of
4156 paragraphs 9-11, namely the "restricted template technique" (e.g.
4157 enable_if).  This technique is the most compact and easy way of coding
4158 the requirements, and has the behavior of #2 (rejects the above
4159 expression).
4160 </p>
4161
4162 <p>
4163 Choosing 1 would allow all implementation techniques I'm aware of.
4164 Choosing 2 would allow only solution 'A' and the enable_if technique.
4165 Choosing 3 would allow only solution 'B'.
4166 </p>
4167
4168 <p>
4169 Possible wording for a future standard if we wanted to actively reject
4170 the expression above would be to change "static_cast" in paragraphs
4171 9-11 to "implicit_cast" where that is defined by:
4172 </p>
4173
4174 <blockquote>
4175 <pre>template &lt;class T, class U&gt;
4176 inline
4177 T implicit_cast(const U&amp; u)
4178 {
4179      return u;
4180 }
4181 </pre>
4182 </blockquote>
4183
4184 <p><b>Proposed resolution:</b></p>
4185
4186 Replace 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> paragraphs 9 - 11 with:
4187
4188 <p>For every sequence defined in this clause and in clause lib.strings:</p>
4189
4190 <ul>
4191   <li>
4192     <p>If the constructor</p>
4193        <pre>       template &lt;class InputIterator&gt;
4194        X(InputIterator f, InputIterator l,
4195          const allocator_type&amp; a = allocator_type())
4196        </pre>
4197     <p>is called with a type InputIterator that does not qualify as
4198     an input iterator, then the constructor will behave as if the
4199     overloaded constructor:</p>
4200        <pre>       X(size_type, const value_type&amp; = value_type(),
4201          const allocator_type&amp; = allocator_type())
4202        </pre>
4203     <p>were called instead, with the arguments static_cast&lt;size_type&gt;(f), l and a, respectively.</p>
4204   </li>
4205
4206   <li>
4207     <p>If the member functions of the forms:</p>
4208        <pre>       template &lt;class InputIterator&gt;          //  such as  insert()
4209        rt fx1(iterator p, InputIterator f, InputIterator l);
4210
4211        template &lt;class InputIterator&gt;          //  such as  append(), assign()
4212        rt fx2(InputIterator f, InputIterator l);
4213
4214        template &lt;class InputIterator&gt;          //  such as  replace()
4215        rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l);
4216        </pre>
4217     <p>are called with a type InputIterator that does not qualify as
4218     an input iterator, then these functions will behave as if the
4219     overloaded member functions:</p>
4220        <pre>       rt fx1(iterator, size_type, const value_type&amp;);
4221
4222        rt fx2(size_type, const value_type&amp;);
4223
4224        rt fx3(iterator, iterator, size_type, const value_type&amp;);
4225        </pre>
4226     <p>were called instead, with the same arguments.</p>
4227   </li>
4228 </ul>
4229
4230 <p>In the previous paragraph the alternative binding will fail if f
4231 is not implicitly convertible to X::size_type or if l is not implicitly
4232 convertible to X::value_type.</p>
4233
4234 <p>
4235 The extent to which an implementation determines that a type cannot be
4236 an input iterator is unspecified, except that as a minimum integral
4237 types shall not qualify as input iterators.
4238 </p>
4239
4240
4241
4242 <p><i>[
4243 Kona: agreed that the current standard requires <tt>v('a', 'b')</tt>
4244 to be accepted, and also agreed that this is surprising behavior.  The
4245 LWG considered several options, including something like
4246 implicit_cast, which doesn't appear to be quite what we want.  We
4247 considered Howards three options: allow acceptance or rejection,
4248 require rejection as a compile time error, and require acceptance.  By
4249 straw poll (1-6-1), we chose to require a compile time error.
4250 Post-Kona: Howard provided wording.
4251 ]</i></p>
4252
4253 <p><i>[
4254 Sydney: The LWG agreed with this general direction, but there was some
4255 discomfort with the wording in the original proposed resolution.
4256 Howard submitted new wording, and we will review this again in
4257 Redmond.
4258 ]</i></p>
4259
4260 <p><i>[Redmond: one very small change in wording: the first argument
4261   is cast to size_t.  This fixes the problem of something like
4262   <tt>vector&lt;vector&lt;int&gt; &gt;(5, 5)</tt>, where int is not
4263   implicitly convertible to the value type.]</i></p>
4264
4265 <p><b>Rationale:</b></p>
4266 <p>The proposed resolution fixes:</p>
4267
4268 <pre>  vector&lt;int&gt; v(10, 1);
4269 </pre>
4270
4271 <p>
4272 since as integral types 10 and 1 must be disqualified as input
4273 iterators and therefore the (size,value) constructor is called (as
4274 if).</p>
4275
4276 <p>The proposed resolution breaks:</p>
4277
4278 <pre>  vector&lt;vector&lt;T&gt; &gt; v(10, 1);
4279 </pre>
4280
4281 <p>
4282 because the integral type 1 is not *implicitly* convertible to
4283 vector&lt;T&gt;.  The wording above requires a diagnostic.</p>
4284
4285 <p>
4286 The proposed resolution leaves the behavior of the following code
4287 unspecified.
4288 </p>
4289
4290 <pre>  struct A
4291   {
4292     operator int () const {return 10;}
4293   };
4294
4295   struct B
4296   {
4297     B(A) {}
4298   };
4299
4300   vector&lt;B&gt; v(A(), A());
4301 </pre>
4302
4303 <p>
4304 The implementation may or may not detect that A is not an input
4305 iterator and employee the (size,value) constructor.  Note though that
4306 in the above example if the B(A) constructor is qualified explicit,
4307 then the implementation must reject the constructor as A is no longer
4308 implicitly convertible to B.
4309 </p>
4310 <hr>
4311 <a name="444"><h3>444.&nbsp;Bad use of casts in fstream</h3></a><p><b>Section:</b>&nbsp;27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;20 Nov 2003</p>
4312 <p>
4313 27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> p1, 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a> p1, 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a> p1 seems have same problem as exposed in LWG issue
4314 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#252">252</a>.
4315 </p>
4316 <p><b>Proposed resolution:</b></p>
4317
4318 <p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away
4319  constness. The other two places are stylistic: we could change the
4320  C-style casts to const_cast. Post-Sydney: Howard provided wording.
4321 ]</i></p>
4322
4323 <p>Change 27.8.1.7/1 from:</p>
4324 <blockquote>
4325   Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
4326 </blockquote>
4327
4328 <p>to:</p>
4329 <blockquote>
4330   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
4331 </blockquote>
4332
4333 <p>Change 27.8.1.10/1 from:</p>
4334 <blockquote>
4335   Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
4336 </blockquote>
4337
4338 <p>to:</p>
4339 <blockquote>
4340   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
4341 </blockquote>
4342
4343 <p>Change 27.8.1.13/1 from:</p>
4344 <blockquote>
4345   Returns: &amp;sb.
4346 </blockquote>
4347
4348 <p>to:</p>
4349 <blockquote>
4350   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
4351 </blockquote>
4352
4353
4354
4355 <hr>
4356 <a name="445"><h3>445.&nbsp;iterator_traits::reference unspecified for some iterator categories</h3></a><p><b>Section:</b>&nbsp;24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;9 Dec 2003</p>
4357 <p>
4358 The standard places no restrictions at all on the reference type
4359 of input, output, or forward iterators (for forward iterators it
4360 only specifies that *x must be value_type&amp; and doesn't mention
4361 the reference type).  Bidirectional iterators' reference type is
4362 restricted only by implication, since the base iterator's
4363 reference type is used as the return type of reverse_iterator's
4364 operator*, which must be T&amp; in order to be a conforming forward
4365 iterator.
4366 </p>
4367
4368 <p>
4369 Here's what I think we ought to be able to expect from an input
4370 or forward iterator's reference type R, where a is an iterator
4371 and V is its value_type
4372 </p>
4373
4374 <ul>
4375   <li>
4376       *a is convertible to R
4377   </li>
4378
4379   <li>
4380       R is convertible to V
4381   </li>
4382
4383   <li>
4384       static_cast&lt;V&gt;(static_cast&lt;R&gt;(*a)) is equivalent to
4385       static_cast&lt;V&gt;(*a)
4386   </li>
4387 </ul>
4388
4389 <p>A mutable forward iterator ought to satisfy, for x of type V:</p>
4390   <li>
4391       { R r = *a; r = x; } is equivalent to *a = x;
4392   </li>
4393
4394 <p>
4395 I think these requirements capture existing container iterators
4396 (including vector&lt;bool&gt;'s), but render istream_iterator invalid;
4397 its reference type would have to be changed to a constant
4398 reference.
4399 </p>
4400
4401
4402 <p>
4403 (Jeremy Siek) During the discussion in Sydney, it was felt that a
4404 simpler long term solution for this was needed. The solution proposed
4405 was to require <tt>reference</tt> to be the same type as <tt>*a</tt>
4406 and <tt>pointer</tt> to be the same type as <tt>a-&gt;</tt>.  Most
4407 iterators in the Standard Library already meet this requirement. Some
4408 iterators are output iterators, and do not need to meet the
4409 requirement, and others are only specified through the general
4410 iterator requirements (which will change with this resolution). The
4411 sole case where there is an explicit definition of the reference type
4412 that will need to change is <tt>istreambuf_iterator</tt> which returns
4413 <tt>charT</tt> from <tt>operator*</tt> but has a reference type of
4414 <tt>charT&amp;</tt>. We propose changing the reference type of
4415 <tt>istreambuf_iterator</tt> to <tt>charT</tt>.
4416 </p>
4417
4418 <p>The other option for resolving the issue with <tt>pointer</tt>,
4419   mentioned in the note below, is to remove <tt>pointer</tt>
4420   altogether. I prefer placing requirements on <tt>pointer</tt> to
4421   removing it for two reasons. First, <tt>pointer</tt> will become
4422   useful for implementing iterator adaptors and in particular,
4423   <tt>reverse_iterator</tt> will become more well defined. Second,
4424   removing <tt>pointer</tt> is a rather drastic and publicly-visible
4425   action to take.</p>
4426
4427 <p>The proposed resolution technically enlarges the requirements for
4428 iterators, which means there are existing iterators (such as
4429 <tt>istreambuf_iterator</tt>, and potentially some programmer-defined
4430 iterators) that will no longer meet the requirements. Will this break
4431 existing code? The scenario in which it would is if an algorithm
4432 implementation (say in the Standard Library) is changed to rely on
4433 <tt>iterator_traits::reference</tt>, and then is used with one of the
4434 iterators that do not have an appropriately defined
4435 <tt>iterator_traits::reference</tt>.
4436 </p>
4437
4438
4439 <p>The proposed resolution makes one other subtle change. Previously,
4440 it was required that output iterators have a <tt>difference_type</tt>
4441 and <tt>value_type</tt> of <tt>void</tt>, which means that a forward
4442 iterator could not be an output iterator. This is clearly a mistake,
4443 so I've changed the wording to say that those types may be
4444 <tt>void</tt>.
4445 </p>
4446
4447 <p><b>Proposed resolution:</b></p>
4448
4449 <p>In 24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a>, after:</p>
4450
4451 <blockquote>
4452 be defined as the iterator's difference type, value type and iterator
4453 category, respectively.
4454 </blockquote>
4455
4456 <p>add</p>
4457
4458 <blockquote>
4459 In addition, the types
4460 <pre>iterator_traits&lt;Iterator&gt;::reference
4461 iterator_traits&lt;Iterator&gt;::pointer
4462 </pre>
4463 must be defined as the iterator's reference and pointer types, that
4464 is, the same type as the type of <tt>*a</tt> and <tt>a-&gt;</tt>,
4465 respectively.
4466 </blockquote>
4467
4468 <p>In 24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a>, change:</p>
4469
4470 <blockquote>
4471 In the case of an output iterator, the types
4472 <pre>iterator_traits&lt;Iterator&gt;::difference_type
4473 iterator_traits&lt;Iterator&gt;::value_type
4474 </pre>
4475 are both defined as <tt>void</tt>.
4476 </blockquote>
4477
4478 <p>to:</p>
4479 <blockquote>
4480 In the case of an output iterator, the types
4481 <pre>iterator_traits&lt;Iterator&gt;::difference_type
4482 iterator_traits&lt;Iterator&gt;::value_type
4483 iterator_traits&lt;Iterator&gt;::reference
4484 iterator_traits&lt;Iterator&gt;::pointer
4485 </pre>
4486 may be defined as <tt>void</tt>.
4487 </blockquote>
4488
4489 <p>In 24.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, change:</p>
4490 <blockquote>
4491 <pre>typename traits::off_type, charT*, charT&amp;&gt;
4492 </pre>
4493 </blockquote>
4494 <p>to:</p>
4495 <blockquote>
4496 <pre>typename traits::off_type, charT*, charT&gt;
4497 </pre>
4498 </blockquote>
4499
4500 <p><i>[
4501 Redmond: there was concern in Sydney that this might not be the only place
4502 where things were underspecified and needed to be changed.  Jeremy
4503 reviewed iterators in the standard and confirmed that nothing else
4504 needed to be changed.
4505 ]</i></p>
4506
4507 <hr>
4508 <a name="446"><h3>446.&nbsp;Iterator equality between different containers</h3></a><p><b>Section:</b>&nbsp;24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>, 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Koenig&nbsp; <b>Date:</b>&nbsp;16 Dec 2003</p>
4509 <p>
4510 What requirements does the standard place on equality comparisons between
4511 iterators that refer to elements of different containers.  For example, if
4512 v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true?
4513 Is it allowed to throw an exception?
4514 </p>
4515
4516 <p>
4517 The standard appears to be silent on both questions.
4518 </p>
4519 <p><b>Proposed resolution:</b></p>
4520
4521 <p><i>[Sydney: The intention is that comparing two iterators from
4522 different containers is undefined, but it's not clear if we say that,
4523 or even whether it's something we should be saying in clause 23 or in
4524 clause 24.  Intuitively we might want to say that equality is defined
4525 only if one iterator is reachable from another, but figuring out how
4526 to say it in any sensible way is a bit tricky: reachability is defined
4527 in terms of equality, so we can't also define equality in terms of
4528 reachability.
4529 ]</i></p>
4530
4531 <hr>
4532 <a name="453"><h3>453.&nbsp;basic_stringbuf::seekoff need not always fail for an empty stream</h3></a><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
4533 <pre>  pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
4534                                     ios_base::openmode);
4535 </pre>
4536 <p>
4537 is obliged to fail if nothing has been inserted into the stream. This
4538 is unnecessary and undesirable. It should be permissible to seek to
4539 an effective offset of zero.</p>
4540
4541 <p><i>[
4542  Sydney: Agreed that this is an annoying problem: seeking to zero should be
4543  legal. Bill will provide wording.
4544 ]</i></p>
4545
4546 <p><b>Proposed resolution:</b></p>
4547 <p>Change the sentence from:</p>
4548 <blockquote>
4549 For a sequence to be positioned, if its next pointer (either
4550 gptr() or pptr()) is a null pointer, the positioning operation
4551 fails.
4552 </blockquote>
4553
4554 <p>to:</p>
4555
4556 <blockquote>
4557 For a sequence to be positioned, if its next pointer (either
4558 gptr() or pptr()) is a null pointer and the new offset newoff
4559 is nonzero, the positioning operation fails.
4560 </blockquote>
4561 <hr>
4562 <a name="454"><h3>454.&nbsp;basic_filebuf::open should accept wchar_t names</h3></a><p><b>Section:</b>&nbsp;27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
4563 <pre>    basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
4564 </pre>
4565
4566 <p>should be supplemented with the overload:</p>
4567
4568 <pre>    basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
4569 </pre>
4570
4571 <p>
4572 Depending on the operating system, one of these forms is fundamental and
4573 the other requires an implementation-defined mapping to determine the
4574 actual filename.
4575 </p>
4576
4577 <p><i>[Sydney: Yes, we want to allow wchar_t filenames.  Bill will
4578   provide wording.]</i></p>
4579
4580 <p><b>Proposed resolution:</b></p>
4581
4582 <p>Change from:</p>
4583 <blockquote>
4584 <pre>basic_filebuf&lt;charT,traits&gt;* open(
4585         const char* s,
4586         ios_base::openmode mode );
4587 </pre>
4588
4589 <p>
4590 Effects: If is_open() != false, returns a null pointer.
4591 Otherwise, initializes the filebuf as required. It then
4592 opens a file, if possible, whose name is the NTBS s ("as if"
4593 by calling std::fopen(s,modstr)).</p>
4594 </blockquote>
4595
4596 <p>to:</p>
4597
4598 <blockquote>
4599 <pre>basic_filebuf&lt;charT,traits&gt;* open(
4600         const char* s,
4601         ios_base::openmode mode );
4602
4603 basic_filebuf&lt;charT,traits&gt;* open(
4604         const wchar_t* ws,
4605         ios_base::openmode mode );
4606 </pre>
4607
4608 <p>
4609 Effects: If is_open() != false, returns a null pointer.
4610 Otherwise, initializes the filebuf as required. It then
4611 opens a file, if possible, whose name is the NTBS s ("as if"
4612 by calling std::fopen(s,modstr)).
4613 For the second signature, the NTBS s is determined from the
4614 WCBS ws in an implementation-defined manner.
4615 </p>
4616
4617 <p>
4618 (NOTE: For a system that "naturally" represents a filename
4619 as a WCBS, the NTBS s in the first signature may instead
4620 be mapped to a WCBS; if so, it follows the same mapping
4621 rules as the first argument to open.)
4622 </p>
4623 </blockquote>
4624
4625 <p><b>Rationale:</b></p>
4626 <p>
4627 Slightly controversial, but by a 7-1 straw poll the LWG agreed to move
4628 this to Ready.  The controversy was because the mapping between wide
4629 names and files in a filesystem is implementation defined.  The
4630 counterargument, which most but not all LWG members accepted, is that
4631 the mapping between narrow files names and files is also
4632 implemenation defined.</p>
4633 <hr>
4634 <a name="455"><h3>455.&nbsp;cerr::tie() and wcerr::tie() are overspecified</h3></a><p><b>Section:</b>&nbsp;27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
4635 <p>
4636 Both cerr::tie() and wcerr::tie() are obliged to be null at program
4637 startup. This is overspecification and overkill. It is both traditional
4638 and useful to tie cerr to cout, to ensure that standard output is drained
4639 whenever an error message is written. This behavior should at least be
4640 permitted if not required. Same for wcerr::tie().
4641 </p>
4642 <p><b>Proposed resolution:</b></p>
4643
4644 <p>Add to the description of cerr:</p>
4645 <blockquote>
4646 After the object cerr is initialized, cerr.tie() returns &amp;cout.
4647 Its state is otherwise the same as required for basic_ios&lt;char&gt;::init
4648 (lib.basic.ios.cons).
4649 </blockquote>
4650
4651 <p>Add to the description of wcerr:</p>
4652
4653 <blockquote>
4654 After the object wcerr is initialized, wcerr.tie() returns &amp;wcout.
4655 Its state is otherwise the same as required for basic_ios&lt;wchar_t&gt;::init
4656 (lib.basic.ios.cons).
4657 </blockquote>
4658
4659 <p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just
4660   permit, cout and cerr to be tied on startup.  Pre-Redmond: Bill will
4661   provide wording.]</i></p>
4662 <hr>
4663 <a name="456"><h3>456.&nbsp;Traditional C header files are overspecified</h3></a><p><b>Section:</b>&nbsp;17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.headers"> [lib.headers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
4664
4665 <p>The C++ Standard effectively requires that the traditional C headers
4666 (of the form &lt;xxx.h&gt;) be defined in terms of the newer C++
4667 headers (of the form &lt;cxxx&gt;). Clauses 17.4.1.2/4 and D.5 combine
4668 to require that:</p>
4669
4670 <ul>
4671  <li>Including the header &lt;cxxx&gt; declares a C name in namespace std.</li>
4672
4673  <li> Including the header &lt;xxx.h&gt; declares a C name in namespace std
4674     (effectively by including &lt;cxxx&gt;), then imports it into the global
4675     namespace with an individual using declaration.</li>
4676 </ul>
4677
4678 <p>
4679 The rules were left in this form despited repeated and heated objections
4680 from several compiler vendors. The C headers are often beyond the direct
4681 control of C++ implementors. In some organizations, it's all they can do
4682 to get a few #ifdef __cplusplus tests added. Third-party library vendors
4683 can perhaps wrap the C headers. But neither of these approaches supports
4684 the drastic restructuring required by the C++ Standard. As a result, it is
4685 still widespread practice to ignore this conformance requirement, nearly
4686 seven years after the committee last debated this topic. Instead, what is
4687 often implemented is:
4688 </p>
4689
4690 <ul>
4691  <li> Including the header &lt;xxx.h&gt; declares a C name in the
4692  global namespace.</li>
4693
4694  <li> Including the header &lt;cxxx&gt; declares a C name in the
4695  global namespace (effectively by including &lt;xxx.h&gt;), then
4696  imports it into namespace std with an individual using declaration.</li>
4697 </ul>
4698
4699 <p>
4700 The practical benefit for implementors with the second approach is that
4701 they can use existing C library headers, as they are pretty much obliged
4702 to do. The practical cost for programmers facing a mix of implementations
4703 is that they have to assume weaker rules:</p>
4704
4705 <ul>
4706   <li> If you want to assuredly declare a C name in the global
4707   namespace, include &lt;xxx.h&gt;. You may or may not also get the
4708   declaration in namespace std.</li>
4709
4710   <li> If you want to assuredly declare a C name in namespace std,
4711   include &lt;cxxx.h&gt;. You may or may not also get the declaration in
4712   the global namespace.</li>
4713 </ul>
4714
4715 <p>
4716 There also exists the <i>possibility</i> of subtle differences due to
4717 Koenig lookup, but there are so few non-builtin types defined in the C
4718 headers that I've yet to see an example of any real problems in this
4719 area.
4720 </p>
4721
4722 <p>
4723 It is worth observing that the rate at which programmers fall afoul of
4724 these differences has remained small, at least as measured by newsgroup
4725 postings and our own bug reports. (By an overwhelming margin, the
4726 commonest problem is still that programmers include &lt;string&gt; and can't
4727 understand why the typename string isn't defined -- this a decade after
4728 the committee invented namespace std, nominally for the benefit of all
4729 programmers.)
4730 </p>
4731
4732 <p>
4733 We should accept the fact that we made a serious mistake and rectify it,
4734 however belatedly, by explicitly allowing either of the two schemes for
4735 declaring C names in headers.
4736 </p>
4737
4738 <p><i>[Sydney: This issue has been debated many times, and will
4739   certainly have to be discussed in full committee before any action
4740   can be taken.  However, the preliminary sentiment of the LWG was in
4741   favor of the change.  (6 yes, 0 no, 2 abstain) Robert Klarer
4742   suggests that we might also want to undeprecate the
4743   C-style <tt>.h</tt> headers.]</i></p>
4744
4745 <p><b>Proposed resolution:</b></p>
4746 <hr>
4747 <a name="457"><h3>457.&nbsp;bitset constructor: incorrect number of initialized bits</h3></a><p><b>Section:</b>&nbsp;23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Dag Henriksson&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
4748 <p>
4749 The constructor from unsigned long says it initializes "the first M
4750 bit positions to the corresponding bit values in val. M is the smaller
4751 of N and the value CHAR_BIT * sizeof(unsigned long)."
4752 </p>
4753
4754 <p>
4755 Object-representation vs. value-representation strikes again. CHAR_BIT *
4756 sizeof (unsigned long) does not give us the number of bits an unsigned long
4757 uses to hold the value. Thus, the first M bit position above is not
4758 guaranteed to have any corresponding bit values in val.
4759 </p>
4760 <p><b>Proposed resolution:</b></p>
4761 <p>In 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> paragraph 2, change "M is the smaller of
4762   N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
4763   "<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in
4764   the value representation (section 3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/basic.html#basic.types"> [basic.types]</a>) of <tt>unsigned
4765   long</tt>."
4766 </p>
4767 <hr>
4768 <a name="458"><h3>458.&nbsp;24.1.5 contains unintented limitation for operator-</h3></a><p><b>Section:</b>&nbsp;24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Daniel Frey&nbsp; <b>Date:</b>&nbsp;27 Feb 2004</p>
4769 <p>
4770 In 24.1.5 [lib.random.access.iterators], table 76 the operational
4771 semantics for the expression "r -= n" are defined as "return r += -n".
4772 This means, that the expression -n must be valid, which is not the case
4773 for unsigned types.
4774 </p>
4775
4776 <p><i>[
4777 Sydney: Possibly not a real problem, since difference type is required
4778 to be a signed integer type. However, the wording in the standard may
4779 be less clear than we would like.
4780 ]</i></p>
4781
4782 <p><b>Proposed resolution:</b></p>
4783 <p>
4784 To remove this limitation, I suggest to change the
4785 operational semantics for this column to:
4786 </p>
4787 <code>
4788     { Distance m = n;
4789       if (m &gt;= 0)
4790         while (m--) --r;
4791       else
4792         while (m++) ++r;
4793       return r; }
4794 </code>
4795
4796 <hr>
4797 <a name="459"><h3>459.&nbsp;Requirement for widening in stage 2 is overspecification</h3></a><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;16 Mar 2004</p>
4798 <p>When parsing strings of wide-character digits, the standard
4799   requires the library to widen narrow-character "atoms" and compare
4800   the widened atoms against the characters that are being parsed.
4801   Simply narrowing the wide characters would be far simpler, and
4802   probably more efficient.  The two choices are equivalent except in
4803   convoluted test cases, and many implementations already ignore the
4804   standard and use narrow instead of widen.</p>
4805
4806 <p>
4807 First, I disagree that using narrow() instead of widen() would
4808 necessarily have unfortunate performance implications. A possible
4809 implementation of narrow() that allows num_get to be implemented
4810 in a much simpler and arguably comparably efficient way as calling
4811 widen() allows, i.e. without making a virtual call to do_narrow every
4812 time, is as follows:
4813 </p>
4814
4815 <pre>  inline char ctype&lt;wchar_t&gt;::narrow (wchar_t wc, char dflt) const
4816   {
4817       const unsigned wi = unsigned (wc);
4818
4819       if (wi &gt; UCHAR_MAX)
4820           return typeid (*this) == typeid (ctype&lt;wchar_t&gt;) ?
4821                  dflt : do_narrow (wc, dflt);
4822
4823       if (narrow_ [wi] &lt; 0) {
4824          const char nc = do_narrow (wc, dflt);
4825          if (nc == dflt)
4826              return dflt;
4827          narrow_ [wi] = nc;
4828       }
4829
4830       return char (narrow_ [wi]);
4831   }
4832 </pre>
4833
4834 <p>
4835 Second, I don't think the change proposed in the issue (i.e., to use
4836 narrow() instead of widen() during Stage 2) would be at all
4837 drastic. Existing implementations with the exception of libstdc++
4838 currently already use narrow() so the impact of the change on programs
4839 would presumably be isolated to just a single implementation. Further,
4840 since narrow() is not required to translate alternate wide digit
4841 representations such as those mentioned in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-defects.html#303">303</a> to
4842 their narrow equivalents (i.e., the portable source characters '0'
4843 through '9'), the change does not necessarily imply that these
4844 alternate digits would be treated as ordinary digits and accepted as
4845 part of numbers during parsing. In fact, the requirement in 22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>, p13 forbids narrow() to translate an alternate
4846 digit character, wc, to an ordinary digit in the basic source
4847 character set unless the expression
4848 (ctype&lt;charT&gt;::is(ctype_base::digit, wc) == true) holds. This in
4849 turn is prohibited by the C standard (7.25.2.1.5, 7.25.2.1.5, and
4850 5.2.1, respectively) for charT of either char or wchar_t.
4851 </p>
4852
4853 <p><i>[Sydney: To a large extent this is a nonproblem. As long as
4854 you're only trafficking in char and wchar_t we're only dealing with a
4855 stable character set, so you don't really need either 'widen' or
4856 'narrow': can just use literals. Finally, it's not even clear whether
4857 widen-vs-narrow is the right question; arguably we should be using
4858 codecvt instead.]</i></p>
4859
4860 <p><b>Proposed resolution:</b></p>
4861 <p>Change stage 2 so that implementations are permitted to use either
4862 technique to perform the comparison:</p>
4863 <ol>
4864   <li> call widen on the atoms and compare (either by using
4865       operator== or char_traits&lt;charT&gt;::eq) the input with
4866       the widened atoms, or</li>
4867   <li> call narrow on the input and compare the narrow input
4868       with the atoms</li>
4869   <li> do (1) or (2) only if charT is not char or wchar_t,
4870       respectively; i.e., avoid calling widen or narrow
4871       if it the source and destination types are the same</li>
4872 </ol>
4873 <hr>
4874 <a name="460"><h3>460.&nbsp;Default modes missing from basic_fstream member specifications</h3></a><p><b>Section:</b>&nbsp;27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Ben Hutchings&nbsp; <b>Date:</b>&nbsp;1 Apr 2004</p>
4875 <p>
4876 The second parameters of the non-default constructor and of the open
4877 member function for basic_fstream, named "mode", are optional
4878 according to the class declaration in 27.8.1.11 [lib.fstream].  The
4879 specifications of these members in 27.8.1.12 [lib.fstream.cons] and
4880 27.8.1.13 lib.fstream.members] disagree with this, though the
4881 constructor declaration has the "explicit" function-specifier implying
4882 that it is intended to be callable with one argument.
4883 </p>
4884 <p><b>Proposed resolution:</b></p>
4885 <p>In 27.8.1.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.fstream.cons"> [lib.fstream.cons]</a>, change</p>
4886 <pre>  explicit basic_fstream(const char* s, ios_base::openmode mode);
4887 </pre>
4888 <p>to</p>
4889 <pre>  explicit basic_fstream(const char* s,
4890                          ios_base::openmode mode = ios_base::in|ios_base::out);
4891 </pre>
4892 <p>In 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a>, change</p>
4893 <pre>  void open(const char*s, ios_base::openmode mode);
4894 </pre>
4895 <p>to</p>
4896   void open(const char*s,
4897             ios_base::openmode mode = ios_base::in|ios_base::out);
4898 <hr>
4899 <a name="461"><h3>461.&nbsp;time_get hard or impossible to implement</h3></a><p><b>Section:</b>&nbsp;22.2.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;23 Mar 2004</p>
4900 <p>
4901 Template time_get currently contains difficult, if not impossible,
4902 requirements for do_date_order, do_get_time, and do_get_date. All require
4903 the implementation to scan a field generated by the %x or %X conversion
4904 specifier in strftime. Yes, do_date_order can always return no_order, but
4905 that doesn't help the other functions. The problem is that %x can be
4906 nearly anything, and it can vary widely with locales. It's horribly
4907 onerous to have to parse "third sunday after Michaelmas in the year of
4908 our Lord two thousand and three," but that's what we currently ask of
4909 do_get_date. More practically, it leads some people to think that if
4910 %x produces 10.2.04, we should know to look for dots as separators. Still
4911 not easy.
4912 </p>
4913
4914 <p>
4915 Note that this is the <i>opposite</i> effect from the intent stated in the
4916 footnote earlier in this subclause:
4917 </p>
4918
4919 <blockquote>
4920 "In other words, user confirmation is required for reliable parsing of
4921 user-entered dates and times, but machine-generated formats can be
4922 parsed reliably. This allows parsers to be aggressive about interpreting
4923 user variations on standard formats."
4924 </blockquote>
4925
4926 <p>
4927 We should give both implementers and users an easier and more reliable
4928 alternative: provide a (short) list of alternative delimiters and say
4929 what the default date order is for no_order. For backward compatibility,
4930 and maximum latitude, we can permit an implementation to parse whatever
4931 %x or %X generates, but we shouldn't require it.
4932 </p>
4933 <p><b>Proposed resolution:</b></p>
4934
4935 <p><b>In the description:</b></p>
4936 <pre>iter_type do_get_time(iter_type s, iter_type end, ios_base&amp; str,
4937         ios_base::iostate&amp; err, tm* t) const;
4938 </pre>
4939
4940 <p>
4941 2 Effects: Reads characters starting at suntil it has extracted those
4942 struct tm members, and remaining format characters, used by
4943 time_put&lt;&gt;::put to produce the format specified by 'X', or until it
4944 encounters an error or end of sequence.
4945 </p>
4946
4947 <p><b>change:</b> 'X'</p>
4948
4949 <p><b>to:</b> "%H:%M:%S"</p>
4950
4951
4952 <p><b>In the description:</b></p>
4953 <pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
4954         ios_base::iostate&amp; err, tm* t) const;
4955 </pre>
4956 <p>
4957 4 Effects: Reads characters starting at suntil it has extracted those
4958 struct tm members, and remaining format characters, used by
4959 time_put&lt;&gt;::put to produce the format specified by 'x', or until it
4960 encounters an error.
4961 </p>
4962
4963 <p>
4964 <b>change:</b> used by time_put&lt;&gt;::put to produce the format
4965 specified by 'x', or until it encounters an error.
4966 </p>
4967
4968 <p><b>to:</b> used by time_put&lt;&gt;:: put to produce one of the
4969 following formats, or until it encounters an error. The format depends
4970 on the value returned by date_order() as follows:
4971 </p>
4972 <pre>        date_order()  format
4973
4974         no_order      "%m/%d/%y"
4975         dmy           "%d/%m/%y"
4976         mdy           "%m/%d/%y"
4977         ymd           "%y/%m/%d"
4978         ydm           "%y/%d/%m"
4979 </pre>
4980
4981 <p><i>[Redmond: agreed that this is a real problem.  The solution is
4982   probably to match C99's parsing rules.  Bill provided wording.
4983 ]</i></p>
4984
4985 <hr>
4986 <a name="462"><h3>462.&nbsp;Destroying objects with static storage duration</h3></a><p><b>Section:</b>&nbsp;3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/basic.html#basic.start.term"> [basic.start.term]</a>, 18.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.support.start.term"> [lib.support.start.term]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;23 Mar 2004</p>
4987 <p>
4988 3.6.3 Termination spells out in detail the interleaving of static
4989 destructor calls and calls to functions registered with atexit. To
4990 match this behavior requires intimate cooperation between the code
4991 that calls destructors and the exit/atexit machinery. The former
4992 is tied tightly to the compiler; the latter is a primitive mechanism
4993 inherited from C that traditionally has nothing to do with static
4994 construction and destruction. The benefits of intermixing destructor
4995 calls with atexit handler calls is questionable at best, and <i>very</i>
4996 difficult to get right, particularly when mixing third-party C++
4997 libraries with different third-party C++ compilers and C libraries
4998 supplied by still other parties.
4999 </p>
5000
5001 <p>
5002 I believe the right thing to do is defer all static destruction
5003 until after all atexit handlers are called. This is a change in
5004 behavior, but one that is likely visible only to perverse test
5005 suites. At the very least, we should <i>permit</i> deferred destruction
5006 even if we don't require it.
5007 </p>
5008 <p><b>Proposed resolution:</b></p>
5009
5010 <p><i>[If this is to be changed, it should probably be changed by CWG.
5011   At this point, however, the LWG is leaning toward NAD.  Implementing
5012   what the standard says is hard work, but it's not impossible and
5013   most vendors went through that pain years ago.  Changing this
5014   behavior would be a user-visible change, and would break at least
5015   one real application.]</i></p>
5016
5017 <p>
5018 </p>
5019 <hr>
5020 <a name="463"><h3>463.&nbsp;auto_ptr usability issues</h3></a><p><b>Section:</b>&nbsp;20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Rani Sharoni&nbsp; <b>Date:</b>&nbsp;7 Dec 2003</p>
5021
5022 <p>
5023 TC1 CWG DR #84 effectively made the template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;()
5024 member of auto_ptr (20.4.5.3/4) obsolete.
5025 </p>
5026
5027 <p>
5028 The sole purpose of this obsolete conversion member is to enable copy
5029 initialization base from r-value derived (or any convertible types like
5030 cv-types) case:
5031 </p>
5032 <pre>#include &lt;memory&gt;
5033 using std::auto_ptr;
5034
5035 struct B {};
5036 struct D : B {};
5037
5038 auto_ptr&lt;D&gt; source();
5039 int sink(auto_ptr&lt;B&gt;);
5040 int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
5041 </pre>
5042
5043 <p>
5044 The excellent analysis of conversion operations that was given in the final
5045 auto_ptr proposal
5046 (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
5047 explicitly specifies this case analysis (case 4). DR #84 makes the analysis
5048 wrong and actually comes to forbid the loophole that was exploited by the
5049 auto_ptr designers.
5050 </p>
5051
5052 <p>
5053 I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
5054 ever allowed this case. This is probably because it requires 3 user defined
5055 conversions and in fact current compilers conform to DR #84.
5056 </p>
5057
5058 <p>
5059 I was surprised to discover that the obsolete conversion member actually has
5060 negative impact of the copy initialization base from l-value derived
5061 case:</p>
5062 <pre>auto_ptr&lt;D&gt; dp;
5063 int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
5064 </pre>
5065
5066 <p>
5067 I'm sure that the original intention was allowing this initialization using
5068 the template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;&amp; a) constructor (20.4.5.1/4) but
5069 since in this copy initialization it's merely user defined conversion (UDC)
5070 and the obsolete conversion member is UDC with the same rank (for the early
5071 overloading stage) there is an ambiguity between them.
5072 </p>
5073
5074 <p>
5075 Removing the obsolete member will have impact on code that explicitly
5076 invokes it:
5077 </p>
5078 <pre>int y = sink(source().operator auto_ptr&lt;B&gt;());
5079 </pre>
5080
5081 <p>
5082 IMHO no one ever wrote such awkward code and the reasonable workaround for
5083 #1 is:
5084 </p>
5085 <pre>int y = sink( auto_ptr&lt;B&gt;(source()) );
5086 </pre>
5087
5088 <p>
5089 I was even more surprised to find out that after removing the obsolete
5090 conversion member the initialization was still ill-formed:
5091 int x3 = sink(dp); // #3 EDG - no suitable copy constructor
5092 </p>
5093
5094 <p>
5095 This copy initialization semantically requires copy constructor which means
5096 that both template conversion constructor and the auto_ptr_ref conversion
5097 member (20.4.5.3/3) are required which is what was explicitly forbidden in
5098 DR #84. This is a bit amusing case in which removing ambiguity results with
5099 no candidates.
5100 </p>
5101
5102 <p>
5103 I also found exception safety issue with auto_ptr related to auto_ptr_ref:
5104 </p>
5105 <pre>int f(auto_ptr&lt;B&gt;, std::string);
5106 auto_ptr&lt;B&gt; source2();
5107
5108 // string constructor throws while auto_ptr_ref
5109 // "holds" the pointer
5110 int x4 = f(source2(), "xyz"); // #4
5111 </pre>
5112
5113 <p>
5114 The theoretic execution sequence that will cause a leak:
5115 </p>
5116 <ol>
5117 <li>call auto_ptr&lt;B&gt;::operator auto_ptr_ref&lt;B&gt;()</li>
5118 <li>call string::string(char const*) and throw</li>
5119 </ol>
5120
5121 <p>
5122 According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
5123 returns auto_ptr_ref&lt;Y&gt; that holds *this and this is another defect since
5124 the type of *this is auto_ptr&lt;X&gt; where X might be different from Y. Several
5125 library vendors (e.g. SGI) implement auto_ptr_ref&lt;Y&gt; with Y* as member which
5126 is much more reasonable. Other vendor implemented auto_ptr_ref as
5127 defectively required and it results with awkward and catastrophic code:
5128 int oops = sink(auto_ptr&lt;B&gt;(source())); // warning recursive on all control
5129 paths
5130 </p>
5131
5132 <p>
5133 Dave Abrahams noticed that there is no specification saying that
5134 auto_ptr_ref copy constructor can't throw.
5135 </p>
5136
5137 <p>
5138 My proposal comes to solve all the above issues and significantly simplify
5139 auto_ptr implementation. One of the fundamental requirements from auto_ptr
5140 is that it can be constructed in an intuitive manner (i.e. like ordinary
5141 pointers) but with strict ownership semantics which yield that source
5142 auto_ptr in initialization must be non-const. My idea is to add additional
5143 constructor template with sole propose to generate ill-formed, diagnostic
5144 required, instance for const auto_ptr arguments during instantiation of
5145 declaration. This special constructor will not be instantiated for other
5146 types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
5147 in hand makes the constructor template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;)
5148 legitimate since the actual argument can't be const yet non const r-value
5149 are acceptable.
5150 </p>
5151
5152 <p>
5153 This implementation technique makes the "private auxiliary class"
5154 auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
5155 GCC and VC) consume the new implementation as expected and allow all
5156 intuitive initialization and assignment cases while rejecting illegal cases
5157 that involve const auto_ptr arguments.
5158 </p>
5159
5160 <p>The proposed auto_ptr interface:</p>
5161
5162 <pre>namespace std {
5163     template&lt;class X&gt; class auto_ptr {
5164     public:
5165         typedef X element_type;
5166
5167         // 20.4.5.1 construct/copy/destroy:
5168         explicit auto_ptr(X* p=0) throw();
5169         auto_ptr(auto_ptr&amp;) throw();
5170         template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;) throw();
5171         auto_ptr&amp; operator=(auto_ptr&amp;) throw();
5172         template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;) throw();
5173         ~auto_ptr() throw();
5174
5175         // 20.4.5.2 members:
5176         X&amp; operator*() const throw();
5177         X* operator-&gt;() const throw();
5178         X* get() const throw();
5179         X* release() throw();
5180         void reset(X* p=0) throw();
5181
5182     private:
5183         template&lt;class U&gt;
5184         auto_ptr(U&amp; rhs, typename
5185 unspecified_error_on_const_auto_ptr&lt;U&gt;::type = 0);
5186     };
5187 }
5188 </pre>
5189
5190 <p>
5191 One compliant technique to implement the unspecified_error_on_const_auto_ptr
5192 helper class is using additional private auto_ptr member class template like
5193 the following:
5194 </p>
5195 <pre>template&lt;typename T&gt; struct unspecified_error_on_const_auto_ptr;
5196
5197 template&lt;typename T&gt;
5198 struct unspecified_error_on_const_auto_ptr&lt;auto_ptr&lt;T&gt; const&gt;
5199 { typedef typename auto_ptr&lt;T&gt;::const_auto_ptr_is_not_allowed type; };
5200 </pre>
5201
5202 <p>
5203 There are other techniques to implement this helper class that might work
5204 better for different compliers (i.e. better diagnostics) and therefore I
5205 suggest defining its semantic behavior without mandating any specific
5206 implementation. IMO, and I didn't found any compiler that thinks otherwise,
5207 14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
5208 verifying this with core language experts.
5209 </p>
5210
5211 <p><b>Further changes in standard text:</b></p>
5212 <p>Remove section 20.4.5.3</p>
5213
5214 <p>Change 20.4.5/2 to read something like:
5215 Initializing auto_ptr&lt;X&gt; from const auto_ptr&lt;Y&gt; will result with unspecified
5216 ill-formed declaration that will require unspecified diagnostic.</p>
5217
5218 <p>Change 20.4.5.1/4,5,6 to read:</p>
5219
5220 <pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp; a) throw();</pre>
5221 <p> 4 Requires: Y* can be implicitly converted to X*.</p>
5222 <p> 5 Effects: Calls const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(a).release().</p>
5223 <p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
5224
5225 <p>Change 20.4.5.1/10</p>
5226 <pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt; a) throw();
5227 </pre>
5228 <p>
5229 10 Requires: Y* can be implicitly converted to X*. The expression delete
5230 get() is well formed.
5231 </p>
5232
5233 <p>LWG TC DR #127 is obsolete.</p>
5234
5235 <p>
5236 Notice that the copy constructor and copy assignment operator should remain
5237 as before and accept non-const auto_ptr&amp; since they have effect on the form
5238 of the implicitly declared copy constructor and copy assignment operator of
5239 class that contains auto_ptr as member per 12.8/5,10:
5240 </p>
5241 <pre>struct X {
5242     // implicit X(X&amp;)
5243     // implicit X&amp; operator=(X&amp;)
5244     auto_ptr&lt;D&gt; aptr_;
5245 };
5246 </pre>
5247
5248 <p>
5249 In most cases this indicates about sloppy programming but preserves the
5250 current auto_ptr behavior.
5251 </p>
5252
5253 <p>
5254 Dave Abrahams encouraged me to suggest fallback implementation in case that
5255 my suggestion that involves removing of auto_ptr_ref will not be accepted.
5256 In this case removing the obsolete conversion member to auto_ptr&lt;Y&gt; and
5257 20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
5258 cases. The two constructors that I suggested will co exist with the current
5259 members but will make auto_ptr_ref obsolete in initialization contexts.
5260 auto_ptr_ref will be effective in assignment contexts as suggested in DR
5261 #127 and I can't see any serious exception safety issues in those cases
5262 (although it's possible to synthesize such). auto_ptr_ref&lt;X&gt; semantics will
5263 have to be revised to say that it strictly holds pointer of type X and not
5264 reference to an auto_ptr for the favor of cases in which auto_ptr_ref&lt;Y&gt; is
5265 constructed from auto_ptr&lt;X&gt; in which X is different from Y (i.e. assignment
5266 from r-value derived to base).
5267 </p>
5268
5269 <p><b>Proposed resolution:</b></p>
5270 <p><i>[Redmond: punt for the moment. We haven't decided yet whether we
5271   want to fix auto_ptr for C++-0x, or remove it and replace it with
5272   move_ptr and unique_ptr.]</i></p>
5273 <hr>
5274 <a name="464"><h3>464.&nbsp;Suggestion for new member functions in standard containers</h3></a><p><b>Section:</b>&nbsp;23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.vector"> [lib.vector]</a>, 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.map"> [lib.map]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Thorsten Ottosen&nbsp; <b>Date:</b>&nbsp;12 May 2004</p>
5275
5276 <p>To add slightly more convenience to vector&lt;T&gt; and map&lt;Key,T&gt; we should consider to add</p>
5277 <ol>
5278 <li> add vector&lt;T&gt;::data() member (const and non-const version)
5279 semantics: if( empty() ) return 0; else return buffer_;</li>
5280 <li> add map&lt;Key,T&gt;::at( const Key&amp; k ) member (const and non-const version)
5281 <i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
5282 </ol>
5283
5284 <p>Rationale:</p>
5285
5286 <ul>
5287 <li>To obtain a pointer to the vector's buffer, one must use either
5288 operator[]() (which can give undefined behavior for empty vectors) or
5289 at() (which will then throw if the vector is empty). </li>
5290 <li>tr1::array&lt;T,sz&gt; already has a data() member</li>
5291 <li>e cannot use operator[]() when T is not DefaultDonstructible</li>
5292 <li>Neither when the map is const.</li>
5293 <li>when we want to make sure we don't add an element accidently</li>
5294 <li>when it should be considered an error if a key is not in the map</li>
5295 </ul>
5296
5297 <p><b>Proposed resolution:</b></p>
5298 <p>In 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.vector"> [lib.vector]</a>, add the following to the <tt>vector</tt>
5299   synopsis after "element access" and before "modifiers":</p>
5300 <pre>  // <i>[lib.vector.data] data access</i>
5301   pointer       data();
5302   const_pointer data() const;
5303 </pre>
5304
5305 <p>Add a new subsection of 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.vector"> [lib.vector]</a>:</p>
5306 <blockquote>
5307 <p>23.2.4.x <tt>vector</tt> data access</p>
5308 <pre>   pointer       data();
5309    const_pointer data() const;
5310 </pre>
5311 <p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
5312    range that contains the same elements as [begin(), end()).</p>
5313 <p><b>Complexity:</b> Constant time.</p>
5314 <p><b>Throws:</b> Nothing.</p>
5315 </blockquote>
5316
5317 <p>In 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.map"> [lib.map]</a>, add the following to the <tt>map</tt>
5318 synopsis immediately after the line for operator[]:</p>
5319 <pre>  T&amp;       at(const key_type&amp; x);
5320   const T&amp; at(const key_type&amp; x) const;
5321 </pre>
5322
5323 <p>Add the following to 23.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.map.access"> [lib.map.access]</a>:</p>
5324 <blockquote>
5325 <pre>  T&amp;       at(const key_type&amp; x);
5326   const T&amp; at(const key_type&amp; x) const;
5327 </pre>
5328
5329 <p><b>Returns:</b> A reference to the element whose key is equivalent
5330   to x, if such an element is present in the map.</p>
5331 <p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
5332
5333 </blockquote>
5334
5335 <p><b>Rationale:</b></p>
5336 <p>Neither of these additions provides any new functionality but the
5337   LWG agreed that they are convenient, especially for novices.  The
5338   exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
5339   was chosen to match <tt>vector::at</tt>.</p>
5340 <hr>
5341 <a name="465"><h3>465.&nbsp;Contents of &lt;ciso646&gt;</h3></a><p><b>Section:</b>&nbsp;17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.headers"> [lib.headers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;3 Jun 2004</p>
5342 <p>C header &lt;iso646.h&gt; defines macros for some operators, such as
5343 not_eq for !=.</p>
5344
5345 <p>Section 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-intro.html#lib.headers"> [lib.headers]</a> "Headers" says that except as noted in
5346 clauses 18 through 27, the &lt;cname&gt; C++ header contents are the same
5347 as the C header &lt;name.h&gt;. In particular, table 12 lists
5348 &lt;ciso646&gt; as a C++ header.</p>
5349
5350 <p>I don't find any other mention of &lt;ciso646&gt;, or any mention of
5351 &lt;iso646.h&gt;, in clauses 17 thorough 27. That implies that the
5352 contents of &lt;ciso646&gt; are the same as C header &lt;iso646.h&gt;.</p>
5353
5354 <p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
5355 "Header &lt;iso646.h&gt;" says that the alternative tokens are not
5356 defined as macros in &lt;ciso646&gt;, but does not mention the contents
5357 of &lt;iso646.h&gt;.</p>
5358
5359 <p>I don't find any normative text to support C.2.2.2.</p>
5360
5361 <p><b>Proposed resolution:</b></p>
5362 <p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
5363   paragraph 6 (the one about functions must be functions):</p>
5364
5365 <blockquote>
5366 <p>Identifiers that are keywords or operators in C++ shall not be defined
5367 as macros in C++ standard library headers.
5368 [Footnote:In particular, including the standard header &lt;iso646.h&gt;
5369 or &lt;ciso646&gt; has no effect. </p>
5370 </blockquote>
5371
5372 <p><i>[post-Redmond: Steve provided wording.]</i></p>
5373
5374 <hr>
5375 <a name="466"><h3>466.&nbsp;basic_string ctor should prevent null pointer error</h3></a><p><b>Section:</b>&nbsp;21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Daniel Frey&nbsp; <b>Date:</b>&nbsp;10 Jun 2004</p>
5376 <p>
5377 Today, my colleagues and me wasted a lot of time. After some time, I
5378 found the problem. It could be reduced to the following short example:
5379 </p>
5380
5381 <pre>  #include &lt;string&gt;
5382   int main() { std::string( 0 ); }
5383 </pre>
5384
5385 <p>The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and
5386 Comeau online) compile the above without errors or warnings! The
5387 programs (at least for the GCC) resulted in a SEGV.</p>
5388
5389 <p>I know that the standard explicitly states that the ctor of string
5390 requires a char* which is not zero. STLs could easily detect the above
5391 case with a private ctor for basic_string which takes a single 'int'
5392 argument. This would catch the above code at compile time and would not
5393 ambiguate any other legal ctors.</p>
5394
5395 <p><b>Proposed resolution:</b></p>
5396 <p><i>[Redmond: No great enthusiasm for doing this.  If we do,
5397   however, we want to do it for all places that take <tt>charT*</tt>
5398   pointers, not just the single-argument constructor.  The other
5399   question is whether we want to catch this at compile time (in which
5400   case we catch the error of a literal 0, but not an expression whose
5401   value is a null pointer), at run time, or both.]</i></p>
5402
5403 <hr>
5404 <a name="467"><h3>467.&nbsp;char_traits::lt(), compare(), and memcmp()</h3></a><p><b>Section:</b>&nbsp;21.1.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-strings.html#lib.char.traits.specializations.char"> [lib.char.traits.specializations.char]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
5405
5406 <p>
5407 Table 37 describes the requirements on Traits::compare() in terms of
5408 those on Traits::lt(). 21.1.3.1, p6 requires char_traits&lt;char&gt;::lt()
5409 to yield the same result as operator&lt;(char, char).
5410 </p>
5411
5412 <p>
5413 Most, if not all, implementations of char_traits&lt;char&gt;::compare()
5414 call memcmp() for efficiency. However, the C standard requires both
5415 memcmp() and strcmp() to interpret characters under comparison as
5416 unsigned, regardless of the signedness of char. As a result, all
5417 these char_traits implementations fail to meet the requirement
5418 imposed by Table 37 on compare() when char is signed.
5419 </p>
5420
5421
5422 <p>Read email thread starting with c++std-lib-13499 for more. </p>
5423 <p><b>Proposed resolution:</b></p>
5424
5425
5426 <p>Change 21.1.3.1, p6 from</p>
5427 <blockquote>
5428     The two-argument members assign, eq, and lt are defined identically
5429     to the built-in operators =, ==, and &lt; respectively.
5430 </blockquote>
5431 <p>to</p>
5432 <blockquote>
5433   The two-argument member assign is defined identically to
5434   the built-in operators = and == respectively. The two
5435   argument members eq and lt are defined identically to
5436   the built-in operators == and &lt; for type unsigned char.
5437 </blockquote>
5438
5439 <p><i>[Redmond: The LWG agreed with this general direction, but we
5440   also need to change <tt>eq</tt> to be consistent with this change.
5441   Post-Redmond: Martin provided wording.]</i></p>
5442
5443 <hr>
5444 <a name="468"><h3>468.&nbsp;unexpected consequences of ios_base::operator void*()</h3></a><p><b>Section:</b>&nbsp;27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
5445
5446 <p>The program below is required to compile but when run it typically
5447 produces unexpected results due to the user-defined conversion from
5448 std::cout or any object derived from basic_ios to void*.
5449 </p>
5450
5451 <pre>    #include &lt;cassert&gt;
5452     #include &lt;iostream&gt;
5453
5454     int main ()
5455     {
5456         assert (std::cin.tie () == std::cout);
5457         // calls std::cout.ios::operator void*()
5458     }
5459 </pre>
5460
5461 <p><b>Proposed resolution:</b></p>
5462
5463 <p>
5464 Replace std::basic_ios&lt;charT, traits&gt;::operator void*() with another
5465 conversion operator to some unspecified type that is guaranteed not
5466 to be convertible to any other type except for bool (a pointer-to-member
5467 might be one such suitable type). In addition, make it clear that the
5468 pointer type need not be a pointer to a complete type and when non-null,
5469 the value need not be valid.
5470 </p>
5471
5472 <p>Specifically, change in [lib.ios] the signature of</p>
5473 <pre>    operator void*() const;
5474 </pre>
5475 <p>to</p>
5476 <pre>    operator unspecified_pointer_type () const;
5477 </pre>
5478 <p>and change [lib.iostate.flags], p1 from</p>
5479 <pre>    operator void*() const;
5480 </pre>
5481 <p>to</p>
5482 <pre>    operator unspecified_pointer_type() const;
5483     -1- Returns: If fail() then a null pointer; otherwise some
5484         non-null but not necessarily valid pointer to indicate
5485         success.
5486     -2- Note: The type named unspecified_pointer_type above is a pointer
5487         to some unspecified, possibly incomplete type, that is guaranteed
5488         not to be convertible to any other type except bool.(Footnote 1)
5489         --
5490         Footnote 1: A pointer-to-member might be one such suitable type.
5491 </pre>
5492
5493 <p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
5494
5495 <hr>
5496 <a name="469"><h3>469.&nbsp;vector&lt;bool&gt; ill-formed relational operators</h3></a><p><b>Section:</b>&nbsp;23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
5497
5498 <p>
5499 The overloads of relational operators for vector&lt;bool&gt; specified
5500 in [lib.vector.bool] are redundant (they are semantically identical
5501 to those provided for the vector primary template) and may even be
5502 diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation
5503 in c++std-lib-13647).
5504 </p>
5505
5506 <p><b>Proposed resolution:</b></p>
5507 <p>
5508 Remove all overloads of overloads of relational operators for
5509 vector&lt;bool&gt; from [lib.vector.bool].
5510 </p>
5511 <hr>
5512 <a name="470"><h3>470.&nbsp;accessing containers from their elements' special functions</h3></a><p><b>Section:</b>&nbsp;23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.containers"> [lib.containers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
5513
5514 <p>
5515 The standard doesn't prohibit the destructors (or any other special
5516 functions) of containers' elements invoked from a member function
5517 of the container from "recursively" calling the same (or any other)
5518 member function on the same container object, potentially while the
5519 container is in an intermediate state, or even changing the state
5520 of the container object while it is being modified. This may result
5521 in some surprising (i.e., undefined) behavior.
5522 </p>
5523
5524 <p>Read email thread starting with c++std-lib-13637 for more.</p>
5525
5526 <p><b>Proposed resolution:</b></p>
5527
5528 <p>Add to Container Requirements the following new paragraph:</p>
5529
5530 <pre>    Unless otherwise specified, the behavior of a program that
5531     invokes a container member function f from a member function
5532     g of the container's value_type on a container object c that
5533     called g from its mutating member function h, is undefined.
5534     I.e., if v is an element of c, directly or indirectly calling
5535     c.h() from v.g() called from c.f(), is undefined.
5536 </pre>
5537
5538 <p><i>[Redmond: This is a real issue, but it's probably a clause 17
5539   issue, not clause 23.  We get the same issue, for example, if we
5540   try to destroy a stream from one of the stream's callback functions.]</i></p>
5541
5542
5543 <hr>
5544 <a name="471"><h3>471.&nbsp;result of what() implementation-defined</h3></a><p><b>Section:</b>&nbsp;18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-support.html#lib.exception"> [lib.exception]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
5545
5546 <p>[lib.exception] specifies the following:</p>
5547 <pre>    exception (const exception&amp;) throw();
5548     exception&amp; operator= (const exception&amp;) throw();
5549
5550     -4- Effects: Copies an exception object.
5551     -5- Notes: The effects of calling what() after assignment
5552         are implementation-defined.
5553 </pre>
5554
5555 <p>
5556 First, does the Note only apply to the assignment operator? If so,
5557 what are the effects of calling what() on a copy of an object? Is
5558 the returned pointer supposed to point to an identical copy of
5559 the NTBS returned by what() called on the original object or not?
5560 </p>
5561
5562 <p>
5563 Second, is this Note intended to extend to all the derived classes
5564 in section 19? I.e., does the standard provide any guarantee for
5565 the effects of what() called on a copy of any of the derived class
5566 described in section 19?
5567 </p>
5568
5569 <p>
5570 Finally, if the answer to the first question is no, I believe it
5571 constitutes a defect since throwing an exception object typically
5572 implies invoking the copy ctor on the object. If the answer is yes,
5573 then I believe the standard ought to be clarified to spell out
5574 exactly what the effects are on the copy (i.e., after the copy
5575 ctor was called).
5576 </p>
5577
5578 <p><i>[Redmond: Yes, this is fuzzy.  The issue of derived classes is
5579   fuzzy too.]</i></p>
5580
5581 <p><b>Proposed resolution:</b></p>
5582 <hr>
5583 <a name="472"><h3>472.&nbsp;Missing "Returns" clause in std::equal_range</h3></a><p><b>Section:</b>&nbsp;25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Prateek R Karandikar&nbsp; <b>Date:</b>&nbsp;29 Feb 1900</p>
5584 <p>
5585 There is no "Returns:" clause for std::equal_range, which returns non-void.
5586 </p>
5587 <p><b>Proposed resolution:</b></p>
5588 <p>In 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>, change</p>
5589 <blockquote>
5590   <b>Effects:</b> Finds the largest subrange [i, j)...
5591 </blockquote>
5592 <p>to</p>
5593 <blockquote>
5594   <b>Returns:</b> The largest subrange [i, j)...
5595 </blockquote>
5596 <hr>
5597 <a name="473"><h3>473.&nbsp;underspecified ctype calls</h3></a><p><b>Section:</b>&nbsp;22.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-locales.html#lib.locale.ctype"> [lib.locale.ctype]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;1 Jul 2004</p>
5598 <p>
5599 Most ctype member functions come in two forms: one that operates
5600 on a single character at a time and another form that operates
5601 on a range of characters. Both forms are typically described by
5602 a single Effects and/or Returns clause.
5603 </p>
5604 <p>
5605 The Returns clause of each of the single-character non-virtual forms
5606 suggests that the function calls the corresponding single character
5607 virtual function, and that the array form calls the corresponding
5608 virtual array form. Neither of the two forms of each virtual member
5609 function is required to be implemented in terms of the other.
5610 </p>
5611 <p>
5612 There are three problems:
5613 </p>
5614 <p>
5615 1. One is that while the standard does suggest that each non-virtual
5616 member function calls the corresponding form of the virtual function,
5617 it doesn't actually explicitly require it.
5618 </p>
5619 <p>
5620 Implementations that cache results from some of the virtual member
5621 functions for some or all values of their arguments might want to
5622 call the array form from the non-array form the first time to fill
5623 the cache and avoid any or most subsequent virtual calls. Programs
5624 that rely on each form of the virtual function being called from
5625 the corresponding non-virtual function will see unexpected behavior
5626 when using such implementations.
5627 </p>
5628 <p>
5629 2. The second problem is that either form of each of the virtual
5630 functions can be overridden by a user-defined function in a derived
5631 class to return a value that is different from the one produced by
5632 the virtual function of the alternate form that has not been
5633 overriden.
5634 </p>
5635 <p>
5636 Thus, it might be possible for, say, ctype::widen(c) to return one
5637 value, while for ctype::widen(&amp;c, &amp;c + 1, &amp;wc) to set
5638 wc to another value. This is almost certainly not intended. Both
5639 forms of every function should be required to return the same result
5640 for the same character, otherwise the same program using an
5641 implementation that calls one form of the functions will behave
5642 differently than when using another implementation that calls the
5643 other form of the function "under the hood."
5644 </p>
5645 <p>
5646 3. The last problem is that the standard text fails to specify whether
5647 one form of any of the virtual functions is permitted to be implemented
5648 in terms of the other form or not, and if so, whether it is required
5649 or permitted to call the overridden virtual function or not.
5650 </p>
5651 <p>
5652 Thus, a program that overrides one of the virtual functions so that
5653 it calls the other form which then calls the base member might end
5654 up in an infinite loop if the called form of the base implementation
5655 of the function in turn calls the other form.
5656 </p>
5657 <p><b>Proposed resolution:</b></p>
5658 <p>
5659 To fix these problems I propose the following:
5660 </p>
5661 <p>
5662 Add two paragraphs immediately after 22.2.1.1 [lib.locale.ctype],
5663 p2, with the following text:
5664 </p>
5665
5666 <pre>  -3- Each ctype non-virtual member function that comes in two forms,
5667       one that takes a range of elements of char_type, and another
5668       that takes just a single element of char_type, is required to
5669       call the corresponding form of the virtual member function
5670       with the same value of char_type to obtain the result. The
5671       result for the same argument may be cached and returned from
5672       subsequent calls to either form of the non-virtual member
5673       function with that argument.
5674
5675   -4- For each ctype virtual member function that comes in two forms
5676       (as explained above), the single element form is required to
5677       produce the same result for a character c that the corresponding
5678       array form produces for the array element with the same value as
5679       c, and vice versa.
5680
5681   -5- It is unspecified whether the array form of each virtual member
5682       function calls the single-element virtual overload of the same
5683       function in a loop, or whether the single element form calls
5684       the array form with an array of a single element with the value
5685       of its argument, or whether neither form calls the other. In
5686       any case, an implementation is not permitted to make calls from
5687       one form of any virtual member function to the corresponding
5688       other form that is overridden in a derived class.
5689 </pre>
5690
5691 <hr>
5692 <a name="474"><h3>474.&nbsp;confusing Footnote 297</h3></a><p><b>Section:</b>&nbsp;27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;1 Jul 2004</p>
5693
5694 <p>
5695 I think Footnote 297 is confused. The paragraph it applies to seems
5696 quite clear in that widen() is only called if the object is not a char
5697 stream (i.e., not basic_ostream&lt;char&gt;), so it's irrelevant what the
5698 value of widen(c) is otherwise.
5699 </p>
5700 <p><b>Proposed resolution:</b></p>
5701 <p>
5702 I propose to strike the Footnote.
5703 </p>
5704 <hr>
5705 <a name="475"><h3>475.&nbsp;May the function object passed to for_each modify the elements of the iterated sequence?</h3></a><p><b>Section:</b>&nbsp;25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Stephan T. Lavavej, Jaakko Jarvi&nbsp; <b>Date:</b>&nbsp;9 Jul 2004</p>
5706 <p>
5707 It is not clear whether the function object passed to for_each is allowed to
5708 modify the elements of the sequence being iterated over.
5709 </p>
5710
5711 <p>
5712 for_each is classified without explanation in [lib.alg.nonmodifying], "25.1
5713 Non-modifying sequence operations". 'Non-modifying sequence operation' is
5714 never defined.
5715 </p>
5716
5717 <p>
5718 25(5) says: "If an algorithm's Effects section says that a value pointed to
5719 by any iterator passed as an argument is modified, then that algorithm has
5720 an additional type requirement: The type of that argument shall satisfy the
5721 requirements of a mutable iterator (24.1)."
5722 </p>
5723
5724 <p>for_each's Effects section does not mention whether arguments can be
5725 modified:</p>
5726
5727 <blockquote>
5728   "Effects: Applies f to the result of dereferencing every iterator in the
5729    range [first, last), starting from first and proceeding to last - 1."
5730 </blockquote>
5731
5732 <p>
5733 Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in
5734 the sense that neither the algorithms themselves nor the function objects
5735 passed to the algorithms may modify the sequences or elements in any way.
5736 This DR affects only for_each.
5737 </p>
5738
5739 <p>
5740 We suspect that for_each's classification in "non-modifying sequence
5741 operations" means that the algorithm itself does not inherently modify the
5742 sequence or the elements in the sequence, but that the function object
5743 passed to it may modify the elements it operates on.
5744 </p>
5745
5746 <p>
5747 The original STL document by Stepanov and Lee explicitly prohibited the
5748 function object from modifying its argument.
5749 The "obvious" implementation of for_each found in several standard library
5750 implementations, however, does not impose this restriction.
5751 As a result, we suspect that the use of for_each with function objects that modify
5752 their arguments is wide-spread.
5753 If the restriction was reinstated, all such code would become non-conforming.
5754 Further, none of the other algorithms in the Standard
5755 could serve the purpose of for_each (transform does not guarantee the order in
5756 which its function object is called).
5757 </p>
5758
5759 <p>
5760 We suggest that the standard be clarified to explicitly allow the function object
5761 passed to for_each modify its argument.</p>
5762
5763 <p><b>Proposed resolution:</b></p>
5764 <p>Add the following sentence to the Effects in 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>:</p>
5765
5766 <blockquote>
5767 "f may apply non-constant functions through the dereferenced iterators
5768 passed to it; if it does, the type of first shall satisfy the requirements
5769 of a mutable iterator (24.1)."
5770 </blockquote>
5771
5772 <hr>
5773 <a name="476"><h3>476.&nbsp;Forward Iterator implied mutability</h3></a><p><b>Section:</b>&nbsp;24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;9 Jul 2004</p>
5774
5775 <p>24.1/3 says:</p>
5776 <blockquote>
5777   Forward iterators satisfy all the requirements of the input and
5778   output iterators and can be used whenever either kind is specified
5779 </blockquote>
5780
5781 <p>
5782 The problem is that satisfying the requirements of output iterator
5783 means that you can always assign *something* into the result of
5784 dereferencing it.  That makes almost all non-mutable forward
5785 iterators non-conforming.  I think we need to sever the refinement
5786 relationship between forward iterator and output iterator.
5787 </p>
5788
5789 <p><b>Proposed resolution:</b></p>
5790 <p>in 24.1/3, replace:</p>
5791 <blockquote>
5792     Forward iterators satisfy all the requirements of the input and
5793     output iterators and can be used whenever either kind is specified.
5794 </blockquote>
5795 <p>with</p>
5796 <blockquote>
5797    A forward iterator satisfies all the input iterator requirements.
5798    A mutable forward iterator satisfies all the output iterator
5799    requirements.
5800 </blockquote>
5801 <hr>
5802 <a name="477"><h3>477.&nbsp;Operator-&gt; for const forward iterators</h3></a><p><b>Section:</b>&nbsp;24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;11 Jul 2004</p>
5803 <p>
5804 The Forward Iterator requirements table contains the following:
5805 </p>
5806 <pre> expression  return type         operational  precondition
5807                                   semantics
5808   ==========  ==================  ===========  ==========================
5809   a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
5810               otherwise const U&amp;
5811
5812   r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
5813 </pre>
5814
5815 <p>
5816 The first line is exactly right.  The second line is wrong.  Basically
5817 it implies that the const-ness of the iterator affects the const-ness
5818 of referenced members.  But Paragraph 11 of [lib.iterator.requirements] says:
5819 </p>
5820
5821 <blockquote>
5822    In the following sections, a and b denote values of type const X, n
5823    denotes a value of the difference type Distance, u, tmp, and m
5824    denote identifiers, r denotes a value of X&amp;, t denotes a value of
5825    value type T, o denotes a value of some type that is writable to
5826    the output iterator.
5827 </blockquote>
5828
5829 <p>AFAICT if we need the second line at all, it should read the same
5830 as the first line.</p>
5831
5832 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#478">478</a></p>
5833 <p><b>Proposed resolution:</b></p>
5834 <hr>
5835 <a name="478"><h3>478.&nbsp;Should forward iterator requirements table have a line for r-&gt;m?</h3></a><p><b>Section:</b>&nbsp;24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;11 Jul 2004</p>
5836 <p>
5837 The Forward Iterator requirements table contains the following:
5838 </p>
5839 <pre> expression  return type         operational  precondition
5840                                   semantics
5841   ==========  ==================  ===========  ==========================
5842   a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
5843               otherwise const U&amp;
5844
5845   r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
5846 </pre>
5847
5848 <p>The second line may be unnecessary.  Paragraph 11 of
5849   [lib.iterator.requirements] says:
5850 </p>
5851
5852 <blockquote>
5853    In the following sections, a and b denote values of type const X, n
5854    denotes a value of the difference type Distance, u, tmp, and m
5855    denote identifiers, r denotes a value of X&amp;, t denotes a value of
5856    value type T, o denotes a value of some type that is writable to
5857    the output iterator.
5858 </blockquote>
5859
5860 <p>
5861 Because operators can be overloaded on an iterator's const-ness, the
5862 current requirements allow iterators to make many of the operations
5863 specified using the identifiers a and b invalid for non-const
5864 iterators.  Rather than expanding the tables, I think the right
5865 answer is to change
5866 </p>
5867 <blockquote>
5868     "const X"
5869 </blockquote>
5870
5871 <p> to </p>
5872
5873 <blockquote>
5874     "X or const X"
5875 </blockquote>
5876
5877 <p>in paragraph 11 of [lib.iterator.requirements].</p>
5878
5879 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#477">477</a></p>
5880 <p><b>Proposed resolution:</b></p>
5881 <hr>
5882 <a name="479"><h3>479.&nbsp;Container requirements and placement new</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Herb Sutter&nbsp; <b>Date:</b>&nbsp;1 Aug 2004</p>
5883 <p>Nothing in the standard appears to make this program ill-formed:</p>
5884
5885 <pre>  struct C {
5886     void* operator new( size_t s ) { return ::operator new( s ); }
5887     // NOTE: this hides in-place and nothrow new
5888   };
5889
5890   int main() {
5891     vector&lt;C&gt; v;
5892     v.push_back( C() );
5893   }
5894 </pre>
5895
5896 <p>Is that intentional?  We should clarify whether or not we intended
5897   to require containers to support types that define their own special
5898   versions of <tt>operator new</tt>.</p>
5899
5900 <p><b>Proposed resolution:</b></p>
5901 <hr>
5902 <a name="480"></a><h3><a name="480">480.&nbsp;unary_function and binary_function should have protected nonvirtual destructors</a></h3><p><b>Section:</b>&nbsp;20.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.base"> [lib.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Joe Gottman&nbsp; <b>Date:</b>&nbsp;19 Aug 2004</p>
5903 <p>The classes std::unary_function and std::binary_function are both
5904 designed to be inherited from but contain no virtual functions.  This
5905 makes it too easy for a novice programmer to write code like
5906 binary_function&lt;int, int, int&gt; *p = new plus&lt;int&gt;; delete p;</p>
5907
5908 <p>There are two common ways to prevent this source of undefined
5909 behavior: give the base class a public virtual destructor, or give it
5910 a protected nonvirtual destructor.  Since unary_function and
5911 binary_function have no other virtual functions, (note in particular
5912 the absence of an operator()() ), it would cost too much to give them
5913 public virtual destructors.  Therefore, they should be given protected
5914 nonvirtual destructors.</p>
5915 <p><b>Proposed resolution:</b></p>
5916 <p>Change Paragraph 20.3.1 of the Standard from</p>
5917 <pre>    template &lt;class Arg, class Result&gt;
5918     struct unary_function {
5919         typedef Arg argument_type;
5920         typedef Result result_type;
5921     };
5922
5923     template &lt;class Arg1, class Arg2, class Result&gt;
5924     struct binary_function {
5925         typedef Arg1 first_argument_type;
5926         typedef Arg2 second_argument_type;
5927         typedef Result result_type;
5928     };
5929 </pre>
5930
5931 <p>to</p>
5932 <pre>    template &lt;class Arg, class Result&gt;
5933         struct unary_function {
5934         typedef Arg argument_type;
5935         typedef Result result_type;
5936     protected:
5937         ~unary_function() {}
5938     };
5939
5940     template &lt;class Arg1, class Arg2, class Result&gt;
5941     struct binary_function {
5942         typedef Arg1 first_argument_type;
5943         typedef Arg2 second_argument_type;
5944         typedef Result result_type;
5945     protected:
5946         ~binary_function() {}
5947     };
5948 </pre>
5949 <hr>
5950 <a name="481"><h3>481.&nbsp;unique's effects on the range [result, last)</h3></a><p><b>Section:</b>&nbsp;25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;30 Aug 2004</p>
5951 <p>
5952 The standard says that unique(first, last) "eliminates all but the
5953 first element from every consecutive group of equal elements" in
5954 [first, last) and returns "the end of the resulting range".  So a
5955 postcondition is that [first, result) is the same as the old [first,
5956 last) except that duplicates have been eliminated.
5957 </p>
5958
5959 <p>What postconditions are there on the range [result, last)?  One
5960   might argue that the standard says nothing about those values, so
5961   they can be anything.  One might also argue that the standard
5962   doesn't permit those values to be changed, so they must not be.
5963   Should the standard say something explicit one way or the other?</p>
5964
5965 <p><b>Proposed resolution:</b></p>
5966 <p>
5967 </p>
5968 <hr>
5969 <a name="482"><h3>482.&nbsp;Swapping pairs</h3></a><p><b>Section:</b>&nbsp;20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.pairs"> [lib.pairs]</a>, 25.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;14 Sep 2004</p>
5970 <p>(Based on recent comp.std.c++ discussion)</p>
5971
5972 <p>Pair (and tuple) should specialize std::swap to work in terms of
5973 std::swap on their components.  For example, there's no obvious reason
5974 why swapping two objects of type pair&lt;vector&lt;int&gt;,
5975 list&lt;double&gt; &gt; should not take O(1).</p>
5976 <p><b>Proposed resolution:</b></p>
5977 <hr>
5978 <a name="484"><h3>484.&nbsp;Convertible to T</h3></a><p><b>Section:</b>&nbsp;24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Chris&nbsp; <b>Date:</b>&nbsp;16 Sep 2004</p>
5979 <p>From comp.std.c++:</p>
5980
5981 <p>
5982 I note that given an input iterator a for type T,
5983 then *a only has to be "convertable to T", not actually of type T.
5984 </p>
5985
5986 <p>Firstly, I can't seem to find an exact definition of "convertable to T".
5987 While I assume it is the obvious definition (an implicit conversion), I
5988 can't find an exact definition. Is there one?</p>
5989
5990 <p>Slightly more worryingly, there doesn't seem to be any restriction on
5991 the this type, other than it is "convertable to T". Consider two input
5992 iterators a and b. I would personally assume that most people would
5993 expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that
5994 the standard requires that, and that whatever type *a is (call it U)
5995 could have == defined on it with totally different symantics and still
5996 be a valid inputer iterator.</p>
5997
5998 <p>Is this a correct reading? When using input iterators should I write
5999 T(*a) all over the place to be sure that the object i'm using is the
6000 class I expect?</p>
6001
6002 <p>This is especially a nuisance for operations that are defined to be
6003   "convertible to bool".  (This is probably allowed so that
6004   implementations could return say an int and avoid an unnessary
6005   conversion. However all implementations I have seen simply return a
6006   bool anyway.  Typical implemtations of STL algorithms just write
6007   things like <tt>while(a!=b &amp;&amp; *a!=0)</tt>.  But strictly
6008   speaking, there are lots of types that are convertible to T but
6009   that also overload the appropriate operators so this doesn't behave
6010   as expected.</p>
6011
6012 <p>If we want to make code like this legal (which most people seem to
6013   expect), then we'll need to tighten up what we mean by "convertible
6014   to T".</p>
6015
6016 <p><b>Proposed resolution:</b></p>
6017 <p>
6018 </p>
6019 <hr>
6020 <a name="485"><h3>485.&nbsp;output iterator insufficently constrained</h3></a><p><b>Section:</b>&nbsp;24.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Chris&nbsp; <b>Date:</b>&nbsp;13 Oct 2004</p>
6021 <p>
6022 The note on 24.1.2 Output iterators insufficently limits what can be
6023 performed on output iterators. While it requires that each iterator is
6024 progressed through only once and that each iterator is written to only
6025 once, it does not require the following things:</p>
6026
6027 <p>Note: Here it is assumed that x is an output iterator of type X which
6028 has not yet been assigned to.</p>
6029
6030 <p>a) That each value of the output iterator is written to:
6031 The standard allows:
6032 ++x; ++x; ++x;
6033 </p>
6034
6035 <p>
6036 b) That assignments to the output iterator are made in order
6037 X a(x); ++a; *a=1; *x=2; is allowed
6038 </p>
6039
6040 <p>
6041 c) Chains of output iterators cannot be constructed:
6042 X a(x); ++a; X b(a); ++b; X c(b); ++c; is allowed, and under the current
6043 wording (I believe) x,a,b,c could be written to in any order.
6044 </p>
6045
6046 <p>I do not believe this was the intension of the standard?</p>
6047 <p><b>Proposed resolution:</b></p>
6048 <p>Add to the note:</p>
6049
6050 <p>"The values of an output iterator must be assigned to in the order they
6051 are generated. It is undefined to progress forward more than once from a
6052 value of an output iterator which has not yet been assigned."</p>
6053
6054 <p>This is I believe the intension of the existing text. The "progress
6055 forward once" is allowed so that "*r++=t" is allowed. It may be prefered
6056 to instead allow something more along the lines of:</p>
6057
6058 <p>"The values of an output iterator must be assigned to in the order they
6059 are generated. With the exception of '*r++=t', an iterator must always
6060 be assigned to before it is incremented".</p>
6061 <hr>
6062 <a name="487"><h3>487.&nbsp;Allocator::construct is too limiting</h3></a><p><b>Section:</b>&nbsp;20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Dhruv Matani&nbsp; <b>Date:</b>&nbsp;17 Oct 2004</p>
6063 <p>
6064 The standard's version of allocator::construct(pointer,
6065 const_reference) severely limits what you can construct using this
6066 function.  Say you can construct a socket from a file descriptor. Now,
6067 using this syntax, I first have to manually construct a socket from
6068 the fd, and then pass the constructed socket to the construct()
6069 function so it will just to an uninitialized copy of the socket I
6070 manually constructed. Now it may not always be possible to copy
6071 construct a socket eh! So, I feel that the changes should go in the
6072 allocator::construct(), making it:
6073 </p>
6074 <pre>    template&lt;typename T&gt;
6075     struct allocator{
6076       template&lt;typename T1&gt;
6077       void construct(pointer T1 const&amp; rt1);
6078     };
6079 </pre>
6080
6081 <p>
6082 Now, the ctor of the class T which matches the one that takes a T1 can
6083 be called! Doesn't that sound great?
6084 </p>
6085 <p><b>Proposed resolution:</b></p>
6086 <p>
6087 </p>
6088 <hr>
6089 <a name="488"><h3>488.&nbsp;rotate throws away useful information</h3></a><p><b>Section:</b>&nbsp;25.2.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.rotate"> [lib.alg.rotate]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;22 Nov 2004</p>
6090 <p>
6091 rotate takes 3 iterators:  first, middle and last which point into a
6092 sequence, and rearranges the sequence such that the subrange [middle,
6093 last) is now at the beginning of the sequence and the subrange [first,
6094 middle) follows.  The return type is void.
6095 </p>
6096
6097 <p>
6098 In many use cases of rotate, the client needs to know where the
6099 subrange [first, middle) starts after the rotate is performed.  This
6100 might look like:
6101 </p>
6102 <pre>  rotate(first, middle, last);
6103   Iterator i = advance(first, distance(middle, last));
6104 </pre>
6105
6106 <p>
6107 Unless the iterators are random access, the computation to find the
6108 start of the subrange [first, middle) has linear complexity.  However,
6109 it is not difficult for rotate to return this information with
6110 negligible additional computation expense.  So the client could code:
6111 </p>
6112 <pre>  Iterator i = rotate(first, middle, last);
6113 </pre>
6114
6115 <p>
6116 and the resulting program becomes significantly more efficient.
6117 </p>
6118
6119 <p>
6120 While the backwards compatibility hit with this change is not zero, it
6121 is very small (similar to that of lwg <ire ref="130"></ire>), and there is
6122 a significant benefit to the change.
6123 </p>
6124
6125 <p><b>Proposed resolution:</b></p>
6126 <p>In 25p2, change:</p>
6127 <pre>  template&lt;class ForwardIterator&gt;
6128     void rotate(ForwardIterator first, ForwardIterator middle,
6129                 ForwardIterator last);
6130 </pre>
6131
6132 <p>to:</p>
6133
6134 <pre>  template&lt;class ForwardIterator&gt;
6135     ForwardIterator rotate(ForwardIterator first, ForwardIterator middle,
6136                            ForwardIterator last);
6137 </pre>
6138
6139 <p>In 25.2.10, change:</p>
6140
6141 <pre>  template&lt;class ForwardIterator&gt;
6142     void rotate(ForwardIterator first, ForwardIterator middle,
6143                 ForwardIterator last);
6144 </pre>
6145
6146 <p>to:</p>
6147
6148 <pre>  template&lt;class ForwardIterator&gt;
6149     ForwardIterator rotate(ForwardIterator first, ForwardIterator middle,
6150                            ForwardIterator last);
6151 </pre>
6152
6153 <p>In 25.2.10 insert a new paragraph after p1:</p>
6154
6155 <blockquote>
6156 <p><b>Returns</b>: advance(first, distance(middle, last)).</p>
6157 </blockquote>
6158 <hr>
6159 <a name="489"><h3>489.&nbsp;std::remove / std::remove_if wrongly specified</h3></a><p><b>Section:</b>&nbsp;25.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Thomas Mang&nbsp; <b>Date:</b>&nbsp;12 Dec 2004</p>
6160 <p>In Section 25.2.7 [lib.alg.remove], paragraphs 1 to 5 describe the
6161 behavior of the mutating sequence operations std::remove and
6162 std::remove_if. However, the wording does not reflect the intended
6163 behavior [Note: See definition of intended behavior below] of these
6164 algorithms, as it is known to the C++ community [1].
6165 </p>
6166
6167
6168
6169 <p>1) Analysis of current wording:</p>
6170
6171
6172 <p>25.2.7 [lib.alg.remove], paragraph 2:</p>
6173
6174 <p>Current wording says:
6175 "Effects: Eliminates all the elements referred to by iterator i in the
6176 range [first, last) for which the following corresponding conditions
6177 hold: *i == value, pred(*i) != false."</p>
6178
6179 <p>
6180 This sentences expresses specifically that all elements denoted by the
6181 (original) range [first, last) for which the corresponding condition
6182 hold will be eliminated. Since there is no formal definition of the term
6183 "eliminate" provided, the meaning of "eliminate" in everyday language
6184 implies that as postcondition, no element in the range denoted by
6185 [first, last) will hold the corresponding condition on reiteration over
6186 the range [first, last).
6187 </p>
6188
6189 <p>
6190 However, this is neither the intent [Note: See definition of intended
6191 behavior below] nor a general possible approach. It can be easily proven
6192 that if all elements of the original range[first, last) will hold the
6193 condition, it is not possible to substitute them by an element for which
6194 the condition will not hold.
6195 </p>
6196
6197
6198 <p>25.2.7 [lib.alg.remove], paragraph 3:</p>
6199
6200 <p>
6201 Current wording says:
6202 "Returns: The end of the resulting range."
6203 </p>
6204
6205 <p>
6206 The resulting range is not specified. In combination with 25.2.7
6207 [lib.alg.remove], paragraph 2, the only reasonable interpretation of
6208 this so-called resulting range is the range [first,last) - thus
6209 returning always the ForwardIterator 'last' parameter.
6210 </p>
6211
6212
6213 <p>
6214 25.2.7 [lib.alg.remove], paragraph 4:
6215 </p>
6216
6217 <p>
6218 Current wording says:
6219 "Notes: Stable: the relative order of the elements that are not removed
6220 is the same as their relative order in the original range"
6221 </p>
6222
6223 <p>
6224 This sentences makes use of the term "removed", which is neither
6225 specified, nor used in a previous paragraph (which uses the term
6226 "eliminate"), nor unamgiuously separated from the name of the algorithm.
6227 </p>
6228
6229
6230 <p>2) Description of intended behavior:</p>
6231
6232 <p>
6233 For the rest of this Defect Report, it is assumed that the intended
6234 behavior was that all elements of the range [first, last) which do not
6235 hold the condition *i == value (std::remove) or  pred(*i) != false
6236 (std::remove_if)], call them s-elements [Note: s...stay], will be placed
6237 into a contiguous subrange of [first, last), denoted by the iterators
6238 [first, return value). The number of elements in the resulting range
6239 [first, return value) shall be equal to the number of s-elements in the
6240 original range [first, last). The relative order of the elements in the
6241 resulting subrange[first, return value) shall be the same as the
6242 relative order of the corresponding elements in the original range. It
6243 is undefined whether any elements in the resulting subrange [return
6244 value, last) will hold the corresponding condition, or not.
6245 </p>
6246
6247 <p>
6248 All implementations known to the author of this Defect Report comply
6249 with this intent. Since the intent  of the behavior (contrary to the
6250 current wording) is also described in various utility references serving
6251 the C++ community [1], it is not expected that fixing the paragraphs
6252 will influence current code - unless the code relies on the behavior as
6253 it is described by current wording and the implementation indeed
6254 reflects the current wording, and not the intent.
6255 </p>
6256
6257
6258
6259 <p>3) Proposed fixes:</p>
6260
6261
6262 <p>Change 25.2.7 [lib.alg.remove], paragraph 2 to:</p>
6263
6264 <p>
6265 "Effect: Places all the elements referred to by iterator i in the range
6266 [first, last) for which the following corresponding conditions hold :
6267 !(*i == value), pred(*i) == false into the subrange [first, k) of the
6268 original range, where k shall denote a value of type ForwardIterator. It
6269 is undefined whether any elements in the resulting subrange [k, last)
6270 will hold the corresponding condition, or not."
6271 </p>
6272
6273 <p>Comments to the new wording:</p>
6274
6275 <p>
6276 a) "Places" has no special meaning, and the everyday language meaning
6277 should fit.
6278 b) The corresponding conditions were negated compared to the current
6279 wording, becaue the new wording requires it.
6280 c) The wording "of the original range" might be redundant, since any
6281 subrange starting at 'first' and containing no more elements than the
6282 original range is implicitly a subrange of the original range [first,
6283 last).
6284 d) The iterator k was introduced instead of "return value" in order to
6285 avoid a cyclic dependency on 25.2.7/3. The wording ", where k shall
6286 denote a value of type ForwardIterator" might be redundant, because it
6287 follows implicitly by 25.2.7/3.
6288 e) "Places" does, in the author's opinion, explicitly forbid duplicating
6289 any element holding the corresponding condition in the original range
6290 [first, last) within the resulting range [first, k). If there is doubt
6291 this term might be not unambiguous regarding this, it is suggested that
6292 k is specified more closely by the following wording: "k shall denote a
6293 value of type ForwardIterator [Note: see d)] so that k - first is equal
6294 to the number of elements in the original range [first, last) for which
6295 the corresponding condition did hold". This could also be expressed as a
6296 separate paragraph "Postcondition:"
6297 f) The senctence "It is undefined whether any elements in the resulting
6298 subrange [k, last) will hold the corresponding condition, or not." was
6299 added consciously so the term "Places" does not imply if the original
6300 range [first, last) contains n elements holding the corresponding
6301 condition, the identical range[first, last) will also contain exactly n
6302 elements holding the corresponding condition after application of the
6303 algorithm.
6304 </p>
6305
6306 <p>
6307 Change 25.2.7 [lib.alg.remove], paragraph 3 to:
6308
6309 "Returns: The iterator k."
6310 </p>
6311
6312 <p>
6313 Change 25.2.7 [lib.alg.remove], paragraph 4 to:
6314
6315 "Notes: Stable: the relative order of the elements that are placed into
6316 the subrange [first, return value) shall be the same as their relative
6317 order was in the original range [first, last) prior to application of
6318 the algorithm."
6319 </p>
6320
6321 <p>
6322 Comments to the new wording:
6323 </p>
6324
6325 <p>
6326 a) the wording "was ...  prior to application of the algorithm" is used
6327 to explicitly distinguish the original range not only by means of
6328 iterators, but also by a 'chronological' factor from the resulting range
6329 [first, return value). It might be redundant.
6330 </p>
6331
6332 <p>
6333 [1]:
6334 The wording of these references is not always unambiguous, and provided
6335 examples partially contradict verbal description of the algorithms,
6336 because the verbal description resembles the problematic wording of
6337 ISO/IEC 14882:2003.
6338 </p>
6339 <p><b>Proposed resolution:</b></p>
6340 <p>
6341 </p>
6342 <hr>
6343 <a name="490"><h3>490.&nbsp;std::unique wrongly specified</h3></a><p><b>Section:</b>&nbsp;25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Thomas Mang&nbsp; <b>Date:</b>&nbsp;12 Dec 2004</p>
6344 <p>In Section 25.2.8 [lib.alg.unique], paragraphs 1 to 3 describe the
6345 behavior of the mutating sequence operation std::unique. However, the
6346 wording does not reflect the intended behavior [Note: See definition of
6347 intended behavior below] of these algorithms, as it is known to the C++
6348 community [1].</p>
6349
6350
6351
6352 <p>1) Analysis of current wording:</p>
6353
6354
6355 <p>25.2.8 [lib.alg.unique], paragraph 1:</p>
6356
6357 <p>
6358 Current wording says:
6359 "Effects: Eliminates all but the first element from every consecutive
6360 group of equal elements referred to by the iterator i in the range
6361 [first, last) for which the following corresponding conditions hold: *i
6362 == *(i - 1) or pred(*i, *(i -1)) != false"
6363 </p>
6364
6365 <p>
6366 This sentences expresses specifically that all elements denoted by the
6367 (original) range [first, last) which are not but the first element from
6368 a consecutive group of equal elements (where equality is defined as *i
6369 == *(i - 1) or pred(*i, *(i - 1)) ! = false) [Note: See DR 202], call
6370 them r-elements [Note: r...remove], will be eliminated. Since there is
6371 no formal definition of the term "eliminate" provided, it is undefined
6372 how this "elimination" takes place. But the meaning of "eliminate" in
6373 everyday language seems to disallow explicitly that after application of
6374 the algorithm, any r-element will remain at any position of the range
6375 [first, last) [2].
6376 </p>
6377
6378 <p>
6379 Another defect in the current wording concerns the iterators used to
6380 compare two elements for equality: The current wording contains the
6381 expression "(i - 1)", which is not covered by 25/9 [Note: See DR
6382 submitted by Thomas Mang regarding invalid iterator arithmetic
6383 expressions].
6384 </p>
6385
6386
6387 <p>
6388 25.2.8 [lib.alg.unique], paragraph 2:
6389 </p>
6390 <p>Current wording says:
6391 "Returns: The end of the resulting range."</p>
6392
6393 <p>
6394 The resulting range is not specified. In combination with 25.2.8
6395 [lib.alg.unique], paragraph 1, one reasonable interpretation (in the
6396 author's opinion even the only possible interpretation) of this
6397 so-called resulting range is the range [first, last) - thus returning
6398 always the ForwardIterator 'last' parameter.
6399 </p>
6400
6401 <p>2) Description of intended behavior:</p>
6402
6403 <p>
6404 For the rest of this Defect Report, it is assumed that the intended
6405 behavior was that all elements denoted by the original range [first,
6406 last) which are the first element from a consecutive group of elements
6407 for which the corresponding conditions: *(i-1) == *i (for the version of
6408 unique without a predicate argument) or pred(*(i-1), *i) ! = false (for
6409 the version of unique with a predicate argument) [Note: If such a group
6410 of elements consists of only a single element, this is also considered
6411 the first element] [Note: See resolutions of DR 202], call them
6412 s-elements [Note: s...stay], will be placed into a contiguous subrange
6413 of [first, last), denoted by the iterators [first, return value). The
6414 number of elements in the resulting range [first, return value) shall be
6415 equal to the number of s-elements in the original range [first, last).
6416 Invalid iterator arithmetic expressions are expected to be resolved as
6417 proposed in DR submitted by Thomas Mang regarding invalid iterator
6418 arithmetic expressions. It is also assumed by the author that the
6419 relative order of the elements in the resulting subrange [first, return
6420 value) shall be the same as the relative order of the corresponding
6421 elements (the s-elements) in the original range [Note: If this was not
6422 intended behavior, the additional proposed paragraph about stable order
6423 will certainly become obsolete].
6424 Furthermore, the resolutions of DR 202 are partially considered.
6425 </p>
6426
6427 <p>
6428 All implementations known to the author of this Defect Report comply
6429 with this intent [Note: Except possible effects of DR 202]. Since this
6430 intent of the behavior (contrary to the current wording) is also
6431 described in various utility references serving the C++ community [1],
6432 it is not expected that fixing the paragraphs will influence current
6433 code [Note: Except possible effects of DR 202] - unless the code relies
6434 on the behavior as it is described by current wording and the
6435 implementation indeed reflects the current wording, and not the intent.
6436 </p>
6437
6438
6439
6440 <p>3) Proposed fixes:</p>
6441
6442 <p>
6443 Change 25.2.8 [lib.alg.unique], paragraph 1 to:
6444 </p>
6445
6446 <p>
6447 "Effect: Places the first element from every consecutive group of
6448 elements, referred to by the iterator i in the range [first, last), for
6449 which the following conditions hold: *(i-1) == *i (for the version of
6450 unique without a predicate argument) or pred(*(i -1), *i) != false (for
6451 the version of unique with a predicate argument), into the subrange
6452 [first, k) of the original range, where k shall denote a value of type
6453 ForwardIterator."
6454 </p>
6455
6456 <p>Comments to the new wording:</p>
6457
6458 <p>
6459 a) The new wording was influenced by the resolutions of DR 202. If DR
6460 202 is resolved in another way, the proposed wording need also
6461 additional review.
6462 b) "Places" has no special meaning, and the everyday language meaning
6463 should fit.
6464 c) The expression "(i - 1)" was left, but is expected that DR submitted
6465 by Thomas Mang regarding invalid iterator arithmetic expressions will
6466 take this into account.
6467 d) The wording "(for the version of unique without a predicate
6468 argument)" and "(for the version of unique with a predicate argument)"
6469 was added consciously for clarity and is in resemblence with current
6470 23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant.
6471 e) The wording "of the original range" might be redundant, since any
6472 subrange starting at first and containing no more elements than the
6473 original range is implicitly a subrange of the original range [first,
6474 last).
6475 f) The iterator k was introduced instead of "return value" in order to
6476 avoid a cyclic dependency on 25.2.8 [lib.alg.unique], paragraph 2. The
6477 wording ", where k shall denote a value of type ForwardIterator" might
6478 be redundant, because it follows implicitly by 25.2.8 [lib.alg.unique],
6479 paragraph 2.
6480 g) "Places" does, in the author's opinion, explicitly forbid duplicating
6481 any s-element in the original range [first, last) within the resulting
6482 range [first, k). If there is doubt this term might be not unambiguous
6483 regarding this, it is suggested that k is specified more closely by the
6484 following wording: "k shall denote a value of type ForwardIterator
6485 [Note: See f)] so that k - first is equal to the number of elements in
6486 the original range [first, last) being the first element from every
6487 consecutive group of elements for which the corresponding condition did
6488 hold". This could also be expressed as a separate paragraph
6489 "Postcondition:".
6490 h) If it is considered that the wording is unclear whether it declares
6491 the element of a group which consists of only a single element
6492 implicitly to be the first element of this group [Note: Such an
6493 interpretation could eventually arise especially in case last - first ==
6494 1] , the following additional sentence is proposed: "If such a group of
6495 elements consists of only a single element, this element is also
6496 considered the first element."
6497 </p>
6498
6499 <p>
6500 Change 25.2.8 [lib.alg.unique], paragraph 2 to:
6501 "Returns: The iterator k."
6502 </p>
6503
6504 <p>
6505 Add a separate paragraph "Notes:" as 25.2.8 [lib.alg.unique], paragraph
6506 2a or 3a, or a separate paragraph "Postcondition:" before 25.2.8
6507 [lib.alg.unique], paragraph 2 (wording inside {} shall be eliminated if
6508 the preceding expressions are used, or the preceding expressions shall
6509 be eliminated if wording inside {} is used):
6510 </p>
6511
6512 <p>
6513 "Notes:{Postcondition:} Stable: the relative order of the elements that
6514 are placed into the subrange [first, return value {k}) shall be the same
6515 as their relative order was in the original range [first, last) prior to
6516 application of the algorithm."
6517 </p>
6518
6519 <p>Comments to the new wording:</p>
6520
6521 <p>
6522 a) It is assumed by the author that the algorithm was intended to be
6523 stable.
6524 In case this was not the intent, this paragraph becomes certainly
6525 obsolete.
6526 b) The wording "was ...  prior to application of the algorithm" is used
6527 to explicitly distinguish the original range not only by means of
6528 iterators, but also by a 'chronological' factor from the resulting range
6529 [first, return value). It might be redundant.
6530 </p>
6531
6532 <p>
6533 25.2.8 [lib.alg.unique], paragraph 3:
6534 </p>
6535 <p>See DR 239.</p>
6536
6537 <p>
6538 4) References to other DRs:
6539 </p>
6540
6541 <p>
6542 See DR 202, but which does not address any of the problems described in
6543 this Defect Report [Note: This DR is supposed to complement DR 202].
6544 See DR 239.
6545 See DR submitted by Thomas Mang regarding invalid iterator arithmetic
6546 expressions.
6547 </p>
6548
6549 <p>
6550 [1]:
6551 The wording of these references is not always unambiguous, and provided
6552 examples partially contradict verbal description of the algorithms,
6553 because the verbal description resembles the problematic wording of
6554 ISO/IEC 14882:2003.
6555 </p>
6556
6557 <p>
6558 [2]:
6559 Illustration of conforming implementations according to current wording:
6560 </p>
6561
6562 <p>
6563 One way the author of this DR considers how this "elimination" could be
6564 achieved by a conforming implementation according to current wording is
6565 by substituting each r-element by _any_ s-element [Note: s...stay; any
6566 non-r-element], since all r-elements are "eliminated".
6567 </p>
6568
6569 <p>
6570 In case of a sequence consisting of elements being all 'equal' [Note:
6571 See DR 202], substituting each r-element by the single s-element is the
6572 only possible solution according to current wording.
6573 </p>
6574 <p><b>Proposed resolution:</b></p>
6575 <p>
6576 </p>
6577 <hr>
6578 <a name="491"><h3>491.&nbsp;std::list&lt;&gt;::unique incorrectly specified</h3></a><p><b>Section:</b>&nbsp;23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Thomas Mang&nbsp; <b>Date:</b>&nbsp;12 Dec 2004</p>
6579 <p>In Section 23.2.2.4 [lib.list.ops], paragraphs 19 to 21 describe the
6580 behavior of the std::list&lt;T, Allocator&gt;::unique operation. However, the
6581 current wording is defective for various reasons.</p>
6582
6583
6584
6585 <p>
6586 1) Analysis of current wording:
6587 </p>
6588
6589 <p>23.2.2.4 [lib.list.ops], paragraph 19:</p>
6590
6591 <p>
6592 Current wording says:
6593 "Effects:  Eliminates all but the first element from every consecutive
6594 group of equal elements referred to by the iterator i in the range
6595 [first + 1, last) for which *i == *(i - 1) (for the version of unique
6596 with no argument) or pred(*i, *(i -1)) (for the version of unique with a
6597 predicate argument) holds."</p>
6598
6599 <p>
6600 This sentences makes use of the undefined term "Eliminates". Although it
6601 is, to a certain degree, reasonable to consider the term "eliminate"
6602 synonymous with "erase", using "Erase" in the first place, as the
6603 wording of 23.2.2.4 [lib.list.ops], paragraph 15 does, would be clearer.</p>
6604
6605 <p>
6606 The range of the elements referred to by iterator i is "[first + 1,
6607 last)". However, neither "first" nor "last" is defined.</p>
6608
6609 <p>
6610 The sentence makes three times use of iterator arithmetic expressions (
6611 "first + 1", "*i == *(i - 1)", "pred(*i, *(i -1))" ) which is not
6612 defined for bidirectional iterator [see DR submitted by Thomas Mang
6613 regarding invalid iterator arithmetic expressions].</p>
6614
6615 <p>
6616 The same problems as pointed out in DR 202 (equivalence relation / order
6617 of arguments for pred()) apply to this paragraph.</p>
6618
6619 <p>
6620 23.2.2.4 [lib.list.ops], paragraph 20:
6621 </p>
6622
6623 <p>
6624 Current wording says:
6625 "Throws: Nothing unless an exception in thrown by *i == *(i-1) or
6626 pred(*i, *(i - 1))"</p>
6627
6628 <p>
6629 The sentence makes two times use of invalid iterator arithmetic
6630 expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ).
6631 </p>
6632 <p>
6633 [Note: Minor typos: "in" / missing dot at end of sentence.]
6634 </p>
6635
6636 <p>
6637 23.2.2.4 [lib.list.ops], paragraph 21:</p>
6638
6639 <p>
6640 Current wording says:
6641 "Complexity: If the range (last - first) is not empty, exactly (last -
6642 first) - 1 applications of the corresponding predicate, otherwise no
6643 application of the predicate.</p>
6644
6645 <p>
6646 See DR 315 regarding "(last - first)" not yielding a range.</p>
6647
6648 <p>
6649 Invalid iterator arithmetic expression "(last - first) - 1" left .</p>
6650
6651
6652 <p>2) Description of intended behavior:</p>
6653
6654 <p>
6655 For the rest of this Defect Report, it is assumed that "eliminate" is
6656 supposed to be synonymous to "erase", that "first" is equivalent to an
6657 iterator obtained by a call to begin(), "last" is equivalent to an
6658 iterator obtained by a call to end(), and that all invalid iterator
6659 arithmetic expressions are resolved as described in DR submitted by
6660 Thomas Mang regarding invalid iterator arithmetic expressions.</p>
6661
6662 <p>
6663 Furthermore, the resolutions of DR 202 are considered regarding
6664 equivalence relation and order of arguments for a call to pred.</p>
6665
6666 <p>
6667 All implementations known to the author of this Defect Report comply
6668 with these assumptions, apart from the impact of the alternative
6669 resolution of DR 202. Except for the changes implied by the resolutions
6670 of DR 202, no impact on current code is expected.</p>
6671
6672 <p>
6673 3) Proposed fixes:</p>
6674
6675 <p>
6676 Change 23.2.2.4 [lib.list.ops], paragraph 19 to:</p>
6677
6678 <p>
6679 "Effect: Erases all but the first element from every consecutive group
6680 of elements, referred to by the iterator i in the range [begin(),
6681 end()), for which the following conditions hold: *(i-1) == *i (for the
6682 version of unique with no argument) or pred(*(i-1), *i) != false (for
6683 the version of unique with a predicate argument)."</p>
6684
6685 <p>
6686 Comments to the new wording:</p>
6687
6688 <p>
6689 a) The new wording was influenced by DR 202 and the resolutions
6690 presented there. If DR 202 is resolved in another way, the proposed
6691 wording need also additional review.
6692 b) "Erases" refers in the author's opinion unambiguously to the member
6693 function "erase". In case there is doubt this might not be unamgibuous,
6694 a direct reference to the member function "erase" is suggested [Note:
6695 This would also imply a change of 23.2.2.4 [lib.list.ops], paragraph
6696 15.].
6697 c) The expression "(i - 1)" was left, but is expected that DR submitted
6698 by Thomas Mang regarding invalid iterator arithmetic expressions will
6699 take this into account.
6700 d) The wording "(for the version of unique with no argument)" and "(for
6701 the version of unique with a predicate argument)" was kept consciously
6702 for clarity.
6703 e) "begin()" substitutes "first", and "end()" substitutes "last". The
6704 range need adjustment from "[first + 1, last)" to "[begin(), end())" to
6705 ensure a valid range in case of an empty list.
6706 f) If it is considered that the wording is unclear whether it declares
6707 the element of a group which consists of only a single element
6708 implicitly to be the first element of this group [Note: Such an
6709 interpretation could eventually arise especially in case size() == 1] ,
6710 the following additional sentence is proposed: "If such a group of
6711 elements consists of only a single element, this element is also
6712 considered the first element."</p>
6713
6714 <p>
6715 Change 23.2.2.4 [lib.list.ops], paragraph 20 to:</p>
6716
6717 <p>
6718 "Throws: Nothing unless an exception is thrown by *(i-1) == *i or
6719 pred(*(i-1), *i)."</p>
6720
6721 <p>
6722 Comments to the new wording:</p>
6723
6724 <p>
6725 a) The wording regarding the conditions is identical to proposed
6726 23.2.2.4 [lib.list.ops], paragraph 19. If 23.2.2.4 [lib.list.ops],
6727 paragraph 19 is resolved in another way, the proposed wording need also
6728 additional review.
6729 b) The expression "(i - 1)" was left, but is expected that DR submitted
6730 by Thomas Mang regarding invalid iterator arithmetic expressions will
6731 take this into account.
6732 c) Typos fixed.</p>
6733
6734 <p>
6735 Change 23.2.2.4 [lib.list.ops], paragraph 21 to:</p>
6736
6737 <p>
6738 "Complexity: If empty() == false, exactly size() - 1 applications of the
6739 corresponding predicate, otherwise no applications of the corresponding
6740 predicate."</p>
6741
6742 <p>
6743 Comments to the new wording:</p>
6744
6745 <p>
6746 a) The new wording is supposed to also replace the proposed resolution
6747 of DR 315, which suffers from the problem of undefined "first" / "last".
6748 </p>
6749
6750 <p>
6751 5) References to other DRs:</p>
6752
6753 <p>See DR 202.
6754 See DR 239.
6755 See DR 315.
6756 See DR submitted by Thomas Mang regarding invalid iterator arithmetic
6757 expressions.</p>
6758
6759 <p><b>Proposed resolution:</b></p>
6760 <p>
6761 </p>
6762 <hr>
6763 <a name="492"><h3>492.&nbsp;Invalid iterator arithmetic expressions</h3></a><p><b>Section:</b>&nbsp;23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.containers"> [lib.containers]</a>, 24 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.iterators"> [lib.iterators]</a>, 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Thomas Mang&nbsp; <b>Date:</b>&nbsp;12 Dec 2004</p>
6764 <p>Various clauses other than clause 25 make use of iterator arithmetic not
6765 supported by the iterator category in question.
6766 Algorithms in clause 25 are exceptional because of 25 [lib.algorithms],
6767 paragraph 9, but this paragraph does not provide semantics to the
6768 expression "iterator - n", where n denotes a value of a distance type
6769 between iterators.</p>
6770
6771 <p>1) Examples of current wording:</p>
6772
6773 <p>Current wording outside clause 25:</p>
6774
6775 <p>
6776 23.2.2.4 [lib.list.ops], paragraphs 19-21: "first + 1", "(i - 1)",
6777 "(last - first)"
6778 23.3.1.1 [lib.map.cons], paragraph 4: "last - first"
6779 23.3.2.1 [lib.multimap.cons], paragraph 4: "last - first"
6780 23.3.3.1 [lib.set.cons], paragraph 4: "last - first"
6781 23.3.4.1 [lib.multiset.cons], paragraph 4: "last - first"
6782 24.4.1 [lib.reverse.iterators], paragraph 1: "(i - 1)"
6783 </p>
6784
6785 <p>
6786 [Important note: The list is not complete, just an illustration. The
6787 same issue might well apply to other paragraphs not listed here.]</p>
6788
6789 <p>None of these expressions is valid for the corresponding iterator
6790 category.</p>
6791
6792 <p>Current wording in clause 25:</p>
6793
6794 <p>
6795 25.1.1 [lib.alg.foreach], paragraph 1: "last - 1"
6796 25.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 -
6797 (last2-first2))"
6798 25.2.8 [lib.alg.unique], paragraph 1: "(i - 1)"
6799 25.2.8 [lib.alg.unique], paragraph 5: "(i - 1)"
6800 </p>
6801
6802 <p>
6803 However, current wording of 25 [lib.algorithms], paragraph 9 covers
6804 neither of these four cases:</p>
6805
6806 <p>Current wording of 25 [lib.algorithms], paragraph 9:</p>
6807
6808 <p>
6809 "In the description of the algorithms operator + and - are used for some
6810 of the iterator categories for which they do not have to be defined. In
6811 these cases the semantics of a+n is the same as that of</p>
6812 <pre>{X tmp = a;
6813 advance(tmp, n);
6814 return tmp;
6815 }
6816 </pre>
6817 <p>and that of b-a is the same as of return distance(a, b)"</p>
6818
6819 <p>
6820 This paragrpah does not take the expression "iterator - n" into account,
6821 where n denotes a value of a distance type between two iterators [Note:
6822 According to current wording, the expression "iterator - n" would be
6823 resolved as equivalent to "return distance(n, iterator)"]. Even if the
6824 expression "iterator - n" were to be reinterpreted as equivalent to
6825 "iterator + -n" [Note: This would imply that "a" and "b" were
6826 interpreted implicitly as values of iterator types, and "n" as value of
6827 a distance type], then 24.3.4/2 interfers because it says: "Requires: n
6828 may be negative only for random access and bidirectional iterators.",
6829 and none of the paragraphs quoted above requires the iterators on which
6830 the algorithms operate to be of random access or bidirectional category.
6831 </p>
6832
6833 <p>2) Description of intended behavior:</p>
6834
6835 <p>
6836 For the rest of this Defect Report, it is assumed that the expression
6837 "iterator1 + n" and "iterator1 - iterator2" has the semantics as
6838 described in current 25 [lib.algorithms], paragraph 9, but applying to
6839 all clauses. The expression "iterator1 - n" is equivalent to an
6840 result-iterator for which the expression "result-iterator + n" yields an
6841 iterator denoting the same position as iterator1 does. The terms
6842 "iterator1", "iterator2" and "result-iterator" shall denote the value of
6843 an iterator type, and the term "n" shall denote a value of a distance
6844 type between two iterators.</p>
6845
6846 <p>
6847 All implementations known to the author of this Defect Report comply
6848 with these assumptions.
6849 No impact on current code is expected.</p>
6850
6851 <p>3) Proposed fixes:</p>
6852
6853
6854 <p>Change 25 [lib.algorithms], paragraph 9 to:</p>
6855
6856 <p>
6857 "In the description of the algorithms operator + and - are used for some
6858 of the iterator categories for which they do not have to be defined. In
6859 this paragraph, a and b denote values of an iterator type, and n denotes
6860 a value of a distance type between two iterators. In these cases the
6861 semantics of a+n is the same as that of</p>
6862 <pre>{X tmp = a;
6863 advance(tmp, n);
6864 return tmp;
6865 }
6866 </pre>
6867 <p>,the semantics of a-n denotes the value of an iterator i for which the
6868 following condition holds:
6869 advance(i, n) == a,
6870 and that of b-a is the same as of
6871 return distance(a, b)".
6872 </p>
6873
6874 <p>Comments to the new wording:</p>
6875
6876 <p>
6877 a) The wording " In this paragraph, a and b denote values of an iterator
6878 type, and n denotes a value of a distance type between two iterators."
6879 was added so the expressions "b-a" and "a-n" are distinguished regarding
6880 the types of the values on which they operate.
6881 b) The wording ",the semantics of a-n denotes the value of an iterator i
6882 for which the following condition holds: advance(i, n) == a" was added
6883 to cover the expression 'iterator - n'. The wording "advance(i, n) == a"
6884 was used to avoid a dependency on the semantics of a+n, as the wording
6885 "i + n == a" would have implied. However, such a dependency might well
6886 be deserved.
6887 c) DR 225 is not considered in the new wording.
6888 </p>
6889
6890 <p>
6891 Proposed fixes regarding invalid iterator arithmetic expressions outside
6892 clause 25:</p>
6893
6894 <p>
6895 Either
6896 a) Move modified 25 [lib.algorithms], paragraph 9 (as proposed above)
6897 before any current invalid iterator arithmetic expression. In that case,
6898 the first sentence of 25 [lib.algorithms], paragraph 9, need also to be
6899 modified and could read: "For the rest of this International Standard,
6900 ...." / "In the description of the following clauses including this
6901 ...." / "In the description of the text below ..." etc. - anyways
6902 substituting the wording "algorithms", which is a straight reference to
6903 clause 25.
6904 In that case, 25 [lib.algorithms] paragraph 9 will certainly become
6905 obsolete.
6906 Alternatively,
6907 b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
6908 paragraph 9, to the beginning of each clause containing invalid iterator
6909 arithmetic expressions.
6910 Alternatively,
6911 c) Fix each paragraph (both current wording and possible resolutions of
6912 DRs) containing invalid iterator arithmetic expressions separately.
6913 </p>
6914
6915 <p>5) References to other DRs:</p>
6916
6917 <p>
6918 See DR 225.
6919 See DR 237. The resolution could then also read "Linear in last -
6920 first".
6921 </p>
6922 <p><b>Proposed resolution:</b></p>
6923 <p>
6924 </p>
6925 <hr>
6926 <a name="493"><h3>493.&nbsp;Undefined Expression in Input Iterator Note Title</h3></a><p><b>Section:</b>&nbsp;24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Chris Jefferson&nbsp; <b>Date:</b>&nbsp;13 Dec 2004</p>
6927 <p>1) In 24.1.1/3, the following text is currently present.</p>
6928
6929 <p>"Note: For input iterators, a==b does not imply ++a=++b (Equality does
6930 not guarantee the substitution property or referential transparency)."</p>
6931
6932 <p>However, when in Table 72, part of the definition of ++r is given as:</p>
6933
6934 <p>"pre: r is dereferenceable.
6935 post: any copies of the previous value of r are no longer required
6936 either to be dereferenceable ..."</p>
6937
6938 <p>While a==b does not imply that b is a copy of a, this statement should
6939 perhaps still be made more clear.</p>
6940
6941 <p>2) There are no changes to intended behaviour</p>
6942
6943 <p>
6944 3) This Note should be altered to say "Note: For input iterators a==b,
6945 when its behaviour is defined ++a==++b may still be false (Equality does
6946 not guarantee the substitution property or referential transparency).</p>
6947
6948 <p><b>Proposed resolution:</b></p>
6949 <p>
6950 </p>
6951 <hr>
6952 <a name="494"><h3>494.&nbsp;Wrong runtime complexity for associative container's insert and delete</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Hans B os&nbsp; <b>Date:</b>&nbsp;19 Dec 2004</p>
6953 <p>According to [lib.associative.reqmts] table 69, the runtime comlexity
6954 of insert(p, t) and erase(q) can be done in amortized constant time.</p>
6955
6956 <p>It was my understanding that an associative container could be
6957 implemented as a balanced binary tree.</p>
6958
6959 <p>For inser(p, t), you 'll have to iterate to p's next node to see if t
6960 can be placed next to p.  Furthermore, the insertion usually takes
6961 place at leaf nodes. An insert next to the root node will be done at
6962 the left of the root next node</p>
6963
6964 <p>So when p is the root node you 'll have to iterate from the root to
6965 its next node, which  takes O(log(size)) time in a balanced tree.</p>
6966
6967 <p>If you insert all values with insert(root, t) (where root is the
6968 root of the tree before insertion) then each insert takes O(log(size))
6969 time.  The amortized complexity per insertion will be O(log(size))
6970 also.</p>
6971
6972 <p>For erase(q), the normal algorithm for deleting a node that has no
6973 empty left or right subtree, is to iterate to the next (or previous),
6974 which is a leaf node. Then exchange the node with the next and delete
6975 the leaf node.  Furthermore according to DR 130, erase should return
6976 the next node of the node erased.  Thus erasing the root node,
6977 requires iterating to the next node.</p>
6978
6979 <p>Now if you empty a map by deleting the root node until the map is
6980 empty, each operation will take O(log(size)), and the amortized
6981 complexity is still O(log(size)).</p>
6982
6983 <p>The operations can be done in amortized constant time if iterating
6984 to the next node can be done in (non amortized) constant time.  This
6985 can be done by putting all nodes in a double linked list.  This
6986 requires two extra links per node.  To me this is a bit overkill since
6987 you can already efficiently insert or erase ranges with erase(first,
6988 last) and insert(first, last).</p>
6989
6990 <p><b>Proposed resolution:</b></p>
6991 <p>
6992 </p>
6993 <p>----- End of document -----</p>
6994 </body></html>