gnu/dist/gcc4/libstdc++-v3/docs/html/ext/lwg-active.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
   2 <html><head><title>C++ Standard Library Active Issues List</title></head>
   3
   4 <body bgcolor="#ffffff" text="#000000">
   5 <table>
   6 <tbody><tr>
   7 <td align="left">Doc. no.</td>
   8 <td align="left">N1908=05-0168</td>
   9 </tr>
  10 <tr>
  11 <td align="left">Date:</td>
  12 <td align="left">2005-10-23</td>
  13 </tr>
  14 <tr>
  15 <td align="left">Project:</td>
  16 <td align="left">Programming Language C++</td>
  17 </tr>
  18 <tr>
  19 <td align="left">Reply to:</td>
  20 <td align="left">Howard Hinnant &lt;howard.hinnant@gmail.com&gt;</td>
  21 </tr>
  22 </tbody></table>
  23 <h1>C++ Standard Library Active Issues List (Revision R39)</h1>
  24   <p>Reference ISO/IEC IS 14882:1998(E)</p>
  25   <p>Also see:</p>
  26   <ul>
  27       <li>
  28 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
  29       <li>
  30 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
  31       <li>
  32 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
  33       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li>
  34       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
  35   </ul>
  36   <p>The purpose of this document is to record the status of issues
  37   which have come before the Library Working Group (LWG) of the ANSI
  38   (J16) and ISO (WG21) C++ Standards Committee. Issues represent
  39   potential defects in the ISO/IEC IS 14882:1998(E) document.  Issues
  40   are not to be used to request new features. </p>
  41
  42   <p>This document contains only library issues which are actively being
  43   considered by the Library Working Group. That is, issues which have a
  44   status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>,
  45   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>. See
  46   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered defects and
  47   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</p>
  48
  49   <p>The issues in these lists are not necessarily formal ISO Defect
  50   Reports (DR's). While some issues will eventually be elevated to
  51   official Defect Report status, other issues will be disposed of in
  52   other ways. See <a href="#Status">Issue Status</a>.</p>
  53
  54   <p>This document is in an experimental format designed for both
  55   viewing via a world-wide web browser and hard-copy printing. It
  56   is available as an HTML file for browsing or PDF file for
  57   printing.</p>
  58
  59   <p>Prior to Revision 14, library issues lists existed in two slightly
  60   different versions; a Committee Version and a Public
  61   Version. Beginning with Revision 14 the two versions were combined
  62   into a single version.</p>
  63
  64   <p>This document includes <i>[bracketed italicized notes]</i> as a
  65   reminder to the LWG of current progress on issues. Such notes are
  66   strictly unofficial and should be read with caution as they may be
  67   incomplete or incorrect. Be aware that LWG support for a particular
  68   resolution can quickly change if new viewpoints or killer examples are
  69   presented in subsequent discussions.</p>
  70
  71   <p>For the most current official version of this document see
  72   <a href="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21/</a>.
  73   Requests for further information about this document should include
  74   the document number above, reference ISO/IEC 14882:1998(E), and be
  75   submitted to Information Technology Industry Council (ITI), 1250 Eye
  76   Street NW, Washington, DC 20005.</p>
  77
  78   <p>Public information as to how to obtain a copy of the C++ Standard,
  79   join the standards committee, submit an issue, or comment on an issue
  80   can be found in the comp.std.c++ FAQ.
  81   Public discussion of C++ Standard related issues occurs on <a href="news://comp.std.c++/">news:comp.std.c++</a>.
  82   </p>
  83
  84  <p>For committee members, files available on the committee's private
  85   web site include the HTML version of the Standard itself. HTML
  86   hyperlinks from this issues list to those files will only work for
  87   committee members who have downloaded them into the same disk
  88   directory as the issues list files.  </p>
  89 <h2>Revision History</h2>
  90 <ul>
  91 <li>R39:
  92 2005-10-14 post-Mont Tremblant mailing.
  93 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#528">528</a>.
  94 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
  95 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#497">497</a> from Review to Ready.
  96 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#514">514</a> from New to Open.
  97 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#519">519</a> from New to Ready.
  98 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
  99 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
 100 </li>
 101 <li>R38:
 102 2005-07-03 pre-Mont Tremblant mailing.
 103 Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
 104 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>
 105 </li>
 106 <li>R37:
 107 2005-06 mid-term mailing.
 108 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>.
 109 </li>
 110 <li>R36:
 111 2005-04 post-Lillehammer mailing. All issues in "ready" status except
 112 for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a> were moved to "DR" status, and all issues
 113 previously in "DR" status were moved to "WP".
 114 </li>
 115 <li>R35:
 116 2005-03 pre-Lillehammer mailing.
 117 </li>
 118 <li>R34:
 119 2005-01 mid-term mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
 120 </li>
 121 <li>R33:
 122 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
 123 </li>
 124 <li>R32:
 125 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
 126 new issues received after the 2004-07 mailing.  Added
 127 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>.
 128 </li>
 129 <li>R31:
 130 2004-07 mid-term mailing: reflects new proposed resolutions and
 131 new issues received after the post-Sydney mailing.  Added
 132 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#478">478</a>.
 133 </li>
 134 <li>R30:
 135 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 136 Voted all "Ready" issues from R29 into the working paper.
 137 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>.
 138 </li>
 139 <li>R29:
 140 Pre-Sydney mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>.
 141 </li>
 142 <li>R28:
 143 Post-Kona mailing: reflects decisions made at the Kona meeting.
 144 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#440">440</a>.
 145 </li>
 146 <li>R27:
 147 Pre-Kona mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
 148 </li>
 149 <li>R26:
 150 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
 151 All issues in Ready status were voted into DR status.  All issues in
 152 DR status were voted into WP status.
 153 </li>
 154 <li>R25:
 155 Pre-Oxford mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>.
 156 </li>
 157 <li>R24:
 158 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
 159 meeting.  All Ready issues from R23 with the exception of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, which has been given a new proposed resolution, were
 160 moved to DR status.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>.  (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
 161 at the meeting.)  Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining
 162 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
 163 </li>
 164 <li>R23:
 165 Pre-Santa Cruz mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#367">367</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#382">382</a>.
 166 Moved issues in the TC to TC status.
 167 </li>
 168 <li>R22:
 169 Post-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>.
 170 </li>
 171 <li>R21:
 172 Pre-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>.
 173 </li>
 174 <li>R20:
 175 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 176 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, of which issues
 177 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a> were added since Redmond, hence
 178 not discussed at the meeting.
 179
 180 All Ready issues were moved to DR status, with the exception of issues
 181 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
 182
 183 Noteworthy issues discussed at Redmond include
 184 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#233">233</a>,
 185 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.
 186 </li>
 187 <li>R19:
 188 Pre-Redmond mailing.  Added new issues
 189 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>.
 190 </li>
 191 <li>R18:
 192 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
 193 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, and discussed
 194 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>.
 195
 196 Changed status of issues
 197 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>
 198 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a>
 199 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>
 200 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a>
 201 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a>
 202 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>
 203 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
 204 to DR.
 205
 206 Changed status of issues
 207 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>
 208 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>
 209 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>
 210 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>
 211 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a>
 212 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a>
 213 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a>
 214 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a>
 215 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>
 216 to Ready.
 217
 218 Closed issues
 219 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a>
 220 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#289">289</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#293">293</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#302">302</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#313">313</a>
 221 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
 222 as NAD.
 223
 224 </li>
 225 <li>R17:
 226 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 227 resolutions for issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
 228 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>.
 229 </li>
 230 <li>R16:
 231 post-Toronto mailing; reflects actions taken in Toronto. Added new
 232 issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a>.  Changed status of issues
 233 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>,
 234 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>,
 235 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>,
 236 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>,
 237 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>,
 238 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>,
 239 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>,
 240 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>,
 241 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>,
 242 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>,
 243 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>,
 244 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>,
 245 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR".  Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>. Reopened
 246 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#2">2</a> and
 247 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>. Fixed
 248 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
 249 appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix
 250 the bug in enough places.
 251 </li>
 252 <li>R15:
 253 pre-Toronto mailing. Added issues
 254 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#233">233</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>. Some small HTML formatting
 255 changes so that we pass Weblint tests.
 256 </li>
 257 <li>R14:
 258 post-Tokyo II mailing; reflects committee actions taken in
 259 Tokyo. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>. (00-0019R1/N1242)
 260 </li>
 261 <li>R13:
 262 pre-Tokyo II updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.
 263 </li>
 264 <li>R12:
 265 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
 266 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
 267 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
 268 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
 269 </li>
 270 <li>R11:
 271 post-Kona mailing: Updated to reflect LWG and full committee actions
 272 in Kona (99-0048/N1224). Note changed resolution of issues
 273 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a>
 274 to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
 275 "closed" documents.  Changed the proposed resolution of issue
 276 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
 277 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
 278 </li>
 279 <li>R10:
 280 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 281 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>,
 282 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a> to
 283 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 284 </li>
 285 <li>R9:
 286 pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
 287 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
 288 "closed" documents. (99-0030/N1206, 25 Aug 99)
 289 </li>
 290 <li>R8:
 291 post-Dublin mailing. Updated to reflect LWG and full committee actions
 292 in Dublin. (99-0016/N1193, 21 Apr 99)
 293 </li>
 294 <li>R7:
 295 pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>,
 296 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>,
 297 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>,
 298 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
 299 </li>
 300 <li>R6:
 301 pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>,
 302 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 303 </li>
 304 <li>R5:
 305 update issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>; added issues
 306 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>. Format revisions to prepare
 307 for making list public. (30 Dec 98)
 308 </li>
 309 <li>R4:
 310 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
 311 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
 312 issues corrected. (22 Oct 98)
 313 </li>
 314 <li>R3:
 315 post-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#94">94</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>
 316 added, many issues updated to reflect LWG consensus (12 Oct 98)
 317 </li>
 318 <li>R2:
 319 pre-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#93">93</a> added,
 320 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
 321 </li>
 322 <li>R1:
 323 Correction to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a> resolution, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> code
 324 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
 325 </li>
 326 </ul>
 327 <h2>
 328 <a name="Status"></a>Issue Status</h2>
 329   <p><b><a name="New">New</a></b> - The issue has not yet been
 330   reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a
 331   suggestion from the issue submitter, and should not be construed as
 332   the view of LWG.</p>
 333
 334   <p><b><a name="Open">Open</a></b> - The LWG has discussed the issue
 335   but is not yet ready to move the issue forward. There are several
 336   possible reasons for open status:</p>
 337      <ul>
 338         <li>Consensus may have not yet have been reached as to how to deal
 339             with the issue.</li>
 340         <li>Informal consensus may have been reached, but the LWG awaits
 341             exact <b>Proposed Resolution</b> wording for review.</li>
 342         <li>The LWG wishes to consult additional technical experts before
 343             proceeding.</li>
 344         <li>The issue may require further study.</li>
 345      </ul>
 346
 347   <p>A <b>Proposed Resolution</b> for an open issue is still not be
 348   construed as the view of LWG. Comments on the current state of
 349   discussions are often given at the end of open issues in an italic
 350   font. Such comments are for information only and should not be given
 351   undue importance.</p>
 352
 353   <p><b><a name="Dup">Dup</a></b> - The LWG has reached consensus that
 354   the issue is a duplicate of another issue, and will not be further
 355   dealt with. A <b>Rationale</b> identifies the duplicated issue's
 356   issue number.  </p>
 357
 358   <p><b><a name="NAD">NAD</a></b> - The LWG has reached consensus that
 359   the issue is not a defect in the Standard, and the issue is ready to
 360   forward to the full committee as a proposed record of response. A
 361   <b>Rationale</b> discusses the LWG's reasoning.</p>
 362
 363   <p><b><a name="Review">Review</a></b> - Exact wording of a
 364   <b>Proposed Resolution</b> is now available for review on an issue
 365   for which the LWG previously reached informal consensus.</p>
 366
 367   <p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus
 368   that the issue is a defect in the Standard, the <b>Proposed
 369   Resolution</b> is correct, and the issue is ready to forward to the
 370   full committee for further action as a Defect Report (DR).</p>
 371
 372   <p><b><a name="DR">DR</a></b> - (Defect Report) - The full J16
 373   committee has voted to forward the issue to the Project Editor to be
 374   processed as a Potential Defect Report. The Project Editor reviews
 375   the issue, and then forwards it to the WG21 Convenor, who returns it
 376   to the full committee for final disposition. This issues list
 377   accords the status of DR to all these Defect Reports regardless of
 378   where they are in that process.</p>
 379
 380   <p><b><a name="TC">TC</a></b> - (Technical Corrigenda) - The full
 381   WG21 committee has voted to accept the Defect Report's Proposed
 382   Resolution as a Technical Corrigenda.  Action on this issue is thus
 383   complete and no further action is possible under ISO rules.</p>
 384
 385   <p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed
 386   resolution has not been accepted as a Technical Corrigendum, but
 387   the full WG21 committee has voted to apply the Defect Report's Proposed
 388   Resolution to the working paper.</p>
 389
 390   <p><b><a name="RR">RR</a></b> - (Record of Response) - The full WG21
 391   committee has determined that this issue is not a defect in the
 392   Standard. Action on this issue is thus complete and no further
 393   action is possible under ISO rules.</p>
 394
 395   <p><b><a name="Future">Future</a></b> - In addition to the regular
 396   status, the LWG believes that this issue should be revisited at the
 397   next revision of the standard.  It is usually paired with NAD.</p>
 398
 399   <p>Issues are always given the status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> when
 400   they first appear on the issues list. They may progress to
 401   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> while the LWG
 402   is actively working on them. When the LWG has reached consensus on
 403   the disposition of an issue, the status will then change to
 404   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>, or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> as appropriate.  Once the full J16 committee votes to
 405   forward Ready issues to the Project Editor, they are given the
 406   status of Defect Report ( <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>). These in turn may
 407   become the basis for Technical Corrigenda (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>),
 408   or are closed without action other than a Record of Response
 409   (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a> ). The intent of this LWG process is that
 410   only issues which are truly defects in the Standard move to the
 411   formal ISO DR status.
 412   </p>
 413
 414 <h2>Active Issues</h2>
 415 <hr>
 416 <a name="23"><h3>23.&nbsp;Num_get overflow result</h3></a><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 417 <p>The current description of numeric input does not account for the
 418 possibility of overflow. This is an implicit result of changing the
 419 description to rely on the definition of scanf() (which fails to
 420 report overflow), and conflicts with the documented behavior of
 421 traditional and current implementations. </p>
 422
 423 <p>Users expect, when reading a character sequence that results in a
 424 value unrepresentable in the specified type, to have an error
 425 reported. The standard as written does not permit this. </p>
 426
 427 <p><b>Further comments from Dietmar:</b></p>
 428
 429 <p>
 430 I don't feel comfortable with the proposed resolution to issue 23: It
 431 kind of simplifies the issue to much. Here is what is going on:
 432 </p>
 433
 434 <p>
 435 Currently, the behavior of numeric overflow is rather counter intuitive
 436 and hard to trace, so I will describe it briefly:
 437 </p>
 438
 439 <ul>
 440   <li>
 441     According to 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>
 442     paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
 443     return an input error; otherwise a value is converted to the rules
 444     of <tt>scanf</tt>.
 445   </li>
 446   <li>
 447     <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>.
 448   </li>
 449   <li>
 450     <tt>fscanf()</tt> returns an input failure if during conversion no
 451     character matching the conversion specification could be extracted
 452     before reaching EOF. This is the only reason for <tt>fscanf()</tt>
 453     to fail due to an input error and clearly does not apply to the case
 454     of overflow.
 455   </li>
 456   <li>
 457     Thus, the conversion is performed according to the rules of
 458     <tt>fscanf()</tt> which basically says that <tt>strtod</tt>,
 459     <tt>strtol()</tt>, etc. are to be used for the conversion.
 460   </li>
 461   <li>
 462     The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as
 463     many matching characters as there are and on overflow continue to
 464     consume matching characters but also return a value identical to
 465     the maximum (or minimum for signed types if there was a leading minus)
 466     value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>.
 467   </li>
 468   <li>
 469     Thus, according to the current wording in the standard, overflows
 470     can be detected! All what is to be done is to check <tt>errno</tt>
 471     after reading an element and, of course, clearing <tt>errno</tt>
 472     before trying a conversion. With the current wording, it can be
 473     detected whether the overflow was due to a positive or negative
 474     number for signed types.
 475   </li>
 476 </ul>
 477
 478 <p><b>Further discussion from Redmond:</b></p>
 479
 480 <p>The basic problem is that we've defined our behavior,
 481 including our error-reporting behavior, in terms of C90.  However,
 482 C90's method of reporting overflow in scanf is not technically an
 483 "input error".  The <tt>strto_*</tt> functions are more precise.</p>
 484
 485 <p>There was general consensus that <tt>failbit</tt> should be set
 486 upon overflow.  We considered three options based on this:</p>
 487 <ol>
 488 <li>Set failbit upon conversion error (including overflow), and
 489     don't store any value.</li>
 490 <li>Set failbit upon conversion error, and also set <tt>errno</tt> to
 491     indicated the precise nature of the error.</li>
 492 <li>Set failbit upon conversion error.  If the error was due to
 493     overflow, store +-numeric_limits&lt;T&gt;::max() as an
 494     overflow indication.</li>
 495 </ol>
 496
 497 <p>Straw poll: (1) 5; (2) 0; (3) 8.</p>
 498
 499
 500 <p><b>Proposed resolution:</b></p>
 501
 502 <p>Discussed at Lillehammer.  General outline of what we want the
 503   solution to look like: we want to say that overflow is an error, and
 504   provide a way to distinguish overflow from other kinds of errors.
 505   Choose candidate field the same way scanf does, but don't describe
 506   the rest of the process in terms of format.  If a finite input field
 507   is too large (positive or negative) to be represented as a finite
 508   value, then set failbit and assign the nearest representable value.
 509   Bill will provide wording.</p>
 510
 511 <hr>
 512 <a name="96"><h3>96.&nbsp;Vector&lt;bool&gt; is not a container</h3></a><p><b>Section:</b>&nbsp;23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
 513 <p><tt>vector&lt;bool&gt;</tt> is not a container as its reference and
 514 pointer types are not references and pointers. </p>
 515
 516 <p>Also it forces everyone to have a space optimization instead of a
 517 speed one.</p>
 518
 519 <p><b>See also:</b> 99-0008 == N1185 Vector&lt;bool&gt; is
 520 Nonconforming, Forces Optimization Choice.</p>
 521 <p><b>Proposed resolution:</b></p>
 522
 523 <p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>
 524
 525 <p><i>[In Dublin many present felt that failure to meet Container
 526 requirements was a defect. There was disagreement as to whether
 527 or not the optimization requirements constituted a defect.]</i></p>
 528
 529 <p><i>[The LWG looked at the following resolutions in some detail:
 530 <br>
 531 &nbsp;&nbsp;&nbsp;&nbsp; * Not A Defect.<br>
 532 &nbsp;&nbsp;&nbsp;&nbsp; * Add a note explaining that vector&lt;bool&gt; does not meet
 533 Container requirements.<br>
 534 &nbsp;&nbsp;&nbsp;&nbsp; * Remove vector&lt;bool&gt;.<br>
 535 &nbsp;&nbsp;&nbsp;&nbsp; * Add a new category of container requirements which
 536 vector&lt;bool&gt; would meet.<br>
 537 &nbsp;&nbsp;&nbsp;&nbsp; * Rename vector&lt;bool&gt;.<br>
 538 <br>
 539 No alternative had strong, wide-spread, support and every alternative
 540 had at least one "over my dead body" response.<br>
 541 <br>
 542 There was also mention of a transition scheme something like (1) add
 543 vector_bool and deprecate vector&lt;bool&gt; in the next standard. (2)
 544 Remove vector&lt;bool&gt; in the following standard.]</i></p>
 545
 546 <p><i>[Modifying container requirements to permit returning proxies
 547 (thus allowing container requirements conforming vector&lt;bool&gt;)
 548 was also discussed.]</i></p>
 549
 550 <p><i>[It was also noted that there is a partial but ugly workaround in
 551 that vector&lt;bool&gt; may be further specialized with a customer
 552 allocator.]</i></p>
 553
 554 <p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
 555 vector&lt;bool&gt;: More Problems, Better Solutions. Much discussion
 556 of a two step approach: a) deprecate, b) provide replacement under a
 557 new name.  LWG straw vote on that: 1-favor, 11-could live with, 2-over
 558 my dead body.  This resolution was mentioned in the LWG report to the
 559 full committee, where several additional committee members indicated
 560 over-my-dead-body positions.]</i></p>
 561
 562 <p>Discussed at Lillehammer.  General agreement that we should
 563   deprecate vector&lt;bool&gt; and introduce this functionality under
 564   a different name, e.g. bit_vector.  This might make it possible to
 565   remove the vector&lt;bool&gt; specialization in the standard that comes
 566   after C++0x. There was also a suggestion that
 567   in C++0x we could additional say that it's implementation defined
 568   whether vector&lt;bool&gt; refers to the specialization or to the
 569   primary template, but there wasn't general agreement that this was a
 570   good idea.</p>
 571
 572 <p>We need a paper for the new bit_vector class.</p>
 573
 574 <hr>
 575 <a name="201"><h3>201.&nbsp;Numeric limits terminology wrong</h3></a><p><b>Section:</b>&nbsp;18.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.limits"> [lib.limits]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Stephen Cleary&nbsp; <b>Date:</b>&nbsp;21 Dec 1999</p>
 576 <p>
 577 In some places in this section, the terms "fundamental types" and
 578 "scalar types" are used when the term "arithmetic types" is intended.
 579 The current usage is incorrect because void is a fundamental type and
 580 pointers are scalar types, neither of which should have
 581 specializations of numeric_limits.
 582 </p>
 583 <p><b>Proposed resolution:</b></p>
 584 <p><i>[Lillehammer: it remains true that numeric_limits is using
 585   imprecise language. However, none of the proposals for changed
 586   wording are clearer.  A redesign of numeric_limits is needed, but this
 587   is more a task than an open issue.]</i></p>
 588 <hr>
 589 <a name="233"><h3>233.&nbsp;Insertion hints in associative containers</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;30 Apr 2000</p>
 590 <p>
 591 If <tt>mm</tt> is a multimap and <tt>p</tt> is an iterator
 592 into the multimap, then <tt>mm.insert(p, x)</tt> inserts
 593 <tt>x</tt> into <tt>mm</tt> with <tt>p</tt> as a hint as
 594 to where it should go.  Table 69 claims that the execution time is
 595 amortized constant if the insert winds up taking place adjacent to
 596 <tt>p</tt>, but does not say when, if ever, this is guaranteed to
 597 happen.  All it says it that <tt>p</tt> is a hint as to where to
 598 insert.
 599 </p>
 600 <p>
 601 The question is whether there is any guarantee about the relationship
 602 between <tt>p</tt> and the insertion point, and, if so, what it
 603 is.
 604 </p>
 605 <p>
 606 I believe the present state is that there is no guarantee: The user
 607 can supply <tt>p</tt>, and the implementation is allowed to
 608 disregard it entirely.
 609 </p>
 610
 611 <p><b>Additional comments from Nathan:</b><br>
 612
 613 The vote [in Redmond] was on whether to elaborately specify the use of
 614 the hint, or to require behavior only if the value could be inserted
 615 adjacent to the hint.  I would like to ensure that we have a chance to
 616 vote for a deterministic treatment: "before, if possible, otherwise
 617 after, otherwise anywhere appropriate", as an alternative to the
 618 proposed "before or after, if possible, otherwise [...]".
 619 </p>
 620
 621
 622 <p><b>Proposed resolution:</b></p>
 623
 624 <p>In table 69 "Associative Container Requirements" in 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in the row for <tt>a.insert(p, t)</tt>,
 625 change</p>
 626
 627 <blockquote>
 628 iterator p is a hint pointing to where the insert
 629 should start to search.
 630 </blockquote>
 631
 632 <p>to</p>
 633
 634 <blockquote>
 635 insertion adjacent to iterator p is preferred if
 636 more than one insertion point is valid.
 637 </blockquote>
 638
 639 <p>and change</p>
 640
 641 <blockquote>
 642 logarithmic in general, but amortized constant if
 643 t is inserted right after p.
 644 </blockquote>
 645
 646 <p>to</p>
 647
 648 <blockquote>
 649 logarithmic in general, but amortized constant if
 650 t is inserted adjacent to iterator p.
 651 </blockquote>
 652
 653 <p><i>[Toronto: there was general agreement that this is a real defect:
 654 when inserting an element x into a multiset that already contains
 655 several copies of x, there is no way to know whether the hint will be
 656 used.  The proposed resolution was that the new element should always
 657 be inserted as close to the hint as possible.  So, for example, if
 658 there is a subsequence of equivalent values, then providing a.begin()
 659 as the hint means that the new element should be inserted before the
 660 subsequence even if a.begin() is far away.  JC van Winkel supplied
 661 precise wording for this proposed resolution, and also for an
 662 alternative resolution in which hints are only used when they are
 663 adjacent to the insertion point.]</i></p>
 664
 665 <p><i>[Copenhagen: the LWG agreed to the original proposed resolution,
 666 in which an insertion hint would be used even when it is far from the
 667 insertion point.  This was contingent on seeing a reference
 668 implementation showing that it is possible to implement this
 669 requirement without loss of efficiency.  John Potter provided such a
 670 reference implementation.]</i></p>
 671
 672 <p><i>[Redmond: The LWG was reluctant to adopt the proposal that
 673 emerged from Copenhagen: it seemed excessively complicated, and went
 674 beyond fixing the defect that we identified in Toronto.  PJP provided
 675 the new wording described in this issue.  Nathan agrees that we
 676 shouldn't adopt the more detailed semantics, and notes: "we know that
 677 you can do it efficiently enough with a red-black tree, but there are
 678 other (perhaps better) balanced tree techniques that might differ
 679 enough to make the detailed semantics hard to satisfy."]</i></p>
 680
 681 <p><i>[Curaçao: Nathan should give us the alternative wording he
 682 suggests so the LWG can decide between the two options.]</i></p>
 683
 684 <p><i>[Lillehammer: The LWG previously rejected the more detailed
 685   semantics, because it seemed more loike a new feature than like
 686   defect fixing.  We're now more sympathetic to it, but we (especially
 687   Bill) are still worried about performance.  N1780 describes a naive
 688   algorithm, but it's not clear whether there is a non-naive
 689   implementation. Is it possible to implement this as efficently as
 690   the current version of insert?]</i></p>
 691
 692 <p><i>[Post Lillehammer:  N1780 updated in post meeting mailing with
 693 feedback from Lillehammer with more information regarding performance.
 694 ]</i></p>
 695
 696 <hr>
 697 <a name="247"><h3>247.&nbsp;<tt>vector</tt>, <tt>deque::insert</tt> complexity</h3></a><p><b>Section:</b>&nbsp;23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;06 June 2000</p>
 698 <p>Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity
 699 of <tt>vector::insert</tt>:</p>
 700
 701    <blockquote>
 702    Complexity: If first and last are forward iterators, bidirectional
 703    iterators, or random access iterators, the complexity is linear in
 704    the number of elements in the range [first, last) plus the distance
 705    to the end of the vector. If they are input iterators, the complexity
 706    is proportional to the number of elements in the range [first, last)
 707    times the distance to the end of the vector.
 708    </blockquote>
 709
 710 <p>First, this fails to address the non-iterator forms of
 711 <tt>insert</tt>.</p>
 712
 713 <p>Second, the complexity for input iterators misses an edge case --
 714 it requires that an arbitrary number of elements can be added at
 715 the end of a <tt>vector</tt> in constant time.</p>
 716
 717 <p>I looked to see if <tt>deque</tt> had a similar problem, and was
 718 surprised to find that <tt>deque</tt> places no requirement on the
 719 complexity of inserting multiple elements (23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>,
 720 paragraph 3):</p>
 721
 722    <blockquote>
 723    Complexity: In the worst case, inserting a single element into a
 724    deque takes time linear in the minimum of the distance from the
 725    insertion point to the beginning of the deque and the distance
 726    from the insertion point to the end of the deque. Inserting a
 727    single element either at the beginning or end of a deque always
 728    takes constant time and causes a single call to the copy constructor
 729    of T.
 730    </blockquote>
 731 <p><b>Proposed resolution:</b></p>
 732
 733 <p>Change Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] to</p>
 734    <blockquote>
 735    Complexity: The complexity is linear in the number of elements
 736    inserted plus the distance to the end of the vector.
 737    </blockquote>
 738
 739    <p><i>[For input iterators, one may achieve this complexity by first
 740    inserting at the end of the <tt>vector</tt>, and then using
 741    <tt>rotate</tt>.]</i></p>
 742
 743 <p>Change 23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>, paragraph 3, to:</p>
 744
 745    <blockquote>
 746    Complexity: The complexity is linear in the number of elements
 747    inserted plus the shorter of the distances to the beginning and
 748    end of the deque.  Inserting a single element at either the
 749    beginning or the end of a deque causes a single call to the copy
 750    constructor of T.
 751    </blockquote>
 752
 753 <p><b>Rationale:</b></p>
 754 <p>This is a real defect, and proposed resolution fixes it: some
 755   complexities aren't specified that should be.  This proposed
 756   resolution does constrain deque implementations (it rules out the
 757   most naive possible implementations), but the LWG doesn't see a
 758   reason to permit that implementation.</p>
 759 <hr>
 760 <a name="254"><h3>254.&nbsp;Exception types in clause 19 are constructed from <tt>std::string</tt>
 761 </h3></a><p><b>Section:</b>&nbsp;19.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.std.exceptions"> [lib.std.exceptions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Aug 2000</p>
 762 <p>
 763 Many of the standard exception types which implementations are
 764 required to throw are constructed with a const std::string&amp;
 765 parameter. For example:
 766 </p>
 767
 768 <pre>     19.1.5  Class out_of_range                          [lib.out.of.range]
 769      namespace std {
 770        class out_of_range : public logic_error {
 771        public:
 772          explicit out_of_range(const string&amp; what_arg);
 773        };
 774      }
 775
 776    1 The class out_of_range defines the type of objects  thrown  as  excep-
 777      tions to report an argument value not in its expected range.
 778
 779      out_of_range(const string&amp; what_arg);
 780
 781      Effects:
 782        Constructs an object of class out_of_range.
 783      Postcondition:
 784        strcmp(what(), what_arg.c_str()) == 0.
 785 </pre>
 786
 787 <p>
 788 There are at least two problems with this:
 789 </p>
 790 <ol>
 791 <li>A program which is low on memory may end up throwing
 792 std::bad_alloc instead of out_of_range because memory runs out while
 793 constructing the exception object.</li>
 794 <li>An obvious implementation which stores a std::string data member
 795 may end up invoking terminate() during exception unwinding because the
 796 exception object allocates memory (or rather fails to) as it is being
 797 copied.</li>
 798 </ol>
 799
 800 <p>
 801 There may be no cure for (1) other than changing the interface to
 802 out_of_range, though one could reasonably argue that (1) is not a
 803 defect. Personally I don't care that much if out-of-memory is reported
 804 when I only have 20 bytes left, in the case when out_of_range would
 805 have been reported. People who use exception-specifications might care
 806 a lot, though.
 807 </p>
 808
 809 <p>
 810 There is a cure for (2), but it isn't completely obvious. I think a
 811 note for implementors should be made in the standard. Avoiding
 812 possible termination in this case shouldn't be left up to chance.  The
 813 cure is to use a reference-counted "string" implementation
 814 in the exception object. I am not necessarily referring to a
 815 std::string here; any simple reference-counting scheme for a NTBS
 816 would do.
 817 </p>
 818
 819 <p><b>Further discussion, in email:</b></p>
 820
 821 <p>
 822 ...I'm not so concerned about (1). After all, a library implementation
 823 can add const char* constructors as an extension, and users don't
 824 <i>need</i> to avail themselves of the standard exceptions, though this is
 825 a lame position to be forced into.  FWIW, std::exception and
 826 std::bad_alloc don't require a temporary basic_string.
 827 </p>
 828
 829 <p>
 830 ...I don't think the fixed-size buffer is a solution to the problem,
 831 strictly speaking, because you can't satisfy the postcondition
 832 <br>
 833     <tt>&nbsp;&nbsp;strcmp(what(), what_arg.c_str()) == 0</tt>
 834 <br>
 835 For all values of what_arg (i.e. very long values). That means that
 836 the only truly conforming solution requires a dynamic allocation.
 837 </p>
 838
 839 <p><b>Further discussion, from Redmond:</b></p>
 840
 841 <p>The most important progress we made at the Redmond meeting was
 842 realizing that there are two separable issues here: the const
 843 string&amp; constructor, and the copy constructor.  If a user writes
 844 something like <tt>throw std::out_of_range("foo")</tt>, the const
 845 string&amp; constructor is invoked before anything gets thrown.  The
 846 copy constructor is potentially invoked during stack unwinding.</p>
 847
 848 <p>The copy constructor is a more serious problem, becuase failure
 849 during stack unwinding invokes <tt>terminate</tt>.  The copy
 850 constructor must be nothrow. <i>Curaçao: Howard thinks this
 851 requirement may already be present.</i></p>
 852
 853 <p>The fundamental problem is that it's difficult to get the nothrow
 854 requirement to work well with the requirement that the exception
 855 objects store a string of unbounded size, particularly if you also try
 856 to make the const string&amp; constructor nothrow.  Options discussed
 857 include:</p>
 858
 859 <ul>
 860 <li>Limit the size of a string that exception objects are required to
 861 throw: change the postconditions of 19.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.domain.error"> [lib.domain.error]</a> paragraph 3
 862 and 19.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.runtime.error"> [lib.runtime.error]</a> paragraph 3 to something like this:
 863 "strncmp(what(), what_arg._str(), N) == 0, where N is an
 864 implementation defined constant no smaller than 256".</li>
 865 <li>Allow the const string&amp; constructor to throw, but not the
 866 copy constructor.  It's the implementor's responsibility to get it
 867 right.  (An implementor might use a simple refcount class.)</li>
 868 <li>Compromise between the two: an implementation is not allowed to
 869 throw if the string's length is less than some N, but, if it doesn't
 870 throw, the string must compare equal to the argument.</li>
 871 <li>Add a new constructor that takes a const char*</li>
 872 </ul>
 873
 874 <p>(Not all of these options are mutually exclusive.)</p>
 875
 876 <p><b>Proposed resolution:</b></p>
 877 <p><b>Rationale:</b></p>
 878
 879 <p>Throwing a bad_alloc while trying to construct a message for another
 880 exception-derived class is not necessarily a bad thing.  And the
 881 bad_alloc constructor already has a no throw spec on it (18.4.2.1).</p>
 882
 883 <p><b>Future:</b></p>
 884
 885 <p>All involved would like to see const char* constructors added, but
 886 this should probably be done for C++0X as opposed to a DR.</p>
 887
 888 <p>I believe the no throw specs currently decorating these functions
 889 could be improved by some kind of static no throw spec checking
 890 mechanism (in a future C++ language).  As they stand, the copy
 891 constructors might fail via a call to unexpected.  I think what is
 892 intended here is that the copy constructors can't fail.</p>
 893
 894 <p><i>[Pre-Sydney: reopened at the request of Howard Hinnant.
 895   Post-Redmond: James Kanze noticed that the copy constructors of
 896   exception-derived classes do not have nothrow clauses.  Those
 897   classes have no copy constructors declared, meaning the
 898   compiler-generated implicit copy constructors are used, and those
 899   compiler-generated constructors might in principle throw anything.]</i></p>
 900
 901 <hr>
 902 <a name="258"><h3>258.&nbsp;Missing allocator requirement</h3></a><p><b>Section:</b>&nbsp;20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;22 Aug 2000</p>
 903 <p>
 904 &gt;From lib-7752:
 905 </p>
 906
 907 <p>
 908 I've been assuming (and probably everyone else has been assuming) that
 909 allocator instances have a particular property, and I don't think that
 910 property can be deduced from anything in Table 32.
 911 </p>
 912
 913 <p>
 914 I think we have to assume that allocator type conversion is a
 915 homomorphism.  That is, if x1 and x2 are of type X, where
 916 X::value_type is T, and if type Y is X::template
 917 rebind&lt;U&gt;::other, then Y(x1) == Y(x2) if and only if x1 == x2.
 918 </p>
 919
 920 <p>
 921 Further discussion: Howard Hinnant writes, in lib-7757:
 922 </p>
 923
 924 <p>
 925 I think I can prove that this is not provable by Table 32.  And I agree
 926 it needs to be true except for the "and only if".  If x1 != x2, I see no
 927 reason why it can't be true that Y(x1) == Y(x2).  Admittedly I can't
 928 think of a practical instance where this would happen, or be valuable.
 929 But I also don't see a need to add that extra restriction.  I think we
 930 only need:
 931 </p>
 932
 933 <blockquote>
 934      if (x1 == x2) then Y(x1) == Y(x2)
 935 </blockquote>
 936
 937 <p>
 938 If we decide that == on allocators is transitive, then I think I can
 939 prove the above.  But I don't think == is necessarily transitive on
 940 allocators.  That is:
 941 </p>
 942
 943 <p>
 944 Given x1 == x2  and x2 == x3, this does not mean x1 == x3.
 945 </p>
 946
 947 <p>Example:</p>
 948
 949 <blockquote>
 950 <p>
 951 x1 can deallocate pointers from:  x1, x2, x3    <br>
 952 x2 can deallocate pointers from:  x1, x2, x4    <br>
 953 x3 can deallocate pointers from:  x1, x3        <br>
 954 x4 can deallocate pointers from:  x2, x4
 955 </p>
 956
 957 <p>
 958 x1 == x2, and x2 == x4, but x1 != x4
 959 </p>
 960 </blockquote>
 961 <p><b>Proposed resolution:</b></p>
 962
 963 <p><i>[Toronto: LWG members offered multiple opinions.  One
 964 opinion is that it should not be required that <tt>x1 == x2</tt>
 965 implies <tt>Y(x1) == Y(x2)</tt>, and that it should not even be
 966 required that <tt>X(x1) == x1</tt>.  Another opinion is that
 967 the second line from the bottom in table 32 already implies the
 968 desired property.  This issue should be considered in light of
 969 other issues related to allocator instances.]</i></p>
 970 <hr>
 971 <a name="290"><h3>290.&nbsp;Requirements to for_each and its function object</h3></a><p><b>Section:</b>&nbsp;25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;03 Jan 2001</p>
 972 <p>The specification of the for_each algorithm does not have a
 973 "Requires" section, which means that there are no
 974 restrictions imposed on the function object whatsoever. In essence it
 975 means that I can provide any function object with arbitrary side
 976 effects and I can still expect a predictable result. In particular I
 977 can expect that the function object is applied exactly last - first
 978 times, which is promised in the "Complexity" section.
 979 </p>
 980
 981 <p>I don't see how any implementation can give such a guarantee
 982 without imposing requirements on the function object.
 983 </p>
 984
 985 <p>Just as an example: consider a function object that removes
 986 elements from the input sequence.  In that case, what does the
 987 complexity guarantee (applies f exactly last - first times) mean?
 988 </p>
 989
 990 <p>One can argue that this is obviously a nonsensical application and
 991 a theoretical case, which unfortunately it isn't.  I have seen
 992 programmers shooting themselves in the foot this way, and they did not
 993 understand that there are restrictions even if the description of the
 994 algorithm does not say so.
 995 </p>
 996 <p><b>Proposed resolution:</b></p>
 997 <p><i>[Lillehammer: This is more general than for_each.  We don't want
 998   the function object in transform invalidiating iterators
 999   either. There should be a note somewhere in clause 17 (17, not 25)
1000   saying that user code operating on a range may not invalidate
1001   iterators unless otherwise specified.  Bill will provide wording.]</i></p>
1002
1003 <hr>
1004 <a name="294"><h3>294.&nbsp;User defined macros and standard headers</h3></a><p><b>Section:</b>&nbsp;17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;11 Jan 2001</p>
1005 <p>Paragraph 2 of 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> reads: "A
1006 translation unit that includes a header shall not contain any macros
1007 that define names declared in that header." As I read this, it
1008 would mean that the following program is legal:</p>
1009
1010 <pre>  #define npos 3.14
1011   #include &lt;sstream&gt;
1012 </pre>
1013
1014 <p>since npos is not defined in &lt;sstream&gt;.  It is, however, defined
1015 in &lt;string&gt;, and it is hard to imagine an implementation in
1016 which &lt;sstream&gt; didn't include &lt;string&gt;.</p>
1017
1018 <p>I think that this phrase was probably formulated before it was
1019 decided that a standard header may freely include other standard
1020 headers.  The phrase would be perfectly appropriate for C, for
1021 example.  In light of 17.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.headers"> [lib.res.on.headers]</a> paragraph 1, however,
1022 it isn't stringent enough.</p>
1023 <p><b>Proposed resolution:</b></p>
1024 <p>For 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>, replace the current wording, which reads:</p>
1025 <blockquote>
1026      <p>Each name defined as a macro in a header is reserved to the
1027      implementation for any use if the translation unit includes
1028      the header.168)</p>
1029
1030      <p>A translation unit that includes a header shall not contain any
1031      macros that define names declared or defined in that header. Nor shall
1032      such a translation unit define macros for names lexically
1033      identical to keywords.</p>
1034
1035      <p>168) It is not permissible to remove a library macro definition by
1036      using the #undef directive.</p>
1037 </blockquote>
1038
1039 <p>with the wording:</p>
1040
1041 <blockquote>
1042      <p>A translation unit that includes a standard library header shall not
1043      #define or #undef names declared in any standard library header.</p>
1044
1045      <p>A translation unit shall not #define or #undef names lexically
1046      identical to keywords.</p>
1047 </blockquote>
1048
1049 <p><i>[Lillehammer: Beman provided new wording]</i></p>
1050
1051 <hr>
1052 <a name="299"><h3>299.&nbsp;Incorrect return types for iterator dereference</h3></a><p><b>Section:</b>&nbsp;24.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, 24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;John Potter&nbsp; <b>Date:</b>&nbsp;22 Jan 2001</p>
1053 <p>
1054 In section 24.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>,
1055 Table 75 gives the return type of *r-- as convertible to T.  This is
1056 not consistent with Table 74 which gives the return type of *r++ as
1057 T&amp;.  *r++ = t is valid while *r-- = t is invalid.
1058 </p>
1059
1060 <p>
1061 In section 24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>,
1062 Table 76 gives the return type of a[n] as convertible to T.  This is
1063 not consistent with the semantics of *(a + n) which returns T&amp; by
1064 Table 74.  *(a + n) = t is valid while a[n] = t is invalid.
1065 </p>
1066
1067 <p>
1068 Discussion from the Copenhagen meeting: the first part is
1069 uncontroversial.  The second part, operator[] for Random Access
1070 Iterators, requires more thought.  There are reasonable arguments on
1071 both sides.  Return by value from operator[] enables some potentially
1072 useful iterators, e.g. a random access "iota iterator" (a.k.a
1073 "counting iterator" or "int iterator").  There isn't any obvious way
1074 to do this with return-by-reference, since the reference would be to a
1075 temporary.  On the other hand, <tt>reverse_iterator</tt> takes an
1076 arbitrary Random Access Iterator as template argument, and its
1077 operator[] returns by reference.  If we decided that the return type
1078 in Table 76 was correct, we would have to change
1079 <tt>reverse_iterator</tt>.  This change would probably affect user
1080 code.
1081 </p>
1082
1083 <p>
1084 History: the contradiction between <tt>reverse_iterator</tt> and the
1085 Random Access Iterator requirements has been present from an early
1086 stage.  In both the STL proposal adopted by the committee
1087 (N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
1088 Stepanov and Lee), the Random Access Iterator requirements say that
1089 operator[]'s return value is "convertible to T".  In N0527
1090 reverse_iterator's operator[] returns by value, but in HPL-95-11
1091 (R.1), and in the STL implementation that HP released to the public,
1092 reverse_iterator's operator[] returns by reference.  In 1995, the
1093 standard was amended to reflect the contents of HPL-95-11 (R.1).  The
1094 original intent for operator[] is unclear.
1095 </p>
1096
1097 <p>
1098 In the long term it may be desirable to add more fine-grained
1099 iterator requirements, so that access method and traversal strategy
1100 can be decoupled.  (See "Improved Iterator Categories and
1101 Requirements", N1297 = 01-0011, by Jeremy Siek.)  Any decisions
1102 about issue 299 should keep this possibility in mind.
1103 </p>
1104
1105 <p>Further discussion: I propose a compromise between John Potter's
1106 resolution, which requires <tt>T&amp;</tt> as the return type of
1107 <tt>a[n]</tt>, and the current wording, which requires convertible to
1108 <tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt>
1109 for the return type of the expression <tt>a[n]</tt>, but to also add
1110 <tt>a[n] = t</tt> as a valid expression. This compromise "saves" the
1111 common case uses of random access iterators, while at the same time
1112 allowing iterators such as counting iterator and caching file
1113 iterators to remain random access iterators (iterators where the
1114 lifetime of the object returned by <tt>operator*()</tt> is tied to the
1115 lifetime of the iterator).
1116 </p>
1117
1118 <p>
1119 Note that the compromise resolution necessitates a change to
1120 <tt>reverse_iterator</tt>. It would need to use a proxy to support
1121 <tt>a[n] = t</tt>.
1122 </p>
1123
1124 <p>
1125 Note also there is one kind of mutable random access iterator that
1126 will no longer meet the new requirements. Currently, iterators that
1127 return an r-value from <tt>operator[]</tt> meet the requirements for a
1128 mutable random access iterartor, even though the expression <tt>a[n] =
1129 t</tt> will only modify a temporary that goes away. With this proposed
1130 resolution, <tt>a[n] = t</tt> will be required to have the same
1131 operational semantics as <tt>*(a + n) = t</tt>.
1132 </p>
1133
1134 <p><b>Proposed resolution:</b></p>
1135
1136 <p>
1137 In section 24.1.4 [lib.bidirectdional.iterators], change the return
1138 type in table 75 from "convertible to <tt>T</tt>" to
1139 <tt>T&amp;</tt>.
1140 </p>
1141
1142 <p>
1143 In section 24.1.5 [lib.random.access.iterators], change the
1144 operational semantics for <tt>a[n]</tt> to " the r-value of
1145 <tt>a[n]</tt> is equivalent to the r-value of <tt>*(a +
1146 n)</tt>". Add a new row in the table for the expression <tt>a[n] = t</tt>
1147 with a return type of convertible to <tt>T</tt> and operational semantics of
1148 <tt>*(a + n) = t</tt>.
1149 </p>
1150
1151 <p><i>[Lillehammer: Real problem, but should be addressed as part of
1152   iterator redesign]</i></p>
1153
1154 <hr>
1155 <a name="342"><h3>342.&nbsp;seek and eofbit</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;09 Oct 2001</p>
1156 <p>I think we have a defect.</p>
1157
1158 <p>According to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> which is now a dr, the
1159 description of seekg in 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> paragraph 38 now looks
1160 like:</p>
1161
1162 <blockquote>
1163 Behaves as an unformatted input function (as described in 27.6.1.3,
1164 paragraph 1), except that it does not count the number of characters
1165 extracted and does not affect the value returned by subsequent calls to
1166 gcount(). After constructing a sentry object, if fail() != true,
1167 executes rdbuf()&gt;pubseekpos( pos).
1168 </blockquote>
1169
1170 <p>And according to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> which is also now a dr,
1171 27.6.1.3, paragraph 1 looks like:</p>
1172
1173 <blockquote>
1174 Each unformatted input function begins execution by constructing an
1175 object of class sentry with the default argument noskipws (second)
1176 argument true. If the sentry object returns true, when converted to a
1177 value of type bool, the function endeavors to obtain the requested
1178 input.  Otherwise, if the sentry constructor exits by throwing an
1179 exception or if the sentry object returns false, when converted to a
1180 value of type bool, the function returns without attempting to obtain
1181 any input. In either case the number of extracted characters is set to
1182 0; unformatted input functions taking a character array of non-zero
1183 size as an argument shall also store a null character (using charT())
1184 in the first location of the array. If an exception is thrown during
1185 input then ios::badbit is turned on in *this'ss error state. If
1186 (exception()&amp;badbit)!= 0 then the exception is rethrown. It also counts
1187 the number of characters extracted. If no exception has been thrown it
1188 ends by storing the count in a member object and returning the value
1189 specified. In any event the sentry object is destroyed before leaving
1190 the unformatted input function.
1191 </blockquote>
1192
1193 <p>And finally 27.6.1.1.2/5 says this about sentry:</p>
1194
1195 <blockquote>
1196 If, after any preparation is completed, is.good() is true, ok_ != false
1197 otherwise, ok_ == false.
1198 </blockquote>
1199
1200 <p>
1201 So although the seekg paragraph says that the operation proceeds if
1202 !fail(), the behavior of unformatted functions says the operation
1203 proceeds only if good().  The two statements are contradictory when only
1204 eofbit is set.  I don't think the current text is clear which condition
1205 should be respected.
1206 </p>
1207
1208 <p><b>Further discussion from Redmond:</b></p>
1209
1210 <p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is
1211 "unformatted". That makes specific claims about sentry that
1212 aren't quite appropriate for seeking, which has less fragile failure
1213 modes than actual input.  If we do really mean that it's unformatted
1214 input, it should behave the same way as other unformatted input.  On
1215 the other hand, "principle of least surprise" is that seeking from EOF
1216 ought to be OK.</p>
1217 <p><b>Proposed resolution:</b></p>
1218
1219 <p>Change 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> to:</p>
1220 <blockquote>
1221 Behaves as an unformatted input function (as described in 27.6.1.3,
1222 paragraph 1), except that it does not count the number of characters
1223 extracted, does not affect the value returned by subsequent calls to
1224 gcount(), and does not examine the value returned by the sentry
1225 object. After constructing a sentry object, if <tt>fail() !=
1226 true</tt>, executes <tt>rdbuf()-&gt;pubseekpos(pos)</tt>.  In
1227 case of success, the function calls clear().
1228 In case of failure, the function calls <tt>setstate(failbit)</tt>
1229 (which may throw <tt>ios_base::failure</tt>).
1230 </blockquote>
1231
1232 <p><i>[Lillehammer: Matt provided wording.]</i></p>
1233
1234 <p><b>Rationale:</b></p>
1235 <p>In C, fseek does clear EOF.  This is probably what most users would
1236   expect.  We agree that having eofbit set should not deter a seek,
1237   and that a successful seek should clear eofbit. Note
1238   that <tt>fail()</tt> is true only if <tt>failbit</tt>
1239   or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather
1240   than <tt>good()</tt>, satisfies this goal.</p>
1241 <hr>
1242 <a name="362"><h3>362.&nbsp;bind1st/bind2nd type safety</h3></a><p><b>Section:</b>&nbsp;20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Demkin&nbsp; <b>Date:</b>&nbsp;26 Apr 2002</p>
1243 <p>
1244 The definition of bind1st() (20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>) can result in
1245 the construction of an unsafe binding between incompatible pointer
1246 types. For example, given a function whose first parameter type is
1247 'pointer to T', it's possible without error to bind an argument of
1248 type 'pointer to U' when U does not derive from T:
1249 </p>
1250 <pre>   foo(T*, int);
1251
1252    struct T {};
1253    struct U {};
1254
1255    U u;
1256
1257    int* p;
1258    int* q;
1259
1260    for_each(p, q, bind1st(ptr_fun(foo), &amp;u));    // unsafe binding
1261 </pre>
1262
1263 <p>
1264 The definition of bind1st() includes a functional-style conversion to
1265 map its argument to the expected argument type of the bound function
1266 (see below):
1267 </p>
1268 <pre>  typename Operation::first_argument_type(x)
1269 </pre>
1270
1271 <p>
1272 A functional-style conversion (5.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.type.conv"> [expr.type.conv]</a>) is defined to be
1273 semantically equivalent to an explicit cast expression (5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.cast"> [expr.cast]</a>), which may (according to 5.4, paragraph 5) be interpreted
1274 as a reinterpret_cast, thus masking the error.
1275 </p>
1276
1277 <p>The problem and proposed change also apply to 20.3.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.2nd"> [lib.bind.2nd]</a>.</p>
1278 <p><b>Proposed resolution:</b></p>
1279 <p>Add this sentence to the end of 20.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binders"> [lib.binders]</a>/1:
1280   "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in
1281   favor of <tt>std::tr1::bind</tt>."</p>
1282
1283 <p>(Notes to editor: (1) when and if tr1::bind is incorporated into
1284   the standard, "std::tr1::bind" should be changed to "std::bind". (2)
1285   20.3.6 should probably be moved to Annex D.</p>
1286 <p><b>Rationale:</b></p>
1287 <p>There is no point in fixing bind1st and bind2nd.  tr1::bind is a
1288   superior solution.  It solves this problem and others.</p>
1289 <hr>
1290 <a name="369"><h3>369.&nbsp;io stream objects and static ctors</h3></a><p><b>Section:</b>&nbsp;27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Ruslan Abdikeev&nbsp; <b>Date:</b>&nbsp;8 Jul 2002</p>
1291 <p>
1292 Is it safe to use standard iostream objects from constructors of
1293 static objects?  Are standard iostream objects constructed and are
1294 their associations established at that time?
1295 </p>
1296
1297 <p>Surpisingly enough, Standard does NOT require that.</p>
1298
1299 <p>
1300 27.3/2 [lib.iostream.objects] guarantees that standard iostream
1301 objects are constructed and their associations are established before
1302 the body of main() begins execution.  It also refers to ios_base::Init
1303 class as the panacea for constructors of static objects.
1304 </p>
1305
1306 <p>
1307 However, there's nothing in 27.3 [lib.iostream.objects],
1308 in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
1309 that would require implementations to allow access to standard
1310 iostream objects from constructors of static objects.
1311 </p>
1312
1313 <p>Details:</p>
1314
1315 <p>Core text refers to some magic object ios_base::Init, which will
1316 be discussed below:</p>
1317
1318 <blockquote>
1319     "The [standard iostream] objects are constructed, and their
1320     associations are established at some time prior to or during
1321     first time an object of class basic_ios&lt;charT,traits&gt;::Init
1322     is constructed, and in any case before the body of main
1323     begins execution." (27.3/2 [lib.iostream.objects])
1324 </blockquote>
1325
1326 <p>
1327 The first <i>non-normative</i> footnote encourages implementations
1328 to initialize standard iostream objects earlier than required.
1329 </p>
1330
1331 <p>However, the second <i>non-normative</i> footnote makes an explicit
1332 and unsupported claim:</p>
1333
1334 <blockquote>
1335   "Constructors and destructors for static objects can access these
1336   [standard iostream] objects to read input from stdin or write output
1337   to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects])
1338 </blockquote>
1339
1340 <p>
1341 The only bit of magic is related to that ios_base::Init class.  AFAIK,
1342 the rationale behind ios_base::Init was to bring an instance of this
1343 class to each translation unit which #included &lt;iostream&gt; or
1344 related header.  Such an inclusion would support the claim of footnote
1345 quoted above, because in order to use some standard iostream object it
1346 is necessary to #include &lt;iostream&gt;.
1347 </p>
1348
1349 <p>
1350 However, while Standard explicitly describes ios_base::Init as
1351 an appropriate class for doing the trick, I failed to found a
1352 mention of an _instance_ of ios_base::Init in Standard.
1353 </p>
1354 <p><b>Proposed resolution:</b></p>
1355
1356 <p>Add to 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>, p2, immediately before the last sentence
1357 of the paragraph, the following two sentences:</p>
1358
1359 <blockquote>
1360 If a translation unit includes &lt;iostream&gt;, or explicitly
1361 constructs an ios_base::Init object, these stream objects shall
1362 be constructed before dynamic initialization of non-local
1363 objects defined later in that translation unit, and these stream
1364 objects shall be destroyed after the destruction of dynamically
1365 initialized non-local objects defined later in that translation unit.
1366 </blockquote>
1367
1368 <p><i>[Lillehammer: Matt provided wording.]</i></p>
1369 <p><i>[Mont Tremblant: Matt provided revised wording.]</i></p>
1370 <p><b>Rationale:</b></p>
1371 <p>
1372 The original proposed resolution unconditionally required
1373 implementations to define an ios_base::Init object of some
1374 implementation-defined name in the header &lt;iostream&gt;. That's an
1375 overspecification. First, defining the object may be unnecessary
1376 and even detrimental to performance if an implementation can
1377 guarantee that the 8 standard iostream objects will be initialized
1378 before any other user-defined object in a program. Second, there
1379 is no need to require implementations to document the name of the
1380 object.</p>
1381
1382 <p>
1383 The new proposed resolution gives users guidance on what they need to
1384 do to ensure that stream objects are constructed during startup.</p>
1385 <hr>
1386 <a name="371"><h3>371.&nbsp;Stability of multiset and multimap member functions</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Frank Compagner&nbsp; <b>Date:</b>&nbsp;20 Jul 2002</p>
1387 <p>
1388 The requirements for multiset and multimap containers (23.1
1389 [lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
1390 23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
1391 the stability of the required (mutating) member functions. It appears
1392 the standard allows these functions to reorder equivalent elements of
1393 the container at will, yet the pervasive red-black tree implementation
1394 appears to provide stable behaviour.
1395 </p>
1396
1397 <p>This is of most concern when considering the behaviour of erase().
1398 A stability requirement would guarantee the correct working of the
1399 following 'idiom' that removes elements based on a certain predicate
1400 function.
1401 </p>
1402
1403 <pre>  multimap&lt;int, int&gt; m;
1404   multimap&lt;int, int&gt;::iterator i = m.begin();
1405   while (i != m.end()) {
1406       if (pred(i))
1407           m.erase (i++);
1408       else
1409           ++i;
1410   }
1411 </pre>
1412
1413 <p>
1414 Although clause 23.1.2/8 guarantees that i remains a valid iterator
1415 througout this loop, absence of the stability requirement could
1416 potentially result in elements being skipped. This would make
1417 this code incorrect, and, furthermore, means that there is no way
1418 of erasing these elements without iterating first over the entire
1419 container, and second over the elements to be erased. This would
1420 be unfortunate, and have a negative impact on both performance and
1421 code simplicity.
1422 </p>
1423
1424 <p>
1425 If the stability requirement is intended, it should be made explicit
1426 (probably through an extra paragraph in clause 23.1.2).
1427 </p>
1428 <p>
1429 If it turns out stability cannot be guaranteed, i'd argue that a
1430 remark or footnote is called for (also somewhere in clause 23.1.2) to
1431 warn against relying on stable behaviour (as demonstrated by the code
1432 above).  If most implementations will display stable behaviour, any
1433 problems emerging on an implementation without stable behaviour will
1434 be hard to track down by users. This would also make the need for an
1435 erase_if() member function that much greater.
1436 </p>
1437
1438 <p>This issue is somewhat related to LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>.</p>
1439
1440 <p><b>Proposed resolution:</b></p>
1441
1442 <p>Add the following to the end of 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> paragraph 4:
1443 "For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt>
1444   are <i>stable</i>: they preserve the relative ordering of equivalent
1445   elements.</p>
1446
1447 <p><i>[Lillehammer: Matt provided wording]</i></p>
1448 <p><i>[Joe Gottman points out that the provided wording does not address
1449 multimap and multiset.  N1780 also addresses this issue and suggests
1450 wording.]</i></p>
1451
1452 <p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p>
1453
1454 <p><b>Rationale:</b></p>
1455 <p>The LWG agrees that this guarantee is necessary for common user
1456   idioms to work, and that all existing implementations provide this
1457   property.  Note that this resolution guarantees stability for
1458   multimap and multiset, not for all associative containers in
1459   general.</p>
1460
1461 <hr>
1462 <a name="376"><h3>376.&nbsp;basic_streambuf semantics</h3></a><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
1463 <p>
1464 In Section 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, Table 90, the implication is that
1465 the four conditions should be mutually exclusive, but they are not.
1466 The first two cases, as written, are subcases of the third.</p>
1467
1468 <p>
1469 As written, it is unclear what should be the result if cases 1 and 2
1470 are both true, but case 3 is false.
1471 </p>
1472
1473 <p><b>Proposed resolution:</b></p>
1474
1475 <p>Rewrite these conditions as:</p>
1476 <blockquote>
1477 <p>
1478   (which &amp; (ios_base::in|ios_base::out)) == ios_base::in
1479 </p>
1480
1481 <p>
1482   (which &amp; (ios_base::in|ios_base::out)) == ios_base::out
1483 </p>
1484
1485 <p>
1486   (which &amp; (ios_base::in|ios_base::out)) ==
1487 (ios_base::in|ios_base::out)
1488    and way == either ios_base::beg or ios_base::end
1489 </p>
1490
1491 <p>Otherwise</p>
1492 </blockquote>
1493
1494 <p><b>Rationale:</b></p>
1495 <p>It's clear what we wanted to say, we just failed to say it.  This
1496   fixes it.</p>
1497 <hr>
1498 <a name="382"><h3>382.&nbsp;codecvt do_in/out result</h3></a><p><b>Section:</b>&nbsp;22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;30 Aug  2002</p>
1499 <p>
1500 It seems that the descriptions of codecvt do_in() and do_out() leave
1501 sufficient room for interpretation so that two implementations of
1502 codecvt may not work correctly with the same filebuf. Specifically,
1503 the following seems less than adequately specified:
1504 </p>
1505
1506 <ol>
1507 <li>
1508   the conditions under which the functions terminate
1509 </li>
1510 <li>
1511   precisely when the functions return ok
1512 </li>
1513 <li>
1514   precisely when the functions return partial
1515 </li>
1516 <li>
1517   the full set of conditions when the functions return error
1518 </li>
1519 </ol>
1520
1521 <ol>
1522 <li>
1523    22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p2 says this about the effects of the
1524    function: ...Stops if it encounters a character it cannot
1525    convert...  This assumes that there *is* a character to
1526    convert. What happens when there is a sequence that doesn't form a
1527    valid source character, such as an unassigned or invalid UNICODE
1528    character, or a sequence that cannot possibly form a character
1529    (e.g., the sequence "\xc0\xff" in UTF-8)?
1530 </li>
1531 <li>
1532    Table 53 says that the function returns codecvt_base::ok
1533    to indicate that the function(s) "completed the conversion."
1534    Suppose that the source sequence is "\xc0\x80" in UTF-8,
1535    with from pointing to '\xc0' and (from_end==from + 1).
1536    It is not clear whether the return value should be ok
1537    or partial (see below).
1538 </li>
1539 <li>
1540    Table 53 says that the function returns codecvt_base::partial
1541    if "not all source characters converted." With the from pointers
1542    set up the same way as above, it is not clear whether the return
1543    value should be partial or ok (see above).
1544 </li>
1545 <li>
1546    Table 53, in the row describing the meaning of error mistakenly
1547    refers to a "from_type" character, without the symbol from_type
1548    having been defined. Most likely, the word "source" character
1549    is intended, although that is not sufficient. The functions
1550    may also fail when they encounter an invalid source sequence
1551    that cannot possibly form a valid source character (e.g., as
1552    explained in bullet 1 above).
1553 </li>
1554 </ol>
1555 <p>
1556 Finally, the conditions described at the end of 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p4 don't seem to be possible:
1557 </p>
1558 <blockquote>
1559     "A return value of partial, if (from_next == from_end),
1560     indicates that either the destination sequence has not
1561     absorbed all the available destination elements, or that
1562     additional source elements are needed before another
1563     destination element can be produced."
1564 </blockquote>
1565 <p>
1566 If the value is partial, it's not clear to me that (from_next
1567 ==from_end) could ever hold if there isn't enough room
1568 in the destination buffer. In order for (from_next==from_end) to
1569 hold, all characters in that range must have been successfully
1570 converted (according to 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p2) and since there are no
1571 further source characters to convert, no more room in the
1572 destination buffer can be needed.
1573 </p>
1574 <p>
1575 It's also not clear to me that (from_next==from_end) could ever
1576 hold if additional source elements are needed to produce another
1577 destination character (not element as incorrectly stated in the
1578 text). partial is returned if "not all source characters have
1579 been converted" according to Table 53, which also implies that
1580 (from_next==from) does NOT hold.
1581 </p>
1582 <p>
1583 Could it be that the intended qualifying condition was actually
1584 (from_next != from_end), i.e., that the sentence was supposed
1585 to read
1586 </p>
1587 <blockquote>
1588     "A return value of partial, if (from_next != from_end),..."
1589 </blockquote>
1590 <p>
1591 which would make perfect sense, since, as far as I understand it,
1592 partial can only occur if (from_next != from_end)?
1593 </p>
1594 <p><b>Proposed resolution:</b></p>
1595
1596 <p><i>[Lillehammer: Defer for the moment, but this really needs to be
1597   fixed. Right now, the description of codecvt is too vague for it to
1598   be a useful contract between providers and clients of codecvt
1599   facets.  (Note that both vendors and users can be both providers and
1600   clients of codecvt facets.) The major philosophical issue is whether
1601   the standard should only describe mappings that take a single wide
1602   character to multiple narrow characters (and vice versa), or whether
1603   it should describe fully general N-to-M conversions. When the
1604   original standard was written only the former was contemplated, but
1605   today, in light of the popularity of utf8 and utf16, that doesn't
1606   seem sufficient for C++0x. Bill supports general N-to-M conversions;
1607   we need to make sure Martin and Howard agree.]</i></p>
1608
1609 <hr>
1610 <a name="384"><h3>384.&nbsp;equal_range has unimplementable runtime complexity</h3></a><p><b>Section:</b>&nbsp;25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Bos&nbsp; <b>Date:</b>&nbsp;18 Oct 2002</p>
1611 <p>
1612 Section 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>
1613 states that at most 2 * log(last - first) + 1
1614 comparisons are allowed for equal_range.
1615 </p>
1616
1617 <p>It is not possible to implement equal_range with these constraints.</p>
1618
1619 <p>In a range of one element as in:</p>
1620 <pre>    int x = 1;
1621     equal_range(&amp;x, &amp;x + 1, 1)
1622 </pre>
1623
1624 <p>it is easy to see that at least 2 comparison operations are needed.</p>
1625
1626 <p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p>
1627
1628 <p>I have checked a few libraries and they all use the same (nonconforming)
1629 algorithm for equal_range that has a complexity of</p>
1630 <pre>     2* log(distance(first, last)) + 2.
1631 </pre>
1632 <p>I guess this is the algorithm that the standard assumes for equal_range.</p>
1633
1634 <p>
1635 It is easy to see that 2 * log(distance) + 2 comparisons are enough
1636 since equal range can be implemented with lower_bound and upper_bound
1637 (both log(distance) + 1).
1638 </p>
1639
1640 <p>
1641 I think it is better to require something like 2log(distance) + O(1)  (or
1642 even logarithmic as multiset::equal_range).
1643 Then an implementation has more room to optimize for certain cases (e.g.
1644 have log(distance) characteristics when at most match is found in the range
1645 but 2log(distance) + 4 for the worst case).
1646 </p>
1647
1648 <p><b>Proposed resolution:</b></p>
1649 <p>In 25.3.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.lower.bound"> [lib.lower.bound]</a>/4, change <tt>log(last - first) + 1</tt>
1650 to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
1651
1652 <p>In 25.3.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.upper.bound"> [lib.upper.bound]</a>/4, change <tt>log(last - first) + 1</tt>
1653 to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
1654
1655 <p>In 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>/4, change <tt>2*log(last - first) + 1</tt>
1656 to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
1657
1658 <p><i>[Matt provided wording]</i></p>
1659 <p><b>Rationale:</b></p>
1660 <p>The LWG considered just saying <i>O</i>(log n) for all three, but
1661 Ê decided that threw away too much valuable information.Ê The fact
1662 Ê that lower_bound is twice as fast as equal_range is important.
1663 Ê However, it's better to allow an arbitrary additive constant than to
1664 Ê specify an exact count.Ê An exact count would have to
1665 Ê involve <tt>floor</tt> or <tt>ceil</tt>.Ê It would be too easy to
1666 Ê get this wrong, and don't provide any substantial value for users.</p>
1667 <hr>
1668 <a name="385"><h3>385.&nbsp;Does call by value imply the CopyConstructible requirement?</h3></a><p><b>Section:</b>&nbsp;17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Oct 2002</p>
1669 <p>
1670 Many function templates have parameters that are passed by value;
1671 a typical example is <tt>find_if</tt>'s <i>pred</i> parameter in
1672 25.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a>.  Are the corresponding template parameters
1673 (<tt>Predicate</tt> in this case) implicitly required to be
1674 CopyConstructible, or does that need to be spelled out explicitly?
1675 </p>
1676
1677 <p>
1678 This isn't quite as silly a question as it might seem to be at first
1679 sight.  If you call <tt>find_if</tt> in such a way that template
1680 argument deduction applies, then of course you'll get call by value
1681 and you need to provide a copy constructor.  If you explicitly provide
1682 the template arguments, however, you can force call by reference by
1683 writing something like <tt>find_if&lt;my_iterator,
1684 my_predicate&amp;&gt;</tt>.  The question is whether implementation
1685 are required to accept this, or whether this is ill-formed because
1686 my_predicate&amp; is not CopyConstructible.
1687 </p>
1688
1689 <p>
1690 The scope of this problem, if it is a problem, is unknown.  Function
1691 object arguments to generic algorithms in clauses 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>
1692 and 26 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numerics"> [lib.numerics]</a> are obvious examples.  A review of the whole
1693 library is necessary.
1694 </p>
1695 <p><b>Proposed resolution:</b></p>
1696 <p><i>[
1697 This is really two issues.  First, predicates are typically passed by
1698 value but we don't say they must be Copy Constructible.  They should
1699 be. Second: is specialization allowed to transform value arguments
1700 into references? References aren't copy constructible, so this should
1701 not be allowed.
1702 ]</i></p>
1703 <hr>
1704 <a name="387"><h3>387.&nbsp;std::complex over-encapsulated</h3></a><p><b>Section:</b>&nbsp;26.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Gabriel Dos Reis&nbsp; <b>Date:</b>&nbsp;8 Nov 2002</p>
1705 <p>
1706 The absence of explicit description of std::complex&lt;T&gt; layout
1707 makes it imposible to reuse existing software developed in traditional
1708 languages like Fortran or C with unambigous and commonly accepted
1709 layout assumptions.  There ought to be a way for practitioners to
1710 predict with confidence the layout of std::complex&lt;T&gt; whenever T
1711 is a numerical datatype.  The absence of ways to access individual
1712 parts of a std::complex&lt;T&gt; object as lvalues unduly promotes
1713 severe pessimizations. For example, the only way to change,
1714 independently, the real and imaginary parts is to write something like
1715 </p>
1716
1717 <pre>complex&lt;T&gt; z;
1718 // ...
1719 // set the real part to r
1720 z = complex&lt;T&gt;(r, z.imag());
1721 // ...
1722 // set the imaginary part to i
1723 z = complex&lt;T&gt;(z.real(), i);
1724 </pre>
1725
1726 <p>
1727 At this point, it seems appropriate to recall that a complex number
1728 is, in effect, just a pair of numbers with no particular invariant to
1729 maintain.  Existing practice in numerical computations has it that a
1730 complex number datatype is usually represented by Cartesian
1731 coordinates. Therefore the over-encapsulation put in the specification
1732 of std::complex&lt;&gt; is not justified.
1733 </p>
1734
1735 <p><b>Proposed resolution:</b></p>
1736 <p>Add the following requirements to 26.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a> as 26.2/4:</p>
1737 <blockquote>
1738 <p>If z is an lvalue expression of type cv std::complex&lt;T&gt; then</p>
1739
1740 <ul>
1741 <li>the expression reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)
1742 is well-formed; and</li>
1743 <li>reinterpret_cast&lt;cvT(&amp;)[2]&gt;(z)[0]designates the
1744 real part of z; and</li>
1745 <li>reinterpret_cast&lt;cvT(&amp;)[2]&gt;(z)[1]designates the
1746 imaginary part of z.</li>
1747 </ul>
1748
1749 <p>
1750 Moreover, if a is an expression of pointer type cv complex&lt;T&gt;*
1751 and the expression a[i] is well-defined for an integer expression
1752 i then:
1753 </p>
1754
1755 <ul>
1756 <li>reinterpret_cast&lt;cvT*&gt;(a)[2+i] designates the real
1757 part of a[i]; and</li>
1758 <li>reinterpret_cast&lt;cv T*&gt;(a)[2+i+1] designates the
1759 imaginary part of a[i].</li>
1760 </ul>
1761 </blockquote>
1762
1763 <p>In the header synopsis in 26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, replace</p>
1764 <pre>  template&lt;class T&gt; T real(const complex&lt;T&gt;&amp;);
1765   template&lt;class T&gt; T imag(const complex&lt;T&gt;&amp;);
1766 </pre>
1767
1768 <p>with</p>
1769
1770 <pre>  template&lt;class T&gt; const T&amp; real(const complex&lt;T&gt;&amp;);
1771   template&lt;class T&gt;       T&amp; real(      complex&lt;T&gt;&amp;);
1772   template&lt;class T&gt; const T&amp; imag(const complex&lt;T&gt;&amp;);
1773   template&lt;class T&gt;       T&amp; imag(      complex&lt;T&gt;&amp;);
1774 </pre>
1775
1776 <p>In 26.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> paragraph 1, change</p>
1777 <pre>  template&lt;class T&gt; T real(const complex&lt;T&gt;&amp;);
1778 </pre>
1779 <p>to</p>
1780 <pre>  template&lt;class T&gt; const T&amp; real(const complex&lt;T&gt;&amp;);
1781   template&lt;class T&gt;       T&amp; real(      complex&lt;T&gt;&amp;);
1782 </pre>
1783 <p>and change the <b>Returns</b> clause to "<b>Returns:</b> The real
1784 part of <i>x</i></p>.
1785
1786 <p>In 26.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> paragraph 2, change</p>
1787 <pre>  template&lt;class T&gt; T imag(const complex&lt;T&gt;&amp;);
1788 </pre>
1789 <p>to</p>
1790 <pre>  template&lt;class T&gt; const T&amp; imag(const complex&lt;T&gt;&amp;);
1791   template&lt;class T&gt;       T&amp; imag(      complex&lt;T&gt;&amp;);
1792 </pre>
1793 <p>and change the <b>Returns</b> clause to "<b>Returns:</b> The imaginary
1794 part of <i>x</i></p>.
1795
1796 <p><i>[Kona: The layout guarantee is absolutely necessary for C
1797   compatibility.  However, there was disagreement about the other part
1798   of this proposal: retrieving elements of the complex number as
1799   lvalues.  An alternative: continue to have real() and imag() return
1800   rvalues, but add set_real() and set_imag().  Straw poll: return
1801   lvalues - 2, add setter functions - 5.  Related issue: do we want
1802   reinterpret_cast as the interface for converting a complex to an
1803   array of two reals, or do we want to provide a more explicit way of
1804   doing it?  Howard will try to resolve this issue for the next
1805   meeting.]</i></p>
1806
1807 <p><i>[pre-Sydney: Howard summarized the options in n1589.]</i></p>
1808
1809 <p><b>Rationale:</b></p>
1810 <p>The LWG believes that C99 compatibility would be enough
1811 justification for this change even without other considerations.  All
1812 existing implementations already have the layout proposed here.</p>
1813 <hr>
1814 <a name="394"><h3>394.&nbsp;behavior of formatted output on failure</h3></a><p><b>Section:</b>&nbsp;27.6.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Dec 2002</p>
1815 <p>
1816 There is a contradiction in Formatted output about what bit is
1817 supposed to be set if the formatting fails. On sentence says it's
1818 badbit and another that it's failbit.
1819 </p>
1820 <p>
1821 27.6.2.5.1, p1 says in the Common Requirements on Formatted output
1822 functions:
1823 </p><pre>     ... If the generation fails, then the formatted output function
1824      does setstate(ios::failbit), which might throw an exception.
1825 </pre>
1826 <p></p>
1827 <p>
1828 27.6.2.5.2, p1 goes on to say this about Arithmetic Inserters:
1829 </p>
1830 <p>
1831      ... The formatting conversion occurs as if it performed the
1832      following code fragment:
1833 </p>
1834 <p>
1835 </p><pre>     bool failed =
1836          use_facet&lt;num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt;
1837          &gt; &gt;
1838          (getloc()).put(*this, *this, fill(), val). failed();
1839
1840      ... If failed is true then does setstate(badbit) ...
1841 </pre>
1842 <p></p>
1843 <p>
1844 The original intent of the text, according to Jerry Schwarz (see
1845 c++std-lib-10500), is captured in the following paragraph:
1846 </p>
1847 <p>
1848 In general "badbit" should mean that the stream is unusable because
1849 of some underlying failure, such as disk full or socket closure;
1850 "failbit" should mean that the requested formatting wasn't possible
1851 because of some inconsistency such as negative widths.  So typically
1852 if you clear badbit and try to output something else you'll fail
1853 again, but if you clear failbit and try to output something else
1854 you'll succeed.
1855 </p>
1856 <p>
1857 In the case of the arithmetic inserters, since num_put cannot
1858 report failure by any means other than exceptions (in response
1859 to which the stream must set badbit, which prevents the kind of
1860 recoverable error reporting mentioned above), the only other
1861 detectable failure is if the iterator returned from num_put
1862 returns true from failed().
1863 </p>
1864 <p>
1865 Since that can only happen (at least with the required iostream
1866 specializations) under such conditions as the underlying failure
1867 referred to above (e.g., disk full), setting badbit would seem
1868 to be the appropriate response (indeed, it is required in
1869 27.6.2.5.2, p1). It follows that failbit can never be directly
1870 set by the arithmetic (it can only be set by the sentry object
1871 under some unspecified conditions).
1872 </p>
1873 <p>
1874 The situation is different for other formatted output functions
1875 which can fail as a result of the streambuf functions failing
1876 (they may do so by means other than exceptions), and which are
1877 then required to set failbit.
1878 </p>
1879 <p>
1880 The contradiction, then, is that ostream::operator&lt;&lt;(int) will
1881 set badbit if the disk is full, while operator&lt;&lt;(ostream&amp;,
1882 char) will set failbit under the same conditions. To make the behavior
1883 consistent, the Common requirements sections for the Formatted output
1884 functions should be changed as proposed below.
1885 </p>
1886 <p><b>Proposed resolution:</b></p>
1887
1888
1889 <p><i>[Kona: There's agreement that this is a real issue.  What we
1890   decided at Kona: 1. An error from the buffer (which can be detected
1891   either directly from streambuf's member functions or by examining a
1892   streambuf_iterator) should always result in badbit getting set.
1893   2. There should never be a circumstance where failbit gets set.
1894   That represents a formatting error, and there are no circumstances
1895   under which the output facets are specified as signaling a
1896   formatting error. (Even more so for string output that for numeric
1897   because there's nothing to format.)  If we ever decide to make it
1898   possible for formatting errors to exist then the facets can signal
1899   the error directly, and that should go in clause 22, not clause 27.
1900   3. The phrase "if generation fails" is unclear and should be
1901   eliminated.  It's not clear whether it's intended to mean a buffer
1902   error (e.g. a full disk), a formatting error, or something else.
1903   Most people thought it was supposed to refer to buffer errors; if
1904   so, we should say so.  Martin will provide wording.]</i></p>
1905
1906 <p><b>Rationale:</b></p>
1907
1908 <hr>
1909 <a name="396"><h3>396.&nbsp;what are characters zero and one</h3></a><p><b>Section:</b>&nbsp;23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Jan 2003</p>
1910     <p>
1911 23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
1912 having the value of 0 or 1 but there is no definition of what
1913 that means for charT other than char and wchar_t. And even for
1914 those two types, the values 0 and 1 are not actually what is
1915 intended -- the values '0' and '1' are. This, along with the
1916 converse problem in the description of to_string() in 23.3.5.2,
1917 p33, looks like a defect remotely related to DR 303.
1918     </p>
1919     <p>
1920 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
1921     </p>
1922     <pre>23.3.5.1:
1923   -6-  An element of the constructed string has value zero if the
1924        corresponding character in str, beginning at position pos,
1925        is 0. Otherwise, the element has the value one.
1926     </pre>
1927     <pre>23.3.5.2:
1928   -33-  Effects: Constructs a string object of the appropriate
1929         type and initializes it to a string of length N characters.
1930         Each character is determined by the value of its
1931         corresponding bit position in *this. Character position N
1932         ?- 1 corresponds to bit position zero. Subsequent decreasing
1933         character positions correspond to increasing bit positions.
1934         Bit value zero becomes the character 0, bit value one becomes
1935         the character 1.
1936     </pre>
1937     <p>
1938 Also note the typo in 23.3.5.1, p6: the object under construction
1939 is a bitset, not a string.
1940     </p>
1941   <p><b>Proposed resolution:</b></p>
1942 <p>Change the constructor's function declaration immediately before
1943 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> p3 to:</p>
1944 <pre>    template &lt;class charT, class traits, class Allocator&gt;
1945     explicit
1946     bitset(const basic_string&lt;charT, traits, Allocator&gt;&amp; str,
1947            typename basic_string&lt;charT, traits, Allocator&gt;::size_type pos = 0,
1948            typename basic_string&lt;charT, traits, Allocator&gt;::size_type n =
1949              basic_string&lt;charT, traits, Allocator&gt;::npos,
1950            charT zero = charT('0'), charT one = charT('1'))
1951 </pre>
1952 <p>Change the first two sentences of 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> p6 to: "An
1953 element of the constructed string has value 0 if the corresponding
1954 character in <i>str</i>, beginning at position <i>pos</i>,
1955 is <i>zero</i>. Otherwise, the element has the value 1.</p>
1956
1957 <p>Change the text of the second sentence in 23.3.5.1, p5 to read:
1958     "The function then throws invalid_argument if any of the rlen
1959     characters in str beginning at position pos is other than <i>zero</i>
1960     or <i>one</i>. The function uses traits::eq() to compare the character
1961     values."
1962 </p>
1963
1964 <p>Change the declaration of the <tt>to_string</tt> member function
1965   immediately before 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> p33 to:</p>
1966 <pre>    template &lt;class charT, class traits, class Allocator&gt;
1967     basic_string&lt;charT, traits, Allocator&gt;
1968     to_string(charT zero = charT('0'), charT one = charT('1')) const;
1969 </pre>
1970 <p>Change the last sentence of 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> p33 to: "Bit
1971   value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the
1972   character <tt><i>one</i></tt>.</p>
1973 <p>Change 23.3.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.operators"> [lib.bitset.operators]</a> p8 to:</p>
1974 <p><b>Returns</b>:</p>
1975 <pre>  os &lt;&lt; x.template to_string&lt;charT,traits,allocator&lt;charT&gt; &gt;(
1976       use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('0'),
1977       use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('1'));
1978 </pre>
1979 <p><b>Rationale:</b></p>
1980 <p>There is a real problem here: we need the character values of '0'
1981   and '1', and we have no way to get them since strings don't have
1982   imbued locales. In principle the "right" solution would be to
1983   provide an extra object, either a ctype facet or a full locale,
1984   which would be used to widen '0' and '1'. However, there was some
1985   discomfort about using such a heavyweight mechanism.  The proposed
1986   resolution allows those users who care about this issue to get it
1987   right.</p>
1988 <p>We fix the inserter to use the new arguments.  Note that we already
1989   fixed the analogous problem with the extractor in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>.</p>
1990
1991 <hr>
1992 <a name="397"><h3>397.&nbsp;ostream::sentry dtor throws exceptions</h3></a><p><b>Section:</b>&nbsp;27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Jan 2003</p>
1993     <p>
1994 17.4.4.8, p3 prohibits library dtors from throwing exceptions.
1995     </p>
1996     <p>
1997 27.6.2.3, p4 says this about the ostream::sentry dtor:
1998     </p>
1999     <pre>    -4- If ((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception())
2000         is true, calls os.flush().
2001     </pre>
2002     <p>
2003 27.6.2.6, p7 that describes ostream::flush() says:
2004     </p>
2005     <pre>    -7- If rdbuf() is not a null pointer, calls rdbuf()-&gt;pubsync().
2006         If that function returns ?-1 calls setstate(badbit) (which
2007         may throw ios_base::failure (27.4.4.3)).
2008     </pre>
2009     <p>
2010 That seems like a defect, since both pubsync() and setstate() can
2011 throw an exception.
2012     </p>
2013   <p><b>Proposed resolution:</b></p>
2014 <p><i>[
2015 The contradiction is real.  Clause 17 says destructors may never
2016 throw exceptions, and clause 27 specifies a destructor that does
2017 throw.  In principle we might change either one.  We're leaning
2018 toward changing clause 17: putting in an "unless otherwise specified"
2019 clause, and then putting in a footnote saying the sentry destructor
2020 is the only one that can throw.  PJP suggests specifying that
2021 sentry::~sentry() should internally catch any exceptions it might cause.
2022 ]</i></p>
2023 <hr>
2024 <a name="398"><h3>398.&nbsp;effects of end-of-file on unformatted input functions</h3></a><p><b>Section:</b>&nbsp;27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Jan 2003</p>
2025     <p>
2026 While reviewing unformatted input member functions of istream
2027 for their behavior when they encounter end-of-file during input
2028 I found that the requirements vary, sometimes unexpectedly, and
2029 in more than one case even contradict established practice (GNU
2030 libstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC
2031 5.38, Rogue Wave libstd 3.1, and Classic Iostreams).
2032     </p>
2033     <p>
2034 The following unformatted input member functions set eofbit if they
2035 encounter an end-of-file (this is the expected behavior, and also
2036 the behavior of all major implementations):
2037     </p>
2038     <p>
2039     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
2040     get (char_type*, streamsize, char_type);
2041     </pre>
2042     <p></p>
2043     <p>
2044     Also sets failbit if it fails to extract any characters.
2045     </p>
2046     <p>
2047     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
2048     get (char_type*, streamsize);
2049     </pre>
2050     <p></p>
2051     <p>
2052     Also sets failbit if it fails to extract any characters.
2053     </p>
2054     <p>
2055     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
2056     getline (char_type*, streamsize, char_type);
2057     </pre>
2058     <p></p>
2059     <p>
2060     Also sets failbit if it fails to extract any characters.
2061     </p>
2062     <p>
2063     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
2064     getline (char_type*, streamsize);
2065     </pre>
2066     <p></p>
2067     <p>
2068     Also sets failbit if it fails to extract any characters.
2069     </p>
2070     <p>
2071     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
2072     ignore (int, int_type);
2073     </pre>
2074     <p></p>
2075     <p>
2076     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
2077     read (char_type*, streamsize);
2078     </pre>
2079     <p></p>
2080     <p>
2081     Also sets failbit if it encounters end-of-file.
2082     </p>
2083     <p>
2084     </p><pre>    streamsize readsome (char_type*, streamsize);
2085     </pre>
2086     <p></p>
2087
2088     <p>
2089 The following unformated input member functions set failbit but
2090 not eofbit if they encounter an end-of-file (I find this odd
2091 since the functions make it impossible to distinguish a general
2092 failure from a failure due to end-of-file; the requirement is
2093 also in conflict with all major implementation which set both
2094 eofbit and failbit):
2095     </p>
2096     <p>
2097     </p><pre>    int_type get();
2098     </pre>
2099     <p></p>
2100     <p>
2101     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
2102     get (char_type&amp;);
2103     </pre>
2104     <p></p>
2105     <p>
2106 These functions only set failbit of they extract no characters,
2107 otherwise they don't set any bits, even on failure (I find this
2108 inconsistency quite unexpected; the requirement is also in
2109 conflict with all major implementations which set eofbit
2110 whenever they encounter end-of-file):
2111     </p>
2112     <p>
2113     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
2114     get (basic_streambuf&lt;charT, traits&gt;&amp;, char_type);
2115     </pre>
2116     <p></p>
2117     <p>
2118     </p><pre>    basic_istream&lt;charT, traits&gt;&amp;
2119     get (basic_streambuf&lt;charT, traits&gt;&amp;);
2120     </pre>
2121     <p></p>
2122     <p>
2123 This function sets no bits (all implementations except for
2124 STLport and Classic Iostreams set eofbit when they encounter
2125 end-of-file):
2126     </p>
2127     <p>
2128     </p><pre>    int_type peek ();
2129     </pre>
2130     <p></p>
2131   <p><b>Proposed resolution:</b></p>
2132 <p>Informally, what we want is a global statement of intent saying
2133   that eofbit gets set if we trip across EOF, and then we can take
2134   away the specific wording for individual functions.  A full review
2135   is necessary.  The wording currently in the standard is a mishmash,
2136   and changing it on an individual basis wouldn't make things better.
2137   Dietmar will do this work.</p>
2138 <hr>
2139 <a name="401"><h3>401.&nbsp; incorrect type casts in table 32 in lib.allocator.requirements</h3></a><p><b>Section:</b>&nbsp;20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;27 Feb 2003</p>
2140 <p>
2141 I think that in par2 of 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> the last two
2142 lines of table 32 contain two incorrect type casts. The lines are ...
2143 </p>
2144
2145 <pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
2146   a.destroy(p)       Effect: ((T*)p)?-&gt;~T()
2147 </pre>
2148
2149 <p>
2150 .... with the prerequisits coming from the preceding two paragraphs, especially
2151 from table 31:
2152 </p>
2153
2154 <pre>  alloc&lt;T&gt;             a     ;// an allocator for T
2155   alloc&lt;T&gt;::pointer    p     ;// random access iterator
2156                               // (may be different from T*)
2157   alloc&lt;T&gt;::reference  r = *p;// T&amp;
2158   T const&amp;             t     ;
2159 </pre>
2160
2161 <p>
2162 For that two type casts ("(void*)p" and "(T*)p") to be well-formed
2163 this would require then conversions to T* and void* for all
2164 alloc&lt;T&gt;::pointer, so it would implicitely introduce extra
2165 requirements for alloc&lt;T&gt;::pointer, additionally to the only
2166 current requirement (being a random access iterator).
2167 </p>
2168 <p><b>Proposed resolution:</b></p>
2169 <p>
2170 "(void*)p" should be replaced with "(void*)&amp;*p" and that
2171 "((T*)p)?-&gt;" should be replaced with "(*p)." or with
2172 "(&amp;*p)-&gt;".
2173 </p>
2174
2175 <p>
2176 Note: Actually I would prefer to replace "((T*)p)?-&gt;dtor_name" with
2177 "p?-&gt;dtor_name", but AFAICS this is not possible cause of an omission
2178 in 13.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/over.html#over.ref"> [over.ref]</a> (for which I have filed another DR on 29.11.2002).
2179 </p>
2180
2181 <p><i>[Kona: The LWG thinks this is somewhere on the border between
2182   Open and NAD.  The intend is clear: <tt>construct</tt> constructs an
2183   object at the location <i>p</i>.  It's reading too much into the
2184   description to think that literally calling <tt>new</tt> is
2185   required.  Tweaking this description is low priority until we can do
2186   a thorough review of allocators, and, in particular, allocators with
2187   non-default pointer types.]</i></p>
2188
2189 <hr>
2190 <a name="408"><h3>408.&nbsp;Is vector&lt;reverse_iterator&lt;char*&gt; &gt; forbidden?</h3></a><p><b>Section:</b>&nbsp;24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;3 June 2003</p>
2191 <p>
2192 I've been discussing iterator semantics with Dave Abrahams, and a
2193 surprise has popped up.  I don't think this has been discussed before.
2194 </p>
2195
2196 <p>
2197 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> says that the only operation that can be performed on "singular"
2198 iterator values is to assign a non-singular value to them.  (It
2199 doesn't say they can be destroyed, and that's probably a defect.)
2200 Some implementations have taken this to imply that there is no need
2201 to initialize the data member of a reverse_iterator&lt;&gt; in the default
2202 constructor.  As a result, code like
2203 </p>
2204 <blockquote>
2205   std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt; v(7);
2206   v.reserve(1000);
2207 </blockquote>
2208 <p>
2209 invokes undefined behavior, because it must default-initialize the
2210 vector elements, and then copy them to other storage.  Of course many
2211 other vector operations on these adapters are also left undefined,
2212 and which those are is not reliably deducible from the standard.
2213 </p>
2214
2215 <p>
2216 I don't think that 24.1 was meant to make standard-library iterator
2217 types unsafe.  Rather, it was meant to restrict what operations may
2218 be performed by functions which take general user- and standard
2219 iterators as arguments, so that raw pointers would qualify as
2220 iterators.  However, this is not clear in the text, others have come
2221 to the opposite conclusion.
2222 </p>
2223
2224 <p>
2225 One question is whether the standard iterator adaptors have defined
2226 copy semantics.  Another is whether they have defined destructor
2227 semantics: is
2228 </p>
2229 <blockquote>
2230   { std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt;  v(7); }
2231 </blockquote>
2232 <p>
2233 undefined too?
2234 </p>
2235
2236 <p>
2237 Note this is not a question of whether algorithms are allowed to
2238 rely on copy semantics for arbitrary iterators, just whether the
2239 types we actually supply support those operations.  I believe the
2240 resolution must be expressed in terms of the semantics of the
2241 adapter's argument type.  It should make clear that, e.g., the
2242 reverse_iterator&lt;T&gt; constructor is actually required to execute
2243 T(), and so copying is defined if the result of T() is copyable.
2244 </p>
2245
2246 <p>
2247 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, which defines reverse_iterator's default
2248 constructor more precisely, has some relevance to this issue.
2249 However, it is not the whole story.
2250 </p>
2251
2252 <p>
2253 The issue was whether
2254 </p>
2255 <blockquote>
2256   reverse_iterator() { }
2257 </blockquote>
2258 <p>
2259 is allowed, vs.
2260 </p>
2261 <blockquote>
2262   reverse_iterator() : current() { }
2263 </blockquote>
2264
2265 <p>
2266 The difference is when T is char*, where the first leaves the member
2267 uninitialized, and possibly equal to an existing pointer value, or
2268 (on some targets) may result in a hardware trap when copied.
2269 </p>
2270
2271 <p>
2272 8.5 paragraph 5 seems to make clear that the second is required to
2273 satisfy DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, at least for non-class Iterator argument
2274 types.
2275 </p>
2276
2277 <p>
2278 But that only takes care of reverse_iterator, and doesn't establish
2279 a policy for all iterators.  (The reverse iterator adapter was just
2280 an example.)  In particular, does my function
2281 </p>
2282 <blockquote>
2283   template &lt;typename Iterator&gt;
2284     void f() { std::vector&lt;Iterator&gt;  v(7); }
2285 </blockquote>
2286 <p>
2287 evoke undefined behavior for some conforming iterator definitions?
2288 I think it does, now, because vector&lt;&gt; will destroy those singular
2289 iterator values, and that's explicitly disallowed.
2290 </p>
2291
2292 <p>
2293 24.1 shouldn't give blanket permission to copy all singular iterators,
2294 because then pointers wouldn't qualify as iterators.  However, it
2295 should allow copying of that subset of singular iterator values that
2296 are default-initialized, and it should explicitly allow destroying any
2297 iterator value, singular or not, default-initialized or not.
2298 </p>
2299
2300 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a></p>
2301 <p><b>Proposed resolution:</b></p>
2302
2303 <p><i>[
2304 We don't want to require all singular iterators to be copyable,
2305 because that is not the case for pointers.  However, default
2306 construction may be a special case.  Issue: is it really default
2307 construction we want to talk about, or is it something like value
2308 initialization?  We need to check with core to see whether default
2309 constructed pointers are required to be copyable; if not, it would be
2310 wrong to impose so strict a requirement for iterators.
2311 ]</i></p>
2312
2313 <hr>
2314 <a name="416"><h3>416.&nbsp;definitions of XXX_MIN and XXX_MAX macros in climits</h3></a><p><b>Section:</b>&nbsp;18.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.c.limits"> [lib.c.limits]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
2315         <p>
2316
2317 Given two overloads of the function foo(), one taking an argument of type
2318 int and the other taking a long, which one will the call foo(LONG_MAX)
2319 resolve to? The expected answer should be foo(long), but whether that
2320 is true depends on the #defintion of the LONG_MAX macro, specifically
2321 its type. This issue is about the fact that the type of these macros
2322 is not actually required to be the same as the the type each respective
2323 limit.
2324 <br>
2325
2326 Section 18.2.2 of the C++ Standard does not specify the exact types of
2327 the XXX_MIN and XXX_MAX macros #defined in the &lt;climits&gt; and &lt;limits.h&gt;
2328 headers such as INT_MAX and LONG_MAX and instead defers to the C standard.
2329 <br>
2330
2331 Section 5.2.4.2.1, p1 of the C standard specifies that "The values [of
2332 these constants] shall be replaced by constant expressions suitable for use
2333 in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX,
2334 the following shall be replaced by expressions that have the same type as
2335 would an expression that is an object of the corresponding type converted
2336 according to the integer promotions."
2337 <br>
2338
2339 The "corresponding type converted according to the integer promotions" for
2340 LONG_MAX is, according to 6.4.4.1, p5 of the C standard, the type of long
2341 converted to the first of the following set of types that can represent it:
2342 int, long int, long long int. So on an implementation where (sizeof(long)
2343 == sizeof(int)) this type is actually int, while on an implementation where
2344 (sizeof(long) &gt; sizeof(int)) holds this type will be long.
2345 <br>
2346
2347 This is not an issue in C since the type of the macro cannot be detected
2348 by any conforming C program, but it presents a portability problem in C++
2349 where the actual type is easily detectable by overload resolution.
2350
2351         </p>
2352     <p><b>Proposed resolution:</b></p>
2353
2354 <p><i>[Kona: the LWG does not believe this is a defect.  The C macro
2355   definitions are what they are; we've got a better
2356   mechanism, <tt>std::numeric_limits</tt>, that is specified more
2357   precisely than the C limit macros.  At most we should add a
2358   nonnormative note recommending that users who care about the exact
2359   types of limit quantities should use &lt;limits&gt; instead of
2360   &lt;climits&gt;.]</i></p>
2361
2362 <hr>
2363 <a name="417"><h3>417.&nbsp;what does ctype::do_widen() return on failure</h3></a><p><b>Section:</b>&nbsp;22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
2364 <p>
2365 The Effects and Returns clauses of the do_widen() member function of
2366 the ctype facet fail to specify the behavior of the function on failure.
2367 That the function may not be able to simply cast the narrow character
2368 argument to the type of the result since doing so may yield the wrong value
2369 for some wchar_t encodings. Popular implementations of ctype&lt;wchar_t&gt; that
2370 use mbtowc() and UTF-8 as the native encoding (e.g., GNU glibc) will fail
2371 when the argument's MSB is set. There is no way for the the rest of locale
2372 and iostream to reliably detect this failure.
2373 </p>
2374 <p><b>Proposed resolution:</b></p>
2375 <p><i>[Kona: This is a real problem.  Widening can fail.  It's unclear
2376   what the solution should be.  Returning WEOF works for the wchar_t
2377   specialization, but not in general.  One option might be to add a
2378   default, like <i>narrow</i>.  But that's an incompatible change.
2379   Using <i>traits::eof</i> might seem like a good idea, but facets
2380   don't have access to traits (a recurring problem).  We could
2381   have <i>widen</i> throw an exception, but that's a scary option;
2382   existing library components aren't written with the assumption
2383   that <i>widen</i> can throw.]</i></p>
2384 <hr>
2385 <a name="418"><h3>418.&nbsp;exceptions thrown during iostream cleanup</h3></a><p><b>Section:</b>&nbsp;27.4.2.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::Init"> [lib.ios::Init]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
2386 <p>
2387 The dtor of the ios_base::Init object is supposed to call flush() on the
2388 6 standard iostream objects cout, cerr, clog, wcout, wcerr, and wclog.
2389 This call may cause an exception to be thrown.
2390 </p>
2391
2392 <p>
2393 17.4.4.8, p3 prohibits all library destructors from throwing exceptions.
2394 </p>
2395
2396 <p>
2397 The question is: What should this dtor do if one or more of these calls
2398 to flush() ends up throwing an exception? This can happen quite easily
2399 if one of the facets installed in the locale imbued in the iostream
2400 object throws.
2401 </p>
2402 <p><b>Proposed resolution:</b></p>
2403 <p><i>[Kona: We probably can't do much better than what we've got, so
2404   the LWG is leaning toward NAD.  At the point where the standard
2405   stream objects are being cleaned up, the usual error reporting
2406   mechanism are all unavailable.  And exception from flush at this
2407   point will definitely cause problems.  A quality implementation
2408   might reasonably swallow the exception, or call abort, or do
2409   something even more drastic.]</i></p>
2410 <hr>
2411 <a name="419"><h3>419.&nbsp;istream extractors not setting failbit if eofbit is already set</h3></a><p><b>Section:</b>&nbsp;27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
2412         <p>
2413
2414 27.6.1.1.2, p2 says that istream::sentry ctor prepares for input if is.good()
2415 is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to
2416 true if the stream state is good after any preparation. 27.6.1.2.1, p1 then
2417 says that a formatted input function endeavors to obtain the requested input
2418 if the sentry's operator bool() returns true.
2419
2420 Given these requirements, no formatted extractor should ever set failbit if
2421 the initial stream rdstate() == eofbit. That is contrary to the behavior of
2422 all implementations I tested. The program below prints out
2423
2424 eof = 1, fail = 0
2425 eof = 1, fail = 1
2426
2427 on all of them.
2428         </p>
2429 <pre>
2430 #include &lt;sstream&gt;
2431 #include &lt;cstdio&gt;
2432
2433 int main()
2434 {
2435     std::istringstream strm ("1");
2436
2437     int i = 0;
2438
2439     strm &gt;&gt; i;
2440
2441     std::printf ("eof = %d, fail = %d\n",
2442                  !!strm.eof (), !!strm.fail ());
2443
2444     strm &gt;&gt; i;
2445
2446     std::printf ("eof = %d, fail = %d\n",
2447                  !!strm.eof (), !!strm.fail ());
2448 }
2449
2450 </pre>
2451         <p>
2452 <br>
2453
2454 Comments from Jerry Schwarz (c++std-lib-11373):
2455 <br>
2456
2457 Jerry Schwarz wrote:
2458 <br>
2459
2460 I don't know where (if anywhere) it says it in the standard, but the
2461 formatted extractors are supposed to set failbit if they don't extract
2462 any characters. If they didn't then simple loops like
2463 <br>
2464
2465 while (cin &gt;&gt; x);
2466 <br>
2467
2468 would loop forever.
2469 <br>
2470
2471 Further comments from Martin Sebor:
2472 <br>
2473
2474 The question is which part of the extraction should prevent this from happening
2475 by setting failbit when eofbit is already set. It could either be the sentry
2476 object or the extractor. It seems that most implementations have chosen to
2477 set failbit in the sentry [...] so that's the text that will need to be
2478 corrected.
2479
2480         </p>
2481     <p><b>Proposed resolution:</b></p>
2482 <p>Kona: Possibly NAD.  If eofbit is set then good() will return false.  We
2483   then set <i>ok</i> to false.  We believe that the sentry's
2484   constructor should always set failbit when <i>ok</i> is false, and
2485   we also think the standard already says that.  Possibly it could be
2486   clearer.</p>
2487
2488 <hr>
2489 <a name="421"><h3>421.&nbsp;is basic_streambuf copy-constructible?</h3></a><p><b>Section:</b>&nbsp;27.5.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
2490 <p>
2491 The reflector thread starting with c++std-lib-11346 notes that the class
2492 template basic_streambuf, along with basic_stringbuf and basic_filebuf,
2493 is copy-constructible but that the semantics of the copy constructors
2494 are not defined anywhere. Further, different implementations behave
2495 differently in this respect: some prevent copy construction of objects
2496 of these types by declaring their copy ctors and assignment operators
2497 private, others exhibit undefined behavior, while others still give
2498 these operations well-defined semantics.
2499 </p>
2500
2501 <p>
2502 Note that this problem doesn't seem to be isolated to just the three
2503 types mentioned above. A number of other types in the library section
2504 of the standard provide a compiler-generated copy ctor and assignment
2505 operator yet fail to specify their semantics.  It's believed that the
2506 only types for which this is actually a problem (i.e. types where the
2507 compiler-generated default may be inappropriate and may not have been
2508 intended) are locale facets.  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#439">439</a>.
2509 </p>
2510 <p><b>Proposed resolution:</b></p>
2511 <p>
2512 27.5.2 [lib.streambuf]:  Add into the synopsis, public section, just above the destructor declaration:
2513 </p>
2514
2515 <blockquote>
2516 <pre>basic_streambuf(const basic_streambuf&amp; sb);
2517 basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
2518 </pre>
2519 </blockquote>
2520
2521 <p>Insert after 27.5.2.1, paragraph 2:</p>
2522 <blockquote>
2523 <pre>basic_streambuf(const basic_streambuf&amp; sb);
2524 </pre>
2525
2526 <p>Constructs a copy of sb.</p>
2527 <p>Postcondtions:</p>
2528 <pre>                eback() == sb.eback()
2529                 gptr()  == sb.gptr()
2530                 egptr() == sb.egptr()
2531                 pbase() == sb.pbase()
2532                 pptr()  == sb.pptr()
2533                 epptr() == sb.epptr()
2534                 getloc() == sb.getloc()
2535 </pre>
2536
2537 <pre>basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
2538 </pre>
2539
2540 <p>Assigns the data members of sb to this.</p>
2541
2542 <p>Postcondtions:</p>
2543 <pre>                eback() == sb.eback()
2544                 gptr()  == sb.gptr()
2545                 egptr() == sb.egptr()
2546                 pbase() == sb.pbase()
2547                 pptr()  == sb.pptr()
2548                 epptr() == sb.epptr()
2549                 getloc() == sb.getloc()
2550 </pre>
2551
2552 <p>Returns: *this.</p>
2553 </blockquote>
2554
2555 <p>27.7.1 [lib.stringbuf]:</p>
2556
2557 <b>Option A:</b>
2558
2559 <blockquote>
2560 <p>Insert into the basic_stringbuf synopsis in the private section:</p>
2561
2562 <pre>basic_stringbuf(const basic_stringbuf&amp;);             // not defined
2563 basic_stringbuf&amp; operator=(const basic_stringbuf&amp;);  // not defined
2564 </pre>
2565 </blockquote>
2566
2567 <b>Option B:</b>
2568
2569 <blockquote>
2570 <p>Insert into the basic_stringbuf synopsis in the public section:</p>
2571
2572 <pre>basic_stringbuf(const basic_stringbuf&amp; sb);
2573 basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);
2574 </pre>
2575
2576 <p>27.7.1.1, insert after paragraph 4:</p>
2577
2578 <pre>basic_stringbuf(const basic_stringbuf&amp; sb);</pre>
2579
2580 <p>
2581 Constructs an independent copy of sb as if with sb.str(), and with the openmode that sb was constructed with.
2582 </p>
2583
2584 <p>Postcondtions: </p>
2585 <pre>               str() == sb.str()
2586                gptr()  - eback() == sb.gptr()  - sb.eback()
2587                egptr() - eback() == sb.egptr() - sb.eback()
2588                pptr()  - pbase() == sb.pptr()  - sb.pbase()
2589                getloc() == sb.getloc()
2590 </pre>
2591
2592 <p>
2593 Note: The only requirement on epptr() is that it point beyond the
2594 initialized range if an output sequence exists. There is no requirement
2595 that epptr() - pbase() == sb.epptr() - sb.pbase().
2596 </p>
2597
2598 <pre>basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);</pre>
2599 <p>After assignment the basic_stringbuf has the same state as if it
2600 were initially copy constructed from sb, except that the
2601 basic_stringbuf is allowed to retain any excess capacity it might have,
2602 which may in turn effect the value of epptr().
2603 </p>
2604 </blockquote>
2605
2606 <p>27.8.1.1 [lib.filebuf]</p>
2607
2608 <p>Insert at the bottom of the basic_filebuf synopsis:</p>
2609
2610 <blockquote>
2611 <pre>private:
2612   basic_filebuf(const basic_filebuf&amp;);             // not defined
2613   basic_filebuf&amp; operator=(const basic_filebuf&amp;);  // not defined
2614 </pre>
2615 </blockquote>
2616 <p><i>[Kona: this is an issue for basic_streambuf itself and for its
2617   derived classes.  We are leaning toward allowing basic_streambuf to
2618   be copyable, and specifying its precise semantics.  (Probably the
2619   obvious: copying the buffer pointers.)  We are less sure whether
2620   the streambuf derived classes should be copyable.  Howard will
2621   write up a proposal.]</i></p>
2622
2623 <p><i>[Sydney: Dietmar presented a new argument against basic_streambuf
2624   being copyable: it can lead to an encapsulation violation. Filebuf
2625   inherits from streambuf. Now suppose you inhert a my_hijacking_buf
2626   from streambuf. You can copy the streambuf portion of a filebuf to a
2627   my_hijacking_buf, giving you access to the pointers into the
2628   filebuf's internal buffer. Perhaps not a very strong argument, but
2629   it was strong enough to make people nervous. There was weak
2630   preference for having streambuf not be copyable. There was weak
2631   preference for having stringbuf not be copyable even if streambuf
2632   is. Move this issue to open for now.
2633 ]</i></p>
2634
2635 <p><b>Rationale:</b></p>
2636 <p>
2637 27.5.2 [lib.streambuf]: The proposed basic_streambuf copy constructor
2638 and assignment operator are the same as currently implied by the lack
2639 of declarations: public and simply copies the data members.  This
2640 resolution is not a change but a clarification of the current
2641 standard.
2642 </p>
2643
2644 <p>
2645 27.7.1 [lib.stringbuf]: There are two reasonable options: A) Make
2646 basic_stringbuf not copyable.  This is likely the status-quo of
2647 current implementations.  B) Reasonable copy semantics of
2648 basic_stringbuf can be defined and implemented.  A copyable
2649 basic_streambuf is arguably more useful than a non-copyable one.  This
2650 should be considered as new functionality and not the fixing of a
2651 defect.  If option B is chosen, ramifications from issue 432 are taken
2652 into account.
2653 </p>
2654
2655 <p>
2656 27.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for
2657 basic_filebuf.
2658 </p>
2659
2660 <hr>
2661 <a name="422"><h3>422.&nbsp;explicit specializations of member functions of class templates</h3></a><p><b>Section:</b>&nbsp;17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
2662 <p>
2663 It has been suggested that 17.4.3.1, p1 may or may not allow programs to
2664 explicitly specialize members of standard templates on user-defined types.
2665 The answer to the question might have an impact where library requirements
2666 are given using the "as if" rule. I.e., if programs are allowed to specialize
2667 member functions they will be able to detect an implementation's strict
2668 conformance to Effects clauses that describe the behavior of the function
2669 in terms of the other member function (the one explicitly specialized by
2670 the program) by relying on the "as if" rule.
2671 </p>
2672 <p><b>Proposed resolution:</b></p>
2673
2674 <p>
2675   Add the following sentence immediately after the text of 17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>, p1:
2676 </p>
2677
2678 <blockquote>
2679     The behavior of a program that declares explicit specializations
2680     of any members of class templates or explicit specializations of
2681     any member templates of classes or class templates defined in
2682     this library is undefined.
2683 </blockquote>
2684
2685
2686 <p><i>[Kona: straw poll was 6-1 that user programs should not be
2687   allowed to specialize individual member functions of standard
2688   library class templates, and that doing so invokes undefined
2689   behavior. Post-Kona: Martin provided wording.]</i></p>
2690
2691 <p><i>[Sydney: The LWG agrees that the standard shouldn't permit users
2692 to specialize individual member functions unless they specialize the
2693 whole class, but we're not sure these words say what we want them to;
2694 they could be read as prohibiting the specialization of any standard
2695 library class templates. We need to consult with CWG to make sure we
2696 use the right wording.]</i></p>
2697
2698 <hr>
2699 <a name="423"><h3>423.&nbsp;effects of negative streamsize in iostreams</h3></a><p><b>Section:</b>&nbsp;27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
2700
2701 <p>
2702 A third party test suite tries to exercise istream::ignore(N) with
2703 a negative value of N and expects that the implementation will treat
2704 N as if it were 0. Our implementation asserts that (N &gt;= 0) holds and
2705 aborts the test.
2706 </p>
2707
2708 <p>
2709 I can't find anything in section 27 that prohibits such values but I don't
2710 see what the effects of such calls should be, either (this applies to
2711 a number of unformatted input functions as well as some member functions
2712 of the basic_streambuf template).
2713 </p>
2714 <p><b>Proposed resolution:</b></p>
2715 <p>
2716 I propose that we add to each function in clause 27 that takes an argument,
2717 say N, of type streamsize a Requires clause saying that "N &gt;= 0." The intent
2718 is to allow negative streamsize values in calls to precision() and width()
2719 but disallow it in calls to streambuf::sgetn(), istream::ignore(), or
2720 ostream::write().
2721 </p>
2722
2723 <p><i>[Kona: The LWG agreed that this is probably what we want.  However, we
2724   need a review to find all places where functions in clause 27 take
2725   arguments of type streamsize that shouldn't be allowed to go
2726   negative.  Martin will do that review.]</i></p>
2727
2728 <hr>
2729 <a name="424"><h3>424.&nbsp;normative notes</h3></a><p><b>Section:</b>&nbsp;17.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.structure.summary"> [lib.structure.summary]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
2730
2731 <p>
2732 The text in 17.3.1.1, p1 says:
2733 <br>
2734
2735 "Paragraphs labelled "Note(s):" or "Example(s):" are informative, other
2736 paragraphs are normative."
2737 <br>
2738
2739 The library section makes heavy use of paragraphs labeled "Notes(s),"
2740 some of which are clearly intended to be normative (see list 1), while
2741 some others are not (see list 2). There are also those where the intent
2742 is not so clear (see list 3).
2743 <br>
2744
2745 List 1 -- Examples of (presumably) normative Notes:
2746 <br>
2747
2748 20.4.1.1, p3, 20.4.1.1, p10, 21.3.1, p11, 22.1.1.2, p11, 23.2.1.3, p2,
2749 25.3.7, p3, 26.2.6, p14a, 27.5.2.4.3, p7.
2750 <br>
2751
2752 List 2 -- Examples of (presumably) informative Notes:
2753 <br>
2754
2755 18.4.1.3, p3, 21.3.5.6, p14, 22.2.1.5.2, p3, 25.1.1, p4, 26.2.5, p1,
2756 27.4.2.5, p6.
2757 <br>
2758
2759 List 3 -- Examples of Notes that are not clearly either normative
2760 or informative:
2761 <br>
2762
2763 22.1.1.2, p8, 22.1.1.5, p6, 27.5.2.4.5, p4.
2764 <br>
2765
2766 None of these lists is meant to be exhaustive.
2767 </p>
2768
2769 <p><b>Proposed resolution:</b></p>
2770
2771 <p><i>[Definitely a real problem.  The big problem is there's material
2772   that doesn't quite fit any of the named paragraph categories
2773   (e.g. <b>Effects</b>).  Either we need a new kind of named
2774   paragraph, or we need to put more material in unnamed paragraphs
2775   jsut after the signature.  We need to talk to the Project Editor
2776   about how to do this.
2777 ]</i></p>
2778
2779 <hr>
2780 <a name="427"><h3>427.&nbsp;stage 2 and rationale of DR 221</h3></a><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
2781 <p>
2782 The requirements specified in Stage 2 and reiterated in the rationale
2783 of DR 221 (and echoed again in DR 303) specify that num_get&lt;charT&gt;::
2784 do_get() compares characters on the stream against the widened elements
2785 of "012...abc...ABCX+-"
2786 </p>
2787
2788 <p>
2789 An implementation is required to allow programs to instantiate the num_get
2790 template on any charT that satisfies the requirements on a user-defined
2791 character type. These requirements do not include the ability of the
2792 character type to be equality comparable (the char_traits template must
2793 be used to perform tests for equality). Hence, the num_get template cannot
2794 be implemented to support any arbitrary character type. The num_get template
2795 must either make the assumption that the character type is equality-comparable
2796 (as some popular implementations do), or it may use char_traits&lt;charT&gt; to do
2797 the comparisons (some other popular implementations do that). This diversity
2798 of approaches makes it difficult to write portable programs that attempt to
2799 instantiate the num_get template on user-defined types.
2800 </p>
2801 <p><b>Proposed resolution:</b></p>
2802 <p><i>[Kona: the heart of the problem is that we're theoretically
2803   supposed to use traits classes for all fundamental character
2804   operations like assignment and comparison, but facets don't have
2805   traits parameters.  This is a fundamental design flaw and it
2806   appears all over the place, not just in this one place.  It's not
2807   clear what the correct solution is, but a thorough review of facets
2808   and traits is in order.  The LWG considered and rejected the
2809   possibility of changing numeric facets to use narrowing instead of
2810   widening.  This may be a good idea for other reasons (see issue
2811   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#459">459</a>), but it doesn't solve the problem raised by this
2812   issue.  Whether we use widen or narrow the <tt>num_get</tt> facet
2813   still has no idea which traits class the user wants to use for
2814   the comparison, because only streams, not facets, are passed traits
2815   classes.   The standard does not require that two different
2816   traits classes with the same <tt>char_type</tt> must necessarily
2817   have the same behavior.]</i></p>
2818
2819 <p>Informally, one possibility: require that some of the basic
2820 character operations, such as <tt>eq</tt>, <tt>lt</tt>,
2821 and <tt>assign</tt>, must behave the same way for all traits classes
2822 with the same <tt>char_type</tt>.  If we accept that limitation on
2823 traits classes, then the facet could reasonably be required to
2824 use <tt>char_traits&lt;charT&gt;</tt></p>.
2825
2826 <hr>
2827 <a name="430"><h3>430.&nbsp;valarray subset operations</h3></a><p><b>Section:</b>&nbsp;26.3.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.sub"> [lib.valarray.sub]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
2828 <p>
2829 The standard fails to specify the behavior of valarray::operator[](slice)
2830 and other valarray subset operations when they are passed an "invalid"
2831 slice object, i.e., either a slice that doesn't make sense at all (e.g.,
2832 slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray
2833 object (e.g., slice (2, 1, 1) for a valarray of size 1).
2834 </p>
2835 <p><b>Proposed resolution:</b></p>
2836 <p><i>[Kona: the LWG believes that invalid slices should invoke
2837   undefined behavior.  Valarrays are supposed to be designed for high
2838   performance, so we don't want to require specific checking.  We
2839   need wording to express this decision.]</i></p>
2840 <hr>
2841 <a name="431"><h3>431.&nbsp;Swapping containers with unequal allocators</h3></a><p><b>Section:</b>&nbsp;20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Sep 2003</p>
2842 <p>Clause 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> paragraph 4 says that implementations
2843   are permitted to supply containers that are unable to cope with
2844   allocator instances and that container implementations may assume
2845   that all instances of an allocator type compare equal.  We gave
2846   implementers this latitude as a temporary hack, and eventually we
2847   want to get rid of it.  What happens when we're dealing with
2848   allocators that <i>don't</i> compare equal?
2849 </p>
2850
2851 <p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
2852   objects of type <tt>vector&lt;int, my_alloc&gt;</tt> and that
2853   <tt>v1.get_allocator() != v2.get_allocator()</tt>.  What happens if
2854   we write <tt>v1.swap(v2)</tt>?  Informally, three possibilities:</p>
2855
2856 <p>1. This operation is illegal.  Perhaps we could say that an
2857   implementation is required to check and to throw an exception, or
2858   perhaps we could say it's undefined behavior.</p>
2859 <p>2. The operation performs a slow swap (i.e. using three
2860   invocations of <tt>operator=</tt>, leaving each allocator with its
2861   original container.  This would be an O(N) operation.</p>
2862 <p>3. The operation swaps both the vectors' contents and their
2863   allocators.  This would be an O(1) operation. That is:</p>
2864   <blockquote>
2865   <pre>    my_alloc a1(...);
2866     my_alloc a2(...);
2867     assert(a1 != a2);
2868
2869     vector&lt;int, my_alloc&gt; v1(a1);
2870     vector&lt;int, my_alloc&gt; v2(a2);
2871     assert(a1 == v1.get_allocator());
2872     assert(a2 == v2.get_allocator());
2873
2874     v1.swap(v2);
2875     assert(a1 == v2.get_allocator());
2876     assert(a2 == v1.get_allocator());
2877   </pre>
2878   </blockquote>
2879
2880 <p><b>Proposed resolution:</b></p>
2881
2882 <p><i>[Kona: This is part of a general problem.  We need a paper
2883   saying how to deal with unequal allocators in general.]</i></p>
2884
2885 <p><i>[pre-Sydney: Howard argues for option 3 in n1599.]</i></p>
2886
2887 <hr>
2888 <a name="446"><h3>446.&nbsp;Iterator equality between different containers</h3></a><p><b>Section:</b>&nbsp;24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>, 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Koenig&nbsp; <b>Date:</b>&nbsp;16 Dec 2003</p>
2889 <p>
2890 What requirements does the standard place on equality comparisons between
2891 iterators that refer to elements of different containers.  For example, if
2892 v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true?
2893 Is it allowed to throw an exception?
2894 </p>
2895
2896 <p>
2897 The standard appears to be silent on both questions.
2898 </p>
2899 <p><b>Proposed resolution:</b></p>
2900
2901 <p><i>[Sydney: The intention is that comparing two iterators from
2902 different containers is undefined, but it's not clear if we say that,
2903 or even whether it's something we should be saying in clause 23 or in
2904 clause 24.  Intuitively we might want to say that equality is defined
2905 only if one iterator is reachable from another, but figuring out how
2906 to say it in any sensible way is a bit tricky: reachability is defined
2907 in terms of equality, so we can't also define equality in terms of
2908 reachability.
2909 ]</i></p>
2910
2911 <hr>
2912 <a name="454"><h3>454.&nbsp;basic_filebuf::open should accept wchar_t names</h3></a><p><b>Section:</b>&nbsp;27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
2913 <pre>    basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
2914 </pre>
2915
2916 <p>should be supplemented with the overload:</p>
2917
2918 <pre>    basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
2919 </pre>
2920
2921 <p>
2922 Depending on the operating system, one of these forms is fundamental and
2923 the other requires an implementation-defined mapping to determine the
2924 actual filename.
2925 </p>
2926
2927 <p><i>[Sydney: Yes, we want to allow wchar_t filenames.  Bill will
2928   provide wording.]</i></p>
2929
2930 <p><b>Proposed resolution:</b></p>
2931
2932 <p>Change from:</p>
2933 <blockquote>
2934 <pre>basic_filebuf&lt;charT,traits&gt;* open(
2935         const char* s,
2936         ios_base::openmode mode );
2937 </pre>
2938
2939 <p>
2940 Effects: If is_open() != false, returns a null pointer.
2941 Otherwise, initializes the filebuf as required. It then
2942 opens a file, if possible, whose name is the NTBS s ("as if"
2943 by calling std::fopen(s,modstr)).</p>
2944 </blockquote>
2945
2946 <p>to:</p>
2947
2948 <blockquote>
2949 <pre>basic_filebuf&lt;charT,traits&gt;* open(
2950         const char* s,
2951         ios_base::openmode mode );
2952
2953 basic_filebuf&lt;charT,traits&gt;* open(
2954         const wchar_t* ws,
2955         ios_base::openmode mode );
2956 </pre>
2957
2958 <p>
2959 Effects: If is_open() != false, returns a null pointer.
2960 Otherwise, initializes the filebuf as required. It then
2961 opens a file, if possible, whose name is the NTBS s ("as if"
2962 by calling std::fopen(s,modstr)).
2963 For the second signature, the NTBS s is determined from the
2964 WCBS ws in an implementation-defined manner.
2965 </p>
2966
2967 <p>
2968 (NOTE: For a system that "naturally" represents a filename
2969 as a WCBS, the NTBS s in the first signature may instead
2970 be mapped to a WCBS; if so, it follows the same mapping
2971 rules as the first argument to open.)
2972 </p>
2973 </blockquote>
2974
2975 <p><b>Rationale:</b></p>
2976 <p>
2977 Slightly controversial, but by a 7-1 straw poll the LWG agreed to move
2978 this to Ready.  The controversy was because the mapping between wide
2979 names and files in a filesystem is implementation defined.  The
2980 counterargument, which most but not all LWG members accepted, is that
2981 the mapping between narrow files names and files is also
2982 implemenation defined.</p>
2983
2984 <p><i>[Lillehammer: Moved back to "open" status, at Beman's urging.
2985 (1) Why just basic_filebuf, instead of also basic_fstream (and
2986 possibly other things too). (2) Why not also constructors that take
2987 std::basic_string? (3) We might want to wait until we see Beman's
2988 filesystem library; we might decide that it obviates this.]</i></p>
2989
2990 <hr>
2991 <a name="456"><h3>456.&nbsp;Traditional C header files are overspecified</h3></a><p><b>Section:</b>&nbsp;17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
2992
2993 <p>The C++ Standard effectively requires that the traditional C headers
2994 (of the form &lt;xxx.h&gt;) be defined in terms of the newer C++
2995 headers (of the form &lt;cxxx&gt;). Clauses 17.4.1.2/4 and D.5 combine
2996 to require that:</p>
2997
2998 <ul>
2999  <li>Including the header &lt;cxxx&gt; declares a C name in namespace std.</li>
3000
3001  <li> Including the header &lt;xxx.h&gt; declares a C name in namespace std
3002     (effectively by including &lt;cxxx&gt;), then imports it into the global
3003     namespace with an individual using declaration.</li>
3004 </ul>
3005
3006 <p>
3007 The rules were left in this form despited repeated and heated objections
3008 from several compiler vendors. The C headers are often beyond the direct
3009 control of C++ implementors. In some organizations, it's all they can do
3010 to get a few #ifdef __cplusplus tests added. Third-party library vendors
3011 can perhaps wrap the C headers. But neither of these approaches supports
3012 the drastic restructuring required by the C++ Standard. As a result, it is
3013 still widespread practice to ignore this conformance requirement, nearly
3014 seven years after the committee last debated this topic. Instead, what is
3015 often implemented is:
3016 </p>
3017
3018 <ul>
3019  <li> Including the header &lt;xxx.h&gt; declares a C name in the
3020  global namespace.</li>
3021
3022  <li> Including the header &lt;cxxx&gt; declares a C name in the
3023  global namespace (effectively by including &lt;xxx.h&gt;), then
3024  imports it into namespace std with an individual using declaration.</li>
3025 </ul>
3026
3027 <p>
3028 The practical benefit for implementors with the second approach is that
3029 they can use existing C library headers, as they are pretty much obliged
3030 to do. The practical cost for programmers facing a mix of implementations
3031 is that they have to assume weaker rules:</p>
3032
3033 <ul>
3034   <li> If you want to assuredly declare a C name in the global
3035   namespace, include &lt;xxx.h&gt;. You may or may not also get the
3036   declaration in namespace std.</li>
3037
3038   <li> If you want to assuredly declare a C name in namespace std,
3039   include &lt;cxxx.h&gt;. You may or may not also get the declaration in
3040   the global namespace.</li>
3041 </ul>
3042
3043 <p>
3044 There also exists the <i>possibility</i> of subtle differences due to
3045 Koenig lookup, but there are so few non-builtin types defined in the C
3046 headers that I've yet to see an example of any real problems in this
3047 area.
3048 </p>
3049
3050 <p>
3051 It is worth observing that the rate at which programmers fall afoul of
3052 these differences has remained small, at least as measured by newsgroup
3053 postings and our own bug reports. (By an overwhelming margin, the
3054 commonest problem is still that programmers include &lt;string&gt; and can't
3055 understand why the typename string isn't defined -- this a decade after
3056 the committee invented namespace std, nominally for the benefit of all
3057 programmers.)
3058 </p>
3059
3060 <p>
3061 We should accept the fact that we made a serious mistake and rectify it,
3062 however belatedly, by explicitly allowing either of the two schemes for
3063 declaring C names in headers.
3064 </p>
3065
3066 <p><i>[Sydney: This issue has been debated many times, and will
3067   certainly have to be discussed in full committee before any action
3068   can be taken.  However, the preliminary sentiment of the LWG was in
3069   favor of the change.  (6 yes, 0 no, 2 abstain) Robert Klarer
3070   suggests that we might also want to undeprecate the
3071   C-style <tt>.h</tt> headers.]</i></p>
3072
3073 <p><b>Proposed resolution:</b></p>
3074 <hr>
3075 <a name="458"><h3>458.&nbsp;24.1.5 contains unintented limitation for operator-</h3></a><p><b>Section:</b>&nbsp;24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Daniel Frey&nbsp; <b>Date:</b>&nbsp;27 Feb 2004</p>
3076 <p>
3077 In 24.1.5 [lib.random.access.iterators], table 76 the operational
3078 semantics for the expression "r -= n" are defined as "return r += -n".
3079 This means, that the expression -n must be valid, which is not the case
3080 for unsigned types.
3081 </p>
3082
3083 <p><i>[
3084 Sydney: Possibly not a real problem, since difference type is required
3085 to be a signed integer type. However, the wording in the standard may
3086 be less clear than we would like.
3087 ]</i></p>
3088
3089 <p><b>Proposed resolution:</b></p>
3090 <p>
3091 To remove this limitation, I suggest to change the
3092 operational semantics for this column to:
3093 </p>
3094 <code>
3095     { Distance m = n;
3096       if (m &gt;= 0)
3097         while (m--) --r;
3098       else
3099         while (m++) ++r;
3100       return r; }
3101 </code>
3102
3103 <hr>
3104 <a name="459"></a><h3><a name="459">459.&nbsp;Requirement for widening in stage 2 is overspecification</a></h3><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;16 Mar 2004</p>
3105 <p>When parsing strings of wide-character digits, the standard
3106   requires the library to widen narrow-character "atoms" and compare
3107   the widened atoms against the characters that are being parsed.
3108   Simply narrowing the wide characters would be far simpler, and
3109   probably more efficient.  The two choices are equivalent except in
3110   convoluted test cases, and many implementations already ignore the
3111   standard and use narrow instead of widen.</p>
3112
3113 <p>
3114 First, I disagree that using narrow() instead of widen() would
3115 necessarily have unfortunate performance implications. A possible
3116 implementation of narrow() that allows num_get to be implemented
3117 in a much simpler and arguably comparably efficient way as calling
3118 widen() allows, i.e. without making a virtual call to do_narrow every
3119 time, is as follows:
3120 </p>
3121
3122 <pre>  inline char ctype&lt;wchar_t&gt;::narrow (wchar_t wc, char dflt) const
3123   {
3124       const unsigned wi = unsigned (wc);
3125
3126       if (wi &gt; UCHAR_MAX)
3127           return typeid (*this) == typeid (ctype&lt;wchar_t&gt;) ?
3128                  dflt : do_narrow (wc, dflt);
3129
3130       if (narrow_ [wi] &lt; 0) {
3131          const char nc = do_narrow (wc, dflt);
3132          if (nc == dflt)
3133              return dflt;
3134          narrow_ [wi] = nc;
3135       }
3136
3137       return char (narrow_ [wi]);
3138   }
3139 </pre>
3140
3141 <p>
3142 Second, I don't think the change proposed in the issue (i.e., to use
3143 narrow() instead of widen() during Stage 2) would be at all
3144 drastic. Existing implementations with the exception of libstdc++
3145 currently already use narrow() so the impact of the change on programs
3146 would presumably be isolated to just a single implementation. Further,
3147 since narrow() is not required to translate alternate wide digit
3148 representations such as those mentioned in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> to
3149 their narrow equivalents (i.e., the portable source characters '0'
3150 through '9'), the change does not necessarily imply that these
3151 alternate digits would be treated as ordinary digits and accepted as
3152 part of numbers during parsing. In fact, the requirement in 22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>, p13 forbids narrow() to translate an alternate
3153 digit character, wc, to an ordinary digit in the basic source
3154 character set unless the expression
3155 (ctype&lt;charT&gt;::is(ctype_base::digit, wc) == true) holds. This in
3156 turn is prohibited by the C standard (7.25.2.1.5, 7.25.2.1.5, and
3157 5.2.1, respectively) for charT of either char or wchar_t.
3158 </p>
3159
3160 <p><i>[Sydney: To a large extent this is a nonproblem. As long as
3161 you're only trafficking in char and wchar_t we're only dealing with a
3162 stable character set, so you don't really need either 'widen' or
3163 'narrow': can just use literals. Finally, it's not even clear whether
3164 widen-vs-narrow is the right question; arguably we should be using
3165 codecvt instead.]</i></p>
3166
3167 <p><b>Proposed resolution:</b></p>
3168 <p>Change stage 2 so that implementations are permitted to use either
3169 technique to perform the comparison:</p>
3170 <ol>
3171   <li> call widen on the atoms and compare (either by using
3172       operator== or char_traits&lt;charT&gt;::eq) the input with
3173       the widened atoms, or</li>
3174   <li> call narrow on the input and compare the narrow input
3175       with the atoms</li>
3176   <li> do (1) or (2) only if charT is not char or wchar_t,
3177       respectively; i.e., avoid calling widen or narrow
3178       if it the source and destination types are the same</li>
3179 </ol>
3180 <hr>
3181 <a name="462"><h3>462.&nbsp;Destroying objects with static storage duration</h3></a><p><b>Section:</b>&nbsp;3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.start.term"> [basic.start.term]</a>, 18.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.start.term"> [lib.support.start.term]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;23 Mar 2004</p>
3182 <p>
3183 3.6.3 Termination spells out in detail the interleaving of static
3184 destructor calls and calls to functions registered with atexit. To
3185 match this behavior requires intimate cooperation between the code
3186 that calls destructors and the exit/atexit machinery. The former
3187 is tied tightly to the compiler; the latter is a primitive mechanism
3188 inherited from C that traditionally has nothing to do with static
3189 construction and destruction. The benefits of intermixing destructor
3190 calls with atexit handler calls is questionable at best, and <i>very</i>
3191 difficult to get right, particularly when mixing third-party C++
3192 libraries with different third-party C++ compilers and C libraries
3193 supplied by still other parties.
3194 </p>
3195
3196 <p>
3197 I believe the right thing to do is defer all static destruction
3198 until after all atexit handlers are called. This is a change in
3199 behavior, but one that is likely visible only to perverse test
3200 suites. At the very least, we should <i>permit</i> deferred destruction
3201 even if we don't require it.
3202 </p>
3203 <p><b>Proposed resolution:</b></p>
3204
3205 <p><i>[If this is to be changed, it should probably be changed by CWG.
3206   At this point, however, the LWG is leaning toward NAD.  Implementing
3207   what the standard says is hard work, but it's not impossible and
3208   most vendors went through that pain years ago.  Changing this
3209   behavior would be a user-visible change, and would break at least
3210   one real application.]</i></p>
3211
3212 <p>
3213 </p>
3214 <hr>
3215 <a name="463"><h3>463.&nbsp;auto_ptr usability issues</h3></a><p><b>Section:</b>&nbsp;20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Rani Sharoni&nbsp; <b>Date:</b>&nbsp;7 Dec 2003</p>
3216
3217 <p>
3218 TC1 CWG DR #84 effectively made the template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;()
3219 member of auto_ptr (20.4.5.3/4) obsolete.
3220 </p>
3221
3222 <p>
3223 The sole purpose of this obsolete conversion member is to enable copy
3224 initialization base from r-value derived (or any convertible types like
3225 cv-types) case:
3226 </p>
3227 <pre>#include &lt;memory&gt;
3228 using std::auto_ptr;
3229
3230 struct B {};
3231 struct D : B {};
3232
3233 auto_ptr&lt;D&gt; source();
3234 int sink(auto_ptr&lt;B&gt;);
3235 int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
3236 </pre>
3237
3238 <p>
3239 The excellent analysis of conversion operations that was given in the final
3240 auto_ptr proposal
3241 (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
3242 explicitly specifies this case analysis (case 4). DR #84 makes the analysis
3243 wrong and actually comes to forbid the loophole that was exploited by the
3244 auto_ptr designers.
3245 </p>
3246
3247 <p>
3248 I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
3249 ever allowed this case. This is probably because it requires 3 user defined
3250 conversions and in fact current compilers conform to DR #84.
3251 </p>
3252
3253 <p>
3254 I was surprised to discover that the obsolete conversion member actually has
3255 negative impact of the copy initialization base from l-value derived
3256 case:</p>
3257 <pre>auto_ptr&lt;D&gt; dp;
3258 int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
3259 </pre>
3260
3261 <p>
3262 I'm sure that the original intention was allowing this initialization using
3263 the template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;&amp; a) constructor (20.4.5.1/4) but
3264 since in this copy initialization it's merely user defined conversion (UDC)
3265 and the obsolete conversion member is UDC with the same rank (for the early
3266 overloading stage) there is an ambiguity between them.
3267 </p>
3268
3269 <p>
3270 Removing the obsolete member will have impact on code that explicitly
3271 invokes it:
3272 </p>
3273 <pre>int y = sink(source().operator auto_ptr&lt;B&gt;());
3274 </pre>
3275
3276 <p>
3277 IMHO no one ever wrote such awkward code and the reasonable workaround for
3278 #1 is:
3279 </p>
3280 <pre>int y = sink( auto_ptr&lt;B&gt;(source()) );
3281 </pre>
3282
3283 <p>
3284 I was even more surprised to find out that after removing the obsolete
3285 conversion member the initialization was still ill-formed:
3286 int x3 = sink(dp); // #3 EDG - no suitable copy constructor
3287 </p>
3288
3289 <p>
3290 This copy initialization semantically requires copy constructor which means
3291 that both template conversion constructor and the auto_ptr_ref conversion
3292 member (20.4.5.3/3) are required which is what was explicitly forbidden in
3293 DR #84. This is a bit amusing case in which removing ambiguity results with
3294 no candidates.
3295 </p>
3296
3297 <p>
3298 I also found exception safety issue with auto_ptr related to auto_ptr_ref:
3299 </p>
3300 <pre>int f(auto_ptr&lt;B&gt;, std::string);
3301 auto_ptr&lt;B&gt; source2();
3302
3303 // string constructor throws while auto_ptr_ref
3304 // "holds" the pointer
3305 int x4 = f(source2(), "xyz"); // #4
3306 </pre>
3307
3308 <p>
3309 The theoretic execution sequence that will cause a leak:
3310 </p>
3311 <ol>
3312 <li>call auto_ptr&lt;B&gt;::operator auto_ptr_ref&lt;B&gt;()</li>
3313 <li>call string::string(char const*) and throw</li>
3314 </ol>
3315
3316 <p>
3317 According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
3318 returns auto_ptr_ref&lt;Y&gt; that holds *this and this is another defect since
3319 the type of *this is auto_ptr&lt;X&gt; where X might be different from Y. Several
3320 library vendors (e.g. SGI) implement auto_ptr_ref&lt;Y&gt; with Y* as member which
3321 is much more reasonable. Other vendor implemented auto_ptr_ref as
3322 defectively required and it results with awkward and catastrophic code:
3323 int oops = sink(auto_ptr&lt;B&gt;(source())); // warning recursive on all control
3324 paths
3325 </p>
3326
3327 <p>
3328 Dave Abrahams noticed that there is no specification saying that
3329 auto_ptr_ref copy constructor can't throw.
3330 </p>
3331
3332 <p>
3333 My proposal comes to solve all the above issues and significantly simplify
3334 auto_ptr implementation. One of the fundamental requirements from auto_ptr
3335 is that it can be constructed in an intuitive manner (i.e. like ordinary
3336 pointers) but with strict ownership semantics which yield that source
3337 auto_ptr in initialization must be non-const. My idea is to add additional
3338 constructor template with sole propose to generate ill-formed, diagnostic
3339 required, instance for const auto_ptr arguments during instantiation of
3340 declaration. This special constructor will not be instantiated for other
3341 types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
3342 in hand makes the constructor template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;)
3343 legitimate since the actual argument can't be const yet non const r-value
3344 are acceptable.
3345 </p>
3346
3347 <p>
3348 This implementation technique makes the "private auxiliary class"
3349 auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
3350 GCC and VC) consume the new implementation as expected and allow all
3351 intuitive initialization and assignment cases while rejecting illegal cases
3352 that involve const auto_ptr arguments.
3353 </p>
3354
3355 <p>The proposed auto_ptr interface:</p>
3356
3357 <pre>namespace std {
3358     template&lt;class X&gt; class auto_ptr {
3359     public:
3360         typedef X element_type;
3361
3362         // 20.4.5.1 construct/copy/destroy:
3363         explicit auto_ptr(X* p=0) throw();
3364         auto_ptr(auto_ptr&amp;) throw();
3365         template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;) throw();
3366         auto_ptr&amp; operator=(auto_ptr&amp;) throw();
3367         template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;) throw();
3368         ~auto_ptr() throw();
3369
3370         // 20.4.5.2 members:
3371         X&amp; operator*() const throw();
3372         X* operator-&gt;() const throw();
3373         X* get() const throw();
3374         X* release() throw();
3375         void reset(X* p=0) throw();
3376
3377     private:
3378         template&lt;class U&gt;
3379         auto_ptr(U&amp; rhs, typename
3380 unspecified_error_on_const_auto_ptr&lt;U&gt;::type = 0);
3381     };
3382 }
3383 </pre>
3384
3385 <p>
3386 One compliant technique to implement the unspecified_error_on_const_auto_ptr
3387 helper class is using additional private auto_ptr member class template like
3388 the following:
3389 </p>
3390 <pre>template&lt;typename T&gt; struct unspecified_error_on_const_auto_ptr;
3391
3392 template&lt;typename T&gt;
3393 struct unspecified_error_on_const_auto_ptr&lt;auto_ptr&lt;T&gt; const&gt;
3394 { typedef typename auto_ptr&lt;T&gt;::const_auto_ptr_is_not_allowed type; };
3395 </pre>
3396
3397 <p>
3398 There are other techniques to implement this helper class that might work
3399 better for different compliers (i.e. better diagnostics) and therefore I
3400 suggest defining its semantic behavior without mandating any specific
3401 implementation. IMO, and I didn't found any compiler that thinks otherwise,
3402 14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
3403 verifying this with core language experts.
3404 </p>
3405
3406 <p><b>Further changes in standard text:</b></p>
3407 <p>Remove section 20.4.5.3</p>
3408
3409 <p>Change 20.4.5/2 to read something like:
3410 Initializing auto_ptr&lt;X&gt; from const auto_ptr&lt;Y&gt; will result with unspecified
3411 ill-formed declaration that will require unspecified diagnostic.</p>
3412
3413 <p>Change 20.4.5.1/4,5,6 to read:</p>
3414
3415 <pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp; a) throw();</pre>
3416 <p> 4 Requires: Y* can be implicitly converted to X*.</p>
3417 <p> 5 Effects: Calls const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(a).release().</p>
3418 <p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
3419
3420 <p>Change 20.4.5.1/10</p>
3421 <pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt; a) throw();
3422 </pre>
3423 <p>
3424 10 Requires: Y* can be implicitly converted to X*. The expression delete
3425 get() is well formed.
3426 </p>
3427
3428 <p>LWG TC DR #127 is obsolete.</p>
3429
3430 <p>
3431 Notice that the copy constructor and copy assignment operator should remain
3432 as before and accept non-const auto_ptr&amp; since they have effect on the form
3433 of the implicitly declared copy constructor and copy assignment operator of
3434 class that contains auto_ptr as member per 12.8/5,10:
3435 </p>
3436 <pre>struct X {
3437     // implicit X(X&amp;)
3438     // implicit X&amp; operator=(X&amp;)
3439     auto_ptr&lt;D&gt; aptr_;
3440 };
3441 </pre>
3442
3443 <p>
3444 In most cases this indicates about sloppy programming but preserves the
3445 current auto_ptr behavior.
3446 </p>
3447
3448 <p>
3449 Dave Abrahams encouraged me to suggest fallback implementation in case that
3450 my suggestion that involves removing of auto_ptr_ref will not be accepted.
3451 In this case removing the obsolete conversion member to auto_ptr&lt;Y&gt; and
3452 20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
3453 cases. The two constructors that I suggested will co exist with the current
3454 members but will make auto_ptr_ref obsolete in initialization contexts.
3455 auto_ptr_ref will be effective in assignment contexts as suggested in DR
3456 #127 and I can't see any serious exception safety issues in those cases
3457 (although it's possible to synthesize such). auto_ptr_ref&lt;X&gt; semantics will
3458 have to be revised to say that it strictly holds pointer of type X and not
3459 reference to an auto_ptr for the favor of cases in which auto_ptr_ref&lt;Y&gt; is
3460 constructed from auto_ptr&lt;X&gt; in which X is different from Y (i.e. assignment
3461 from r-value derived to base).
3462 </p>
3463
3464 <p><b>Proposed resolution:</b></p>
3465 <p><i>[Redmond: punt for the moment. We haven't decided yet whether we
3466   want to fix auto_ptr for C++-0x, or remove it and replace it with
3467   move_ptr and unique_ptr.]</i></p>
3468 <hr>
3469 <a name="466"><h3>466.&nbsp;basic_string ctor should prevent null pointer error</h3></a><p><b>Section:</b>&nbsp;21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Daniel Frey&nbsp; <b>Date:</b>&nbsp;10 Jun 2004</p>
3470 <p>
3471 Today, my colleagues and me wasted a lot of time. After some time, I
3472 found the problem. It could be reduced to the following short example:
3473 </p>
3474
3475 <pre>  #include &lt;string&gt;
3476   int main() { std::string( 0 ); }
3477 </pre>
3478
3479 <p>The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and
3480 Comeau online) compile the above without errors or warnings! The
3481 programs (at least for the GCC) resulted in a SEGV.</p>
3482
3483 <p>I know that the standard explicitly states that the ctor of string
3484 requires a char* which is not zero. STLs could easily detect the above
3485 case with a private ctor for basic_string which takes a single 'int'
3486 argument. This would catch the above code at compile time and would not
3487 ambiguate any other legal ctors.</p>
3488
3489 <p><b>Proposed resolution:</b></p>
3490 <p><i>[Redmond: No great enthusiasm for doing this.  If we do,
3491   however, we want to do it for all places that take <tt>charT*</tt>
3492   pointers, not just the single-argument constructor.  The other
3493   question is whether we want to catch this at compile time (in which
3494   case we catch the error of a literal 0, but not an expression whose
3495   value is a null pointer), at run time, or both.]</i></p>
3496
3497 <hr>
3498 <a name="470"><h3>470.&nbsp;accessing containers from their elements' special functions</h3></a><p><b>Section:</b>&nbsp;23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.containers"> [lib.containers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
3499
3500 <p>
3501 The standard doesn't prohibit the destructors (or any other special
3502 functions) of containers' elements invoked from a member function
3503 of the container from "recursively" calling the same (or any other)
3504 member function on the same container object, potentially while the
3505 container is in an intermediate state, or even changing the state
3506 of the container object while it is being modified. This may result
3507 in some surprising (i.e., undefined) behavior.
3508 </p>
3509
3510 <p>Read email thread starting with c++std-lib-13637 for more.</p>
3511
3512 <p><b>Proposed resolution:</b></p>
3513
3514 <p>Add to Container Requirements the following new paragraph:</p>
3515
3516 <pre>    Unless otherwise specified, the behavior of a program that
3517     invokes a container member function f from a member function
3518     g of the container's value_type on a container object c that
3519     called g from its mutating member function h, is undefined.
3520     I.e., if v is an element of c, directly or indirectly calling
3521     c.h() from v.g() called from c.f(), is undefined.
3522 </pre>
3523
3524 <p><i>[Redmond: This is a real issue, but it's probably a clause 17
3525   issue, not clause 23.  We get the same issue, for example, if we
3526   try to destroy a stream from one of the stream's callback functions.]</i></p>
3527
3528
3529 <hr>
3530 <a name="471"><h3>471.&nbsp;result of what() implementation-defined</h3></a><p><b>Section:</b>&nbsp;18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.exception"> [lib.exception]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
3531
3532 <p>[lib.exception] specifies the following:</p>
3533 <pre>    exception (const exception&amp;) throw();
3534     exception&amp; operator= (const exception&amp;) throw();
3535
3536     -4- Effects: Copies an exception object.
3537     -5- Notes: The effects of calling what() after assignment
3538         are implementation-defined.
3539 </pre>
3540
3541 <p>
3542 First, does the Note only apply to the assignment operator? If so,
3543 what are the effects of calling what() on a copy of an object? Is
3544 the returned pointer supposed to point to an identical copy of
3545 the NTBS returned by what() called on the original object or not?
3546 </p>
3547
3548 <p>
3549 Second, is this Note intended to extend to all the derived classes
3550 in section 19? I.e., does the standard provide any guarantee for
3551 the effects of what() called on a copy of any of the derived class
3552 described in section 19?
3553 </p>
3554
3555 <p>
3556 Finally, if the answer to the first question is no, I believe it
3557 constitutes a defect since throwing an exception object typically
3558 implies invoking the copy ctor on the object. If the answer is yes,
3559 then I believe the standard ought to be clarified to spell out
3560 exactly what the effects are on the copy (i.e., after the copy
3561 ctor was called).
3562 </p>
3563
3564 <p><i>[Redmond: Yes, this is fuzzy.  The issue of derived classes is
3565   fuzzy too.]</i></p>
3566
3567 <p><b>Proposed resolution:</b></p>
3568 <hr>
3569 <a name="473"><h3>473.&nbsp;underspecified ctype calls</h3></a><p><b>Section:</b>&nbsp;22.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype"> [lib.locale.ctype]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;1 Jul 2004</p>
3570 <p>
3571 Most ctype member functions come in two forms: one that operates
3572 on a single character at a time and another form that operates
3573 on a range of characters. Both forms are typically described by
3574 a single Effects and/or Returns clause.
3575 </p>
3576 <p>
3577 The Returns clause of each of the single-character non-virtual forms
3578 suggests that the function calls the corresponding single character
3579 virtual function, and that the array form calls the corresponding
3580 virtual array form. Neither of the two forms of each virtual member
3581 function is required to be implemented in terms of the other.
3582 </p>
3583 <p>
3584 There are three problems:
3585 </p>
3586 <p>
3587 1. One is that while the standard does suggest that each non-virtual
3588 member function calls the corresponding form of the virtual function,
3589 it doesn't actually explicitly require it.
3590 </p>
3591 <p>
3592 Implementations that cache results from some of the virtual member
3593 functions for some or all values of their arguments might want to
3594 call the array form from the non-array form the first time to fill
3595 the cache and avoid any or most subsequent virtual calls. Programs
3596 that rely on each form of the virtual function being called from
3597 the corresponding non-virtual function will see unexpected behavior
3598 when using such implementations.
3599 </p>
3600 <p>
3601 2. The second problem is that either form of each of the virtual
3602 functions can be overridden by a user-defined function in a derived
3603 class to return a value that is different from the one produced by
3604 the virtual function of the alternate form that has not been
3605 overriden.
3606 </p>
3607 <p>
3608 Thus, it might be possible for, say, ctype::widen(c) to return one
3609 value, while for ctype::widen(&amp;c, &amp;c + 1, &amp;wc) to set
3610 wc to another value. This is almost certainly not intended. Both
3611 forms of every function should be required to return the same result
3612 for the same character, otherwise the same program using an
3613 implementation that calls one form of the functions will behave
3614 differently than when using another implementation that calls the
3615 other form of the function "under the hood."
3616 </p>
3617 <p>
3618 3. The last problem is that the standard text fails to specify whether
3619 one form of any of the virtual functions is permitted to be implemented
3620 in terms of the other form or not, and if so, whether it is required
3621 or permitted to call the overridden virtual function or not.
3622 </p>
3623 <p>
3624 Thus, a program that overrides one of the virtual functions so that
3625 it calls the other form which then calls the base member might end
3626 up in an infinite loop if the called form of the base implementation
3627 of the function in turn calls the other form.
3628 </p>
3629 <p><b>Proposed resolution:</b></p>
3630
3631 <p>
3632 Lillehammer: Part of this isn't a real problem. We already talk about
3633 caching. 22.1.1/6 But part is a real problem. ctype virtuals may call
3634 each other, so users don't know which ones to override to avoid avoid
3635 infinite loops.</p>
3636
3637 <p>This is a problem for all facet virtuals, not just ctype virtuals,
3638 so we probably want a blanket statement in clause 22 for all
3639 facets. The LWG is leaning toward a blanket prohibition, that a
3640 facet's virtuals may never call each other. We might want to do that
3641 in clause 27 too, for that matter. A review is necessary.  Bill will
3642 provide wording.</p>
3643 <hr>
3644 <a name="475"><h3>475.&nbsp;May the function object passed to for_each modify the elements of the iterated sequence?</h3></a><p><b>Section:</b>&nbsp;25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Stephan T. Lavavej, Jaakko Jarvi&nbsp; <b>Date:</b>&nbsp;9 Jul 2004</p>
3645 <p>
3646 It is not clear whether the function object passed to for_each is allowed to
3647 modify the elements of the sequence being iterated over.
3648 </p>
3649
3650 <p>
3651 for_each is classified without explanation in [lib.alg.nonmodifying], "25.1
3652 Non-modifying sequence operations". 'Non-modifying sequence operation' is
3653 never defined.
3654 </p>
3655
3656 <p>
3657 25(5) says: "If an algorithm's Effects section says that a value pointed to
3658 by any iterator passed as an argument is modified, then that algorithm has
3659 an additional type requirement: The type of that argument shall satisfy the
3660 requirements of a mutable iterator (24.1)."
3661 </p>
3662
3663 <p>for_each's Effects section does not mention whether arguments can be
3664 modified:</p>
3665
3666 <blockquote>
3667   "Effects: Applies f to the result of dereferencing every iterator in the
3668    range [first, last), starting from first and proceeding to last - 1."
3669 </blockquote>
3670
3671 <p>
3672 Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in
3673 the sense that neither the algorithms themselves nor the function objects
3674 passed to the algorithms may modify the sequences or elements in any way.
3675 This DR affects only for_each.
3676 </p>
3677
3678 <p>
3679 We suspect that for_each's classification in "non-modifying sequence
3680 operations" means that the algorithm itself does not inherently modify the
3681 sequence or the elements in the sequence, but that the function object
3682 passed to it may modify the elements it operates on.
3683 </p>
3684
3685 <p>
3686 The original STL document by Stepanov and Lee explicitly prohibited the
3687 function object from modifying its argument.
3688 The "obvious" implementation of for_each found in several standard library
3689 implementations, however, does not impose this restriction.
3690 As a result, we suspect that the use of for_each with function objects that modify
3691 their arguments is wide-spread.
3692 If the restriction was reinstated, all such code would become non-conforming.
3693 Further, none of the other algorithms in the Standard
3694 could serve the purpose of for_each (transform does not guarantee the order in
3695 which its function object is called).
3696 </p>
3697
3698 <p>
3699 We suggest that the standard be clarified to explicitly allow the function object
3700 passed to for_each modify its argument.</p>
3701
3702 <p><b>Proposed resolution:</b></p>
3703 <p>Add a nonnormative note to the Effects in 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>: If
3704 the type of 'first' satisfies the requirements of a mutable iterator,
3705 'f' may apply nonconstant functions through the dereferenced iterators
3706 passed to it.
3707 </p>
3708
3709 <p><b>Rationale:</b></p>
3710 <p>The LWG believes that nothing in the standard prohibits function
3711   objects that modify the sequence elements. The problem is that
3712   for_each is in a secion entitled "nonmutating algorithms", and the
3713   title may be confusing.  A nonnormative note should clarify that.</p>
3714 <hr>
3715 <a name="478"><h3>478.&nbsp;Should forward iterator requirements table have a line for r-&gt;m?</h3></a><p><b>Section:</b>&nbsp;24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;11 Jul 2004</p>
3716 <p>
3717 The Forward Iterator requirements table contains the following:
3718 </p>
3719 <pre> expression  return type         operational  precondition
3720                                   semantics
3721   ==========  ==================  ===========  ==========================
3722   a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
3723               otherwise const U&amp;
3724
3725   r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
3726 </pre>
3727
3728 <p>The second line may be unnecessary.  Paragraph 11 of
3729   [lib.iterator.requirements] says:
3730 </p>
3731
3732 <blockquote>
3733    In the following sections, a and b denote values of type const X, n
3734    denotes a value of the difference type Distance, u, tmp, and m
3735    denote identifiers, r denotes a value of X&amp;, t denotes a value of
3736    value type T, o denotes a value of some type that is writable to
3737    the output iterator.
3738 </blockquote>
3739
3740 <p>
3741 Because operators can be overloaded on an iterator's const-ness, the
3742 current requirements allow iterators to make many of the operations
3743 specified using the identifiers a and b invalid for non-const
3744 iterators.</p>
3745
3746 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
3747 <p><b>Proposed resolution:</b></p>
3748
3749 <p>Remove the "r-&gt;m" line from the Forward Iterator requirements
3750 table. Change</p>
3751 <blockquote>
3752     "const X"
3753 </blockquote>
3754
3755 <p> to </p>
3756
3757 <blockquote>
3758     "X or const X"
3759 </blockquote>
3760
3761 <p>in paragraph 11 of [lib.iterator.requirements].</p>
3762
3763
3764 <p><b>Rationale:</b></p>
3765 <p>
3766 This is a defect because it constrains an lvalue to returning a modifiable lvalue.
3767 </p>
3768 <hr>
3769 <a name="479"><h3>479.&nbsp;Container requirements and placement new</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Herb Sutter&nbsp; <b>Date:</b>&nbsp;1 Aug 2004</p>
3770 <p>Nothing in the standard appears to make this program ill-formed:</p>
3771
3772 <pre>  struct C {
3773     void* operator new( size_t s ) { return ::operator new( s ); }
3774     // NOTE: this hides in-place and nothrow new
3775   };
3776
3777   int main() {
3778     vector&lt;C&gt; v;
3779     v.push_back( C() );
3780   }
3781 </pre>
3782
3783 <p>Is that intentional?  We should clarify whether or not we intended
3784   to require containers to support types that define their own special
3785   versions of <tt>operator new</tt>.</p>
3786
3787 <p><i>[
3788 Lillehammer: A container will definitely never use this overridden
3789 operator new, but whether it will fail to compile is unclear from the
3790 standard.  Are containers supposed to use qualified or unqualified
3791 placement new?  20.4.1.1 is somewhat relevant, but the standard
3792 doesn't make it completely clear whether containers have to use
3793 Allocator::construct(). If containers don't use it, the details of how
3794 containers use placement new are unspecified. That is the real bug,
3795 but it needs to be fixed as part of the allocator overhaul.  Weak
3796 support that the eventual solution should make this code well formed.
3797 ]</i></p>
3798
3799 <p><b>Proposed resolution:</b></p>
3800 <hr>
3801 <a name="482"><h3>482.&nbsp;Swapping pairs</h3></a><p><b>Section:</b>&nbsp;20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a>, 25.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;14 Sep 2004</p>
3802 <p>(Based on recent comp.std.c++ discussion)</p>
3803
3804 <p>Pair (and tuple) should specialize std::swap to work in terms of
3805 std::swap on their components.  For example, there's no obvious reason
3806 why swapping two objects of type pair&lt;vector&lt;int&gt;,
3807 list&lt;double&gt; &gt; should not take O(1).</p>
3808 <p><b>Proposed resolution:</b></p>
3809
3810
3811 <p><i>[Lillehammer: We agree it should be swappable.  Howard will
3812   provide wording.]</i></p>
3813
3814 <hr>
3815 <a name="484"><h3>484.&nbsp;Convertible to T</h3></a><p><b>Section:</b>&nbsp;24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Chris&nbsp; <b>Date:</b>&nbsp;16 Sep 2004</p>
3816 <p>From comp.std.c++:</p>
3817
3818 <p>
3819 I note that given an input iterator a for type T,
3820 then *a only has to be "convertable to T", not actually of type T.
3821 </p>
3822
3823 <p>Firstly, I can't seem to find an exact definition of "convertable to T".
3824 While I assume it is the obvious definition (an implicit conversion), I
3825 can't find an exact definition. Is there one?</p>
3826
3827 <p>Slightly more worryingly, there doesn't seem to be any restriction on
3828 the this type, other than it is "convertable to T". Consider two input
3829 iterators a and b. I would personally assume that most people would
3830 expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that
3831 the standard requires that, and that whatever type *a is (call it U)
3832 could have == defined on it with totally different symantics and still
3833 be a valid inputer iterator.</p>
3834
3835 <p>Is this a correct reading? When using input iterators should I write
3836 T(*a) all over the place to be sure that the object i'm using is the
3837 class I expect?</p>
3838
3839 <p>This is especially a nuisance for operations that are defined to be
3840   "convertible to bool".  (This is probably allowed so that
3841   implementations could return say an int and avoid an unnessary
3842   conversion. However all implementations I have seen simply return a
3843   bool anyway.  Typical implemtations of STL algorithms just write
3844   things like <tt>while(a!=b &amp;&amp; *a!=0)</tt>.  But strictly
3845   speaking, there are lots of types that are convertible to T but
3846   that also overload the appropriate operators so this doesn't behave
3847   as expected.</p>
3848
3849 <p>If we want to make code like this legal (which most people seem to
3850   expect), then we'll need to tighten up what we mean by "convertible
3851   to T".</p>
3852
3853 <p><b>Proposed resolution:</b></p>
3854 <p><i>[Lillehammer: The first part is NAD, since "convertible" is
3855  well-defined in core. The second part is basically about pathological
3856  overloads. It's a minor problem but a real one. So leave open for
3857  now, hope we solve it as part of iterator redesign.]</i></p>
3858 <hr>
3859 <a name="485"><h3>485.&nbsp;output iterator insufficently constrained</h3></a><p><b>Section:</b>&nbsp;24.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Chris&nbsp; <b>Date:</b>&nbsp;13 Oct 2004</p>
3860 <p>
3861 The note on 24.1.2 Output iterators insufficently limits what can be
3862 performed on output iterators. While it requires that each iterator is
3863 progressed through only once and that each iterator is written to only
3864 once, it does not require the following things:</p>
3865
3866 <p>Note: Here it is assumed that x is an output iterator of type X which
3867 has not yet been assigned to.</p>
3868
3869 <p>a) That each value of the output iterator is written to:
3870 The standard allows:
3871 ++x; ++x; ++x;
3872 </p>
3873
3874 <p>
3875 b) That assignments to the output iterator are made in order
3876 X a(x); ++a; *a=1; *x=2; is allowed
3877 </p>
3878
3879 <p>
3880 c) Chains of output iterators cannot be constructed:
3881 X a(x); ++a; X b(a); ++b; X c(b); ++c; is allowed, and under the current
3882 wording (I believe) x,a,b,c could be written to in any order.
3883 </p>
3884
3885 <p>I do not believe this was the intension of the standard?</p>
3886 <p><b>Proposed resolution:</b></p>
3887 <p><i>[Lillehammer: Real issue.  There are lots of constraints we
3888   intended but didn't specify.  Should be solved as part of iterator
3889   redesign.]</i></p>
3890 <hr>
3891 <a name="488"><h3>488.&nbsp;rotate throws away useful information</h3></a><p><b>Section:</b>&nbsp;25.2.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.rotate"> [lib.alg.rotate]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;22 Nov 2004</p>
3892 <p>
3893 rotate takes 3 iterators:  first, middle and last which point into a
3894 sequence, and rearranges the sequence such that the subrange [middle,
3895 last) is now at the beginning of the sequence and the subrange [first,
3896 middle) follows.  The return type is void.
3897 </p>
3898
3899 <p>
3900 In many use cases of rotate, the client needs to know where the
3901 subrange [first, middle) starts after the rotate is performed.  This
3902 might look like:
3903 </p>
3904 <pre>  rotate(first, middle, last);
3905   Iterator i = advance(first, distance(middle, last));
3906 </pre>
3907
3908 <p>
3909 Unless the iterators are random access, the computation to find the
3910 start of the subrange [first, middle) has linear complexity.  However,
3911 it is not difficult for rotate to return this information with
3912 negligible additional computation expense.  So the client could code:
3913 </p>
3914 <pre>  Iterator i = rotate(first, middle, last);
3915 </pre>
3916
3917 <p>
3918 and the resulting program becomes significantly more efficient.
3919 </p>
3920
3921 <p>
3922 While the backwards compatibility hit with this change is not zero, it
3923 is very small (similar to that of lwg <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>), and there is
3924 a significant benefit to the change.
3925 </p>
3926
3927 <p><b>Proposed resolution:</b></p>
3928 <p>In 25p2, change:</p>
3929 <pre>  template&lt;class ForwardIterator&gt;
3930     void rotate(ForwardIterator first, ForwardIterator middle,
3931                 ForwardIterator last);
3932 </pre>
3933
3934 <p>to:</p>
3935
3936 <pre>  template&lt;class ForwardIterator&gt;
3937     ForwardIterator rotate(ForwardIterator first, ForwardIterator middle,
3938                            ForwardIterator last);
3939 </pre>
3940
3941 <p>In 25.2.10, change:</p>
3942
3943 <pre>  template&lt;class ForwardIterator&gt;
3944     void rotate(ForwardIterator first, ForwardIterator middle,
3945                 ForwardIterator last);
3946 </pre>
3947
3948 <p>to:</p>
3949
3950 <pre>  template&lt;class ForwardIterator&gt;
3951     ForwardIterator rotate(ForwardIterator first, ForwardIterator middle,
3952                            ForwardIterator last);
3953 </pre>
3954
3955 <p>In 25.2.10 insert a new paragraph after p1:</p>
3956
3957 <blockquote>
3958 <p><b>Returns</b>: <tt>first + (last - middle)</tt>.</p>
3959 </blockquote>
3960
3961 <p><i>[
3962 The LWG agrees with this idea, but has one quibble: we want to make
3963 sure not to give the impression that the function "advance" is
3964 actually called, just that the nth iterator is returned.  (Calling
3965 advance is observable behavior, since users can specialize it for
3966 their own iterators.)  Howard will provide wording.
3967 ]</i></p>
3968
3969 <p><i>[Howard provided wording for mid-meeting-mailing Jun. 2005.]</i></p>
3970
3971 <hr>
3972 <a name="492"><h3>492.&nbsp;Invalid iterator arithmetic expressions</h3></a><p><b>Section:</b>&nbsp;23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.containers"> [lib.containers]</a>, 24 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterators"> [lib.iterators]</a>, 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Thomas Mang&nbsp; <b>Date:</b>&nbsp;12 Dec 2004</p>
3973 <p>Various clauses other than clause 25 make use of iterator arithmetic not
3974 supported by the iterator category in question.
3975 Algorithms in clause 25 are exceptional because of 25 [lib.algorithms],
3976 paragraph 9, but this paragraph does not provide semantics to the
3977 expression "iterator - n", where n denotes a value of a distance type
3978 between iterators.</p>
3979
3980 <p>1) Examples of current wording:</p>
3981
3982 <p>Current wording outside clause 25:</p>
3983
3984 <p>
3985 23.2.2.4 [lib.list.ops], paragraphs 19-21: "first + 1", "(i - 1)",
3986 "(last - first)"
3987 23.3.1.1 [lib.map.cons], paragraph 4: "last - first"
3988 23.3.2.1 [lib.multimap.cons], paragraph 4: "last - first"
3989 23.3.3.1 [lib.set.cons], paragraph 4: "last - first"
3990 23.3.4.1 [lib.multiset.cons], paragraph 4: "last - first"
3991 24.4.1 [lib.reverse.iterators], paragraph 1: "(i - 1)"
3992 </p>
3993
3994 <p>
3995 [Important note: The list is not complete, just an illustration. The
3996 same issue might well apply to other paragraphs not listed here.]</p>
3997
3998 <p>None of these expressions is valid for the corresponding iterator
3999 category.</p>
4000
4001 <p>Current wording in clause 25:</p>
4002
4003 <p>
4004 25.1.1 [lib.alg.foreach], paragraph 1: "last - 1"
4005 25.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 -
4006 (last2-first2))"
4007 25.2.8 [lib.alg.unique], paragraph 1: "(i - 1)"
4008 25.2.8 [lib.alg.unique], paragraph 5: "(i - 1)"
4009 </p>
4010
4011 <p>
4012 However, current wording of 25 [lib.algorithms], paragraph 9 covers
4013 neither of these four cases:</p>
4014
4015 <p>Current wording of 25 [lib.algorithms], paragraph 9:</p>
4016
4017 <p>
4018 "In the description of the algorithms operator + and - are used for some
4019 of the iterator categories for which they do not have to be defined. In
4020 these cases the semantics of a+n is the same as that of</p>
4021 <pre>{X tmp = a;
4022 advance(tmp, n);
4023 return tmp;
4024 }
4025 </pre>
4026 <p>and that of b-a is the same as of return distance(a, b)"</p>
4027
4028 <p>
4029 This paragrpah does not take the expression "iterator - n" into account,
4030 where n denotes a value of a distance type between two iterators [Note:
4031 According to current wording, the expression "iterator - n" would be
4032 resolved as equivalent to "return distance(n, iterator)"]. Even if the
4033 expression "iterator - n" were to be reinterpreted as equivalent to
4034 "iterator + -n" [Note: This would imply that "a" and "b" were
4035 interpreted implicitly as values of iterator types, and "n" as value of
4036 a distance type], then 24.3.4/2 interfers because it says: "Requires: n
4037 may be negative only for random access and bidirectional iterators.",
4038 and none of the paragraphs quoted above requires the iterators on which
4039 the algorithms operate to be of random access or bidirectional category.
4040 </p>
4041
4042 <p>2) Description of intended behavior:</p>
4043
4044 <p>
4045 For the rest of this Defect Report, it is assumed that the expression
4046 "iterator1 + n" and "iterator1 - iterator2" has the semantics as
4047 described in current 25 [lib.algorithms], paragraph 9, but applying to
4048 all clauses. The expression "iterator1 - n" is equivalent to an
4049 result-iterator for which the expression "result-iterator + n" yields an
4050 iterator denoting the same position as iterator1 does. The terms
4051 "iterator1", "iterator2" and "result-iterator" shall denote the value of
4052 an iterator type, and the term "n" shall denote a value of a distance
4053 type between two iterators.</p>
4054
4055 <p>
4056 All implementations known to the author of this Defect Report comply
4057 with these assumptions.
4058 No impact on current code is expected.</p>
4059
4060 <p>3) Proposed fixes:</p>
4061
4062
4063 <p>Change 25 [lib.algorithms], paragraph 9 to:</p>
4064
4065 <p>
4066 "In the description of the algorithms operator + and - are used for some
4067 of the iterator categories for which they do not have to be defined. In
4068 this paragraph, a and b denote values of an iterator type, and n denotes
4069 a value of a distance type between two iterators. In these cases the
4070 semantics of a+n is the same as that of</p>
4071 <pre>{X tmp = a;
4072 advance(tmp, n);
4073 return tmp;
4074 }
4075 </pre>
4076 <p>,the semantics of a-n denotes the value of an iterator i for which the
4077 following condition holds:
4078 advance(i, n) == a,
4079 and that of b-a is the same as of
4080 return distance(a, b)".
4081 </p>
4082
4083 <p>Comments to the new wording:</p>
4084
4085 <p>
4086 a) The wording " In this paragraph, a and b denote values of an iterator
4087 type, and n denotes a value of a distance type between two iterators."
4088 was added so the expressions "b-a" and "a-n" are distinguished regarding
4089 the types of the values on which they operate.
4090 b) The wording ",the semantics of a-n denotes the value of an iterator i
4091 for which the following condition holds: advance(i, n) == a" was added
4092 to cover the expression 'iterator - n'. The wording "advance(i, n) == a"
4093 was used to avoid a dependency on the semantics of a+n, as the wording
4094 "i + n == a" would have implied. However, such a dependency might well
4095 be deserved.
4096 c) DR 225 is not considered in the new wording.
4097 </p>
4098
4099 <p>
4100 Proposed fixes regarding invalid iterator arithmetic expressions outside
4101 clause 25:</p>
4102
4103 <p>
4104 Either
4105 a) Move modified 25 [lib.algorithms], paragraph 9 (as proposed above)
4106 before any current invalid iterator arithmetic expression. In that case,
4107 the first sentence of 25 [lib.algorithms], paragraph 9, need also to be
4108 modified and could read: "For the rest of this International Standard,
4109 ...." / "In the description of the following clauses including this
4110 ...." / "In the description of the text below ..." etc. - anyways
4111 substituting the wording "algorithms", which is a straight reference to
4112 clause 25.
4113 In that case, 25 [lib.algorithms] paragraph 9 will certainly become
4114 obsolete.
4115 Alternatively,
4116 b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
4117 paragraph 9, to the beginning of each clause containing invalid iterator
4118 arithmetic expressions.
4119 Alternatively,
4120 c) Fix each paragraph (both current wording and possible resolutions of
4121 DRs) containing invalid iterator arithmetic expressions separately.
4122 </p>
4123
4124 <p>5) References to other DRs:</p>
4125
4126 <p>
4127 See DR 225.
4128 See DR 237. The resolution could then also read "Linear in last -
4129 first".
4130 </p>
4131 <p><b>Proposed resolution:</b></p>
4132
4133 <p><i>[Lillehammer: Minor issue, but real. We have a blanket statement
4134 about this in 25/11. But (a) it should be in 17, not 25; and (b) it's
4135 not quite broad enough, because there are some arithmetic expressions
4136 it doesn't cover. Bill will provide wording.]</i></p>
4137
4138 <hr>
4139 <a name="495"><h3>495.&nbsp;Clause 22 template parameter requirements</h3></a><p><b>Section:</b>&nbsp;22 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.localization"> [lib.localization]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;10 Jan 2005</p>
4140 <p>It appears that there are no requirements specified for many of the
4141 template parameters in clause 22. It looks like this issue has never
4142 come up, except perhaps for Facet.</p>
4143
4144 <p>Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions],
4145 either, which is the wording that allows requirements on template
4146 parameters to be identified by name.</p>
4147
4148 <p>So one issue is that 17.3.2.1 [lib.type.descriptions] Should be
4149 changed to cover clause 22. A better change, which will cover us in
4150 the future, would be to say that it applies to all the library
4151 clauses. Then if a template gets added to any library clause we are
4152 covered.</p>
4153
4154 <p>charT, InputIterator, and other names with requirements defined
4155 elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix.
4156 But there are a few template arguments names which I don't think have
4157 requirements given elsewhere:</p>
4158
4159 <ul>
4160 <li>internT and externT.  The fix is to add wording saying that internT
4161 and externT must meet the same requirements as template arguments
4162 named charT.</li>
4163
4164 <li>stateT.  I'm not sure about this one. There already is some wording,
4165 but it seems a bit vague.</li>
4166
4167 <li>Intl.  [lib.locale.moneypunct.byname] The fix for this one is to
4168 rename "Intl" to "International". The name is important because other
4169 text identifies the requirements for the name International but not
4170 for Intl.</li>
4171 </ul>
4172 <p><b>Proposed resolution:</b></p>
4173 <p>Change 17.3.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a>, paragraph 1, from:</p>
4174 <blockquote>
4175 The Requirements subclauses may describe names that are used to
4176 specify constraints on template arguments.153) These names are used in
4177 clauses 20, 23, 25, and 26 to describe the types that may be supplied
4178 as arguments by a C++ program when instantiating template components
4179 from the library.
4180 </blockquote>
4181 <p>to:</p>
4182 <blockquote>
4183 The Requirements subclauses may describe names that are used to
4184 specify constraints on template arguments.153) These names are used in
4185 library clauses to describe the types that may be supplied as
4186 arguments by a C++ program when instantiating template components from
4187 the library.
4188 </blockquote>
4189
4190 <p>In the front matter of class 22, locales, add:</p>
4191 <blockquote>
4192 Template parameter types internT and externT shall meet the
4193 requirements of charT (described in 21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.strings"> [lib.strings]</a>).
4194 </blockquote>
4195 <p><b>Rationale:</b></p>
4196 <p>
4197  Again, a blanket clause isn't blanket enough. Also, we've got a
4198  couple of names that we don't have blanket requirement statements
4199  for. The only issue is what to do about stateT. This wording is
4200  thin, but probably adequate.</p>
4201 <hr>
4202 <a name="497"><h3>497.&nbsp;meaning of numeric_limits::traps for floating point types</h3></a><p><b>Section:</b>&nbsp;18.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.limits.members"> [lib.numeric.limits.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;2 Mar 2005</p>
4203
4204 <p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p>
4205
4206 <blockquote>
4207 <p>static const bool traps;<br>
4208 -59- true if trapping is implemented for the type.204)
4209 <br>
4210 Footnote 204: Required by LIA-1.
4211 </p>
4212 </blockquote>
4213
4214 <p>It's not clear what is meant by "is implemented" here.</p>
4215
4216 <p>
4217 In the context of floating point numbers it seems reasonable to expect
4218 to be able to use traps to determine whether a program can "safely" use
4219 infinity(), quiet_NaN(), etc., in arithmetic expressions, that is
4220 without causing a trap (i.e., on UNIX without having to worry about
4221 getting a signal). When traps is true, I would expect any of the
4222 operations in section 7 of IEEE 754 to cause a trap (and my program
4223 to get a SIGFPE). So, for example, on Alpha, I would expect traps
4224 to be true by default (unless I compiled my program with the -ieee
4225 option), false by default on most other popular architectures,
4226 including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require
4227 traps to be explicitly enabled by the program.
4228 </p>
4229
4230 <p>
4231 Another possible interpretation of p59 is that traps should be true
4232 on any implementation that supports traps regardless of whether they
4233 are enabled by default or not. I don't think such an interpretation
4234 makes the traps member very useful, even though that is how traps is
4235 implemented on several platforms. It is also the only way to implement
4236 traps on platforms that allow programs to enable and disable trapping
4237 at runtime.
4238 </p>
4239 <p><b>Proposed resolution:</b></p>
4240 <p>Change p59 to read:</p>
4241 <blockquote>True if, at program startup, there exists a value of the type that
4242   would cause an arithmetic operation using that value to trap.</blockquote>
4243 <p><b>Rationale:</b></p>
4244 <p>
4245  Real issue, since trapping can be turned on and off. Unclear what a
4246  static query can say about a dynamic issue. The real advice we should
4247  give users is to use cfenv for these sorts of queries. But this new
4248  proposed resolution is at least consistent and slightly better than
4249  nothing.</p>
4250 <hr>
4251 <a name="498"><h3>498.&nbsp;Requirements for partition() and stable_partition() too strong</h3></a><p><b>Section:</b>&nbsp;25.2.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.partitions"> [lib.alg.partitions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Sean Parent, Joe Gottman&nbsp; <b>Date:</b>&nbsp;4 May 2005</p>
4252 <p>
4253 Problem:
4254 The iterator requirements for partition() and stable_partition() [25.2.12]
4255 are listed as BidirectionalIterator, however, there are efficient algorithms
4256 for these functions that only require ForwardIterator that have been known
4257 since before the standard existed. The SGI implementation includes these (see
4258 <a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a>
4259 and
4260 <a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>).
4261 </p>
4262 <p><b>Proposed resolution:</b></p>
4263 <p>
4264 Change 25.2.12 from </p>
4265 <blockquote><pre>template&lt;class BidirectionalIterator, class Predicate&gt;
4266 BidirectionalIterator partition(BidirectionalIterato r first,
4267                                 BidirectionalIterator last,
4268                                 Predicate pred);
4269 </pre></blockquote>
4270 <p>to </p>
4271 <blockquote><pre>template&lt;class ForwardIterator, class Predicate&gt;
4272 ForwardIterator partition(ForwardIterator first,
4273                           ForwardIterator last,
4274                           Predicate pred);
4275 </pre></blockquote>
4276 <p>Change the complexity from </p>
4277
4278 <blockquote><p>
4279 At most (last - first)/2 swaps are done. Exactly (last - first)
4280 applications of the predicate are done.
4281 </p></blockquote>
4282
4283 <p>to </p>
4284
4285 <blockquote><p>
4286 If ForwardIterator is a bidirectional_iterator, at most (last - first)/2
4287 swaps are done; otherwise at most (last - first) swaps are done. Exactly
4288 (last - first) applications of the predicate are done.
4289 </p></blockquote>
4290
4291 <p><b>Rationale:</b></p>
4292 Partition is a "foundation" algorithm useful in many contexts (like sorting
4293 as just one example) - my motivation for extending it to include forward
4294 iterators is slist - without this extension you can't partition an slist
4295 (without writing your own partition). Holes like this in the standard
4296 library weaken the argument for generic programming (ideally I'd be able
4297 to provide a library that would refine std::partition() to other concepts
4298 without fear of conflicting with other libraries doing the same - but
4299 that is a digression). I consider the fact that partition isn't defined
4300 to work for ForwardIterator a minor embarrassment.
4301
4302 <p><i>[Mont Tremblant: Moved to Open, request motivation and use cases
4303 by next meeting. Sean provided further rationale by post-meeting
4304 mailing.]</i></p>
4305
4306 <hr>
4307 <a name="499"><h3>499.&nbsp;Std. doesn't seem to require stable_sort() to be stable!</h3></a><p><b>Section:</b>&nbsp;25.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.stable.sort"> [lib.stable.sort]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Prateek Karandikar&nbsp; <b>Date:</b>&nbsp;12 Apr 2005</p>
4308 <blockquote>
4309 <p>
4310 17.3.1.1 Summary</p>
4311
4312 <p>
4313 1 The Summary provides a synopsis of the category, and introduces the
4314 first-level subclauses. Each subclause also provides a summary, listing
4315 the headers specified in the subclause and the library entities
4316 provided in each header.
4317 </p>
4318 <p>
4319 2 Paragraphs labelled "Note(s):" or "Example(s):" are informative,
4320 other paragraphs are normative.
4321 </p>
4322 </blockquote>
4323
4324 <p>So this means that a "Notes" paragraph wouldn't be normative. </p>
4325
4326 <blockquote>
4327 <p>
4328 25.3.1.2 stable_sort
4329 </p>
4330 <pre>template&lt;class RandomAccessIterator&gt;
4331 void stable_sort(RandomAccessIterat or first, RandomAccessIterator last);
4332
4333 template&lt;class RandomAccessIterator, class Compare&gt;
4334 void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp);
4335 </pre>
4336 <p>
4337 1 Effects: Sorts the elements in the range [first, last).
4338 </p>
4339 <p>
4340 2 Complexity: It does at most N(log N)^2 (where N == last - first)
4341 comparisons; if enough extra memory is available, it is N log N.
4342 </p>
4343 <p>
4344 3 Notes: Stable: the relative order of the equivalent elements is
4345 preserved.
4346 </p>
4347 </blockquote>
4348
4349 <p>
4350 The Notes para is informative, and nowhere else is stability mentioned above.
4351 </p>
4352
4353 <p>
4354 Also, I just searched for the word "stable" in my copy of the Standard.
4355 and the phrase "Notes: Stable: the relative order of the elements..."
4356 is repeated several times in the Standard library clauses for
4357 describing various functions. How is it that stability is talked about
4358 in the informative paragraph? Or am I missing something obvious?
4359 </p>
4360 <p><b>Proposed resolution:</b></p>
4361 <p>
4362 </p>
4363 <hr>
4364 <a name="501"><h3>501.&nbsp;Proposal: strengthen guarantees of lib.comparisons</h3></a><p><b>Section:</b>&nbsp;20.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.comparisons"> [lib.comparisons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Me &lt;anti_spam_email2003@yahoo.com&gt;&nbsp; <b>Date:</b>&nbsp;7 Jun 2005</p>
4365 <blockquote>
4366 "For templates greater, less, greater_equal, and less_equal,
4367 the specializations for any pointer type yield a total order, even if
4368 the built-in operators &lt;, &gt;, &lt;=, &gt;= do not."
4369 </blockquote>
4370
4371 <p>
4372 The standard should do much better than guarantee that these provide a
4373 total order, it should guarantee that it can be used to test if memory
4374 overlaps, i.e. write a portable memmove. You can imagine a platform
4375 where the built-in operators use a uint32_t comparison (this tests for
4376 overlap on this platform) but the less&lt;T*&gt; functor is allowed to be
4377 defined to use a int32_t comparison. On this platform, if you use
4378 std::less with the intent of making a portable memmove, comparison on
4379 an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give
4380 incorrect results.
4381 </p>
4382 <p><b>Proposed resolution:</b></p>
4383 <p>
4384 Add a footnote to 20.3.3/8 saying:
4385 </p>
4386
4387 <blockquote>
4388 Given a p1 and p2 such that p1 points to N objects of type T and p2
4389 points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M),
4390 less returns the same value when comparing all pointers in [p1,p1+N) to
4391 all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R
4392 such that less returns the same value when comparing all pointers in
4393 [p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when
4394 comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M).
4395 For the sake of completeness, the null pointer value (4.10) for T is
4396 considered to be an array of 1 object that doesn't overlap with any
4397 non-null pointer to T. less_equal, greater, greater_equal, equal_to,
4398 and not_equal_to give the expected results based on the total ordering
4399 semantics of less. For T of void, treat it as having similar semantics
4400 as T of char i.e. less&lt;cv T*&gt;(a, b) gives the same results as less&lt;cv
4401 void*&gt;(a, b) which gives the same results as less&lt;cv char*&gt;((cv
4402 char*)(cv void*)a, (cv char*)(cv void*)b).
4403 </blockquote>
4404
4405 <p>
4406 I'm also thinking there should be a footnote to 20.3.3/1 saying that if
4407 A and B are similar types (4.4/4), comp&lt;A&gt;(a,b) returns the same value
4408 as comp&lt;B&gt;(a,b) (where comp is less, less_equal, etc.). But this might
4409 be problematic if there is some really funky operator overloading going
4410 on that does different things based on cv (that should be undefined
4411 behavior if somebody does that though). This at least should be
4412 guaranteed for all POD types (especially pointers) that use the
4413 built-in comparison operators.
4414 </p>
4415
4416 <hr>
4417 <a name="502"><h3>502.&nbsp;Proposition: Clarification of the interaction between a facet and an iterator</h3></a><p><b>Section:</b>&nbsp;22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Christopher Conrade Zseleghovski&nbsp; <b>Date:</b>&nbsp;7 Jun 2005</p>
4418 <p>
4419 Motivation:
4420 </p>
4421
4422 <p>
4423 This requirement seems obvious to me, it is the essence of code modularity.
4424 I have complained to Mr. Plauger that the Dinkumware library does not
4425 observe this principle but he objected that this behaviour is not covered in
4426 the standard.
4427 </p>
4428 <p><b>Proposed resolution:</b></p>
4429 <p>
4430 Append the following point to 22.1.1.1.1:
4431 </p>
4432
4433 <p>
4434 6. The implementation of a facet of Table 52 parametrized with an
4435 InputIterator/OutputIterator should use that iterator only as character
4436 source/sink respectively.
4437 For a *_get facet, it means that the value received depends only on the
4438 sequence of input characters and not on how they are accessed.
4439 For a *_put facet, it means that the sequence of characters output depends
4440 only on the value to be formatted and not of how the characters are stored.
4441 </p>
4442 <hr>
4443 <a name="503"><h3>503.&nbsp;more on locales</h3></a><p><b>Section:</b>&nbsp;22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;P.J. Plauger&nbsp; <b>Date:</b>&nbsp;20 Jun 2005</p>
4444 <p>
4445 a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table
4446 51" to refer to the facet *objects* associated with a locale. And we
4447 almost certainly mean just those associated with the default or "C"
4448 locale. Otherwise, you can't switch to a locale that enforces a different
4449 mapping between narrow and wide characters, or that defines additional
4450 uppercase characters.
4451 </p>
4452
4453 <p>
4454 b) 22.2.1.5 para. 3 (codecvt) has the same issues.
4455 </p>
4456
4457 <p>
4458 c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation of
4459 a homing sequence for the basic character set, which might very well need
4460 one.
4461 </p>
4462
4463 <p>
4464 d) 22.2.1.5.2 (do_length) likewise dictates that the default mapping
4465 between wide and narrow characters be taken as one-for-one.
4466 </p>
4467
4468 <p>
4469 e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far as
4470 I can tell. The muddle is, as before, calling Table 51 a list of
4471 instantiations. But the constraint it applies seems to me to cover
4472 *all* defined uses of num_get/put, so why bother to say so?
4473 </p>
4474
4475 <p>
4476 f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiations
4477 return '.' or L'.'.) Presumably this means "as appropriate for the
4478 character type. But given the vague definition of "required" earlier,
4479 this overrules *any* change of decimal point for non "C" locales.
4480 Surely we don't want to do that.
4481 </p>
4482
4483 <p>
4484 g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiations
4485 return ',' or L','.) As above, this probably means "as appropriate for the
4486 character type. But this overrules the "C" locale, which requires *no*
4487 character ('\0') for the thousands separator. Even if we agree that we
4488 don't mean to block changes in decimal point or thousands separator,
4489 we should also eliminate this clear incompatibility with C.
4490 </p>
4491
4492 <p>
4493 h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiations
4494 return the empty string, indicating no grouping." Same considerations
4495 as for do_decimal_point.
4496 </p>
4497
4498 <p>
4499 i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table
4500 51". Same bad jargon.
4501 </p>
4502
4503 <p>
4504 j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required
4505 in Table 51". Same bad jargon.
4506 </p>
4507
4508 <p>
4509 k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous
4510 as num_get/put.
4511 </p>
4512
4513 <p>
4514 l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous
4515 as num_get/put.
4516 </p>
4517
4518 <p>
4519 m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations required
4520 in Table 51 ... return an object of type pattern initialized to
4521 {symbol, sign, none, value}." This once again *overrides* the "C"
4522 locale, as well as any other locale."
4523 </p>
4524
4525 <p>
4526 3) We constrain the use_facet calls that can be made by num_get/put,
4527 so why don't we do the same for money_get/put? Or for any of the
4528 other facets, for that matter?
4529 </p>
4530
4531 <p>
4532 4) As an almost aside, we spell out when a facet needs to use the ctype
4533 facet, but several also need to use a codecvt facet and we don't say so.
4534 </p>
4535 <p><b>Proposed resolution:</b></p>
4536 <p>
4537 </p>
4538 <hr>
4539 <a name="504"><h3>504.&nbsp;Integer types in pseudo-random number engine requirements</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
4540 <p>
4541 In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type,
4542 g is an ... object returning values of unsigned integral type ..."
4543 </p>
4544 <p><b>Proposed resolution:</b></p>
4545 <p>
4546 In 5.1.1 [tr.rand.req], Paragraph 2 replace
4547 </p>
4548
4549 <blockquote>
4550 ... s is a value of integral type, g is an lvalue of a type other than X that
4551 defines a zero-argument function object returning values of <del>unsigned integral</del> type
4552 <ins><tt>unsigned long int</tt></ins>,
4553 ...
4554 </blockquote>
4555
4556 <p>
4557 In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s)
4558 </p>
4559
4560 <blockquote>
4561 creates an engine with the initial internal state
4562 determined by <ins><tt>static_cast&lt;unsigned long&gt;(</tt></ins><tt><i>s</i></tt><ins><tt>)</tt></ins>
4563 </blockquote>
4564
4565 <p><i>[
4566 Mont Tremblant:  Both s and g should be unsigned long.
4567 This should refer to the constructor signatures. Jens  provided wording post Mont Tremblant.
4568 ]</i></p>
4569
4570 <p><b>Rationale:</b></p>
4571 <p>
4572 Jens:  Just requiring X(unsigned long) still makes it possible
4573 for an evil library writer to also supply a X(int) that does something
4574 unexpected.  The wording above requires that X(s) always performs
4575 as if X(unsigned long) would have been called.  I believe that is
4576 sufficient and implements our intentions from Mont Tremblant.  I
4577 see no additional use in actually requiring a X(unsigned long)
4578 signature.  u.seed(s) is covered by its reference to X(s), same
4579 arguments.
4580 </p>
4581 <hr>
4582 <a name="505"><h3>505.&nbsp;Result_type in random distribution requirements</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
4583 <p>
4584 Table 17: Random distribution requirements
4585 </p>
4586 <p>
4587 Row 1 requires that each random distribution provide a nested type "input_type";
4588 this type denotes the type of the values that the distribution consumes.
4589 </p>
4590 <p>
4591 Inspection of all distributions in [tr.rand.dist] reveals that each distribution
4592 provides a second typedef ("result_type") that denotes the type of the values the
4593 distribution produces when called.
4594 </p>
4595 <p><b>Proposed resolution:</b></p>
4596 <p>
4597 It seems to me that this is also a requirement
4598 for all distributions and should therefore be  indicated as such via a new second
4599 row to this table 17:
4600 </p>
4601 <table border="1" cellpadding="5">
4602 <tbody><tr>
4603 <td>X::result_type</td>
4604 <td>T</td>
4605 <td>---</td>
4606 <td>compile-time</td>
4607 </tr>
4608 </tbody></table>
4609 <hr>
4610 <a name="506"><h3>506.&nbsp;Requirements of Distribution parameter for variate_generator</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
4611 <p>
4612 Paragraph 3 requires that template argument U (which corresponds to template
4613 parameter Engine) satisfy all uniform random number generator requirements.
4614 However, there is no  analogous requirement regarding the template argument
4615 that corresponds to template parameter Distribution.  We believe there should
4616 be, and that it should require that this template argument satisfy all random
4617 distribution requirements.
4618 </p>
4619 <p><b>Proposed resolution:</b></p>
4620 <p>
4621 Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18.
4622 </p>
4623 <p>
4624 Consequence 2: Add max() and min() functions to those distributions that
4625 do not already have them.
4626 </p>
4627
4628 <p><i>[
4629 Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere.
4630 Marc supports having min and max to satisfy generic programming interface.
4631 ]</i></p>
4632
4633 <hr>
4634 <a name="507"><h3>507.&nbsp;Missing requirement for variate_generator::operator()</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
4635 <p>
4636 Paragraph 11 of [tr.rand.var] equires that the member template
4637 </p>
4638 <blockquote><pre>template&lt;class T&gt; result_type operator() (T value);
4639 </pre></blockquote>
4640 <p>
4641 return
4642 </p>
4643 <blockquote><pre>distribution()(e, value)
4644 </pre></blockquote>
4645 <p>
4646 However, not all distributions have an operator() with a corresponding signature.
4647 </p>
4648 <p><b>Proposed resolution:</b></p>
4649 <p>
4650 We therefore  recommend that we insert the following precondition before paragraph 11:
4651 </p>
4652 <blockquote>
4653 Precondition:  <tt>distribution().operator()(e,value)</tt> is well-formed.
4654 </blockquote>
4655 <hr>
4656 <a name="508"><h3>508.&nbsp;Bad parameters for ranlux64_base_01</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.predef"> [tr.rand.predef]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
4657 <p>
4658 The fifth of these engines with predefined parameters, ranlux64_base_01,
4659 appears to have an unintentional error for which there is a simple correction.
4660 The two pre-defined  subtract_with_carry_01 engines are given as:
4661 </p>
4662 <blockquote><pre>typedef subtract_with_carry_01&lt;float,  24, 10, 24&gt; ranlux_base_01;
4663 typedef subtract_with_carry_01&lt;double, 48, 10, 24&gt; ranlux64_base_01;
4664 </pre></blockquote>
4665 <p>
4666 We demonstrate below that ranlux64_base_01 fails to meet the intent of the
4667 random number generation proposal, but that the simple correction to
4668 </p>
4669 <blockquote><pre>typedef subtract_with_carry_01&lt;double, 48,  5, 12&gt; ranlux64_base_01;
4670 </pre></blockquote>
4671 <p>
4672 does meet the intent of defining well-known good parameterizations.
4673 </p>
4674 <p>
4675 The ranlux64_base_01 engine as presented fails to meet the intent for
4676 predefined engines, stated in proposal N1398 (section E):
4677 </p>
4678 <blockquote><p>
4679 In order to make good random numbers available to a large number of library
4680 users, this proposal not only defines generic random-number engines, but also
4681 provides a number of predefined well-known good parameterizations for those.
4682 </p></blockquote>
4683 <p>
4684 The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very
4685 long period and so meets this criterion.  This property makes it suitable for
4686 use in the excellent discard_block  engines defined subsequently.  The proof
4687 of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s)
4688 + 1 is prime (w, r, and s are template parameters to subtract_with_carry_01,
4689 as defined in [tr.rand.eng.sub1]).
4690 </p>
4691 <p>
4692 The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10.
4693 For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though
4694 explicit factorization  would be a challenge).  In consequence, while it is
4695 certainly possible for some seeding states that this engine would have a very
4696 long period, it is not at all Òwell-knownÓ that this is the case. The intent
4697 in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy
4698 use in the physics community.  This is isomorphic to the predefined ranlux_base_01,
4699 but exploits the ability of double variables to hold (at least) 48 bits of mantissa,
4700 to deliver 48 random bits at a time rather than 24.
4701 </p>
4702 <p><b>Proposed resolution:</b></p>
4703 <p>
4704 To achieve this intended behavior, the correct template parameteriztion  would be:
4705 </p>
4706 <blockquote><pre>typedef subtract_with_carry_01&lt;double, 48, 5, 12&gt; ranlux64_base_01;
4707 </pre></blockquote>
4708 <p>
4709 The sequence of mantissa bits delivered by this is isomorphic (treating each
4710 double as having the  bits of two floats) to that delivered by ranlux_base_01.
4711 </p>
4712 <p>
4713 <b>References:</b>
4714 </p>
4715 <ol>
4716 <li>F. James, Comput. Phys. Commun. 60(1990) 329</li>
4717 <li>G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462</li>
4718 <li>M. Luscher, Comput. Phys. Commun. 79(1994) 100-110</li>
4719 </ol>
4720
4721 <hr>
4722 <a name="509"><h3>509.&nbsp;Uniform_int template parameters</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.iunif"> [tr.rand.dist.iunif]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
4723 <p>
4724 In [tr.rand.dist.iunif] the uniform_int distribution currently has a single
4725 template parameter, IntType, used as the input_type and as the result_type
4726 of the distribution.  We believe there is no reason to conflate these types
4727 in this way.
4728 </p>
4729 <p><b>Proposed resolution:</b></p>
4730 <p>
4731 We recommend that there be a second template  parameter to
4732 reflect the distributionÕs input_type, and that the existing first template
4733 parameter continue to reflect (solely) the result_type:
4734 </p>
4735 <blockquote><pre>template&lt; class IntType = int, UIntType = unsigned int &gt;
4736 class uniform_int
4737 {
4738 public:
4739   // types
4740   typedef  UIntType  input_type;
4741   typedef  IntType   result_type;
4742 </pre></blockquote>
4743 <hr>
4744 <a name="510"><h3>510.&nbsp;Input_type for bernoulli_distribution</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bern"> [tr.rand.dist.bern]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
4745 <p>
4746 In [tr.rand.dist.bern] the distribution currently requires;
4747 </p>
4748 <blockquote><pre>typedef  int  input_type;
4749 </pre></blockquote>
4750 <p><b>Proposed resolution:</b></p>
4751 <p>
4752 We believe this is an unfortunate choice, and recommend instead:
4753 </p>
4754 <blockquote><pre>typedef  unsigned int  input_type;
4755 </pre></blockquote>
4756 <hr>
4757 <a name="511"><h3>511.&nbsp;Input_type for binomial_distribution</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.7.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bin"> [tr.rand.dist.bin]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
4758 <p>
4759 Unlike all other distributions in TR1, this binomial_distribution has an
4760 implementation-defined  input_type.  We believe this is an unfortunate choice,
4761 because it hinders users from writing portable code.  It also hinders the
4762 writing of compliance tests.  We recommend instead:
4763 </p>
4764 <blockquote><pre>typedef  RealType  input_type;
4765 </pre></blockquote>
4766 <p>
4767 While this choice is somewhat arbitrary (as it was for some of the other
4768 distributions), we make  this particular choice because (unlike all other
4769 distributions) otherwise this template would not publish its RealType
4770 argument and so users could not write generic code that accessed this
4771 second template parameter.  In this respect, the choice is consistent with
4772 the other distributions in  TR1.
4773 </p>
4774 <p>
4775 We have two reasons for recommending that a real type be specified instead.
4776 One reason is  based specifically on characteristics of binomial distribution
4777 implementations, while the other is based on mathematical characteristics of
4778 probability distribution functions in general.
4779 </p>
4780 <p>
4781 Implementations of binomial distributions commonly use Stirling approximations
4782 for values in certain ranges.  It is far more natural to use real values to
4783 represent these approximations than it would be to use integral values to do
4784 so.  In other ranges, implementations reply on the Bernoulli  distribution to
4785 obtain values.  While TR1Õs bernoulli_distribution::input_type is specified as
4786 int, we believe this would be better specified as double.
4787 </p>
4788 <p>
4789 This brings us to our main point:  The notion of a random distribution rests
4790 on the notion of a cumulative distribution function, which in turn mathematically
4791 depends on a continuous dependent variable.  Indeed, such a distribution function
4792 would be meaningless if it depended on  discrete values such as integersÑand this
4793 remains true even if the distribution function were to take discrete steps.
4794 </p>
4795 <p>
4796 Although this note is specifically about binomial_distribution::input_type,
4797 we intend to recommend that all of the random distributionsÕ input_types be
4798 specified as a real type (either a RealType template parameter, or double,
4799 as appropriate).
4800 </p>
4801 <p>
4802 Of the nine distributions in TR1, four already have this characteristic
4803 (uniform_real, exponential_distribution, normal_distribution, and
4804 gamma_distribution).  We have already argued the case for the binomial the
4805 remaining four distributions.
4806 </p>
4807 <p>
4808 In the case of uniform_int, we believe that the calculations to produce an
4809 integer result in a  specified range from an integer in a different specified
4810 range is best done using real arithmetic.  This is because it involves a
4811 product, one of whose terms is the ratio of the extents of the two ranges.
4812 Without real arithmetic, the results become less uniform: some numbers become
4813 more  (or less) probable that they should be.  This is, of course, undesireable
4814 behavior in a uniform distribution.
4815 </p>
4816 <p>
4817 Finally, we believe that in the case of the bernoulli_distribution (briefly
4818 mentioned earlier), as well as the cases of the geometric_distribution and the
4819 poisson_distribution, it would be far more natural to have a real input_type.
4820 This is because the most natural computation involves the  random number
4821 delivered and the distributionÕs parameter p (in the case of bernoulli_distribution,
4822 for example, the computation is a comparison against p), and p is already specified
4823 in each case as having some real type.
4824 </p>
4825 <p><b>Proposed resolution:</b></p>
4826 <blockquote><pre>typedef  RealType  input_type;
4827 </pre></blockquote>
4828 <hr>
4829 <a name="512"></a><h3><a name="512">512.&nbsp;Seeding subtract_with_carry_01 from a single unsigned long</a></h3><p><b>Section:</b>&nbsp;TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
4830 <p>
4831 Paragraph 8 specifies the algorithm by which a subtract_with_carry_01  engine
4832 is to be seeded given a single unsigned long.  This algorithm is seriously
4833 flawed in the case where the engine parameter w (also known as word_size)
4834 exceeds 31 [bits].  The key part of the paragraph reads:
4835 </p>
4836 <blockquote>
4837 sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1
4838 </blockquote>
4839 <p>
4840 and so forth.
4841 </p>
4842 <p>
4843 Since the specified linear congruential engine, lcg, delivers numbers with
4844 a maximum of 2147483563 (just a shade under 31 bits), then when w is, for
4845 example, 48, each of the x(i) will be less than 2**-17.  The consequence
4846 is that roughly the first 400 numbers delivered will be  conspicuously
4847 close to either zero or one.
4848 </p>
4849 <p>
4850 Unfortunately, this is not an innocuous flaw:  One of the predefined engines
4851 in [tr.rand.predef],  namely ranlux64_base_01, has w = 48 and would exhibit
4852 this poor behavior, while the original N1378 proposal states that these
4853 pre-defined engines are intended to be of "known good properties."
4854 </p>
4855 <p><b>Proposed resolution:</b></p>
4856 <p>
4857 In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for
4858 void seed(unsigned long value = 19780503) by
4859 </p>
4860
4861 <blockquote>
4862 <i>Effects:</i> If <tt>value == 0</tt>, sets value to <tt>19780503</tt>. In any
4863 case, <del>with a linear congruential generator <tt>lcg</tt>(i) having parameters
4864 <tt><i>m<sub>lcg</sub></i> = 2147483563</tt>, <tt><i>a<sub>lcg</sub></i> = 40014</tt>,
4865 <tt><i>c<sub>lcg</sub></i> = 0</tt>, and <tt><i>lcg</i>(0) = value</tt>,</del>
4866 sets <ins>carry<tt>(-1)</tt> and</ins> <tt>x(-r) &#8230; x(-1)</tt>
4867 <ins>as if executing</ins>
4868
4869 <blockquote><pre><ins>
4870 linear_congruential&lt;unsigned long, 40014, 0, 2147483563&gt; lcg(value);
4871 seed(lcg);
4872 </ins></pre></blockquote>
4873
4874 <del>to <tt>(<i>lcg</i>(1) · 2<sup>-<i>w</i></sup>) mod 1
4875 &#8230; (<i>lcg</i>(<i>r</i>) · 2<sup>-<i>w</i></sup>) mod 1</tt>,
4876 respectively. If <tt><i>x</i>(-1) == 0</tt>, sets carry<tt>(-1) = 2<sup>-<i>w</i></sup></tt>,
4877 else sets carry<tt>(-1) = 0</tt>.</del>
4878 </blockquote>
4879
4880 <p><i>[
4881 Jens provided revised wording post Mont Tremblant.
4882 ]</i></p>
4883
4884 <p><b>Rationale:</b></p>
4885 <p>
4886 Jens: I'm using an explicit type here, because fixing the
4887 prose would probably not qualify for the (with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a> even
4888 stricter) requirements we have for seed(Gen&amp;).
4889 </p>
4890 <hr>
4891 <a name="513"><h3>513.&nbsp;Size of state for subtract_with_carry_01</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
4892 <p>
4893 Paragraph 3 begins:
4894 </p>
4895 <blockquote>
4896 The size of the state is r.
4897 </blockquote>
4898 <p>
4899 However, this is not quite consistent with the remainder of the paragraph
4900 which specifies a total  of nr+1 items in the textual representation of
4901 the state.  We recommend the sentence be corrected to match:
4902 </p>
4903 <blockquote>
4904 The size of the state is nr+1.
4905 </blockquote>
4906 <p>
4907 To give meaning to the coefficient n, it may be also desirable to move
4908 nÕs definition from later in the paragraph.  Either of the following
4909 seem reasonable formulations:
4910 </p>
4911 <blockquote>
4912 With n=..., the size of the state is nr+1.
4913 </blockquote>
4914 <blockquote>
4915 The size of the state is nr+1, where n=... .
4916 </blockquote>
4917 <p>
4918 </p>
4919 <p><b>Proposed resolution:</b></p>
4920 <p><i>[
4921 Jens:  I plead for "NAD" on the grounds that "size of state" is only
4922 used as an argument for big-O complexity notation, thus
4923 constant factors and additions don't count.
4924 ]</i></p>
4925 <hr>
4926 <a name="514"><h3>514.&nbsp;Size of state for subtract_with_carry</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub"> [tr.rand.eng.sub]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
4927 <p>
4928 Paragraph 2 begins:
4929 </p>
4930 <blockquote>
4931 The size of the state is r.
4932 </blockquote>
4933 <p>
4934 However, the next sentence specifies a total of r+1 items in the textual
4935 representation of the state,  r specific xÕs as well as a specific carry.
4936 This makes a total of r+1 items that constitute the size of the state,
4937 rather than r.
4938 </p>
4939 <p><b>Proposed resolution:</b></p>
4940 <p>
4941 We recommend the sentence be corrected to match:
4942 </p>
4943 <blockquote>
4944  The size of the state is r+1.
4945 </blockquote>
4946
4947 <p><i>[
4948 Jens:  I plead for "NAD" on the grounds that "size of state" is only
4949 used as an argument for big-O complexity notation, thus
4950 constant factors and additions don't count.
4951 ]</i></p>
4952
4953 <hr>
4954 <a name="515"><h3>515.&nbsp;Random number engine traits</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.synopsis"> [tr.rand.synopsis]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
4955 <p>
4956 To accompany the concept of a pseudo-random number engine as defined in Table 17,
4957 we propose and recommend an adjunct template, engine_traits, to be declared in
4958 [tr.rand.synopsis] as:
4959 </p>
4960 <blockquote><pre>template&lt; class PSRE &gt;
4961 class engine_traits;
4962 </pre></blockquote>
4963 <p>
4964 This templateÕs primary purpose would be as an aid to generic programming involving
4965 pseudo-random number engines.  Given only the facilities described in tr1, it would
4966 be very difficult to produce any algorithms involving the notion of a generic engine.
4967 The intent of this proposal is to  provide, via engine_traits&lt;&gt;, sufficient
4968 descriptive information to allow an algorithm to employ a pseudo-random number engine
4969 without regard to its exact type, i.e., as a template parameter.
4970 </p>
4971 <p>
4972 For example, today it is not possible to write an efficient generic function that
4973 requires any specific number of random bits.  More specifically, consider a
4974 cryptographic application that internally needs 256 bits of randomness per call:
4975 </p>
4976 <blockquote><pre>template&lt; class Eng, class InIter, class OutIter &gt;
4977 void crypto( Eng&amp; e, InIter in, OutIter out );
4978 </pre></blockquote>
4979 <p>
4980 Without knowning the number of bits of randomness produced per call to a provided
4981 engine, the algorithm has no means of determining how many times to call the engine.
4982 </p>
4983 <p>
4984 In a new section [tr.rand.eng.traits], we proposed to define the engine_traits
4985 template as:
4986 </p>
4987 <blockquote><pre>template&lt; class PSRE &gt;
4988 class engine_traits
4989 {
4990   static  std::size_t  bits_of_randomness = 0u;
4991   static  std::string  name()  { return "unknown_engine"; }
4992   // TODO: other traits here
4993 };
4994 </pre></blockquote>
4995 <p>
4996 Further, each engine described in [tr.rand.engine] would be accompanied by a
4997 complete specialization of this new engine_traits template.
4998 </p>
4999 <p><b>Proposed resolution:</b></p>
5000 <p>
5001
5002 </p>
5003 <hr>
5004 <a name="516"><h3>516.&nbsp;Seeding subtract_with_carry_01 using a generator</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
5005 <p>
5006 Paragraph 6 says:
5007 </p>
5008 <blockquote>
5009 ... obtained by successive invocations of g, ...
5010 </blockquote>
5011 <p>
5012 We recommend instead:
5013 </p>
5014 <blockquote>
5015 ... obtained by taking successive invocations of g mod 2**32, ...
5016 </blockquote>
5017 <p>
5018 as the context seems to require only 32-bit quantities be used here.
5019 </p>
5020 <p><b>Proposed resolution:</b></p>
5021 <p>
5022
5023 </p>
5024 <hr>
5025 <a name="517"><h3>517.&nbsp;Should include name in external representation</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
5026 <p>
5027 The last two rows of Table 16 deal with the i/o requirements of an engine,
5028 specifying that the textual representation of an engineÕs state,
5029 appropriately formatted, constitute the engineÕs  external representation.
5030 </p>
5031 <p>
5032 This seems adequate when an engineÕs type is known.  However, it seems
5033 inadequate in the  context of generic code, where it becomes useful and
5034 perhaps even necessary to determine an engineÕs type via input.
5035 </p>
5036 <p>
5037 </p>
5038 <p><b>Proposed resolution:</b></p>
5039 <p>
5040 We therefore recommend that, in each of these two rows of Table 16, the
5041 text "textual representation" be expanded so as to read "engine name
5042 followed by the textual representation."
5043 </p>
5044 <hr>
5045 <a name="518"><h3>518.&nbsp;Are insert and erase stable for unordered_multiset and unordered_multimap?</h3></a><p><b>Section:</b>&nbsp;TR1 6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.hash"> [tr.hash]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
5046 <p>
5047 Issue 371 deals with stability of multiset/multimap under insert and erase
5048 (i.e. do they preserve the relative order in ranges of equal elements).
5049 The same issue applies to unordered_multiset and unordered_multimap.
5050 </p>
5051 <p><b>Proposed resolution:</b></p>
5052 <p>
5053 </p>
5054 <hr>
5055 <a name="519"><h3>519.&nbsp;Data() undocumented</h3></a><p><b>Section:</b>&nbsp;TR1 6.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.array.array"> [tr.array.array]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
5056 <p>
5057 <tt>array&lt;&gt;::data()</tt> is present in the class synopsis, but not documented.
5058 </p>
5059 <p><b>Proposed resolution:</b></p>
5060 <p>
5061 Add a new section, after 6.2.2.3:
5062 </p>
5063 <blockquote><pre>T*       data()
5064 const T* data() const;
5065 </pre></blockquote>
5066 <p>
5067 <b>Returns:</b> <tt>elems</tt>.
5068 </p>
5069 <p>
5070 Change 6.2.2.4/2 to:
5071 </p>
5072 <blockquote>
5073 In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value
5074 of <tt>data()</tt> is unspecified.
5075 </blockquote>
5076 <hr>
5077 <a name="520"><h3>520.&nbsp;Result_of and pointers to data members</h3></a><p><b>Section:</b>&nbsp;TR1 3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind"> [tr.func.bind]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
5078 <p>
5079 In the original proposal for binders, the return type of bind() when
5080 called with a pointer to member data as it's callable object was
5081 defined to be mem_fn(ptr); when Peter Dimov and I  unified the
5082 descriptions of the TR1 function objects we hoisted the descriptions
5083 of return types into the INVOKE pseudo-function and into result_of.
5084 Unfortunately, we left pointer to member data out of result_of, so
5085 bind doesn't have any specified behavior when called with a pointer
5086 to  member data.
5087 </p>
5088 <p><b>Proposed resolution:</b></p>
5089 <p><i>[
5090 Pete and Peter will provide wording.
5091 ]</i></p>
5092 <hr>
5093 <a name="521"><h3>521.&nbsp;Garbled requirements for argument_type in reference_wrapper</h3></a><p><b>Section:</b>&nbsp;TR1 2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.refwrp.refwrp"> [tr.util.refwrp.refwrp]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
5094 <p>
5095 2.1.2/3, second bullet item currently says that reference_wrapper&lt;T&gt; is
5096 derived from unary_function&lt;T, R&gt; if T is:
5097 </p>
5098 <blockquote>
5099 a pointer to member function type with cv-qualifier cv and no arguments;
5100 the type T1 is cv T* and R is the return type of the pointer to member function;
5101 </blockquote>
5102 <p>
5103 The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member
5104 function. It should be a pointer to the class that T is a pointer to member of.
5105 Like this:
5106 </p>
5107 <blockquote>
5108 a pointer to a member function R T0::f() cv (where cv represents the member
5109 function's cv-qualifiers); the type T1 is cv T0*
5110 </blockquote>
5111 <p>
5112 Similarly, bullet item 2 in 2.1.2/4 should be:
5113 </p>
5114 <blockquote>
5115 a pointer to a member function R T0::f(T2) cv (where cv represents the member
5116 function's cv-qualifiers); the type T1 is cv T0*
5117 </blockquote>
5118 <p><b>Proposed resolution:</b></p>
5119 <hr>
5120 <a name="522"></a><h3><a name="522">522.&nbsp;Tuple doesn't define swap</a></h3><p><b>Section:</b>&nbsp;TR1 6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.tuple"> [tr.tuple]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Koenig&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
5121 <p>
5122 Tuple doesn't define swap().  It should.
5123 </p>
5124 <p><b>Proposed resolution:</b></p>
5125 <hr>
5126 <a name="523"><h3>523.&nbsp;regex case-insensitive character ranges are unimplementable as specified</h3></a><p><b>Section:</b>&nbsp;TR1 7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.re"> [tr.re]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Eric Niebler&nbsp; <b>Date:</b>&nbsp;1 Jul 2005</p>
5127 <p>
5128 A problem with TR1 regex is currently being discussed on the Boost
5129 developers list. It involves the handling of case-insensitive matching
5130 of character ranges such as [Z-a]. The proper behavior (according to the
5131 ECMAScript standard) is unimplementable given the current specification
5132 of the TR1 regex_traits&lt;&gt; class template. John Maddock, the author of
5133 the TR1 regex proposal, agrees there is a problem. The full discussion
5134 can be found at http://lists.boost.org/boost/2005/06/28850.php (first
5135 message copied below). We don't have any recommendations as yet.
5136 </p>
5137 <p>
5138 -- Begin original message --
5139 </p>
5140 <p>
5141 The situation of interest is described in the ECMAScript specification
5142 (ECMA-262), section 15.10.2.15:
5143 </p>
5144 <p>
5145 "Even if the pattern ignores case, the case of the two ends of a range
5146 is significant in determining which characters belong to the range.
5147 Thus, for example, the pattern /[E-F]/i matches only the letters E, F,
5148 e, and f, while the pattern /[E-f]/i matches all upper and lower-case
5149 ASCII letters as well as the symbols [, \, ], ^, _, and `."
5150 </p>
5151 <p>
5152 A more interesting case is what should happen when doing a
5153 case-insentitive match on a range such as [Z-a]. It should match z, Z,
5154 a, A and the symbols [, \, ], ^, _, and `. This is not what happens with
5155 Boost.Regex (it throws an exception from the regex constructor).
5156 </p>
5157 <p>
5158 The tough pill to swallow is that, given the specification in TR1, I
5159 don't think there is any effective way to handle this situation.
5160 According to the spec, case-insensitivity is handled with
5161 regex_traits&lt;&gt;::translate_nocase(CharT) -- two characters are equivalent
5162 if they compare equal after both are sent through the translate_nocase
5163 function. But I don't see any way of using this translation function to
5164 make character ranges case-insensitive. Consider the difficulty of
5165 detecting whether "z" is in the range [Z-a]. Applying the transformation
5166 to "z" has no effect (it is essentially std::tolower). And we're not
5167 allowed to apply the transformation to the ends of the range, because as
5168 ECMA-262 says, "the case of the two ends of a range is significant."
5169 </p>
5170 <p>
5171 So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix
5172 is to redefine translate_nocase to return a string_type containing all
5173 the characters that should compare equal to the specified character. But
5174 this function is hard to implement for Unicode, and it doesn't play nice
5175 with the existing ctype facet. What a mess!
5176 </p>
5177 <p>
5178 -- End original message --
5179 </p>
5180
5181 <p><i>[
5182 John Maddock adds:
5183 ]</i></p>
5184
5185 <p>
5186 One small correction, I have since found that ICU's regex package does
5187 implement this correctly, using a similar mechanism to the current
5188 TR1.Regex.
5189 </p>
5190 <p>
5191 Given an expression [c1-c2] that is compiled as case insensitive it:
5192 </p>
5193 <p>
5194 Enumerates every character in the range c1 to c2 and converts it to it's
5195 case folded equivalent.  That case folded character is then used a key to a
5196 table of equivalence classes, and each member of the class is added to the
5197 list of possible matches supported by the character-class.  This second step
5198 isn't possible with our current traits class design, but isn't necessary if
5199 the input text is also converted to a case-folded equivalent on the fly.
5200 </p>
5201 <p>
5202 ICU applies similar brute force mechanisms to character classes such as
5203 [[:lower:]] and [[:word:]], however these are at least cached, so the impact
5204 is less noticeable in this case.
5205 </p>
5206 <p>
5207 Quick and dirty performance comparisons show that expressions such as
5208 "[X-\\x{fff0}]+" are indeed very slow to compile with ICU (about 200 times
5209 slower than a "normal" expression).  For an application that uses a lot of
5210 regexes this could have a noticeable performance impact.  ICU also has an
5211 advantage in that it knows the range of valid characters codes: code points
5212 outside that range are assumed not to require enumeration, as they can not
5213 be part of any equivalence class.  I presume that if we want the TR1.Regex
5214 to work with arbitrarily large character sets enumeration really does become
5215 impractical.
5216 </p>
5217 <p>
5218 Finally note that Unicode has:
5219 </p>
5220 <p>
5221 Three cases (upper, lower and title).
5222 One to many, and many to one case transformations.
5223 Character that have context sensitive case translations - for example an
5224 uppercase sigma has two different lowercase forms  - the form chosen depends
5225 on context(is it end of a word or not), a caseless match for an upper case
5226 sigma should match either of the lower case forms, which is why case folding
5227 is often approximated by tolower(toupper(c)).
5228 </p>
5229 <p>
5230 Probably we need some way to enumerate character equivalence classes,
5231 including digraphs (either as a result or an input), and some way to tell
5232 whether the next character pair is a valid digraph in the current locale.
5233 </p>
5234 <p>
5235 Hoping this doesn't make this even more complex that it was already,
5236 </p>
5237
5238 <p><b>Proposed resolution:</b></p>
5239 <hr>
5240 <a name="524"><h3>524.&nbsp;regex named character classes and case-insensitivity don't mix</h3></a><p><b>Section:</b>&nbsp;TR1 7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.re"> [tr.re]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Eric Niebler&nbsp; <b>Date:</b>&nbsp;1 Jul 2005</p>
5241 <p>
5242 This defect is also being discussed on the Boost developers list. The
5243 full discussion can be found here:
5244 http://lists.boost.org/boost/2005/07/29546.php
5245 </p>
5246 <p>
5247 -- Begin original message --
5248 </p>
5249 <p>
5250 Also, I may have found another issue, closely related to the one under
5251 discussion. It regards case-insensitive matching of named character
5252 classes. The regex_traits&lt;&gt; provides two functions for working with
5253 named char classes: lookup_classname and isctype. To match a char class
5254 such as [[:alpha:]], you pass "alpha" to lookup_classname and get a
5255 bitmask. Later, you pass a char and the bitmask to isctype and get a
5256 bool yes/no answer.
5257 </p>
5258 <p>
5259 But how does case-insensitivity work in this scenario? Suppose we're
5260 doing a case-insensitive match on [[:lower:]]. It should behave as if it
5261 were [[:lower:][:upper:]], right? But there doesn't seem to be enough
5262 smarts in the regex_traits interface to do this.
5263 </p>
5264 <p>
5265 Imagine I write a traits class which recognizes [[:fubar:]], and the
5266 "fubar" char class happens to be case-sensitive. How is the regex engine
5267 to know that? And how should it do a case-insensitive match of a
5268 character against the [[:fubar:]] char class? John, can you confirm this
5269 is a legitimate problem?
5270 </p>
5271 <p>
5272 I see two options:
5273 </p>
5274 <p>
5275 1) Add a bool icase parameter to lookup_classname. Then,
5276 lookup_classname( "upper", true ) will know to return lower|upper
5277 instead of just upper.
5278 </p>
5279 <p>
5280 2) Add a isctype_nocase function
5281 </p>
5282 <p>
5283 I prefer (1) because the extra computation happens at the time the
5284 pattern is compiled rather than when it is executed.
5285 </p>
5286 <p>
5287 -- End original message --
5288 </p>
5289
5290 <p>
5291 For what it's worth, John has also expressed his preference for option
5292 (1) above.
5293 </p>
5294 <p><b>Proposed resolution:</b></p>
5295 <hr>
5296 <a name="525"><h3>525.&nbsp;type traits definitions not clear</h3></a><p><b>Section:</b>&nbsp;TR1 4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.meta.unary"> [tr.meta.unary]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Robert Klarer&nbsp; <b>Date:</b>&nbsp;11 Jul 2005</p>
5297 <p>
5298 It is not completely clear how the primary type traits deal with
5299 cv-qualified types.  And several of the secondary type traits
5300 seem to be lacking a definition.
5301 </p>
5302 <p><b>Proposed resolution:</b></p>
5303 <hr>
5304 <a name="526"></a><h3><a name="526">526.&nbsp;Is it undefined if a function in the standard changes in parameters?</a></h3><p><b>Section:</b>&nbsp;23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Chris Jefferson&nbsp; <b>Date:</b>&nbsp;14 Sep 2005</p>
5305 <p>
5306 Problem: There are a number of places in the C++ standard library where
5307 it is possible to write what appear to be sensible ways of calling
5308 functions, but which can cause problems in some (or all)
5309 implementations, as they cause the values given to the function to be
5310 changed in a way not specified in standard (and therefore not coded to
5311 correctly work). These fall into two similar categories.
5312 </p>
5313
5314 <p>
5315 1) Parameters taken by const reference can be changed during execution
5316 of the function
5317 </p>
5318
5319 <p>
5320 Examples:
5321 </p>
5322
5323 <p>
5324 Given std::vector&lt;int&gt; v:
5325 </p>
5326 <p>
5327 v.insert(v.begin(), v[2]);
5328 </p>
5329 <p>
5330 v[2] can be changed by moving elements of vector
5331 </p>
5332
5333
5334 <p>
5335 Given std::list&lt;int&gt; l:
5336 </p>
5337 <p>
5338 l.remove(*l.begin());
5339 </p>
5340 <p>
5341 Will delete the first element, and then continue trying to access it.
5342 This is particularily vicious, as it will appear to work in almost all
5343 cases.
5344 </p>
5345
5346 <p>
5347 2) A range is given which changes during the execution of the function:
5348 Similarly,
5349 </p>
5350
5351 <p>
5352 v.insert(v.begin(), v.begin()+4, v.begin()+6);
5353 </p>
5354
5355 <p>
5356 This kind of problem has been partly covered in some cases. For example
5357 std::copy(first, last, result) states that result cannot be in the range
5358 [first, last). However, does this cover the case where result is a
5359 reverse_iterator built from some iterator in the range [first, last)?
5360 Also, std::copy would still break if result was reverse_iterator(last +
5361 1), yet this is not forbidden by the standard
5362 </p>
5363
5364 <p>
5365 Solution:
5366 </p>
5367
5368 <p>
5369 One option would be to try to more carefully limit the requirements of
5370 each function. There are many functions which would have to be checked.
5371 However as has been shown in the std::copy case, this may be difficult.
5372 A simpler, more global option would be to somewhere insert text similar to:
5373 </p>
5374
5375 <p>
5376 If the execution of any function would change either any values passed
5377 by reference or any value in any range passed to a function in a way not
5378 defined in the definition of that function, the result is undefined.
5379 </p>
5380
5381 <p>
5382 Such code would have to at least cover chapters 23 and 25 (the sections
5383 I read through carefully). I can see no harm on applying it to much of
5384 the rest of the standard.
5385 </p>
5386
5387 <p>
5388 Some existing parts of the standard could be improved to fit with this,
5389 for example the requires for 25.2.1 (Copy) could be adjusted to:
5390 </p>
5391
5392 <p>
5393 Requires: For each non-negative integer n &lt; (last - first), assigning to
5394 *(result + n) must not alter any value in the range [first + n, last).
5395 </p>
5396
5397 <p>
5398 However, this may add excessive complication.
5399 </p>
5400
5401 <p>
5402 One other benefit of clearly introducing this text is that it would
5403 allow a number of small optimisations, such as caching values passed
5404 by const reference.
5405 </p>
5406
5407 <p><b>Proposed resolution:</b></p>
5408 <p>
5409 </p>
5410 <hr>
5411 <a name="527"><h3>527.&nbsp;tr1::bind has lost its Throws clause</h3></a><p><b>Section:</b>&nbsp;TR1 3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind.bind"> [tr.func.bind.bind]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;01 Oct 2005</p>
5412 <p>
5413 The original bind proposal gives the guarantee that tr1::bind(f, t1,
5414 ..., tN) does not throw when the copy constructors of f, t1, ..., tN
5415 don't.
5416 </p>
5417
5418 <p>
5419 This guarantee is not present in the final version of TR1.
5420 </p>
5421
5422 <p>
5423 I'm pretty certain that we never removed it on purpose. Editorial omission? :-)
5424 </p>
5425 <p><b>Proposed resolution:</b></p>
5426 <p>
5427 </p>
5428 <hr>
5429 <a name="528"><h3>528.&nbsp;TR1: issue 6.19 vs 6.3.4.3/2 (and 6.3.4.5/2)</h3></a><p><b>Section:</b>&nbsp;TR1 6.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.unord.unord"> [tr.unord.unord]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Paolo Carlini&nbsp; <b>Date:</b>&nbsp;12 Oct 2005</p>
5430 <p>
5431 while implementing the resolution of issue 6.19 I'm noticing the
5432 following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and
5433 unordered_multiset:
5434 </p>
5435
5436 <blockquote>
5437     "The iterator and const_iterator types are both const types. It is
5438 unspecified whether they are the same type"
5439 </blockquote>
5440
5441 <p>
5442 Now, according to the resolution of 6.19, we have overloads of insert
5443 with hint and erase (single and range) both for iterator and
5444 const_iterator, which, AFAICS, can be meaningful at the same time *only*
5445 if iterator and const_iterator *are* in fact different types.
5446 </p>
5447 <p>
5448 Then, iterator and const_iterator are *required* to be different types?
5449 Or that is an unintended consequence? Maybe the overloads for plain
5450 iterators should be added only to unordered_map and unordered_multimap?
5451 Or, of course, I'm missing something?
5452 </p>
5453
5454 <p><b>Proposed resolution:</b></p>
5455 <p>
5456 Add to 6.3.4.3p2 (and 6.3.4.5p2):
5457 </p>
5458 <p>
5459 2  ... The iterator and const_iterator types are both <del>const</del>
5460 <ins>constant</ins> iterator types.
5461 It is unspecified whether they are the same type. <ins>If they are the
5462 same type, those signatures that become otherwise indistinguishable
5463 collapse into a single signature.</ins>
5464 </p>
5465
5466 <p>----- End of document -----</p>
5467 </body></html>