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>
   3 <head><title>C++ Standard Library Active Issues List</title></head>
   4 <body bgcolor="#ffffff" text="#000000">
   5 <table>
   6 <tr>
   7 <td align="left">Doc. no.</td>
   8 <td align="left">J16/02-0048 = WG21 N1390</td>
   9 </tr>
  10 <tr>
  11 <td align="left">Date:</td>
  12 <td align="left">10 Sep 2002</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 </table>
  23 <h1>C++ Standard Library Active Issues List (Revision 23)</h1>
  24   <p>Reference ISO/IEC IS 14882:1998(E)</p>
  25   <p>Also see:</p>
  26   <ul>
  27       <li>
  28 <a href="lwg-toc.html">Table of Contents</a> for all library issues.</li>
  29       <li>
  30 <a href="lwg-index.html">Index by Section</a> for all library issues.</li>
  31       <li>
  32 <a href="lwg-status.html">Index by Status</a> for all library issues.</li>
  33       <li><a href="lwg-defects.html">Library Defect Reports List</a></li>
  34       <li><a href="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 or other extensions. </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="lwg-active.html#New">New</a>, <a href="lwg-active.html#Open">Open</a>,
  45   <a href="lwg-active.html#Ready">Ready</a>, and <a href="lwg-active.html#Review">Review</a>. See
  46   <a href="lwg-defects.html">Library Defect Reports List</a> for issues considered defects and
  47   <a href="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.dkuug.dk/jtc1/sc22/wg21">http://www.dkuug.dk/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 C++ FAQ at <a href="http://www.research.att.com/~austern/csc/faq.html">http://www.research.att.com/~austern/csc/faq.html</a>.
  81   Public discussion of C++ Standard related issues occurs on <a href="news:comp.std.c%2B%2B">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>R23:
  92 Pre-Santa Cruz mailing.  Added new issues <a href="lwg-active.html#367">367</a>-<a href="lwg-active.html#382">382</a>.
  93 Moved issues in the TC to TC status.
  94 </li>
  95 <li>R22:
  96 Post-Cura&ccedil;ao mailing.  Added new issues <a href="lwg-active.html#362">362</a>-<a href="lwg-active.html#366">366</a>.
  97 </li>
  98 <li>R21:
  99 Pre-Cura&ccedil;ao mailing.  Added new issues <a href="lwg-closed.html#351">351</a>-<a href="lwg-active.html#361">361</a>.
 100 </li>
 101 <li>R20:
 102 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 103 new issues <a href="lwg-active.html#336">336</a>-<a href="lwg-active.html#350">350</a>, of which issues
 104 <a href="lwg-active.html#347">347</a>-<a href="lwg-active.html#350">350</a> were added since Redmond, hence
 105 not discussed at the meeting.
 106
 107 All Ready issues were moved to DR status, with the exception of issues
 108 <a href="lwg-defects.html#284">284</a>, <a href="lwg-active.html#241">241</a>, and <a href="lwg-closed.html#267">267</a>.
 109
 110 Noteworthy issues discussed at Redmond include
 111 <a href="lwg-active.html#120">120</a> <a href="lwg-active.html#202">202</a>, <a href="lwg-active.html#226">226</a>, <a href="lwg-active.html#233">233</a>,
 112 <a href="lwg-defects.html#270">270</a>, <a href="lwg-active.html#253">253</a>, <a href="lwg-active.html#254">254</a>, <a href="lwg-active.html#323">323</a>.
 113 </li>
 114 <li>R19:
 115 Pre-Redmond mailing.  Added new issues
 116 <a href="lwg-active.html#323">323</a>-<a href="lwg-defects.html#335">335</a>.
 117 </li>
 118 <li>R18:
 119 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
 120 Added new issues <a href="lwg-defects.html#312">312</a>-<a href="lwg-defects.html#317">317</a>, and discussed
 121 new issues <a href="lwg-defects.html#271">271</a>-<a href="lwg-closed.html#314">314</a>.
 122
 123 Changed status of issues
 124 <a href="lwg-defects.html#103">103</a> <a href="lwg-defects.html#118">118</a> <a href="lwg-defects.html#136">136</a> <a href="lwg-defects.html#153">153</a>
 125 <a href="lwg-defects.html#165">165</a> <a href="lwg-defects.html#171">171</a> <a href="lwg-defects.html#183">183</a> <a href="lwg-defects.html#184">184</a>
 126 <a href="lwg-defects.html#185">185</a> <a href="lwg-defects.html#186">186</a> <a href="lwg-defects.html#214">214</a> <a href="lwg-defects.html#221">221</a>
 127 <a href="lwg-defects.html#234">234</a> <a href="lwg-defects.html#237">237</a> <a href="lwg-defects.html#243">243</a> <a href="lwg-defects.html#248">248</a>
 128 <a href="lwg-defects.html#251">251</a> <a href="lwg-defects.html#252">252</a> <a href="lwg-defects.html#256">256</a> <a href="lwg-defects.html#260">260</a>
 129 <a href="lwg-defects.html#261">261</a> <a href="lwg-defects.html#262">262</a> <a href="lwg-defects.html#263">263</a> <a href="lwg-defects.html#265">265</a>
 130 <a href="lwg-defects.html#268">268</a>
 131 to DR.
 132
 133 Changed status of issues
 134 <a href="lwg-defects.html#49">49</a>  <a href="lwg-defects.html#109">109</a> <a href="lwg-defects.html#117">117</a> <a href="lwg-defects.html#182">182</a>
 135 <a href="lwg-defects.html#228">228</a> <a href="lwg-defects.html#230">230</a> <a href="lwg-defects.html#232">232</a> <a href="lwg-defects.html#235">235</a>
 136 <a href="lwg-defects.html#238">238</a> <a href="lwg-active.html#241">241</a> <a href="lwg-defects.html#242">242</a> <a href="lwg-defects.html#250">250</a>
 137 <a href="lwg-defects.html#259">259</a> <a href="lwg-defects.html#264">264</a> <a href="lwg-defects.html#266">266</a> <a href="lwg-closed.html#267">267</a>
 138 <a href="lwg-defects.html#271">271</a> <a href="lwg-defects.html#272">272</a> <a href="lwg-defects.html#273">273</a> <a href="lwg-defects.html#275">275</a>
 139 <a href="lwg-defects.html#281">281</a> <a href="lwg-defects.html#284">284</a> <a href="lwg-defects.html#285">285</a> <a href="lwg-defects.html#286">286</a>
 140 <a href="lwg-defects.html#288">288</a> <a href="lwg-defects.html#292">292</a> <a href="lwg-defects.html#295">295</a> <a href="lwg-defects.html#297">297</a>
 141 <a href="lwg-defects.html#298">298</a> <a href="lwg-defects.html#301">301</a> <a href="lwg-defects.html#303">303</a> <a href="lwg-defects.html#306">306</a>
 142 <a href="lwg-defects.html#307">307</a> <a href="lwg-defects.html#308">308</a> <a href="lwg-defects.html#312">312</a>
 143 to Ready.
 144
 145 Closed issues
 146 <a href="lwg-closed.html#111">111</a> <a href="lwg-closed.html#277">277</a> <a href="lwg-closed.html#279">279</a> <a href="lwg-closed.html#287">287</a>
 147 <a href="lwg-closed.html#289">289</a> <a href="lwg-closed.html#293">293</a> <a href="lwg-closed.html#302">302</a> <a href="lwg-closed.html#313">313</a>
 148 <a href="lwg-closed.html#314">314</a>
 149 as NAD.
 150
 151 </li>
 152 <li>R17:
 153 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 154 resolutions for issues <a href="lwg-defects.html#49">49</a>, <a href="lwg-defects.html#76">76</a>, <a href="lwg-active.html#91">91</a>, <a href="lwg-defects.html#235">235</a>, <a href="lwg-defects.html#250">250</a>, <a href="lwg-closed.html#267">267</a>.
 155 Added new issues <a href="lwg-active.html#278">278</a>-<a href="lwg-defects.html#311">311</a>.
 156 </li>
 157 <li>R16:
 158 post-Toronto mailing; reflects actions taken in Toronto. Added new
 159 issues <a href="lwg-defects.html#265">265</a>-<a href="lwg-closed.html#277">277</a>.  Changed status of issues
 160 <a href="lwg-defects.html#3">3</a>, <a href="lwg-defects.html#8">8</a>, <a href="lwg-defects.html#9">9</a>, <a href="lwg-defects.html#19">19</a>,
 161 <a href="lwg-defects.html#26">26</a>, <a href="lwg-defects.html#31">31</a>, <a href="lwg-defects.html#61">61</a>,
 162 <a href="lwg-defects.html#63">63</a>, <a href="lwg-defects.html#86">86</a>, <a href="lwg-defects.html#108">108</a>,
 163 <a href="lwg-defects.html#112">112</a>, <a href="lwg-defects.html#114">114</a>, <a href="lwg-defects.html#115">115</a>,
 164 <a href="lwg-defects.html#122">122</a>, <a href="lwg-defects.html#127">127</a>, <a href="lwg-defects.html#129">129</a>,
 165 <a href="lwg-defects.html#134">134</a>, <a href="lwg-defects.html#137">137</a>, <a href="lwg-defects.html#142">142</a>,
 166 <a href="lwg-defects.html#144">144</a>, <a href="lwg-defects.html#146">146</a>, <a href="lwg-defects.html#147">147</a>,
 167 <a href="lwg-defects.html#159">159</a>, <a href="lwg-defects.html#164">164</a>, <a href="lwg-defects.html#170">170</a>,
 168 <a href="lwg-defects.html#181">181</a>, <a href="lwg-defects.html#199">199</a>, <a href="lwg-defects.html#208">208</a>,
 169 <a href="lwg-defects.html#209">209</a>, <a href="lwg-defects.html#210">210</a>, <a href="lwg-defects.html#211">211</a>,
 170 <a href="lwg-defects.html#212">212</a>, <a href="lwg-defects.html#217">217</a>, <a href="lwg-defects.html#220">220</a>,
 171 <a href="lwg-defects.html#222">222</a>, <a href="lwg-defects.html#223">223</a>, <a href="lwg-defects.html#224">224</a>,
 172 <a href="lwg-defects.html#227">227</a> to &quot;DR&quot;.  Reopened issue <a href="lwg-active.html#23">23</a>. Reopened
 173 issue <a href="lwg-active.html#187">187</a>. Changed issues <a href="lwg-closed.html#2">2</a> and
 174 <a href="lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="lwg-defects.html#17">17</a>. Fixed
 175 issue <a href="lwg-defects.html#70">70</a>: signature should be changed both places it
 176 appears. Fixed issue <a href="lwg-defects.html#160">160</a>: previous version didn't fix
 177 the bug in enough places.
 178 </li>
 179 <li>R15:
 180 pre-Toronto mailing. Added issues
 181 <a href="lwg-active.html#233">233</a>-<a href="lwg-defects.html#264">264</a>. Some small HTML formatting
 182 changes so that we pass Weblint tests.
 183 </li>
 184 <li>R14:
 185 post-Tokyo II mailing; reflects committee actions taken in
 186 Tokyo. Added issues <a href="lwg-defects.html#228">228</a> to <a href="lwg-defects.html#232">232</a>. (00-0019R1/N1242)
 187 </li>
 188 <li>R13:
 189 pre-Tokyo II updated: Added issues <a href="lwg-defects.html#212">212</a> to <a href="lwg-defects.html#227">227</a>.
 190 </li>
 191 <li>R12:
 192 pre-Tokyo II mailing: Added issues <a href="lwg-defects.html#199">199</a> to
 193 <a href="lwg-defects.html#211">211</a>. Added &quot;and paragraph 5&quot; to the proposed resolution
 194 of issue <a href="lwg-defects.html#29">29</a>.  Add further rationale to issue
 195 <a href="lwg-closed.html#178">178</a>.
 196 </li>
 197 <li>R11:
 198 post-Kona mailing: Updated to reflect LWG and full committee actions
 199 in Kona (99-0048/N1224). Note changed resolution of issues
 200 <a href="lwg-closed.html#4">4</a> and <a href="lwg-defects.html#38">38</a>. Added issues <a href="lwg-closed.html#196">196</a>
 201 to <a href="lwg-defects.html#198">198</a>. Closed issues list split into &quot;defects&quot; and
 202 &quot;closed&quot; documents.  Changed the proposed resolution of issue
 203 <a href="lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
 204 of issue <a href="lwg-defects.html#38">38</a>.
 205 </li>
 206 <li>R10:
 207 pre-Kona updated.  Added proposed resolutions <a href="lwg-defects.html#83">83</a>,
 208 <a href="lwg-defects.html#86">86</a>, <a href="lwg-active.html#91">91</a>, <a href="lwg-active.html#92">92</a>,
 209 <a href="lwg-defects.html#109">109</a>. Added issues <a href="lwg-closed.html#190">190</a> to
 210 <a href="lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 211 </li>
 212 <li>R9:
 213 pre-Kona mailing.  Added issues <a href="lwg-closed.html#140">140</a> to
 214 <a href="lwg-defects.html#189">189</a>. Issues list split into separate &quot;active&quot; and
 215 &quot;closed&quot; documents. (99-0030/N1206, 25 Aug 99)
 216 </li>
 217 <li>R8:
 218 post-Dublin mailing. Updated to reflect LWG and full committee actions
 219 in Dublin. (99-0016/N1193, 21 Apr 99)
 220 </li>
 221 <li>R7:
 222 pre-Dublin updated: Added issues <a href="lwg-closed.html#130">130</a>, <a href="lwg-closed.html#131">131</a>,
 223 <a href="lwg-defects.html#132">132</a>, <a href="lwg-defects.html#133">133</a>, <a href="lwg-defects.html#134">134</a>,
 224 <a href="lwg-closed.html#135">135</a>, <a href="lwg-defects.html#136">136</a>, <a href="lwg-defects.html#137">137</a>,
 225 <a href="lwg-closed.html#138">138</a>, <a href="lwg-defects.html#139">139</a> (31 Mar 99)
 226 </li>
 227 <li>R6:
 228 pre-Dublin mailing. Added issues <a href="lwg-defects.html#127">127</a>, <a href="lwg-closed.html#128">128</a>,
 229 and <a href="lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 230 </li>
 231 <li>R5:
 232 update issues <a href="lwg-defects.html#103">103</a>, <a href="lwg-defects.html#112">112</a>; added issues
 233 <a href="lwg-defects.html#114">114</a> to <a href="lwg-defects.html#126">126</a>. Format revisions to prepare
 234 for making list public. (30 Dec 98)
 235 </li>
 236 <li>R4:
 237 post-Santa Cruz II updated: Issues <a href="lwg-defects.html#110">110</a>,
 238 <a href="lwg-closed.html#111">111</a>, <a href="lwg-defects.html#112">112</a>, <a href="lwg-closed.html#113">113</a> added, several
 239 issues corrected. (22 Oct 98)
 240 </li>
 241 <li>R3:
 242 post-Santa Cruz II: Issues <a href="lwg-closed.html#94">94</a> to <a href="lwg-defects.html#109">109</a>
 243 added, many issues updated to reflect LWG consensus (12 Oct 98)
 244 </li>
 245 <li>R2:
 246 pre-Santa Cruz II: Issues <a href="lwg-closed.html#73">73</a> to <a href="lwg-closed.html#93">93</a> added,
 247 issue <a href="lwg-defects.html#17">17</a> updated. (29 Sep 98)
 248 </li>
 249 <li>R1:
 250 Correction to issue <a href="lwg-defects.html#55">55</a> resolution, <a href="lwg-defects.html#60">60</a> code
 251 format, <a href="lwg-defects.html#64">64</a> title. (17 Sep 98)
 252 </li>
 253 </ul>
 254 <h2>
 255 <a name="Status"></a>Issue Status</h2>
 256   <p>
 257 <b><a name="New">New</a></b> - The issue has not yet been
 258   reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a
 259   suggestion from the issue submitter, and should not be construed as
 260   the view of LWG.</p>
 261
 262   <p>
 263 <b><a name="Open">Open</a></b> - The LWG has discussed the issue
 264   but is not yet ready to move the issue forward. There are several
 265   possible reasons for open status:</p>
 266      <ul>
 267         <li>Consensus may have not yet have been reached as to how to deal
 268             with the issue.</li>
 269         <li>Informal consensus may have been reached, but the LWG awaits
 270             exact <b>Proposed Resolution</b> wording for review.</li>
 271         <li>The LWG wishes to consult additional technical experts before
 272             proceeding.</li>
 273         <li>The issue may require further study.</li>
 274      </ul>
 275
 276   <p>A <b>Proposed Resolution</b> for an open issue is still not be
 277   construed as the view of LWG. Comments on the current state of
 278   discussions are often given at the end of open issues in an italic
 279   font. Such comments are for information only and should not be given
 280   undue importance.</p>
 281
 282   <p>
 283 <b><a name="Dup">Dup</a></b> - The LWG has reached consensus that
 284   the issue is a duplicate of another issue, and will not be further
 285   dealt with. A <b>Rationale</b> identifies the duplicated issue's
 286   issue number.  </p>
 287
 288   <p>
 289 <b><a name="NAD">NAD</a></b> - The LWG has reached consensus that
 290   the issue is not a defect in the Standard, and the issue is ready to
 291   forward to the full committee as a proposed record of response. A
 292   <b>Rationale</b> discusses the LWG's reasoning.</p>
 293
 294   <p>
 295 <b><a name="Review">Review</a></b> - Exact wording of a
 296   <b>Proposed Resolution</b> is now available for review on an issue
 297   for which the LWG previously reached informal consensus.</p>
 298
 299   <p>
 300 <b><a name="Ready">Ready</a></b> - The LWG has reached consensus
 301   that the issue is a defect in the Standard, the <b>Proposed
 302   Resolution</b> is correct, and the issue is ready to forward to the
 303   full committee for further action as a Defect Report (DR).</p>
 304
 305   <p>
 306 <b><a name="DR">DR</a></b> - (Defect Report) - The full J16
 307   committee has voted to forward the issue to the Project Editor to be
 308   processed as a Potential Defect Report. The Project Editor reviews
 309   the issue, and then forwards it to the WG21 Convenor, who returns it
 310   to the full committee for final disposition. This issues list
 311   accords the status of DR to all these Defect Reports regardless of
 312   where they are in that process.</p>
 313
 314   <p>
 315 <b><a name="TC">TC</a></b> - (Technical Corrigenda) - The full
 316   WG21 committee has voted to accept the Defect Report's Proposed
 317   Resolution as a Technical Corrigenda.  Action on this issue is thus
 318   complete and no further action is possible under ISO rules.</p>
 319
 320   <p>
 321 <b><a name="RR">RR</a></b> - (Record of Response) - The full WG21
 322   committee has determined that this issue is not a defect in the
 323   Standard. Action on this issue is thus complete and no further
 324   action is possible under ISO rules.</p>
 325
 326   <p>
 327 <b><a name="Future">Future</a></b> - In addition to the regular
 328   status, the LWG believes that this issue should be revisited at the
 329   next revision of the standard.  It is usually paired with NAD.</p>
 330
 331   <p>Issues are always given the status of <a href="lwg-active.html#New">New</a> when
 332   they first appear on the issues list. They may progress to
 333   <a href="lwg-active.html#Open">Open</a> or <a href="lwg-active.html#Review">Review</a> while the LWG
 334   is actively working on them. When the LWG has reached consensus on
 335   the disposition of an issue, the status will then change to
 336   <a href="lwg-active.html#Dup">Dup</a>, <a href="lwg-active.html#NAD">NAD</a>, or <a href="lwg-active.html#Ready">Ready</a> as appropriate.  Once the full J16 committee votes to
 337   forward Ready issues to the Project Editor, they are given the
 338   status of Defect Report ( <a href="lwg-active.html#DR">DR</a>). These in turn may
 339   become the basis for Technical Corrigenda (<a href="lwg-active.html#TC">TC</a>),
 340   or are closed without action other than a Record of Response
 341   (<a href="lwg-active.html#RR">RR</a> ). The intent of this LWG process is that
 342   only issues which are truly defects in the Standard move to the
 343   formal ISO DR status.
 344   </p>
 345
 346 <h2>Active Issues</h2>
 347 <hr>
 348 <a name="23"><h3>23.&nbsp;Num_get overflow result</h3></a><p>
 349 <b>Section:</b>&nbsp;22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 350 <p>The current description of numeric input does not account for the possibility of
 351 overflow. This is an implicit result of changing the description to rely on the definition
 352 of scanf() (which fails to report overflow), and conflicts with the documented behavior of
 353 traditional and current implementations. </p>
 354
 355 <p>Users expect, when reading a character sequence that results in a value unrepresentable
 356 in the specified type, to have an error reported. The standard as written does not permit
 357 this. </p>
 358
 359 <p><b>Further comments from Dietmar:</b></p>
 360
 361 <p>
 362 I don't feel comfortable with the proposed resolution to issue 23: It
 363 kind of simplifies the issue to much. Here is what is going on:
 364 </p>
 365
 366 <p>
 367 Currently, the behavior of numeric overflow is rather counter intuitive
 368 and hard to trace, so I will describe it briefly:
 369 </p>
 370
 371 <ul>
 372   <li>
 373     According to 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>
 374     paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
 375     return an input error; otherwise a value is converted to the rules
 376     of <tt>scanf</tt>.
 377   </li>
 378   <li>
 379     <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>.
 380   </li>
 381   <li>
 382     <tt>fscanf()</tt> returns an input failure if during conversion no
 383     character matching the conversion specification could be extracted
 384     before reaching EOF. This is the only reason for <tt>fscanf()</tt>
 385     to fail due to an input error and clearly does not apply to the case
 386     of overflow.
 387   </li>
 388   <li>
 389     Thus, the conversion is performed according to the rules of
 390     <tt>fscanf()</tt> which basically says that <tt>strtod</tt>,
 391     <tt>strtol()</tt>, etc. are to be used for the conversion.
 392   </li>
 393   <li>
 394     The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as
 395     many matching characters as there are and on overflow continue to
 396     consume matching characters but also return a value identical to
 397     the maximum (or minimum for signed types if there was a leading minus)
 398     value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>.
 399   </li>
 400   <li>
 401     Thus, according to the current wording in the standard, overflows
 402     can be detected! All what is to be done is to check <tt>errno</tt>
 403     after reading an element and, of course, clearing <tt>errno</tt>
 404     before trying a conversion. With the current wording, it can be
 405     detected whether the overflow was due to a positive or negative
 406     number for signed types.
 407   </li>
 408 </ul>
 409
 410 <p><b>Further discussion from Redmond:</b></p>
 411
 412 <p>The basic problem is that we've defined our behavior,
 413 including our error-reporting behavior, in terms of C90.  However,
 414 C90's method of reporting overflow in scanf is not technically an
 415 &quot;input error&quot;.  The <tt>strto_*</tt> functions are more precise.</p>
 416
 417 <p>There was general consensus that <tt>failbit</tt> should be set
 418 upon overflow.  We considered three options based on this:</p>
 419 <ol>
 420 <li>Set failbit upon conversion error (including overflow), and
 421     don't store any value.</li>
 422 <li>Set failbit upon conversion error, and also set <tt>errno</tt> to
 423     indicated the precise nature of the error.</li>
 424 <li>Set failbit upon conversion error.  If the error was due to
 425     overflow, store +-numeric_limits&lt;T&gt;::max() as an
 426     overflow indication.</li>
 427 </ol>
 428
 429 <p>Straw poll: (1) 5; (2) 0; (3) 8.</p>
 430
 431 <p>PJP will provide wording.</p>
 432
 433 <p><b>Proposed resolution:</b></p>
 434 <hr>
 435 <a name="44"><h3>44.&nbsp;Iostreams use operator== on int_type values</h3></a><p>
 436 <b>Section:</b>&nbsp;27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 437 <p>Many of the specifications for iostreams specify that character
 438 values or their int_type equivalents are compared using operators ==
 439 or !=, though in other places traits::eq() or traits::eq_int_type is
 440 specified to be used throughout. This is an inconsistency; we should
 441 change uses of == and != to use the traits members instead. </p>
 442 <p><b>Proposed resolution:</b></p>
 443
 444 <p><i>[Kona: Nathan to supply proposed wording]</i></p>
 445
 446 <p><i>[
 447 Tokyo: the LWG reaffirmed that this is a defect, and requires careful
 448 review of clause 27 as the changes are context sensitive.
 449 ]</i></p>
 450
 451 <hr>
 452 <a name="91"><h3>91.&nbsp;Description of operator&gt;&gt; and getline() for string&lt;&gt; might cause endless loop</h3></a><p>
 453 <b>Section:</b>&nbsp;21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
 454 <p>Operator &gt;&gt; and getline() for strings read until eof()
 455 in the input stream is true. However, this might never happen, if the
 456 stream can't read anymore without reaching EOF. So shouldn't it be
 457 changed into that it reads until !good() ? </p>
 458 <p><b>Proposed resolution:</b></p>
 459 <p>In 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>, paragraph 1, replace:</p>
 460 <blockquote>
 461 Effects: Begins by constructing a sentry object k as if k were
 462 constructed by typename basic_istream&lt;charT,traits&gt;::sentry k( is). If
 463 bool( k) is true, it calls str.erase() and then extracts characters
 464 from is and appends them to str as if by calling str.append(1, c). If
 465 is.width() is greater than zero, the maximum number n of characters
 466 appended is is.width(); otherwise n is str.max_size(). Characters are
 467 extracted and appended until any of the following occurs:
 468 </blockquote>
 469 <p>with:</p>
 470 <blockquote>
 471 Effects: Behaves as a formatted input function (27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>).  After constructing a sentry object, if the
 472 sentry converts to true, calls str.erase() and then extracts
 473 characters from is and appends them to str as if by calling
 474 str.append(1,c). If is.width() is greater than zero, the maximum
 475 number n of characters appended is is.width(); otherwise n is
 476 str.max_size(). Characters are extracted and appended until any of the
 477 following occurs:
 478 </blockquote>
 479
 480 <p>In 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>, paragraph 6, replace</p>
 481 <blockquote>
 482 Effects: Begins by constructing a sentry object k as if by typename
 483 basic_istream&lt;charT,traits&gt;::sentry k( is, true). If bool( k) is true,
 484 it calls str.erase() and then extracts characters from is and appends
 485 them to str as if by calling str.append(1, c) until any of the
 486 following occurs:
 487 </blockquote>
 488 <p>with:</p>
 489 <blockquote>
 490 Effects: Behaves as an unformatted input function (27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), except that it does not affect the value returned
 491 by subsequent calls to basic_istream&lt;&gt;::gcount().  After
 492 constructing a sentry object, if the sentry converts to true, calls
 493 str.erase() and then extracts characters from is and appends them to
 494 str as if by calling str.append(1,c) until any of the following
 495 occurs:
 496 </blockquote>
 497
 498 <p><i>[Redmond: Made changes in proposed resolution.  <tt>operator&gt;&gt;</tt>
 499 should be a formatted input function, not an unformatted input function.
 500 <tt>getline</tt> should not be required to set <tt>gcount</tt>, since
 501 there is no mechanism for <tt>gcount</tt> to be set except by one of
 502 <tt>basic_istream</tt>'s member functions.]</i></p>
 503
 504 <p><i>[Cura&ccedil;ao: Nico agrees with proposed resolution.]</i></p>
 505
 506 <p><b>Rationale:</b></p>
 507 <p>The real issue here is whether or not these string input functions
 508 get their characters from a streambuf, rather than by calling an
 509 istream's member functions, a streambuf signals failure either by
 510 returning eof or by throwing an exception; there are no other
 511 possibilities.  The proposed resolution makes it clear that these two
 512 functions do get characters from a streambuf.</p>
 513 <hr>
 514 <a name="92"><h3>92.&nbsp;Incomplete Algorithm Requirements</h3></a><p>
 515 <b>Section:</b>&nbsp;25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
 516 <p>The standard does not state, how often a function object is copied,
 517 called, or the order of calls inside an algorithm. This may lead to
 518 surprising/buggy behavior. Consider the following example: </p>
 519
 520 <pre>class Nth {    // function object that returns true for the nth element
 521   private:
 522     int nth;     // element to return true for
 523     int count;   // element counter
 524   public:
 525     Nth (int n) : nth(n), count(0) {
 526     }
 527     bool operator() (int) {
 528         return ++count == nth;
 529     }
 530 };
 531 ....
 532 // remove third element
 533     list&lt;int&gt;::iterator pos;
 534     pos = remove_if(coll.begin(),coll.end(),  // range
 535                     Nth(3)),                  // remove criterion
 536     coll.erase(pos,coll.end()); </pre>
 537
 538 <p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
 539 happens because the usual implementation of the algorithm copies the
 540 function object internally: </p>
 541
 542 <pre>template &lt;class ForwIter, class Predicate&gt;
 543 ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op)
 544 {
 545     beg = find_if(beg, end, op);
 546     if (beg == end) {
 547         return beg;
 548     }
 549     else {
 550         ForwIter next = beg;
 551         return remove_copy_if(++next, end, beg, op);
 552     }
 553 } </pre>
 554
 555 <p>The algorithm uses find_if() to find the first element that should
 556 be removed. However, it then uses a copy of the passed function object
 557 to process the resulting elements (if any). Here, Nth is used again
 558 and removes also the sixth element. This behavior compromises the
 559 advantage of function objects being able to have a state. Without any
 560 cost it could be avoided (just implement it directly instead of
 561 calling find_if()). </p>
 562 <p><b>Proposed resolution:</b></p>
 563 <p> In [lib.function.objects] 20.3 Function objects add as new
 564 paragraph 6 (or insert after paragraph 1): </p>
 565
 566 <p>Option 1: </p>
 567 <blockquote>
 568 Predicates are functions or function objects that fulfill the
 569 following requirements:<br> &nbsp; - They return a Boolean value (bool
 570 or a value convertible to bool)<br> &nbsp; - It doesn't matter for the
 571 behavior of a predicate how often it is copied or assigned and how
 572 often it is called.
 573 </blockquote>
 574
 575 <p>Option 2: </p>
 576 <blockquote>
 577 - if it's a function:<br> &nbsp; - All calls with the same
 578 argument values yield the same result.<br> - if it's a function
 579 object:<br> &nbsp; - In any sequence of calls to operator () without
 580 calling any non-constant member function, all calls with the same
 581 argument values yield the same result.&nbsp;<br> - After an assignment
 582 or copy both objects return the same result for the same values.
 583 </blockquote>
 584
 585 <p><i>[Santa Cruz: The LWG believes that there may be more to this than
 586 meets the eye. It applies to all function objects, particularly
 587 predicates. Two questions: (1) must a function object be
 588 copyable? (2) how many times is a function object called?&nbsp; These
 589 are in effect questions about state.&nbsp; Function objects appear to
 590 require special copy semantics to make state work, and may fail if
 591 calling alters state and calling occurs an unexpected number of
 592 times.]</i></p>
 593
 594 <p><i>[Dublin: Pete Becker felt that this may not be a defect,
 595 but rather something that programmers need to be educated about.
 596 There was discussion of adding wording to the effect that the number
 597 and order of calls to function objects, including predicates, not
 598 affect the behavior of the function object.]</i></p>
 599
 600 <p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
 601 have a clear statement of &quot;predicate&quot; in the
 602 standard. People including me seemed to think &quot;a function
 603 returning a Boolean value and being able to be called by an STL
 604 algorithm or be used as sorting criterion or ... is a
 605 predicate&quot;. But a predicate has more requirements: It should
 606 never change its behavior due to a call or being copied. IMHO we have
 607 to state this in the standard. If you like, see section 8.1.4 of my
 608 library book for a detailed discussion.]</i></p>
 609
 610 <p><i>[Kona: Nico will provide wording to the effect that &quot;unless
 611 otherwise specified, the number of copies of and calls to function
 612 objects by algorithms is unspecified&quot;.&nbsp; Consider placing in
 613 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> after paragraph 9.]</i></p>
 614
 615 <p><i>[Pre-Tokyo: Angelika Langer comments: if the resolution is
 616 that algorithms are free to copy and pass around any function objects,
 617 then it is a valid question whether they are also allowed to change
 618 the type information from reference type to value type.]</i></p>
 619
 620 <p><i>[Tokyo: Nico will discuss this further with Matt as there are
 621 multiple problems beyond the underlying problem of no definition of
 622 &quot;Predicate&quot;.]</i></p>
 623
 624 <p><i>[Post-Tokyo: Nico provided the above proposed
 625 resolutions.]</i></p>
 626
 627 <p><i>[Cura&ccedil;ao: Nico will provide wording to make options clearer: are
 628 the exclusive, or is one a superset of the other?]</i></p>
 629
 630 <hr>
 631 <a name="96"><h3>96.&nbsp;Vector&lt;bool&gt; is not a container</h3></a><p>
 632 <b>Section:</b>&nbsp;23.2.5 <a href="lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
 633 <p>
 634 <tt>vector&lt;bool&gt;</tt> is not a container as its reference and
 635 pointer types are not references and pointers. </p>
 636
 637 <p>Also it forces everyone to have a space optimization instead of a
 638 speed one.</p>
 639
 640 <p>
 641 <b>See also:</b> 99-0008 == N1185 Vector&lt;bool&gt; is
 642 Nonconforming, Forces Optimization Choice.</p>
 643 <p><b>Proposed resolution:</b></p>
 644
 645 <p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>
 646
 647 <p><i>[In Dublin many present felt that failure to meet Container
 648 requirements was a defect. There was disagreement as to whether
 649 or not the optimization requirements constituted a defect.]</i></p>
 650
 651 <p><i>[The LWG looked at the following resolutions in some detail:
 652 <br>
 653 &nbsp;&nbsp;&nbsp;&nbsp; * Not A Defect.<br>
 654 &nbsp;&nbsp;&nbsp;&nbsp; * Add a note explaining that vector&lt;bool&gt; does not meet
 655 Container requirements.<br>
 656 &nbsp;&nbsp;&nbsp;&nbsp; * Remove vector&lt;bool&gt;.<br>
 657 &nbsp;&nbsp;&nbsp;&nbsp; * Add a new category of container requirements which
 658 vector&lt;bool&gt; would meet.<br>
 659 &nbsp;&nbsp;&nbsp;&nbsp; * Rename vector&lt;bool&gt;.<br>
 660 <br>
 661 No alternative had strong, wide-spread, support and every alternative
 662 had at least one &quot;over my dead body&quot; response.<br>
 663 <br>
 664 There was also mention of a transition scheme something like (1) add
 665 vector_bool and deprecate vector&lt;bool&gt; in the next standard. (2)
 666 Remove vector&lt;bool&gt; in the following standard.]</i></p>
 667
 668 <p><i>[Modifying container requirements to permit returning proxies
 669 (thus allowing container requirements conforming vector&lt;bool&gt;)
 670 was also discussed.]</i></p>
 671
 672 <p><i>[It was also noted that there is a partial but ugly workaround in
 673 that vector&lt;bool&gt; may be further specialized with a customer
 674 allocator.]</i></p>
 675
 676 <p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
 677 vector&lt;bool&gt;: More Problems, Better Solutions. Much discussion
 678 of a two step approach: a) deprecate, b) provide replacement under a
 679 new name.  LWG straw vote on that: 1-favor, 11-could live with, 2-over
 680 my dead body.  This resolution was mentioned in the LWG report to the
 681 full committee, where several additional committee members indicated
 682 over-my-dead-body positions.]</i></p>
 683
 684 <p><i>[Tokyo: Not discussed by the full LWG; no one claimed new
 685 insights and so time was more productively spent on other issues. In
 686 private discussions it was asserted that requirements for any solution
 687 include 1) Increasing the full committee's understanding of the
 688 problem, and 2) providing compiler vendors, authors, teachers, and of
 689 course users with specific suggestions as to how to apply the eventual
 690 solution.]</i></p>
 691
 692 <hr>
 693 <a name="98"><h3>98.&nbsp;Input iterator requirements are badly written</h3></a><p>
 694 <b>Section:</b>&nbsp;24.1.1 <a href="lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
 695 <p>Table 72 in 24.1.1 <a href="lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> specifies semantics for
 696 <tt>*r++</tt> of:</p>
 697
 698 <p>&nbsp;&nbsp; <tt>{ T tmp = *r; ++r; return tmp; }</tt>
 699 </p>
 700
 701 <p>There are two problems with this.  First, the return type is
 702 specified to be &quot;T&quot;, as opposed to something like &quot;convertible to T&quot;.
 703 This is too specific: we want to allow *r++ to return an lvalue.</p>
 704
 705 <p>Second, writing the semantics in terms of code misleadingly
 706 suggests that the effects *r++ should precisely replicate the behavior
 707 of this code, including side effects.  (What if it's a user-defined
 708 type whose copy constructor has observable behavior?)  We should
 709 replace the code with words, or else put some blanket statement in
 710 clause 17 saying that code samples aren't intended to specify exactly
 711 how many times a copy constructor is called, even if the copy
 712 constructor has observable behavior.  (See issue <a href="lwg-active.html#334">334</a>
 713 for a similar problem.)</p>
 714
 715 <p><i>[Issue still isn't clear.  Matt will try to explain it more
 716 clearly at the next meeting.]</i></p>
 717
 718 <p><b>Proposed resolution:</b></p>
 719 <hr>
 720 <a name="120"><h3>120.&nbsp;Can an implementor add specializations?</h3></a><p>
 721 <b>Section:</b>&nbsp;17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
 722
 723 <p>The original issue asked whether a library implementor could
 724 specialize standard library templates for built-in types.  (This was
 725 an issue because users are permitted to explicitly instantiate
 726 standard library templates.)</p>
 727
 728 <p>Specializations are no longer a problem, because of the resolution
 729 to core issue 259.  Under the proposed resolution, it will be legal
 730 for a translation unit to contain both a specialization and an
 731 explicit instantiation of the same template, provided that the
 732 specialization comes first.  In such a case, the explicit
 733 instantiation will be ignored.  Further discussion of library issue
 734 120 assumes that the core 259 resolution will be adopted.</p>
 735
 736 <p>However, as noted in lib-7047, one piece of this issue still
 737 remains: what happens if a standard library implementor explicitly
 738 instantiates a standard library templates?  It's illegal for a program
 739 to contain two different explicit instantiations of the same template
 740 for the same type in two different translation units (ODR violation),
 741 and the core working group doesn't believe it is practical to relax
 742 that restriction.</p>
 743
 744 <p>The issue, then, is: are users allowed to implicitly instantiate
 745 standard library templates for non-user defined types?  The status quo
 746 answer is 'yes'.  Changing it to 'no' would give library implementors
 747 more freedom.</p>
 748
 749 <p>This is an issue because, for performance reasons, library
 750 implementors often need to explicitly instantiate standard library
 751 templates.  (for example, std::basic_string&lt;char&gt;)  Does giving
 752 users freedom to explicitly instantiate standard library templates for
 753 non-user defined types make it impossible or painfully difficult for
 754 library implementors to do this?</p>
 755
 756 <p>John Spicer suggests, in lib-8957, that library implementors have a
 757 mechanism they can use for explicit instantiations that doesn't
 758 prevent users from performing their own explicit instantiations: put
 759 each explicit instantiation in its own object file.  (Different
 760 solutions might be necessary for Unix DSOs or MS-Windows DLLs.)  On
 761 some platforms, library implementors might not need to do anything
 762 special: the &quot;undefined behavior&quot; that results from having two
 763 different explicit instantiations might be harmless.</p>
 764
 765 <p><b>Proposed resolution:</b></p>
 766 <p>Option 1.</p>
 767 <blockquote>
 768   <p>Append to 17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> paragraph 1: </p>
 769   <blockquote>
 770     A program may explicitly instantiate any templates in the standard
 771     library only if the declaration depends on a user-defined name of
 772     external linkage and the instantiation meets the standard library
 773     requirements for the original template.
 774   </blockquote>
 775 </blockquote>
 776
 777 <p>Option 2.</p>
 778 <blockquote>
 779   <p>In light of the resolution to core issue 259, no normative changes
 780   in the library clauses are necessary.  Add the following non-normative
 781   note to the end of 17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> paragraph 1:</p>
 782   <blockquote>
 783     [<i>Note:</i> A program may explicitly instantiate standard library
 784     templates, even when an explicit instantiation does not depend on
 785     a user-defined name. <i>--end note</i>]
 786   </blockquote>
 787 </blockquote>
 788
 789 <p><i>[Copenhagen: LWG discussed three options.  (1) Users may not
 790 explicitly instantiate standard library templates, except on
 791 user-defined types.  Consequence: library implementors may freely
 792 specialize or instantiate templates.  (2) Users may explicitly
 793 instantiate any standard library template.  Consequence: if
 794 implementors specialize or instantiate library templates, they may
 795 need to take special steps to make sure users can do it too.  (3) It
 796 is implementation defined whether users may explicitly instantiate
 797 standard library templates on non-user-defined types.  Consequence:
 798 library implementors may freely specialize or instantiate templates,
 799 but may need to document some or all templates that have been
 800 explicitly instantiated.
 801 ]</i></p>
 802
 803 <p><i>[Straw poll (first number is favor, second is strongly oppose): 1
 804 - 4, 0; 2 - 9, 1; 3 - 0, 9.  (Proposed resolution 1 was the original
 805 proposed resolution.)  Because there was no support for option 3, no
 806 wording is provided.]</i></p>
 807
 808 <p><i>[Redmond: discussed again; straw poll had results similar to
 809 those of Copenhagen (1 - 1, 3; 2 - 8, 4; 3 - 6, 2).  Most people said
 810 they could live with any option. The only objection to option 2 is
 811 potential implementation difficulty.  Steve Clamage volunteered do a
 812 survey to see if there are any popular platforms where option 2 would
 813 present a real problem for implementors.  See his reflector message,
 814 c++std-lib-9002.
 815 ]</i></p>
 816
 817 <p><i>[Steve and Pete Becker will talk to Jonathan Caves.  The
 818 Microsoft linker might present a problem if there are multiple copies,
 819 some of which have static data and some of which are in DLLs.  There
 820 may be similar problems with the Apple linker; Matt will clarify
 821 that.]</i></p>
 822
 823 <hr>
 824 <a name="123"><h3>123.&nbsp;Should valarray helper arrays fill functions be const?</h3></a><p>
 825 <b>Section:</b>&nbsp;26.3.5.4 <a href="lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a>, 26.3.7.4 <a href="lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a>, 26.3.8.4 <a href="lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a>, 26.3.9.4 <a href="lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998 </p>
 826 <p>One of the operator= in the valarray helper arrays is const and one
 827 is not. For example, look at slice_array. This operator= in Section
 828 26.3.5.2 <a href="lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> is const: </p>
 829
 830 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const valarray&lt;T&gt;&amp;) const;</tt> </p>
 831
 832 <p>but this one in Section 26.3.5.4 <a href="lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> is not: </p>
 833
 834 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const T&amp;); </tt>
 835 </p>
 836
 837 <p>The description of the semantics for these two functions is similar. </p>
 838 <p><b>Proposed resolution:</b></p>
 839
 840 <p>26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> Template class slice_array</p>
 841 <blockquote>
 842
 843    <p>In the class template definition for slice_array, replace the member
 844    function declaration</p>
 845     <pre>
 846       void operator=(const T&amp;);
 847     </pre>
 848    <p>with</p>
 849     <pre>
 850       void operator=(const T&amp;) const;
 851     </pre>
 852 </blockquote>
 853
 854 <p>26.3.5.4 <a href="lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> slice_array fill function</p>
 855 <blockquote>
 856
 857    <p>Change the function declaration</p>
 858     <pre>
 859       void operator=(const T&amp;);
 860     </pre>
 861    <p>to</p>
 862     <pre>
 863       void operator=(const T&amp;) const;
 864     </pre>
 865 </blockquote>
 866
 867 <p>26.3.7 <a href="lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> Template class gslice_array</p>
 868 <blockquote>
 869
 870    <p>In the class template definition for gslice_array, replace the member
 871    function declaration</p>
 872     <pre>
 873       void operator=(const T&amp;);
 874     </pre>
 875    <p>with</p>
 876     <pre>
 877       void operator=(const T&amp;) const;
 878     </pre>
 879 </blockquote>
 880
 881 <p>26.3.7.4 <a href="lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a> gslice_array fill function</p>
 882 <blockquote>
 883
 884    <p>Change the function declaration</p>
 885     <pre>
 886       void operator=(const T&amp;);
 887     </pre>
 888    <p>to</p>
 889     <pre>
 890       void operator=(const T&amp;) const;
 891     </pre>
 892 </blockquote>
 893
 894 <p>26.3.8 <a href="lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> Template class mask_array</p>
 895 <blockquote>
 896
 897    <p>In the class template definition for mask_array, replace the member
 898    function declaration</p>
 899     <pre>
 900       void operator=(const T&amp;);
 901     </pre>
 902    <p>with</p>
 903     <pre>
 904       void operator=(const T&amp;) const;
 905     </pre>
 906 </blockquote>
 907
 908 <p>26.3.8.4 <a href="lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a> mask_array fill function</p>
 909 <blockquote>
 910
 911    <p>Change the function declaration</p>
 912     <pre>
 913       void operator=(const T&amp;);
 914     </pre>
 915    <p>to</p>
 916     <pre>
 917       void operator=(const T&amp;) const;
 918     </pre>
 919 </blockquote>
 920
 921 <p>26.3.9 <a href="lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a> Template class indirect_array</p>
 922 <blockquote>
 923
 924    <p>In the class template definition for indirect_array, replace the member
 925    function declaration</p>
 926     <pre>
 927       void operator=(const T&amp;);
 928     </pre>
 929    <p>with</p>
 930     <pre>
 931       void operator=(const T&amp;) const;
 932     </pre>
 933 </blockquote>
 934
 935 <p>26.3.9.4 <a href="lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a> indirect_array fill function</p>
 936 <blockquote>
 937
 938    <p>Change the function declaration</p>
 939     <pre>
 940       void operator=(const T&amp;);
 941     </pre>
 942    <p>to</p>
 943     <pre>
 944       void operator=(const T&amp;) const;
 945     </pre>
 946 </blockquote>
 947
 948
 949 <p><i>[Redmond: Robert provided wording.]</i></p>
 950
 951 <p><b>Rationale:</b></p>
 952 <p>There's no good reason for one version of operator= being const and
 953 another one not.  Because of issue <a href="lwg-active.html#253">253</a>, this now
 954 matters: these functions are now callable in more circumstances.  In
 955 many existing implementations, both versions are already const.</p>
 956 <hr>
 957 <a name="167"><h3>167.&nbsp;Improper use of <tt>traits_type::length()</tt>
 958 </h3></a><p>
 959 <b>Section:</b>&nbsp;27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
 960 <p>Paragraph 4 states that the length is determined using
 961 <tt>traits::length(s)</tt>.  Unfortunately, this function is not
 962 defined for example if the character type is <tt>wchar_t</tt> and the
 963 type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
 964 the character type is <tt>char</tt> and the type of <tt>s</tt> is
 965 either <tt>signed char const*</tt> or <tt>unsigned char
 966 const*</tt>.</p>
 967 <p><b>Proposed resolution:</b></p>
 968 <p>Change 27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> paragraph 4 from:</p>
 969 <blockquote>
 970   <p>Effects: Behaves like an formatted inserter (as described in
 971   lib.ostream.formatted.reqmts) of out. After a sentry object is
 972   constructed it inserts characters. The number of characters starting
 973   at s to be inserted is traits::length(s). Padding is determined as
 974   described in lib.facet.num.put.virtuals. The traits::length(s)
 975   characters starting at s are widened using out.widen
 976   (lib.basic.ios.members). The widened characters and any required
 977   padding are inserted into out. Calls width(0).</p>
 978 </blockquote>
 979 <p>to:</p>
 980 <blockquote>
 981   <p>Effects: Behaves like an formatted inserter (as described in
 982   lib.ostream.formatted.reqmts) of out. After a sentry object is
 983   constructed it inserts characters. The number len of characters
 984   starting at s to be inserted is</p>
 985   <p>
 986   - traits::length((const char*)s) if the second argument is of type
 987     const charT*<br>
 988   - char_traits&lt;char&gt;::length(s) if the second argument is of
 989     type const char*, const signed char*, or const unsigned char* and
 990     and charT is not char.<br>
 991   </p>
 992   <p>Padding is determined as described in
 993   lib.facet.num.put.virtuals. The len characters starting at s are
 994   widened using out.widen (lib.basic.ios.members).  The widened
 995   characters and any required padding are inserted into out. Calls
 996   width(0).</p>
 997 </blockquote>
 998
 999 <p><i>[Kona: It is clear to the LWG there is a defect here.
1000 Dietmar will supply specific wording.]</i></p>
1001
1002 <p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
1003
1004 <p><i>[Toronto: The original proposed resolution involved
1005 char_traits&lt;signed char&gt; and char_traits&lt;unsigned char&gt;.
1006 There was strong opposition to requiring that library implementors
1007 provide those specializations of char_traits.]</i></p>
1008
1009 <p><i>[Copenhagen: This still isn't quite right: proposed resolution
1010 text got garbled when the signed char/unsigned char specializations
1011 were removed.  Dietmar will provide revised wording.]</i></p>
1012 <hr>
1013 <a name="179"><h3>179.&nbsp;Comparison of const_iterators to iterators doesn't work</h3></a><p>
1014 <b>Section:</b>&nbsp;23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;2 Jul 1998</p>
1015 <p>Currently the following will not compile on two well-known standard
1016 library implementations:</p>
1017
1018 <blockquote>
1019   <pre>#include &lt;set&gt;
1020 using namespace std;
1021
1022 void f(const set&lt;int&gt; &amp;s)
1023 {
1024   set&lt;int&gt;::iterator i;
1025   if (i==s.end()); // s.end() returns a const_iterator
1026 }</pre>
1027 </blockquote>
1028
1029 <p>
1030 The reason this doesn't compile is because operator== was implemented
1031 as a member function of the nested classes set:iterator and
1032 set::const_iterator, and there is no conversion from const_iterator to
1033 iterator. Surprisingly, (s.end() == i) does work, though, because of
1034 the conversion from iterator to const_iterator.
1035 </p>
1036
1037 <p>
1038 I don't see a requirement anywhere in the standard that this must
1039 work. Should there be one?  If so, I think the requirement would need
1040 to be added to the tables in section 24.1.1. I'm not sure about the
1041 wording.  If this requirement existed in the standard, I would think
1042 that implementors would have to make the comparison operators
1043 non-member functions.</p>
1044
1045 <p>This issues was also raised on comp.std.c++ by Darin
1046 Adler.&nbsp; The example given was:</p>
1047
1048 <blockquote>
1049   <pre>bool check_equal(std::deque&lt;int&gt;::iterator i,
1050 std::deque&lt;int&gt;::const_iterator ci)
1051 {
1052 return i == ci;
1053 }</pre>
1054 </blockquote>
1055
1056 <p>Comment from John Potter:</p>
1057 <blockquote>
1058     <p>
1059     In case nobody has noticed, accepting it will break reverse_iterator.
1060     </p>
1061
1062     <p>
1063     The fix is to make the comparison operators templated on two types.
1064     </p>
1065
1066     <pre>
1067     template &lt;class Iterator1, class Iterator2&gt;
1068     bool operator== (reverse_iterator&lt;Iterator1&gt; const&amp; x,
1069                      reverse_iterator&lt;Iterator2&gt; const&amp; y);
1070     </pre>
1071
1072     <p>
1073     Obviously:  return x.base() == y.base();
1074     </p>
1075
1076     <p>
1077     Currently, no reverse_iterator to const_reverse_iterator compares are
1078     valid.
1079     </p>
1080
1081     <p>
1082     BTW, I think the issue is in support of bad code.  Compares should be
1083     between two iterators of the same type.  All std::algorithms require
1084     the begin and end iterators to be of the same type.
1085     </p>
1086 </blockquote>
1087 <p><b>Proposed resolution:</b></p>
1088 <p>Insert this paragraph after 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 7:</p>
1089 <blockquote>
1090   <p>In the expressions</p>
1091   <pre>
1092     i == j
1093     i != j
1094     i &lt; j
1095     i &lt;= j
1096     i &gt;= j
1097     i &gt; j
1098     i - j
1099   </pre>
1100   <p>Where i and j denote objects of a container's iterator type,
1101   either or both may be replaced by an object of the container's
1102   const_iterator type referring to the same element with no
1103   change in semantics.</p>
1104 </blockquote>
1105
1106 <p><i>[post-Toronto: Judy supplied a proposed resolution saying that
1107 <tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
1108 iterator comparison and difference operations.]</i></p>
1109
1110 <p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
1111 explicitly listed expressions; there was concern that the previous
1112 proposed resolution was too informal.]</i></p>
1113 <p><b>Rationale:</b></p>
1114 <p>
1115 The LWG believes it is clear that the above wording applies only to
1116 the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
1117 where <tt>X</tt> is a container.  There is no requirement that
1118 <tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
1119 can be mixed.  If mixing them is considered important, that's a
1120 separate issue.  (Issue <a href="lwg-active.html#280">280</a>.)
1121 </p>
1122 <hr>
1123 <a name="187"><h3>187.&nbsp;iter_swap underspecified</h3></a><p>
1124 <b>Section:</b>&nbsp;25.2.2 <a href="lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;14 Aug 1999</p>
1125 <p>The description of iter_swap in 25.2.2 paragraph 7,says that it ``exchanges the values''
1126 of the objects to which two iterators refer.<br>
1127 <br>
1128 What it doesn't say is whether it does so using swap or using the assignment operator and copy constructor.<br>
1129 <br>
1130 This question is an important one to answer, because swap is specialized to work efficiently for standard containers.<br>
1131 For example:</p>
1132 <blockquote>
1133 <pre>vector&lt;int&gt; v1, v2;
1134 iter_swap(&amp;v1, &amp;v2);</pre>
1135 </blockquote>
1136 <p>Is this call to iter_swap equivalent to calling swap(v1, v2)?&nbsp; Or is it equivalent to</p>
1137 <blockquote>
1138 <pre>{
1139 vector&lt;int&gt; temp = v1;
1140 v1 = v2;
1141 v2 = temp;
1142 }</pre>
1143 </blockquote>
1144 <p>The first alternative is O(1); the second is O(n).</p>
1145 <p>A LWG member, Dave Abrahams, comments:</p>
1146 <blockquote>
1147 <p>Not an objection necessarily, but I want to point out the cost of that requirement:</p>
1148   <blockquote>
1149 <p><tt>iter_swap(list&lt;T&gt;::iterator, list&lt;T&gt;::iterator)</tt></p>
1150   </blockquote>
1151 <p>can currently be specialized to be more efficient than iter_swap(T*,T*) for many T (by using splicing). Your proposal would make that optimization
1152 illegal.&nbsp;</p>
1153 </blockquote>
1154
1155 <p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
1156 which are no longer permitted.]</i></p>
1157 <p><b>Proposed resolution:</b></p>
1158 <p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
1159 <blockquote>
1160 <p>Exchanges the values pointed to by the two iterators a and b.</p>
1161 </blockquote>
1162 <p>to</p>
1163 <blockquote>
1164 <p>
1165 <tt>swap(*a, *b)</tt>.</p>
1166 </blockquote>
1167
1168 <p><i>[post-Toronto: The LWG is concerned about possible
1169 overspecification: there may be cases, such as Dave Abrahams's example
1170 above, and such as vector&lt;bool&gt;'s iterators, where it makes more
1171 sense for iter_swap to do something other than swap.  If performance
1172 is a concern, it may be better to have explicit complexity
1173 requirements than to say how iter_swap should be implemented.]</i></p>
1174
1175 <p><i>[Redmond: Discussed, with no consensus.  There was very little
1176 support for the proposed resolution.  Some people favored closing this
1177 issue as NAD. Others favored a more complicated specification of
1178 <tt>iter_swap</tt>, which might distinguish between ordinary iterators
1179 and proxies.  A possible new issue: how do we know that the iterators
1180 passed to <tt>iter_swap</tt> have Assignable value types?  (If this
1181 new issue is real, it extends far beyond just
1182 <tt>iter_swap</tt>.)]</i></p>
1183
1184 <hr>
1185 <a name="197"><h3>197.&nbsp;max_size() underspecified</h3></a><p>
1186 <b>Section:</b>&nbsp;20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;21 Oct 1999</p>
1187 <p>Must the value returned by max_size() be unchanged from call to call? </p>
1188
1189 <p>Must the value returned from max_size() be meaningful? </p>
1190
1191 <p>Possible meanings identified in lib-6827: </p>
1192
1193 <p>1) The largest container the implementation can support given &quot;best
1194 case&quot; conditions - i.e. assume the run-time platform is &quot;configured to
1195 the max&quot;, and no overhead from the program itself. This may possibly
1196 be determined at the point the library is written, but certainly no
1197 later than compile time.<br>
1198 <br>
1199 2) The largest container the program could create, given &quot;best case&quot;
1200 conditions - i.e. same platform assumptions as (1), but take into
1201 account any overhead for executing the program itself. (or, roughly
1202 &quot;storage=storage-sizeof(program)&quot;). This does NOT include any resource
1203 allocated by the program. This may (or may not) be determinable at
1204 compile time.<br>
1205 <br>
1206 3) The largest container the current execution of the program could
1207 create, given knowledge of the actual run-time platform, but again,
1208 not taking into account any currently allocated resource. This is
1209 probably best determined at program start-up.<br>
1210 <br>
1211 4) The largest container the current execution program could create at
1212 the point max_size() is called (or more correctly at the point
1213 max_size() returns :-), given it's current environment (i.e. taking
1214 into account the actual currently available resources). This,
1215 obviously, has to be determined dynamically each time max_size() is
1216 called. </p>
1217 <p><b>Proposed resolution:</b></p>
1218 <p>Change 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> table 32 max_size() wording from:<br>
1219 <br>
1220 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the largest value that can meaningfully be
1221 passed to X::allocate<br>
1222 to:<br>
1223 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the value of the largest constant expression
1224 (5.19 <a href="expr.html#expr.const"> [expr.const]</a>) that could ever meaningfully be passed to X::allocate</p>
1225
1226 <p>
1227 Change 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> table 65 max_size() wording from:<br>
1228 <br>
1229 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; size() of the largest possible container.<br>
1230 to:<br>
1231 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the value of the largest constant expression
1232 (5.19 <a href="expr.html#expr.const"> [expr.const]</a>) that could ever meaningfully be returned by X::size().
1233 </p>
1234
1235 <p><i>[Kona: The LWG informally discussed this and asked Andy Sawyer to submit
1236 an issue.]</i></p>
1237
1238 <p><i>[Tokyo: The LWG believes (1) above is the intended meaning.]</i></p>
1239
1240 <p><i>[Post-Tokyo: Beman Dawes supplied the above resolution at the
1241 request of the LWG. 21.3.3 <a href="lib-strings.html#lib.string.capacity"> [lib.string.capacity]</a> was not changed because it
1242 references max_size() in 23.1.  The term &quot;compile-time&quot; was
1243 avoided because it is not defined anywhere in the standard (even
1244 though it is used several places in the library clauses).]</i></p>
1245
1246 <p><i>[Copenhagen: Exactly what <tt>max_size</tt> means is still
1247 unclear.  It may have a different meaning as a container member
1248 function than as an allocator member function.  For the latter,
1249 it is probably best thought of as an architectural limit.
1250 Nathan will provide new wording.]</i></p>
1251 <hr>
1252 <a name="200"><h3>200.&nbsp;Forward iterator requirements don't allow constant iterators</h3></a><p>
1253 <b>Section:</b>&nbsp;24.1.3 <a href="lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Nov 1999</p>
1254 <p>
1255 In table 74, the return type of the expression <tt>*a</tt> is given
1256 as <tt>T&amp;</tt>, where <tt>T</tt> is the iterator's value type.
1257 For constant iterators, however, this is wrong.  (&quot;Value type&quot;
1258 is never defined very precisely, but it is clear that the value type
1259 of, say, <tt>std::list&lt;int&gt;::const_iterator</tt> is supposed to be
1260 <tt>int</tt>, not <tt>const int</tt>.)
1261 </p>
1262 <p><b>Proposed resolution:</b></p>
1263 <p>
1264 In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
1265 return type from &quot;<tt>T&amp;</tt>&quot; to &quot;<tt>T&amp;</tt>
1266 if <tt>X</tt> is mutable, otherwise <tt>const T&amp;</tt>&quot;.
1267 In the <tt>a-&gt;m</tt> row, change the return type from
1268 &quot;<tt>U&amp;</tt>&quot; to &quot;<tt>U&amp;</tt> if <tt>X</tt> is mutable,
1269 otherwise <tt>const U&amp;</tt>&quot;.
1270 </p>
1271
1272 <p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
1273 there are multiple const problems with the STL portion of the library
1274 and that these should be addressed as a single package.&nbsp; Note
1275 that issue <a href="lwg-closed.html#180">180</a> has already been declared NAD Future for
1276 that very reason.]</i></p>
1277
1278 <p><i>[Redmond: the LWG thinks this is separable from other constness
1279 issues.  This issue is just cleanup; it clarifies language that was
1280 written before we had iterator_traits.  Proposed resolution was
1281 modified: the original version only discussed *a.  It was pointed out
1282 that we also need to worry about *r++ and a-&gt;m.]</i></p>
1283
1284 <hr>
1285 <a name="201"><h3>201.&nbsp;Numeric limits terminology wrong</h3></a><p>
1286 <b>Section:</b>&nbsp;18.2.1 <a href="lib-support.html#lib.limits"> [lib.limits]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Stephen Cleary&nbsp; <b>Date:</b>&nbsp;21 Dec 1999</p>
1287 <p>
1288 In some places in this section, the terms &quot;fundamental types&quot; and
1289 &quot;scalar types&quot; are used when the term &quot;arithmetic types&quot; is intended.
1290 The current usage is incorrect because void is a fundamental type and
1291 pointers are scalar types, neither of which should have
1292 specializations of numeric_limits.
1293 </p>
1294 <p><b>Proposed resolution:</b></p>
1295 <p>Change 18.2 [lib.support.limits] para 1 from:</p>
1296 <blockquote>
1297
1298 <p>  The headers &lt;limits&gt;, &lt;climits&gt;, and &lt;cfloat&gt; supply characteristics of  implementation-dependent fundamental types (3.9.1).</p>
1299 </blockquote>
1300
1301 <p>to:</p>
1302 <blockquote>
1303
1304 <p>  The headers &lt;limits&gt;, &lt;climits&gt;, and &lt;cfloat&gt; supply characteristics of  implementation-dependent arithmetic types (3.9.1).</p>
1305 </blockquote>
1306
1307 <p>Change 18.2.1 [lib.limits] para 1 from:</p>
1308 <blockquote>
1309
1310 <p>  The numeric_limits component provides a C++ program with information about various  properties of the implementation's representation of the fundamental
1311 types.</p>
1312 </blockquote>
1313
1314 <p>to:</p>
1315 <blockquote>
1316
1317 <p>  The numeric_limits component provides a C++ program with information about various  properties of the implementation's representation of the arithmetic
1318 types.</p>
1319 </blockquote>
1320
1321 <p>Change 18.2.1 [lib.limits] para 2 from:</p>
1322 <blockquote>
1323
1324 <p>  Specializations shall be provided for each fundamental type. . .</p>
1325 </blockquote>
1326
1327 <p>to:</p>
1328 <blockquote>
1329
1330 <p>  Specializations shall be provided for each arithmetic type. . .</p>
1331 </blockquote>
1332
1333 <p>Change 18.2.1 [lib.limits] para 4 from:</p>
1334 <blockquote>
1335
1336 <p>  Non-fundamental standard types. . .</p>
1337 </blockquote>
1338
1339 <p>to:</p>
1340 <blockquote>
1341
1342 <p>  Non-arithmetic standard types. . .</p>
1343 </blockquote>
1344
1345 <p>Change 18.2.1.1 [lib.numeric.limits] para 1 from:</p>
1346 <blockquote>
1347
1348 <p>  The member is_specialized makes it possible to distinguish between fundamental types,  which have specializations, and non-scalar types, which
1349 do not.</p>
1350 </blockquote>
1351
1352 <p>to:</p>
1353 <blockquote>
1354
1355 <p>  The member is_specialized makes it possible to distinguish between arithmetic types,  which have specializations, and non-arithmetic types,
1356 which do not.</p>
1357 </blockquote>
1358
1359 <p><i>[post-Toronto: The opinion of the LWG is that the wording in the
1360 standard, as well as the wording of the proposed resolution, is
1361 flawed.  The term &quot;arithmetic types&quot; is well defined in C
1362 and C++, and it is not clear that the term is being used correctly.
1363 It is also not clear that the term &quot;implementation
1364 dependent&quot; has any useful meaning in this context.  The biggest
1365 problem is that numeric_limits seems to be intended both for built-in
1366 types and for user-defined types, and the standard doesn't make it
1367 clear how numeric_limits applies to each of those cases.  A wholesale
1368 review of numeric_limits is needed.  A paper would be welcome.]</i></p>
1369 <hr>
1370 <a name="202"><h3>202.&nbsp;unique() effects unclear when predicate not an equivalence relation</h3></a><p>
1371 <b>Section:</b>&nbsp;25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;13 Jan 2000</p>
1372 <p>
1373 What should unique() do if you give it a predicate that is not an
1374 equivalence relation?  There are at least two plausible answers:
1375 </p>
1376
1377 <blockquote>
1378
1379 <p>
1380    1. You can't, because 25.2.8 says that it it &quot;eliminates all but
1381    the first element from every consecutive group of equal
1382    elements...&quot; and it wouldn't make sense to interpret &quot;equal&quot; as
1383    meaning anything but an equivalence relation.  [It also doesn't
1384    make sense to interpret &quot;equal&quot; as meaning ==, because then there
1385    would never be any sense in giving a predicate as an argument at
1386    all.]
1387 </p>
1388
1389 <p>
1390    2. The word &quot;equal&quot; should be interpreted to mean whatever the
1391    predicate says, even if it is not an equivalence relation
1392    (and in particular, even if it is not transitive).
1393 </p>
1394
1395 </blockquote>
1396
1397 <p>
1398 The example that raised this question is from Usenet:
1399 </p>
1400
1401 <blockquote>
1402
1403 <pre>int f[] = { 1, 3, 7, 1, 2 };
1404 int* z = unique(f, f+5, greater&lt;int&gt;());</pre>
1405
1406 </blockquote>
1407
1408 <p>
1409 If one blindly applies the definition using the predicate
1410 greater&lt;int&gt;, and ignore the word &quot;equal&quot;, you get:
1411 </p>
1412
1413 <blockquote>
1414
1415 <p>
1416     Eliminates all but the first element from every consecutive group
1417     of elements referred to by the iterator i in the range [first, last)
1418     for which *i &gt; *(i - 1).
1419 </p>
1420
1421 </blockquote>
1422
1423 <p>
1424 The first surprise is the order of the comparison.  If we wanted to
1425 allow for the predicate not being an equivalence relation, then we
1426 should surely compare elements the other way: pred(*(i - 1), *i).  If
1427 we do that, then the description would seem to say: &quot;Break the
1428 sequence into subsequences whose elements are in strictly increasing
1429 order, and keep only the first element of each subsequence&quot;.  So the
1430 result would be 1, 1, 2.  If we take the description at its word, it
1431 would seem to call for strictly DEcreasing order, in which case the
1432 result should be 1, 3, 7, 2.<br>
1433 <br>
1434 In fact, the SGI implementation of unique() does neither: It yields 1,
1435 3, 7.
1436 </p>
1437 <p><b>Proposed resolution:</b></p>
1438 <p>Change 25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> paragraph 1 to:</p>
1439 <blockquote>
1440 For a nonempty range, eliminates all but the first element from every
1441 consecutive group of equivalent elements referred to by the iterator
1442 <tt>i</tt> in the range [first+1, last) for which the following
1443 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
1444 false</tt>.
1445 </blockquote>
1446
1447 <p>
1448 Also insert a new paragraph, paragraph 2a, that reads: &quot;Requires: The
1449 comparison function must be an equivalence relation.&quot;
1450 </p>
1451
1452 <p><i>[Redmond: discussed arguments for and against requiring the
1453 comparison function to be an equivalence relation.  Straw poll:
1454 14-2-5.  First number is to require that it be an equivalence
1455 relation, second number is to explicitly not require that it be an
1456 equivalence relation, third number is people who believe they need
1457 more time to consider the issue.  A separate issue: Andy Sawyer
1458 pointed out that &quot;i-1&quot; is incorrect, since &quot;i&quot; can refer to the first
1459 iterator in the range.  Matt provided wording to address this
1460 problem.]</i></p>
1461
1462 <p><i>[Cura&ccedil;ao: The LWG changed &quot;... the range (first,
1463 last)...&quot; to &quot;...  the range [first+1, last)...&quot; for
1464 clarity. They considered this change close enough to editorial to not
1465 require another round of review.]</i></p>
1466
1467 <p><b>Rationale:</b></p>
1468 <p>The LWG also considered an alternative resolution: change
1469 25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> paragraph 1 to:</p>
1470
1471 <blockquote>
1472 For a nonempty range, eliminates all but the first element from every
1473 consecutive group of elements referred to by the iterator
1474 <tt>i</tt> in the range (first, last) for which the following
1475 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
1476 false</tt>.
1477 </blockquote>
1478
1479 <p>
1480 Also insert a new paragraph, paragraph 1a, that reads: &quot;Notes: The
1481 comparison function need not be an equivalence relation.&quot;
1482 </p>
1483
1484
1485 <p>Informally: the proposed resolution imposes an explicit requirement
1486 that the comparison function be an equivalence relation.  The
1487 alternative resolution does not, and it gives enough information so
1488 that the behavior of unique() for a non-equivalence relation is
1489 specified.  Both resolutions are consistent with the behavior of
1490 existing implementations.</p>
1491 <hr>
1492 <a name="225"><h3>225.&nbsp;std:: algorithms use of other unqualified algorithms</h3></a><p>
1493 <b>Section:</b>&nbsp;17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
1494 <p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
1495 user namespaces might be found through Koenig lookup?</p>
1496 <p>For example, a popular standard library implementation includes this
1497 implementation of std::unique:</p>
1498 <blockquote>
1499 <pre>namespace std {
1500     template &lt;class _ForwardIter&gt;
1501     _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
1502       __first = adjacent_find(__first, __last);
1503       return unique_copy(__first, __last, __first);
1504     }
1505     }</pre>
1506 </blockquote>
1507 <p>Imagine two users on opposite sides of town, each using unique on his own
1508 sequences bounded by my_iterators . User1 looks at his standard library
1509 implementation and says, &quot;I know how to implement a more efficient
1510 unique_copy for my_iterators&quot;, and writes:</p>
1511 <blockquote>
1512 <pre>namespace user1 {
1513     class my_iterator;
1514     // faster version for my_iterator
1515     my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
1516     }</pre>
1517 </blockquote>
1518 <p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
1519 <p>User2 has other needs, and writes:</p>
1520 <blockquote>
1521 <pre>namespace user2 {
1522     class my_iterator;
1523     // Returns true iff *c is a unique copy of *a and *b.
1524     bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
1525     }</pre>
1526 </blockquote>
1527 <p>User2 is shocked to find later that his fully-qualified use of
1528 std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
1529 compile (if he's lucky). Looking in the standard, he sees the following Effects
1530 clause for unique():</p>
1531 <blockquote>
1532   <p>Effects: Eliminates all but the first element from every consecutive group
1533   of equal elements referred to by the iterator i in the range [first, last) for
1534   which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
1535   *(i - 1)) != false</p>
1536 </blockquote>
1537 <p>The standard gives user2 absolutely no reason to think he can interfere with
1538 std::unique by defining names in namespace user2. His standard library has been
1539 built with the template export feature, so he is unable to inspect the
1540 implementation. User1 eventually compiles his code with another compiler, and
1541 his version of unique_copy silently stops being called. Eventually, he realizes
1542 that he was depending on an implementation detail of his library and had no
1543 right to expect his unique_copy() to be called portably.</p>
1544 <p>On the face of it, and given above scenario, it may seem obvious that the
1545 implementation of unique() shown is non-conforming because it uses unique_copy()
1546 rather than ::std::unique_copy(). Most standard library implementations,
1547 however, seem to disagree with this notion.</p>
1548 <p> <i>[Tokyo:&nbsp; Steve Adamczyk from
1549 the core working group indicates that &quot;std::&quot; is sufficient;&nbsp;
1550 leading &quot;::&quot; qualification is not required because any namespace
1551 qualification is sufficient to suppress Koenig lookup.]</i>
1552 </p>
1553 <p><b>Proposed resolution:</b></p>
1554 <p>Add a paragraph and a note at the end of
1555 17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a>:</p>
1556 <blockquote>
1557
1558 <p>Unless otherwise specified, no global or non-member function in the
1559 standard library shall use a function from another namespace which is
1560 found through <i>argument-dependent name lookup</i> (3.4.2 <a href="basic.html#basic.lookup.koenig"> [basic.lookup.koenig]</a>).</p>
1561
1562 <p>[Note: the phrase &quot;unless otherwise specified&quot; is intended to
1563 allow Koenig lookup in cases like that of ostream_iterators:<br>
1564
1565 <br>
1566   Effects:</p>
1567   <blockquote>
1568 <p>*out_stream &lt;&lt; value;<br>
1569       if(delim != 0) *out_stream &lt;&lt; delim;<br>
1570       return (*this);</p>
1571     <p>--end note]</p>
1572   </blockquote>
1573 </blockquote>
1574
1575 <p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
1576 is as yet unsure if the proposed resolution is the best
1577 solution. Furthermore, the LWG believes that the same problem of
1578 unqualified library names applies to wording in the standard itself,
1579 and has opened issue <a href="lwg-active.html#229">229</a> accordingly. Any resolution of
1580 issue <a href="lwg-active.html#225">225</a> should be coordinated with the resolution of
1581 issue <a href="lwg-active.html#229">229</a>.]</i></p>
1582
1583 <p><i>[Toronto: The LWG is not sure if this is a defect in the
1584 standard.  Most LWG members believe that an implementation of
1585 <tt>std::unique</tt> like the one quoted in this issue is already
1586 illegal, since, under certain circumstances, its semantics are not
1587 those specified in the standard.  The standard's description of
1588 <tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
1589 should have any effect.]</i></p>
1590
1591 <p><i>[Cura&ccedil;ao: An LWG-subgroup spent an afternoon working on issues
1592 225, 226, and 229.  Their conclusion was that the issues should be
1593 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
1594 EWG portion (Dave will write a proposal). The LWG and EWG had
1595 (separate) discussions of this plan the next day.  The proposed
1596 resolution for this issue is in accordance with Howard's paper.]</i></p>
1597
1598 <hr>
1599 <a name="226"><h3>226.&nbsp;User supplied specializations or overloads of namespace std function templates</h3></a><p>
1600 <b>Section:</b>&nbsp;17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
1601 <p>The issues are:&nbsp;</p>
1602 <p>1. How can a 3rd party library implementor (lib1) write a version of a standard
1603 algorithm which is specialized to work with his own class template?&nbsp;</p>
1604 <p>2. How can another library implementor (lib2) write a generic algorithm which
1605 will take advantage of the specialized algorithm in lib1?</p>
1606 <p>This appears to be the only viable answer under current language rules:</p>
1607 <blockquote>
1608   <pre>namespace lib1
1609 {
1610     // arbitrary-precision numbers using T as a basic unit
1611     template &lt;class T&gt;
1612     class big_num { //...
1613     };
1614     </pre>
1615   <pre>    // defining this in namespace std is illegal (it would be an
1616     // overload), so we hope users will rely on Koenig lookup
1617     template &lt;class T&gt;
1618     void swap(big_int&lt;T&gt;&amp;, big_int&lt;T&gt;&amp;);
1619 }</pre>
1620   <pre>#include &lt;algorithm&gt;
1621 namespace lib2
1622 {
1623     template &lt;class T&gt;
1624     void generic_sort(T* start, T* end)
1625     {
1626             ...
1627         // using-declaration required so we can work on built-in types
1628         using std::swap;
1629         // use Koenig lookup to find specialized algorithm if available
1630         swap(*x, *y);
1631     }
1632 }</pre>
1633 </blockquote>
1634 <p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
1635 and somewhat slippery. The implementor needs to remember to write the
1636 using-declaration, or generic_sort will fail to compile when T is a built-in
1637 type. The second drawback is that the use of this style in lib2 effectively
1638 &quot;reserves&quot; names in any namespace which defines types which may
1639 eventually be used with lib2. This may seem innocuous at first when applied to
1640 names like swap, but consider more ambiguous names like unique_copy() instead.
1641 It is easy to imagine the user wanting to define these names differently in his
1642 own namespace. A definition with semantics incompatible with the standard
1643 library could cause serious problems (see issue <a href="lwg-active.html#225">225</a>).</p>
1644 <p>Why, you may ask, can't we just partially specialize std::swap()? It's
1645 because the language doesn't allow for partial specialization of function
1646 templates. If you write:</p>
1647 <blockquote>
1648   <pre>namespace std
1649 {
1650     template &lt;class T&gt;
1651     void swap(lib1::big_int&lt;T&gt;&amp;, lib1::big_int&lt;T&gt;&amp;);
1652 }</pre>
1653 </blockquote>
1654 <p>You have just overloaded std::swap, which is illegal under the current
1655 language rules. On the other hand, the following full specialization is legal:</p>
1656 <blockquote>
1657   <pre>namespace std
1658 {
1659     template &lt;&gt;
1660     void swap(lib1::other_type&amp;, lib1::other_type&amp;);
1661 }</pre>
1662 </blockquote>
1663
1664 <p>This issue reflects concerns raised by the &quot;Namespace issue
1665 with specialized swap&quot; thread on comp.lang.c++.moderated. A
1666 similar set of concerns was earlier raised on the boost.org mailing
1667 list and the ACCU-general mailing list.  Also see library reflector
1668 message c++std-lib-7354.</p>
1669
1670 <p>
1671 J. C. van Winkel points out (in c++std-lib-9565) another unexpected
1672 fact: it's impossible to output a container of std::pair's using copy
1673 and an ostream_iterator, as long as both pair-members are built-in or
1674 std:: types.  That's because a user-defined operator&lt;&lt; for (for
1675 example) std::pair&lt;const std::string, int&gt; will not be found:
1676 lookup for operator&lt;&lt; will be performed only in namespace std.
1677 Opinions differed on whether or not this was a defect, and, if so,
1678 whether the defect is that something is wrong with user-defined
1679 functionality and std, or whether it's that the standard library does
1680 not provide an operator&lt;&lt; for std::pair&lt;&gt;.
1681 </p>
1682
1683 <p><b>Proposed resolution:</b></p>
1684
1685 <p>Adopt the wording in the <b>Customization Points</b> section of
1686 Howard Hinnant's paper, N1387=02-0045.</p>
1687
1688 <p><i>[Tokyo: Summary, &quot;There is no conforming way to extend
1689 std::swap for user defined templates.&quot;&nbsp; The LWG agrees that
1690 there is a problem.&nbsp; Would like more information before
1691 proceeding. This may be a core issue.  Core issue 229 has been opened
1692 to discuss the core aspects of this problem. It was also noted that
1693 submissions regarding this issue have been received from several
1694 sources, but too late to be integrated into the issues list.
1695 ]</i></p>
1696
1697 <p><i>[Post-Tokyo: A paper with several proposed resolutions,
1698 J16/00-0029==WG21/N1252, &quot;Shades of namespace std functions
1699 &quot; by Alan Griffiths, is in the Post-Tokyo mailing. It
1700 should be considered a part of this issue.]</i></p>
1701
1702 <p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
1703 resolution that involves core changes: it would add partial
1704 specialization of function template.  The Core Working Group is
1705 reluctant to add partial specialization of function templates.  It is
1706 viewed as a large change, CWG believes that proposal presented leaves
1707 some syntactic issues unanswered; if the CWG does add partial
1708 specialization of function templates, it wishes to develop its own
1709 proposal.  The LWG continues to believe that there is a serious
1710 problem: there is no good way for users to force the library to use
1711 user specializations of generic standard library functions, and in
1712 certain cases (e.g. transcendental functions called by
1713 <tt>valarray</tt> and <tt>complex</tt>) this is important.  Koenig
1714 lookup isn't adequate, since names within the library must be
1715 qualified with <tt>std</tt> (see issue 225), specialization doesn't
1716 work (we don't have partial specialization of function templates), and
1717 users aren't permitted to add overloads within namespace std.
1718 ]</i></p>
1719
1720 <p><i>[Copenhagen: Discussed at length, with no consensus.  Relevant
1721 papers in the pre-Copenhagen mailing: N1289, N1295, N1296.  Discussion
1722 focused on four options. (1) Relax restrictions on overloads within
1723 namespace std. (2) Mandate that the standard library use unqualified
1724 calls for <tt>swap</tt> and possibly other functions.  (3) Introduce
1725 helper class templates for <tt>swap</tt> and possibly other functions.
1726 (4) Introduce partial specialization of function templates.  Every
1727 option had both support and opposition.  Straw poll (first number is
1728 support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
1729 (4) 4, 4.]</i></p>
1730
1731 <p><i>[Redmond: Discussed, again no consensus.  Herb presented an
1732 argument that a user who is defining a type <tt>T</tt> with an
1733 associated <tt>swap</tt> should not be expected to put that
1734 <tt>swap</tt> in namespace std, either by overloading or by partial
1735 specialization.  The argument is that <tt>swap</tt> is part of
1736 <tt>T</tt>'s interface, and thus should to in the same namespace as
1737 <tt>T</tt> and only in that namespace.  If we accept this argument,
1738 the consequence is that standard library functions should use
1739 unqualified call of <tt>swap</tt>.  (And which other functions? Any?)
1740 A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
1741 try to put together a proposal before the next meeting.]</i></p>
1742
1743 <p><i>[Cura&ccedil;ao: An LWG-subgroup spent an afternoon working on issues
1744 225, 226, and 229.  Their conclusion was that the issues should be
1745 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
1746 EWG portion (Dave will write a proposal). The LWG and EWG had
1747 (separate) discussions of this plan the next day.  The proposed
1748 resolution is the one proposed by Howard.]</i></p>
1749
1750 <hr>
1751 <a name="229"><h3>229.&nbsp;Unqualified references of other library entities</h3></a><p>
1752 <b>Section:</b>&nbsp;17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;19 Apr 2000</p>
1753 <p>Throughout the library chapters, the descriptions of library entities refer
1754 to other library entities without necessarily qualifying the names.</p>
1755
1756 <p>For example, section 25.2.2 &quot;Swap&quot; describes the effect of
1757 swap_ranges in terms of the unqualified name &quot;swap&quot;. This section
1758 could reasonably be interpreted to mean that the library must be implemented so
1759 as to do a lookup of the unqualified name &quot;swap&quot;, allowing users to
1760 override any ::std::swap function when Koenig lookup applies.</p>
1761
1762 <p>Although it would have been best to use explicit qualification with
1763 &quot;::std::&quot; throughout, too many lines in the standard would have to be
1764 adjusted to make that change in a Technical Corrigendum.</p>
1765
1766 <p>Issue <a href="lwg-defects.html#182">182</a>, which addresses qualification of
1767 <tt>size_t</tt>, is a special case of this.
1768 </p>
1769 <p><b>Proposed resolution:</b></p>
1770 <p>To section 17.4.1.1 &quot;Library contents&quot; Add the following paragraph:</p>
1771 <blockquote>
1772   <p>Whenever a name x defined in the standard library is mentioned, the name x
1773   is assumed to be fully qualified as ::std::x, unless explicitly described
1774   otherwise. For example, if the Effects section for library function F is
1775   described as calling library function G, the function ::std::G is meant.</p>
1776 </blockquote>
1777
1778 <p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
1779 the LWG to solve a problem in the standard itself similar to the
1780 problem within implementations of library identified by issue <a href="lwg-active.html#225">225</a>.  Any resolution of issue <a href="lwg-active.html#225">225</a> should be
1781 coordinated with the resolution of this issue.]</i></p>
1782
1783 <p><i>[post-Toronto: Howard is undecided about whether it is
1784 appropriate for all standard library function names referred to in
1785 other standard library functions to be explicitly qualified by
1786 <tt>std</tt>: it is common advice that users should define global
1787 functions that operate on their class in the same namespace as the
1788 class, and this requires argument-dependent lookup if those functions
1789 are intended to be called by library code.  Several LWG members are
1790 concerned that valarray appears to require argument-dependent lookup,
1791 but that the wording may not be clear enough to fall under
1792 &quot;unless explicitly described otherwise&quot;.]</i></p>
1793
1794 <p><i>[Cura&ccedil;ao: An LWG-subgroup spent an afternoon working on issues
1795 225, 226, and 229.  Their conclusion was that the issues should be
1796 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
1797 EWG portion (Dave will write a proposal). The LWG and EWG had
1798 (separate) discussions of this plan the next day.  This paper resolves
1799 issues 225 and 226.  In light of that resolution, the proposed
1800 resolution for the current issue makes sense.]</i></p>
1801
1802 <hr>
1803 <a name="231"><h3>231.&nbsp;Precision in iostream?</h3></a><p>
1804 <b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze, Stephen Clamage&nbsp; <b>Date:</b>&nbsp; 25 Apr 2000</p>
1805 <p>What is the following program supposed to output?</p>
1806 <pre>#include &lt;iostream&gt;
1807
1808     int
1809     main()
1810     {
1811         std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
1812         std::cout.precision( 0 ) ;
1813         std::cout &lt;&lt; 1.00 &lt;&lt; '\n' ;
1814         return 0 ;
1815     }</pre>
1816 <p>From my C experience, I would expect &quot;1e+00&quot;; this is what
1817 <tt>printf(&quot;%.0e&quot; , 1.00 );</tt> does. G++ outputs
1818 &quot;1.000000e+00&quot;.</p>
1819
1820 <p>The only indication I can find in the standard is 22.2.2.2.2/11,
1821 where it says &quot;For conversion from a floating-point type, if
1822 (flags &amp; fixed) != 0 or if str.precision() &gt; 0, then
1823 str.precision() is specified in the conversion specification.&quot;
1824 This is an obvious error, however, fixed is not a mask for a field,
1825 but a value that a multi-bit field may take -- the results of and'ing
1826 fmtflags with ios::fixed are not defined, at least not if
1827 ios::scientific has been set. G++'s behavior corresponds to what might
1828 happen if you do use (flags &amp; fixed) != 0 with a typical
1829 implementation (floatfield == 3 &lt;&lt; something, fixed == 1
1830 &lt;&lt; something, and scientific == 2 &lt;&lt; something).</p>
1831
1832 <p>Presumably, the intent is either (flags &amp; floatfield) != 0, or
1833 (flags &amp; floatfield) == fixed; the first gives something more or
1834 less like the effect of precision in a printf floating point
1835 conversion. Only more or less, of course. In order to implement printf
1836 formatting correctly, you must know whether the precision was
1837 explicitly set or not. Say by initializing it to -1, instead of 6, and
1838 stating that for floating point conversions, if precision &lt; -1, 6
1839 will be used, for fixed point, if precision &lt; -1, 1 will be used,
1840 etc. Plus, of course, if precision == 0 and flags &amp; floatfield ==
1841 0, 1 should be = used. But it probably isn't necessary to emulate all
1842 of the anomalies of printf:-).</p>
1843 <p><b>Proposed resolution:</b></p>
1844 <p>
1845 Replace 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, paragraph 11, with the following
1846 sentence:
1847 </p>
1848 <blockquote>
1849 For conversion from a floating-point type,
1850 <tt><i>str</i>.precision()</tt> is specified in the conversion
1851 specification.
1852 </blockquote>
1853 <p><b>Rationale:</b></p>
1854 <p>The floatfield determines whether numbers are formatted as if
1855 with %f, %e, or %g.  If the <tt>fixed</tt> bit is set, it's %f,
1856 if <tt>scientific</tt> it's %e, and if both bits are set, or
1857 neither, it's %g.</p>
1858 <p>Turning to the C standard, a precision of 0 is meaningful
1859 for %f and %e.  For %g, precision 0 is taken to be the same as
1860 precision 1.</p>
1861 <p>The proposed resolution has the effect that if neither
1862 <tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
1863 specifying a precision of 0, which will be internally
1864 turned into 1.  There's no need to call it out as a special
1865 case.</p>
1866 <p>The output of the above program will be &quot;1e+00&quot;.</p>
1867
1868 <p><i>[Post-Cura&ccedil;ao: Howard provided improved wording covering the case
1869 where precision is 0 and mode is %g.]</i></p>
1870
1871 <hr>
1872 <a name="233"><h3>233.&nbsp;Insertion hints in associative containers</h3></a><p>
1873 <b>Section:</b>&nbsp;23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;30 Apr 2000</p>
1874 <p>
1875 If <tt>mm</tt> is a multimap and <tt>p</tt> is an iterator
1876 into the multimap, then <tt>mm.insert(p, x)</tt> inserts
1877 <tt>x</tt> into <tt>mm</tt> with <tt>p</tt> as a hint as
1878 to where it should go.  Table 69 claims that the execution time is
1879 amortized constant if the insert winds up taking place adjacent to
1880 <tt>p</tt>, but does not say when, if ever, this is guaranteed to
1881 happen.  All it says it that <tt>p</tt> is a hint as to where to
1882 insert.
1883 </p>
1884 <p>
1885 The question is whether there is any guarantee about the relationship
1886 between <tt>p</tt> and the insertion point, and, if so, what it
1887 is.
1888 </p>
1889 <p>
1890 I believe the present state is that there is no guarantee: The user
1891 can supply <tt>p</tt>, and the implementation is allowed to
1892 disregard it entirely.
1893 </p>
1894
1895 <p>
1896 <b>Additional comments from Nathan:</b><br>
1897
1898 The vote [in Redmond] was on whether to elaborately specify the use of
1899 the hint, or to require behavior only if the value could be inserted
1900 adjacent to the hint.  I would like to ensure that we have a chance to
1901 vote for a deterministic treatment: &quot;before, if possible, otherwise
1902 after, otherwise anywhere appropriate&quot;, as an alternative to the
1903 proposed &quot;before or after, if possible, otherwise [...]&quot;.
1904 </p>
1905
1906
1907 <p><b>Proposed resolution:</b></p>
1908
1909 <p>In table 69 &quot;Associative Container Requirements&quot; in 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in the row for <tt>a.insert(p, t)</tt>,
1910 change</p>
1911
1912 <blockquote>
1913 iterator p is a hint pointing to where the insert
1914 should start to search.
1915 </blockquote>
1916
1917 <p>to</p>
1918
1919 <blockquote>
1920 insertion adjacent to iterator p is preferred if
1921 more than one insertion point is valid.
1922 </blockquote>
1923
1924 <p>and change</p>
1925
1926 <blockquote>
1927 logarithmic in general, but amortized constant if
1928 t is inserted right after p.
1929 </blockquote>
1930
1931 <p>to</p>
1932
1933 <blockquote>
1934 logarithmic in general, but amortized constant if
1935 t is inserted adjacent to iterator p.
1936 </blockquote>
1937
1938 <p><i>[Toronto: there was general agreement that this is a real defect:
1939 when inserting an element x into a multiset that already contains
1940 several copies of x, there is no way to know whether the hint will be
1941 used.  The proposed resolution was that the new element should always
1942 be inserted as close to the hint as possible.  So, for example, if
1943 there is a subsequence of equivalent values, then providing a.begin()
1944 as the hint means that the new element should be inserted before the
1945 subsequence even if a.begin() is far away.  JC van Winkel supplied
1946 precise wording for this proposed resolution, and also for an
1947 alternative resolution in which hints are only used when they are
1948 adjacent to the insertion point.]</i></p>
1949
1950 <p><i>[Copenhagen: the LWG agreed to the original proposed resolution,
1951 in which an insertion hint would be used even when it is far from the
1952 insertion point.  This was contingent on seeing a reference
1953 implementation showing that it is possible to implement this
1954 requirement without loss of efficiency.  John Potter provided such a
1955 reference implementation.]</i></p>
1956
1957 <p><i>[Redmond: The LWG was reluctant to adopt the proposal that
1958 emerged from Copenhagen: it seemed excessively complicated, and went
1959 beyond fixing the defect that we identified in Toronto.  PJP provided
1960 the new wording described in this issue.  Nathan agrees that we
1961 shouldn't adopt the more detailed semantics, and notes: &quot;we know that
1962 you can do it efficiently enough with a red-black tree, but there are
1963 other (perhaps better) balanced tree techniques that might differ
1964 enough to make the detailed semantics hard to satisfy.&quot;]</i></p>
1965
1966 <p><i>[Cura&ccedil;ao: Nathan should give us the alternative wording he
1967 suggests so the LWG can decide between the two options.]</i></p>
1968
1969 <hr>
1970 <a name="241"><h3>241.&nbsp;Does unique_copy() require CopyConstructible and Assignable?</h3></a><p>
1971 <b>Section:</b>&nbsp;25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
1972
1973 <p>Some popular implementations of unique_copy() create temporary
1974 copies of values in the input sequence, at least if the input iterator
1975 is a pointer.  Such an implementation is built on the assumption that
1976 the value type is CopyConstructible and Assignable.</p>
1977
1978 <p>It is common practice in the standard that algorithms explicitly
1979 specify any additional requirements that they impose on any of the
1980 types used by the algorithm. An example of an algorithm that creates
1981 temporary copies and correctly specifies the additional requirements
1982 is accumulate(), 26.4.1 <a href="lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p>
1983
1984 <p>Since the specifications of unique() and unique_copy() do not
1985 require CopyConstructible and Assignable of the InputIterator's value
1986 type the above mentioned implementations are not standard-compliant. I
1987 cannot judge whether this is a defect in the standard or a defect in
1988 the implementations.</p>
1989 <p><b>Proposed resolution:</b></p>
1990 <p>In 25.2.8 change:</p>
1991
1992 <blockquote>
1993 -4- Requires: The ranges [first, last) and [result, result+(last-first))
1994 shall not overlap.
1995 </blockquote>
1996
1997 <p>to:</p>
1998
1999 <blockquote>
2000   <p>-4- Requires: The ranges [first, last) and [result,
2001   result+(last-first)) shall not overlap. The expression *result =
2002   *first must be valid. If neither InputIterator nor OutputIterator
2003   meets the requirements of forward iterator then the value type of
2004   InputIterator must be copy constructible. Otherwise copy
2005   constructible is not required. </p>
2006 </blockquote>
2007
2008 <p><i>[Redmond: the original proposed resolution didn't impose an
2009 explicit requirement that the iterator's value type must be copy
2010 constructible, on the grounds that an input iterator's value type must
2011 always be copy constructible.  Not everyone in the LWG thought that
2012 this requirement was clear from table 72.  It has been suggested that
2013 it might be possible to implement <tt>unique_copy</tt> without
2014 requiring assignability, although current implementations do impose
2015 that requirement.  Howard provided new wording.]</i></p>
2016
2017 <p><i>[
2018 Cura&ccedil;ao: The LWG changed the PR editorially to specify
2019 &quot;neither...nor...meet...&quot; as clearer than
2020 &quot;both...and...do not meet...&quot;. Change believed to be so
2021 minor as not to require re-review.
2022 ]</i></p>
2023
2024 <hr>
2025 <a name="247"><h3>247.&nbsp;<tt>vector</tt>, <tt>deque::insert</tt> complexity</h3></a><p>
2026 <b>Section:</b>&nbsp;23.2.4.3 <a href="lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;06 June 2000</p>
2027 <p>Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity
2028 of <tt>vector::insert</tt>:</p>
2029
2030    <blockquote>
2031    Complexity: If first and last are forward iterators, bidirectional
2032    iterators, or random access iterators, the complexity is linear in
2033    the number of elements in the range [first, last) plus the distance
2034    to the end of the vector. If they are input iterators, the complexity
2035    is proportional to the number of elements in the range [first, last)
2036    times the distance to the end of the vector.
2037    </blockquote>
2038
2039 <p>First, this fails to address the non-iterator forms of
2040 <tt>insert</tt>.</p>
2041
2042 <p>Second, the complexity for input iterators misses an edge case --
2043 it requires that an arbitrary number of elements can be added at
2044 the end of a <tt>vector</tt> in constant time.</p>
2045
2046 <p>At the risk of strengthening the requirement, I suggest simply</p>
2047
2048    <blockquote>
2049    Complexity: The complexity is linear in the number of elements
2050    inserted plus the distance to the end of the vector.
2051    </blockquote>
2052
2053 <p>For input iterators, one may achieve this complexity by first
2054 inserting at the end of the <tt>vector</tt>, and then using
2055 <tt>rotate</tt>.</p>
2056
2057 <p>I looked to see if <tt>deque</tt> had a similar problem, and was
2058 surprised to find that <tt>deque</tt> places no requirement on the
2059 complexity of inserting multiple elements (23.2.1.3 <a href="lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>,
2060 paragraph 3):</p>
2061
2062    <blockquote>
2063    Complexity: In the worst case, inserting a single element into a
2064    deque takes time linear in the minimum of the distance from the
2065    insertion point to the beginning of the deque and the distance
2066    from the insertion point to the end of the deque. Inserting a
2067    single element either at the beginning or end of a deque always
2068    takes constant time and causes a single call to the copy constructor
2069    of T.
2070    </blockquote>
2071
2072 <p>I suggest:</p>
2073
2074    <blockquote>
2075    Complexity: The complexity is linear in the number of elements
2076    inserted plus the shorter of the distances to the beginning and
2077    end of the deque.  Inserting a single element at either the
2078    beginning or the end of a deque causes a single call to the copy
2079    constructor of T.
2080    </blockquote>
2081 <p><b>Proposed resolution:</b></p>
2082
2083 <p><i>[Toronto: It's agreed that there is a defect in complexity of
2084 multi-element insert for vector and deque.  For vector, the complexity
2085 should probably be something along the lines of <tt>c<sub>1</sub> * N
2086 + c<sub>2</sub> * distance(i, end())</tt>.  However, there is some
2087 concern about whether it is reasonable to amortize away the copies
2088 that we get from a reallocation whenever we exceed the vector's
2089 capacity.  For deque, the situation is somewhat less clear.  Deque is
2090 notoriously complicated, and we may not want to impose complexity
2091 requirements that would imply any implementation technique more
2092 complicated than a while loop whose body is a single-element
2093 insert.]</i></p>
2094 <hr>
2095 <a name="253"><h3>253.&nbsp;valarray helper functions are almost entirely useless</h3></a><p>
2096 <b>Section:</b>&nbsp;26.3.2.1 <a href="lib-numerics.html#lib.valarray.cons"> [lib.valarray.cons]</a>, 26.3.2.2 <a href="lib-numerics.html#lib.valarray.assign"> [lib.valarray.assign]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Robert Klarer&nbsp; <b>Date:</b>&nbsp;31 Jul 2000</p>
2097 <p>This discussion is adapted from message c++std-lib-7056 posted
2098 November 11, 1999.  I don't think that anyone can reasonably claim
2099 that the problem described below is NAD.</p>
2100
2101 <p>These valarray constructors can never be called:</p>
2102
2103 <pre>
2104    template &lt;class T&gt;
2105          valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
2106    template &lt;class T&gt;
2107          valarray&lt;T&gt;::valarray(const gslice_array&lt;T&gt; &amp;);
2108    template &lt;class T&gt;
2109          valarray&lt;T&gt;::valarray(const mask_array&lt;T&gt; &amp;);
2110    template &lt;class T&gt;
2111          valarray&lt;T&gt;::valarray(const indirect_array&lt;T&gt; &amp;);
2112 </pre>
2113
2114 <p>Similarly, these valarray assignment operators cannot be
2115 called:</p>
2116
2117 <pre>
2118      template &lt;class T&gt;
2119      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const slice_array&lt;T&gt; &amp;);
2120      template &lt;class T&gt;
2121      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const gslice_array&lt;T&gt; &amp;);
2122      template &lt;class T&gt;
2123      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const mask_array&lt;T&gt; &amp;);
2124      template &lt;class T&gt;
2125      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const indirect_array&lt;T&gt; &amp;);
2126 </pre>
2127
2128 <p>Please consider the following example:</p>
2129
2130 <pre>
2131    #include &lt;valarray&gt;
2132    using namespace std;
2133
2134    int main()
2135    {
2136        valarray&lt;double&gt; va1(12);
2137        valarray&lt;double&gt; va2(va1[slice(1,4,3)]); // line 1
2138    }
2139 </pre>
2140
2141
2142 <p>Since the valarray va1 is non-const, the result of the sub-expression
2143 va1[slice(1,4,3)] at line 1 is an rvalue of type const
2144 std::slice_array&lt;double&gt;.  This slice_array rvalue is then used to
2145 construct va2.  The constructor that is used to construct va2 is
2146 declared like this:</p>
2147
2148 <pre>
2149      template &lt;class T&gt;
2150      valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
2151 </pre>
2152
2153 <p>Notice the constructor's const reference parameter.  When the
2154 constructor is called, a slice_array must be bound to this reference.
2155 The rules for binding an rvalue to a const reference are in 8.5.3,
2156 paragraph 5 (see also 13.3.3.1.4).  Specifically, paragraph 5
2157 indicates that a second slice_array rvalue is constructed (in this
2158 case copy-constructed) from the first one; it is this second rvalue
2159 that is bound to the reference parameter.  Paragraph 5 also requires
2160 that the constructor that is used for this purpose be callable,
2161 regardless of whether the second rvalue is elided.  The
2162 copy-constructor in this case is not callable, however, because it is
2163 private.  Therefore, the compiler should report an error.</p>
2164
2165 <p>Since slice_arrays are always rvalues, the valarray constructor that has a
2166 parameter of type const slice_array&lt;T&gt; &amp; can never be called.  The
2167 same reasoning applies to the three other constructors and the four
2168 assignment operators that are listed at the beginning of this post.
2169 Furthermore, since these functions cannot be called, the valarray helper
2170 classes are almost entirely useless.</p>
2171 <p><b>Proposed resolution:</b></p>
2172 <p>slice_array:</p>
2173 <ul>
2174 <li> remove the copy constructor and copy-assignment operator declarations
2175     from the slice_array class template definition in 26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> </li>
2176 <li> remove paragraph 3 of 26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>
2177 </li>
2178 <li> remove the copy constructor declaration from 26.3.5.1 <a href="lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a>
2179 </li>
2180 <li> change paragraph 1 of 26.3.5.1 <a href="lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a> to read &quot;This constructor is declared
2181     to be private.  This constructor need not be defined.&quot;</li>
2182 <li> remove the copy-assignment operator declaration from 26.3.5.2 <a href="lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a>
2183 </li>
2184 <li> remove the first sentence of paragraph 1 of 26.3.5.2 <a href="lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a>
2185 </li>
2186 <li> Change the first two words of the second sentence of paragraph 1 of
2187     26.3.5.2 <a href="lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> to &quot;This function.&quot;</li>
2188 </ul>
2189
2190 <p>gslice_array:</p>
2191 <ul>
2192 <li> remove the copy constructor and copy-assignment operator declarations
2193     from the gslice_array class template definition in 26.3.7 <a href="lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> </li>
2194 <li> remove the note in paragraph 3 of 26.3.7 <a href="lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a>
2195 </li>
2196 <li> remove the copy constructor declaration from 26.3.7.1 <a href="lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a>
2197 </li>
2198 <li> change paragraph 1 of 26.3.7.1 <a href="lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a> to read &quot;This constructor is declared
2199     to be private.  This constructor need not be defined.&quot;</li>
2200 <li> remove the copy-assignment operator declaration from 26.3.7.2 <a href="lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a>
2201 </li>
2202 <li> remove the first sentence of paragraph 1 of 26.3.7.2 <a href="lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a>
2203 </li>
2204 <li> Change the first two words of the second sentence of paragraph 1 of
2205     26.3.7.2 <a href="lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a> to &quot;This function.&quot;</li>
2206 </ul>
2207
2208 <p>mask_array:</p>
2209 <ul>
2210 <li> remove the copy constructor and copy-assignment operator declarations
2211     from the mask_array class template definition in 26.3.8 <a href="lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> </li>
2212 <li> remove the note in paragraph 2 of 26.3.8 <a href="lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a>
2213 </li>
2214 <li> remove the copy constructor declaration from 26.3.8.1 <a href="lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a>
2215 </li>
2216 <li> change paragraph 1 of 26.3.8.1 <a href="lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a> to read &quot;This constructor is declared
2217     to be private.  This constructor need not be defined.&quot;</li>
2218 <li> remove the first sentence of paragraph 1 of 26.3.8.2 <a href="lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a>
2219 </li>
2220 <li> Change the first two words of the second sentence of paragraph 1 of
2221     26.3.8.2 <a href="lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a> to &quot;This function.&quot;</li>
2222 </ul>
2223
2224 <p>indirect_array:</p>
2225 <ul>
2226 <li>remove the copy constructor and copy-assignment operator declarations
2227     from the indirect_array class definition in 26.3.9 <a href="lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
2228 </li>
2229 <li> remove the note in paragraph 2 of 26.3.9 <a href="lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
2230 </li>
2231 <li> remove the copy constructor declaration from 26.3.9.1 <a href="lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a>
2232 </li>
2233 <li> change the descriptive text in 26.3.9.1 <a href="lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a> to read &quot;This constructor is
2234     declared to be private.  This constructor need not be defined.&quot;</li>
2235 <li> remove the first sentence of paragraph 1 of 26.3.9.2 <a href="lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a>
2236 </li>
2237 <li> Change the first two words of the second sentence of paragraph 1 of
2238     26.3.9.2 <a href="lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a> to &quot;This function.&quot;</li>
2239 </ul>
2240 <p><i>[This wording is taken from Robert Klarer's reflector message,
2241 c++std-lib-7827.  Gabriel Dos Reis agrees that this general solution
2242 is correct.]</i></p>
2243 <p><b>Rationale:</b></p>
2244 <p>Keeping the valarray constructors private is untenable.  Merely
2245 making valarray a friend of the helper classes isn't good enough,
2246 because access to the copy constructor is checked in the user's
2247 environment.</p>
2248
2249 <p>Making the assignment operator public is not strictly necessary to
2250 solve this problem.  A majority of the LWG <i>(straw poll: 13-4)</i>
2251 believed we should make the assignment operators public, in addition
2252 to the copy constructors, for reasons of symmetry and user
2253 expectation.</p>
2254 <hr>
2255 <a name="254"><h3>254.&nbsp;Exception types in clause 19 are constructed from <tt>std::string</tt>
2256 </h3></a><p>
2257 <b>Section:</b>&nbsp;19.1 <a href="lib-diagnostics.html#lib.std.exceptions"> [lib.std.exceptions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Aug 2000</p>
2258 <p>
2259 Many of the standard exception types which implementations are
2260 required to throw are constructed with a const std::string&amp;
2261 parameter. For example:
2262 </p>
2263
2264 <pre>
2265      19.1.5  Class out_of_range                          [lib.out.of.range]
2266      namespace std {
2267        class out_of_range : public logic_error {
2268        public:
2269          explicit out_of_range(const string&amp; what_arg);
2270        };
2271      }
2272
2273    1 The class out_of_range defines the type of objects  thrown  as  excep-
2274      tions to report an argument value not in its expected range.
2275
2276      out_of_range(const string&amp; what_arg);
2277
2278      Effects:
2279        Constructs an object of class out_of_range.
2280      Postcondition:
2281        strcmp(what(), what_arg.c_str()) == 0.
2282 </pre>
2283
2284 <p>
2285 There are at least two problems with this:
2286 </p>
2287 <ol>
2288 <li>A program which is low on memory may end up throwing
2289 std::bad_alloc instead of out_of_range because memory runs out while
2290 constructing the exception object.</li>
2291 <li>An obvious implementation which stores a std::string data member
2292 may end up invoking terminate() during exception unwinding because the
2293 exception object allocates memory (or rather fails to) as it is being
2294 copied.</li>
2295 </ol>
2296
2297 <p>
2298 There may be no cure for (1) other than changing the interface to
2299 out_of_range, though one could reasonably argue that (1) is not a
2300 defect. Personally I don't care that much if out-of-memory is reported
2301 when I only have 20 bytes left, in the case when out_of_range would
2302 have been reported. People who use exception-specifications might care
2303 a lot, though.
2304 </p>
2305
2306 <p>
2307 There is a cure for (2), but it isn't completely obvious. I think a
2308 note for implementors should be made in the standard. Avoiding
2309 possible termination in this case shouldn't be left up to chance.  The
2310 cure is to use a reference-counted &quot;string&quot; implementation
2311 in the exception object. I am not necessarily referring to a
2312 std::string here; any simple reference-counting scheme for a NTBS
2313 would do.
2314 </p>
2315
2316 <p><b>Further discussion, in email:</b></p>
2317
2318 <p>
2319 ...I'm not so concerned about (1). After all, a library implementation
2320 can add const char* constructors as an extension, and users don't
2321 <i>need</i> to avail themselves of the standard exceptions, though this is
2322 a lame position to be forced into.  FWIW, std::exception and
2323 std::bad_alloc don't require a temporary basic_string.
2324 </p>
2325
2326 <p>
2327 ...I don't think the fixed-size buffer is a solution to the problem,
2328 strictly speaking, because you can't satisfy the postcondition
2329 <br>
2330     <tt>&nbsp;&nbsp;strcmp(what(), what_arg.c_str()) == 0</tt>
2331 <br>
2332 For all values of what_arg (i.e. very long values). That means that
2333 the only truly conforming solution requires a dynamic allocation.
2334 </p>
2335
2336 <p><b>Further discussion, from Redmond:</b></p>
2337
2338 <p>The most important progress we made at the Redmond meeting was
2339 realizing that there are two separable issues here: the const
2340 string&amp; constructor, and the copy constructor.  If a user writes
2341 something like <tt>throw std::out_of_range(&quot;foo&quot;)</tt>, the const
2342 string&amp; constructor is invoked before anything gets thrown.  The
2343 copy constructor is potentially invoked during stack unwinding.</p>
2344
2345 <p>The copy constructor is a more serious problem, becuase failure
2346 during stack unwinding invokes <tt>terminate</tt>.  The copy
2347 constructor must be nothrow. <i>Cura&ccedil;ao: Howard thinks this
2348 requirement is already present.</i>
2349 </p>
2350
2351 <p>The fundamental problem is that it's difficult to get the nothrow
2352 requirement to work well with the requirement that the exception
2353 objects store a string of unbounded size, particularly if you also try
2354 to make the const string&amp; constructor nothrow.  Options discussed
2355 include:</p>
2356
2357 <ul>
2358 <li>Limit the size of a string that exception objects are required to
2359 throw: change the postconditions of 19.1.2 <a href="lib-diagnostics.html#lib.domain.error"> [lib.domain.error]</a> paragraph 3
2360 and 19.1.6 <a href="lib-diagnostics.html#lib.runtime.error"> [lib.runtime.error]</a> paragraph 3 to something like this:
2361 &quot;strncmp(what(), what_arg._str(), N) == 0, where N is an
2362 implementation defined constant no smaller than 256&quot;.</li>
2363 <li>Allow the const string&amp; constructor to throw, but not the
2364 copy constructor.  It's the implementor's responsibility to get it
2365 right.  (An implementor might use a simple refcount class.)</li>
2366 <li>Compromise between the two: an implementation is not allowed to
2367 throw if the string's length is less than some N, but, if it doesn't
2368 throw, the string must compare equal to the argument.</li>
2369 <li>Add a new constructor that takes a const char*</li>
2370 </ul>
2371
2372 <p>(Not all of these options are mutually exclusive.)</p>
2373
2374 <p><b>Proposed resolution:</b></p>
2375 <p>NAD/Future</p>
2376 <p><b>Rationale:</b></p>
2377
2378 <p>Throwing a bad_alloc while trying to construct a message for another
2379 exception-derived class is not necessarily a bad thing.  And the
2380 bad_alloc constructor already has a no throw spec on it (18.4.2.1).</p>
2381
2382 <p>
2383 The copy constructors of all exception-derived classes already have a
2384 no throw spec.  Reference 18.6.1,  19.1 and 15.4/13.
2385 </p>
2386
2387 <p><b>Future:</b></p>
2388
2389 <p>All involved would like to see const char* constructors added, but
2390 this should probably be done for C++0X as opposed to a DR.</p>
2391
2392 <p>I believe the no throw specs currently decorating these functions
2393 could be improved by some kind of static no throw spec checking
2394 mechanism (in a future C++ language).  As they stand, the copy
2395 constructors might fail via a call to unexpected.  I think what is
2396 intended here is that the copy constructors can't fail.</p>
2397
2398 <p><i>[Toronto: some LWG members thought this was merely a QoI issue,
2399 but most believed that it was at least a borderline defect.  There was
2400 more support for nonnormative advice to implementors than for a
2401 normative change.]</i></p>
2402
2403 <p><i>[Redmond: discussed, without definite conclusion.  Most LWG
2404 members thought there was a real defect lurking here.  The above
2405 proposed resolution/rationale is from Howard, Herb, Kevlin,  Martin,
2406 and Dave.]</i></p>
2407
2408 <hr>
2409 <a name="258"><h3>258.&nbsp;Missing allocator requirement</h3></a><p>
2410 <b>Section:</b>&nbsp;20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;22 Aug 2000</p>
2411 <p>
2412 From lib-7752:
2413 </p>
2414
2415 <p>
2416 I've been assuming (and probably everyone else has been assuming) that
2417 allocator instances have a particular property, and I don't think that
2418 property can be deduced from anything in Table 32.
2419 </p>
2420
2421 <p>
2422 I think we have to assume that allocator type conversion is a
2423 homomorphism.  That is, if x1 and x2 are of type X, where
2424 X::value_type is T, and if type Y is X::template
2425 rebind&lt;U&gt;::other, then Y(x1) == Y(x2) if and only if x1 == x2.
2426 </p>
2427
2428 <p>
2429 Further discussion: Howard Hinnant writes, in lib-7757:
2430 </p>
2431
2432 <p>
2433 I think I can prove that this is not provable by Table 32.  And I agree
2434 it needs to be true except for the &quot;and only if&quot;.  If x1 != x2, I see no
2435 reason why it can't be true that Y(x1) == Y(x2).  Admittedly I can't
2436 think of a practical instance where this would happen, or be valuable.
2437 But I also don't see a need to add that extra restriction.  I think we
2438 only need:
2439 </p>
2440
2441 <blockquote>
2442      if (x1 == x2) then Y(x1) == Y(x2)
2443 </blockquote>
2444
2445 <p>
2446 If we decide that == on allocators is transitive, then I think I can
2447 prove the above.  But I don't think == is necessarily transitive on
2448 allocators.  That is:
2449 </p>
2450
2451 <p>
2452 Given x1 == x2  and x2 == x3, this does not mean x1 == x3.
2453 </p>
2454
2455 <p>Example:</p>
2456
2457 <blockquote>
2458 <p>
2459 x1 can deallocate pointers from:  x1, x2, x3    <br>
2460 x2 can deallocate pointers from:  x1, x2, x4    <br>
2461 x3 can deallocate pointers from:  x1, x3        <br>
2462 x4 can deallocate pointers from:  x2, x4
2463 </p>
2464
2465 <p>
2466 x1 == x2, and x2 == x4, but x1 != x4
2467 </p>
2468 </blockquote>
2469 <p><b>Proposed resolution:</b></p>
2470
2471 <p><i>[Toronto: LWG members offered multiple opinions.  One
2472 opinion is that it should not be required that <tt>x1 == x2</tt>
2473 implies <tt>Y(x1) == Y(x2)</tt>, and that it should not even be
2474 required that <tt>X(x1) == x1</tt>.  Another opinion is that
2475 the second line from the bottom in table 32 already implies the
2476 desired property.  This issue should be considered in light of
2477 other issues related to allocator instances.]</i></p>
2478 <hr>
2479 <a name="278"><h3>278.&nbsp;What does iterator validity mean?</h3></a><p>
2480 <b>Section:</b>&nbsp;23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;P.J. Plauger&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
2481 <p>
2482 Section 23.2.2.4 [lib.list.ops] states that
2483 </p>
2484 <pre>
2485   void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
2486 </pre>
2487 <p>
2488 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
2489 </p>
2490
2491 <p>
2492 But what does the C++ Standard mean by &quot;invalidate&quot;?  You
2493 can still dereference the iterator to a spliced list element, but
2494 you'd better not use it to delimit a range within the original
2495 list. For the latter operation, it has definitely lost some of its
2496 validity.
2497 </p>
2498
2499 <p>
2500 If we accept the proposed resolution to issue <a href="lwg-defects.html#250">250</a>,
2501 then we'd better clarify that a &quot;valid&quot; iterator need no
2502 longer designate an element within the same container as it once did.
2503 We then have to clarify what we mean by invalidating a past-the-end
2504 iterator, as when a vector or string grows by reallocation. Clearly,
2505 such an iterator has a different kind of validity. Perhaps we should
2506 introduce separate terms for the two kinds of &quot;validity.&quot;
2507 </p>
2508 <p><b>Proposed resolution:</b></p>
2509 <p>Add the following text to the end of section 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>,
2510 after paragraph 5:</p>
2511 <blockquote>
2512 An <i>invalid</i> iterator is an iterator that may be
2513 singular. [Footnote: This definition applies to pointers, since
2514 pointers are iterators. The effect of dereferencing an iterator that
2515 has been invalidated is undefined.]
2516 </blockquote>
2517
2518 <p><i>[post-Copenhagen: Matt provided wording.]</i></p>
2519
2520 <p><i>[Redmond: General agreement with the intent, some objections to
2521 the wording.  Dave provided new wording.]</i></p>
2522
2523 <p><i>[Cura&ccedil;ao: The definition of &quot;singular&quot; is
2524 contentious.&nbsp; The 278 resolution must be made consistent with
2525 issue <a href="lwg-defects.html#208">208</a> and 24.1/5. Furthermore, a Rationale paragraph
2526 is required.]</i></p>
2527
2528 <hr>
2529 <a name="280"><h3>280.&nbsp;Comparison of reverse_iterator to const reverse_iterator</h3></a><p>
2530 <b>Section:</b>&nbsp;24.4.1 <a href="lib-iterators.html#lib.reverse.iterators"> [lib.reverse.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Cleary&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
2531 <p>
2532 This came from an email from Steve Cleary to Fergus in reference to
2533 issue <a href="lwg-active.html#179">179</a>. The library working group briefly discussed
2534 this in Toronto and believed it should be a separate issue.  There was
2535 also some reservations about whether this was a worthwhile problem to
2536 fix.
2537 </p>
2538
2539 <p>
2540 Steve said: &quot;Fixing reverse_iterator. std::reverse_iterator can
2541 (and should) be changed to preserve these additional
2542 requirements.&quot; He also said in email that it can be done without
2543 breaking user's code: &quot;If you take a look at my suggested
2544 solution, reverse_iterator doesn't have to take two parameters; there
2545 is no danger of breaking existing code, except someone taking the
2546 address of one of the reverse_iterator global operator functions, and
2547 I have to doubt if anyone has ever done that. . .  <i>But</i>, just in
2548 case they have, you can leave the old global functions in as well --
2549 they won't interfere with the two-template-argument functions.  With
2550 that, I don't see how <i>any</i> user code could break.&quot;
2551 </p>
2552 <p><b>Proposed resolution:</b></p>
2553 <p>
2554 <b>Section:</b> 24.4.1.1 <a href="lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a>
2555 add/change the following declarations:</p>
2556 <pre>
2557   A) Add a templated assignment operator, after the same manner
2558         as the templated copy constructor, i.e.:
2559
2560   template &lt; class U &gt;
2561   reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
2562
2563   B) Make all global functions (except the operator+) have
2564   two template parameters instead of one, that is, for
2565   operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
2566
2567        template &lt; class Iterator &gt;
2568        typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
2569                  const reverse_iterator&lt; Iterator &gt;&amp; x,
2570                  const reverse_iterator&lt; Iterator &gt;&amp; y);
2571
2572   with:
2573
2574       template &lt; class Iterator1, class Iterator2 &gt;
2575       typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
2576                  const reverse_iterator &lt; Iterator1 &gt; &amp; x,
2577                  const reverse_iterator &lt; Iterator2 &gt; &amp; y);
2578 </pre>
2579 <p>
2580 Also make the addition/changes for these signatures in
2581 24.4.1.3 <a href="lib-iterators.html#lib.reverse.iter.ops"> [lib.reverse.iter.ops]</a>.
2582 </p>
2583
2584 <p><i>[
2585 Copenhagen: The LWG is concerned that the proposed resolution
2586 introduces new overloads.  Experience shows that introducing
2587 overloads is always risky, and that it would be inappropriate to
2588 make this change without implementation experience.  It may be
2589 desirable to provide this feature in a different way.
2590 ]</i></p>
2591
2592 <hr>
2593 <a name="282"><h3>282.&nbsp;What types does numpunct grouping refer to?</h3></a><p>
2594 <b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;5 Dec 2000</p>
2595 <p>
2596 Paragraph 16 mistakenly singles out integral types for inserting
2597 thousands_sep() characters.  This conflicts with the syntax for floating
2598 point numbers described under 22.2.3.1/2.
2599 </p>
2600 <p><b>Proposed resolution:</b></p>
2601 <p>Change paragraph 16 from:</p>
2602
2603 <blockquote>
2604 For integral types, punct.thousands_sep() characters are inserted into
2605 the sequence as determined by the value returned by punct.do_grouping()
2606 using the method described in 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>.
2607 </blockquote>
2608
2609 <p>To:</p>
2610
2611 <blockquote>
2612 For arithmetic types, punct.thousands_sep() characters are inserted into
2613 the sequence as determined by the value returned by punct.do_grouping()
2614 using the method described in 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>.
2615 </blockquote>
2616
2617 <p><i>[
2618 Copenhagen: Opinions were divided about whether this is actually an
2619 inconsistency, but at best it seems to have been unintentional.  This
2620 is only an issue for floating-point output: The standard is
2621 unambiguous that implementations must parse thousands_sep characters
2622 when performing floating-point.  The standard is also unambiguous that
2623 this requirement does not apply to the &quot;C&quot; locale.
2624 ]</i></p>
2625
2626 <p><i>[
2627 A survey of existing practice is needed; it is believed that some
2628 implementations do insert thousands_sep characters for floating-point
2629 output and others fail to insert thousands_sep characters for
2630 floating-point input even though this is unambiguously required by the
2631 standard.
2632 ]</i></p>
2633
2634 <p><i>[Post-Cura&ccedil;ao: the above proposed resolution is the consensus of
2635 Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
2636
2637 <hr>
2638 <a name="283"><h3>283.&nbsp;std::replace() requirement incorrect/insufficient</h3></a><p>
2639 <b>Section:</b>&nbsp;25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Dec 2000</p>
2640 <p>
2641 The requirements in 25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>, p1 that <tt>T</tt> to be
2642 <tt>Assignable</tt> (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>) is not necessary or
2643 sufficient for either of the algorithms. The algorithms require that
2644 <tt>std::iterator_traits&lt;ForwardIterator&gt;::value_type</tt> be
2645 <tt>Assignable</tt> and that both
2646 <tt>std::iterator_traits&lt;ForwardIterator&gt;::value_type</tt> and be
2647 <tt>EqualityComparable</tt> (20.1.1 <a href="lib-utilities.html#lib.equalitycomparable"> [lib.equalitycomparable]</a>) with respect to
2648 one another.
2649 </p>
2650
2651 <p>
2652 <b>Further discussion, from Jeremy</b>:
2653 </p>
2654
2655 <p>There are a number of problems with the requires clauses for the
2656 algorithms in 25.1 <a href="lib-algorithms.html#lib.alg.nonmodifying"> [lib.alg.nonmodifying]</a> and 25.2 <a href="lib-algorithms.html#lib.alg.modifying.operations"> [lib.alg.modifying.operations]</a>. The requires
2657 clause of each algorithm should describe the necessary and sufficient
2658 requirements on the inputs to the algorithm such that the algorithm
2659 compiles and runs properly.  Many of the requires clauses fail to do
2660 this. Here is a summary of the kinds of mistakes:</p>
2661
2662 <ol>
2663 <li> Use of EqualityComparable, which only puts requirements on a single
2664   type, when in fact an equality operator is required between two
2665   different types, typically either T and the iterators value_type
2666   or between the value_type's of two different iterators.</li>
2667
2668 <li> Use of Assignable for T when in fact what was needed is Assignable
2669   for the value_type of the iterator, and convertability from T to the
2670   value_type of the iterator. Or for output iterators, the requirement
2671   should be that T is writable to the iterator (output iterators do
2672   not have value types; see issue <a href="lwg-active.html#324">324</a>).</li>
2673
2674 <li> Lack of a requires clause.</li>
2675 </ol>
2676
2677 <p>Here is the list of algorithms that contain mistakes:</p>
2678 <ul>
2679 <li>25.1.2 <a href="lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a>
2680 </li>
2681 <li>25.1.3 <a href="lib-algorithms.html#lib.alg.find.end"> [lib.alg.find.end]</a>
2682 </li>
2683 <li>25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a>
2684 </li>
2685 <li>25.1.6 <a href="lib-algorithms.html#lib.alg.count"> [lib.alg.count]</a>
2686 </li>
2687 <li>25.1.7 <a href="lib-algorithms.html#lib.mismatch"> [lib.mismatch]</a>
2688 </li>
2689 <li>25.1.8 <a href="lib-algorithms.html#lib.alg.equal"> [lib.alg.equal]</a>
2690 </li>
2691 <li>25.1.9 <a href="lib-algorithms.html#lib.alg.search"> [lib.alg.search]</a>
2692 </li>
2693 <li>25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>
2694 </li>
2695 <li>25.2.5 <a href="lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a>
2696 </li>
2697 <li>25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a>
2698 </li>
2699 </ul>
2700
2701 <p>Also, in the requirements for EqualityComparable, the requirement that
2702 the operator be defined for const objects is lacking.</p>
2703 <p><b>Proposed resolution:</b></p>
2704 <p>20.1.1 <a href="lib-utilities.html#lib.equalitycomparable"> [lib.equalitycomparable]</a> Change p1 from</p>
2705
2706 <blockquote>
2707 In Table 28, T is a type to be supplied by a C++ program instantiating
2708 a template, a, b, and c are values of type T.
2709 </blockquote>
2710
2711 <p>to</p>
2712
2713 <blockquote>
2714 In Table 28, T is a type to be supplied by a C++ program instantiating
2715 a template, a, b, and c are values of type const T.
2716 </blockquote>
2717
2718 <p>25.1.2 <a href="lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a> Change p1 from</p>
2719
2720 <blockquote>
2721 Requires: Type T is EqualityComparable (20.1.1).
2722 </blockquote>
2723
2724 <p>to </p>
2725
2726 <blockquote>
2727 Requires: There must be a equality operator defined that accepts type
2728 std::iterator_traits&lt;InputIterator&gt;::reference for the left operand
2729 and const T for the right operand.
2730 </blockquote>
2731
2732
2733 <p>25.1.3 <a href="lib-algorithms.html#lib.alg.find.end"> [lib.alg.find.end]</a> Add the following requires clause</p>
2734
2735 <blockquote>
2736 Requires: There must be an equality operator defined that accepts
2737 type const std::iterator_traits&lt;ForwardIterator1&gt;::value_type for the
2738 left operand and const
2739 std::iterator_traits&lt;ForwardIterator2&gt;::value_type for the right
2740 operand.
2741 </blockquote>
2742
2743 <p>25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> Add the following requires clause</p>
2744
2745 <blockquote>
2746 Requires: There must be an equality operator defined that accepts
2747 type const std::iterator_traits&lt;ForwardIterator1&gt;::value_type for the
2748 left operand and const
2749 std::iterator_traits&lt;ForwardIterator2&gt;::value_type for the right
2750 operand.
2751 </blockquote>
2752
2753
2754 <p>25.1.5 <a href="lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a> Add the following requires clause</p>
2755
2756 <blockquote>
2757 Requires: T must be EqualityComparable (20.1.1).
2758 </blockquote>
2759
2760 <p>25.1.6 <a href="lib-algorithms.html#lib.alg.count"> [lib.alg.count]</a> Change p1 from</p>
2761
2762 <blockquote>
2763 Requires: Type T is EqualityComparable (20.1.1).
2764 </blockquote>
2765
2766 <p>to</p>
2767
2768 <blockquote>
2769 Requires: There must be a equality operator defined that accepts type
2770 std::iterator_traits&lt;InputIterator&gt;::reference for the left operand
2771 and const T for the right operand.
2772 </blockquote>
2773
2774 <p>25.1.7 <a href="lib-algorithms.html#lib.mismatch"> [lib.mismatch]</a> Add the following requires clause</p>
2775
2776 <blockquote>
2777 Requires: There must be an equality operator defined that accepts type
2778 std::iterator_traits&lt;InputIterator1&gt;::reference for the left operand
2779 and std::iterator_traits&lt;InputIterator2&gt;::reference for the right operand.
2780 </blockquote>
2781
2782
2783 <p>25.1.8 <a href="lib-algorithms.html#lib.alg.equal"> [lib.alg.equal]</a> Add the following requires clause</p>
2784
2785 <blockquote>
2786 Requires: There must be an equality operator defined that accepts type
2787 std::iterator_traits&lt;InputIterator1&gt;::reference for the left operand
2788 and std::iterator_traits&lt;InputIterator2&gt;::reference for the right operand.
2789 </blockquote>
2790
2791 <p>25.1.9 <a href="lib-algorithms.html#lib.alg.search"> [lib.alg.search]</a> Add the following requires clause</p>
2792
2793 <blockquote>
2794 Requires: There must be an equality operator defined that accepts
2795 type const std::iterator_traits&lt;ForwardIterator1&gt;::value_type for
2796 the left operand and const
2797 std::iterator_traits&lt;ForwardIterator2&gt;::value_type for the right
2798 operand.
2799 </blockquote>
2800
2801 <p>Change change p4 from</p>
2802
2803 <blockquote>
2804 Requires: Type T is EqualityComparable (20.1.1), type Size is
2805 convertible to integral type (4.7.12.3).
2806 </blockquote>
2807
2808 <p>to</p>
2809
2810 <blockquote>
2811 Requires: There must be an equality operator defined that accepts
2812 const std::iterator_traits&lt;ForwardIterator&gt;::value_type for the left
2813 operand and const T for the right operand.  The type Size is convertible to
2814 integral type (4.7.12.3).
2815 </blockquote>
2816
2817 <p>25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> Change p1 from</p>
2818
2819 <blockquote>
2820 Requires: Type T is Assignable (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>) (and, for replace(),
2821 EqualityComparable (20.1.1 <a href="lib-utilities.html#lib.equalitycomparable"> [lib.equalitycomparable]</a>)).
2822 </blockquote>
2823
2824 <p>to</p>
2825
2826 <blockquote>
2827 Requires: Type std::iterator_traits&lt;ForwardIterator&gt;::value_type
2828 is Assignable (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>) and the type const T is convertible to
2829 std::iterator_traits&lt;ForwardIterator&gt;::value_type.  For replace(), an
2830 equality operator must be defined that accepts type
2831 std::iterator_traits&lt;ForwardIterator&gt;::reference for the left operand
2832 and const T for the right operand.
2833 </blockquote>
2834
2835 <p>and change p4 from</p>
2836
2837 <blockquote>
2838 Requires: Type T is Assignable (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>) (and, for replace_copy(),
2839 EqualityComparable (20.1.1 <a href="lib-utilities.html#lib.equalitycomparable"> [lib.equalitycomparable]</a>)). The ranges [first, last) and [result,
2840 result + (last - first)) shall not overlap.
2841 </blockquote>
2842
2843 <p>to</p>
2844
2845 <blockquote>
2846 Requires: Both types const T and
2847 std::iterator_traits&lt;InputIterator&gt;::reference are writable to the
2848 OutputIterator type. For replace_copy() an equality operator must be
2849 defined that accepts type
2850 std::iterator_traits&lt;InputIterator&gt;::reference for the left operand
2851 and const T for the right operand.  The ranges [first, last) and [result,
2852 result + (last - first)) shall not overlap.
2853 </blockquote>
2854
2855 <p>25.2.5 <a href="lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a> Change p1 from</p>
2856
2857 <blockquote>
2858 Requires: Type T is Assignable (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> ). Size is convertible to an integral
2859  type (3.9.1 <a href="basic.html#basic.fundamental"> [basic.fundamental]</a> ).
2860 </blockquote>
2861
2862 <p>to</p>
2863
2864 <blockquote>
2865 Requires: Type const T is writable to the OutputIterator. Size is
2866 convertible to an integral type (3.9.1 <a href="basic.html#basic.fundamental"> [basic.fundamental]</a> ).
2867 </blockquote>
2868
2869
2870 <p>25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a> Change p1 from</p>
2871
2872 <blockquote>
2873 Requires: Type T is EqualityComparable (20.1.1 <a href="lib-utilities.html#lib.equalitycomparable"> [lib.equalitycomparable]</a>).
2874 </blockquote>
2875
2876 <p>to</p>
2877
2878 <blockquote>
2879 Requires: There must be an equality operator defined that accepts
2880 type const std::iterator_traits&lt;ForwardIterator&gt;::value_type for the left
2881 operand and const T for the right operand. The type
2882 std::iterator_traits&lt;ForwardIterator&gt;::value_type must be Assignable
2883 (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>).
2884 </blockquote>
2885
2886 <p><i>[Cura&ccedil;ao: Jeremy reports he has run the changes through his
2887 automated test tools.  At the request of the LWG, Jeremy will reword
2888 the PR in terms of valid expressions rather than &quot;equality
2889 operator&quot;.]</i></p>
2890
2891 <hr>
2892 <a name="290"><h3>290.&nbsp;Requirements to for_each and its function object</h3></a><p>
2893 <b>Section:</b>&nbsp;25.1.1 <a href="lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;03 Jan 2001</p>
2894 <p>The specification of the for_each algorithm does not have a
2895 &quot;Requires&quot; section, which means that there are no
2896 restrictions imposed on the function object whatsoever. In essence it
2897 means that I can provide any function object with arbitrary side
2898 effects and I can still expect a predictable result. In particular I
2899 can expect that the function object is applied exactly last - first
2900 times, which is promised in the &quot;Complexity&quot; section.
2901 </p>
2902
2903 <p>I don't see how any implementation can give such a guarantee
2904 without imposing requirements on the function object.
2905 </p>
2906
2907 <p>Just as an example: consider a function object that removes
2908 elements from the input sequence.  In that case, what does the
2909 complexity guarantee (applies f exactly last - first times) mean?
2910 </p>
2911
2912 <p>One can argue that this is obviously a nonsensical application and
2913 a theoretical case, which unfortunately it isn't.  I have seen
2914 programmers shooting themselves in the foot this way, and they did not
2915 understand that there are restrictions even if the description of the
2916 algorithm does not say so.
2917 </p>
2918 <p><b>Proposed resolution:</b></p>
2919 <p>Add a &quot;Requires&quot; section to section 25.1.1 similar to those
2920 proposed for transform and the numeric algorithms (see issue
2921 <a href="lwg-defects.html#242">242</a>):
2922 </p>
2923
2924 <blockquote>
2925     -2- <b>Requires</b>: In the range [first, last], f shall not invalidate
2926     iterators or subranges.
2927 </blockquote>
2928
2929 <p><i>[Copenhagen: The LWG agrees that a function object passed to an
2930 algorithm should not invalidate iterators in the range that the
2931 algorithm is operating on.  The LWG believes that this should be a
2932 blanket statement in Clause 25, not just a special requirement for
2933 <tt>for_each</tt>.
2934 ]</i></p>
2935
2936 <hr>
2937 <a name="291"><h3>291.&nbsp;Underspecification of set algorithms</h3></a><p>
2938 <b>Section:</b>&nbsp;25.3.5 <a href="lib-algorithms.html#lib.alg.set.operations"> [lib.alg.set.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;03 Jan 2001</p>
2939 <p>
2940 The standard library contains four algorithms that compute set
2941 operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
2942 <tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>.  Each
2943 of these algorithms takes two sorted ranges as inputs, and writes the
2944 output of the appropriate set operation to an output range.  The elements
2945 in the output range are sorted.
2946 </p>
2947
2948 <p>
2949 The ordinary mathematical definitions are generalized so that they
2950 apply to ranges containing multiple copies of a given element.  Two
2951 elements are considered to be &quot;the same&quot; if, according to an
2952 ordering relation provided by the user, neither one is less than the
2953 other.  So, for example, if one input range contains five copies of an
2954 element and another contains three, the output range of <tt>set_union</tt>
2955 will contain five copies, the output range of
2956 <tt>set_intersection</tt> will contain three, the output range of
2957 <tt>set_difference</tt> will contain two, and the output range of
2958 <tt>set_symmetric_difference</tt> will contain two.
2959 </p>
2960
2961 <p>
2962 Because two elements can be &quot;the same&quot; for the purposes
2963 of these set algorithms, without being identical in other respects
2964 (consider, for example, strings under case-insensitive comparison),
2965 this raises a number of unanswered questions:
2966 </p>
2967
2968 <ul>
2969 <li>If we're copying an element that's present in both of the
2970 input ranges, which one do we copy it from?</li>
2971 <li>If there are <i>n</i> copies of an element in the relevant
2972 input range, and the output range will contain fewer copies (say
2973 <i>m</i>) which ones do we choose?  The first <i>m</i>, or the last
2974 <i>m</i>, or something else?</li>
2975 <li>Are these operations stable?  That is, does a run of equivalent
2976 elements appear in the output range in the same order as as it
2977 appeared in the input range(s)?</li>
2978 </ul>
2979
2980 <p>
2981 The standard should either answer these questions, or explicitly
2982 say that the answers are unspecified.  I prefer the former option,
2983 since, as far as I know, all existing implementations behave the
2984 same way.
2985 </p>
2986
2987 <p><b>Proposed resolution:</b></p>
2988
2989 <p>Add the following to the end of 25.3.5.2 <a href="lib-algorithms.html#lib.set.union"> [lib.set.union]</a> paragraph 5:</p>
2990 <blockquote>
2991 If [first1, last1) contains <i>m</i> elements that are equivalent to
2992 each other and [first2, last2) contains <i>n</i> elements that are
2993 equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
2994 will be copied to the output range: all <i>m</i> of these elements
2995 from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
2996 [first2, last2), in that order.
2997 </blockquote>
2998
2999 <p>Add the following to the end of 25.3.5.3 <a href="lib-algorithms.html#lib.set.intersection"> [lib.set.intersection]</a> paragraph 5:</p>
3000 <blockquote>
3001 If [first1, last1) contains <i>m</i> elements that are equivalent to each
3002 other and [first2, last2) contains <i>n</i> elements that are
3003 equivalent to them, the first min(<i>m</i>, <i>n</i>) of those
3004 elements from [first1, last1) are copied to the output range.
3005 </blockquote>
3006
3007 <p>Add a new paragraph, <b>Notes</b>, after 25.3.5.4 <a href="lib-algorithms.html#lib.set.difference"> [lib.set.difference]</a>
3008 paragraph 4:</p>
3009 <blockquote>
3010 If [first1, last1) contains <i>m</i> elements that are equivalent to each
3011 other and [first2, last2) contains <i>n</i> elements that are
3012 equivalent to them, the last max(<i>m-n</i>, 0) elements from
3013 [first1, last1) are copied to the output range.
3014 </blockquote>
3015
3016 <p>Add a new paragraph, <b>Notes</b>, after 25.3.5.5 <a href="lib-algorithms.html#lib.set.symmetric.difference"> [lib.set.symmetric.difference]</a>
3017 paragraph 4:</p>
3018 <blockquote>
3019 If [first1, last1) contains <i>m</i> elements that are equivalent to
3020 each other and [first2, last2) contains <i>n</i> elements that are
3021 equivalent to them, then |<i>m - n</i>| of those elements will be
3022 copied to the output range: the last <i>m - n</i> of these elements
3023 from [first1, last1) if <i>m</i> &gt; <i>n</i>, and the last <i>n -
3024 m</i> of these elements from [first2, last2) if <i>m</i> &lt; <i>n</i>.
3025 </blockquote>
3026
3027 <p><i>[Cura&ccedil;ao: Missing Rationale and missing status comments from
3028 Redmond made discussion difficult. For union, doesn't the standard
3029 already say this? Howard, others think maybe so. Several thought the
3030 PR may be &quot;too complicated&quot;.]</i></p>
3031
3032 <hr>
3033 <a name="294"><h3>294.&nbsp;User defined macros and standard headers</h3></a><p>
3034 <b>Section:</b>&nbsp;17.4.3.1.1 <a href="lib-intro.html#lib.macro.names"> [lib.macro.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;11 Jan 2001</p>
3035 <p>Paragraph 2 of 17.4.3.1.1 <a href="lib-intro.html#lib.macro.names"> [lib.macro.names]</a> reads: &quot;A
3036 translation unit that includes a header shall not contain any macros
3037 that define names declared in that header.&quot; As I read this, it
3038 would mean that the following program is legal:</p>
3039
3040 <pre>
3041   #define npos 3.14
3042   #include &lt;sstream&gt;
3043 </pre>
3044
3045 <p>since npos is not defined in &lt;sstream&gt;.  It is, however, defined
3046 in &lt;string&gt;, and it is hard to imagine an implementation in
3047 which &lt;sstream&gt; didn't include &lt;string&gt;.</p>
3048
3049 <p>I think that this phrase was probably formulated before it was
3050 decided that a standard header may freely include other standard
3051 headers.  The phrase would be perfectly appropriate for C, for
3052 example.  In light of 17.4.4.1 <a href="lib-intro.html#lib.res.on.headers"> [lib.res.on.headers]</a> paragraph 1, however,
3053 it isn't stringent enough.</p>
3054 <p><b>Proposed resolution:</b></p>
3055 <p>In paragraph 2 of 17.4.3.1.1 <a href="lib-intro.html#lib.macro.names"> [lib.macro.names]</a>, change &quot;A
3056 translation unit that includes a header shall not contain any macros
3057 that define names declared in that header.&quot; to &quot;A
3058 translation unit that includes a header shall not contain any macros
3059 that define names declared in any standard header.&quot;</p>
3060
3061 <p><i>[Copenhagen: the general idea is clearly correct, but there is
3062 concern about making sure that the two paragraphs in 17.4.3.1.1 <a href="lib-intro.html#lib.macro.names"> [lib.macro.names]</a> remain consistent.  Nathan will provide new
3063 wording.]</i></p>
3064
3065 <hr>
3066 <a name="299"><h3>299.&nbsp;Incorrect return types for iterator dereference</h3></a><p>
3067 <b>Section:</b>&nbsp;24.1.4 <a href="lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, 24.1.5 <a href="lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;John Potter&nbsp; <b>Date:</b>&nbsp;22 Jan 2001</p>
3068 <p>
3069 In section 24.1.4 <a href="lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>,
3070 Table 75 gives the return type of *r-- as convertible to T.  This is
3071 not consistent with Table 74 which gives the return type of *r++ as
3072 T&amp;.  *r++ = t is valid while *r-- = t is invalid.
3073 </p>
3074
3075 <p>
3076 In section 24.1.5 <a href="lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>,
3077 Table 76 gives the return type of a[n] as convertible to T.  This is
3078 not consistent with the semantics of *(a + n) which returns T&amp; by
3079 Table 74.  *(a + n) = t is valid while a[n] = t is invalid.
3080 </p>
3081
3082 <p>
3083 Discussion from the Copenhagen meeting: the first part is
3084 uncontroversial.  The second part, operator[] for Random Access
3085 Iterators, requires more thought.  There are reasonable arguments on
3086 both sides.  Return by value from operator[] enables some potentially
3087 useful iterators, e.g. a random access &quot;iota iterator&quot; (a.k.a
3088 &quot;counting iterator&quot; or &quot;int iterator&quot;).  There isn't any obvious way
3089 to do this with return-by-reference, since the reference would be to a
3090 temporary.  On the other hand, <tt>reverse_iterator</tt> takes an
3091 arbitrary Random Access Iterator as template argument, and its
3092 operator[] returns by reference.  If we decided that the return type
3093 in Table 76 was correct, we would have to change
3094 <tt>reverse_iterator</tt>.  This change would probably affect user
3095 code.
3096 </p>
3097
3098 <p>
3099 History: the contradiction between <tt>reverse_iterator</tt> and the
3100 Random Access Iterator requirements has been present from an early
3101 stage.  In both the STL proposal adopted by the committee
3102 (N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
3103 Stepanov and Lee), the Random Access Iterator requirements say that
3104 operator[]'s return value is &quot;convertible to T&quot;.  In N0527
3105 reverse_iterator's operator[] returns by value, but in HPL-95-11
3106 (R.1), and in the STL implementation that HP released to the public,
3107 reverse_iterator's operator[] returns by reference.  In 1995, the
3108 standard was amended to reflect the contents of HPL-95-11 (R.1).  The
3109 original intent for operator[] is unclear.
3110 </p>
3111
3112 <p>
3113 In the long term it may be desirable to add more fine-grained
3114 iterator requirements, so that access method and traversal strategy
3115 can be decoupled.  (See &quot;Improved Iterator Categories and
3116 Requirements&quot;, N1297 = 01-0011, by Jeremy Siek.)  Any decisions
3117 about issue 299 should keep this possibility in mind.
3118 </p>
3119
3120 <p><b>Proposed resolution:</b></p>
3121 <p>In section 24.1.4 <a href="lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, change the return type in table
3122 75 from &quot;convertible to T&quot; to T&amp;.</p>
3123
3124 <p>In section 24.1.5 <a href="lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>, change the return type in table
3125 76 from &quot;convertible to T&quot; to T&amp;.</p>
3126
3127 <p><i>[Cura&ccedil;ao: Jeremy volunteered to work on this issue.]</i></p>
3128
3129 <hr>
3130 <a name="300"><h3>300.&nbsp;list::merge() specification incomplete</h3></a><p>
3131 <b>Section:</b>&nbsp;23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;John Pedretti&nbsp; <b>Date:</b>&nbsp;23 Jan 2001</p>
3132 <p>
3133 The &quot;Effects&quot; clause for list::merge() (23.2.2.4, p23)
3134 appears to be incomplete: it doesn't cover the case where the argument
3135 list is identical to *this (i.e., this == &amp;x). The requirement in the
3136 note in p24 (below) is that x be empty after the merge which is surely
3137 unintended in this case.
3138 </p>
3139 <p><b>Proposed resolution:</b></p>
3140 <p>In 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraps 23-25 with:</p>
3141 <blockquote>
3142 <p>
3143 23 Effects: if (&amp;x == this) does nothing; otherwise, merges the two
3144 sorted ranges [begin(), end()) and [x.begin(), x.end()).  The result
3145 is a range in which the elements will be sorted in non-decreasing
3146 order according to the ordering defined by comp; that is, for every
3147 iterator i in the range other than the first, the condition comp(*i,
3148 *(i - 1)) will be false.
3149 </p>
3150
3151 <p>
3152 24 Notes: Stable: if (&amp;x != this), then for equivalent elements in the
3153 two original ranges, the elements from the original range [begin(),
3154 end()) always precede the elements from the original range [x.begin(),
3155 x.end()).  If (&amp;x != this) the range [x.begin(), x.end()) is empty
3156 after the merge.
3157 </p>
3158
3159 <p>
3160 25 Complexity: At most size() + x.size() - 1 applications of comp if
3161 (&amp;x !  = this); otherwise, no applications of comp are performed.  If
3162 an exception is thrown other than by a comparison there are no
3163 effects.
3164 </p>
3165
3166 </blockquote>
3167
3168 <p><i>[Copenhagen: The original proposed resolution did not fix all of
3169 the problems in 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, p22-25.  Three different
3170 paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
3171 Changing p23, without changing the other two, appears to introduce
3172 contradictions.  Additionally, &quot;merges the argument list into the
3173 list&quot; is excessively vague.]</i></p>
3174
3175 <p><i>[Post-Cura&ccedil;ao: Robert Klarer provided new wording.]</i></p>
3176
3177 <hr>
3178 <a name="304"><h3>304.&nbsp;Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</h3></a><p>
3179 <b>Section:</b>&nbsp;24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;5 Feb 2001</p>
3180 <p>
3181 We all &quot;know&quot; that input iterators are allowed to produce
3182 values when dereferenced of which there is no other in-memory copy.
3183 </p>
3184
3185 <p>
3186 But: Table 72, with a careful reading, seems to imply that this can only be
3187 the case if the value_type has no members (e.g. is a built-in type).
3188 </p>
3189
3190 <p>The problem occurs in the following entry:</p>
3191
3192 <pre>
3193   a-&gt;m     pre: (*a).m is well-defined
3194            Equivalent to (*a).m
3195 </pre>
3196
3197 <p>
3198 <tt>*a.m</tt> can be well-defined if <tt>*a</tt> is not a reference
3199 type, but since <tt>operator-&gt;()</tt> must return a pointer for
3200 <tt>a-&gt;m</tt> to be well-formed, it needs something to return a
3201 pointer <i>to</i>. This seems to indicate that <tt>*a</tt> must be
3202 buffered somewhere to make a legal input iterator.
3203 </p>
3204
3205 <p>I don't think this was intentional.</p>
3206 <p><b>Proposed resolution:</b></p>
3207 <p><i>[Copenhagen: the two obvious possibilities are to keep the
3208 <tt>operator-&gt;</tt> requirement for Input Iterators, and put
3209 in a non-normative note describing how it can be implemented with
3210 proxies, or else moving the <tt>operator-&gt;</tt> requirement
3211 from Input Iterator to Forward Iterator.  If we do the former
3212 we'll also have to change <tt>istreambuf_iterator</tt>, because
3213 it has no <tt>operator-&gt;</tt>.  A straw poll showed roughly equal
3214 support for the two options.]</i></p>
3215 <hr>
3216 <a name="305"><h3>305.&nbsp;Default behavior of codecvt&lt;wchar_t, char, mbstate_t&gt;::length()</h3></a><p>
3217 <b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;24 Jan 2001</p>
3218 <p>22.2.1.5/3 introduces codecvt in part with:</p>
3219
3220 <blockquote>
3221   codecvt&lt;wchar_t,char,mbstate_t&gt; converts between the native
3222   character sets for tiny and wide characters. Instantiations on
3223   mbstate_t perform conversion between encodings known to the library
3224   implementor.
3225 </blockquote>
3226
3227 <p>But 22.2.1.5.2/10 describes do_length in part with:</p>
3228
3229 <blockquote>
3230   ... codecvt&lt;wchar_t, char, mbstate_t&gt; ... return(s) the lesser of max and
3231   (from_end-from).
3232 </blockquote>
3233
3234 <p>
3235 The semantics of do_in and do_length are linked.  What one does must
3236 be consistent with what the other does.  22.2.1.5/3 leads me to
3237 believe that the vendor is allowed to choose the algorithm that
3238 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in performs so that it makes
3239 his customers happy on a given platform.  But 22.2.1.5.2/10 explicitly
3240 says what codecvt&lt;wchar_t,char,mbstate_t&gt;::do_length must
3241 return.  And thus indirectly specifies the algorithm that
3242 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in must perform.  I believe
3243 that this is not what was intended and is a defect.
3244 </p>
3245
3246 <p>Discussion from the -lib reflector:
3247
3248 <br>This proposal would have the effect of making the semantics of
3249 all of the virtual functions in <tt>codecvt&lt;wchar_t, char,
3250 mbstate_t&gt;</tt> implementation specified.  Is that what we want, or
3251 do we want to mandate specific behavior for the base class virtuals
3252 and leave the implementation specified behavior for the codecvt_byname
3253 derived class?  The tradeoff is that former allows implementors to
3254 write a base class that actually does something useful, while the
3255 latter gives users a way to get known and specified---albeit
3256 useless---behavior, and is consistent with the way the standard
3257 handles other facets.  It is not clear what the original intention
3258 was.</p>
3259
3260 <p>
3261 Nathan has suggest a compromise: a character that is a widened version
3262 of the characters in the basic execution character set must be
3263 converted to a one-byte sequence, but there is no such requirement
3264 for characters that are not part of the basic execution character set.
3265 </p>
3266 <p><b>Proposed resolution:</b></p>
3267 <p>
3268 Change 22.2.1.5.2/5 from:
3269 </p>
3270 <p>
3271 The instantiations required in Table 51 (lib.locale.category), namely
3272 codecvt&lt;wchar_t,char,mbstate_t&gt; and
3273 codecvt&lt;char,char,mbstate_t&gt;, store no characters. Stores no more
3274 than (to_limit-to) destination elements. It always leaves the to_next
3275 pointer pointing one beyond the last element successfully stored.
3276 </p>
3277 <p>
3278 to:
3279 </p>
3280 <p>
3281 Stores no more than (to_limit-to) destination elements, and leaves the
3282 to_next pointer pointing one beyond the last element successfully
3283 stored.  codecvt&lt;char,char,mbstate_t&gt; stores no characters.
3284 </p>
3285
3286 <p>Change 22.2.1.5.2/10 from:</p>
3287
3288 <blockquote>
3289 -10- Returns: (from_next-from) where from_next is the largest value in
3290 the range [from,from_end] such that the sequence of values in the
3291 range [from,from_next) represents max or fewer valid complete
3292 characters of type internT. The instantiations required in Table 51
3293 (21.1.1.1.1), namely codecvt&lt;wchar_t, char, mbstate_t&gt; and
3294 codecvt&lt;char, char, mbstate_t&gt;, return the lesser of max and
3295 (from_end-from).
3296 </blockquote>
3297
3298 <p>to:</p>
3299
3300 <blockquote>
3301 -10- Returns: (from_next-from) where from_next is the largest value in
3302 the range [from,from_end] such that the sequence of values in the range
3303 [from,from_next) represents max or fewer valid complete characters of
3304 type internT. The instantiation codecvt&lt;char, char, mbstate_t&gt; returns
3305 the lesser of max and (from_end-from).
3306 </blockquote>
3307
3308 <p><i>[Redmond: Nathan suggested an alternative resolution: same as
3309 above, but require that, in the default encoding, a character from the
3310 basic execution character set would map to a single external
3311 character.  The straw poll was 8-1 in favor of the proposed
3312 resolution.]</i></p>
3313
3314 <p><b>Rationale:</b></p>
3315 <p>The default encoding should be whatever users of a given platform
3316 would expect to be the most natural.  This varies from platform to
3317 platform.  In many cases there is a preexisting C library, and users
3318 would expect the default encoding to be whatever C uses in the default
3319 &quot;C&quot; locale.  We could impose a guarantee like the one Nathan suggested
3320 (a character from the basic execution character set must map to a
3321 single external character), but this would rule out important
3322 encodings that are in common use: it would rule out JIS, for
3323 example, and it would rule out a fixed-width encoding of UCS-4.</p>
3324
3325 <p><i>[Cura&ccedil;ao: fixed rationale typo at the request of Ichiro Koshida;
3326 &quot;shift-JIS&quot; changed to &quot;JIS&quot;.]</i></p>
3327
3328 <hr>
3329 <a name="309"><h3>309.&nbsp;Does sentry catch exceptions?</h3></a><p>
3330 <b>Section:</b>&nbsp;27.6 <a href="lib-iostreams.html#lib.iostream.format"> [lib.iostream.format]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;19 Mar 2001</p>
3331 <p>
3332 The descriptions of the constructors of basic_istream&lt;&gt;::sentry
3333 (27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>) and basic_ostream&lt;&gt;::sentry
3334 (27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>) do not explain what the functions do in
3335 case an exception is thrown while they execute. Some current
3336 implementations allow all exceptions to propagate, others catch them
3337 and set ios_base::badbit instead, still others catch some but let
3338 others propagate.
3339 </p>
3340
3341 <p>
3342 The text also mentions that the functions may call setstate(failbit)
3343 (without actually saying on what object, but presumably the stream
3344 argument is meant).  That may have been fine for
3345 basic_istream&lt;&gt;::sentry prior to issue <a href="lwg-defects.html#195">195</a>, since
3346 the function performs an input operation which may fail. However,
3347 issue <a href="lwg-defects.html#195">195</a> amends 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>, p2 to
3348 clarify that the function should actually call setstate(failbit |
3349 eofbit), so the sentence in p3 is redundant or even somewhat
3350 contradictory.
3351 </p>
3352
3353 <p>
3354 The same sentence that appears in 27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>, p3
3355 doesn't seem to be very meaningful for basic_istream&lt;&gt;::sentry
3356 which performs no input. It is actually rather misleading since it
3357 would appear to guide library implementers to calling
3358 setstate(failbit) when os.tie()-&gt;flush(), the only called function,
3359 throws an exception (typically, it's badbit that's set in response to
3360 such an event).
3361 </p>
3362 <p><b>Proposed resolution:</b></p>
3363 <p>Add the following paragraph immediately after
3364 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>, p5</p>
3365
3366 <blockquote>
3367     <p>
3368     If an exception is thrown during the preparation then ios::badbit
3369     is turned on* in is's error state.
3370     </p>
3371
3372     <p>
3373     [Footnote: This is done without causing an ios::failure to be thrown.
3374     --- end footnote]
3375     </p>
3376
3377     <p>
3378     If (is.exceptions() &amp; ios_base::badbit)!= 0 then the exception is
3379     rethrown.
3380     </p>
3381 </blockquote>
3382
3383 <p>And strike the following sentence from 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>, p5</p>
3384
3385 <blockquote>
3386     During preparation, the constructor may call setstate(failbit)
3387     (which may throw ios_base::failure (lib.iostate.flags))
3388 </blockquote>
3389
3390 <p>Add the following paragraph immediately after
3391 27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>, p3</p>
3392
3393 <blockquote>
3394     <p>
3395     If an exception is thrown during the preparation then ios::badbit
3396     is turned on* in os's error state.
3397     </p>
3398
3399     <p>
3400     [Footnote: This is done without causing an ios::failure to be
3401     thrown.  --- end footnote]
3402     </p>
3403
3404     <p>
3405     If (os.exceptions() &amp; ios_base::badbit)!= 0 then the exception
3406     is rethrown.
3407     </p>
3408 </blockquote>
3409
3410 <p>And strike the following sentence from 27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>, p3</p>
3411
3412 <blockquote>
3413     During preparation, the constructor may call setstate(failbit)
3414     (which may throw ios_base::failure (lib.iostate.flags))
3415 </blockquote>
3416
3417 <p>(Note that the removal of the two sentences means that the ctors
3418 will not be able to report the failure of any implementation-dependent
3419 operations referred to in footnotes 280 and 293, unless such
3420 operations throw an exception.)</p>
3421
3422 <p><i>[
3423 Copenhagen: It was agreed that there was an issue here, but there was
3424 disagreement about the resolution.  Some LWG members argued that a
3425 sentry's constructor should not catch exceptions, because sentries
3426 should only be used within (un)formatted input functions and that
3427 exception handling is the responsibility of those functions, not of
3428 the sentries.
3429 ]</i></p>
3430
3431 <hr>
3432 <a name="320"><h3>320.&nbsp;list::assign overspecified</h3></a><p>
3433 <b>Section:</b>&nbsp;23.2.2.1 <a href="lib-containers.html#lib.list.cons"> [lib.list.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
3434 <p>
3435 Section 23.2.2.1, paragraphs 6-8 specify that list assign (both forms) have
3436 the &quot;effects&quot; of a call to erase followed by a call to insert.
3437 </p>
3438
3439 <p>
3440 I would like to document that implementers have the freedom to implement
3441 assign by other methods, as long as the end result is the same and the
3442 exception guarantee is as good or better than the basic guarantee.
3443 </p>
3444
3445 <p>
3446 The motivation for this is to use T's assignment operator to recycle
3447 existing nodes in the list instead of erasing them and reallocating
3448 them with new values.  It is also worth noting that, with careful
3449 coding, most common cases of assign (everything but assignment with
3450 true input iterators) can elevate the exception safety to strong if
3451 T's assignment has a nothrow guarantee (with no extra memory cost).
3452 Metrowerks does this.  However I do not propose that this subtlety be
3453 standardized.  It is a QoI issue.  </p>
3454
3455 <p>Existing practise:
3456 Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
3457 </p>
3458 <p><b>Proposed resolution:</b></p>
3459 <p>Change 23.2.2.1/7 from:</p>
3460
3461 <blockquote>
3462 <p>Effects:</p>
3463
3464 <pre>
3465    erase(begin(), end());
3466    insert(begin(), first, last);
3467 </pre>
3468 </blockquote>
3469
3470 <p>to:</p>
3471
3472 <blockquote>
3473 <p>Effects: Replaces the contents of the list with the range [first, last).</p>
3474 </blockquote>
3475
3476 <p>In 23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>, in Table 67 (sequence requirements),
3477 add two new rows:</p>
3478 <pre>
3479       a.assign(i,j)     void      pre: i,j are not iterators into a.
3480                                   Replaces elements in a with a copy
3481                                   of [i, j).
3482
3483       a.assign(n,t)     void      pre: t is not a reference into a.
3484                                   Replaces elements in a with n copies
3485                                   of t.
3486 </pre>
3487
3488 <p>Change 23.2.2.1/8 from:</p>
3489
3490 <blockquote>
3491 <p>Effects:</p>
3492 <pre>
3493    erase(begin(), end());
3494    insert(begin(), n, t);
3495 </pre>
3496 </blockquote>
3497 <p>to:</p>
3498
3499 <blockquote>
3500 <p>Effects: Replaces the contents of the list with n copies of t.</p>
3501 </blockquote>
3502
3503 <p><i>[Redmond: Proposed resolution was changed slightly.  Previous
3504 version made explicit statement about exception safety, which wasn't
3505 consistent with the way exception safety is expressed elsewhere.
3506 Also, the change in the sequence requirements is new.  Without that
3507 change, the proposed resolution would have required that assignment of
3508 a subrange would have to work.  That too would have been
3509 overspecification; it would effectively mandate that assignment use a
3510 temporary.  Howard provided wording.
3511 ]</i></p>
3512
3513 <p><i>[Cura&ccedil;ao: Made editorial improvement in wording; changed
3514 &quot;Replaces elements in a with copies of elements in [i, j).&quot;
3515 with &quot;Replaces the elements of a with a copy of [i, j).&quot;
3516 Changes not deemed serious enough to requre rereview.]</i></p>
3517
3518 <hr>
3519 <a name="323"><h3>323.&nbsp;abs() overloads in different headers</h3></a><p>
3520 <b>Section:</b>&nbsp;26.5 <a href="lib-numerics.html#lib.c.math"> [lib.c.math]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;4 June 2001</p>
3521 <p>Currently the standard mandates the following overloads of
3522 abs():</p>
3523
3524 <pre>
3525     abs(long), abs(int) in &lt;cstdlib&gt;
3526
3527     abs(float), abs(double), abs(long double) in &lt;cmath&gt;
3528
3529     template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp;) in &lt;complex&gt;
3530
3531     template&lt;class T&gt; valarray&lt;T&gt; abs(const valarray&lt;T&gt;&amp;); in &lt;valarray&gt;
3532 </pre>
3533
3534 <p>
3535 The problem is that having only some overloads visible of a function
3536 that works on &quot;implicitly inter-convertible&quot; types is dangerous in
3537 practice. The headers that get included at any point in a translation
3538 unit can change unpredictably during program
3539 development/maintenance. The wrong overload might be unintentionally
3540 selected.
3541 </p>
3542
3543 <p>
3544 Currently, there is nothing that mandates the simultaneous visibility
3545 of these overloads. Indeed, some vendors have begun fastidiously
3546 reducing dependencies among their (public) headers as a QOI issue: it
3547 helps people to write portable code by refusing to compile unless all
3548 the correct headers are #included.
3549 </p>
3550
3551 <p>The same issue may exist for other functions in the library.</p>
3552
3553 <p>Redmond: PJP reports that C99 adds two new kinds of abs: comples,
3554 and int_max_abs.</p>
3555
3556 <p>Related issue: <a href="lwg-closed.html#343">343</a>.</p>
3557
3558 <p><b>Proposed resolution:</b></p>
3559
3560 <p><i>[Redmond: General agreement that the current situation is
3561 somewhat fragile.  No consensus on whether it's more fragile than any
3562 number of other things, or whether there's any good way to fix it.
3563 Walter suggests that <tt>abs</tt> should be defined for all built-in
3564 types in both &lt;cmath&gt; and &lt;cstdlib&gt;, but that no effort
3565 should be made to put all overloads for class types in one place.
3566 Beman suggests closing this issue as &quot;NAD Future&quot;, and adding a
3567 &lt;all&gt; header as an extension.  The &lt;all&gt; header would
3568 solve a more general problem: users who can't remember which names are
3569 defined in which headers. (See issue <a href="lwg-closed.html#343">343</a>)]</i></p>
3570
3571 <hr>
3572 <a name="324"><h3>324.&nbsp;Do output iterators have value types?</h3></a><p>
3573 <b>Section:</b>&nbsp;24.1.2 <a href="lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;7 June 2001</p>
3574
3575 <p>Table 73 suggests that output iterators have value types.  It
3576 requires the expression &quot;*a = t&quot;.  Additionally, although Table 73
3577 never lists &quot;a = t&quot; or &quot;X(a) = t&quot; in the &quot;expressions&quot; column, it
3578 contains a note saying that &quot;a = t&quot; and &quot;X(a) = t&quot; have equivalent
3579 (but nowhere specified!) semantics.</p>
3580
3581 <p>According to 24.1/9, t is supposed to be &quot;a value of value type
3582 T&quot;:</p>
3583
3584     <blockquote>
3585     In the following sections, a and b denote values of X, n denotes a
3586     value of the difference type Distance, u, tmp, and m denote
3587     identifiers, r denotes a value of X&amp;, t denotes a value of
3588     value type T.
3589     </blockquote>
3590
3591 <p>Two other parts of the standard that are relevant to whether
3592 output iterators have value types:</p>
3593
3594 <ul>
3595     <li>24.1/1 says &quot;All iterators i support the expression *i,
3596     resulting in a value of some class, enumeration, or built-in type
3597     T, called the value type of the iterator&quot;.</li>
3598
3599     <li>
3600     24.3.1/1, which says &quot;In the case of an output iterator, the types
3601     iterator_traits&lt;Iterator&gt;::difference_type
3602     iterator_traits&lt;Iterator&gt;::value_type are both defined as void.&quot;
3603     </li>
3604 </ul>
3605
3606 <p>The first of these passages suggests that &quot;*i&quot; is supposed to
3607 return a useful value, which contradicts the note in 24.1.2/2 saying
3608 that the only valid use of &quot;*i&quot; for output iterators is in an
3609 expression of the form &quot;*i = t&quot;.  The second of these passages appears
3610 to contradict Table 73, because it suggests that &quot;*i&quot;'s return value
3611 should be void.  The second passage is also broken in the case of a an
3612 iterator type, like non-const pointers, that satisfies both the output
3613 iterator requirements and the forward iterator requirements.</p>
3614
3615 <p>What should the standard say about <tt>*i</tt>'s return value when
3616 i is an output iterator, and what should it say about that t is in the
3617 expression &quot;*i = t&quot;?  Finally, should the standard say anything about
3618 output iterators' pointer and reference types?</p>
3619
3620 <p><b>Proposed resolution:</b></p>
3621 <p>24.1 p1, change</p>
3622
3623 <blockquote>
3624 <p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
3625 in a value of some class, enumeration, or built-in type <tt>T</tt>,
3626 called the value type of the iterator.</p>
3627 </blockquote>
3628
3629 <p>to</p>
3630
3631 <blockquote>
3632 <p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
3633 resulting in a value of some class, enumeration, or built-in type
3634 <tt>T</tt>, called the value type of the iterator. All output
3635 iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
3636 value of some type that is in the set of types that are <i>writable</i> to
3637 the particular iterator type of <tt>i</tt>.
3638 </p>
3639 </blockquote>
3640
3641 <p>24.1 p9, add</p>
3642
3643 <blockquote>
3644 <p>
3645 <tt>o</tt> denotes a value of some type that is writable to the
3646 output iterator.
3647 </p>
3648 </blockquote>
3649
3650 <p>Table 73, change</p>
3651
3652 <blockquote>
3653 <pre>
3654 *a = t
3655 </pre>
3656 </blockquote>
3657
3658 <p>to</p>
3659
3660 <blockquote>
3661 <pre>
3662 *r = o
3663 </pre>
3664 </blockquote>
3665
3666 <p>and change</p>
3667
3668 <blockquote>
3669 <pre>
3670 *r++ = t
3671 </pre>
3672 </blockquote>
3673
3674 <p>to</p>
3675
3676 <blockquote>
3677 <pre>
3678 *r++ = o
3679 </pre>
3680 </blockquote>
3681
3682 <p><i>[post-Redmond: Jeremy provided wording]</i></p>
3683
3684 <p><b>Rationale:</b></p>
3685 <p>The LWG considered two options: change all of the language that
3686 seems to imply that output iterators have value types, thus making it
3687 clear that output iterators have no value types, or else define value
3688 types for output iterator consistently.  The LWG chose the former
3689 option, because it seems clear that output iterators were never
3690 intended to have value types.  This was a deliberate design decision,
3691 and any language suggesting otherwise is simply a mistake.</p>
3692
3693 <p>A future revision of the standard may wish to revisit this design
3694 decision.</p>
3695 <hr>
3696 <a name="325"><h3>325.&nbsp;Misleading text in moneypunct&lt;&gt;::do_grouping</h3></a><p>
3697 <b>Section:</b>&nbsp;22.2.6.3.2 <a href="lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Jul 2001</p>
3698 <p>The Returns clause in 22.2.6.3.2, p3 says about
3699 moneypunct&lt;charT&gt;::do_grouping()
3700 </p>
3701
3702 <blockquote>
3703     Returns: A pattern defined identically as the result of
3704     numpunct&lt;charT&gt;::do_grouping().241)
3705 </blockquote>
3706
3707 <p>Footnote 241 then reads</p>
3708
3709 <blockquote>
3710     This is most commonly the value &quot;\003&quot; (not &quot;3&quot;).
3711 </blockquote>
3712
3713 <p>
3714 The returns clause seems to imply that the two member functions must
3715 return an identical value which in reality may or may not be true,
3716 since the facets are usually implemented in terms of struct std::lconv
3717 and return the value of the grouping and mon_grouping, respectively.
3718 The footnote also implies that the member function of the moneypunct
3719 facet (rather than the overridden virtual functions in moneypunct_byname)
3720 most commonly return &quot;\003&quot;, which contradicts the C standard which
3721 specifies the value of &quot;&quot; for the (most common) C locale.
3722 </p>
3723
3724 <p><b>Proposed resolution:</b></p>
3725 <p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>
3726
3727 <blockquote>
3728     Returns: A pattern defined identically as, but not necessarily
3729     equal to, the result of numpunct&lt;charT&gt;::do_grouping().241)
3730 </blockquote>
3731
3732 <p>and replace the text in Footnote 241 with the following:</p>
3733
3734 <blockquote>
3735     To specify grouping by 3s the value is &quot;\003&quot;, not &quot;3&quot;.
3736 </blockquote>
3737 <p><b>Rationale:</b></p>
3738 <p>
3739 The fundamental problem is that the description of the locale facet
3740 virtuals serves two purposes: describing the behavior of the base
3741 class, and describing the meaning of and constraints on the behavior
3742 in arbitrary derived classes.  The new wording makes that separation a
3743 little bit clearer.  The footnote (which is nonnormative) is not
3744 supposed to say what the grouping is in the &quot;C&quot; locale or in any other
3745 locale. It is just a reminder that the values are interpreted as small
3746 integers, not ASCII characters.
3747 </p>
3748 <hr>
3749 <a name="329"><h3>329.&nbsp;vector capacity, reserve and reallocation</h3></a><p>
3750 <b>Section:</b>&nbsp;23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>, 23.2.4.3 <a href="lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;13 Jul 2001</p>
3751 <p>
3752 There is an apparent contradiction about which circumstances can cause
3753 a reallocation of a vector in Section 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> and
3754 section 23.2.4.3 <a href="lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>.
3755 </p>
3756
3757 <p>23.2.4.2p5 says:</p>
3758 <blockquote>
3759 Notes: Reallocation invalidates all the references, pointers, and iterators
3760 referring to the elements in the sequence. It is guaranteed that no
3761 reallocation takes place during insertions that happen after a call to
3762 reserve() until the time when an insertion would make the size of the vector
3763 greater than the size specified in the most recent call to reserve().
3764 </blockquote>
3765
3766 <p>Which implies if I do</p>
3767
3768 <pre>
3769   std::vector&lt;int&gt; vec;
3770   vec.reserve(23);
3771   vec.reserve(0);
3772   vec.insert(vec.end(),1);
3773 </pre>
3774
3775 <p>then the implementation may reallocate the vector for the insert,
3776 as the size specified in the previous call to reserve was zero.</p>
3777
3778 <p>However, the previous paragraphs (23.2.4.2, p1-2) state:</p>
3779 <blockquote>
3780 <p>
3781 (capacity) Returns: The total number of elements the vector
3782 can hold without requiring reallocation
3783 </p>
3784 <p>
3785 ...After reserve(), capacity() is greater or equal to the
3786 argument of reserve if reallocation happens; and equal to the previous value
3787 of capacity() otherwise...
3788 </p>
3789 </blockquote>
3790
3791 <p>
3792 This implies that vec.capacity() is still 23, and so the insert()
3793 should not require a reallocation, as vec.size() is 0. This is backed
3794 up by 23.2.4.3p1:
3795 </p>
3796 <blockquote>
3797 (insert) Notes: Causes reallocation if the new size is greater than the old
3798 capacity.
3799 </blockquote>
3800
3801 <p>
3802 Though this doesn't rule out reallocation if the new size is less
3803 than the old capacity, I think the intent is clear.
3804 </p>
3805
3806 <p><b>Proposed resolution:</b></p>
3807 <p>Change the wording of 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> paragraph 5 to:</p>
3808
3809 <blockquote>
3810 Notes: Reallocation invalidates all the references, pointers, and
3811 iterators referring to the elements in the sequence. It is guaranteed
3812 that no reallocation takes place during insertions that happen after a
3813 call to reserve() until the time when an insertion would make the size
3814 of the vector greater than the value of capacity().
3815 </blockquote>
3816
3817 <p><i>[Redmond: original proposed resolution was modified slightly.  In
3818 the original, the guarantee was that there would be no reallocation
3819 until the size would be greater than the value of capacity() after the
3820 most recent call to reserve().  The LWG did not believe that the
3821 &quot;after the most recent call to reserve()&quot; added any useful
3822 information.]</i></p>
3823
3824 <p><b>Rationale:</b></p>
3825 <p>There was general agreement that, when reserve() is called twice in
3826 succession and the argument to the second invocation is smaller than
3827 the argument to the first, the intent was for the second invocation to
3828 have no effect.  Wording implying that such cases have an effect on
3829 reallocation guarantees was inadvertant.</p>
3830 <hr>
3831 <a name="333"><h3>333.&nbsp;does endl imply synchronization with the device?</h3></a><p>
3832 <b>Section:</b>&nbsp;27.6.2.7 <a href="lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;PremAnand M. Rao&nbsp; <b>Date:</b>&nbsp;27 Aug 2001</p>
3833 <p>A footnote in 27.6.2.7 <a href="lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a> states:</p>
3834 <blockquote>
3835     [Footnote: The effect of executing cout &lt;&lt; endl is to insert a
3836      newline character in the output sequence controlled by cout, then
3837      synchronize it with any external file with which it might be
3838      associated. --- end foonote]
3839 </blockquote>
3840
3841 <p>
3842 Does the term &quot;file&quot; here refer to the external device?
3843 This leads to some implementation ambiguity on systems with fully
3844 buffered files where a newline does not cause a flush to the device.
3845 </p>
3846
3847 <p>
3848 Choosing to sync with the device leads to significant performance
3849 penalties for each call to endl, while not sync-ing leads to
3850 errors under special circumstances.
3851 </p>
3852
3853 <p>
3854 I could not find any other statement that explicitly defined
3855 the behavior one way or the other.
3856 </p>
3857 <p><b>Proposed resolution:</b></p>
3858 <p>Remove footnote 300 from section 27.6.2.7 <a href="lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a>.</p>
3859 <p><b>Rationale:</b></p>
3860 <p>We already have normative text saying what <tt>endl</tt> does: it
3861 inserts a newline character and calls <tt>flush</tt>.  This footnote
3862 is at best redundant, at worst (as this issue says) misleading,
3863 because it appears to make promises about what <tt>flush</tt>
3864 does.</p>
3865 <hr>
3866 <a name="334"><h3>334.&nbsp;map::operator[] specification forces inefficient implementation</h3></a><p>
3867 <b>Section:</b>&nbsp;23.3.1.2 <a href="lib-containers.html#lib.map.access"> [lib.map.access]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Andrea Griffini&nbsp; <b>Date:</b>&nbsp;02 Sep 2001</p>
3868 <p>
3869 The current standard describes map::operator[] using a
3870 code example. That code example is however quite
3871 inefficient because it requires several useless copies
3872 of both the passed key_type value and of default
3873 constructed mapped_type instances.
3874 My opinion is that was not meant by the comitee to
3875 require all those temporary copies.
3876 </p>
3877
3878 <p>Currently map::operator[] behaviour is specified as: </p>
3879 <pre>
3880   Returns:
3881     (*((insert(make_pair(x, T()))).first)).second.
3882 </pre>
3883
3884 <p>
3885 This specification however uses make_pair that is a
3886 template function of which parameters in this case
3887 will be deduced being of type const key_type&amp; and
3888 const T&amp;. This will create a pair&lt;key_type,T&gt; that
3889 isn't the correct type expected by map::insert so
3890 another copy will be required using the template
3891 conversion constructor available in pair to build
3892 the required pair&lt;const key_type,T&gt; instance.
3893 </p>
3894
3895 <p>If we consider calling of key_type copy constructor
3896 and mapped_type default constructor and copy
3897 constructor as observable behaviour (as I think we
3898 should) then the standard is in this place requiring
3899 two copies of a key_type element plus a default
3900 construction and two copy construction of a mapped_type
3901 (supposing the addressed element is already present
3902 in the map; otherwise at least another copy
3903 construction for each type).
3904 </p>
3905
3906 <p>A simple (half) solution would be replacing the description with:</p>
3907 <pre>
3908   Returns:
3909     (*((insert(value_type(x, T()))).first)).second.
3910 </pre>
3911
3912 <p>This will remove the wrong typed pair construction that
3913 requires one extra copy of both key and value.</p>
3914
3915 <p>However still the using of map::insert requires temporary
3916 objects while the operation, from a logical point of view,
3917 doesn't require any. </p>
3918
3919 <p>I think that a better solution would be leaving free an
3920 implementer to use a different approach than map::insert
3921 that, because of its interface, forces default constructed
3922 temporaries and copies in this case.
3923 The best solution in my opinion would be just requiring
3924 map::operator[] to return a reference to the mapped_type
3925 part of the contained element creating a default element
3926 with the specified key if no such an element is already
3927 present in the container. Also a logarithmic complexity
3928 requirement should be specified for the operation.
3929 </p>
3930
3931 <p>
3932 This would allow library implementers to write alternative
3933 implementations not using map::insert and reaching optimal
3934 performance in both cases of the addressed element being
3935 present or absent from the map (no temporaries at all and
3936 just the creation of a new pair inside the container if
3937 the element isn't present).
3938 Some implementer has already taken this option but I think
3939 that the current wording of the standard rules that as
3940 non-conforming.
3941 </p>
3942
3943 <p><b>Proposed resolution:</b></p>
3944
3945 <p>
3946 Replace 23.3.1.2 <a href="lib-containers.html#lib.map.access"> [lib.map.access]</a> paragraph 1 with
3947 </p>
3948 <blockquote>
3949 <p>
3950 -1- Effects:  If there is no key equivalent to x in the map, inserts
3951 value_type(x, T()) into the map.
3952 </p>
3953 <p>
3954 -2- Returns: A reference to the mapped_type corresponding to x in *this.
3955 </p>
3956 <p>
3957 -3- Complexity: logarithmic.
3958 </p>
3959 </blockquote>
3960
3961 <p><i>[This is the second option mentioned above.  Howard provided
3962 wording.  We may also wish to have a blanket statement somewhere in
3963 clause 17 saying that we do not intend the semantics of sample code
3964 fragments to be interpreted as specifing exactly how many copies are
3965 made.  See issue <a href="lwg-active.html#98">98</a> for a similar problem.]</i></p>
3966
3967 <p><b>Rationale:</b></p>
3968 <p>
3969 This is the second solution described above; as noted, it is
3970 consistent with existing practice.
3971 </p>
3972
3973 <p>Note that we now need to specify the complexity explicitly, because
3974 we are no longer defining <tt>operator[]</tt> in terms of
3975 <tt>insert</tt>.</p>
3976 <hr>
3977 <a name="336"><h3>336.&nbsp;Clause 17 lack of references to deprecated headers</h3></a><p>
3978 <b>Section:</b>&nbsp;17 <a href="lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Detlef Vollmann&nbsp; <b>Date:</b>&nbsp;05 Sep 2001</p>
3979 <p>From c++std-edit-873:</p>
3980
3981 <p>17.4.1.2 <a href="lib-intro.html#lib.headers"> [lib.headers]</a>, Table 11.  In this table, the header
3982 &lt;strstream&gt; is missing.</p>
3983
3984 <p>This shows a general problem: The whole clause 17 refers quite
3985 often to clauses 18 through 27, but D.7 is also a part of the standard
3986 library (though a deprecated one).</p>
3987
3988 <p><b>Proposed resolution:</b></p>
3989 <p><i>[Redmond: The LWG agrees that &lt;strstream&gt; should be added
3990 to table 11.  A review is needed to determine whether there are any
3991 other places in clause 17 where clause D material should be referred
3992 to. Beman will review clause 17.]</i></p>
3993
3994 <p><i>[Cura&ccedil;ao: Beman emailed wording to Matt, but not in time for the
3995 pre-meeting mailing.]</i></p>
3996
3997 <hr>
3998 <a name="338"><h3>338.&nbsp; is whitespace allowed between `-' and a digit?</h3></a><p>
3999 <b>Section:</b>&nbsp;22.2 <a href="lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 Sep 2001</p>
4000 <p>
4001 From Stage 2 processing in 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, p8 and 9 (the
4002 original text or the text corrected by the proposed resolution of
4003 issue <a href="lwg-defects.html#221">221</a>) it seems clear that no whitespace is allowed
4004 within a number, but 22.2.3.1 <a href="lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a>, p2, which gives the
4005 format for integer and floating point values, says that whitespace is
4006 optional between a plusminus and a sign.
4007 </p>
4008
4009 <p>
4010 The text needs to be clarified to either consistently allow or
4011 disallow whitespace between a plusminus and a sign. It might be
4012 worthwhile to consider the fact that the C library stdio facility does
4013 not permit whitespace embedded in numbers and neither does the C or
4014 C++ core language (the syntax of integer-literals is given in 2.13.1 <a href="lex.html#lex.icon"> [lex.icon]</a>, that of floating-point-literals in 2.13.3 <a href="lex.html#lex.fcon"> [lex.fcon]</a> of the C++ standard).
4015 </p>
4016 <p><b>Proposed resolution:</b></p>
4017 <p>Change the first part of 22.2.3.1 <a href="lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a> paragraph 2 from:</p>
4018 <blockquote>
4019 <p>
4020 The syntax for number formats is as follows, where <tt>digit</tt>
4021 represents the radix set specified by the <tt>fmtflags</tt> argument
4022 value, <tt>whitespace</tt> is as determined by the facet
4023 <tt>ctype&lt;charT&gt;</tt> (22.2.1.1), and <tt>thousands-sep</tt> and
4024 <tt>decimal-point</tt> are the results of corresponding
4025 <tt>numpunct&lt;charT&gt;</tt> members.  Integer values have the
4026 format:
4027 </p>
4028 <pre>
4029   integer   ::= [sign] units
4030   sign      ::= plusminus [whitespace]
4031   plusminus ::= '+' | '-'
4032   units     ::= digits [thousands-sep units]
4033   digits    ::= digit [digits]
4034 </pre>
4035 </blockquote>
4036 <p>to:</p>
4037 <blockquote>
4038 <p>
4039 The syntax for number formats is as follows, where <tt>digit</tt>
4040 represents the radix set specified by the <tt>fmtflags</tt> argument
4041 value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
4042 results of corresponding <tt>numpunct&lt;charT&gt;</tt> members.
4043 Integer values have the format:
4044 </p>
4045 <pre>
4046   integer   ::= [sign] units
4047   sign      ::= plusminus
4048   plusminus ::= '+' | '-'
4049   units     ::= digits [thousands-sep units]
4050   digits    ::= digit [digits]
4051 </pre>
4052 </blockquote>
4053 <p><b>Rationale:</b></p>
4054 <p>It's not clear whether the format described in 22.2.3.1 <a href="lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a> paragraph 2 has any normative weight: nothing in the
4055 standard says how, or whether, it's used.  However, there's no reason
4056 for it to differ gratuitously from the very specific description of
4057 numeric processing in 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>.  The proposed
4058 resolution removes all mention of &quot;whitespace&quot; from that format.</p>
4059 <hr>
4060 <a name="339"><h3>339.&nbsp;definition of bitmask type restricted to clause 27</h3></a><p>
4061 <b>Section:</b>&nbsp;22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, 17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 September 2001</p>
4062 <p>
4063 The ctype_category::mask type is declared to be an enum in 22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a> with p1 then stating that it is a bitmask type, most
4064 likely referring to the definition of bitmask type in 17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>, p1. However, the said definition only applies to
4065 clause 27, making the reference in 22.2.1 somewhat dubious.
4066 </p>
4067 <p><b>Proposed resolution:</b></p>
4068 <p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
4069     <blockquote>
4070     Several types defined in clause 27 are bitmask types. Each bitmask type
4071     can be implemented as an enumerated type that overloads certain operators,
4072     as an integer type, or as a bitset (23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>).
4073     </blockquote>
4074 <p>to read</p>
4075     <blockquote>
4076     Several types defined in clauses lib.language.support through
4077     lib.input.output and Annex D are bitmask types. Each bitmask type can
4078     be implemented as an enumerated type that overloads certain operators,
4079     as an integer  type, or as a bitset (lib.template.bitset).
4080     </blockquote>
4081
4082 <p>
4083 Additionally, change the definition in 22.2.1 to adopt the same
4084 convention as in clause 27 by replacing the existing text with the
4085 following (note, in particluar, the cross-reference to 17.3.2.1.2 in
4086 22.2.1, p1):
4087 </p>
4088
4089 <blockquote>
4090 <p>22.2.1 The ctype category [lib.category.ctype]</p>
4091 <pre>
4092 namespace std {
4093     class ctype_base {
4094     public:
4095         typedef <b><i>T</i></b> mask;
4096
4097         // numeric values are for exposition only.
4098         static const mask space = 1 &lt;&lt; 0;
4099         static const mask print = 1 &lt;&lt; 1;
4100         static const mask cntrl = 1 &lt;&lt; 2;
4101         static const mask upper = 1 &lt;&lt; 3;
4102         static const mask lower = 1 &lt;&lt; 4;
4103         static const mask alpha = 1 &lt;&lt; 5;
4104         static const mask digit = 1 &lt;&lt; 6;
4105         static const mask punct = 1 &lt;&lt; 7;
4106         static const mask xdigit = 1 &lt;&lt; 8;
4107         static const mask alnum = alpha | digit;
4108         static const mask graph = alnum | punct;
4109     };
4110 }
4111 </pre>
4112
4113 <p>The type <tt>mask</tt> is a bitmask type (17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>).</p>
4114 </blockquote>
4115
4116 <p><i>[Cura&ccedil;ao: The LWG notes that T above should be bold-italics to be
4117 consistent with the rest of the standard.]</i></p>
4118
4119 <hr>
4120 <a name="340"><h3>340.&nbsp;interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt>
4121 </h3></a><p>
4122 <b>Section:</b>&nbsp;22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2001</p>
4123 <p>
4124 It's unclear whether 22.1.1.1.1, p3 says that
4125 <tt>has_facet&lt;Facet&gt;(loc)</tt> returns true for any <tt>Facet</tt>
4126 from Table 51 or whether it includes Table 52 as well:
4127 </p>
4128
4129 <blockquote>
4130 For any locale <tt>loc</tt> either constructed, or returned by
4131 locale::classic(), and any facet <tt>Facet</tt> that is a member of a
4132 standard category, <tt>has_facet&lt;Facet&gt;(loc)</tt> is true. Each
4133 locale member function which takes a <tt>locale::category</tt>
4134 argument operates on the corresponding set of facets.
4135 </blockquote>
4136
4137 <p>
4138 It seems that it comes down to which facets are considered to be members of a
4139 standard category. Intuitively, I would classify all the facets in Table 52 as
4140 members of their respective standard categories, but there are an unbounded set
4141 of them...
4142 </p>
4143
4144 <p>
4145 The paragraph implies that, for instance, <tt>has_facet&lt;num_put&lt;C,
4146 OutputIterator&gt; &gt;(loc)</tt> must always return true. I don't think that's
4147 possible. If it were, then <tt>use_facet&lt;num_put&lt;C, OutputIterator&gt;
4148 &gt;(loc)</tt> would have to return a reference to a distinct object for each
4149 valid specialization of <tt>num_put&lt;C, OutputIteratory&gt;</tt>, which is
4150 clearly impossible.
4151 </p>
4152
4153 <p>
4154 On the other hand, if none of the facets in Table 52 is a member of a standard
4155 category then none of the locale member functions that operate on entire
4156 categories of facets will work properly.
4157 </p>
4158
4159 <p>
4160 It seems that what p3 should mention that it's required (permitted?)
4161 to hold only for specializations of <tt>Facet</tt> from Table 52 on
4162 <tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
4163 <tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
4164 {
4165 {i,o}<tt>streambuf_iterator</tt>&lt;{<tt>char</tt>,<tt>wchar_t</tt>}<tt>&gt;</tt>
4166 }.
4167 </p>
4168 <p><b>Proposed resolution:</b></p>
4169 <p>In 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, paragraph 3, change
4170 &quot;that is a member of a standard category&quot; to &quot;shown in Table 51&quot;.</p>
4171 <p><b>Rationale:</b></p>
4172 <p>The facets in Table 52 are an unbounded set.  Locales should not be
4173 required to contain an infinite number of facets.</p>
4174
4175 <p>It's not necessary to talk about which values of InputIterator and
4176 OutputIterator must be supported.  Table 51 already contains a
4177 complete list of the ones we need.</p>
4178 <hr>
4179 <a name="341"><h3>341.&nbsp;Vector reallocation and swap</h3></a><p>
4180 <b>Section:</b>&nbsp;23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;27 Sep 2001</p>
4181 <p>It is a common idiom to reduce the capacity of a vector by swapping it with
4182 an empty one:</p>
4183 <pre>
4184   std::vector&lt;SomeType&gt; vec;
4185   // fill vec with data
4186   std::vector&lt;SomeType&gt;().swap(vec);
4187   // vec is now empty, with minimal capacity
4188 </pre>
4189
4190 <p>However, the wording of 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>paragraph 5 prevents
4191 the capacity of a vector being reduced, following a call to
4192 reserve(). This invalidates the idiom, as swap() is thus prevented
4193 from reducing the capacity. The proposed wording for issue <a href="lwg-active.html#329">329</a> does not affect this.  Consequently, the example above
4194 requires the temporary to be expanded to cater for the contents of
4195 vec, and the contents be copied across. This is a linear-time
4196 operation.</p>
4197
4198 <p>However, the container requirements state that swap must have constant
4199 complexity (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> note to table 65).</p>
4200
4201 <p>This is an important issue, as reallocation affects the validity of
4202 references and iterators.</p>
4203
4204 <p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
4205 references and iterators remain valid after a call to swap, if they refer to
4206 an element before the new end() of the vector into which they originally
4207 pointed, in which case they refer to the element at the same index position.
4208 Iterators and references that referred to an element whose index position
4209 was beyond the new end of the vector are invalidated.</p>
4210
4211 <p>If the note to table 65 is taken as the desired intent, then there are two
4212 possibilities with regard to iterators and references:</p>
4213
4214 <ol>
4215 <li>All Iterators and references into both vectors are invalidated.</li>
4216 <li>Iterators and references into either vector remain valid, and remain
4217 pointing to the same element. Consequently iterators and references that
4218 referred to one vector now refer to the other, and vice-versa.</li>
4219 </ol>
4220 <p><b>Proposed resolution:</b></p>
4221 <p>Add a new paragraph after 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> paragraph 5:</p>
4222 <blockquote>
4223 <pre>
4224   void swap(vector&lt;T,Allocator&gt;&amp; x);
4225 </pre>
4226 <p>
4227 <b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
4228 with that of <tt>x</tt>.</p>
4229 <p>
4230 <b>Complexity:</b> Constant time.</p>
4231 </blockquote>
4232
4233 <p><i>[This solves the problem reported for this issue.  We may also
4234 have a problem with a circular definition of swap() for other
4235 containers.]</i></p>
4236
4237 <p><b>Rationale:</b></p>
4238 <p>
4239 swap should be constant time.  The clear intent is that it should just
4240 do pointer twiddling, and that it should exchange all properties of
4241 the two vectors, including their reallocation guarantees.
4242 </p>
4243 <hr>
4244 <a name="342"><h3>342.&nbsp;seek and eofbit</h3></a><p>
4245 <b>Section:</b>&nbsp;27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;09 Oct 201</p>
4246 <p>I think we have a defect.</p>
4247
4248 <p>According to lwg issue <a href="lwg-defects.html#60">60</a> which is now a dr, the
4249 description of seekg in 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> paragraph 38 now looks
4250 like:</p>
4251
4252 <blockquote>
4253 Behaves as an unformatted input function (as described in 27.6.1.3,
4254 paragraph 1), except that it does not count the number of characters
4255 extracted and does not affect the value returned by subsequent calls to
4256 gcount(). After constructing a sentry object, if fail() != true,
4257 executes rdbuf()&shy;&gt;pubseekpos( pos).
4258 </blockquote>
4259
4260 <p>And according to lwg issue <a href="lwg-defects.html#243">243</a> which is also now a dr,
4261 27.6.1.3, paragraph 1 looks like:</p>
4262
4263 <blockquote>
4264 Each unformatted input function begins execution by constructing an
4265 object of class sentry with the default argument noskipws (second)
4266 argument true. If the sentry object returns true, when converted to a
4267 value of type bool, the function endeavors to obtain the requested
4268 input.  Otherwise, if the sentry constructor exits by throwing an
4269 exception or if the sentry object returns false, when converted to a
4270 value of type bool, the function returns without attempting to obtain
4271 any input. In either case the number of extracted characters is set to
4272 0; unformatted input functions taking a character array of non-zero
4273 size as an argument shall also store a null character (using charT())
4274 in the first location of the array. If an exception is thrown during
4275 input then ios::badbit is turned on in *this'ss error state. If
4276 (exception()&amp;badbit)!= 0 then the exception is rethrown. It also counts
4277 the number of characters extracted. If no exception has been thrown it
4278 ends by storing the count in a member object and returning the value
4279 specified. In any event the sentry object is destroyed before leaving
4280 the unformatted input function.
4281 </blockquote>
4282
4283 <p>And finally 27.6.1.1.2/5 says this about sentry:</p>
4284
4285 <blockquote>
4286 If, after any preparation is completed, is.good() is true, ok_ != false
4287 otherwise, ok_ == false.
4288 </blockquote>
4289
4290 <p>
4291 So although the seekg paragraph says that the operation proceeds if
4292 !fail(), the behavior of unformatted functions says the operation
4293 proceeds only if good().  The two statements are contradictory when only
4294 eofbit is set.  I don't think the current text is clear which condition
4295 should be respected.
4296 </p>
4297
4298 <p><b>Further discussion from Redmond:</b></p>
4299
4300 <p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is
4301 &quot;unformatted&quot;. That makes specific claims about sentry that
4302 aren't quite appropriate for seeking, which has less fragile failure
4303 modes than actual input.  If we do really mean that it's unformatted
4304 input, it should behave the same way as other unformatted input.  On
4305 the other hand, &quot;principle of least surprise&quot; is that seeking from EOF
4306 ought to be OK.</p>
4307
4308 <p>Dietmar: nothing should depend on eofbit.  Eofbit should only be
4309 examined by the user to determine why something failed.</p>
4310
4311 <p><i>[Taken from c++std-lib-8873, c++std-lib-8874, c++std-lib-8876]</i></p>
4312
4313 <p><b>Proposed resolution:</b></p>
4314 <p><i>[Howard will do a survey to find out if there are any other
4315 places where we have a problem, where the difference between
4316 <tt>fail()</tt> and <tt>!good()</tt> is important.]</i></p>
4317 <hr>
4318 <a name="347"><h3>347.&nbsp;locale::category and bitmask requirements</h3></a><p>
4319 <b>Section:</b>&nbsp;22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;P.J. Plauger, Nathan Myers&nbsp; <b>Date:</b>&nbsp;23 Oct 2001</p>
4320 <p>
4321 In 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> paragraph 1, the category members
4322 are described as bitmask elements.  In fact, the bitmask requirements
4323 in 17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a> don't seem quite right: <tt>none</tt>
4324 and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
4325
4326 <p>In particular, the requirements for <tt>none</tt> interact poorly
4327 with the requirement that the LC_* constants from the C library must
4328 be recognizable as C++ locale category constants.  LC_* values should
4329 not be mixed with these values to make category values.</p>
4330
4331 <p>We have two options for the proposed resolution.  Informally:
4332 option 1 removes the requirement that LC_* values be recognized as
4333 category arguments.  Option 2 changes the category type so that this
4334 requirement is implementable, by allowing <tt>none</tt> to be some
4335 value such as 0x1000 instead of 0.</p>
4336
4337 <p>Nathan writes: &quot;I believe my proposed resolution [Option 2] merely
4338 re-expresses the status quo more clearly, without introducing any
4339 changes beyond resolving the DR.</p>
4340
4341 <p><b>Proposed resolution:</b></p>
4342 <p>
4343 <b>Option 1:</b> <br>
4344 Replace the first two paragraphs of 22.1.1.1 <a href="lib-locales.html#lib.locale.types"> [lib.locale.types]</a> with:</p>
4345 <blockquote>
4346 <pre>
4347     typedef int category;
4348 </pre>
4349
4350 <p>Valid category values include the <tt>locale</tt> member bitmask
4351 elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
4352 <tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
4353 represents a single locale category. In addition, <tt>locale</tt> member
4354 bitmask constant <tt>none</tt> is defined as zero and represents no
4355 category. And locale member bitmask constant <tt>all</tt> is defined such that
4356 the expression</p>
4357 <pre>
4358     (collate | ctype | monetary | numeric | time | messages | all) == all
4359 </pre>
4360 <p>
4361 is <tt>true</tt>, and represents the union of all categories.  Further
4362 the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
4363 represent a single category, represents the union of the two
4364 categories.
4365 </p>
4366
4367 <p>
4368 <tt>locale</tt> member functions expecting a <tt>category</tt>
4369 argument require one of the <tt>category</tt> values defined above, or
4370 the union of two or more such values. Such a <tt>category</tt>
4371 argument identifies a set of locale categories. Each locale category,
4372 in turn, identifies a set of locale facets, including at least those
4373 shown in Table 51:
4374 </p>
4375 </blockquote>
4376
4377 <p>
4378 <b>Option 2:</b> <br>
4379 Replace the first paragraph of 22.1.1.1 <a href="lib-locales.html#lib.locale.types"> [lib.locale.types]</a> with:</p>
4380 <blockquote>
4381 <p>
4382 Valid category values include the enumerated values.  In addition, the
4383 result of applying commutative operators | and &amp; to any two valid
4384 values is valid, and results in the setwise union and intersection,
4385 respectively, of the argument categories.  The values <tt>all</tt> and
4386 <tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
4387 expressions <tt>(cat | all == all)</tt>, <tt>(cat &amp; all == cat)</tt>,
4388 <tt>(cat | none == cat)</tt> and <tt>(cat &amp; none == none)</tt> are
4389 true.  For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
4390 remaining enumerated values, <tt>(cat1 &amp; cat2 == none)</tt> is true.
4391 For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
4392 of <tt>(cat1 &amp; ~cat2)</tt> is valid, and equals the setwise union of
4393 those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
4394 [Footnote: it is not required that <tt>all</tt> equal the setwise union
4395 of the other enumerated values; implementations may add extra categories.]
4396 </p>
4397 </blockquote>
4398
4399 <p><i>[Cura&ccedil;ao: need input from locale experts.]</i></p>
4400
4401 <hr>
4402 <a name="348"><h3>348.&nbsp;Minor issue with std::pair operator&lt;</h3></a><p>
4403 <b>Section:</b>&nbsp;20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;23 Oct 2001</p>
4404 <p>
4405 The current wording of 20.2.2 [lib.pairs] p6 precludes the use of
4406 operator&lt; on any pair type which contains a pointer.
4407 </p>
4408 <p><b>Proposed resolution:</b></p>
4409 <p>In 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> paragraph 6, replace:</p>
4410 <pre>
4411     Returns: x.first &lt; y.first || (!(y.first &lt; x.first) &amp;&amp; x.second &lt;
4412         y.second).
4413 </pre>
4414 <p>With:</p>
4415 <pre>
4416     Returns: std::less&lt;T1&gt;()( x.first, y.first ) ||
4417              (!std::less&lt;T1&gt;()( y.first, x.first) &amp;&amp;
4418              std::less&lt;T2&gt;()( x.second, y.second ) )
4419 </pre>
4420
4421 <p><i>[Cura&ccedil;ao: LWG leaning toward NAD.&nbsp; In favor of the PR is
4422 that it removes a trap for users.&nbsp; Concerns: 1) will break some
4423 small amount of existing code (which define less and operator &lt;
4424 with different behavior), 2) don't have any indication of rationale
4425 for current design (and unwilling to change without knowing
4426 rationale), 3) consistency; pairs of ptrs would behave differenly from
4427 individual pointers.]</i></p>
4428
4429 <hr>
4430 <a name="349"><h3>349.&nbsp;Minor typographical error in ostream_iterator</h3></a><p>
4431 <b>Section:</b>&nbsp;24.5.2 <a href="lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterator]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;24 Oct 2001</p>
4432 <p>24.5.2 [lib.ostream.iterator] states:</p>
4433 <pre>
4434     [...]
4435
4436     private:
4437     // basic_ostream&lt;charT,traits&gt;* out_stream; exposition only
4438     // const char* delim; exposition only
4439 </pre>
4440
4441 <p>Whilst it's clearly marked &quot;exposition only&quot;, I suspect 'delim'
4442 should be of type 'const charT*'.</p>
4443 <p><b>Proposed resolution:</b></p>
4444 <p>
4445 In 24.5.2 <a href="lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterator]</a>, replace <tt>const char* delim</tt> with
4446 <tt>const charT* delim</tt>.
4447 </p>
4448 <hr>
4449 <a name="350"><h3>350.&nbsp;allocator&lt;&gt;::address</h3></a><p>
4450 <b>Section:</b>&nbsp;20.4.1.1 <a href="lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a>, 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;25 Oct 2001</p>
4451 <p>See c++std-lib-9006 and c++std-lib-9007.  This issue is taken
4452 verbatim from -9007.</p>
4453
4454 <p>
4455 The core language feature allowing definition of operator&amp;() applied
4456 to any non-builtin type makes that operator often unsafe to use in
4457 implementing libraries, including the Standard Library.  The result
4458 is that many library facilities fail for legal user code, such as
4459 the fragment</p>
4460 <pre>
4461   class A { private: A* operator&amp;(); };
4462   std::vector&lt;A&gt; aa;
4463
4464   class B { };
4465   B* operator&amp;(B&amp;) { return 0; }
4466   std::vector&lt;B&gt; ba;
4467 </pre>
4468
4469 <p>
4470 In particular, the requirements table for Allocator (Table 32) specifies
4471 no semantics at all for member address(), and allocator&lt;&gt;::address is
4472 defined in terms of unadorned operator &amp;.
4473 </p>
4474
4475 <p><i>[Cura&ccedil;ao: The LWG believes both examples are ill-formed.&nbsp;
4476 The contained type is required to be CopyConstructible (20.1.3), and
4477 that includes the requirement that &amp;t return the usual types and
4478 values. Since the CopyConstructible requirements appear to have been
4479 written to deal with the concerns of this issue, the LWG feels it is
4480 NAD unless someone can come up with a well-formed example exhibiting a
4481 problem.]</i></p>
4482
4483 <p><b>Proposed resolution:</b></p>
4484 <p>
4485 In 20.4.1.1, Change the definition of allocator&lt;&gt;::address from:</p>
4486 <blockquote>
4487   Returns: &amp;x
4488 </blockquote>
4489
4490 <p>to:</p>
4491
4492 <p>
4493   Returns: The value that the built in operator&amp;(x) would return if not
4494   overloaded.
4495 </p>
4496
4497 <p>
4498 In 20.1.5, Table 32, add to the Notes column of the a.address(r) and
4499 a.address(s) lines, respectively:
4500 </p>
4501
4502 <pre>
4503   allocator&lt;T&gt;::address(r)
4504   allocator&lt;T&gt;::address(s)
4505 </pre>
4506
4507 <p>In addition, in clause 17.4.1.1, add a statement:</p>
4508
4509 <blockquote>
4510  The Standard Library does not apply operator&amp; to any type for which
4511  operator&amp; may be overloaded.
4512 </blockquote>
4513
4514 <p><i>[Cura&ccedil;ao: If the issues isn't NAD, suggest changing &quot;if not
4515 overloaded&quot; to &quot;ignoring all overloads&quot;.]</i></p>
4516
4517 <p><b>Rationale:</b></p>
4518 <p>The obvious implementations for std::allocator&lt;&gt;::address are</p>
4519 <pre>
4520    T* reinterpret_cast&lt;T*&gt;(&amp;static_cast&lt;char&amp;&gt;(o));
4521 </pre>
4522
4523 <p>and</p>
4524
4525 <pre>
4526    T const* reinterpret_cast&lt;T const*&gt;(&amp;static_cast&lt;char const&amp;&gt;(o));
4527 </pre>
4528
4529 <p>
4530 but to define them formally in terms of reinterpret_cast&lt;&gt; seems
4531 to introduce semantic difficulties best avoided.  Using a.address()
4532 should not introduce unspecified or implementation-defined semantics
4533 into a user program.</p>
4534 <hr>
4535 <a name="352"><h3>352.&nbsp;missing fpos requirements</h3></a><p>
4536 <b>Section:</b>&nbsp;21.1.2 <a href="lib-strings.html#lib.char.traits.typedefs"> [lib.char.traits.typedefs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;2 Dec 2001</p>
4537 <p>
4538 <i>(1)</i>
4539 There are no requirements on the <tt>stateT</tt> template parameter of
4540 <tt>fpos</tt> listed in 27.4.3. The interface appears to require that
4541 the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
4542 and I think also DefaultConstructible (to implement the operations in
4543 Table 88).
4544 </p>
4545 <p>
4546 21.1.2, p3, however, only requires that
4547 <tt>char_traits&lt;charT&gt;::state_type</tt> meet the requirements of
4548 CopyConstructible types.
4549 </p>
4550 <p>
4551 <i>(2)</i>
4552 Additionally, the <tt>stateT</tt> template argument has no
4553 corresponding typedef in fpos which might make it difficult to use in
4554 generic code.
4555 </p>
4556 <p><b>Proposed resolution:</b></p>
4557 <p>
4558 Modify 21.1.2, p4 from
4559 </p>
4560 <p>
4561     Requires: <tt>state_type</tt> shall meet the requirements of
4562               CopyConstructible types (20.1.3).
4563 </p>
4564 <p>
4565     Requires: state_type shall meet the requirements of Assignable
4566               (23.1, p4), CopyConstructible (20.1.3), and
4567               DefaultConstructible  (20.1.4) types.
4568 </p>
4569 <p>
4570 Add to the definition of the fpos class template the following member:
4571 </p>
4572 <pre>
4573     typedef stateT state_type;
4574 </pre>
4575 <p>
4576 and add to 27.4.3.1 a paragraph with the following text:
4577 </p>
4578 <pre>
4579     typedef stateT state_type;
4580 </pre>
4581 <p>
4582     Requires: <tt>state_type</tt> shall meet the requirements of
4583               Assignable (23.1, p4), CopyConstructible (20.1.3), and
4584               DefaultConstructible (20.1.4) types.
4585 </p>
4586
4587 <p><i>[Cura&ccedil;ao: The LWG feels this is two issues, as indicated
4588 above. The first is a defect; more I/O experts need to review
4589 the PR. The second is questionable; who would use it? Unless
4590 motivation is provided, the second should be considered NAD.]</i></p>
4591
4592 <hr>
4593 <a name="354"><h3>354.&nbsp;Associative container lower/upper bound requirements</h3></a><p>
4594 <b>Section:</b>&nbsp;23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Aberg&nbsp; <b>Date:</b>&nbsp;17 Dec 2001</p>
4595 <p>
4596 Discussions in the thread &quot;Associative container lower/upper bound
4597 requirements&quot; on comp.std.c++ suggests that there is a defect in the
4598 C++ standard, Table 69 of section 23.1.2, &quot;Associative containers&quot;,
4599 [lib.associative.reqmts].  It currently says:</p>
4600
4601 <blockquote>
4602 <p>
4603 a.find(k): returns an iterator pointing to an element with the key equivalent to
4604 k, or a.end() if such an element is not found.
4605 </p>
4606
4607 <p>
4608 a.lower_bound(k): returns an iterator pointing to the first element with
4609 key not less than k.
4610 </p>
4611
4612 <p>
4613 a.upper_bound(k): returns an iterator pointing to the first element with
4614 key greater than k.
4615 </p>
4616 </blockquote>
4617
4618 <p>
4619 We have &quot;or a.end() if such an element is not found&quot; for
4620 <tt>find</tt>, but not for <tt>upper_bound</tt> or
4621 <tt>lower_bound</tt>.  As the text stands, one would be forced to
4622 insert a new element into the container and return an iterator to that
4623 in case the sought iterator does not exist, which does not seem to be
4624 the intention (and not possible with the &quot;const&quot; versions).
4625 </p>
4626 <p><b>Proposed resolution:</b></p>
4627
4628 <p>Change Table 69 of section 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> indicated entries
4629 to:</p>
4630
4631 <blockquote>
4632 <p>
4633 a.lower_bound(k): returns an iterator pointing to the first element with
4634 key not less than k, or a.end() if such an element is not found.
4635 </p>
4636
4637 <p>
4638 a.upper_bound(k): returns an iterator pointing to the first element with
4639 key greater than k, or a.end() if such an element is not found.
4640 </p>
4641 </blockquote>
4642
4643 <p><i>[Cura&ccedil;ao: LWG reviewed PR.]</i></p>
4644
4645 <hr>
4646 <a name="355"><h3>355.&nbsp;Operational semantics for a.back()</h3></a><p>
4647 <b>Section:</b>&nbsp;23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Yaroslav Mironov&nbsp; <b>Date:</b>&nbsp;23 Jan 2002</p>
4648
4649 <p>Table 68 &quot;Optional Sequence Operations&quot; in 23.1.1/12
4650 specifies operational semantics for &quot;a.back()&quot; as
4651 &quot;*--a.end()&quot;, which may be ill-formed <i>[because calling
4652 operator-- on a temporary (the return) of a built-in type is
4653 ill-formed]</i>, provided a.end() returns a simple pointer rvalue
4654 (this is almost always the case for std::vector::end(), for
4655 example). Thus, the specification is not only incorrect, it
4656 demonstrates a dangerous construct: &quot;--a.end()&quot; may
4657 successfully compile and run as intended, but after changing the type
4658 of the container or the mode of compilation it may produce
4659 compile-time error. </p>
4660
4661 <p><b>Proposed resolution:</b></p>
4662 <p>Change the specification in table 68 &quot;Optional Sequence
4663 Operations&quot; in 23.1.1/12 for &quot;a.back()&quot; from</p>
4664
4665
4666 <blockquote>
4667 *--a.end()
4668 </blockquote>
4669
4670 <p>to</p>
4671
4672 <blockquote>
4673   <p>*a.rbegin()</p>
4674 </blockquote>
4675
4676 <p>and the specification for &quot;a.pop_back()&quot; from</p>
4677
4678 <blockquote>
4679 a.erase(--a.end())
4680 </blockquote>
4681
4682 <p>to</p>
4683
4684 <blockquote>
4685   <p>a.erase(rbegin())</p>
4686 </blockquote>
4687
4688 <p><i>[Cura&ccedil;ao: LWG changed PR from &quot;{ X::iterator tmp =
4689 a.end(); return *--tmp; }&quot; to &quot;*a.rbegin()&quot;, and from
4690 &quot;{ X::iterator tmp = a.end(); a.erase(--tmp); }&quot; to
4691 &quot;a.erase(rbegin())&quot;.]</i></p>
4692
4693 <p><i>[There is a second possible defect; table 68 &quot;Optional
4694 Sequence Operations&quot; in the &quot;Operational Semantics&quot;
4695 column uses operations present only in the &quot;Reversible
4696 Container&quot; requirements, yet there is no stated dependency
4697 between these separate requirements tables. Ask in Santa Cruz if the
4698 LWG would like a new issue opened.]</i></p>
4699
4700 <hr>
4701 <a name="356"><h3>356.&nbsp;Meaning of ctype_base::mask enumerators</h3></a><p>
4702 <b>Section:</b>&nbsp;22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Jan 2002</p>
4703
4704 <p>What should the following program print?</p>
4705
4706 <pre>
4707   #include &lt;locale&gt;
4708   #include &lt;iostream&gt;
4709
4710   class my_ctype : public std::ctype&lt;char&gt;
4711   {
4712     typedef std::ctype&lt;char&gt; base;
4713   public:
4714     my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
4715     {
4716       std::copy(base::classic_table(), base::classic_table() + base::table_size,
4717                 my_table);
4718       my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space);
4719     }
4720   private:
4721     mask my_table[base::table_size];
4722   };
4723
4724   int main()
4725   {
4726     my_ctype ct;
4727     std::cout &lt;&lt; &quot;isspace: &quot; &lt;&lt; ct.is(std::ctype_base::space, '_') &lt;&lt; &quot;    &quot;
4728               &lt;&lt; &quot;isalpha: &quot; &lt;&lt; ct.is(std::ctype_base::alpha, '_') &lt;&lt; std::endl;
4729   }
4730 </pre>
4731
4732 <p>The goal is to create a facet where '_' is treated as whitespace.</p>
4733
4734 <p>On gcc 3.0, this program prints &quot;isspace: 1 isalpha: 0&quot;.  On
4735 Microsoft C++ it prints &quot;isspace: 1 isalpha: 1&quot;.</p>
4736
4737 <p>
4738 I believe that both implementations are legal, and the standard does not
4739 give enough guidance for users to be able to use std::ctype's
4740 protected interface portably.</p>
4741
4742 <p>
4743 The above program assumes that ctype_base::mask enumerators like
4744 <tt>space</tt> and <tt>print</tt> are disjoint, and that the way to
4745 say that a character is both a space and a printing character is to or
4746 those two enumerators together.  This is suggested by the &quot;exposition
4747 only&quot; values in 22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, but it is nowhere specified in
4748 normative text.  An alternative interpretation is that the more
4749 specific categories subsume the less specific.  The above program
4750 gives the results it does on the Microsoft compiler because, on that
4751 compiler, <tt>print</tt> has all the bits set for each specific
4752 printing character class.
4753 </p>
4754
4755 <p>From the point of view of std::ctype's public interface, there's no
4756 important difference between these two techniques.  From the point of
4757 view of the protected interface, there is.  If I'm defining a facet
4758 that inherits from std::ctype&lt;char&gt;, I'm the one who defines the
4759 value that table()['a'] returns.  I need to know what combination of
4760 mask values I should use.  This isn't so very esoteric: it's exactly
4761 why std::ctype has a protected interface.  If we care about users
4762 being able to write their own ctype facets, we have to give them a
4763 portable way to do it.
4764 </p>
4765
4766 <p>
4767 Related reflector messages:
4768 lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274,
4769 lib-9277, lib-9279.
4770 </p>
4771
4772 <p>Issue <a href="lwg-active.html#339">339</a> is related, but not identical.  The
4773 proposed resolution if issue <a href="lwg-active.html#339">339</a> says that
4774 ctype_base::mask must be a bitmask type. It does not say that the
4775 ctype_base::mask elements are bitmask elements, so it doesn't
4776 directly affect this issue.</p>
4777
4778 <p><b>Proposed resolution:</b></p>
4779 <p>Informally, we have three choices:</p>
4780 <ol>
4781 <li>Require that the enumerators are disjoint (except for alnum and
4782 graph)</li>
4783 <li>Require that the enumerators are not disjoint, and specify which
4784 of them subsume which others.  (e.g. mandate that lower includes alpha
4785 and print)</li>
4786 <li>Explicitly leave this unspecified, which the result that the above
4787 program is not portable.</li>
4788 </ol>
4789
4790 <p>Either of the first two options is just as good from the standpoint
4791 of portability.  Either one will require some implementations to
4792 change.</p>
4793
4794 <hr>
4795 <a name="357"><h3>357.&nbsp;&lt;cmath&gt; float functions cannot return HUGE_VAL</h3></a><p>
4796 <b>Section:</b>&nbsp;26.5 <a href="lib-numerics.html#lib.c.math"> [lib.c.math]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;26 Feb 2002</p>
4797 <p>
4798 The float versions of the math functions have no meaningful value to return
4799 for a range error. The long double versions have a value they can return,
4800 but it isn't necessarily the most reasonable value.
4801 </p>
4802
4803 <p>
4804 Section 26.5 [lib.c.math], paragraph 5, says that C++ &quot;adds float and long
4805 double overloaded versions of these functions, with the same semantics,&quot;
4806 referring to the math functions from the C90 standard.
4807 </p>
4808
4809 <p>
4810 The C90 standard, in section 7.5.1, paragraph 3, says that functions return
4811 &quot;the value of the macro HUGE_VAL&quot; when they encounter a range error.
4812 Section 7.5, paragraph 2, defines HUGE_VAL as a macro that &quot;expands to a
4813 positive double expression, not necessarily representable as a float.&quot;
4814 </p>
4815
4816 <p>
4817 Therefore, the float versions of the math functions have no way to
4818 signal a range error. <i>[Cura&ccedil;ao: The LWG notes that this isn't
4819 strictly correct, since errno is set.]</i> The semantics require that they
4820 return HUGE_VAL, but they cannot because HUGE_VAL might not be
4821 representable as a float.
4822 </p>
4823
4824 <p>
4825 The problem with long double functions is less severe because HUGE_VAL is
4826 representable as a long double. On the other hand, it might not be a &quot;huge&quot;
4827 long double value, and might fall well within the range of normal return
4828 values for a long double function. Therefore, it does not make sense for a
4829 long double function to return a double (HUGE_VAL) for a range error.
4830 </p>
4831 <p><b>Proposed resolution:</b></p>
4832 <p>Cura&ccedil;ao: C99 was faced with a similar problem, which they fixed by
4833 adding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.</p>
4834
4835 <p>C++ must also fix, but it should be done in the context of the
4836 general C99 based changes to C++, not via DR. Thus the LWG in Cura&ccedil;ao
4837 felt the resolution should be NAD, FUTURE, but the issue is being held
4838 open for one more meeting to ensure LWG members not present during the
4839 discussion concur.</p>
4840 <hr>
4841 <a name="358"><h3>358.&nbsp;interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt>
4842 </h3></a><p>
4843 <b>Section:</b>&nbsp;22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
4844 <p>
4845 I don't think <tt>thousands_sep</tt> is being treated correctly after
4846 decimal_point has been seen. Since grouping applies only to the
4847 integral part of the number, the first such occurrence should, IMO,
4848 terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
4849 and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
4850 interpreted in the fractional part of a number.)
4851 </p>
4852
4853 <p>
4854 The easiest change I can think of that resolves this issue would be
4855 something like below.
4856 </p>
4857 <p><b>Proposed resolution:</b></p>
4858 <p>
4859 Change the first sentence of 22.2.2.1.2, p9 from
4860 </p>
4861
4862 <blockquote>
4863     If discard is true then the position of the character is
4864     remembered, but the character is otherwise ignored. If it is not
4865     discarded, then a check is made to determine if c is allowed as
4866     the next character of an input field of the conversion specifier
4867     returned by stage 1. If so it is accumulated.
4868 </blockquote>
4869
4870 <p>to</p>
4871
4872 <blockquote>
4873     If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
4874     accumulated, then the position of the character is remembered, but
4875     the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
4876     already been accumulated, the character is discarded and Stage 2
4877      terminates. ...
4878 </blockquote>
4879
4880 <hr>
4881 <a name="359"><h3>359.&nbsp;num_put&lt;&gt;::do_put (..., bool) undocumented</h3></a><p>
4882 <b>Section:</b>&nbsp;22.2.2.2.1 <a href="lib-locales.html#lib.facet.num.put.members"> [lib.facet.num.put.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
4883 <p>22.2.2.2.1, p1:</p>
4884
4885     <pre>
4886     iter_type put (iter_type out, ios_base&amp; str, char_type fill,
4887                    bool val) const;
4888     ...
4889
4890     1   Returns: do_put (out, str, fill, val).
4891     </pre>
4892
4893 <p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
4894 however, 22.2.2.2.2, p23:</p>
4895
4896 <blockquote>
4897 <pre>
4898 iter_type put (iter_type out, ios_base&amp; str, char_type fill,
4899                bool val) const;
4900 </pre>
4901
4902
4903         Effects: If (str.flags() &amp; ios_base::boolalpha) == 0 then do
4904              out = do_put(out, str, fill, (int)val)
4905            Otherwise do
4906 <pre>
4907              string_type s =
4908                  val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
4909                      : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
4910 </pre>
4911            and then insert the characters of s into out. <i>out</i>.
4912 </blockquote>
4913
4914 <p>
4915 This means that the bool overload of <tt>do_put()</tt> will never be called,
4916 which contradicts the first paragraph. Perhaps the declaration
4917 should read <tt>do_put()</tt>, and not <tt>put()</tt>?
4918 </p>
4919
4920 <p>
4921 Note also that there is no <b>Returns</b> clause for this function, which
4922 should probably be corrected, just as should the second occurrence
4923 of <i>&quot;out.&quot;</i> in the text.
4924 </p>
4925
4926 <p>
4927 I think the least invasive change to fix it would be something like
4928 the following:
4929 </p>
4930 <p><b>Proposed resolution:</b></p>
4931 <p>
4932 In 22.2.2.2.2, p23, make the following changes
4933 </p>
4934
4935 <blockquote>
4936      Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
4937      of the member function.
4938 </blockquote>
4939
4940 <blockquote>
4941     Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
4942     avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
4943     do_put (..., bool))</tt>
4944     like so:
4945 </blockquote>
4946
4947 <blockquote>
4948     23   <b>Returns</b>: If <tt>(str.flags() &amp;
4949          ios_base::boolalpha) == 0</tt> then
4950          <tt>do_put (out, str, fill, (int)val)</tt>
4951          Otherwise the function obtains a string <tt>s</tt> as if by
4952 <pre>
4953              string_type s =
4954                 val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
4955                     : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
4956 </pre>
4957          and then inserts each character <tt>c</tt> of s into out via
4958            <tt>*out++ = c</tt>
4959          and returns <tt>out</tt>.
4960 </blockquote>
4961
4962 <hr>
4963 <a name="360"><h3>360.&nbsp;locale mandates inefficient implementation</h3></a><p>
4964 <b>Section:</b>&nbsp;22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
4965 <p>
4966 22.1.1, p7 (copied below) allows iostream formatters and extractors
4967 to make assumptions about the values returned from facet members.
4968 However, such assumptions are apparently not guaranteed to hold
4969 in other cases (e.g., when the facet members are being called directly
4970 rather than as a result of iostream calls, or between successive
4971 calls to the same iostream functions with no interevening calls to
4972 <tt>imbue()</tt>, or even when the facet member functions are called
4973 from other member functions of other facets). This restriction
4974 prevents locale from being implemented efficiently.
4975 </p>
4976 <p><b>Proposed resolution:</b></p>
4977 <p>Change the first sentence in 22.1.1, p7 from</p>
4978 <blockquote>
4979     In successive calls to a locale facet member function during
4980     a call to an iostream inserter or extractor or a streambuf member
4981     function, the returned result shall be identical. [Note: This
4982     implies that such results may safely be reused without calling
4983     the locale facet member function again, and that member functions
4984     of iostream classes cannot safely call <tt>imbue()</tt>
4985     themselves, except as specified elsewhere. --end note]
4986 </blockquote>
4987
4988 <p>to</p>
4989
4990 <blockquote>
4991     In successive calls to a locale facet member function on a facet
4992     object installed in the same locale, the returned result shall be
4993     identical. ...
4994 </blockquote>
4995
4996 <hr>
4997 <a name="361"><h3>361.&nbsp;num_get&lt;&gt;::do_get (..., void*&amp;) checks grouping</h3></a><p>
4998 <b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
4999 <p>
5000 22.2.2.2.2, p12 specifies that <tt>thousands_sep</tt> is to be inserted only
5001 for integral types (issue 282 suggests that this should be done for
5002 all arithmetic types).
5003 </p>
5004
5005 <p>
5006 22.2.2.1.2, p12 requires that grouping be checked for all extractors
5007 including that for <tt>void*</tt>.
5008 </p>
5009
5010 <p>
5011 I don't think that's right. <tt>void*</tt> values should not be checked for
5012 grouping, should they? (Although if they should, then <tt>num_put</tt> needs
5013 to write them out, otherwise their extraction will fail.)
5014 </p>
5015 <p><b>Proposed resolution:</b></p>
5016 <p>
5017 Change the first sentence of 22.2.2.2.2, p12 from
5018 </p>
5019 <blockquote>
5020     Digit grouping is checked. That is, the positions of discarded
5021     separators is examined for consistency with
5022     use_facet&lt;numpunct&lt;charT&gt; &gt;(loc).grouping().
5023     If they are not consistent then ios_base::failbit is assigned
5024     to err.
5025 </blockquote>
5026
5027 <p>to</p>
5028 <blockquote>
5029     Except for conversions to void*, digit grouping is checked...
5030 </blockquote>
5031
5032 <hr>
5033 <a name="362"><h3>362.&nbsp;bind1st/bind2nd type safety</h3></a><p>
5034 <b>Section:</b>&nbsp;20.3.6.2 <a href="lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Demkin&nbsp; <b>Date:</b>&nbsp;26 Apr 2002</p>
5035 <p>
5036 The definition of bind1st() (20.3.6.2 <a href="lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>) can result in
5037 the construction of an unsafe binding between incompatible pointer
5038 types. For example, given a function whose first parameter type is
5039 'pointer to T', it's possible without error to bind an argument of
5040 type 'pointer to U' when U does not derive from T:
5041 </p>
5042 <pre>
5043    foo(T*, int);
5044
5045    struct T {};
5046    struct U {};
5047
5048    U u;
5049
5050    int* p;
5051    int* q;
5052
5053    for_each(p, q, bind1st(ptr_fun(foo), &amp;u));    // unsafe binding
5054 </pre>
5055
5056 <p>
5057 The definition of bind1st() includes a functional-style conversion to
5058 map its argument to the expected argument type of the bound function
5059 (see below):
5060 </p>
5061 <pre>
5062   typename Operation::first_argument_type(x)
5063 </pre>
5064
5065 <p>
5066 A functional-style conversion (5.2.3 <a href="expr.html#expr.type.conv"> [expr.type.conv]</a>) is defined to be
5067 semantically equivalent to an explicit cast expression (5.4 <a href="expr.html#expr.cast"> [expr.cast]</a>), which may (according to 5.4, paragraph 5) be interpreted
5068 as a reinterpret_cast, thus masking the error.
5069 </p>
5070
5071 <p>The problem and proposed change also apply to 20.3.6.4 <a href="lib-utilities.html#lib.bind.2nd"> [lib.bind.2nd]</a>.</p>
5072 <p><b>Proposed resolution:</b></p>
5073 <p>
5074 The simplest and most localized change to prevent such errors is to
5075 require bind1st() use a static_cast expression rather than the
5076 functional-style conversion; that is, have bind1st() return:
5077 </p>
5078 <pre>
5079    binder1st&lt;Operation&gt;( op,
5080      static_cast&lt;typename Operation::first_argument_type&gt;(x)).
5081 </pre>
5082
5083 <p>
5084 A more agressive solution is to change the semantics of
5085 functional-style conversions to not permit a reinterpret_cast. For
5086 contexts that require the semantics of reinterpret_cast, the language
5087 may want to require the use of an explicit cast expression such as
5088 '(T) x' or 'reinterpret_cast&lt;T&gt;(x)' and limit the behavior of
5089 the functional notation to match statically-checked and standard
5090 conversions (as defined by 5.2.9 and 4.10, etc.).  Although changing
5091 the semantics of functional-style conversions may seem drastic and
5092 does have language-wide ramifications, it has the benefit of better
5093 unifying the conversion rules for user defined types and built-in
5094 types, which can be especially important for generic template
5095 programming.
5096 </p>
5097 <hr>
5098 <a name="363"><h3>363.&nbsp;Missing exception specification in 27.4.2.1.1</h3></a><p>
5099 <b>Section:</b>&nbsp;27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;20 May 2002</p>
5100 <p>
5101 The destructor of ios_base::failure should have an empty throw
5102 specification, because the destructor of its base class, exception, is
5103 declared in this way.
5104 </p>
5105 <p><b>Proposed resolution:</b></p>
5106 <p>Change the destructor to</p>
5107 <pre>
5108   virtual ~failure() throw();
5109 </pre>
5110 <hr>
5111 <a name="364"><h3>364.&nbsp;Inconsistent wording in 27.5.2.4.2</h3></a><p>
5112 <b>Section:</b>&nbsp;27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;10 May 2002</p>
5113 <p>
5114 27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a> paragraph 1 is inconsistent with the Effects
5115 clause for seekoff.
5116 </p>
5117 <p><b>Proposed resolution:</b></p>
5118 <p>
5119 Make this paragraph, the Effects clause for setbuf, consistent in wording
5120 with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
5121 to indicate the purpose of setbuf:
5122 </p>
5123
5124 <p>Original text:</p>
5125
5126 <blockquote>
5127 1 Effects: Performs an operation that is defined separately for each
5128 class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
5129 </blockquote>
5130
5131 <p>Proposed text:</p>
5132
5133 <blockquote>
5134 1 Effects: Influences stream buffering in a way that is defined separately
5135 for each class derived from basic_streambuf in this clause
5136 (27.7.1.3, 27.8.1.4).
5137 </blockquote>
5138
5139 <hr>
5140 <a name="365"><h3>365.&nbsp;Lack of const-qualification in clause 27</h3></a><p>
5141 <b>Section:</b>&nbsp;27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;10 May 2002</p>
5142 <p>
5143 None of the following member functions are declared const, but we
5144 believe each should be. See document N1360 for details and rationale.
5145 </p>
5146 <p><b>Proposed resolution:</b></p>
5147 <p>In 27.5.2 and 27.5.2.2.3</p>
5148 <p>Replace</p>
5149 <pre>
5150   streamsize in_avail();
5151 </pre>
5152 <p>with</p>
5153 <pre>
5154   streamsize in_avail() const;
5155 </pre>
5156
5157 <p>In 27.5.2 and 27.5.2.4.3, and  27.8.1.1 and 27.8.1.4</p>
5158 <p>Replace</p>
5159 <pre>
5160   virtual streamsize showmanyc();
5161 </pre>
5162 <p>with</p>
5163 <pre>
5164   virtual streamsize showmanyc() const;
5165 </pre>
5166
5167 <p>In 27.6.1.1 and 27.6.1.3</p>
5168 <p>Replace</p>
5169 <pre>
5170   pos_type tellg();
5171 </pre>
5172 <p>with</p>
5173 <pre>
5174   pos_type tellg() const;
5175 </pre>
5176
5177 <p>This requires additional change, because paragraph 37 describes the
5178 return value in terms of calls to non-const member functions. Either of
5179 the two following solutions would allow tellg to be declared const.</p>
5180
5181 <p>Option 1: Implementers may cast away const-ness, to allow calling the
5182 non-const rdbuf.</p>
5183 <p>In paragraph 37, replace:</p>
5184 <pre>
5185   .... rdbuf()
5186   -&gt;pubseekoff(0, cur, in).
5187 </pre>
5188 <p>by</p>
5189 <pre>
5190   .... const_cast&lt;basic_istream&lt;charT, traits&gt;*&gt;(this)-&gt;rdbuf()
5191   -&gt;pubseekoff(0, cur, in).
5192 </pre>
5193
5194 <p>Option 2: Provide const member functions to do the job. The proposals in
5195 a later section (specifically, the modifications concerning rdbuf
5196 throughout the iostream library) meet most of this need; we would also
5197 need the following addition to basic_streambuf:</p>
5198
5199 <blockquote>
5200 <pre>
5201 basic_streambuf&lt;charT,traits&gt;::pos_type
5202 basic_streambuf&lt;charT,traits&gt;::position(ios_base::openmode mode =
5203                                         ios_base::in|ios_base::out)
5204                                         const;
5205 </pre>
5206 <p>Effects: same as calling basic_streambuf::pubseekoff(0, ios base::cur, mode)</p>
5207 </blockquote>
5208
5209 <p>In 27.6.2.1 and 27.6.2.4</p>
5210 <p>Replace</p>
5211 <pre>
5212   pos_type tellp();
5213 </pre>
5214 <p>with</p>
5215 <pre>
5216   pos_type tell() const;
5217 </pre>
5218
5219 <p>This requires additional change; see the discussion for tellg() above.</p>
5220
5221 <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>
5222 <p>Replace</p>
5223 <pre>
5224   bool is_open();
5225 </pre>
5226 <p>with</p>
5227 <pre>
5228   bool is_open() const;
5229 </pre>
5230 <hr>
5231 <a name="366"><h3>366.&nbsp;Excessive const-qualification</h3></a><p>
5232 <b>Section:</b>&nbsp;27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;10 May 2002</p>
5233 <p>
5234 The following member functions are declared const, yet return non-const
5235 pointers. We believe they are should be changed, because they allow code
5236 that may surprise the user. See document N1360 for details and
5237 rationale.
5238 </p>
5239 <p><b>Proposed resolution:</b></p>
5240 <p>In 27.4.4 and 27.4.4.2</p>
5241 <p>Replace</p>
5242 <pre>
5243   basic_ostream&lt;charT,traits&gt;* tie() const;
5244 </pre>
5245 <p>with</p>
5246 <pre>
5247   basic_ostream&lt;charT,traits&gt;* tie();
5248   const basic_ostream&lt;charT,traits&gt;* tie() const;
5249 </pre>
5250
5251 <p>and replace</p>
5252 <pre>
5253   basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
5254 </pre>
5255 <p>with</p>
5256 <pre>
5257   basic_streambuf&lt;charT,traits&gt;* rdbuf();
5258   const basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
5259 </pre>
5260
5261 <p>In 27.5.2 and 27.5.2.3.1</p>
5262 <p>Replace</p>
5263 <pre>
5264   char_type* eback() const;
5265 </pre>
5266 <p>with</p>
5267 <pre>
5268   char_type* eback();
5269   const char_type* eback() const;
5270 </pre>
5271
5272 <p>Replace</p>
5273 <pre>
5274   char_type gptr() const;
5275 </pre>
5276 <p>with</p>
5277 <pre>
5278   char_type* gptr();
5279   const char_type* gptr() const;
5280 </pre>
5281
5282 <p>Replace</p>
5283 <pre>
5284   char_type* egptr() const;
5285 </pre>
5286 <p>with</p>
5287 <pre>
5288   char_type* egptr();
5289   const char_type* egptr() const;
5290 </pre>
5291
5292 <p>In 27.5.2 and 27.5.2.3.2</p>
5293 <p>Replace</p>
5294 <pre>
5295   char_type* pbase() const;
5296 </pre>
5297 <p>with</p>
5298 <pre>
5299   char_type* pbase();
5300   const char_type* pbase() const;
5301 </pre>
5302
5303 <p>Replace</p>
5304 <pre>
5305   char_type* pptr() const;
5306 </pre>
5307 <p>with</p>
5308 <pre>
5309   char_type* pptr();
5310   const char_type* pptr() const;
5311 </pre>
5312
5313 <p>Replace</p>
5314 <pre>
5315   char_type* epptr() const;
5316 </pre>
5317 <p>with</p>
5318 <pre>
5319   char_type* epptr();
5320   const char_type* epptr() const;
5321 </pre>
5322
5323 <p>In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6</p>
5324 <p>Replace</p>
5325 <pre>
5326   basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
5327 </pre>
5328 <p>with</p>
5329 <pre>
5330   basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf();
5331   const basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
5332 </pre>
5333
5334 <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>
5335 <p>Replace</p>
5336 <pre>
5337   basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
5338 </pre>
5339 <p>with</p>
5340 <pre>
5341   basic_filebuf&lt;charT,traits&gt;* rdbuf();
5342   const basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
5343 </pre>
5344 <hr>
5345 <a name="367"><h3>367.&nbsp;remove_copy/remove_copy_if and Input Iterators</h3></a><p>
5346 <b>Section:</b>&nbsp;25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;13 May 2002</p>
5347 <p>
5348 remove_copy and remove_copy_if (25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a>) permit their
5349 input range to be marked with Input Iterators. However, since two
5350 operations are required against the elements to copy (comparison and
5351 assigment), when the input range uses Input Iterators, a temporary
5352 copy must be taken to avoid dereferencing the iterator twice. This
5353 therefore requires the value type of the InputIterator to be
5354 CopyConstructible. If the iterators are at least Forward Iterators,
5355 then the iterator can be dereferenced twice, or a reference to the
5356 result maintained, so the temporary is not required.
5357 </p>
5358 <p><b>Proposed resolution:</b></p>
5359 <p>
5360 Add &quot;If InputIterator does not meet the requirements of forward
5361 iterator, then the value type of InputIterator must be copy
5362 constructible. Otherwise copy constructible is not required.&quot; to
5363 25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a> paragraph 6.
5364 </p>
5365 <hr>
5366 <a name="368"><h3>368.&nbsp;basic_string::replace has two &quot;Throws&quot; paragraphs</h3></a><p>
5367 <b>Section:</b>&nbsp;21.3.5.6 <a href="lib-strings.html#lib.string::replace"> [lib.string::replace]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;3 Jun 2002</p>
5368 <p>
5369 21.3.5.6 <a href="lib-strings.html#lib.string::replace"> [lib.string::replace]</a> basic_string::replace, second
5370 signature, given in paragraph 1, has two &quot;Throws&quot; paragraphs (3 and
5371 5).
5372 </p>
5373
5374 <p>
5375 In addition, the second &quot;Throws&quot; paragraph (5) includes specification
5376 (beginning with &quot;Otherwise, the function replaces ...&quot;) that should be
5377 part of the &quot;Effects&quot; paragraph.
5378 </p>
5379 <p><b>Proposed resolution:</b></p>
5380 <hr>
5381 <a name="369"><h3>369.&nbsp;io stream objects and static ctors</h3></a><p>
5382 <b>Section:</b>&nbsp;27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ruslan Abdikeev&nbsp; <b>Date:</b>&nbsp;8 Jul 2002</p>
5383 <p>
5384 Is it safe to use standard iostream objects from constructors of
5385 static objects?  Are standard iostream objects constructed and are
5386 their associations established at that time?
5387 </p>
5388
5389 <p>Surpisingly enough, Standard does NOT require that.</p>
5390
5391 <p>
5392 27.3/2 [lib.iostream.objects] guarantees that standard iostream
5393 objects are constructed and their associations are established before
5394 the body of main() begins execution.  It also refers to ios_base::Init
5395 class as the panacea for constructors of static objects.
5396 </p>
5397
5398 <p>
5399 However, there's nothing in 27.3 [lib.iostream.objects],
5400 in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
5401 that would require implementations to allow access to standard
5402 iostream objects from constructors of static objects.
5403 </p>
5404
5405 <p>Details:</p>
5406
5407 <p>Core text refers to some magic object ios_base::Init, which will
5408 be discussed below:</p>
5409
5410 <blockquote>
5411     &quot;The [standard iostream] objects are constructed, and their
5412     associations are established at some time prior to or during
5413     first time an object of class basic_ios&lt;charT,traits&gt;::Init
5414     is constructed, and in any case before the body of main
5415     begins execution.&quot; (27.3/2 [lib.iostream.objects])
5416 </blockquote>
5417
5418 <p>
5419 The first <i>non-normative</i> footnote encourages implementations
5420 to initialize standard iostream objects earlier than required.
5421 </p>
5422
5423 <p>However, the second <i>non-normative</i> footnote makes an explicit
5424 and unsupported claim:</p>
5425
5426 <blockquote>
5427   &quot;Constructors and destructors for static objects can access these
5428   [standard iostream] objects to read input from stdin or write output
5429   to stdout or stderr.&quot; (27.3/2 footnote 265 [lib.iostream.objects])
5430 </blockquote>
5431
5432 <p>
5433 The only bit of magic is related to that ios_base::Init class.  AFAIK,
5434 the rationale behind ios_base::Init was to bring an instance of this
5435 class to each translation unit which #included &lt;iostream&gt; or
5436 related header.  Such an inclusion would support the claim of footnote
5437 quoted above, because in order to use some standard iostream object it
5438 is necessary to #include &lt;iostream&gt;.
5439 </p>
5440
5441 <p>
5442 However, while Standard explicitly describes ios_base::Init as
5443 an appropriate class for doing the trick, I failed to found a
5444 mention of an _instance_ of ios_base::Init in Standard.
5445 </p>
5446 <p><b>Proposed resolution:</b></p>
5447 <p>
5448 At the end of header &lt;iostream&gt; synopsis in 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>
5449 </p>
5450
5451 <pre>
5452        namespace std
5453        {
5454           ... extern istream cin; ...
5455 </pre>
5456
5457 <p>add the following lines</p>
5458
5459 <pre>
5460           namespace
5461           {
5462              ios_base::Init &lt;some_implementation_defined_name&gt;;
5463           }
5464         }
5465 </pre>
5466 <hr>
5467 <a name="370"><h3>370.&nbsp;Minor error in basic_istream::get</h3></a><p>
5468 <b>Section:</b>&nbsp;27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;15 Jul 2002</p>
5469 <p>Defect report for description of basic_istream::get (section 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), paragraph 15. The description for the get function
5470 with the following signature:</p>
5471
5472 <pre>
5473   basic_istream&lt;charT,traits&gt;&amp; get(basic_streambuf&lt;char_type,traits&gt;&amp;
5474   sb);
5475 </pre>
5476
5477 <p>is incorrect. It reads</p>
5478
5479 <blockquote>
5480   Effects: Calls get(s,n,widen('\n'))
5481 </blockquote>
5482
5483 <p>which I believe should be:</p>
5484
5485 <blockquote>
5486   Effects: Calls get(sb,widen('\n'))
5487 </blockquote>
5488 <p><b>Proposed resolution:</b></p>
5489 <p>Change the <b>Effects</b> paragraph to:</p>
5490 <blockquote>
5491   Effects: Calls get(sb,widen('\n'))
5492 </blockquote>
5493 <hr>
5494 <a name="371"><h3>371.&nbsp;Stability of multiset and multimap member functions</h3></a><p>
5495 <b>Section:</b>&nbsp;23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Frank Compagner&nbsp; <b>Date:</b>&nbsp;20 Jul 2002</p>
5496 <p>
5497 The requirements for multiset and multimap containers (23.1
5498 [lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
5499 23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
5500 the stability of the required (mutating) member functions. It appears
5501 the standard allows these functions to reorder equivalent elements of
5502 the container at will, yet the pervasive red-black tree implementation
5503 appears to provide stable behaviour.
5504 </p>
5505
5506 <p>This is of most concern when considering the behaviour of erase().
5507 A stability requirement would guarantee the correct working of the
5508 following 'idiom' that removes elements based on a certain predicate
5509 function.
5510 </p>
5511
5512 <pre>
5513   multimap&lt;int, int&gt; m;
5514   multimap&lt;int, int&gt;::iterator i = m.begin();
5515   while (i != m.end()) {
5516       if (pred(i))
5517           m.erase (i++);
5518       else
5519           ++i;
5520   }
5521 </pre>
5522
5523 <p>
5524 Although clause 23.1.2/8 guarantees that i remains a valid iterator
5525 througout this loop, absence of the stability requirement could
5526 potentially result in elements being skipped. This would make
5527 this code incorrect, and, furthermore, means that there is no way
5528 of erasing these elements without iterating first over the entire
5529 container, and second over the elements to be erased. This would
5530 be unfortunate, and have a negative impact on both performance and
5531 code simplicity.
5532 </p>
5533
5534 <p>
5535 If the stability requirement is intended, it should be made explicit
5536 (probably through an extra paragraph in clause 23.1.2).
5537 </p>
5538 <p>
5539 If it turns out stability cannot be guaranteed, i'd argue that a
5540 remark or footnote is called for (also somewhere in clause 23.1.2) to
5541 warn against relying on stable behaviour (as demonstrated by the code
5542 above).  If most implementations will display stable behaviour, any
5543 problems emerging on an implementation without stable behaviour will
5544 be hard to track down by users. This would also make the need for an
5545 erase_if() member function that much greater.
5546 </p>
5547
5548 <p>This issue is somewhat related to LWG issue <a href="lwg-closed.html#130">130</a>.</p>
5549 <p><b>Proposed resolution:</b></p>
5550 <hr>
5551 <a name="372"><h3>372.&nbsp;Inconsistent description of stdlib exceptions</h3></a><p>
5552 <b>Section:</b>&nbsp;17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>, 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a>, &nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Randy Maddox&nbsp; <b>Date:</b>&nbsp;22 Jul 2002</p>
5553
5554 <p>Paragraph 3 under clause 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>, Restrictions on
5555 Exception Handling, states that &quot;Any other functions defined in the
5556 C++ Standard Library that do not have an exception-specification may
5557 throw implementation-defined exceptions unless otherwise specified.&quot;
5558 This statement is followed by a reference to footnote 178 at the
5559 bottom of that page which states, apparently in reference to the C++
5560 Standard Library, that &quot;Library implementations are encouraged (but
5561 not required) to report errors by throwing exceptions from (or derived
5562 from) the standard exceptions.&quot;</p>
5563
5564 <p>These statements appear to be in direct contradiction to clause
5565 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a>, which states &quot;The class exception defines the
5566 base class for the types of objects thrown as exceptions by the C++
5567 Standard library components ...&quot;.</p>
5568
5569 <p>Is this inconsistent?</p>
5570
5571 <p><b>Proposed resolution:</b></p>
5572 <hr>
5573 <a name="373"><h3>373.&nbsp;Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</h3></a><p>
5574 <b>Section:</b>&nbsp;27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>, 27.6.2.5.1 <a href="lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Keith Baker&nbsp; <b>Date:</b>&nbsp;23 Jul 2002</p>
5575
5576 <p>
5577 In 27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> and 27.6.2.5.1 <a href="lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>
5578 (exception()&amp;badbit) != 0 is used in testing for rethrow, yet
5579 exception() is the constructor to class std::exception in 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> that has no return type. Should member function
5580 exceptions() found in 27.4.4 <a href="lib-iostreams.html#lib.ios"> [lib.ios]</a> be used instead?
5581 </p>
5582
5583 <p><b>Proposed resolution:</b></p>
5584 <p>
5585 </p>
5586 <hr>
5587 <a name="374"><h3>374.&nbsp;moneypunct::frac_digits returns int not unsigned</h3></a><p>
5588 <b>Section:</b>&nbsp;22.2.6.3.1 <a href="lib-locales.html#lib.locale.moneypunct.members"> [lib.locale.moneypunct.members]</a>, 22.2.6.3.2 <a href="lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;8 Aug 2002</p>
5589 <p>
5590 In section 22.2.6.3.1 <a href="lib-locales.html#lib.locale.moneypunct.members"> [lib.locale.moneypunct.members]</a>, frac_digits() returns type
5591 &quot;int&quot;. This implies that frac_digits() might return a negative value,
5592 but a negative value is nonsensical. It should return &quot;unsigned&quot;.
5593 </p>
5594
5595 <p>
5596 Similarly, in section 22.2.6.3.2 <a href="lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a>, do_frac_digits()
5597 should return &quot;unsigned&quot;.
5598 </p>
5599
5600 <p><b>Proposed resolution:</b></p>
5601 <hr>
5602 <a name="375"><h3>375.&nbsp;basic_ios should be ios_base in 27.7.1.3</h3></a><p>
5603 <b>Section:</b>&nbsp;27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
5604 <p>
5605 In Section 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>: Table 90, Table 91, and paragraph
5606 14 all contain references to &quot;basic_ios::&quot; which should be
5607 &quot;ios_base::&quot;.
5608 </p>
5609 <p><b>Proposed resolution:</b></p>
5610 <p>
5611 Change all references to &quot;basic_ios&quot; in Table 90, Table 91, and
5612 paragraph 14 to &quot;ios_base&quot;.
5613 </p>
5614 <hr>
5615 <a name="376"><h3>376.&nbsp;basic_streambuf semantics</h3></a><p>
5616 <b>Section:</b>&nbsp;27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
5617 <p>
5618 In Section 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, Table 90, the implication is that
5619 the four conditions should be mutually exclusive, but they are not.
5620 The first two cases, as written, are subcases of the third. I think it
5621 would be clearer if the conditions were rewritten as follows:
5622 </p>
5623
5624 <blockquote>
5625 <p>
5626   (which &amp; (ios_base::in|ios_base::out)) == ios_base::in
5627 </p>
5628
5629 <p>
5630   (which &amp; (ios_base::in|ios_base::out)) == ios_base::out
5631 </p>
5632
5633 <p>
5634   (which &amp; (ios_base::in|ios_base::out)) ==
5635 (ios_base::in|ios_base::out)
5636    and way == either ios_base::beg or ios_base::end
5637 </p>
5638
5639 <p>Otherwise</p>
5640 </blockquote>
5641
5642 <p>
5643 As written, it is unclear what should be the result if cases 1 &amp; 2
5644 are true, but case 3 is false, e.g.,
5645 </p>
5646
5647 <blockquote>
5648   seekoff(0, ios_base::cur, ios_base::in | ios_base::out)
5649 </blockquote>
5650
5651 <p><b>Proposed resolution:</b></p>
5652 <hr>
5653 <a name="377"><h3>377.&nbsp;basic_string::insert and length_error</h3></a><p>
5654 <b>Section:</b>&nbsp;21.3.5.4 <a href="lib-strings.html#lib.string::insert"> [lib.string::insert]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;16 Aug 2002</p>
5655 <p>
5656 Section 21.3.5.4 <a href="lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, paragraph 4, contains the following,
5657 &quot;Then throws length_error if size() &gt;= npos - rlen.&quot;
5658 </p>
5659
5660 <p>
5661 Related to DR 83, this sentence should probably be removed.
5662 </p>
5663 <p><b>Proposed resolution:</b></p>
5664 <hr>
5665 <a name="378"><h3>378.&nbsp;locale immutability and locale::operator=()</h3></a><p>
5666 <b>Section:</b>&nbsp;22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
5667 <p>
5668 I think there is a problem with 22.1.1, p6 which says that
5669 </p>
5670 <pre>
5671     -6- An instance of locale is immutable; once a facet reference
5672         is obtained from it, that reference remains usable as long
5673         as the locale value itself exists.
5674 </pre>
5675 <p>
5676 and 22.1.1.2, p4:
5677 </p>
5678 <pre>
5679     const locale&amp; operator=(const locale&amp; other) throw();
5680
5681     -4- Effects: Creates a copy of other, replacing the current value.
5682 </pre>
5683 <p>
5684 How can a reference to a facet obtained from a locale object remain
5685 valid after an assignment that clearly must replace all the facets
5686 in the locale object? Imagine a program such as this
5687 </p>
5688 <pre>
5689     std::locale loc (&quot;de_DE&quot;);
5690     const std::ctype&lt;char&gt; &amp;r0 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
5691     loc = std::locale (&quot;en_US&quot;);
5692     const std::ctype&lt;char&gt; &amp;r1 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
5693 </pre>
5694 <p>
5695 Is r0 really supposed to be preserved and destroyed only when loc goes
5696 out of scope?
5697 </p>
5698 <p><b>Proposed resolution:</b></p>
5699 <p>
5700 Suggest to replace 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>, p6 with
5701 </p>
5702 <pre>
5703     -6- Unless assigned a new value, locale objects are immutable;
5704         once a facet reference is obtained from it, that reference
5705         remains usable as long as the locale object itself exists
5706         or until the locale object is assigned the value of another,
5707         distinct locale object.
5708 </pre>
5709 <hr>
5710 <a name="379"><h3>379.&nbsp;nonsensical ctype::do_widen() requirement</h3></a><p>
5711 <b>Section:</b>&nbsp;22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
5712 <p>
5713 The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
5714 </p>
5715 <pre>
5716   charT do_widen (char c) const;
5717
5718   -11- Effects: Applies the simplest reasonable transformation from
5719        a char value or sequence of char values to the corresponding
5720        charT value or values. The only characters for which unique
5721        transformations are required are those in the basic source
5722        character set (2.2). For any named ctype category with a
5723        ctype&lt;charT&gt; facet ctw and valid ctype_base::mask value
5724        M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
5725 </pre>
5726 <p>
5727 Shouldn't the last sentence instead read
5728 </p>
5729 <pre>
5730        For any named ctype category with a ctype&lt;char&gt; facet ctc
5731        and valid ctype_base::mask value M
5732        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
5733 </pre>
5734 <p>
5735 I.e., if the narrow character c is not a member of a class of
5736 characters then neither is the widened form of c. (To paraphrase
5737 footnote 224.)
5738 </p>
5739 <p><b>Proposed resolution:</b></p>
5740 <p>
5741 Replace the last sentence of 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>, p11 with the
5742 following text:
5743 </p>
5744 <pre>
5745        For any named ctype category with a ctype&lt;char&gt; facet ctc
5746        and valid ctype_base::mask value M
5747        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
5748 </pre>
5749 <hr>
5750 <a name="380"><h3>380.&nbsp;typos in codecvt tables 53 and 54</h3></a><p>
5751 <b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
5752 <p>
5753 Tables 53 and 54 in 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> are both titled &quot;convert
5754 result values,&quot; when surely &quot;do_in/do_out result values&quot; must have
5755 been intended for Table 53 and &quot;do_unshift result values&quot; for Table
5756 54.
5757 </p>
5758 <p>
5759 Table 54, row 3 says that the meaning of partial is &quot;more characters
5760 needed to be supplied to complete termination.&quot; The function is not
5761 supplied any characters, it is given a buffer which it fills with
5762 characters or, more precisely, destination elements (i.e., an escape
5763 sequence). So partial means that space for more than (to_limit - to)
5764 destination elements was needed to terminate a sequence given the
5765 value of state.
5766 </p>
5767 <p><b>Proposed resolution:</b></p>
5768 <p>
5769 Change the title of Table 53 to &quot;do_in/do_out result values&quot; and
5770 the title of Table 54 to &quot;do_unshift result values.&quot;
5771 </p>
5772 <p>
5773 Change the text in Table 54, row 3, under the heading Meaning to
5774 &quot;space for more than (to_limit - to) destination elements was
5775 needed to terminate a sequence given the value of state.&quot;
5776 </p>
5777 <hr>
5778 <a name="381"><h3>381.&nbsp;detection of invalid mbstate_t in codecvt</h3></a><p>
5779 <b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
5780 <p>
5781 All but one codecvt member functions that take a state_type argument
5782 list as one of their preconditions that the state_type argument have
5783 a valid value. However, according to 22.2.1.5.2, p6,
5784 codecvt::do_unshift() is the only codecvt member that is supposed to
5785 return error if the state_type object is invalid.
5786 </p>
5787
5788 <p>
5789 It seems to me that the treatment of state_type by all codecvt member
5790 functions should be the same and the current requirements should be
5791 changed. Since the detection of invalid state_type values may be
5792 difficult in general or computationally expensive in some specific
5793 cases, I propose the following:
5794 </p>
5795 <p><b>Proposed resolution:</b></p>
5796 <p>
5797 Add a new paragraph before 22.2.1.5.2, p5, and after the function
5798 declaration below
5799 </p>
5800 <pre>
5801     result do_unshift(stateT&amp; state,
5802     externT* to, externT* to_limit, externT*&amp; to_next) const;
5803 </pre>
5804 <p>
5805 as follows:
5806 </p>
5807 <pre>
5808     Requires: (to &lt;= to_end) well defined and true; state initialized,
5809     if at the beginning of a sequence, or else equal to the result of
5810     converting the preceding characters in the sequence.
5811 </pre>
5812 <p>
5813 and change the text in Table 54, row 4, under the heading Meaning
5814 from
5815 </p>
5816 <pre>
5817     state has invalid value
5818 </pre>
5819 <p>
5820 to
5821 </p>
5822 <pre>
5823     an unspecified error has occurred
5824 </pre>
5825 <p>
5826 The return value of error should allow implementers to detect and
5827 report invalid state values but shouldn't require it, hence the
5828 word &quot;unspecified&quot; in the new wording.
5829 </p>
5830 <hr>
5831 <a name="382"><h3>382.&nbsp;codecvt do_in/out result</h3></a><p>
5832 <b>Section:</b>&nbsp;22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;30 Aug  2002</p>
5833 <p>
5834 It seems that the descriptions of codecvt do_in() and do_out() leave
5835 sufficient room for interpretation so that two implementations of
5836 codecvt may not work correctly with the same filebuf. Specifically,
5837 the following seems less than adequately specified:
5838 </p>
5839
5840 <ol>
5841 <li>
5842   the conditions under which the functions terminate
5843 </li>
5844 <li>
5845   precisely when the functions return ok
5846 </li>
5847 <li>
5848   precisely when the functions return partial
5849 </li>
5850 <li>
5851   the full set of conditions when the functions return error
5852 </li>
5853 </ol>
5854
5855 <ol>
5856 <li>
5857    22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p2 says this about the effects of the
5858    function: ...Stops if it encounters a character it cannot
5859    convert...  This assumes that there *is* a character to
5860    convert. What happens when there is a sequence that doesn't form a
5861    valid source character, such as an unassigned or invalid UNICODE
5862    character, or a sequence that cannot possibly form a character
5863    (e.g., the sequence &quot;\xc0\xff&quot; in UTF-8)?
5864 </li>
5865 <li>
5866    Table 53 says that the function returns codecvt_base::ok
5867    to indicate that the function(s) &quot;completed the conversion.&quot;
5868    Suppose that the source sequence is &quot;\xc0\x80&quot; in UTF-8,
5869    with from pointing to '\xc0' and (from_end==from + 1).
5870    It is not clear whether the return value should be ok
5871    or partial (see below).
5872 </li>
5873 <li>
5874    Table 53 says that the function returns codecvt_base::partial
5875    if &quot;not all source characters converted.&quot; With the from pointers
5876    set up the same way as above, it is not clear whether the return
5877    value should be partial or ok (see above).
5878 </li>
5879 <li>
5880    Table 53, in the row describing the meaning of error mistakenly
5881    refers to a &quot;from_type&quot; character, without the symbol from_type
5882    having been defined. Most likely, the word &quot;source&quot; character
5883    is intended, although that is not sufficient. The functions
5884    may also fail when they encounter an invalid source sequence
5885    that cannot possibly form a valid source character (e.g., as
5886    explained in bullet 1 above).
5887 </li>
5888 </ol>
5889 <p>
5890 Finally, the conditions described at the end of 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p4 don't seem to be possible:
5891 </p>
5892 <blockquote>
5893     &quot;A return value of partial, if (from_next == from_end),
5894     indicates that either the destination sequence has not
5895     absorbed all the available destination elements, or that
5896     additional source elements are needed before another
5897     destination element can be produced.&quot;
5898 </blockquote>
5899 <p>
5900 If the value is partial, it's not clear to me that (from_next
5901 ==from_end) could ever hold if there isn't enough room
5902 in the destination buffer. In order for (from_next==from_end) to
5903 hold, all characters in that range must have been successfully
5904 converted (according to 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p2) and since there are no
5905 further source characters to convert, no more room in the
5906 destination buffer can be needed.
5907 </p>
5908 <p>
5909 It's also not clear to me that (from_next==from_end) could ever
5910 hold if additional source elements are needed to produce another
5911 destination character (not element as incorrectly stated in the
5912 text). partial is returned if &quot;not all source characters have
5913 been converted&quot; according to Table 53, which also implies that
5914 (from_next==from) does NOT hold.
5915 </p>
5916 <p>
5917 Could it be that the intended qualifying condition was actually
5918 (from_next != from_end), i.e., that the sentence was supposed
5919 to read
5920 </p>
5921 <blockquote>
5922     &quot;A return value of partial, if (from_next != from_end),...&quot;
5923 </blockquote>
5924 <p>
5925 which would make perfect sense, since, as far as I understand it,
5926 partial can only occur if (from_next != from_end)?
5927 </p>
5928 <p><b>Proposed resolution:</b></p>
5929 <p>
5930 To address these issues, I propose that paragraphs 2, 3, and 4
5931 be rewritten as follows. The proposal incorporates the accepted
5932 resolution of lwg issue 19.
5933 </p>
5934 <pre>
5935 -2- Effects: Converts characters in the range of source elements
5936     [from, from_end), placing the results in sequential positions
5937     starting at destination to. Converts no more than (from_end&shy;from)
5938     source elements, and stores no more than (to_limit&shy;to)
5939     destination elements.
5940
5941     Stops if it encounters a sequence of source elements it cannot
5942     convert to a valid destination character. It always leaves the
5943     from_next and to_next pointers pointing one beyond the last
5944     element successfully converted.
5945
5946     [Note: If returns noconv, internT and externT are the same type
5947     and the converted sequence is identical to the input sequence
5948     [from, from_next). to_next is set equal to to, the value of
5949     state is unchanged, and there are no changes to the values in
5950     [to, to_limit). --end note]
5951
5952 -3- Notes: Its operations on state are unspecified.
5953     [Note: This argument can be used, for example, to maintain shift
5954     state, to specify conversion options (such as count only), or to
5955     identify a cache of seek offsets. --end note]
5956
5957 -4- Returns: An enumeration value, as summarized in Table 53:
5958
5959     Table 53 -- do_in/do_out result values
5960
5961      Value      Meaning
5962     +---------+----------------------------------------------------+
5963     | ok      | successfully completed the conversion of all       |
5964     |         | complete characters in the source range            |
5965     +---------+----------------------------------------------------+
5966     | partial | the characters in the source range would, after    |
5967     |         | conversion, require space greater than that        |
5968     |         | available in the destination range                 |
5969     +---------+----------------------------------------------------+
5970     | error   | encountered either a sequence of elements in the   |
5971     |         | source range forming a valid source character that |
5972     |         | could not be converted to a destination character, |
5973     |         | or a sequence of elements in the source range that |
5974     |         | could not possibly form a valid source character   |
5975     +---------+----------------------------------------------------+
5976     | noconv  | internT and externT are the same type, and input   |
5977     |         | sequence is identical to converted sequence        |
5978     +---------+----------------------------------------------------+
5979
5980     A return value of partial, i.e., if (from_next != from_end),
5981     indicates that either the destination sequence has not absorbed
5982     all the available destination elements, or that additional
5983     source elements are needed before another destination character
5984     can be produced.
5985 </pre>
5986 <p>----- End of document -----</p>
5987 </body>
5988 </html>