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

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
   2 <html><head><title>C++ Standard Library Defect Report List</title>
   3
   4 <style type="text/css">
   5 p {text-align:justify}
   6 li {text-align:justify}
   7 ins {background-color:#FFFFA0}
   8 del {background-color:#FFFFA0}
   9 </style></head>
  10
  11 <body>
  12 <table>
  13 <tbody><tr>
  14 <td align="left">Doc. no.</td>
  15 <td align="left">N2318=07-0178</td>
  16 </tr>
  17 <tr>
  18 <td align="left">Date:</td>
  19 <td align="left">2007-06-24</td>
  20 </tr>
  21 <tr>
  22 <td align="left">Project:</td>
  23 <td align="left">Programming Language C++</td>
  24 </tr>
  25 <tr>
  26 <td align="left">Reply to:</td>
  27 <td align="left">Howard Hinnant &lt;<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>&gt;</td>
  28 </tr>
  29 </tbody></table>
  30 <h1>C++ Standard Library Defect Report List (Revision R49)</h1>
  31
  32   <p>Reference ISO/IEC IS 14882:1998(E)</p>
  33   <p>Also see:</p>
  34     <ul>
  35       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
  36       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
  37       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
  38       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li>
  39       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
  40     </ul>
  41   <p>This document contains only library issues which have been closed
  42   by the Library Working Group (LWG) after being found to be defects
  43   in the standard.  That is, issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>,
  44   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>, or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a>. See the
  45   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues closed as non-defects.  See the
  46   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> for active issues and more information.  The
  47   introductory material in that document also applies to this
  48   document.</p>
  49
  50 <h2>Revision History</h2>
  51 <ul>
  52 <li>R49:
  53 2007-06-23 pre-Toronto mailing.
  54 <ul>
  55 <li><b>Summary:</b><ul>
  56 <li>158 open issues, up by 13.</li>
  57 <li>538 closed issues, up by 7.</li>
  58 <li>696 issues total, up by 20.</li>
  59 </ul></li>
  60 <li><b>Details:</b><ul>
  61 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
  62 <li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#683">683</a>.</li>
  63 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>.</li>
  64 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>.</li>
  65 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>.</li>
  66 </ul></li>
  67 </ul>
  68 </li>
  69 <li>R48:
  70 2007-05-06 post-Oxford mailing.
  71 <ul>
  72 <li><b>Summary:</b><ul>
  73 <li>145 open issues, down by 33.</li>
  74 <li>531 closed issues, up by 53.</li>
  75 <li>676 issues total, up by 20.</li>
  76 </ul></li>
  77 <li><b>Details:</b><ul>
  78 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
  79 <li>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li>
  80 <li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
  81 <li>Changed the following issues from NAD to NAD Editorial: <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#357">357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#368">368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>.</li>
  82 <li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>.</li>
  83 <li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <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#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <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-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <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-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
  84 <li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
  85 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
  86 <li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>.</li>
  87 <li>Changed the following issues from Tentatively Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
  88 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#646">646</a>.</li>
  89 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#604">604</a>.</li>
  90 <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>.</li>
  91 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>.</li>
  92 <li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
  93 </ul></li>
  94 </ul>
  95 </li>
  96 <li>R47:
  97 2007-03-09 pre-Oxford mailing.
  98 <ul>
  99 <li><b>Summary:</b><ul>
 100 <li>178 open issues, up by 37.</li>
 101 <li>478 closed issues, up by 0.</li>
 102 <li>656 issues total, up by 37.</li>
 103 </ul></li>
 104 <li><b>Details:</b><ul>
 105 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
 106 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#626">626</a>.</li>
 107 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li>
 108 <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
 109 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
 110 <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>.</li>
 111 </ul></li>
 112 </ul>
 113 </li>
 114 <li>R46:
 115 2007-01-12 mid-term mailing.
 116 <ul>
 117 <li><b>Summary:</b><ul>
 118 <li>141 open issues, up by 11.</li>
 119 <li>478 closed issues, down by 1.</li>
 120 <li>619 issues total, up by 10.</li>
 121 </ul></li>
 122 <li><b>Details:</b><ul>
 123 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
 124 </ul></li>
 125 </ul>
 126 </li>
 127 <li>R45:
 128 2006-11-03 post-Portland mailing.
 129 <ul>
 130 <li><b>Summary:</b><ul>
 131 <li>130 open issues, up by 0.</li>
 132 <li>479 closed issues, up by 17.</li>
 133 <li>609 issues total, up by 17.</li>
 134 </ul></li>
 135 <li><b>Details:</b><ul>
 136 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a> to WP.</li>
 137 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a> to NAD.</li>
 138 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
 139 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <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#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
 140 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a> to Ready.</li>
 141 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#604">604</a> to Review.</li>
 142 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>.</li>
 143 </ul></li>
 144 </ul>
 145 </li>
 146 <li>R44:
 147 2006-09-08 pre-Portland mailing.
 148 <ul>
 149 <li><b>Summary:</b><ul>
 150 <li>130 open issues, up by 6.</li>
 151 <li>462 closed issues, down by 1.</li>
 152 <li>592 issues total, up by 5.</li>
 153 </ul></li>
 154 <li><b>Details:</b><ul>
 155 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#583">583</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#592">592</a>.</li>
 156 </ul></li>
 157 </ul>
 158 </li>
 159 <li>R43:
 160 2006-06-23 mid-term mailing.
 161 <ul>
 162 <li><b>Summary:</b><ul>
 163 <li>124 open issues, up by 14.</li>
 164 <li>463 closed issues, down by 1.</li>
 165 <li>587 issues total, up by 13.</li>
 166 </ul></li>
 167 <li><b>Details:</b><ul>
 168 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>.</li>
 169 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
 170 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Tentatively Ready.</li>
 171 </ul></li>
 172 </ul>
 173 </li>
 174 <li>R42:
 175 2006-04-21 post-Berlin mailing.
 176 <ul>
 177 <li><b>Summary:</b><ul>
 178 <li>110 open issues, down by 16.</li>
 179 <li>464 closed issues, up by 24.</li>
 180 <li>574 issues total, up by 8.</li>
 181 </ul></li>
 182 <li><b>Details:</b><ul>
 183 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
 184 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li>
 185 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#548">548</a> to Open.</li>
 186 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li>
 187 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li>
 188 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
 189 </ul></li>
 190 </ul>
 191 </li>
 192 <li>R41:
 193 2006-02-24 pre-Berlin mailing.
 194 <ul>
 195 <li><b>Summary:</b><ul>
 196 <li>126 open issues, up by 31.</li>
 197 <li>440 closed issues, up by 0.</li>
 198 <li>566 issues total, up by 31.</li>
 199 </ul></li>
 200 <li><b>Details:</b><ul>
 201 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#566">566</a>.</li>
 202 <li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
 203 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
 204 </ul></li>
 205 </ul>
 206 </li>
 207 <li>R40:
 208 2005-12-16 mid-term mailing.
 209 <ul>
 210 <li><b>Summary:</b><ul>
 211 <li>95 open issues.</li>
 212 <li>440 closed issues.</li>
 213 <li>535 issues total.</li>
 214 </ul></li>
 215 <li><b>Details:</b><ul>
 216 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
 217 </ul></li>
 218 </ul>
 219 </li>
 220 <li>R39:
 221 2005-10-14 post-Mont Tremblant mailing.
 222 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#528">528</a>.
 223 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.
 224 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a> from Review to Ready.
 225 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-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open.
 226 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready.
 227 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
 228 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
 229 </li>
 230 <li>R38:
 231 2005-07-03 pre-Mont Tremblant mailing.
 232 Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
 233 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>
 234 </li>
 235 <li>R37:
 236 2005-06 mid-term mailing.
 237 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>.
 238 </li>
 239 <li>R36:
 240 2005-04 post-Lillehammer mailing. All issues in "ready" status except
 241 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
 242 previously in "DR" status were moved to "WP".
 243 </li>
 244 <li>R35:
 245 2005-03 pre-Lillehammer mailing.
 246 </li>
 247 <li>R34:
 248 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>.
 249 </li>
 250 <li>R33:
 251 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
 252 </li>
 253 <li>R32:
 254 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
 255 new issues received after the 2004-07 mailing.  Added
 256 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>.
 257 </li>
 258 <li>R31:
 259 2004-07 mid-term mailing: reflects new proposed resolutions and
 260 new issues received after the post-Sydney mailing.  Added
 261 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
 262 </li>
 263 <li>R30:
 264 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 265 Voted all "Ready" issues from R29 into the working paper.
 266 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>.
 267 </li>
 268 <li>R29:
 269 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>.
 270 </li>
 271 <li>R28:
 272 Post-Kona mailing: reflects decisions made at the Kona meeting.
 273 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>.
 274 </li>
 275 <li>R27:
 276 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>.
 277 </li>
 278 <li>R26:
 279 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
 280 All issues in Ready status were voted into DR status.  All issues in
 281 DR status were voted into WP status.
 282 </li>
 283 <li>R25:
 284 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>.
 285 </li>
 286 <li>R24:
 287 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
 288 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
 289 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
 290 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
 291 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
 292 </li>
 293 <li>R23:
 294 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>.
 295 Moved issues in the TC to TC status.
 296 </li>
 297 <li>R22:
 298 Post-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>.
 299 </li>
 300 <li>R21:
 301 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>.
 302 </li>
 303 <li>R20:
 304 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 305 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
 306 <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
 307 not discussed at the meeting.
 308
 309 All Ready issues were moved to DR status, with the exception of issues
 310 <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>.
 311
 312 Noteworthy issues discussed at Redmond include
 313 <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-defects.html#233">233</a>,
 314 <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-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.
 315 </li>
 316 <li>R19:
 317 Pre-Redmond mailing.  Added new issues
 318 <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>.
 319 </li>
 320 <li>R18:
 321 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
 322 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
 323 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>.
 324
 325 Changed status of issues
 326 <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>
 327 <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>
 328 <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>
 329 <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>
 330 <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>
 331 <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>
 332 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
 333 to DR.
 334
 335 Changed status of issues
 336 <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>
 337 <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>
 338 <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>
 339 <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>
 340 <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>
 341 <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>
 342 <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>
 343 <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>
 344 <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>
 345 to Ready.
 346
 347 Closed issues
 348 <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>
 349 <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>
 350 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
 351 as NAD.
 352
 353 </li>
 354 <li>R17:
 355 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 356 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>.
 357 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>.
 358 </li>
 359 <li>R16:
 360 post-Toronto mailing; reflects actions taken in Toronto. Added new
 361 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
 362 <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>,
 363 <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>,
 364 <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>,
 365 <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>,
 366 <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>,
 367 <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>,
 368 <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>,
 369 <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>,
 370 <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>,
 371 <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>,
 372 <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>,
 373 <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>,
 374 <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
 375 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
 376 <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
 377 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
 378 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
 379 the bug in enough places.
 380 </li>
 381 <li>R15:
 382 pre-Toronto mailing. Added issues
 383 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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
 384 changes so that we pass Weblint tests.
 385 </li>
 386 <li>R14:
 387 post-Tokyo II mailing; reflects committee actions taken in
 388 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)
 389 </li>
 390 <li>R13:
 391 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>.
 392 </li>
 393 <li>R12:
 394 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
 395 <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
 396 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
 397 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
 398 </li>
 399 <li>R11:
 400 post-Kona mailing: Updated to reflect LWG and full committee actions
 401 in Kona (99-0048/N1224). Note changed resolution of issues
 402 <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>
 403 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
 404 "closed" documents.  Changed the proposed resolution of issue
 405 <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
 406 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
 407 </li>
 408 <li>R10:
 409 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 410 <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>,
 411 <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
 412 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 413 </li>
 414 <li>R9:
 415 pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
 416 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
 417 "closed" documents. (99-0030/N1206, 25 Aug 99)
 418 </li>
 419 <li>R8:
 420 post-Dublin mailing. Updated to reflect LWG and full committee actions
 421 in Dublin. (99-0016/N1193, 21 Apr 99)
 422 </li>
 423 <li>R7:
 424 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>,
 425 <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>,
 426 <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>,
 427 <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)
 428 </li>
 429 <li>R6:
 430 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>,
 431 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 432 </li>
 433 <li>R5:
 434 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
 435 <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
 436 for making list public. (30 Dec 98)
 437 </li>
 438 <li>R4:
 439 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
 440 <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
 441 issues corrected. (22 Oct 98)
 442 </li>
 443 <li>R3:
 444 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>
 445 added, many issues updated to reflect LWG consensus (12 Oct 98)
 446 </li>
 447 <li>R2:
 448 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,
 449 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
 450 </li>
 451 <li>R1:
 452 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
 453 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
 454 </li>
 455 </ul>
 456
 457 <h2>Defect Reports</h2>
 458 <hr>
 459 <h3><a name="1"></a>1. C library linkage editing oversight</h3>
 460 <p><b>Section:</b> 17.4.2.2 [using.linkage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
 461  <b>Submitter:</b> Beman Dawes <b>Date:</b> 1997-11-16</p>
 462 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
 463 <p><b>Discussion:</b></p>
 464 <p>The change specified in the proposed resolution below did not make
 465 it into the Standard. This change was accepted in principle at the
 466 London meeting, and the exact wording below was accepted at the
 467 Morristown meeting.</p>
 468
 469
 470 <p><b>Proposed resolution:</b></p>
 471 <p>Change 17.4.2.2 [using.linkage] paragraph 2
 472 from:</p>
 473
 474 <blockquote>
 475   <p>It is unspecified whether a name from the Standard C library
 476   declared with external linkage has either extern "C" or
 477   extern "C++" linkage.</p>
 478 </blockquote>
 479
 480 <p>to:</p>
 481
 482 <blockquote>
 483   <p>Whether a name from the Standard C library declared with external
 484   linkage has extern "C" or extern "C++" linkage
 485   is implementation defined. It is recommended that an implementation
 486   use extern "C++" linkage for this purpose.</p>
 487 </blockquote>
 488
 489
 490
 491
 492
 493 <hr>
 494 <h3><a name="3"></a>3. Atexit registration during atexit() call is not described</h3>
 495 <p><b>Section:</b> 18.4 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
 496  <b>Submitter:</b> Steve Clamage <b>Date:</b> 1997-12-12</p>
 497 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
 498 <p><b>Discussion:</b></p>
 499 <p>We appear not to have covered all the possibilities of
 500  exit processing with respect to
 501 atexit registration. <br>
 502 <br>
 503 Example 1: (C and C++)</p>
 504
 505 <pre>    #include &lt;stdlib.h&gt;
 506     void f1() { }
 507     void f2() { atexit(f1); }
 508
 509     int main()
 510     {
 511         atexit(f2); // the only use of f2
 512         return 0; // for C compatibility
 513     }</pre>
 514
 515 <p>At program exit, f2 gets called due to its registration in
 516 main. Running f2 causes f1 to be newly registered during the exit
 517 processing. Is this a valid program? If so, what are its
 518 semantics?</p>
 519
 520 <p>
 521 Interestingly, neither the C standard, nor the C++ draft standard nor
 522 the forthcoming C9X Committee Draft says directly whether you can
 523 register a function with atexit during exit processing.</p>
 524
 525 <p>
 526 All 3 standards say that functions are run in reverse order of their
 527 registration. Since f1 is registered last, it ought to be run first,
 528 but by the time it is registered, it is too late to be first.</p>
 529
 530 <p>If the program is valid, the standards are self-contradictory about
 531 its semantics.</p>
 532
 533 <p>Example 2: (C++ only)</p>
 534
 535 <pre>
 536     void F() { static T t; } // type T has a destructor
 537
 538     int main()
 539     {
 540         atexit(F); // the only use of F
 541     }
 542 </pre>
 543
 544 <p>Function F registered with atexit has a local static variable t,
 545 and F is called for the first time during exit processing. A local
 546 static object is initialized the first time control flow passes
 547 through its definition, and all static objects are destroyed during
 548 exit processing. Is the code valid? If so, what are its semantics?</p>
 549
 550 <p>
 551 Section 18.3 "Start and termination" says that if a function
 552 F is registered with atexit before a static object t is initialized, F
 553 will not be called until after t's destructor completes.</p>
 554
 555 <p>
 556 In example 2, function F is registered with atexit before its local
 557 static object O could possibly be initialized. On that basis, it must
 558 not be called by exit processing until after O's destructor
 559 completes. But the destructor cannot be run until after F is called,
 560 since otherwise the object could not be constructed in the first
 561 place.</p>
 562
 563 <p>If the program is valid, the standard is self-contradictory about
 564 its semantics.</p>
 565
 566 <p>I plan to submit Example 1 as a public comment on the C9X CD, with
 567 a recommendation that the results be undefined. (Alternative: make it
 568 unspecified. I don't think it is worthwhile to specify the case where
 569 f1 itself registers additional functions, each of which registers
 570 still more functions.)</p>
 571
 572 <p>I think we should resolve the situation in the whatever way the C
 573 committee decides. </p>
 574
 575 <p>For Example 2, I recommend we declare the results undefined.</p>
 576
 577 <p><i>[See reflector message lib-6500 for further discussion.]</i></p>
 578
 579
 580
 581
 582 <p><b>Proposed resolution:</b></p>
 583 <p>Change section 18.3/8 from:</p>
 584 <blockquote><p>
 585   First, objects with static storage duration are destroyed and
 586   functions registered by calling atexit are called. Objects with
 587   static storage duration are destroyed in the reverse order of the
 588   completion of their constructor.  (Automatic objects are not
 589   destroyed as a result of calling exit().) Functions registered with
 590   atexit are called in the reverse order of their registration.  A
 591   function registered with atexit before an object obj1 of static
 592   storage duration is initialized will not be called until obj1's
 593   destruction has completed. A function registered with atexit after
 594   an object obj2 of static storage duration is initialized will be
 595   called before obj2's destruction starts.
 596 </p></blockquote>
 597 <p>to:</p>
 598 <blockquote><p>
 599   First, objects with static storage duration are destroyed and
 600   functions registered by calling atexit are called. Non-local objects
 601   with static storage duration are destroyed in the reverse order of
 602   the completion of their constructor. (Automatic objects are not
 603   destroyed as a result of calling exit().) Functions registered with
 604   atexit are called in the reverse order of their registration, except
 605   that a function is called after any previously registered functions
 606   that had already been called at the time it was registered. A
 607   function registered with atexit before a non-local object obj1 of
 608   static storage duration is initialized will not be called until
 609   obj1's destruction has completed. A function registered with atexit
 610   after a non-local object obj2 of static storage duration is
 611   initialized will be called before obj2's destruction starts. A local
 612   static object obj3 is destroyed at the same time it would be if a
 613   function calling the obj3 destructor were registered with atexit at
 614   the completion of the obj3 constructor.
 615 </p></blockquote>
 616
 617
 618 <p><b>Rationale:</b></p>
 619 <p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
 620 supporting to the proposed resolution.</p>
 621
 622
 623
 624
 625
 626 <hr>
 627 <h3><a name="5"></a>5. String::compare specification questionable</h3>
 628 <p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
 629  <b>Submitter:</b> Jack Reeves <b>Date:</b> 1997-12-11</p>
 630 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p>
 631 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
 632 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#87">87</a></p>
 633 <p><b>Discussion:</b></p>
 634 <p>At the very end of the basic_string class definition is the signature: int
 635 compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
 636 following text this is defined as: returns
 637 basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
 638 basic_string&lt;charT,traits,Allocator&gt;(s,n2); </p>
 639
 640 <p>Since the constructor basic_string(const charT* s, size_type n, const Allocator&amp; a
 641 = Allocator()) clearly requires that s != NULL and n &lt; npos and further states that it
 642 throws length_error if n == npos, it appears the compare() signature above should always
 643 throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
 644 null terminated character array. </p>
 645
 646 <p>This appears to be a typo since the obvious intent is to allow either the call above or
 647 something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
 648
 649 <p>This would imply that what was really intended was two signatures int compare(size_type
 650 pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
 651 charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
 652
 653
 654 <p><b>Proposed resolution:</b></p>
 655 <p>Replace the compare signature in 21.3 [basic.string]
 656 (at the very end of the basic_string synopsis) which reads:</p>
 657
 658 <blockquote>
 659   <p><tt>int compare(size_type pos1, size_type n1,<br>
 660   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
 661   size_type n2 = npos) const;</tt></p>
 662 </blockquote>
 663
 664 <p>with:</p>
 665
 666 <blockquote>
 667   <p><tt>int compare(size_type pos1, size_type n1,<br>
 668   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s) const;<br>
 669   int compare(size_type pos1, size_type n1,<br>
 670   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
 671   size_type n2) const;</tt></p>
 672 </blockquote>
 673
 674 <p>Replace the portion of 21.3.6.8 [string::swap]
 675 paragraphs 5 and 6 which read:</p>
 676
 677 <blockquote>
 678   <p><tt>int compare(size_type pos, size_type n1,<br>
 679   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; charT * s, size_type n2
 680   = npos) const;<br>
 681   </tt>Returns:<tt><br>
 682   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 683   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 684   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
 685 </blockquote>
 686
 687 <p>with:</p>
 688
 689 <blockquote>
 690   <p><tt>int compare(size_type pos, size_type n1,<br>
 691   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s) const;<br>
 692   </tt>Returns:<tt><br>
 693   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 694   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 695   basic_string&lt;charT,traits,Allocator&gt;( s ))<br>
 696   <br>
 697   int compare(size_type pos, size_type n1,<br>
 698   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s,
 699   size_type n2) const;<br>
 700   </tt>Returns:<tt><br>
 701   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 702   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 703   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
 704 </blockquote>
 705
 706 <p>Editors please note that in addition to splitting the signature, the third argument
 707 becomes const, matching the existing synopsis.</p>
 708
 709
 710 <p><b>Rationale:</b></p>
 711 <p>While the LWG dislikes adding signatures, this is a clear defect in
 712 the Standard which must be fixed.&nbsp; The same problem was also
 713 identified in issues 7 (item 5) and 87.</p>
 714
 715
 716
 717
 718
 719 <hr>
 720 <h3><a name="7"></a>7. String clause minor problems</h3>
 721 <p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
 722  <b>Submitter:</b> Matt Austern <b>Date:</b> 1997-12-15</p>
 723 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#strings">issues</a> in [strings].</p>
 724 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
 725 <p><b>Discussion:</b></p>
 726 <p>(1) In 21.3.6.4 [string::insert], the description of template
 727 &lt;class InputIterator&gt; insert(iterator, InputIterator,
 728 InputIterator) makes no sense. It refers to a member function that
 729 doesn't exist. It also talks about the return value of a void
 730 function. </p>
 731
 732 <p>(2) Several versions of basic_string::replace don't appear in the
 733 class synopsis. </p>
 734
 735 <p>(3) basic_string::push_back appears in the synopsis, but is never
 736 described elsewhere.  In the synopsis its argument is const charT,
 737 which doesn't makes much sense; it should probably be charT, or
 738 possible const charT&amp;. </p>
 739
 740 <p>(4) basic_string::pop_back is missing. </p>
 741
 742 <p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
 743 = npos) make no sense. First, it's const charT* in the synopsis and
 744 charT* in the description. Second, given what it says in RETURNS,
 745 leaving out the final argument will always result in an exception
 746 getting thrown. This is paragraphs 5 and 6 of
 747 21.3.6.8 [string::swap]</p>
 748
 749 <p>(6) In table 37, in section 21.1.1 [char.traits.require],
 750 there's a note for X::move(s, p, n). It says "Copies correctly
 751 even where p is in [s, s+n)". This is correct as far as it goes,
 752 but it doesn't go far enough; it should also guarantee that the copy
 753 is correct even where s in in [p, p+n). These are two orthogonal
 754 guarantees, and neither one follows from the other. Both guarantees
 755 are necessary if X::move is supposed to have the same sort of
 756 semantics as memmove (which was clearly the intent), and both
 757 guarantees are necessary if X::move is actually supposed to be
 758 useful. </p>
 759
 760
 761 <p><b>Proposed resolution:</b></p>
 762 <p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
 763 <br>
 764 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
 765 <br>
 766 ITEM 2:&nbsp; Not a defect; the Standard is clear.. There are ten versions of replace() in
 767 the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
 768 <br>
 769 ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
 770 [lib.basic.string]) from:</p>
 771
 772 <p>&nbsp;&nbsp;&nbsp;&nbsp; void push_back(const charT)<br>
 773 <br>
 774 to<br>
 775 <br>
 776 &nbsp;&nbsp;&nbsp;&nbsp; void push_back(charT)<br>
 777 <br>
 778 Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
 779 <br>
 780 &nbsp;&nbsp;&nbsp; void basic_string::push_back(charT c);<br>
 781 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to append(static_cast&lt;size_type&gt;(1), c);<br>
 782 <br>
 783 ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
 784 <br>
 785 ITEM 5: Duplicate; see issue 5 (and 87).<br>
 786 <br>
 787 ITEM 6: In table 37, Replace:<br>
 788 <br>
 789 &nbsp;&nbsp;&nbsp; "Copies correctly even where p is in [s, s+n)."<br>
 790 <br>
 791 with:<br>
 792 <br>
 793 &nbsp;&nbsp;&nbsp;&nbsp; "Copies correctly even where the ranges [p, p+n) and [s,
 794 s+n) overlap."</p>
 795
 796
 797
 798
 799
 800 <hr>
 801 <h3><a name="8"></a>8. Locale::global lacks guarantee</h3>
 802 <p><b>Section:</b> 22.1.1.5 [locale.statics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
 803  <b>Submitter:</b> Matt Austern <b>Date:</b> 1997-12-24</p>
 804 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
 805 <p><b>Discussion:</b></p>
 806 <p>It appears there's an important guarantee missing from clause
 807 22. We're told that invoking locale::global(L) sets the C locale if L
 808 has a name. However, we're not told whether or not invoking
 809 setlocale(s) sets the global C++ locale. </p>
 810
 811 <p>The intent, I think, is that it should not, but I can't find any
 812 such words anywhere. </p>
 813
 814
 815 <p><b>Proposed resolution:</b></p>
 816 <p>Add a sentence at the end of 22.1.1.5 [locale.statics],
 817 paragraph 2:&nbsp; </p>
 818
 819 <blockquote>
 820   <p>No library function other than <tt>locale::global()</tt> shall affect
 821   the value returned by <tt>locale()</tt>. </p>
 822
 823 </blockquote>
 824
 825
 826
 827
 828
 829 <hr>
 830 <h3><a name="9"></a>9. Operator new(0) calls should not yield the same pointer</h3>
 831 <p><b>Section:</b> 18.5.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
 832  <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-01-04</p>
 833 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
 834 <p><b>Discussion:</b></p>
 835 <p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
 836 section 3.7.3.1 of CD2 seems to allow for the possibility that all
 837 calls to operator new(0) yield the same pointer, an implementation
 838 technique specifically prohibited by ARM 5.3.3.Was this prohibition
 839 really lifted? Does the FDIS agree with CD2 in the regard? [Issues
 840 list maintainer's note: the IS is the same.]</p>
 841
 842
 843 <p><b>Proposed resolution:</b></p>
 844 <p>Change the last paragraph of 3.7.3 from:</p>
 845 <blockquote>
 846   <p>Any allocation and/or deallocation functions defined in a C++ program shall
 847   conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
 848 </blockquote>
 849 <p>to:</p>
 850 <blockquote>
 851   <p>Any allocation and/or deallocation functions defined in a C++ program,
 852   including the default versions in the library, shall conform to the semantics
 853   specified in 3.7.3.1 and 3.7.3.2.</p>
 854 </blockquote>
 855 <p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
 856 <blockquote>
 857   <p>If the size of the space requested is zero, the value returned shall not be
 858   a null pointer value (4.10).</p>
 859 </blockquote>
 860 <p>to:</p>
 861 <blockquote>
 862   <p>Even if the size of the space requested is zero, the request can fail. If
 863   the request succeeds, the value returned shall be a non-null pointer value
 864   (4.10) p0 different from any previously returned value p1, unless that value
 865   p1 was since passed to an operator delete.</p>
 866 </blockquote>
 867 <p>5.3.4/7 currently reads:</p>
 868 <blockquote>
 869   <p>When the value of the expression in a direct-new-declarator is zero, the
 870   allocation function is called to allocate an array with no elements. The
 871   pointer returned by the new-expression is non-null. [Note: If the library
 872   allocation function is called, the pointer returned is distinct from the
 873   pointer to any other object.]</p>
 874 </blockquote>
 875 <p>Retain the first sentence, and delete the remainder.</p>
 876 <p>18.5.1 currently has no text. Add the following:</p>
 877 <blockquote>
 878   <p>Except where otherwise specified, the provisions of 3.7.3 apply to the
 879   library versions of operator new and operator delete.</p>
 880 </blockquote>
 881 <p>To 18.5.1.3, add the following text:</p>
 882 <blockquote>
 883   <p>The provisions of 3.7.3 do not apply to these reserved placement forms of
 884   operator new and operator delete.</p>
 885 </blockquote>
 886
 887
 888 <p><b>Rationale:</b></p>
 889 <p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
 890 supporting to the proposed resolution.</p>
 891
 892
 893
 894
 895
 896 <hr>
 897 <h3><a name="11"></a>11. Bitset minor problems</h3>
 898 <p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
 899  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-22</p>
 900 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
 901 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
 902 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
 903 <p><b>Discussion:</b></p>
 904 <p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is
 905 not documented in 23.3.5.2. </p>
 906
 907 <p>(2) The class synopsis only gives a single signature for bitset&lt;&gt;::operator[],
 908 reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
 909 on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
 910
 911 <p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
 912 trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
 913 go in the Effects clause.</p>
 914
 915
 916 <p><b>Proposed resolution:</b></p>
 917 <p>ITEMS 1 AND 2:<br>
 918 <br>
 919 In the bitset synopsis (23.3.5 [template.bitset]),
 920 replace the member function <br>
 921 <br>
 922 <tt>&nbsp;&nbsp;&nbsp; reference operator[](size_t pos);<br>
 923 </tt><br>
 924 with the two member functions<br>
 925 <br>
 926 <tt>&nbsp;&nbsp;&nbsp; bool operator[](size_t pos) const; <br>
 927 &nbsp;&nbsp;&nbsp; reference operator[](size_t pos); <br>
 928 </tt><br>
 929 Add the following text at the end of 23.3.5.2 [bitset.members],
 930 immediately after paragraph 45:</p>
 931
 932 <blockquote>
 933   <p><tt>bool operator[](size_t pos) const;</tt><br>
 934   Requires: pos is valid<br>
 935   Throws: nothing<br>
 936   Returns: <tt>test(pos)</tt><br>
 937   <br>
 938   <tt>bitset&lt;N&gt;::reference operator[](size_t pos);</tt> <br>
 939   Requires: pos is valid<br>
 940   Throws: nothing<br>
 941   Returns: An object of type <tt>bitset&lt;N&gt;::reference</tt> such that <tt>(*this)[pos]
 942   == this-&gt;test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this-&gt;set(pos,
 943   val);</tt></p>
 944 </blockquote>
 945
 946
 947 <p><b>Rationale:</b></p>
 948 <p>The LWG believes Item 3 is not a defect. "Formatted
 949 input" implies the desired semantics. See 27.6.1.2 [istream.formatted].
 950 </p>
 951
 952
 953
 954
 955
 956 <hr>
 957 <h3><a name="13"></a>13. Eos refuses to die</h3>
 958 <p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
 959  <b>Submitter:</b> William M. Miller <b>Date:</b> 1998-03-03</p>
 960 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
 961 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
 962 <p><b>Discussion:</b></p>
 963 <p>In 27.6.1.2.3, there is a reference to "eos", which is
 964 the only one in the whole draft (at least using Acrobat search), so
 965 it's undefined. </p>
 966
 967
 968 <p><b>Proposed resolution:</b></p>
 969 <p>In 27.6.1.2.3 [istream::extractors], replace "eos" with
 970 "charT()"</p>
 971
 972
 973
 974
 975
 976 <hr>
 977 <h3><a name="14"></a>14. Locale::combine should be const</h3>
 978 <p><b>Section:</b> 22.1.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
 979  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
 980 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.members">issues</a> in [locale.members].</p>
 981 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
 982 <p><b>Discussion:</b></p>
 983 <p>locale::combine is the only member function of locale (other than constructors and
 984 destructor) that is not const. There is no reason for it not to be const, and good reasons
 985 why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
 986 paragraph 6: "An instance of a locale is immutable." </p>
 987
 988 <p>History: this member function originally was a constructor. it happened that the
 989 interface it specified had no corresponding language syntax, so it was changed to a member
 990 function. As constructors are never const, there was no "const" in the interface
 991 which was transformed into member "combine". It should have been added at that
 992 time, but the omission was not noticed. </p>
 993
 994
 995 <p><b>Proposed resolution:</b></p>
 996 <p>In 22.1.1 [locale] and also in 22.1.1.3 [locale.members], add
 997 "const" to the declaration of member combine: </p>
 998 <blockquote>
 999   <pre>template &lt;class Facet&gt; locale combine(const locale&amp; other) const; </pre>
1000 </blockquote>
1001
1002
1003
1004
1005
1006 <hr>
1007 <h3><a name="15"></a>15. Locale::name requirement inconsistent</h3>
1008 <p><b>Section:</b> 22.1.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1009  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1010 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.members">issues</a> in [locale.members].</p>
1011 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1012 <p><b>Discussion:</b></p>
1013 <p>locale::name() is described as returning a string that can be passed to a locale
1014 constructor, but there is no matching constructor. </p>
1015
1016
1017 <p><b>Proposed resolution:</b></p>
1018 <p>In 22.1.1.3 [locale.members], paragraph 5, replace
1019 "<tt>locale(name())</tt>" with
1020 "<tt>locale(name().c_str())</tt>".
1021 </p>
1022
1023
1024
1025
1026
1027 <hr>
1028 <h3><a name="16"></a>16. Bad ctype_byname&lt;char&gt; decl</h3>
1029 <p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1030  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1031 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
1032 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1033 <p><b>Discussion:</b></p>
1034 <p>The new virtual members ctype_byname&lt;char&gt;::do_widen and do_narrow did not get
1035 edited in properly. Instead, the member do_widen appears four times, with wrong argument
1036 lists. </p>
1037
1038
1039 <p><b>Proposed resolution:</b></p>
1040 <p>The correct declarations for the overloaded members
1041 <tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
1042 from 22.2.1.3 [facet.ctype.special].</p>
1043
1044
1045
1046
1047
1048 <hr>
1049 <h3><a name="17"></a>17. Bad bool parsing</h3>
1050 <p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1051  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1052 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
1053 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
1054 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1055 <p><b>Discussion:</b></p>
1056 <p>This section describes the process of parsing a text boolean value from the input
1057 stream. It does not say it recognizes either of the sequences "true" or
1058 "false" and returns the corresponding bool value; instead, it says it recognizes
1059 only one of those sequences, and chooses which according to the received value of a
1060 reference argument intended for returning the result, and reports an error if the other
1061 sequence is found. (!) Furthermore, it claims to get the names from the ctype&lt;&gt;
1062 facet rather than the numpunct&lt;&gt; facet, and it examines the "boolalpha"
1063 flag wrongly; it doesn't define the value "loc"; and finally, it computes
1064 wrongly whether to use numeric or "alpha" parsing.<br>
1065 <br>
1066 I believe the correct algorithm is "as if": </p>
1067
1068 <pre>  // in, err, val, and str are arguments.
1069   err = 0;
1070   const numpunct&lt;charT&gt;&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(str.getloc());
1071   const string_type t = np.truename(), f = np.falsename();
1072   bool tm = true, fm = true;
1073   size_t pos = 0;
1074   while (tm &amp;&amp; pos &lt; t.size() || fm &amp;&amp; pos &lt; f.size()) {
1075     if (in == end) { err = str.eofbit; }
1076     bool matched = false;
1077     if (tm &amp;&amp; pos &lt; t.size()) {
1078       if (!err &amp;&amp; t[pos] == *in) matched = true;
1079       else tm = false;
1080     }
1081     if (fm &amp;&amp; pos &lt; f.size()) {
1082       if (!err &amp;&amp; f[pos] == *in) matched = true;
1083       else fm = false;
1084     }
1085     if (matched) { ++in; ++pos; }
1086     if (pos &gt; t.size()) tm = false;
1087     if (pos &gt; f.size()) fm = false;
1088   }
1089   if (tm == fm || pos == 0) { err |= str.failbit; }
1090   else                      { val = tm; }
1091   return in;</pre>
1092
1093 <p>Notice this works reasonably when the candidate strings are both empty, or equal, or
1094 when one is a substring of the other. The proposed text below captures the logic of the
1095 code above.</p>
1096
1097
1098 <p><b>Proposed resolution:</b></p>
1099 <p>In 22.2.2.1.2 [facet.num.get.virtuals], in the first line of paragraph 14,
1100 change "&amp;&amp;" to "&amp;".</p>
1101
1102 <p>Then, replace paragraphs 15 and 16 as follows:</p>
1103
1104 <blockquote>
1105
1106   <p>Otherwise target sequences are determined "as if" by
1107   calling the members <tt>falsename()</tt> and
1108   <tt>truename()</tt> of the facet obtained by
1109   <tt>use_facet&lt;numpunct&lt;charT&gt;&nbsp;&gt;(str.getloc())</tt>.
1110   Successive characters in the range <tt>[in,end)</tt> (see
1111   [lib.sequence.reqmts]) are obtained and matched against
1112   corresponding positions in the target sequences only as necessary to
1113   identify a unique match. The input iterator <tt>in</tt> is
1114   compared to <tt>end</tt> only when necessary to obtain a
1115   character. If and only if a target sequence is uniquely matched,
1116   <tt>val</tt> is set to the corresponding value.</p>
1117
1118 </blockquote>
1119
1120 <blockquote>
1121   <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
1122   successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
1123   <tt>str.eofbit</tt> if, when seeking another character to match, it is found that
1124   <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
1125   <tt>(str.failbit|str.eofbit)</tt>if
1126   the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
1127   <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
1128   <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
1129   <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
1130   <tt>true</tt>:"1"
1131   and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
1132   and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
1133   <tt>err==str.failbit</tt>. --end example]</p>
1134 </blockquote>
1135
1136
1137
1138
1139
1140 <hr>
1141 <h3><a name="18"></a>18. Get(...bool&amp;) omitted</h3>
1142 <p><b>Section:</b> 22.2.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1143  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1144 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.members">issues</a> in [facet.num.get.members].</p>
1145 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1146 <p><b>Discussion:</b></p>
1147 <p>In the list of num_get&lt;&gt; non-virtual members on page 22-23, the member
1148 that parses bool values was omitted from the list of definitions of non-virtual
1149 members, though it is listed in the class definition and the corresponding
1150 virtual is listed everywhere appropriate. </p>
1151
1152
1153 <p><b>Proposed resolution:</b></p>
1154 <p>Add at the beginning of 22.2.2.1.1 [facet.num.get.members]
1155 another get member for bool&amp;, copied from the entry in
1156 22.2.2.1 [locale.num.get].</p>
1157
1158
1159
1160
1161
1162 <hr>
1163 <h3><a name="19"></a>19. "Noconv" definition too vague</h3>
1164 <p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1165  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1166 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
1167 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1168 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#10">10</a></p>
1169 <p><b>Discussion:</b></p>
1170 <p>
1171 In the definitions of codecvt&lt;&gt;::do_out and do_in, they are
1172 specified to return noconv if "no conversion is
1173 needed". This definition is too vague, and does not say
1174 normatively what is done with the buffers.
1175 </p>
1176
1177
1178 <p><b>Proposed resolution:</b></p>
1179 <p>
1180 Change the entry for noconv in the table under paragraph 4 in section
1181 22.2.1.4.2 [locale.codecvt.virtuals] to read:
1182 </p>
1183 <blockquote>
1184   <p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
1185   and input sequence is identical to converted sequence.</p>
1186 </blockquote>
1187 <p>Change the Note in paragraph 2 to normative text as follows:</p>
1188 <blockquote>
1189   <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
1190   same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
1191   <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
1192   unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
1193 </blockquote>
1194
1195
1196
1197
1198
1199 <hr>
1200 <h3><a name="20"></a>20. Thousands_sep returns wrong type</h3>
1201 <p><b>Section:</b> 22.2.3.1.2 [facet.numpunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1202  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1203 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1204 <p><b>Discussion:</b></p>
1205 <p>The synopsis for numpunct&lt;&gt;::do_thousands_sep, and the
1206 definition of numpunct&lt;&gt;::thousands_sep which calls it, specify
1207 that it returns a value of type char_type. Here it is erroneously
1208 described as returning a "string_type". </p>
1209
1210
1211 <p><b>Proposed resolution:</b></p>
1212 <p>In 22.2.3.1.2 [facet.numpunct.virtuals], above paragraph 2, change
1213 "string_type" to "char_type". </p>
1214
1215
1216
1217
1218
1219 <hr>
1220 <h3><a name="21"></a>21. Codecvt_byname&lt;&gt; instantiations</h3>
1221 <p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1222  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1223 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
1224 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1225 <p><b>Discussion:</b></p>
1226 <p>In the second table in the section, captioned "Required
1227 instantiations", the instantiations for codecvt_byname&lt;&gt;
1228 have been omitted. These are necessary to allow users to construct a
1229 locale by name from facets. </p>
1230
1231
1232 <p><b>Proposed resolution:</b></p>
1233 <p>Add in 22.1.1.1.1 [locale.category] to the table captioned
1234 "Required instantiations", in the category "ctype"
1235 the lines </p>
1236
1237 <blockquote>
1238   <pre>codecvt_byname&lt;char,char,mbstate_t&gt;,
1239 codecvt_byname&lt;wchar_t,char,mbstate_t&gt; </pre>
1240 </blockquote>
1241
1242
1243
1244
1245
1246 <hr>
1247 <h3><a name="22"></a>22. Member open vs. flags</h3>
1248 <p><b>Section:</b> 27.8.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1249  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1250 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
1251 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1252 <p><b>Discussion:</b></p>
1253 <p>The description of basic_istream&lt;&gt;::open leaves unanswered questions about how it
1254 responds to or changes flags in the error status for the stream. A strict reading
1255 indicates that it ignores the bits and does not change them, which confuses users who do
1256 not expect eofbit and failbit to remain set after a successful open. There are three
1257 reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
1258 and eofbit on call to open(). </p>
1259
1260
1261 <p><b>Proposed resolution:</b></p>
1262 <p>In 27.8.1.9 [ifstream.members] paragraph 3, <i>and</i> in 27.8.1.13 [ofstream.members] paragraph 3, under open() effects, add a footnote:
1263 </p>
1264
1265 <blockquote>
1266   <p>A successful open does not change the error state.</p>
1267 </blockquote>
1268
1269
1270 <p><b>Rationale:</b></p>
1271 <p>This may seem surprising to some users, but it's just an instance
1272 of a general rule: error flags are never cleared by the
1273 implementation. The only way error flags are are ever cleared is if
1274 the user explicitly clears them by hand.</p>
1275
1276 <p>The LWG believed that preserving this general rule was
1277 important enough so that an exception shouldn't be made just for this
1278 one case.  The resolution of this issue clarifies what the LWG
1279 believes to have been the original intent.</p>
1280
1281
1282
1283
1284
1285
1286 <hr>
1287 <h3><a name="24"></a>24. "do_convert" doesn't exist</h3>
1288 <p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1289  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1290 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
1291 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1292 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#72">72</a></p>
1293 <p><b>Discussion:</b></p>
1294 <p>The description of codecvt&lt;&gt;::do_out and do_in mentions a
1295 symbol "do_convert" which is not defined in the
1296 standard. This is a leftover from an edit, and should be "do_in
1297 and do_out". </p>
1298
1299
1300 <p><b>Proposed resolution:</b></p>
1301 <p>In 22.2.1.4 [locale.codecvt], paragraph 3, change
1302 "do_convert" to "do_in or do_out". Also, in 22.2.1.4.2 [locale.codecvt.virtuals], change "do_convert()" to "do_in
1303 or do_out". </p>
1304
1305
1306
1307
1308
1309 <hr>
1310 <h3><a name="25"></a>25. String operator&lt;&lt; uses width() value wrong</h3>
1311 <p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1312  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1313 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
1314 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1315 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#67">67</a></p>
1316 <p><b>Discussion:</b></p>
1317 <p>In the description of operator&lt;&lt; applied to strings, the standard says that uses
1318 the smaller of os.width() and str.size(), to pad "as described in stage 3"
1319 elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
1320
1321
1322 <p><b>Proposed resolution:</b></p>
1323 <p>Change 21.3.8.9 [string.io]  paragraph 4 from:<br>
1324 <br>
1325 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
1326 ..."<br>
1327 <br>
1328 to: <br>
1329 <br>
1330 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
1331 ..."</p>
1332
1333
1334
1335
1336
1337 <hr>
1338 <h3><a name="26"></a>26. Bad sentry example</h3>
1339 <p><b>Section:</b> 27.6.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1340  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1341 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
1342 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1343 <p><b>Discussion:</b></p>
1344 <p>In paragraph 6, the code in the example: </p>
1345
1346 <pre>  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
1347   basic_istream&lt;charT,traits&gt;::sentry(
1348            basic_istream&lt;charT,traits&gt;&amp; is, bool noskipws = false) {
1349       ...
1350       int_type c;
1351       typedef ctype&lt;charT&gt; ctype_type;
1352       const ctype_type&amp; ctype = use_facet&lt;ctype_type&gt;(is.getloc());
1353       while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
1354         if (ctype.is(ctype.space,c)==0) {
1355           is.rdbuf()-&gt;sputbackc (c);
1356           break;
1357         }
1358       }
1359       ...
1360    }</pre>
1361
1362 <p>fails to demonstrate correct use of the facilities described. In
1363 particular, it fails to use traits operators, and specifies incorrect
1364 semantics. (E.g. it specifies skipping over the first character in the
1365 sequence without examining it.) </p>
1366
1367
1368 <p><b>Proposed resolution:</b></p>
1369 <p>Remove the example above from 27.6.1.1.3 [istream::sentry]
1370 paragraph 6.</p>
1371
1372
1373 <p><b>Rationale:</b></p>
1374 <p>The originally proposed replacement code for the example was not
1375 correct. The LWG tried in Kona and again in Tokyo to correct it
1376 without success. In Tokyo, an implementor reported that actual working
1377 code ran over one page in length and was quite complicated. The LWG
1378 decided that it would be counter-productive to include such a lengthy
1379 example, which might well still contain errors.</p>
1380
1381
1382
1383
1384
1385 <hr>
1386 <h3><a name="27"></a>27. String::erase(range) yields wrong iterator</h3>
1387 <p><b>Section:</b> 21.3.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1388  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1389 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::erase">issues</a> in [string::erase].</p>
1390 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1391 <p><b>Discussion:</b></p>
1392 <p>The string::erase(iterator first, iterator last) is specified to return an element one
1393 place beyond the next element after the last one erased. E.g. for the string
1394 "abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
1395 while 'd' has not been erased. </p>
1396
1397
1398 <p><b>Proposed resolution:</b></p>
1399 <p>In 21.3.6.5 [string::erase], paragraph 10, change: </p>
1400
1401 <blockquote>
1402   <p>Returns: an iterator which points to the element immediately following _last_ prior to
1403   the element being erased. </p>
1404 </blockquote>
1405
1406 <p>to read </p>
1407
1408 <blockquote>
1409   <p>Returns: an iterator which points to the element pointed to by _last_ prior to the
1410   other elements being erased. </p>
1411 </blockquote>
1412
1413
1414
1415
1416
1417 <hr>
1418 <h3><a name="28"></a>28. Ctype&lt;char&gt;is ambiguous</h3>
1419 <p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1420  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1421 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p>
1422 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1423 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#236">236</a></p>
1424 <p><b>Discussion:</b></p>
1425 <p>The description of the vector form of ctype&lt;char&gt;::is can be interpreted to mean
1426 something very different from what was intended. Paragraph 4 says </p>
1427
1428 <blockquote>
1429   <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
1430   table()[(unsigned char)*p]. </p>
1431 </blockquote>
1432
1433 <p>This is intended to copy the value indexed from table()[] into the place identified in
1434 vec[]. </p>
1435
1436
1437 <p><b>Proposed resolution:</b></p>
1438 <p>Change 22.2.1.3.2 [facet.ctype.char.members], paragraph 4, to read </p>
1439
1440 <blockquote>
1441   <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
1442   the value table()[(unsigned char)*p]. </p>
1443 </blockquote>
1444
1445
1446
1447
1448
1449 <hr>
1450 <h3><a name="29"></a>29. Ios_base::init doesn't exist</h3>
1451 <p><b>Section:</b> 27.3.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1452  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1453 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#narrow.stream.objects">issues</a> in [narrow.stream.objects].</p>
1454 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1455 <p><b>Discussion:</b></p>
1456 <p>Sections 27.3.1 [narrow.stream.objects] and 27.3.2 [wide.stream.objects] mention
1457 a function ios_base::init, which is not defined. Probably they mean
1458 basic_ios&lt;&gt;::init, defined in 27.4.4.1 [basic.ios.cons],
1459 paragraph 3. </p>
1460
1461
1462 <p><b>Proposed resolution:</b></p>
1463 <p>[R12: modified to include paragraph 5.]</p>
1464
1465 <p>In 27.3.1 [narrow.stream.objects] paragraph 2 and 5, change </p>
1466
1467 <blockquote>
1468   <p>ios_base::init </p>
1469 </blockquote>
1470
1471 <p>to </p>
1472
1473 <blockquote>
1474   <p>basic_ios&lt;char&gt;::init </p>
1475 </blockquote>
1476
1477 <p>Also, make a similar change in 27.3.2 [wide.stream.objects] except it
1478 should read </p>
1479
1480 <blockquote>
1481   <p>basic_ios&lt;wchar_t&gt;::init </p>
1482 </blockquote>
1483
1484
1485
1486
1487
1488 <hr>
1489 <h3><a name="30"></a>30. Wrong header for LC_*</h3>
1490 <p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1491  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1492 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
1493 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1494 <p><b>Discussion:</b></p>
1495 <p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in &lt;cctype&gt;,
1496 where they are in fact defined elsewhere to appear in &lt;clocale&gt;. </p>
1497
1498
1499 <p><b>Proposed resolution:</b></p>
1500 <p>In 22.1.1.1.1 [locale.category], paragraph 2, change
1501 "&lt;cctype&gt;" to read "&lt;clocale&gt;". </p>
1502
1503
1504
1505
1506
1507 <hr>
1508 <h3><a name="31"></a>31. Immutable locale values</h3>
1509 <p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1510  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1511 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
1512 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1513 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#378">378</a></p>
1514 <p><b>Discussion:</b></p>
1515 <p>Paragraph 6, says "An instance of <tt>locale</tt> is
1516 <i>immutable</i>; once a facet reference is obtained from it,
1517 ...". This has caused some confusion, because locale variables
1518 are manifestly assignable. </p>
1519
1520
1521 <p><b>Proposed resolution:</b></p>
1522 <p>In 22.1.1 [locale] replace paragraph 6</p>
1523
1524 <blockquote>
1525   <p>An instance of <tt>locale</tt> is immutable; once a facet
1526   reference is obtained from it, that reference remains usable as long
1527   as the locale value itself exists.</p>
1528 </blockquote>
1529
1530 <p>with</p>
1531
1532 <blockquote>
1533   <p>Once a facet reference is obtained from a locale object by
1534   calling use_facet&lt;&gt;, that reference remains usable, and the
1535   results from member functions of it may be cached and re-used, as
1536   long as some locale object refers to that facet.</p>
1537 </blockquote>
1538
1539
1540
1541
1542
1543 <hr>
1544 <h3><a name="32"></a>32. Pbackfail description inconsistent</h3>
1545 <p><b>Section:</b> 27.5.2.4.4 [streambuf.virt.pback] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1546  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1547 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1548 <p><b>Discussion:</b></p>
1549 <p>The description of the required state before calling virtual member
1550 basic_streambuf&lt;&gt;::pbackfail requirements is inconsistent with the conditions
1551 described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
1552 Specifically, the latter says it calls pbackfail if: </p>
1553
1554 <p>&nbsp;&nbsp;&nbsp; traits::eq(c,gptr()[-1]) is false </p>
1555
1556 <p>where pbackfail claims to require: </p>
1557
1558 <p>&nbsp;&nbsp;&nbsp; traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
1559
1560 <p>It appears that the pbackfail description is wrong. </p>
1561
1562
1563 <p><b>Proposed resolution:</b></p>
1564 <p>In 27.5.2.4.4 [streambuf.virt.pback], paragraph 1, change:</p>
1565
1566 <blockquote>
1567   <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
1568 </blockquote>
1569
1570 <p>to </p>
1571
1572 <blockquote>
1573   <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
1574   </p>
1575 </blockquote>
1576
1577
1578 <p><b>Rationale:</b></p>
1579 <p>Note deliberate reordering of arguments for clarity in addition to the correction of
1580 the argument value.</p>
1581
1582
1583
1584
1585
1586 <hr>
1587 <h3><a name="33"></a>33. Codecvt&lt;&gt; mentions from_type</h3>
1588 <p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1589  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1590 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
1591 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1592 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#43">43</a></p>
1593 <p><b>Discussion:</b></p>
1594 <p>In the table defining the results from do_out and do_in, the specification for the
1595 result <i>error</i> says </p>
1596
1597 <blockquote>
1598   <p>encountered a from_type character it could not convert </p>
1599 </blockquote>
1600
1601 <p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
1602 an internT for do_out. </p>
1603
1604
1605 <p><b>Proposed resolution:</b></p>
1606 <p>In 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 4, replace the definition
1607 in the table for the case of _error_ with </p>
1608
1609 <blockquote>
1610   <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
1611 </blockquote>
1612
1613
1614
1615
1616
1617 <hr>
1618 <h3><a name="34"></a>34. True/falsename() not in ctype&lt;&gt;</h3>
1619 <p><b>Section:</b> 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1620  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1621 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
1622 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1623 <p><b>Discussion:</b></p>
1624 <p>In paragraph 19, Effects:, members truename() and falsename are used from facet
1625 ctype&lt;charT&gt;, but it has no such members. Note that this is also a problem in
1626 22.2.2.1.2, addressed in (4). </p>
1627
1628
1629 <p><b>Proposed resolution:</b></p>
1630 <p>In 22.2.2.2.2 [facet.num.put.virtuals], paragraph 19, in the Effects:
1631 clause for member put(...., bool), replace the initialization of the
1632 string_type value s as follows: </p>
1633
1634 <blockquote>
1635   <pre>const numpunct&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(loc);
1636 string_type s = val ? np.truename() : np.falsename(); </pre>
1637 </blockquote>
1638
1639
1640
1641
1642
1643 <hr>
1644 <h3><a name="35"></a>35. No manipulator unitbuf in synopsis</h3>
1645 <p><b>Section:</b> 27.4 [iostreams.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1646  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1647 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1648 <p><b>Discussion:</b></p>
1649 <p>In 27.4.5.1 [fmtflags.manip], we have a definition for a manipulator
1650 named "unitbuf". Unlike other manipulators, it's not listed
1651 in synopsis. Similarly for "nounitbuf". </p>
1652
1653
1654 <p><b>Proposed resolution:</b></p>
1655 <p>Add to the synopsis for &lt;ios&gt; in 27.4 [iostreams.base], after
1656 the entry for "nouppercase", the prototypes: </p>
1657
1658 <blockquote>
1659   <pre>ios_base&amp; unitbuf(ios_base&amp; str);
1660 ios_base&amp; nounitbuf(ios_base&amp; str); </pre>
1661 </blockquote>
1662
1663
1664
1665
1666
1667 <hr>
1668 <h3><a name="36"></a>36. Iword &amp; pword storage lifetime omitted</h3>
1669 <p><b>Section:</b> 27.4.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1670  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1671 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.storage">issues</a> in [ios.base.storage].</p>
1672 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1673 <p><b>Discussion:</b></p>
1674 <p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
1675 specified badly, so that an implementation which only keeps the last value stored appears
1676 to conform. In particular, it says: </p>
1677
1678 <p>The reference returned may become invalid after another call to the object's iword
1679 member with a different index ... </p>
1680
1681 <p>This is not idle speculation; at least one implementation was done this way. </p>
1682
1683
1684 <p><b>Proposed resolution:</b></p>
1685 <p>Add in 27.4.2.5 [ios.base.storage], in both paragraph 2 and also in
1686 paragraph 4, replace the sentence: </p>
1687
1688 <blockquote>
1689   <p>The reference returned may become invalid after another call to the object's iword
1690   [pword] member with a different index, after a call to its copyfmt member, or when the
1691   object is destroyed. </p>
1692 </blockquote>
1693
1694 <p>with: </p>
1695
1696 <blockquote>
1697   <p>The reference returned is invalid after any other operations on the object. However,
1698   the value of the storage referred to is retained, so that until the next call to copyfmt,
1699   calling iword [pword] with the same index yields another reference to the same value. </p>
1700 </blockquote>
1701
1702 <p>substituting "iword" or "pword" as appropriate. </p>
1703
1704
1705
1706
1707
1708 <hr>
1709 <h3><a name="37"></a>37. Leftover "global" reference</h3>
1710 <p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1711  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1712 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
1713 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1714 <p><b>Discussion:</b></p>
1715 <p>In the overview of locale semantics, paragraph 4, is the sentence </p>
1716
1717 <blockquote>
1718   <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
1719   the standard exception bad_cast. </p>
1720 </blockquote>
1721
1722 <p>This is not supported by the definition of use_facet&lt;&gt;, and represents semantics
1723 from an old draft. </p>
1724
1725
1726 <p><b>Proposed resolution:</b></p>
1727 <p>In 22.1.1 [locale], paragraph 4, delete the parenthesized
1728 expression </p>
1729
1730 <blockquote>
1731   <p>(or, failing that, in the global locale) </p>
1732 </blockquote>
1733
1734
1735
1736
1737
1738 <hr>
1739 <h3><a name="38"></a>38. Facet definition incomplete</h3>
1740 <p><b>Section:</b> 22.1.2 [locale.global.templates] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1741  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1742 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1743 <p><b>Discussion:</b></p>
1744 <p>It has been noticed by Esa Pulkkinen that the definition of
1745 "facet" is incomplete. In particular, a class derived from
1746 another facet, but which does not define a member <i>id</i>, cannot
1747 safely serve as the argument <i>F</i> to use_facet&lt;F&gt;(loc),
1748 because there is no guarantee that a reference to the facet instance
1749 stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
1750
1751
1752 <p><b>Proposed resolution:</b></p>
1753 <p>In the definition of std::use_facet&lt;&gt;(), replace the text in paragraph 1 which
1754 reads: </p>
1755
1756 <blockquote>
1757   <p>Get a reference to a facet of a locale. </p>
1758 </blockquote>
1759
1760 <p>with: </p>
1761
1762 <blockquote>
1763   <p>Requires: <tt>Facet</tt> is a facet class whose definition
1764   contains the public static member <tt>id</tt> as defined in 22.1.1.1.2 [locale.facet]. </p>
1765 </blockquote>
1766
1767 <p><i>[
1768 Kona: strike as overspecification the text "(not inherits)"
1769 from the original resolution, which read "... whose definition
1770 contains (not inherits) the public static member
1771 <tt>id</tt>..."
1772 ]</i></p>
1773
1774
1775
1776
1777
1778
1779
1780 <hr>
1781 <h3><a name="39"></a>39. istreambuf_iterator&lt;&gt;::operator++(int) definition garbled</h3>
1782 <p><b>Section:</b> 24.5.3.4 [istreambuf.iterator::op++] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1783  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1784 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1785 <p><b>Discussion:</b></p>
1786 <p>Following the definition of istreambuf_iterator&lt;&gt;::operator++(int) in paragraph
1787 3, the standard contains three lines of garbage text left over from a previous edit. </p>
1788
1789 <blockquote>
1790   <pre>istreambuf_iterator&lt;charT,traits&gt; tmp = *this;
1791 sbuf_-&gt;sbumpc();
1792 return(tmp); </pre>
1793 </blockquote>
1794
1795
1796 <p><b>Proposed resolution:</b></p>
1797 <p>In 24.5.3.4 [istreambuf.iterator::op++], delete the three lines of code at the
1798 end of paragraph 3. </p>
1799
1800
1801
1802
1803
1804 <hr>
1805 <h3><a name="40"></a>40. Meaningless normative paragraph in examples</h3>
1806 <p><b>Section:</b> 22.2.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1807  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1808 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</p>
1809 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1810 <p><b>Discussion:</b></p>
1811 <p>Paragraph 3 of the locale examples is a description of part of an
1812 implementation technique that has lost its referent, and doesn't mean
1813 anything. </p>
1814
1815
1816 <p><b>Proposed resolution:</b></p>
1817 <p>Delete 22.2.8 [facets.examples] paragraph 3 which begins "This
1818 initialization/identification system depends...", or (at the
1819 editor's option) replace it with a place-holder to keep the paragraph
1820 numbering the same. </p>
1821
1822
1823
1824
1825
1826 <hr>
1827 <h3><a name="41"></a>41. Ios_base needs clear(), exceptions()</h3>
1828 <p><b>Section:</b> 27.4.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1829  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1830 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</p>
1831 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1832 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#157">157</a></p>
1833 <p><b>Discussion:</b></p>
1834 <p>The description of ios_base::iword() and pword() in 27.4.2.4 [ios.members.static], say that if they fail, they "set badbit,
1835 which may throw an exception". However, ios_base offers no
1836 interface to set or to test badbit; those interfaces are defined in
1837 basic_ios&lt;&gt;. </p>
1838
1839
1840 <p><b>Proposed resolution:</b></p>
1841 <p>Change the description in 27.4.2.5 [ios.base.storage] in
1842 paragraph 2, and also in paragraph 4, as follows. Replace</p>
1843
1844 <blockquote>
1845   <p>If the function fails it sets badbit, which may throw an exception.</p>
1846 </blockquote>
1847
1848 <p>with</p>
1849
1850 <blockquote>
1851   <p>If the function fails, and <tt>*this</tt> is a base sub-object of
1852   a <tt>basic_ios&lt;&gt;</tt> object or sub-object, the effect is
1853   equivalent to calling <tt>basic_ios&lt;&gt;::setstate(badbit)</tt>
1854   on the derived object (which may throw <tt>failure</tt>).</p>
1855 </blockquote>
1856
1857 <p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
1858 setstate(badbit).]</i></p>
1859
1860
1861
1862
1863
1864
1865
1866 <hr>
1867 <h3><a name="42"></a>42. String ctors specify wrong default allocator</h3>
1868 <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1869  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1870 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
1871 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1872 <p><b>Discussion:</b></p>
1873 <p>The basic_string&lt;&gt; copy constructor: </p>
1874
1875 <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1876              size_type n = npos, const Allocator&amp; a = Allocator()); </pre>
1877
1878 <p>specifies an Allocator argument default value that is
1879 counter-intuitive. The natural choice for a the allocator to copy from
1880 is str.get_allocator(). Though this cannot be expressed in
1881 default-argument notation, overloading suffices. </p>
1882
1883 <p>Alternatively, the other containers in Clause 23 (deque, list,
1884 vector) do not have this form of constructor, so it is inconsistent,
1885 and an evident source of confusion, for basic_string&lt;&gt; to have
1886 it, so it might better be removed. </p>
1887
1888
1889 <p><b>Proposed resolution:</b></p>
1890 <p> In 21.3 [basic.string], replace the declaration of the copy
1891 constructor as follows: </p>
1892
1893 <blockquote>
1894   <pre>basic_string(const basic_string&amp; str);
1895 basic_string(const basic_string&amp; str, size_type pos, size_type n = npos,
1896              const Allocator&amp; a = Allocator());</pre>
1897 </blockquote>
1898
1899 <p>In 21.3.1 [string.require], replace the copy constructor declaration
1900 as above. Add to paragraph 5, Effects:</p>
1901
1902 <blockquote>
1903   <p>In the first form, the Allocator value used is copied from
1904   <tt>str.get_allocator()</tt>.</p>
1905 </blockquote>
1906
1907
1908 <p><b>Rationale:</b></p>
1909 <p>The LWG believes the constructor is actually broken, rather than
1910 just an unfortunate design choice.</p>
1911
1912 <p>The LWG considered two other possible resolutions:</p>
1913
1914 <p>A. In 21.3 [basic.string], replace the declaration of the copy
1915 constructor as follows:</p>
1916
1917 <blockquote>
1918   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1919              size_type n = npos);
1920 basic_string(const basic_string&amp; str, size_type pos,
1921              size_type n, const Allocator&amp; a); </pre>
1922 </blockquote>
1923
1924 <p>In 21.3.1 [string.require], replace the copy constructor declaration
1925 as above. Add to paragraph 5, Effects: </p>
1926
1927 <blockquote>
1928   <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
1929   value <tt>str.get_allocator()</tt>. </p>
1930 </blockquote>
1931
1932 <p>B. In 21.3 [basic.string], and also in 21.3.1 [string.require], replace
1933 the declaration of the copy constructor as follows: </p>
1934
1935 <blockquote>
1936   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1937              size_type n = npos); </pre>
1938 </blockquote>
1939
1940 <p>The proposed resolution reflects the original intent of the LWG. It
1941 was also noted by Pete Becker that this fix "will cause
1942 a small amount of existing code to now work correctly."</p>
1943
1944 <p><i>[
1945 Kona: issue editing snafu fixed - the proposed resolution now correctly
1946 reflects the LWG consensus.
1947 ]</i></p>
1948
1949
1950
1951
1952
1953
1954 <hr>
1955 <h3><a name="44"></a>44. Iostreams use operator== on int_type values</h3>
1956 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
1957  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1958 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
1959 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
1960 <p><b>Discussion:</b></p>
1961 <p>Many of the specifications for iostreams specify that character
1962 values or their int_type equivalents are compared using operators ==
1963 or !=, though in other places traits::eq() or traits::eq_int_type is
1964 specified to be used throughout. This is an inconsistency; we should
1965 change uses of == and != to use the traits members instead. </p>
1966
1967
1968 <p><b>Proposed resolution:</b></p>
1969
1970 <p><i>[Pre-Kona: Dietmar supplied wording]</i></p>
1971
1972
1973 <p>List of changes to clause 27:</p>
1974 <ol>
1975 <li>
1976    In lib.basic.ios.members paragraph 13 (postcondition clause for
1977    'fill(cT)') change
1978
1979 <blockquote><pre>     fillch == fill()
1980 </pre></blockquote>
1981
1982    to
1983
1984 <blockquote><pre>     traits::eq(fillch, fill())
1985 </pre></blockquote>
1986
1987
1988 </li>
1989 <li>
1990    In lib.istream.unformatted paragraph 7 (effects clause for
1991    'get(cT,streamsize,cT)'), third bullet, change
1992
1993 <blockquote><pre>     c == delim for the next available input character c
1994 </pre></blockquote>
1995
1996    to
1997
1998 <blockquote><pre>     traits::eq(c, delim) for the next available input character c
1999 </pre></blockquote>
2000
2001 </li>
2002 <li>
2003    In lib.istream.unformatted paragraph 12 (effects clause for
2004    'get(basic_streambuf&lt;cT,Tr&gt;&amp;,cT)'), third bullet, change
2005
2006 <blockquote><pre>     c == delim for the next available input character c
2007 </pre></blockquote>
2008
2009    to
2010
2011 <blockquote><pre>     traits::eq(c, delim) for the next available input character c
2012 </pre></blockquote>
2013
2014 </li>
2015 <li>
2016    In lib.istream.unformatted paragraph 17 (effects clause for
2017    'getline(cT,streamsize,cT)'), second bullet, change
2018
2019 <blockquote><pre>     c == delim for the next available input character c
2020 </pre></blockquote>
2021
2022    to
2023
2024 <blockquote><pre>     traits::eq(c, delim) for the next available input character c
2025   </pre></blockquote>
2026
2027 </li>
2028 <li>
2029    In lib.istream.unformatted paragraph 24 (effects clause for
2030    'ignore(int,int_type)'), second bullet, change
2031
2032 <blockquote><pre>     c == delim for the next available input character c
2033 </pre></blockquote>
2034
2035    to
2036
2037 <blockquote><pre>     traits::eq_int_type(c, delim) for the next available input
2038      character c
2039 </pre></blockquote>
2040
2041 </li>
2042 <li>
2043    In lib.istream.unformatted paragraph 25 (notes clause for
2044    'ignore(int,int_type)'), second bullet, change
2045
2046 <blockquote><pre>     The last condition will never occur if delim == traits::eof()
2047 </pre></blockquote>
2048
2049    to
2050
2051 <blockquote><pre>     The last condition will never occur if
2052      traits::eq_int_type(delim, traits::eof()).
2053 </pre></blockquote>
2054
2055 </li>
2056 <li>
2057    In lib.istream.sentry paragraph 6 (example implementation for the
2058    sentry constructor) change
2059
2060 <blockquote><pre>     while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
2061 </pre></blockquote>
2062
2063    to
2064
2065 <blockquote><pre>     while (!traits::eq_int_type(c = is.rdbuf()-&gt;snextc(), traits::eof())) {
2066 </pre></blockquote>
2067
2068 </li>
2069 </ol>
2070
2071 <p>List of changes to Chapter 21:</p>
2072
2073 <ol>
2074 <li>
2075    In lib.string::find paragraph 1 (effects clause for find()),
2076    second bullet, change
2077
2078 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2079 </pre></blockquote>
2080
2081    to
2082
2083 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2084 </pre></blockquote>
2085
2086 </li>
2087 <li>
2088    In lib.string::rfind paragraph 1 (effects clause for rfind()),
2089    second bullet, change
2090
2091 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2092 </pre></blockquote>
2093
2094    to
2095
2096 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2097 </pre></blockquote>
2098
2099 </li>
2100 <li>
2101    In lib.string::find.first.of paragraph 1 (effects clause for
2102    find_first_of()), second bullet, change
2103
2104 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2105 </pre></blockquote>
2106
2107    to
2108
2109 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2110 </pre></blockquote>
2111
2112 </li>
2113 <li>
2114    In lib.string::find.last.of paragraph 1 (effects clause for
2115    find_last_of()), second bullet, change
2116
2117 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2118 </pre></blockquote>
2119
2120    to
2121
2122 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2123 </pre></blockquote>
2124
2125 </li>
2126 <li>
2127    In lib.string::find.first.not.of paragraph 1 (effects clause for
2128    find_first_not_of()), second bullet, change
2129
2130 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2131 </pre></blockquote>
2132
2133    to
2134
2135 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2136 </pre></blockquote>
2137 </li>
2138
2139 <li>
2140    In lib.string::find.last.not.of paragraph 1 (effects clause for
2141    find_last_not_of()), second bullet, change
2142
2143 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2144 </pre></blockquote>
2145
2146    to
2147
2148 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2149 </pre></blockquote>
2150 </li>
2151
2152 <li>
2153    In lib.string.ios paragraph 5 (effects clause for getline()),
2154    second bullet, change
2155
2156 <blockquote><pre>     c == delim for the next available input character c
2157 </pre></blockquote>
2158
2159    to
2160
2161 <blockquote><pre>     traits::eq(c, delim) for the next available input character c
2162 </pre></blockquote>
2163 </li>
2164
2165 </ol>
2166
2167 <p>Notes:</p>
2168 <ul>
2169 <li>
2170   Fixing this issue highlights another sloppyness in
2171   lib.istream.unformatted paragraph 24: this clause mentions a "character"
2172   which is then compared to an 'int_type' (see item 5. in the list
2173   below). It is not clear whether this requires explicit words and
2174   if so what these words are supposed to be. A similar issue exists,
2175   BTW, for operator*() of istreambuf_iterator which returns the result
2176   of sgetc() as a character type (see lib.istreambuf.iterator::op*
2177   paragraph 1), and for operator++() of istreambuf_iterator which
2178   passes the result of sbumpc() to a constructor taking a char_type
2179   (see lib.istreambuf.iterator::operator++ paragraph 3). Similarily, the
2180   assignment operator ostreambuf_iterator passes a char_type to a function
2181   taking an int_type (see lib.ostreambuf.iter.ops paragraph 1).
2182 </li>
2183 <li>
2184   It is inconsistent to use comparisons using the traits functions in
2185   Chapter 27 while not using them in Chapter 21, especially as some
2186   of the inconsistent uses actually involve streams (eg. getline() on
2187   streams). To avoid leaving this issue open still longer due to this
2188   inconsistency (it is open since 1998), a list of changes to Chapter
2189   21 is below.
2190 </li>
2191 <li>
2192   In Chapter 24 there are several places with statements like "the end
2193   of stream is reached (streambuf_type::sgetc() returns traits::eof())"
2194   (lib.istreambuf.iterator paragraph 1, lib.ostreambuf.iter.ops
2195   paragraph 5). It is unclear whether these should be clarified to use
2196   traits::eq_int_type() for detecting traits::eof().
2197 </li>
2198 </ul>
2199
2200
2201
2202
2203
2204
2205 <hr>
2206 <h3><a name="46"></a>46. Minor Annex D errors</h3>
2207 <p><b>Section:</b> D.7 [depr.str.strstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2208  <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1998-06-01</p>
2209 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2210 <p><b>Discussion:</b></p><p>See lib-6522 and edit-814.</p>
2211
2212 <p><b>Proposed resolution:</b></p>
2213 <p>Change D.7.1 [depr.strstreambuf] (since streambuf is a typedef of
2214 basic_streambuf&lt;char&gt;) from:</p>
2215
2216 <pre>         virtual streambuf&lt;char&gt;* setbuf(char* s, streamsize n);</pre>
2217
2218 <p>to:</p>
2219
2220 <pre>         virtual streambuf* setbuf(char* s, streamsize n);</pre>
2221
2222 <p>In D.7.4 [depr.strstream] insert the semicolon now missing after
2223 int_type:</p>
2224
2225 <pre>     namespace std {
2226        class strstream
2227          : public basic_iostream&lt;char&gt; {
2228        public:
2229          // Types
2230          typedef char                                char_type;
2231          typedef typename char_traits&lt;char&gt;::int_type int_type
2232          typedef typename char_traits&lt;char&gt;::pos_type pos_type;</pre>
2233
2234
2235
2236
2237
2238 <hr>
2239 <h3><a name="47"></a>47. Imbue() and getloc() Returns clauses swapped</h3>
2240 <p><b>Section:</b> 27.4.2.3 [ios.base.locales] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2241  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p>
2242 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.locales">issues</a> in [ios.base.locales].</p>
2243 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2244 <p><b>Discussion:</b></p>
2245 <p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
2246 section has two RETURNS clauses, and they make no sense as
2247 stated. They make perfect sense, though, if you swap them. Am I
2248 correct in thinking that paragraphs 2 and 4 just got mixed up by
2249 accident?</p>
2250
2251
2252 <p><b>Proposed resolution:</b></p>
2253 <p>In 27.4.2.3 [ios.base.locales] swap paragraphs 2 and 4.</p>
2254
2255
2256
2257
2258
2259 <hr>
2260 <h3><a name="48"></a>48. Use of non-existent exception constructor</h3>
2261 <p><b>Section:</b> 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2262  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p>
2263 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</p>
2264 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2265 <p><b>Discussion:</b></p>
2266 <p>27.4.2.1.1, paragraph 2, says that class failure initializes the
2267 base class, exception, with exception(msg). Class exception (see
2268 18.6.1) has no such constructor.</p>
2269
2270
2271 <p><b>Proposed resolution:</b></p>
2272 <p>Replace 27.4.2.1.1 [ios::failure], paragraph 2, with</p>
2273
2274 <blockquote>
2275   <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
2276 </blockquote>
2277
2278
2279
2280
2281
2282 <hr>
2283 <h3><a name="49"></a>49. Underspecification of ios_base::sync_with_stdio</h3>
2284 <p><b>Section:</b> 27.4.2.4 [ios.members.static] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
2285  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p>
2286 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
2287 <p><b>Discussion:</b></p>
2288 <p>Two problems</p>
2289
2290 <p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
2291 returns. Does it return f, or does it return the previous
2292 synchronization state? My guess is the latter, but the standard
2293 doesn't say so.</p>
2294
2295 <p>(2) 27.4.2.4 doesn't say what it means for streams to be
2296 synchronized with stdio.  Again, of course, I can make some
2297 guesses. (And I'm unhappy about the performance implications of those
2298 guesses, but that's another matter.)</p>
2299
2300
2301 <p><b>Proposed resolution:</b></p>
2302 <p>Change the following sentence in 27.4.2.4 [ios.members.static]
2303 returns clause from:</p>
2304
2305 <blockquote>
2306   <p><tt>true</tt> if the standard iostream objects (27.3) are
2307   synchronized and otherwise returns <tt>false</tt>.</p>
2308 </blockquote>
2309
2310 <p>to:</p>
2311
2312 <blockquote>
2313   <p><tt>true</tt> if the previous state of the standard iostream
2314   objects (27.3) was synchronized and otherwise returns
2315   <tt>false</tt>.</p>
2316 </blockquote>
2317
2318 <p>Add the following immediately after 27.4.2.4 [ios.members.static],
2319 paragraph 2:</p>
2320
2321 <blockquote>
2322 <p>When a standard iostream object str is <i>synchronized</i> with a
2323 standard stdio stream f, the effect of inserting a character c by</p>
2324 <pre>  fputc(f, c);
2325 </pre>
2326
2327 <p>is the same as the effect of</p>
2328 <pre>  str.rdbuf()-&gt;sputc(c);
2329 </pre>
2330
2331 <p>for any sequence of characters; the effect of extracting a
2332 character c by</p>
2333 <pre>  c = fgetc(f);
2334 </pre>
2335
2336 <p>is the same as the effect of:</p>
2337 <pre>  c = str.rdbuf()-&gt;sbumpc(c);
2338 </pre>
2339
2340 <p>for any sequences of characters; and the effect of pushing
2341 back a character c by</p>
2342 <pre>  ungetc(c, f);
2343 </pre>
2344
2345 <p>is the same as the effect of</p>
2346 <pre>  str.rdbuf()-&gt;sputbackc(c);
2347 </pre>
2348
2349 <p>for any sequence of characters.  [<i>Footnote</i>: This implies
2350 that operations on a standard iostream object can be mixed arbitrarily
2351 with operations on the corresponding stdio stream.  In practical
2352 terms, synchronization usually means that a standard iostream object
2353 and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
2354 </blockquote>
2355
2356 <p><i>[pre-Copenhagen: PJP and Matt contributed the definition
2357 of "synchronization"]</i></p>
2358
2359
2360 <p><i>[post-Copenhagen: proposed resolution was revised slightly:
2361 text was added in the non-normative footnote to say that operations
2362 on the two streams can be mixed arbitrarily.]</i></p>
2363
2364
2365
2366
2367
2368
2369 <hr>
2370 <h3><a name="50"></a>50. Copy constructor and assignment operator of ios_base</h3>
2371 <p><b>Section:</b> 27.4.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2372  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p>
2373 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</p>
2374 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2375 <p><b>Discussion:</b></p>
2376 <p>As written, ios_base has a copy constructor and an assignment
2377 operator. (Nothing in the standard says it doesn't have one, and all
2378 classes have copy constructors and assignment operators unless you
2379 take specific steps to avoid them.) However, nothing in 27.4.2 says
2380 what the copy constructor and assignment operator do. </p>
2381
2382 <p>My guess is that this was an oversight, that ios_base is, like
2383 basic_ios, not supposed to have a copy constructor or an assignment
2384 operator.</p>
2385
2386 <p>
2387 Jerry Schwarz comments: Yes, its an oversight, but in the opposite
2388 sense to what you're suggesting. At one point there was a definite
2389 intention that you could copy ios_base. It's an easy way to save the
2390 entire state of a stream for future use. As you note, to carry out
2391 that intention would have required a explicit description of the
2392 semantics (e.g. what happens to the iarray and parray stuff).
2393 </p>
2394
2395
2396 <p><b>Proposed resolution:</b></p>
2397 <p>In 27.4.2 [ios.base], class ios_base, specify the copy
2398 constructor and operator= members as being private.</p>
2399
2400
2401 <p><b>Rationale:</b></p>
2402 <p>The LWG believes the difficulty of specifying correct semantics
2403 outweighs any benefit of allowing ios_base objects to be copyable.</p>
2404
2405
2406
2407
2408
2409 <hr>
2410 <h3><a name="51"></a>51. Requirement to not invalidate iterators missing</h3>
2411 <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2412  <b>Submitter:</b> David Vandevoorde <b>Date:</b> 1998-06-23</p>
2413 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
2414 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
2415 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2416 <p><b>Discussion:</b></p>
2417 <p>The std::sort algorithm can in general only sort a given sequence
2418 by moving around values. The list&lt;&gt;::sort() member on the other
2419 hand could move around values or just update internal pointers. Either
2420 method can leave iterators into the list&lt;&gt; dereferencable, but
2421 they would point to different things. </p>
2422
2423 <p>Does the FDIS mandate anywhere which method should be used for
2424 list&lt;&gt;::sort()?</p>
2425
2426 <p>Matt Austern comments:</p>
2427
2428 <p>I think you've found an omission in the standard. </p>
2429
2430 <p>The library working group discussed this point, and there was
2431 supposed to be a general requirement saying that list, set, map,
2432 multiset, and multimap may not invalidate iterators, or change the
2433 values that iterators point to, except when an operation does it
2434 explicitly. So, for example, insert() doesn't invalidate any iterators
2435 and erase() and remove() only invalidate iterators pointing to the
2436 elements that are being erased. </p>
2437
2438 <p>I looked for that general requirement in the FDIS, and, while I
2439 found a limited form of it for the sorted associative containers, I
2440 didn't find it for list. It looks like it just got omitted. </p>
2441
2442 <p>The intention, though, is that list&lt;&gt;::sort does not
2443 invalidate any iterators and does not change the values that any
2444 iterator points to. There would be no reason to have the member
2445 function otherwise.</p>
2446
2447
2448 <p><b>Proposed resolution:</b></p>
2449 <p>Add a new paragraph at the end of 23.1:</p>
2450
2451 <blockquote>
2452   <p>Unless otherwise specified (either explicitly or by defining a function in terms of
2453   other functions), invoking a container member function or passing a container as an
2454   argument to a library function shall not invalidate iterators to, or change the values of,
2455   objects within that container. </p>
2456 </blockquote>
2457
2458
2459 <p><b>Rationale:</b></p>
2460 <p>This was US issue CD2-23-011; it was accepted in London but the
2461 change was not made due to an editing oversight. The wording in the
2462 proposed resolution below is somewhat updated from CD2-23-011,
2463 particularly the addition of the phrase "or change the values
2464 of"</p>
2465
2466
2467
2468
2469
2470 <hr>
2471 <h3><a name="52"></a>52. Small I/O problems</h3>
2472 <p><b>Section:</b> 27.4.3.2 [fpos.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2473  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-23</p>
2474 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2475 <p><b>Discussion:</b></p>
2476 <p>First, 27.4.4.1 [basic.ios.cons], table 89. This is pretty obvious:
2477 it should be titled "basic_ios&lt;&gt;() effects", not
2478 "ios_base() effects". </p>
2479
2480 <p>[The second item is a duplicate; see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#6">6</a> for
2481 resolution.]</p>
2482
2483 <p>Second, 27.4.3.2 [fpos.operations] table 88 . There are a couple
2484 different things wrong with it, some of which I've already discussed
2485 with Jerry, but the most obvious mechanical sort of error is that it
2486 uses expressions like P(i) and p(i), without ever defining what sort
2487 of thing "i" is.
2488 </p>
2489
2490 <p>(The other problem is that it requires support for streampos
2491 arithmetic. This is impossible on some systems, i.e. ones where file
2492 position is a complicated structure rather than just a number. Jerry
2493 tells me that the intention was to require syntactic support for
2494 streampos arithmetic, but that it wasn't actually supposed to do
2495 anything meaningful except on platforms, like Unix, where genuine
2496 arithmetic is possible.) </p>
2497
2498
2499 <p><b>Proposed resolution:</b></p>
2500 <p>Change 27.4.4.1 [basic.ios.cons] table 89 title from
2501 "ios_base() effects" to "basic_ios&lt;&gt;()
2502 effects". </p>
2503
2504
2505
2506
2507
2508 <hr>
2509 <h3><a name="53"></a>53. Basic_ios destructor unspecified</h3>
2510 <p><b>Section:</b> 27.4.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2511  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-23</p>
2512 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p>
2513 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2514 <p><b>Discussion:</b></p>
2515 <p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
2516 The important question is whether basic_ios::~basic_ios() destroys
2517 rdbuf().</p>
2518
2519
2520 <p><b>Proposed resolution:</b></p>
2521 <p>Add after 27.4.4.1 [basic.ios.cons] paragraph 2:</p>
2522
2523 <blockquote>
2524   <p><tt>virtual ~basic_ios();</tt></p>
2525   <p><b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
2526 </blockquote>
2527
2528
2529 <p><b>Rationale:</b></p>
2530 <p>The LWG reviewed the additional question of whether or not
2531 <tt>rdbuf(0)</tt> may set <tt>badbit</tt>.  The answer is
2532 clearly yes; it may be set via <tt>clear()</tt>.  See 27.4.4.2 [basic.ios.members], paragraph 6.  This issue was reviewed at length
2533 by the LWG, which removed from the original proposed resolution a
2534 footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
2535 <tt>badbit</tt>".</p>
2536
2537
2538
2539
2540
2541 <hr>
2542 <h3><a name="54"></a>54. Basic_streambuf's destructor</h3>
2543 <p><b>Section:</b> 27.5.2.1 [streambuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2544  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-25</p>
2545 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.cons">issues</a> in [streambuf.cons].</p>
2546 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2547 <p><b>Discussion:</b></p>
2548 <p>The class synopsis for basic_streambuf shows a (virtual)
2549 destructor, but the standard doesn't say what that destructor does. My
2550 assumption is that it does nothing, but the standard should say so
2551 explicitly. </p>
2552
2553
2554 <p><b>Proposed resolution:</b></p>
2555 <p>Add after 27.5.2.1 [streambuf.cons] paragraph 2:</p>
2556
2557 <blockquote>
2558   <p><tt>virtual&nbsp; ~basic_streambuf();</tt></p>
2559   <p><b>Effects</b>: None.</p>
2560 </blockquote>
2561
2562
2563
2564
2565
2566 <hr>
2567 <h3><a name="55"></a>55. Invalid stream position is undefined</h3>
2568 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2569  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-26</p>
2570 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
2571 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2572 <p><b>Discussion:</b></p>
2573 <p>Several member functions in clause 27 are defined in certain
2574 circumstances to return an "invalid stream position", a term
2575 that is defined nowhere in the standard. Two places (27.5.2.4.2,
2576 paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
2577 a definition in _lib.iostreams.definitions_, a nonexistent
2578 section. </p>
2579
2580 <p>I suspect that the invalid stream position is just supposed to be
2581 pos_type(-1).  Probably best to say explicitly in (for example)
2582 27.5.2.4.2 that the return value is pos_type(-1), rather than to use
2583 the term "invalid stream position", define that term
2584 somewhere, and then put in a cross-reference. </p>
2585
2586 <p>The phrase "invalid stream position" appears ten times in
2587 the C++ Standard.  In seven places it refers to a return value, and it
2588 should be changed. In three places it refers to an argument, and it
2589 should not be changed. Here are the three places where "invalid
2590 stream position" should not be changed:</p>
2591
2592 <blockquote>
2593   <p>27.7.1.4 [stringbuf.virtuals], paragraph 14<br>
2594   27.8.1.5 [filebuf.virtuals], paragraph 14<br>
2595   D.7.1.3 [depr.strstreambuf.virtuals], paragraph 17
2596   </p>
2597 </blockquote>
2598
2599
2600 <p><b>Proposed resolution:</b></p>
2601 <p>In 27.5.2.4.2 [streambuf.virt.buffer], paragraph 4, change "Returns an
2602 object of class pos_type that stores an invalid stream position
2603 (_lib.iostreams.definitions_)" to "Returns
2604 <tt>pos_type(off_type(-1))</tt>".
2605 </p>
2606
2607 <p>In 27.5.2.4.2 [streambuf.virt.buffer], paragraph 6, change "Returns
2608 an object of class pos_type that stores an invalid stream
2609 position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
2610
2611 <p>In 27.7.1.4 [stringbuf.virtuals], paragraph 13, change "the object
2612 stores an invalid stream position" to "the return value is
2613 <tt>pos_type(off_type(-1))</tt>". </p>
2614
2615 <p>In 27.8.1.5 [filebuf.virtuals], paragraph 13, change "returns an
2616 invalid stream position (27.4.3)" to "returns
2617 <tt>pos_type(off_type(-1))</tt>" </p>
2618
2619 <p>In 27.8.1.5 [filebuf.virtuals], paragraph 15, change "Otherwise
2620 returns an invalid stream position (_lib.iostreams.definitions_)"
2621 to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
2622 </p>
2623
2624 <p>In D.7.1.3 [depr.strstreambuf.virtuals], paragraph 15, change "the object
2625 stores an invalid stream position" to "the return value is
2626 <tt>pos_type(off_type(-1))</tt>" </p>
2627
2628 <p>In D.7.1.3 [depr.strstreambuf.virtuals], paragraph 18, change "the object
2629 stores an invalid stream position" to "the return value is
2630 <tt>pos_type(off_type(-1))</tt>"</p>
2631
2632
2633
2634
2635
2636 <hr>
2637 <h3><a name="56"></a>56. Showmanyc's return type</h3>
2638 <p><b>Section:</b> 27.5.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2639  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-29</p>
2640 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf">issues</a> in [streambuf].</p>
2641 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2642 <p><b>Discussion:</b></p>
2643 <p>The class summary for basic_streambuf&lt;&gt;, in 27.5.2, says that
2644 showmanyc has return type int. However, 27.5.2.4.3 says that its
2645 return type is streamsize. </p>
2646
2647
2648 <p><b>Proposed resolution:</b></p>
2649 <p>Change <tt>showmanyc</tt>'s return type in the
2650 27.5.2 [streambuf] class summary to <tt>streamsize</tt>.</p>
2651
2652
2653
2654
2655
2656 <hr>
2657 <h3><a name="57"></a>57. Mistake in char_traits</h3>
2658 <p><b>Section:</b> 21.1.3.4 [char.traits.specializations.wchar.t] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2659  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-07-01</p>
2660 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2661 <p><b>Discussion:</b></p>
2662 <p>21.1.3.2, paragraph 3, says "The types streampos and
2663 wstreampos may be different if the implementation supports no shift
2664 encoding in narrow-oriented iostreams but supports one or more shift
2665 encodings in wide-oriented streams". </p>
2666
2667 <p>That's wrong: the two are the same type. The &lt;iosfwd&gt; summary
2668 in 27.2 says that streampos and wstreampos are, respectively, synonyms
2669 for fpos&lt;char_traits&lt;char&gt;::state_type&gt; and
2670 fpos&lt;char_traits&lt;wchar_t&gt;::state_type&gt;, and, flipping back
2671 to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
2672 char_traits&lt;char&gt;::state_type and
2673 char_traits&lt;wchar_t&gt;::state_type must both be mbstate_t. </p>
2674
2675
2676 <p><b>Proposed resolution:</b></p>
2677 <p>Remove the sentence in 21.1.3.4 [char.traits.specializations.wchar.t] paragraph 3 which
2678 begins "The types streampos and wstreampos may be
2679 different..." . </p>
2680
2681
2682
2683
2684
2685 <hr>
2686 <h3><a name="59"></a>59. Ambiguity in specification of gbump</h3>
2687 <p><b>Section:</b> 27.5.2.3.2 [streambuf.get.area] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2688  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-07-28</p>
2689 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2690 <p><b>Discussion:</b></p>
2691 <p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
2692 next pointer for the input sequence by n." </p>
2693
2694 <p>The straightforward interpretation is that it is just gptr() +=
2695 n. An alternative interpretation, though, is that it behaves as if it
2696 calls sbumpc n times. (The issue, of course, is whether it might ever
2697 call underflow.) There is a similar ambiguity in the case of
2698 pbump. </p>
2699
2700 <p>(The "classic" AT&amp;T implementation used the
2701 former interpretation.)</p>
2702
2703
2704 <p><b>Proposed resolution:</b></p>
2705 <p>Change 27.5.2.3.2 [streambuf.get.area] paragraph 4 gbump effects from:</p>
2706
2707 <blockquote>
2708   <p>Effects: Advances the next pointer for the input sequence by n.</p>
2709 </blockquote>
2710
2711 <p>to:</p>
2712
2713 <blockquote>
2714   <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
2715 </blockquote>
2716
2717 <p>Make the same change to 27.5.2.3.3 [streambuf.put.area] paragraph 4 pbump
2718 effects.</p>
2719
2720
2721
2722
2723
2724 <hr>
2725 <h3><a name="60"></a>60. What is a formatted input function?</h3>
2726 <p><b>Section:</b> 27.6.1.2.1 [istream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2727  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-03</p>
2728 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.reqmts">issues</a> in [istream.formatted.reqmts].</p>
2729 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2730 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#163">163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#166">166</a></p>
2731 <p><b>Discussion:</b></p>
2732 <p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
2733 formatted input functions. Some of the functions defined in section
2734 27.6.1.2 explicitly say that those requirements apply ("Behaves
2735 like a formatted input member (as described in 27.6.1.2.1)"), but
2736 others don't. The question: is 27.6.1.2.1 supposed to apply to
2737 everything in 27.6.1.2, or only to those member functions that
2738 explicitly say "behaves like a formatted input member"? Or
2739 to put it differently: are we to assume that everything that appears
2740 in a section called "Formatted input functions" really is a
2741 formatted input function? I assume that 27.6.1.2.1 is intended to
2742 apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
2743 is not intended to apply to extractors like </p>
2744
2745 <pre>    basic_istream&amp; operator&gt;&gt;(basic_istream&amp; (*pf)(basic_istream&amp;));</pre>
2746
2747 <p>and </p>
2748
2749 <pre>    basic_istream&amp; operator&gt;&gt;(basic_streammbuf*);</pre>
2750
2751 <p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
2752 output. </p>
2753
2754 <p>Comments from Judy Ward: It seems like the problem is that the
2755 basic_istream and basic_ostream operator &lt;&lt;()'s that are used
2756 for the manipulators and streambuf* are in the wrong section and
2757 should have their own separate section or be modified to make it clear
2758 that the "Common requirements" listed in section 27.6.1.2.1
2759 (for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
2760 apply to them. </p>
2761
2762 <p>Additional comments from Dietmar Kühl: It appears to be somewhat
2763 nonsensical to consider the functions defined in 27.6.1.2.3
2764 [istream::extractors] paragraphs 1 to 5 to be "Formatted input
2765 function" but since these functions are defined in a section
2766 labeled "Formatted input functions" it is unclear to me
2767 whether these operators are considered formatted input functions which
2768 have to conform to the "common requirements" from 27.6.1.2.1
2769 [istream.formatted.reqmts]: If this is the case, all manipulators, not
2770 just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
2771 set (... but setting <tt>noskipws</tt> using the manipulator syntax
2772 would also skip whitespace :-)</p> <p>It is not clear which functions
2773 are to be considered unformatted input functions. As written, it seems
2774 that all functions in 27.6.1.3 [istream.unformatted] are unformatted input
2775 functions. However, it does not really make much sense to construct a
2776 sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
2777 unclear what happens to the <tt>gcount()</tt> if
2778 eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
2779 <tt>sync()</tt> is called: These functions don't extract characters,
2780 some of them even "unextract" a character. Should this still
2781 be reflected in <tt>gcount()</tt>? Of course, it could be read as if
2782 after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
2783 (the last unformatted input function, <tt>gcount()</tt>, didn't
2784 extract any character) and after a call to <tt>putback()</tt>
2785 <tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
2786 function <tt>putback()</tt> did "extract" back into the
2787 stream). Correspondingly for <tt>unget()</tt>. Is this what is
2788 intended?  If so, this should be clarified. Otherwise, a corresponding
2789 clarification should be used.</p>
2790
2791
2792 <p><b>Proposed resolution:</b></p>
2793 <p>
2794 In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
2795 Change the beginning of the second sentence from "The conversion
2796 occurs" to "These extractors behave as formatted input functions (as
2797 described in 27.6.1.2.1).  After a sentry object is constructed,
2798 the conversion occurs"
2799 </p>
2800
2801 <p>
2802 In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
2803 Add an effects clause.  "Effects: None.  This extractor does
2804 not behave as a formatted input function (as described in
2805 27.6.1.2.1).
2806 </p>
2807
2808 <p>
2809 In 27.6.1.2.3, [lib.istream::extractors], paragraph 2.  Change the
2810 effects clause to "Effects: Calls pf(*this).  This extractor does not
2811 behave as a formatted input function (as described in 27.6.1.2.1).
2812 </p>
2813
2814 <p>
2815 In 27.6.1.2.3, [lib.istream::extractors], paragraph 4.  Change the
2816 effects clause to "Effects: Calls pf(*this).  This extractor does not
2817 behave as a formatted input function (as described in 27.6.1.2.1).
2818 </p>
2819
2820 <p>
2821 In 27.6.1.2.3, [lib.istream::extractors], paragraph 12.  Change the
2822 first two sentences from "If sb is null, calls setstate(failbit),
2823 which may throw ios_base::failure (27.4.4.3).  Extracts characters
2824 from *this..." to "Behaves as a formatted input function (as described
2825 in 27.6.1.2.1).  If sb is null, calls setstate(failbit), which may
2826 throw ios_base::failure (27.4.4.3).  After a sentry object is
2827 constructed, extracts characters from *this...".
2828 </p>
2829
2830 <p>
2831 In 27.6.1.3, [lib.istream.unformatted], before paragraph 2.  Add an
2832 effects clause.  "Effects: none. This member function does not behave
2833 as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
2834 </p>
2835
2836 <p>
2837 In 27.6.1.3, [lib.istream.unformatted], paragraph 3.  Change the
2838 beginning of the first sentence of the effects clause from "Extracts a
2839 character" to "Behaves as an unformatted input function (as described
2840 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
2841 character"
2842 </p>
2843
2844 <p>
2845 In 27.6.1.3, [lib.istream.unformatted], paragraph 5.  Change the
2846 beginning of the first sentence of the effects clause from "Extracts a
2847 character" to "Behaves as an unformatted input function (as described
2848 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
2849 character"
2850 </p>
2851
2852 <p>
2853 In 27.6.1.3, [lib.istream.unformatted], paragraph 7.  Change the
2854 beginning of the first sentence of the effects clause from "Extracts
2855 characters" to "Behaves as an unformatted input function (as described
2856 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2857 characters"
2858 </p>
2859
2860 <p>
2861 [No change needed in paragraph 10, because it refers to paragraph 7.]
2862 </p>
2863
2864 <p>
2865 In 27.6.1.3, [lib.istream.unformatted], paragraph 12.  Change the
2866 beginning of the first sentence of the effects clause from "Extracts
2867 characters" to "Behaves as an unformatted input function (as described
2868 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2869 characters"
2870 </p>
2871
2872 <p>
2873 [No change needed in paragraph 15.]
2874 </p>
2875
2876 <p>
2877 In 27.6.1.3, [lib.istream.unformatted], paragraph 17.  Change the
2878 beginning of the first sentence of the effects clause from "Extracts
2879 characters" to "Behaves as an unformatted input function (as described
2880 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2881 characters"
2882 </p>
2883
2884 <p>
2885 [No change needed in paragraph 23.]
2886 </p>
2887
2888 <p>
2889 In 27.6.1.3, [lib.istream.unformatted], paragraph 24.  Change the
2890 beginning of the first sentence of the effects clause from "Extracts
2891 characters" to "Behaves as an unformatted input function (as described
2892 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2893 characters"
2894 </p>
2895
2896 <p>
2897 In 27.6.1.3, [lib.istream.unformatted], before paragraph 27.  Add an
2898 Effects clause: "Effects: Behaves as an unformatted input function (as
2899 described in 27.6.1.3, paragraph 1).  After constructing a sentry
2900 object, reads but does not extract the current input character."
2901 </p>
2902
2903 <p>
2904 In 27.6.1.3, [lib.istream.unformatted], paragraph 28.  Change the
2905 first sentence of the Effects clause from "If !good() calls" to
2906 Behaves as an unformatted input function (as described in 27.6.1.3,
2907 paragraph 1).  After constructing a sentry object, if !good() calls"
2908 </p>
2909
2910 <p>
2911 In 27.6.1.3, [lib.istream.unformatted], paragraph 30.  Change the
2912 first sentence of the Effects clause from "If !good() calls" to
2913 "Behaves as an unformatted input function (as described in 27.6.1.3,
2914 paragraph 1).  After constructing a sentry object, if !good() calls"
2915 </p>
2916
2917 <p>
2918 In 27.6.1.3, [lib.istream.unformatted], paragraph 32.  Change the
2919 first sentence of the Effects clause from "If !good() calls..." to
2920 "Behaves as an unformatted input function (as described in 27.6.1.3,
2921 paragraph 1).  After constructing a sentry object, if !good()
2922 calls..."  Add a new sentence to the end of the Effects clause:
2923 "[Note: this function extracts no characters, so the value returned
2924 by the next call to gcount() is 0.]"
2925 </p>
2926
2927 <p>
2928 In 27.6.1.3, [lib.istream.unformatted], paragraph 34.  Change the
2929 first sentence of the Effects clause from "If !good() calls" to
2930 "Behaves as an unformatted input function (as described in 27.6.1.3,
2931 paragraph 1).  After constructing a sentry object, if !good() calls".
2932 Add a new sentence to the end of the Effects clause: "[Note: this
2933 function extracts no characters, so the value returned by the next
2934 call to gcount() is 0.]"
2935 </p>
2936
2937 <p>
2938 In 27.6.1.3, [lib.istream.unformatted], paragraph 36.  Change the
2939 first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
2940 as an unformatted input function (as described in 27.6.1.3, paragraph
2941 1), except that it does not count the number of characters extracted
2942 and does not affect the value returned by subsequent calls to
2943 gcount().  After constructing a sentry object, if rdbuf() is"
2944 </p>
2945
2946 <p>
2947 In 27.6.1.3, [lib.istream.unformatted], before paragraph 37.  Add an
2948 Effects clause: "Effects: Behaves as an unformatted input function (as
2949 described in 27.6.1.3, paragraph 1), except that it does not count the
2950 number of characters extracted and does not affect the value returned
2951 by subsequent calls to gcount()."  Change the first sentence of
2952 paragraph 37 from "if fail()" to "after constructing a sentry object,
2953 if fail()".
2954 </p>
2955
2956 <p>
2957 In 27.6.1.3, [lib.istream.unformatted], paragraph 38.  Change the
2958 first sentence of the Effects clause from "If fail()" to "Behaves
2959 as an unformatted input function (as described in 27.6.1.3, paragraph
2960 1), except that it does not count the number of characters extracted
2961 and does not affect the value returned by subsequent calls to
2962 gcount().  After constructing a sentry object, if fail()
2963 </p>
2964
2965 <p>
2966 In 27.6.1.3, [lib.istream.unformatted], paragraph 40.  Change the
2967 first sentence of the Effects clause from "If fail()" to "Behaves
2968 as an unformatted input function (as described in 27.6.1.3, paragraph
2969 1), except that it does not count the number of characters extracted
2970 and does not affect the value returned by subsequent calls to
2971 gcount().  After constructing a sentry object, if fail()
2972 </p>
2973
2974 <p>
2975 In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1.  Change
2976 the beginning of the third sentence from "The formatting conversion"
2977 to "These extractors behave as formatted output functions (as
2978 described in 27.6.2.5.1).  After the sentry object is constructed, the
2979 conversion occurs".
2980 </p>
2981
2982 <p>
2983 In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1.  Add an
2984 effects clause: "Effects: None. Does not behave as a formatted output
2985 function (as described in 27.6.2.5.1).".
2986 </p>
2987
2988 <p>
2989 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2.  Change the
2990 effects clause to "Effects: calls pf(*this).  This extractor does not
2991 behave as a formatted output function (as described in 27.6.2.5.1).".
2992 </p>
2993
2994 <p>
2995 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4.  Change the
2996 effects clause to "Effects: calls pf(*this).  This extractor does not
2997 behave as a formatted output function (as described in 27.6.2.5.1).".
2998 </p>
2999
3000 <p>
3001 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6.  Change the first
3002 sentence from "If sb" to "Behaves as a formatted output function (as
3003 described in 27.6.2.5.1).  After the sentry object is constructed, if
3004 sb".
3005 </p>
3006
3007 <p>
3008 In 27.6.2.6 [lib.ostream.unformatted], paragraph 2.  Change the first
3009 sentence from "Inserts the character" to "Behaves as an unformatted
3010 output function (as described in 27.6.2.6, paragraph 1).  After
3011 constructing a sentry object, inserts the character".
3012 </p>
3013
3014 <p>
3015 In 27.6.2.6 [lib.ostream.unformatted], paragraph 5.  Change the first
3016 sentence from "Obtains characters" to "Behaves as an unformatted
3017 output function (as described in 27.6.2.6, paragraph 1).  After
3018 constructing a sentry object, obtains characters".
3019 </p>
3020
3021 <p>
3022 In 27.6.2.6 [lib.ostream.unformatted], paragraph 7.  Add a new
3023 sentence at the end of the paragraph: "Does not behave as an
3024 unformatted output function (as described in 27.6.2.6, paragraph 1)."
3025 </p>
3026
3027
3028 <p><b>Rationale:</b></p>
3029 <p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
3030 by Judy Ward and Matt Austern.  This proposed resolution is section
3031 VI of that paper.</p>
3032
3033
3034
3035
3036
3037 <hr>
3038 <h3><a name="61"></a>61. Ambiguity in iostreams exception policy</h3>
3039 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3040  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-06</p>
3041 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
3042 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
3043 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3044 <p><b>Discussion:</b></p>
3045 <p>The introduction to the section on unformatted input (27.6.1.3)
3046 says that every unformatted input function catches all exceptions that
3047 were thrown during input, sets badbit, and then conditionally rethrows
3048 the exception. That seems clear enough. Several of the specific
3049 functions, however, such as get() and read(), are documented in some
3050 circumstances as setting eofbit and/or failbit. (The standard notes,
3051 correctly, that setting eofbit or failbit can sometimes result in an
3052 exception being thrown.) The question: if one of these functions
3053 throws an exception triggered by setting failbit, is this an exception
3054 "thrown during input" and hence covered by 27.6.1.3, or does
3055 27.6.1.3 only refer to a limited class of exceptions? Just to make
3056 this concrete, suppose you have the following snippet. </p>
3057
3058 <pre>
3059   char buffer[N];
3060   istream is;
3061   ...
3062   is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
3063   is.read(buffer, N);</pre>
3064
3065 <p>Now suppose we reach EOF before we've read N characters. What
3066 iostate bits can we expect to be set, and what exception (if any) will
3067 be thrown? </p>
3068
3069
3070 <p><b>Proposed resolution:</b></p>
3071 <p>
3072 In 27.6.1.3, paragraph 1, after the sentence that begins
3073 "If an exception is thrown...", add the following
3074 parenthetical comment: "(Exceptions thrown from
3075 <tt>basic_ios&lt;&gt;::clear()</tt> are not caught or rethrown.)"
3076 </p>
3077
3078
3079 <p><b>Rationale:</b></p>
3080 <p>The LWG looked to two alternative wordings, and choose the proposed
3081 resolution as better standardese.</p>
3082
3083
3084
3085
3086
3087 <hr>
3088 <h3><a name="62"></a>62. <tt>Sync</tt>'s return value</h3>
3089 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3090  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-06</p>
3091 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
3092 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
3093 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3094 <p><b>Discussion:</b></p>
3095 <p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
3096 "calls rdbuf()-&gt;pubsync() and, if that function returns -1
3097 ... returns traits::eof()." </p>
3098
3099 <p>That looks suspicious, because traits::eof() is of type
3100 traits::int_type while the return type of sync() is int. </p>
3101
3102
3103 <p><b>Proposed resolution:</b></p>
3104 <p>In 27.6.1.3 [istream.unformatted], paragraph 36, change "returns
3105 <tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
3106 </p>
3107
3108
3109
3110
3111
3112 <hr>
3113 <h3><a name="63"></a>63. Exception-handling policy for unformatted output</h3>
3114 <p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3115  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-11</p>
3116 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p>
3117 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3118 <p><b>Discussion:</b></p>
3119 <p>Clause 27 details an exception-handling policy for formatted input,
3120 unformatted input, and formatted output. It says nothing for
3121 unformatted output (27.6.2.6). 27.6.2.6 should either include the same
3122 kind of exception-handling policy as in the other three places, or
3123 else it should have a footnote saying that the omission is
3124 deliberate. </p>
3125
3126
3127 <p><b>Proposed resolution:</b></p>
3128 <p>
3129 In 27.6.2.6, paragraph 1, replace the last sentence ("In any
3130 case, the unformatted output function ends by destroying the sentry
3131 object, then returning the value specified for the formatted output
3132 function.") with the following text:
3133 </p>
3134 <blockquote><p>
3135 If an exception is thrown during output, then <tt>ios::badbit</tt> is
3136 turned on [Footnote: without causing an <tt>ios::failure</tt> to be
3137 thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &amp;
3138 badbit) != 0</tt> then the exception is rethrown.  In any case, the
3139 unformatted output function ends by destroying the sentry object,
3140 then, if no exception was thrown, returning the value specified for
3141 the formatted output function.
3142 </p></blockquote>
3143
3144
3145 <p><b>Rationale:</b></p>
3146 <p>
3147 This exception-handling policy is consistent with that of formatted
3148 input, unformatted input, and formatted output.
3149 </p>
3150
3151
3152
3153
3154
3155 <hr>
3156 <h3><a name="64"></a>64. Exception handling in <tt>basic_istream::operator&gt;&gt;(basic_streambuf*)</tt></h3>
3157 <p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3158  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-11</p>
3159 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
3160 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3161 <p><b>Discussion:</b></p>
3162 <p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
3163 different ways, depending on whether the second sentence is read as an
3164 elaboration of the first. </p>
3165
3166
3167 <p><b>Proposed resolution:</b></p>
3168 <p>Replace 27.6.1.2.3 [istream::extractors], paragraph 13, which begins
3169 "If the function inserts no characters ..." with:</p>
3170
3171 <blockquote>
3172   <p>If the function inserts no characters, it calls
3173   <tt>setstate(failbit)</tt>, which may throw
3174   <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
3175   because it caught an exception thrown while extracting characters
3176   from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
3177   (27.4.4.3), then the caught exception is rethrown. </p>
3178 </blockquote>
3179
3180
3181
3182
3183
3184 <hr>
3185 <h3><a name="66"></a>66. Strstreambuf::setbuf</h3>
3186 <p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3187  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-18</p>
3188 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</p>
3189 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3190 <p><b>Discussion:</b></p>
3191 <p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
3192 "Performs an operation that is defined separately for each class
3193 derived from strstreambuf". This is obviously an incorrect
3194 cut-and-paste from basic_streambuf. There are no classes derived from
3195 strstreambuf. </p>
3196
3197
3198 <p><b>Proposed resolution:</b></p>
3199 <p>D.7.1.3 [depr.strstreambuf.virtuals], paragraph 19, replace the setbuf effects
3200 clause which currently says "Performs an operation that is
3201 defined separately for each class derived from strstreambuf"
3202 with:</p>
3203
3204 <blockquote>
3205   <p><b>Effects</b>: implementation defined, except that
3206   <tt>setbuf(0,0)</tt> has no effect.</p>
3207 </blockquote>
3208
3209
3210
3211
3212
3213 <hr>
3214 <h3><a name="68"></a>68. Extractors for char* should store null at end</h3>
3215 <p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3216  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1998-07-14</p>
3217 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
3218 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3219 <p><b>Discussion:</b></p>
3220 <p>Extractors for char* (27.6.1.2.3) do not store a null character
3221 after the extracted character sequence whereas the unformatted
3222 functions like get() do. Why is this?</p>
3223
3224 <p>Comment from Jerry Schwarz: There is apparently an editing
3225 glitch. You'll notice that the last item of the list of what stops
3226 extraction doesn't make any sense. It was supposed to be the line that
3227 said a null is stored.</p>
3228
3229
3230 <p><b>Proposed resolution:</b></p>
3231 <p>27.6.1.2.3 [istream::extractors], paragraph 7, change the last list
3232 item from:</p>
3233
3234 <blockquote><p>
3235   A null byte (<tt>charT()</tt>) in the next position, which may be
3236   the first position if no characters were extracted.
3237 </p></blockquote>
3238
3239 <p>to become a new paragraph which reads:</p>
3240
3241 <blockquote><p>
3242   Operator&gt;&gt; then stores a null byte (<tt>charT()</tt>) in the
3243   next position, which may be the first position if no characters were
3244   extracted.
3245 </p></blockquote>
3246
3247
3248
3249
3250
3251 <hr>
3252 <h3><a name="69"></a>69. Must elements of a vector be contiguous?</h3>
3253 <p><b>Section:</b> 23.2.5 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3254  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1998-07-29</p>
3255 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
3256 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3257 <p><b>Discussion:</b></p>
3258 <p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
3259
3260 <p>(Please note that this is entirely separate from the question of
3261 whether a vector iterator is required to be a pointer; the answer to
3262 that question is clearly "no," as it would rule out
3263 debugging implementations)</p>
3264
3265
3266 <p><b>Proposed resolution:</b></p>
3267 <p>Add the following text to the end of 23.2.5 [vector],
3268 paragraph 1. </p>
3269
3270 <blockquote>
3271   <p>The elements of a vector are stored contiguously, meaning that if
3272   v is a <tt>vector&lt;T, Allocator&gt;</tt> where T is some type
3273   other than <tt>bool</tt>, then it obeys the identity <tt>&amp;v[n]
3274   == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt; v.size()</tt>.</p>
3275 </blockquote>
3276
3277
3278 <p><b>Rationale:</b></p>
3279 <p>The LWG feels that as a practical matter the answer is clearly
3280 "yes".  There was considerable discussion as to the best way
3281 to express the concept of "contiguous", which is not
3282 directly defined in the standard.  Discussion included:</p>
3283
3284 <ul>
3285   <li>An operational definition similar to the above proposed resolution is
3286     already used for valarray (26.5.2.3 [valarray.access]).</li>
3287   <li>There is no need to explicitly consider a user-defined operator&amp;
3288     because elements must be copyconstructible (23.1 [container.requirements] para 3)
3289     and copyconstructible (20.1.1 [utility.arg.requirements]) specifies
3290     requirements for operator&amp;.</li>
3291   <li>There is no issue of one-past-the-end because of language rules.</li>
3292 </ul>
3293
3294
3295
3296
3297
3298 <hr>
3299 <h3><a name="70"></a>70. Uncaught_exception() missing throw() specification</h3>
3300 <p><b>Section:</b> 18.7 [support.exception], 18.7.4 [uncaught] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3301  <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-08-03</p>
3302 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.exception">issues</a> in [support.exception].</p>
3303 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3304 <p><b>Discussion:</b></p>
3305 <p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
3306
3307 <p>uncaught_exception() doesn't have a throw specification.</p>
3308
3309 <p>It is intentional ? Does it means that one should be prepared to
3310 handle exceptions thrown from uncaught_exception() ?</p>
3311
3312 <p>uncaught_exception() is called in exception handling contexts where
3313 exception safety is very important.</p>
3314
3315
3316 <p><b>Proposed resolution:</b></p>
3317 <p>In 15.5.3 [except.uncaught], paragraph 1, 18.7 [support.exception],
3318 and 18.7.4 [uncaught], add "throw()" to uncaught_exception().</p>
3319
3320
3321
3322
3323 <hr>
3324 <h3><a name="71"></a>71. Do_get_monthname synopsis missing argument</h3>
3325 <p><b>Section:</b> 22.2.5.1 [locale.time.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3326  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-13</p>
3327 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3328 <p><b>Discussion:</b></p>
3329 <p>The locale facet member <tt>time_get&lt;&gt;::do_get_monthname</tt>
3330 is described in 22.2.5.1.2 [locale.time.get.virtuals] with five arguments,
3331 consistent with do_get_weekday and with its specified use by member
3332 get_monthname. However, in the synopsis, it is specified instead with
3333 four arguments. The missing argument is the "end" iterator
3334 value.</p>
3335
3336
3337 <p><b>Proposed resolution:</b></p>
3338 <p>In 22.2.5.1 [locale.time.get], add an "end" argument to
3339 the declaration of member do_monthname as follows:</p>
3340
3341 <pre>  virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&amp;,
3342                                      ios_base::iostate&amp; err, tm* t) const;</pre>
3343
3344
3345
3346
3347 <hr>
3348 <h3><a name="74"></a>74. Garbled text for <tt>codecvt::do_max_length</tt></h3>
3349 <p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3350  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-09-08</p>
3351 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
3352 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3353 <p><b>Discussion:</b></p>
3354 <p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
3355 clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
3356 parentheses and a spurious <b>n</b>.</p>
3357
3358
3359 <p><b>Proposed resolution:</b></p>
3360 <p>Replace 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 11 with the
3361 following:</p>
3362
3363 <blockquote><p>
3364   <b>Returns</b>: The maximum value that
3365   <tt>do_length(state, from, from_end, 1)</tt> can return for any
3366   valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
3367   <tt>state</tt>. The specialization <tt>codecvt&lt;char, char,
3368   mbstate_t&gt;::do_max_length()</tt> returns 1.
3369 </p></blockquote>
3370
3371
3372
3373
3374 <hr>
3375 <h3><a name="75"></a>75. Contradiction in <tt>codecvt::length</tt>'s argument types</h3>
3376 <p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3377  <b>Submitter:</b>  Matt
3378 Austern <b>Date:</b> 1998-09-18</p>
3379 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
3380 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3381 <p><b>Discussion:</b></p>
3382 <p>The class synopses for classes <tt>codecvt&lt;&gt;</tt> (22.2.1.5)
3383 and <tt>codecvt_byname&lt;&gt;</tt> (22.2.1.6) say that the first
3384 parameter of the member functions <tt>length</tt> and
3385 <tt>do_length</tt> is of type <tt>const stateT&amp;</tt>. The member
3386 function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
3387 paragraph 9) say that the type is <tt>stateT&amp;</tt>.  Either the
3388 synopsis or the summary must be changed. </p>
3389
3390 <p>If (as I believe) the member function descriptions are correct,
3391 then we must also add text saying how <tt>do_length</tt> changes its
3392 <tt>stateT</tt> argument. </p>
3393
3394
3395 <p><b>Proposed resolution:</b></p>
3396 <p>In 22.2.1.4 [locale.codecvt], and also in 22.2.1.5 [locale.codecvt.byname],
3397 change the <tt>stateT</tt> argument type on both member
3398 <tt>length()</tt> and member <tt>do_length()</tt> from </p>
3399
3400 <blockquote>
3401   <p><tt>const stateT&amp;</tt></p>
3402 </blockquote>
3403
3404 <p>to</p>
3405
3406 <blockquote>
3407   <p><tt>stateT&amp;</tt></p>
3408 </blockquote>
3409
3410 <p>In 22.2.1.4.2 [locale.codecvt.virtuals], add to the definition for member
3411 <tt>do_length</tt> a paragraph:</p>
3412
3413 <blockquote>
3414   <p>Effects: The effect on the <tt>state</tt> argument is ``as if''
3415   it called <tt>do_in(state, from, from_end, from, to, to+max,
3416   to)</tt> for <tt>to</tt> pointing to a buffer of at least
3417   <tt>max</tt> elements.</p>
3418 </blockquote>
3419
3420
3421
3422
3423 <hr>
3424 <h3><a name="76"></a>76. Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3>
3425 <p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
3426  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-09-25</p>
3427 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
3428 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
3429 <p><b>Discussion:</b></p>
3430 <p>This issue concerns the requirements on classes derived from
3431 <tt>codecvt</tt>, including user-defined classes. What are the
3432 restrictions on the conversion from external characters
3433 (e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
3434 Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
3435 the I/O library make? </p>
3436
3437 <p>The question is whether it's possible to convert from internal
3438 characters to external characters one internal character at a time,
3439 and whether, given a valid sequence of external characters, it's
3440 possible to pick off internal characters one at a time. Or, to put it
3441 differently: given a sequence of external characters and the
3442 corresponding sequence of internal characters, does a position in the
3443 internal sequence correspond to some position in the external
3444 sequence? </p>
3445
3446 <p>To make this concrete, suppose that <tt>[first, last)</tt> is a
3447 sequence of <i>M</i> external characters and that <tt>[ifirst,
3448 ilast)</tt> is the corresponding sequence of <i>N</i> internal
3449 characters, where <i>N &gt; 1</i>. That is, <tt>my_encoding.in()</tt>,
3450 applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
3451 ilast)</tt>. Now the question: does there necessarily exist a
3452 subsequence of external characters, <tt>[first, last_1)</tt>, such
3453 that the corresponding sequence of internal characters is the single
3454 character <tt>*ifirst</tt>?
3455 </p>
3456
3457 <p>(What a "no" answer would mean is that
3458 <tt>my_encoding</tt> translates sequences only as blocks. There's a
3459 sequence of <i>M</i> external characters that maps to a sequence of
3460 <i>N</i> internal characters, but that external sequence has no
3461 subsequence that maps to <i>N-1</i> internal characters.) </p>
3462
3463 <p>Some of the wording in the standard, such as the description of
3464 <tt>codecvt::do_max_length</tt> (22.2.1.4.2 [locale.codecvt.virtuals],
3465 paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.8.1.5 [filebuf.virtuals], paragraph 3) suggests that it must always be
3466 possible to pick off internal characters one at a time from a sequence
3467 of external characters. However, this is never explicitly stated one
3468 way or the other. </p>
3469
3470 <p>This issue seems (and is) quite technical, but it is important if
3471 we expect users to provide their own encoding facets. This is an area
3472 where the standard library calls user-supplied code, so a well-defined
3473 set of requirements for the user-supplied code is crucial. Users must
3474 be aware of the assumptions that the library makes. This issue affects
3475 positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
3476 and several of <tt>codecvt</tt>'s member functions. </p>
3477
3478
3479 <p><b>Proposed resolution:</b></p>
3480 <p>Add the following text as a new paragraph, following 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 2:</p>
3481
3482 <blockquote>
3483 <p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
3484 (27.8 [file.streams]) must have the property that if</p>
3485 <pre>    do_out(state, from, from_end, from_next, to, to_lim, to_next)
3486 </pre>
3487 <p>would return <tt>ok</tt>, where <tt>from != from_end</tt>, then </p>
3488 <pre>    do_out(state, from, from + 1, from_next, to, to_end, to_next)
3489 </pre>
3490 <p>must also return <tt>ok</tt>, and that if</p>
3491 <pre>    do_in(state, from, from_end, from_next, to, to_lim, to_next)
3492 </pre>
3493 <p>would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then</p>
3494 <pre>    do_in(state, from, from_end, from_next, to, to + 1, to_next)
3495 </pre>
3496 <p>must also return <tt>ok</tt>.  [<i>Footnote:</i> Informally, this
3497 means that <tt>basic_filebuf</tt> assumes that the mapping from
3498 internal to external characters is 1 to N: a <tt>codecvt</tt> that is
3499 used by <tt>basic_filebuf</tt> must be able to translate characters
3500 one internal character at a time.  <i>--End Footnote</i>]</p>
3501 </blockquote>
3502
3503 <p><i>[Redmond: Minor change in proposed resolution.  Original
3504 proposed resolution talked about "success", with a parenthetical
3505 comment that success meant returning <tt>ok</tt>.  New wording
3506 removes all talk about "success", and just talks about the
3507 return value.]</i></p>
3508
3509
3510
3511
3512 <p><b>Rationale:</b></p>
3513
3514   <p>The proposed resoluion says that conversions can be performed one
3515   internal character at a time.  This rules out some encodings that
3516   would otherwise be legal.  The alternative answer would mean there
3517   would be some internal positions that do not correspond to any
3518   external file position.</p>
3519   <p>
3520   An example of an encoding that this rules out is one where the
3521   <tt>internT</tt> and <tt>externT</tt> are of the same type, and
3522   where the internal sequence <tt>c1 c2</tt> corresponds to the
3523   external sequence <tt>c2 c1</tt>.
3524   </p>
3525   <p>It was generally agreed that <tt>basic_filebuf</tt> relies
3526   on this property: it was designed under the assumption that
3527   the external-to-internal mapping is N-to-1, and it is not clear
3528   that <tt>basic_filebuf</tt> is implementable without that
3529   restriction.
3530   </p>
3531   <p>
3532   The proposed resolution is expressed as a restriction on
3533   <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
3534   than a blanket restriction on all <tt>codecvt</tt> facets,
3535   because <tt>basic_filebuf</tt> is the only other part of the
3536   library that uses <tt>codecvt</tt>.  If a user wants to define
3537   a <tt>codecvt</tt> facet that implements a more general N-to-M
3538   mapping, there is no reason to prohibit it, so long as the user
3539   does not expect <tt>basic_filebuf</tt> to be able to use it.
3540   </p>
3541
3542
3543
3544
3545
3546 <hr>
3547 <h3><a name="78"></a>78. Typo: event_call_back</h3>
3548 <p><b>Section:</b> 27.4.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3549  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3550 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</p>
3551 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3552 <p><b>Discussion:</b></p>
3553 <p>typo: event_call_back should be event_callback &nbsp; </p>
3554
3555
3556 <p><b>Proposed resolution:</b></p>
3557 <p>In the 27.4.2 [ios.base] synopsis change
3558 "event_call_back" to "event_callback". </p>
3559
3560
3561
3562
3563 <hr>
3564 <h3><a name="79"></a>79. Inconsistent declaration of polar()</h3>
3565 <p><b>Section:</b> 26.3.1 [complex.synopsis], 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3566  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3567 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.synopsis">issues</a> in [complex.synopsis].</p>
3568 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3569 <p><b>Discussion:</b></p>
3570 <p>In 26.3.1 [complex.synopsis] polar is declared as follows:</p>
3571 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;); </pre>
3572
3573 <p>In 26.3.7 [complex.value.ops] it is declared as follows:</p>
3574 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
3575
3576 <p>Thus whether the second parameter is optional is not clear. </p>
3577
3578
3579 <p><b>Proposed resolution:</b></p>
3580 <p>In 26.3.1 [complex.synopsis] change:</p>
3581 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;);</pre>
3582
3583 <p>to:</p>
3584 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
3585
3586
3587
3588
3589
3590 <hr>
3591 <h3><a name="80"></a>80. Global Operators of complex declared twice</h3>
3592 <p><b>Section:</b> 26.3.1 [complex.synopsis], 26.3.2 [complex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3593  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3594 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.synopsis">issues</a> in [complex.synopsis].</p>
3595 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3596 <p><b>Discussion:</b></p>
3597 <p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
3598 class complex. This redundancy should be removed.</p>
3599
3600
3601 <p><b>Proposed resolution:</b></p>
3602 <p>Reduce redundancy according to the general style of the standard. </p>
3603
3604
3605
3606
3607 <hr>
3608 <h3><a name="83"></a>83. String::npos vs. string::max_size()</h3>
3609 <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3610  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3611 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
3612 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3613 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#89">89</a></p>
3614 <p><b>Discussion:</b></p>
3615 <p>Many string member functions throw if size is getting or exceeding
3616 npos. However, I wonder why they don't throw if size is getting or
3617 exceeding max_size() instead of npos.  May be npos is known at compile
3618 time, while max_size() is known at runtime. However, what happens if
3619 size exceeds max_size() but not npos, then? It seems the standard
3620 lacks some clarifications here.</p>
3621
3622
3623 <p><b>Proposed resolution:</b></p>
3624 <p>After 21.3 [basic.string] paragraph 4 ("The functions
3625 described in this clause...") add a new paragraph:</p>
3626
3627 <blockquote>
3628   <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
3629   <tt> max_size()</tt> then
3630   the operation throws <tt>length_error</tt>.</p>
3631 </blockquote>
3632
3633
3634 <p><b>Rationale:</b></p>
3635 <p>The LWG believes length_error is the correct exception to throw.</p>
3636
3637
3638
3639
3640 <hr>
3641 <h3><a name="86"></a>86. String constructors don't describe exceptions</h3>
3642 <p><b>Section:</b> 21.3.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3643  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3644 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
3645 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3646 <p><b>Discussion:</b></p>
3647 <p>The constructor from a range:</p>
3648
3649 <pre>template&lt;class InputIterator&gt;
3650          basic_string(InputIterator begin, InputIterator end,
3651                       const Allocator&amp; a = Allocator());</pre>
3652
3653 <p>lacks a throws clause. However, I would expect that it throws
3654 according to the other constructors if the numbers of characters in
3655 the range equals npos (or exceeds max_size(), see above). </p>
3656
3657
3658 <p><b>Proposed resolution:</b></p>
3659 <p>In 21.3.1 [string.require], Strike throws paragraphs for
3660 constructors which say "Throws: length_error if n ==
3661 npos."</p>
3662
3663
3664 <p><b>Rationale:</b></p>
3665 <p>Throws clauses for length_error if n == npos are no longer needed
3666 because they are subsumed by the general wording added by the
3667 resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
3668
3669
3670
3671
3672 <hr>
3673 <h3><a name="90"></a>90. Incorrect description of operator &gt;&gt; for strings</h3>
3674 <p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3675  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3676 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
3677 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3678 <p><b>Discussion:</b></p>
3679 <p>The effect of operator &gt;&gt; for strings contain the following item:</p>
3680
3681 <p>&nbsp;&nbsp;&nbsp; <tt>isspace(c,getloc())</tt> is true for the next available input
3682 character c.</p>
3683
3684 <p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
3685
3686
3687 <p><b>Proposed resolution:</b></p>
3688 <p>In 21.3.8.9 [string.io] paragraph 1 Effects clause replace:</p>
3689
3690 <blockquote>
3691   <p><tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
3692 </blockquote>
3693
3694 <p>with:</p>
3695
3696 <blockquote>
3697   <p><tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
3698 </blockquote>
3699
3700
3701
3702
3703
3704 <hr>
3705 <h3><a name="91"></a>91. Description of operator&gt;&gt; and getline() for string&lt;&gt; might cause endless loop</h3>
3706 <p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
3707  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3708 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
3709 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
3710 <p><b>Discussion:</b></p>
3711 <p>Operator &gt;&gt; and getline() for strings read until eof()
3712 in the input stream is true. However, this might never happen, if the
3713 stream can't read anymore without reaching EOF. So shouldn't it be
3714 changed into that it reads until !good() ? </p>
3715
3716
3717 <p><b>Proposed resolution:</b></p>
3718 <p>In 21.3.8.9 [string.io], paragraph 1, replace:</p>
3719 <blockquote><p>
3720 Effects: Begins by constructing a sentry object k as if k were
3721 constructed by typename basic_istream&lt;charT,traits&gt;::sentry k( is). If
3722 bool( k) is true, it calls str.erase() and then extracts characters
3723 from is and appends them to str as if by calling str.append(1, c). If
3724 is.width() is greater than zero, the maximum number n of characters
3725 appended is is.width(); otherwise n is str.max_size(). Characters are
3726 extracted and appended until any of the following occurs:
3727 </p></blockquote>
3728 <p>with:</p>
3729 <blockquote><p>
3730 Effects: Behaves as a formatted input function (27.6.1.2.1
3731 [istream.formatted.reqmts]). After constructing a sentry object, if the
3732 sentry converts to true, calls str.erase() and then extracts
3733 characters from is and appends them to str as if by calling
3734 str.append(1,c). If is.width() is greater than zero, the maximum
3735 number n of characters appended is is.width(); otherwise n is
3736 str.max_size(). Characters are extracted and appended until any of the
3737 following occurs:
3738 </p></blockquote>
3739
3740 <p>In 21.3.8.9 [string.io], paragraph 6, replace</p>
3741 <blockquote><p>
3742 Effects: Begins by constructing a sentry object k as if by typename
3743 basic_istream&lt;charT,traits&gt;::sentry k( is, true). If bool( k) is true,
3744 it calls str.erase() and then extracts characters from is and appends
3745 them to str as if by calling str.append(1, c) until any of the
3746 following occurs:
3747 </p></blockquote>
3748 <p>with:</p>
3749 <blockquote><p>Effects: Behaves as an unformatted input function
3750 (27.6.1.3 [istream.unformatted]), except that it does not affect the
3751 value returned
3752 by subsequent calls to basic_istream&lt;&gt;::gcount(). After
3753 constructing a sentry object, if the sentry converts to true, calls
3754 str.erase() and then extracts characters from is and appends them to
3755 str as if by calling str.append(1,c) until any of the following
3756 occurs:
3757 </p></blockquote>
3758
3759 <p><i>[Redmond: Made changes in proposed resolution.  <tt>operator&gt;&gt;</tt>
3760 should be a formatted input function, not an unformatted input function.
3761 <tt>getline</tt> should not be required to set <tt>gcount</tt>, since
3762 there is no mechanism for <tt>gcount</tt> to be set except by one of
3763 <tt>basic_istream</tt>'s member functions.]</i></p>
3764
3765
3766 <p><i>[Curaçao: Nico agrees with proposed resolution.]</i></p>
3767
3768
3769
3770
3771 <p><b>Rationale:</b></p>
3772 <p>The real issue here is whether or not these string input functions
3773 get their characters from a streambuf, rather than by calling an
3774 istream's member functions, a streambuf signals failure either by
3775 returning eof or by throwing an exception; there are no other
3776 possibilities.  The proposed resolution makes it clear that these two
3777 functions do get characters from a streambuf.</p>
3778
3779
3780
3781
3782
3783 <hr>
3784 <h3><a name="92"></a>92. Incomplete Algorithm Requirements</h3>
3785 <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
3786  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3787 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
3788 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
3789 <p><b>Discussion:</b></p>
3790 <p>The standard does not state, how often a function object is copied,
3791 called, or the order of calls inside an algorithm. This may lead to
3792 surprising/buggy behavior. Consider the following example: </p>
3793
3794 <pre>class Nth {    // function object that returns true for the nth element
3795   private:
3796     int nth;     // element to return true for
3797     int count;   // element counter
3798   public:
3799     Nth (int n) : nth(n), count(0) {
3800     }
3801     bool operator() (int) {
3802         return ++count == nth;
3803     }
3804 };
3805 ....
3806 // remove third element
3807     list&lt;int&gt;::iterator pos;
3808     pos = remove_if(coll.begin(),coll.end(),  // range
3809                     Nth(3)),                  // remove criterion
3810     coll.erase(pos,coll.end()); </pre>
3811
3812 <p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
3813 happens because the usual implementation of the algorithm copies the
3814 function object internally: </p>
3815
3816 <pre>template &lt;class ForwIter, class Predicate&gt;
3817 ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op)
3818 {
3819     beg = find_if(beg, end, op);
3820     if (beg == end) {
3821         return beg;
3822     }
3823     else {
3824         ForwIter next = beg;
3825         return remove_copy_if(++next, end, beg, op);
3826     }
3827 } </pre>
3828
3829 <p>The algorithm uses find_if() to find the first element that should
3830 be removed. However, it then uses a copy of the passed function object
3831 to process the resulting elements (if any). Here, Nth is used again
3832 and removes also the sixth element. This behavior compromises the
3833 advantage of function objects being able to have a state. Without any
3834 cost it could be avoided (just implement it directly instead of
3835 calling find_if()). </p>
3836
3837
3838 <p><b>Proposed resolution:</b></p>
3839
3840 <p>Add a new paragraph following 25 [algorithms] paragraph 8:</p>
3841 <blockquote><p>
3842 [Note: Unless otherwise specified, algorithms that take function
3843 objects as arguments are permitted to copy those function objects
3844 freely.  Programmers for whom object identity is important should
3845 consider using a wrapper class that points to a noncopied
3846 implementation object, or some equivalent solution.]
3847 </p></blockquote>
3848
3849 <p><i>[Dublin: Pete Becker felt that this may not be a defect,
3850 but rather something that programmers need to be educated about.
3851 There was discussion of adding wording to the effect that the number
3852 and order of calls to function objects, including predicates, not
3853 affect the behavior of the function object.]</i></p>
3854
3855
3856 <p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
3857 have a clear statement of "predicate" in the
3858 standard. People including me seemed to think "a function
3859 returning a Boolean value and being able to be called by an STL
3860 algorithm or be used as sorting criterion or ... is a
3861 predicate". But a predicate has more requirements: It should
3862 never change its behavior due to a call or being copied. IMHO we have
3863 to state this in the standard. If you like, see section 8.1.4 of my
3864 library book for a detailed discussion.]</i></p>
3865
3866
3867 <p><i>[Kona: Nico will provide wording to the effect that "unless
3868 otherwise specified, the number of copies of and calls to function
3869 objects by algorithms is unspecified".&nbsp; Consider placing in
3870 25 [algorithms] after paragraph 9.]</i></p>
3871
3872
3873 <p><i>[Santa Cruz: The standard doesn't currently guarantee that
3874   functions object won't be copied, and what isn't forbidden is
3875   allowed.  It is believed (especially since implementations that were
3876   written in concert with the standard do make copies of function
3877   objects) that this was intentional.  Thus, no normative change is
3878   needed.  What we should put in is a non-normative note suggesting to
3879   programmers that if they want to guarantee the lack of copying they
3880   should use something like the <tt>ref</tt> wrapper.]</i></p>
3881
3882
3883 <p><i>[Oxford: Matt provided wording.]</i></p>
3884
3885
3886
3887
3888
3889
3890
3891
3892 <hr>
3893 <h3><a name="98"></a>98. Input iterator requirements are badly written</h3>
3894 <p><b>Section:</b> 24.1.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
3895  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
3896 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
3897 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
3898 <p><b>Discussion:</b></p>
3899 <p>Table 72 in 24.1.1 [input.iterators] specifies semantics for
3900 <tt>*r++</tt> of:</p>
3901
3902 <p>&nbsp;&nbsp; <tt>{ T tmp = *r; ++r; return tmp; }</tt></p>
3903
3904 <p>There are two problems with this.  First, the return type is
3905 specified to be "T", as opposed to something like "convertible to T".
3906 This is too specific: we want to allow *r++ to return an lvalue.</p>
3907
3908 <p>Second, writing the semantics in terms of code misleadingly
3909 suggests that the effects *r++ should precisely replicate the behavior
3910 of this code, including side effects.  (Does this mean that *r++
3911 should invoke the copy constructor exactly as many times as the sample
3912 code above would?) See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a> for a similar
3913 problem.</p>
3914
3915
3916
3917 <p><b>Proposed resolution:</b></p>
3918 <p>In Table 72 in 24.1.1 [input.iterators], change the return type
3919 for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".</p>
3920
3921
3922 <p><b>Rationale:</b></p>
3923 <p>This issue has two parts: the return type, and the number of times
3924   the copy constructor is invoked.</p>
3925
3926 <p>The LWG believes the the first part is a real issue.  It's
3927   inappropriate for the return type to be specified so much more
3928   precisely for *r++ than it is for *r.  In particular, if r is of
3929   (say) type <tt>int*</tt>, then *r++ isn't <tt>int</tt>,
3930   but <tt>int&amp;</tt>.</p>
3931
3932 <p>The LWG does not believe that the number of times the copy
3933   constructor is invoked is a real issue.  This can vary in any case,
3934   because of language rules on copy constructor elision.  That's too
3935   much to read into these semantics clauses.</p>
3936
3937 <p>Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since
3938    we're told (24.1/3) that forward iterators satisfy all the requirements
3939    of input iterators, we can't impose any requirements in the Input
3940    Iterator requirements table that forward iterators don't satisfy.</p>
3941
3942
3943
3944
3945
3946 <hr>
3947 <h3><a name="103"></a>103. set::iterator is required to be modifiable, but this allows modification of keys</h3>
3948 <p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
3949  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
3950 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
3951 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
3952 <p><b>Discussion:</b></p>
3953 <p>Set::iterator is described as implementation-defined with a
3954 reference to the container requirement; the container requirement says
3955 that const_iterator is an iterator pointing to const T and iterator an
3956 iterator pointing to T.</p>
3957
3958 <p>23.1.2 paragraph 2 implies that the keys should not be modified to
3959 break the ordering of elements. But that is not clearly
3960 specified. Especially considering that the current standard requires
3961 that iterator for associative containers be different from
3962 const_iterator. Set, for example, has the following: </p>
3963
3964 <p><tt>typedef implementation defined iterator;<br>
3965 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // See _lib.container.requirements_</tt></p>
3966
3967 <p>23.1 [container.requirements] actually requires that iterator type pointing
3968 to T (table 65). Disallowing user modification of keys by changing the
3969 standard to require an iterator for associative container to be the
3970 same as const_iterator would be overkill since that will unnecessarily
3971 significantly restrict the usage of associative container. A class to
3972 be used as elements of set, for example, can no longer be modified
3973 easily without either redesigning the class (using mutable on fields
3974 that have nothing to do with ordering), or using const_cast, which
3975 defeats requiring iterator to be const_iterator. The proposed solution
3976 goes in line with trusting user knows what he is doing. </p>
3977
3978 <p><b>Other Options Evaluated:</b> </p>
3979
3980 <p>Option A.&nbsp;&nbsp; In 23.1.2 [associative.reqmts], paragraph 2, after
3981 first sentence, and before "In addition,...", add one line:
3982 </p>
3983
3984 <blockquote>
3985   <p>Modification of keys shall not change their strict weak ordering. </p>
3986 </blockquote>
3987
3988 <p>Option B.&nbsp;Add three new sentences to 23.1.2 [associative.reqmts]:</p>
3989
3990 <blockquote>
3991   <p>At the end of paragraph 5: "Keys in an associative container
3992   are immutable." At the end of paragraph 6: "For
3993   associative containers where the value type is the same as the key
3994   type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
3995   constant iterators. It is unspecified whether or not
3996   <tt>iterator</tt> and <tt>const_iterator</tt> are the same
3997   type."</p>
3998 </blockquote>
3999
4000 <p>Option C.&nbsp;To 23.1.2 [associative.reqmts], paragraph 3, which
4001 currently reads:</p>
4002
4003 <blockquote>
4004   <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
4005   comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
4006   container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
4007   == false &amp;&amp; comp(k2, k1) == false.</p>
4008 </blockquote>
4009
4010 <p>&nbsp; add the following:</p>
4011
4012 <blockquote>
4013   <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
4014   value whenever it is evaluated. [Note: If k2 is removed from the container and later
4015   reinserted, comp(k1, k2) must still return a consistent value but this value may be
4016   different than it was the first time k1 and k2 were in the same container. This is
4017   intended to allow usage like a string key that contains a filename, where comp compares
4018   file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
4019   reinserted, comp(k1, k2) must again return a consistent value but this value may be
4020   different than it was the previous time k2 was in the container.]</p>
4021 </blockquote>
4022
4023
4024
4025 <p><b>Proposed resolution:</b></p>
4026 <p>Add the following to 23.1.2 [associative.reqmts] at
4027 the indicated location:</p>
4028
4029 <blockquote>
4030   <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
4031   calling comp(k1, k2) shall always return the same
4032   value."</p>
4033   <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
4034   <p>At the end of paragraph 6: "For associative containers where the value type is the
4035   same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
4036   iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
4037   are the same type."</p>
4038 </blockquote>
4039
4040
4041 <p><b>Rationale:</b></p>
4042 <p>Several arguments were advanced for and against allowing set elements to be
4043 mutable as long as the ordering was not effected. The argument which swayed the
4044 LWG was one of safety; if elements were mutable, there would be no compile-time
4045 way to detect of a simple user oversight which caused ordering to be
4046 modified.  There was a report that this had actually happened in practice,
4047 and had been painful to diagnose.  If users need to modify elements,
4048 it is possible to use mutable members or const_cast.</p>
4049
4050 <p>Simply requiring that keys be immutable is not sufficient, because the comparison
4051 object may indirectly (via pointers) operate on values outside of the keys.</p>
4052
4053 <p>
4054 The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
4055 to be different types to allow for potential future work in which some
4056 member functions might be overloaded between the two types.  No such
4057 member functions exist now, and the LWG believes that user functionality
4058 will not be impaired by permitting the two types to be the same.  A
4059 function that operates on both iterator types can be defined for
4060 <tt>const_iterator</tt> alone, and can rely on the automatic
4061 conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
4062 </p>
4063
4064 <p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
4065
4066
4067
4068
4069
4070
4071 <hr>
4072 <h3><a name="106"></a>106. Numeric library private members are implementation defined</h3>
4073 <p><b>Section:</b> 26.5.5 [template.slice.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4074  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
4075 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.slice.array">issues</a> in [template.slice.array].</p>
4076 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4077 <p><b>Discussion:</b></p>
4078 <p>This is the only place in the whole standard where the implementation has to document
4079 something private.</p>
4080
4081
4082 <p><b>Proposed resolution:</b></p>
4083 <p>
4084 Remove the comment which says "// remainder implementation defined" from:
4085 </p>
4086
4087 <ul>
4088   <li>26.5.5 [template.slice.array]</li>
4089   <li>26.5.7 [template.gslice.array]</li>
4090   <li>26.5.8 [template.mask.array]</li>
4091   <li>26.5.9 [template.indirect.array]</li>
4092 </ul>
4093
4094
4095
4096
4097
4098 <hr>
4099 <h3><a name="108"></a>108. Lifetime of exception::what() return unspecified</h3>
4100 <p><b>Section:</b> 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4101  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
4102 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#type.info">issues</a> in [type.info].</p>
4103 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4104 <p><b>Discussion:</b></p>
4105 <p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
4106 exception::what() is left unspecified. This issue has implications
4107 with exception safety of exception handling: some exceptions should
4108 not throw bad_alloc.</p>
4109
4110
4111 <p><b>Proposed resolution:</b></p>
4112 <p>Add to 18.6.1 [type.info] paragraph 9 (exception::what notes
4113 clause) the sentence:</p>
4114
4115 <blockquote>
4116   <p>The return value remains valid until the exception object from which it is obtained is
4117   destroyed or a non-const member function of the exception object is called.</p>
4118 </blockquote>
4119
4120
4121 <p><b>Rationale:</b></p>
4122 <p>If an exception object has non-const members, they may be used
4123 to set internal state that should affect the contents of the string
4124 returned by <tt>what()</tt>.
4125 </p>
4126
4127
4128
4129
4130
4131 <hr>
4132 <h3><a name="109"></a>109. Missing binders for non-const sequence elements</h3>
4133 <p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
4134  <b>Submitter:</b> Bjarne Stroustrup <b>Date:</b> 1998-10-07</p>
4135 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
4136 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
4137 <p><b>Discussion:</b></p>
4138
4139 <p>There are no versions of binders that apply to non-const elements
4140 of a sequence. This makes examples like for_each() using bind2nd() on
4141 page 521 of "The C++ Programming Language (3rd)"
4142 non-conforming. Suitable versions of the binders need to be added.</p>
4143
4144 <p>Further discussion from Nico:</p>
4145
4146 <p>What is probably meant here is shown in the following example:</p>
4147
4148 <pre>class Elem {
4149   public:
4150     void print (int i) const { }
4151     void modify (int i) { }
4152 }; </pre>
4153 <pre>int main()
4154 {
4155     vector&lt;Elem&gt; coll(2);
4156     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::print),42));    // OK
4157     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::modify),42));   // ERROR
4158 }</pre>
4159
4160 <p>The error results from the fact that bind2nd() passes its first
4161 argument (the argument of the sequence) as constant reference. See the
4162 following typical implementation:</p>
4163
4164 <blockquote>
4165   <pre>template &lt;class Operation&gt;
4166 class binder2nd
4167   : public unary_function&lt;typename Operation::first_argument_type,
4168                           typename Operation::result_type&gt; {
4169 protected:
4170   Operation op;
4171   typename Operation::second_argument_type value;
4172 public:
4173   binder2nd(const Operation&amp; o,
4174             const typename Operation::second_argument_type&amp; v)
4175       : op(o), value(v) {} </pre>
4176   <pre> typename Operation::result_type
4177   operator()(const typename Operation::first_argument_type&amp; x) const {
4178     return op(x, value);
4179   }
4180 };</pre>
4181 </blockquote>
4182
4183 <p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
4184
4185 <blockquote>
4186   <pre>template &lt;class Operation&gt;
4187 class binder2nd
4188   : public unary_function&lt;typename Operation::first_argument_type,
4189                           typename Operation::result_type&gt; {
4190 protected:
4191   Operation op;
4192   typename Operation::second_argument_type value;
4193 public:
4194   binder2nd(const Operation&amp; o,
4195             const typename Operation::second_argument_type&amp; v)
4196       : op(o), value(v) {} </pre>
4197   <pre> typename Operation::result_type
4198   operator()(const typename Operation::first_argument_type&amp; x) const {
4199     return op(x, value);
4200   }
4201   typename Operation::result_type
4202   operator()(typename Operation::first_argument_type&amp; x) const {
4203     return op(x, value);
4204   }
4205 };</pre>
4206 </blockquote>
4207
4208
4209 <p><b>Proposed resolution:</b></p>
4210
4211 <p><b>Howard believes there is a flaw</b> in this resolution.
4212 See c++std-lib-9127.  We may need to reopen this issue.</p>
4213
4214 <p>In D.8 [depr.lib.binders] in the declaration of binder1st after:</p>
4215 <blockquote>
4216   <p><tt>typename Operation::result_type<br>
4217   &nbsp;operator()(const typename Operation::second_argument_type&amp; x) const;</tt></p>
4218 </blockquote>
4219 <p>insert:</p>
4220 <blockquote>
4221   <p><tt>typename Operation::result_type<br>
4222   &nbsp;operator()(typename Operation::second_argument_type&amp; x) const;</tt></p>
4223 </blockquote>
4224 <p>In D.8 [depr.lib.binders] in the declaration of binder2nd after:</p>
4225 <blockquote>
4226   <p><tt>typename Operation::result_type<br>
4227   &nbsp;operator()(const typename Operation::first_argument_type&amp; x) const;</tt></p>
4228 </blockquote>
4229 <p>insert:</p>
4230 <blockquote>
4231   <p><tt>typename Operation::result_type<br>
4232   &nbsp;operator()(typename Operation::first_argument_type&amp; x) const;</tt></p>
4233 </blockquote>
4234
4235 <p><i>[Kona: The LWG discussed this at some length.It was agreed that
4236 this is a mistake in the design, but there was no consensus on whether
4237 it was a defect in the Standard.  Straw vote: NAD - 5.  Accept
4238 proposed resolution - 3.  Leave open - 6.]</i></p>
4239
4240
4241 <p><i>[Copenhagen: It was generally agreed that this was a defect.
4242 Strap poll: NAD - 0.  Accept proposed resolution - 10.
4243 Leave open - 1.]</i></p>
4244
4245
4246
4247
4248
4249
4250
4251 <hr>
4252 <h3><a name="110"></a>110. istreambuf_iterator::equal not const</h3>
4253 <p><b>Section:</b> 24.5.3 [istreambuf.iterator], 24.5.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4254  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-10-15</p>
4255 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p>
4256 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4257 <p><b>Discussion:</b></p>
4258 <p>Member istreambuf_iterator&lt;&gt;::equal is not declared
4259 "const", yet 24.5.3.6 [istreambuf.iterator::op==] says that operator==,
4260 which is const, calls it. This is contradictory. </p>
4261
4262
4263 <p><b>Proposed resolution:</b></p>
4264 <p>In 24.5.3 [istreambuf.iterator] and also in 24.5.3.5 [istreambuf.iterator::equal],
4265 replace:</p>
4266
4267 <blockquote>
4268   <pre>bool equal(istreambuf_iterator&amp; b);</pre>
4269 </blockquote>
4270
4271 <p>with:</p>
4272
4273 <blockquote>
4274   <pre>bool equal(const istreambuf_iterator&amp; b) const;</pre>
4275 </blockquote>
4276
4277
4278
4279
4280
4281 <hr>
4282 <h3><a name="112"></a>112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3>
4283 <p><b>Section:</b> 24.5.4.1 [ostreambuf.iter.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4284  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-10-20</p>
4285 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4286 <p><b>Discussion:</b></p>
4287 <p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
4288 constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
4289 reads "<i>s</i> is not null". However, <i>s</i> is a
4290 reference, and references can't be null. </p>
4291
4292
4293 <p><b>Proposed resolution:</b></p>
4294 <p>In 24.5.4.1 [ostreambuf.iter.cons]:</p>
4295
4296 <p>Move the current paragraph 1, which reads "Requires: s is not
4297 null.", from the first constructor to the second constructor.</p>
4298
4299 <p>Insert a new paragraph 1 Requires clause for the first constructor
4300 reading:</p>
4301
4302 <blockquote>
4303   <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
4304 </blockquote>
4305
4306
4307
4308
4309
4310 <hr>
4311 <h3><a name="114"></a>114. Placement forms example in error twice</h3>
4312 <p><b>Section:</b> 18.5.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4313  <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-10-28</p>
4314 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.placement">issues</a> in [new.delete.placement].</p>
4315 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4316 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a></p>
4317 <p><b>Discussion:</b></p>
4318 <p>Section 18.5.1.3 contains the following example: </p>
4319
4320 <pre>[Example: This can be useful for constructing an object at a known address:
4321         char place[sizeof(Something)];
4322         Something* p = new (place) Something();
4323  -end example]</pre>
4324
4325 <p>First code line: "place" need not have any special alignment, and the
4326 following constructor could fail due to misaligned data.</p>
4327
4328 <p>Second code line: Aren't the parens on Something() incorrect?&nbsp; [Dublin: the LWG
4329 believes the () are correct.]</p>
4330
4331 <p>Examples are not normative, but nevertheless should not show code that is invalid or
4332 likely to fail.</p>
4333
4334
4335 <p><b>Proposed resolution:</b></p>
4336 <p>Replace the first line of code in the example in
4337 18.5.1.3 [new.delete.placement] with:
4338 </p>
4339
4340 <blockquote>
4341   <pre>void* place = operator new(sizeof(Something));</pre>
4342 </blockquote>
4343
4344
4345
4346
4347
4348 <hr>
4349 <h3><a name="115"></a>115. Typo in strstream constructors</h3>
4350 <p><b>Section:</b> D.7.4.1 [depr.strstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4351  <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-11-02</p>
4352 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4353 <p><b>Discussion:</b></p>
4354 <p>D.7.4.1 strstream constructors paragraph 2 says: </p>
4355
4356 <blockquote>
4357   <p>Effects: Constructs an object of class strstream, initializing the base class with
4358   iostream(&amp; sb) and initializing sb with one of the two constructors: </p>
4359   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
4360   elements. The constructor is strstreambuf(s, n, s). </p>
4361   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
4362   elements that contains an NTBS whose first element is designated by s. The constructor is
4363   strstreambuf(s, n, s+std::strlen(s)).</p>
4364 </blockquote>
4365
4366 <p>Notice the second condition is the same as the first. I think the second condition
4367 should be "If mode&amp;app==app", or "mode&amp;app!=0", meaning that
4368 the append bit is set.</p>
4369
4370
4371 <p><b>Proposed resolution:</b></p>
4372 <p>In D.7.3.1 [depr.ostrstream.cons] paragraph 2 and D.7.4.1 [depr.strstream.cons]
4373 paragraph 2, change the first condition to <tt>(mode&amp;app)==0</tt>
4374 and the second condition to <tt>(mode&amp;app)!=0</tt>.</p>
4375
4376
4377
4378
4379
4380 <hr>
4381 <h3><a name="117"></a>117. <tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</h3>
4382 <p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
4383  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-11-20</p>
4384 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</p>
4385 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
4386 <p><b>Discussion:</b></p>
4387 <p>The <b>effects</b> clause for numeric inserters says that
4388 insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
4389 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
4390 int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
4391 <tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
4392 delegated to <tt>num_put</tt>, and that insertion is performed as if
4393 through the following code fragment: </p>
4394
4395 <pre>bool failed = use_facet&lt;
4396    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
4397    &gt;(getloc()).put(*this, *this, fill(), val). failed();</pre>
4398
4399 <p>This doesn't work, because <tt>num_put&lt;&gt;</tt>::put is only
4400 overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
4401 long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
4402 void*</tt>. That is, the code fragment in the standard is incorrect
4403 (it is diagnosed as ambiguous at compile time) for the types
4404 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
4405 int</tt>, and <tt>float</tt>. </p>
4406
4407 <p>We must either add new member functions to <tt>num_put</tt>, or
4408 else change the description in <tt>ostream</tt> so that it only calls
4409 functions that are actually there. I prefer the latter. </p>
4410
4411
4412 <p><b>Proposed resolution:</b></p>
4413 <p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
4414
4415 <blockquote>
4416 <p>
4417 The classes num_get&lt;&gt; and num_put&lt;&gt; handle locale-dependent numeric
4418 formatting and parsing.  These inserter functions use the imbued
4419 locale value to perform numeric formatting.  When val is of type bool,
4420 long, unsigned long, double, long double, or const void*, the
4421 formatting conversion occurs as if it performed the following code
4422 fragment:
4423 </p>
4424
4425 <pre>bool failed = use_facet&lt;
4426    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
4427    &gt;(getloc()).put(*this, *this, fill(), val). failed();
4428 </pre>
4429
4430 <p>
4431 When val is of type short the formatting conversion occurs as if it
4432 performed the following code fragment:
4433 </p>
4434
4435 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
4436 bool failed = use_facet&lt;
4437    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
4438    &gt;(getloc()).put(*this, *this, fill(),
4439       baseflags == ios_base::oct || baseflags == ios_base::hex
4440          ? static_cast&lt;long&gt;(static_cast&lt;unsigned short&gt;(val))
4441          : static_cast&lt;long&gt;(val)). failed();
4442 </pre>
4443
4444 <p>
4445 When val is of type int the formatting conversion occurs as if it performed
4446 the following code fragment:
4447 </p>
4448
4449 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
4450 bool failed = use_facet&lt;
4451    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
4452    &gt;(getloc()).put(*this, *this, fill(),
4453       baseflags == ios_base::oct || baseflags == ios_base::hex
4454          ? static_cast&lt;long&gt;(static_cast&lt;unsigned int&gt;(val))
4455          : static_cast&lt;long&gt;(val)). failed();
4456 </pre>
4457
4458 <p>
4459 When val is of type unsigned short or unsigned int the formatting conversion
4460 occurs as if it performed the following code fragment:
4461 </p>
4462
4463 <pre>bool failed = use_facet&lt;
4464    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
4465    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;unsigned long&gt;(val)).
4466 failed();
4467 </pre>
4468
4469 <p>
4470 When val is of type float the formatting conversion occurs as if it
4471 performed the following code fragment:
4472 </p>
4473
4474 <pre>bool failed = use_facet&lt;
4475    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
4476    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;double&gt;(val)).
4477 failed();
4478 </pre>
4479
4480 </blockquote>
4481
4482 <p><i>[post-Toronto: This differs from the previous proposed
4483 resolution; PJP provided the new wording.  The differences are in
4484 signed short and int output.]</i></p>
4485
4486
4487
4488 <p><b>Rationale:</b></p>
4489 <p>The original proposed resolution was to cast int and short to long,
4490 unsigned int and unsigned short to unsigned long, and float to double,
4491 thus ensuring that we don't try to use nonexistent num_put&lt;&gt;
4492 member functions.  The current proposed resolution is more
4493 complicated, but gives more expected results for hex and octal output
4494 of signed short and signed int.  (On a system with 16-bit short, for
4495 example, printing short(-1) in hex format should yield 0xffff.)</p>
4496
4497
4498
4499
4500
4501 <hr>
4502 <h3><a name="118"></a>118. <tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3>
4503 <p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
4504  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-11-20</p>
4505 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.formatted.arithmetic">active issues</a> in [istream.formatted.arithmetic].</p>
4506 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
4507 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
4508 <p><b>Discussion:</b></p>
4509 <p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
4510 <tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
4511 <tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
4512 formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
4513
4514 <pre>typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
4515 iostate err = 0;
4516 use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, val);
4517 setstate(err);</pre>
4518
4519 <p>According to section 22.2.2.1.1 [facet.num.get.members], however,
4520 <tt>num_get&lt;&gt;::get()</tt> is only overloaded for the types
4521 <tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
4522 int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
4523 <tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
4524 <tt>void*</tt>. Comparing the lists from the two sections, we find
4525 that 27.6.1.2.2 is using a nonexistent function for types
4526 <tt>short</tt> and <tt>int</tt>. </p>
4527
4528
4529 <p><b>Proposed resolution:</b></p>
4530 <p>In 27.6.1.2.2 [istream.formatted.arithmetic] Arithmetic Extractors, remove the
4531 two lines (1st and 3rd) which read:</p>
4532 <blockquote>
4533   <pre>operator&gt;&gt;(short&amp; val);
4534 ...
4535 operator&gt;&gt;(int&amp; val);</pre>
4536 </blockquote>
4537
4538 <p>And add the following at the end of that section (27.6.1.2.2) :</p>
4539
4540 <blockquote>
4541   <pre>operator&gt;&gt;(short&amp; val);</pre>
4542   <p>The conversion occurs as if performed by the following code fragment (using
4543   the same notation as for the preceding code fragment):</p>
4544   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
4545   iostate err = 0;
4546   long lval;
4547   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
4548         if (err == 0
4549                 &amp;&amp; (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval))
4550                 err = ios_base::failbit;
4551   setstate(err);</pre>
4552   <pre>operator&gt;&gt;(int&amp; val);</pre>
4553   <p>The conversion occurs as if performed by the following code fragment (using
4554   the same notation as for the preceding code fragment):</p>
4555   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
4556   iostate err = 0;
4557   long lval;
4558   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
4559         if (err == 0
4560                 &amp;&amp; (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval))
4561                 err = ios_base::failbit;
4562   setstate(err);</pre>
4563 </blockquote>
4564
4565 <p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
4566
4567
4568
4569
4570
4571
4572 <hr>
4573 <h3><a name="119"></a>119. Should virtual functions be allowed to strengthen the exception specification?</h3>
4574 <p><b>Section:</b> 17.4.4.8 [res.on.exception.handling] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4575  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4576 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.exception.handling">issues</a> in [res.on.exception.handling].</p>
4577 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4578 <p><b>Discussion:</b></p>
4579 <p>Section 17.4.4.8 [res.on.exception.handling] states: </p>
4580
4581 <p>"An implementation may strengthen the exception-specification
4582 for a function by removing listed exceptions." </p>
4583
4584 <p>The problem is that if an implementation is allowed to do this for
4585 virtual functions, then a library user cannot write a class that
4586 portably derives from that class. </p>
4587
4588 <p>For example, this would not compile if ios_base::failure::~failure
4589 had an empty exception specification: </p>
4590
4591 <pre>#include &lt;ios&gt;
4592 #include &lt;string&gt;
4593
4594 class D : public std::ios_base::failure {
4595 public:
4596         D(const std::string&amp;);
4597         ~D(); // error - exception specification must be compatible with
4598               // overridden virtual function ios_base::failure::~failure()
4599 };</pre>
4600
4601
4602 <p><b>Proposed resolution:</b></p>
4603 <p>Change Section 17.4.4.8 [res.on.exception.handling] from:</p>
4604
4605 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
4606 exception-specification for a function"</p>
4607
4608 <p>to:</p>
4609
4610 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
4611 exception-specification for a non-virtual function". </p>
4612
4613
4614
4615
4616
4617 <hr>
4618 <h3><a name="120"></a>120. Can an implementor add specializations?</h3>
4619 <p><b>Section:</b> 17.4.3.1 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
4620  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4621 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
4622 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
4623 <p><b>Discussion:</b></p>
4624
4625 <p>The original issue asked whether a library implementor could
4626 specialize standard library templates for built-in types.  (This was
4627 an issue because users are permitted to explicitly instantiate
4628 standard library templates.)</p>
4629
4630 <p>Specializations are no longer a problem, because of the resolution
4631 to core issue 259.  Under the proposed resolution, it will be legal
4632 for a translation unit to contain both a specialization and an
4633 explicit instantiation of the same template, provided that the
4634 specialization comes first.  In such a case, the explicit
4635 instantiation will be ignored.  Further discussion of library issue
4636 120 assumes that the core 259 resolution will be adopted.</p>
4637
4638 <p>However, as noted in lib-7047, one piece of this issue still
4639 remains: what happens if a standard library implementor explicitly
4640 instantiates a standard library templates?  It's illegal for a program
4641 to contain two different explicit instantiations of the same template
4642 for the same type in two different translation units (ODR violation),
4643 and the core working group doesn't believe it is practical to relax
4644 that restriction.</p>
4645
4646 <p>The issue, then, is: are users allowed to explicitly instantiate
4647 standard library templates for non-user defined types?  The status quo
4648 answer is 'yes'.  Changing it to 'no' would give library implementors
4649 more freedom.</p>
4650
4651 <p>This is an issue because, for performance reasons, library
4652 implementors often need to explicitly instantiate standard library
4653 templates.  (for example, std::basic_string&lt;char&gt;)  Does giving
4654 users freedom to explicitly instantiate standard library templates for
4655 non-user defined types make it impossible or painfully difficult for
4656 library implementors to do this?</p>
4657
4658 <p>John Spicer suggests, in lib-8957, that library implementors have a
4659 mechanism they can use for explicit instantiations that doesn't
4660 prevent users from performing their own explicit instantiations: put
4661 each explicit instantiation in its own object file.  (Different
4662 solutions might be necessary for Unix DSOs or MS-Windows DLLs.)  On
4663 some platforms, library implementors might not need to do anything
4664 special: the "undefined behavior" that results from having two
4665 different explicit instantiations might be harmless.</p>
4666
4667
4668
4669 <p><b>Proposed resolution:</b></p>
4670   <p>Append to 17.4.3.1 [reserved.names] paragraph 1: </p>
4671   <blockquote><p>
4672     A program may explicitly instantiate any templates in the standard
4673     library only if the declaration depends on the name of a user-defined
4674     type of external linkage and the instantiation meets the standard library
4675     requirements for the original template.
4676   </p></blockquote>
4677
4678 <p><i>[Kona: changed the wording from "a user-defined name" to "the name of
4679   a user-defined type"]</i></p>
4680
4681
4682
4683
4684 <p><b>Rationale:</b></p>
4685 <p>The LWG considered another possible resolution:</p>
4686 <blockquote>
4687   <p>In light of the resolution to core issue 259, no normative changes
4688   in the library clauses are necessary.  Add the following non-normative
4689   note to the end of 17.4.3.1 [reserved.names] paragraph 1:</p>
4690   <blockquote><p>
4691     [<i>Note:</i> A program may explicitly instantiate standard library
4692     templates, even when an explicit instantiation does not depend on
4693     a user-defined name. <i>--end note</i>]
4694   </p></blockquote>
4695 </blockquote>
4696
4697 <p>The LWG rejected this because it was believed that it would make
4698   it unnecessarily difficult for library implementors to write
4699   high-quality implementations.  A program may not include an
4700   explicit instantiation of the same template, for the same template
4701   arguments, in two different translation units.  If users are
4702   allowed to provide explicit instantiations of Standard Library
4703   templates for built-in types, then library implementors aren't,
4704   at least not without nonportable tricks.</p>
4705
4706 <p>The most serious problem is a class template that has writeable
4707   static member variables.  Unfortunately, such class templates are
4708   important and, in existing Standard Library implementations, are
4709   often explicitly specialized by library implementors: locale facets,
4710   which have a writeable static member variable <tt>id</tt>.  If a
4711   user's explicit instantiation collided with the implementations
4712   explicit instantiation, iostream initialization could cause locales
4713   to be constructed in an inconsistent state.</p>
4714
4715 <p>One proposed implementation technique was for Standard Library
4716   implementors to provide explicit instantiations in separate object
4717   files, so that they would not be picked up by the linker when the
4718   user also provides an explicit instantiation.  However, this
4719   technique only applies for Standard Library implementations that
4720   are packaged as static archives.  Most Standard Library
4721   implementations nowadays are packaged as dynamic libraries, so this
4722   technique would not apply.</p>
4723
4724 <p>The Committee is now considering standardization of dynamic
4725   linking.  If there are such changes in the future, it may be
4726   appropriate to revisit this issue later.</p>
4727
4728
4729
4730
4731
4732 <hr>
4733 <h3><a name="122"></a>122. streambuf/wstreambuf description should not say they are specializations</h3>
4734 <p><b>Section:</b> 27.5.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4735  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4736 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf">issues</a> in [streambuf].</p>
4737 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4738 <p><b>Discussion:</b></p>
4739 <p>Section 27.5.2 describes the streambuf classes this way: </p>
4740
4741 <blockquote>
4742
4743 <p>The class streambuf is a specialization of the template class basic_streambuf
4744 specialized for the type char. </p>
4745
4746 <p>The class wstreambuf is a specialization of the template class basic_streambuf
4747 specialized for the type wchar_t. </p>
4748
4749 </blockquote>
4750
4751 <p>This implies that these classes must be template specializations, not typedefs. </p>
4752
4753 <p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
4754
4755
4756 <p><b>Proposed resolution:</b></p>
4757 <p>Remove 27.5.2 [streambuf] paragraphs 2 and 3 (the above two
4758 sentences). </p>
4759
4760
4761 <p><b>Rationale:</b></p>
4762 <p>The <tt>streambuf</tt>  synopsis already has a declaration for the
4763 typedefs and that is sufficient. </p>
4764
4765
4766
4767
4768
4769 <hr>
4770 <h3><a name="123"></a>123. Should valarray helper arrays fill functions be const?</h3>
4771 <p><b>Section:</b> 26.5.5.4 [slice.arr.fill], 26.5.7.4 [gslice.array.fill], 26.5.8.4 [mask.array.fill], 26.5.9.4 [indirect.array.fill] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
4772  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4773 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
4774 <p><b>Discussion:</b></p>
4775 <p>One of the operator= in the valarray helper arrays is const and one
4776 is not. For example, look at slice_array. This operator= in Section
4777 26.5.5.2 [slice.arr.assign] is const: </p>
4778
4779 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const valarray&lt;T&gt;&amp;) const;</tt> </p>
4780
4781 <p>but this one in Section 26.5.5.4 [slice.arr.fill] is not: </p>
4782
4783 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const T&amp;); </tt></p>
4784
4785 <p>The description of the semantics for these two functions is similar. </p>
4786
4787
4788 <p><b>Proposed resolution:</b></p>
4789
4790 <p>26.5.5 [template.slice.array] Template class slice_array</p>
4791 <blockquote>
4792
4793    <p>In the class template definition for slice_array, replace the member
4794    function declaration</p>
4795     <pre>      void operator=(const T&amp;);
4796     </pre>
4797    <p>with</p>
4798     <pre>      void operator=(const T&amp;) const;
4799     </pre>
4800 </blockquote>
4801
4802 <p>26.5.5.4 [slice.arr.fill] slice_array fill function</p>
4803 <blockquote>
4804
4805    <p>Change the function declaration</p>
4806     <pre>      void operator=(const T&amp;);
4807     </pre>
4808    <p>to</p>
4809     <pre>      void operator=(const T&amp;) const;
4810     </pre>
4811 </blockquote>
4812
4813 <p>26.5.7 [template.gslice.array] Template class gslice_array</p>
4814 <blockquote>
4815
4816    <p>In the class template definition for gslice_array, replace the member
4817    function declaration</p>
4818     <pre>      void operator=(const T&amp;);
4819     </pre>
4820    <p>with</p>
4821     <pre>      void operator=(const T&amp;) const;
4822     </pre>
4823 </blockquote>
4824
4825 <p>26.5.7.4 [gslice.array.fill] gslice_array fill function</p>
4826 <blockquote>
4827
4828    <p>Change the function declaration</p>
4829     <pre>      void operator=(const T&amp;);
4830     </pre>
4831    <p>to</p>
4832     <pre>      void operator=(const T&amp;) const;
4833     </pre>
4834 </blockquote>
4835
4836 <p>26.5.8 [template.mask.array] Template class mask_array</p>
4837 <blockquote>
4838
4839    <p>In the class template definition for mask_array, replace the member
4840    function declaration</p>
4841     <pre>      void operator=(const T&amp;);
4842     </pre>
4843    <p>with</p>
4844     <pre>      void operator=(const T&amp;) const;
4845     </pre>
4846 </blockquote>
4847
4848 <p>26.5.8.4 [mask.array.fill] mask_array fill function</p>
4849 <blockquote>
4850
4851    <p>Change the function declaration</p>
4852     <pre>      void operator=(const T&amp;);
4853     </pre>
4854    <p>to</p>
4855     <pre>      void operator=(const T&amp;) const;
4856     </pre>
4857 </blockquote>
4858
4859 <p>26.5.9 [template.indirect.array] Template class indirect_array</p>
4860 <blockquote>
4861
4862    <p>In the class template definition for indirect_array, replace the member
4863    function declaration</p>
4864     <pre>      void operator=(const T&amp;);
4865     </pre>
4866    <p>with</p>
4867     <pre>      void operator=(const T&amp;) const;
4868     </pre>
4869 </blockquote>
4870
4871 <p>26.5.9.4 [indirect.array.fill] indirect_array fill function</p>
4872 <blockquote>
4873
4874    <p>Change the function declaration</p>
4875     <pre>      void operator=(const T&amp;);
4876     </pre>
4877    <p>to</p>
4878     <pre>      void operator=(const T&amp;) const;
4879     </pre>
4880 </blockquote>
4881
4882
4883 <p><i>[Redmond: Robert provided wording.]</i></p>
4884
4885
4886
4887
4888 <p><b>Rationale:</b></p>
4889 <p>There's no good reason for one version of operator= being const and
4890 another one not.  Because of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, this now
4891 matters: these functions are now callable in more circumstances.  In
4892 many existing implementations, both versions are already const.</p>
4893
4894
4895
4896
4897
4898 <hr>
4899 <h3><a name="124"></a>124. ctype_byname&lt;charT&gt;::do_scan_is &amp; do_scan_not return type should be const charT*</h3>
4900 <p><b>Section:</b> 22.2.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4901  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4902 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.byname">issues</a> in [locale.ctype.byname].</p>
4903 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4904 <p><b>Discussion:</b></p>
4905 <p>In Section 22.2.1.2 [locale.ctype.byname]
4906 ctype_byname&lt;charT&gt;::do_scan_is() and do_scan_not() are declared
4907 to return a const char* not a const charT*. </p>
4908
4909
4910 <p><b>Proposed resolution:</b></p>
4911 <p>Change Section 22.2.1.2 [locale.ctype.byname] <tt>do_scan_is()</tt> and
4912 <tt>do_scan_not()</tt> to return a <tt> const
4913 charT*</tt>. </p>
4914
4915
4916
4917
4918
4919 <hr>
4920 <h3><a name="125"></a>125. valarray&lt;T&gt;::operator!() return type is inconsistent</h3>
4921 <p><b>Section:</b> 26.5.2 [template.valarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4922  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4923 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.valarray">issues</a> in [template.valarray].</p>
4924 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4925 <p><b>Discussion:</b></p>
4926 <p>In Section 26.5.2 [template.valarray] valarray&lt;T&gt;::operator!()
4927 is
4928 declared to return a valarray&lt;T&gt;, but in Section 26.5.2.5
4929 [valarray.unary] it is declared to return a valarray&lt;bool&gt;. The
4930 latter appears to be correct. </p>
4931
4932
4933 <p><b>Proposed resolution:</b></p>
4934 <p>Change in Section 26.5.2 [template.valarray] the declaration of
4935 <tt>operator!()</tt> so that the return type is
4936 <tt>valarray&lt;bool&gt;</tt>. </p>
4937
4938
4939
4940
4941 <hr>
4942 <h3><a name="126"></a>126. typos in Effects clause of ctype::do_narrow()</h3>
4943 <p><b>Section:</b> 22.2.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4944  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4945 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.virtuals].</p>
4946 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4947 <p><b>Discussion:</b></p><p>Typos in 22.2.1.1.2 need to be fixed.</p>
4948
4949 <p><b>Proposed resolution:</b></p>
4950 <p>In Section 22.2.1.1.2 [locale.ctype.virtuals] change: </p>
4951
4952 <pre>   do_widen(do_narrow(c),0) == c</pre>
4953
4954 <p>to:</p>
4955
4956 <pre>   do_widen(do_narrow(c,0)) == c</pre>
4957
4958 <p>and change:</p>
4959
4960 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
4961
4962 <p>to:</p>
4963
4964 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
4965
4966
4967
4968
4969
4970 <hr>
4971 <h3><a name="127"></a>127. auto_ptr&lt;&gt; conversion issues</h3>
4972 <p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4973  <b>Submitter:</b> Greg Colvin <b>Date:</b> 1999-02-17</p>
4974 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p>
4975 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4976 <p><b>Discussion:</b></p>
4977 <p>There are two problems with the current <tt>auto_ptr</tt> wording
4978 in the standard: </p>
4979
4980 <p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
4981 because <tt>auto_ptr&lt;Derived&gt;::auto_ptr_ref</tt> is unrelated to
4982 <tt>auto_ptr&lt;Base&gt;::auto_ptr_ref</tt>.  <i>Also submitted by
4983 Nathan Myers, with the same proposed resolution.</i></p>
4984
4985 <p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
4986 <tt>auto_ptr_ref</tt> argument. </p>
4987
4988 <p>I have discussed these problems with my proposal coauthor, Bill
4989 Gibbons, and with some compiler and library implementors, and we
4990 believe that these problems are not desired or desirable implications
4991 of the standard. </p>
4992
4993 <p>25 Aug 1999: The proposed resolution now reflects changes suggested
4994 by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
4995 "assignment operator" to "public assignment
4996 operator", 2) changed effects to specify use of release(), 3)
4997 made the conversion to auto_ptr_ref const. </p>
4998
4999 <p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
5000 states that the conversion from auto_ptr to auto_ptr_ref should
5001 be const.  This is not acceptable, because it would allow
5002 initialization and assignment from _any_ const auto_ptr!  It also
5003 introduces an implementation difficulty in writing this conversion
5004 function -- namely, somewhere along the line, a const_cast will be
5005 necessary to remove that const so that release() may be called.  This
5006 may result in undefined behavior [7.1.5.1/4]. The conversion
5007 operator does not have to be const, because a non-const implicit
5008 object parameter may be bound to an rvalue [13.3.3.1.4/3]
5009 [13.3.1/5]. </p>
5010
5011   <p>Tokyo: The LWG removed the following from the proposed resolution:</p>
5012
5013   <p>In 20.4.4 [meta.unary], paragraph 2, and 20.4.4.3 [meta.unary.prop],
5014   paragraph 2, make the conversion to auto_ptr_ref const:</p>
5015   <blockquote>
5016     <pre>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() const throw();</pre>
5017   </blockquote>
5018
5019
5020 <p><b>Proposed resolution:</b></p>
5021 <p>In 20.4.4 [meta.unary], paragraph 2, move
5022 the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
5023
5024 <p>In 20.4.4 [meta.unary], paragraph 2, add
5025 a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
5026
5027 <blockquote>
5028   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</pre>
5029 </blockquote>
5030
5031 <p>Also add the assignment operator to 20.4.4.3 [meta.unary.prop]: </p>
5032
5033 <blockquote>
5034   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw()</pre>
5035
5036   <p><b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
5037   p</tt> that <tt>r</tt> holds a reference to.<br>
5038   <b>Returns: </b><tt>*this</tt>.</p>
5039
5040 </blockquote>
5041
5042
5043
5044
5045
5046 <hr>
5047 <h3><a name="129"></a>129. Need error indication from seekp() and seekg()</h3>
5048 <p><b>Section:</b> 27.6.1.3 [istream.unformatted], 27.6.2.5 [ostream.seeks] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5049  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p>
5050 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
5051 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
5052 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5053 <p><b>Discussion:</b></p>
5054 <p>Currently, the standard does not specify how seekg() and seekp()
5055 indicate failure. They are not required to set failbit, and they can't
5056 return an error indication because they must return *this, i.e. the
5057 stream. Hence, it is undefined what happens if they fail. And they
5058 <i>can</i> fail, for instance, when a file stream is disconnected from the
5059 underlying file (is_open()==false) or when a wide character file
5060 stream must perform a state-dependent code conversion, etc. </p>
5061
5062 <p>The stream functions seekg() and seekp() should set failbit in the
5063 stream state in case of failure.</p>
5064
5065
5066 <p><b>Proposed resolution:</b></p>
5067 <p>Add to the Effects: clause of&nbsp; seekg() in
5068 27.6.1.3 [istream.unformatted] and to the Effects: clause of seekp() in
5069 27.6.2.5 [ostream.seeks]: </p>
5070
5071 <blockquote>
5072   <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
5073   </p>
5074 </blockquote>
5075
5076
5077 <p><b>Rationale:</b></p>
5078 <p>Setting failbit is the usual error reporting mechanism for streams</p>
5079
5080
5081
5082
5083 <hr>
5084 <h3><a name="130"></a>130. Return type of container::erase(iterator) differs for associative containers</h3>
5085 <p><b>Section:</b> 23.1.2 [associative.reqmts], 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
5086  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-03-02</p>
5087 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
5088 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
5089 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#451">451</a></p>
5090 <p><b>Discussion:</b></p>
5091 <p>Table 67 (23.1.1) says that container::erase(iterator) returns an
5092 iterator. Table 69 (23.1.2) says that in addition to this requirement,
5093 associative containers also say that container::erase(iterator)
5094 returns void.  That's not an addition; it's a change to the
5095 requirements, which has the effect of making associative containers
5096 fail to meet the requirements for containers.</p>
5097
5098
5099 <p><b>Proposed resolution:</b></p>
5100
5101 <p>
5102 In 23.1.2 [associative.reqmts], in Table 69 Associative container
5103 requirements, change the return type of <tt>a.erase(q)</tt> from
5104 <tt>void</tt> to <tt>iterator</tt>.  Change the
5105 assertion/not/pre/post-condition from "erases the element pointed to
5106 by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>.
5107 Returns an iterator pointing to the element immediately following q
5108 prior to the element being erased. If no such element exists, a.end()
5109 is returned."
5110 </p>
5111
5112 <p>
5113 In 23.1.2 [associative.reqmts], in Table 69 Associative container
5114 requirements, change the return type of <tt>a.erase(q1, q2)</tt>
5115 from <tt>void</tt> to <tt>iterator</tt>.  Change the
5116 assertion/not/pre/post-condition from "erases the elements in the
5117 range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1,
5118 q2)</tt>.  Returns q2."
5119 </p>
5120
5121 <p>
5122 In 23.3.1 [map], in the <tt>map</tt> class synopsis; and
5123 in 23.3.2 [multimap], in the <tt>multimap</tt> class synopsis; and
5124 in 23.3.3 [set], in the <tt>set</tt> class synopsis; and
5125 in 23.3.4 [multiset], in the <tt>multiset</tt> class synopsis:
5126 change the signature of the first <tt>erase</tt> overload to
5127 </p>
5128 <pre>   iterator erase(iterator position);
5129 </pre>
5130 <p>and change the signature of the third <tt>erase</tt> overload to</p>
5131 <pre>  iterator erase(iterator first, iterator last);
5132 </pre>
5133
5134
5135 <p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p>
5136
5137
5138 <p><i>[Post-Kona: the LWG agrees the return type should be
5139 <tt>iterator</tt>, not <tt>void</tt>.  (Alex Stepanov agrees too.)
5140 Matt provided wording.]</i></p>
5141
5142
5143 <p><i>[
5144  Sydney: the proposed wording went in the right direction, but it
5145  wasn't good enough. We want to return an iterator from the range form
5146  of erase as well as the single-iterator form. Also, the wording is
5147  slightly different from the wording we have for sequences; there's no
5148  good reason for having a difference.  Matt provided new wording,
5149  which we will review at the next meeting.
5150 ]</i></p>
5151
5152
5153
5154
5155
5156
5157
5158 <hr>
5159 <h3><a name="132"></a>132. list::resize description uses random access iterators</h3>
5160 <p><b>Section:</b> 23.2.3.2 [list.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5161  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
5162 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5163 <p><b>Discussion:</b></p>
5164 <p>The description reads:</p>
5165
5166 <p>-1- Effects:</p>
5167
5168 <pre>         if (sz &gt; size())
5169            insert(end(), sz-size(), c);
5170          else if (sz &lt; size())
5171            erase(begin()+sz, end());
5172          else
5173            ;                           //  do nothing</pre>
5174
5175 <p>Obviously list::resize should not be specified in terms of random access iterators.</p>
5176
5177
5178 <p><b>Proposed resolution:</b></p>
5179 <p>Change 23.2.3.2 [list.capacity] paragraph 1 to:</p>
5180
5181 <p>Effects:</p>
5182
5183 <pre>         if (sz &gt; size())
5184            insert(end(), sz-size(), c);
5185          else if (sz &lt; size())
5186          {
5187            iterator i = begin();
5188            advance(i, sz);
5189            erase(i, end());
5190          }</pre>
5191
5192 <p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
5193 with David Abrahams. They had a discussion and believe there is
5194 no issue of exception safety with the proposed resolution.]</i></p>
5195
5196
5197
5198
5199
5200
5201 <hr>
5202 <h3><a name="133"></a>133. map missing get_allocator()</h3>
5203 <p><b>Section:</b> 23.3.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5204  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
5205 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map">issues</a> in [map].</p>
5206 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5207 <p><b>Discussion:</b></p><p>The title says it all.</p>
5208
5209 <p><b>Proposed resolution:</b></p>
5210 <p>Insert in 23.3.1 [map], paragraph 2,
5211 after operator= in the map declaration:</p>
5212
5213 <pre>    allocator_type get_allocator() const;</pre>
5214
5215
5216
5217
5218 <hr>
5219 <h3><a name="134"></a>134. vector constructors over specified</h3>
5220 <p><b>Section:</b> 23.2.5.1 [vector.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5221  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
5222 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5223 <p><b>Discussion:</b></p>
5224 <p>The complexity description says: "It does at most 2N calls to the copy constructor
5225 of T and logN reallocations if they are just input iterators ...".</p>
5226
5227 <p>This appears to be overly restrictive, dictating the precise memory/performance
5228 tradeoff for the implementor.</p>
5229
5230
5231 <p><b>Proposed resolution:</b></p>
5232 <p>Change 23.2.5.1 [vector.cons], paragraph 1 to:</p>
5233
5234 <p>-1- Complexity: The constructor template &lt;class
5235 InputIterator&gt; vector(InputIterator first, InputIterator last)
5236 makes only N calls to the copy constructor of T (where N is the
5237 distance between first and last) and no reallocations if iterators
5238 first and last are of forward, bidirectional, or random access
5239 categories. It makes order N calls to the copy constructor of T and
5240 order logN reallocations if they are just input iterators.
5241 </p>
5242
5243
5244 <p><b>Rationale:</b></p>
5245 <p>"at most 2N calls" is correct only if the growth factor
5246 is greater than or equal to 2.
5247 </p>
5248
5249
5250
5251
5252 <hr>
5253 <h3><a name="136"></a>136. seekp, seekg setting wrong streams?</h3>
5254 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
5255  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
5256 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
5257 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
5258 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
5259 <p><b>Discussion:</b></p>
5260 <p>I may be misunderstanding the intent, but should not seekg set only
5261 the input stream and seekp set only the output stream? The description
5262 seems to say that each should set both input and output streams. If
5263 that's really the intent, I withdraw this proposal.</p>
5264
5265
5266 <p><b>Proposed resolution:</b></p>
5267 <p>In section 27.6.1.3 change:</p>
5268
5269 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
5270 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
5271
5272 <p>To:</p>
5273
5274 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
5275 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::in). </pre>
5276
5277 <p>In section 27.6.1.3 change:</p>
5278
5279 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
5280 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
5281
5282 <p>To:</p>
5283
5284 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
5285 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::in). </pre>
5286
5287 <p>In section 27.6.2.4, paragraph 2 change:</p>
5288
5289 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
5290
5291 <p>To:</p>
5292
5293 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::out). </pre>
5294
5295 <p>In section 27.6.2.4, paragraph 4 change:</p>
5296
5297 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
5298
5299 <p>To:</p>
5300
5301 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::out). </pre>
5302
5303 <p><i>[Dublin: Dietmar Kühl thinks this is probably correct, but would
5304 like the opinion of more iostream experts before taking action.]</i></p>
5305
5306
5307 <p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
5308 incorrect, his implementation already implements the Proposed
5309 Resolution.]</i></p>
5310
5311
5312 <p><i>[Post-Tokyo: Matt Austern comments:<br>
5313 Is it a problem with basic_istream and basic_ostream, or is it a problem
5314 with basic_stringbuf?
5315 We could resolve the issue either by changing basic_istream and
5316 basic_ostream, or by changing basic_stringbuf. I prefer the latter
5317 change (or maybe both changes): I don't see any reason for the standard to
5318 require that std::stringbuf s(std::string("foo"), std::ios_base::in);
5319 s.pubseekoff(0, std::ios_base::beg); must fail.<br>
5320 This requirement is a bit weird. There's no similar requirement
5321 for basic_streambuf&lt;&gt;::seekpos, or for basic_filebuf&lt;&gt;::seekoff or
5322 basic_filebuf&lt;&gt;::seekpos.]</i></p>
5323
5324
5325
5326
5327
5328
5329 <hr>
5330 <h3><a name="137"></a>137. Do use_facet and has_facet look in the global locale?</h3>
5331 <p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5332  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-03-17</p>
5333 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
5334 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5335 <p><b>Discussion:</b></p>
5336 <p>Section 22.1.1 [locale] says:</p>
5337
5338 <p>-4- In the call to use_facet&lt;Facet&gt;(loc), the type argument
5339 chooses a facet, making available all members of the named type. If
5340 Facet is not present in a locale (or, failing that, in the global
5341 locale), it throws the standard exception bad_cast. A C++ program can
5342 check if a locale implements a particular facet with the template
5343 function has_facet&lt;Facet&gt;(). </p>
5344
5345 <p>This contradicts the specification given in section
5346 22.1.2 [locale.global.templates]:
5347 <br><br>
5348 template &lt;class&nbsp; Facet&gt; const&nbsp; Facet&amp; use_facet(const
5349 locale&amp;&nbsp; loc); <br>
5350 <br>
5351 -1- Get a reference to a facet of a locale. <br>
5352 -2- Returns: a reference to the corresponding facet of loc, if present. <br>
5353 -3- Throws: bad_cast if has_facet&lt;Facet&gt;(loc) is false. <br>
5354 -4- Notes: The reference returned remains valid at least as long as any copy of loc exists
5355 </p>
5356
5357
5358 <p><b>Proposed resolution:</b></p>
5359 <p>Remove the phrase "(or, failing that, in the global locale)"
5360 from section 22.1.1. </p>
5361
5362
5363 <p><b>Rationale:</b></p>
5364 <p>Needed for consistency with the way locales are handled elsewhere
5365 in the standard.</p>
5366
5367
5368
5369
5370 <hr>
5371 <h3><a name="139"></a>139. Optional sequence operation table description unclear</h3>
5372 <p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5373  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-03-30</p>
5374 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
5375 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5376 <p><b>Discussion:</b></p>
5377 <p>The sentence introducing the Optional sequence operation table
5378 (23.1.1 paragraph 12) has two problems:</p>
5379
5380 <p>A. It says ``The operations in table 68 are provided only for the containers for which
5381 they take constant time.''<br>
5382 <br>
5383 That could be interpreted in two ways, one of them being ``Even though table 68 shows
5384 particular operations as being provided, implementations are free to omit them if they
5385 cannot implement them in constant time.''<br>
5386 <br>
5387 B. That paragraph says nothing about amortized constant time, and it should.&nbsp;</p>
5388
5389
5390 <p><b>Proposed resolution:</b></p>
5391 <p>Replace the wording in 23.1.1 paragraph 12&nbsp; which begins ``The operations in table 68 are provided only..."
5392 with:</p>
5393
5394 <blockquote>
5395   <p>Table 68 lists sequence operations that are provided for some types of sequential
5396   containers but not others. An implementation shall provide these operations for all
5397   container types shown in the ``container'' column, and shall implement them so as to take
5398   amortized constant time.</p>
5399 </blockquote>
5400
5401
5402
5403
5404 <hr>
5405 <h3><a name="141"></a>141. basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3>
5406 <p><b>Section:</b> 21.3.6.4 [string::insert], 21.3.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5407  <b>Submitter:</b> Arch Robison <b>Date:</b> 1999-04-28</p>
5408 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p>
5409 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5410 <p><b>Discussion:</b></p>
5411 <p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
5412 say:<br>
5413 <br>
5414 &#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();</tt></p>
5415
5416 <p>Surely the document meant to say ``<tt>xpos &lt; size()</tt>'' in both places.</p>
5417
5418 <p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
5419 proposed resolution.]</i></p>
5420
5421
5422
5423 <p><b>Proposed resolution:</b></p>
5424 <p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
5425 <br>
5426 &#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();<br>
5427 <br>
5428 </tt>to:<br>
5429 <tt><br>
5430 </tt>&#8212; <tt>xpos &lt;= pos</tt> and <tt>xpos &lt; size();</tt></p>
5431
5432
5433
5434
5435 <hr>
5436 <h3><a name="142"></a>142. lexicographical_compare complexity wrong</h3>
5437 <p><b>Section:</b> 25.3.8 [alg.lex.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5438  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-06-20</p>
5439 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5440 <p><b>Discussion:</b></p>
5441 <p>The lexicographical_compare complexity is specified as:<br>
5442 <br>
5443 &nbsp;&nbsp;&nbsp;&nbsp; "At most min((last1 - first1), (last2 - first2))
5444 applications of the corresponding comparison."<br>
5445 <br>
5446 The best I can do is twice that expensive.</p>
5447
5448 <p>Nicolai Josuttis comments in lib-6862: You mean, to check for
5449 equality you have to check both &lt; and &gt;? Yes, IMO you are
5450 right! (and Matt states this complexity in his book)</p>
5451
5452
5453
5454 <p><b>Proposed resolution:</b></p>
5455 <p>Change 25.3.8 [alg.lex.comparison] complexity to:</p>
5456     <blockquote><p>
5457     At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
5458     applications of the corresponding comparison.
5459     </p></blockquote>
5460
5461 <p>Change the example at the end of paragraph 3 to read:</p>
5462     <blockquote><p>
5463     [Example:<br>
5464     <br>
5465     &nbsp;&nbsp;&nbsp; for ( ; first1 != last1 &amp;&amp; first2 != last2 ;
5466     ++first1, ++first2) {<br>
5467     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first1 &lt; *first2) return true;<br>
5468     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first2 &lt; *first1) return false;<br>
5469     &nbsp;&nbsp;&nbsp; }<br>
5470     &nbsp;&nbsp;&nbsp; return first1 == last1 &amp;&amp; first2 != last2;<br>
5471     &nbsp;&nbsp;&nbsp;<br>
5472     --end example]
5473     </p></blockquote>
5474
5475
5476
5477
5478 <hr>
5479 <h3><a name="144"></a>144. Deque constructor complexity wrong </h3>
5480 <p><b>Section:</b> 23.2.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5481  <b>Submitter:</b> Herb Sutter <b>Date:</b> 1999-05-09</p>
5482 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.cons">issues</a> in [deque.cons].</p>
5483 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5484 <p><b>Discussion:</b></p>
5485 <p>In 23.2.2.1 [deque.cons] paragraph 6, the deque ctor that takes an iterator range appears
5486 to have complexity requirements which are incorrect, and which contradict the
5487 complexity requirements for insert(). I suspect that the text in question,
5488 below, was taken from vector:</p>
5489 <blockquote>
5490   <p>Complexity: If the iterators first and last are forward iterators,
5491   bidirectional iterators, or random access iterators the constructor makes only
5492   N calls to the copy constructor, and performs no reallocations, where N is
5493   last - first.</p>
5494 </blockquote>
5495 <p>The word "reallocations" does not really apply to deque. Further,
5496 all of the following appears to be spurious:</p>
5497 <blockquote>
5498   <p>It makes at most 2N calls to the copy constructor of T and log N
5499   reallocations if they are input iterators.1)</p>
5500   <p>1) The complexity is greater in the case of input iterators because each
5501   element must be added individually: it is impossible to determine the distance
5502   between first abd last before doing the copying.</p>
5503 </blockquote>
5504 <p>This makes perfect sense for vector, but not for deque. Why should deque gain
5505 an efficiency advantage from knowing in advance the number of elements to
5506 insert?</p>
5507
5508
5509 <p><b>Proposed resolution:</b></p>
5510 <p>In 23.2.2.1 [deque.cons] paragraph 6, replace the Complexity description, including the
5511 footnote, with the following text (which also corrects the "abd"
5512 typo):</p>
5513 <blockquote>
5514   <p>Complexity: Makes last - first calls to the copy constructor of T.</p>
5515 </blockquote>
5516
5517
5518
5519
5520 <hr>
5521 <h3><a name="146"></a>146. complex&lt;T&gt; Inserter and Extractor need sentries</h3>
5522 <p><b>Section:</b> 26.3.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5523  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-05-12</p>
5524 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.ops">issues</a> in [complex.ops].</p>
5525 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5526 <p><b>Discussion:</b></p>
5527 <p>The extractor for complex numbers is specified as:&nbsp;</p>
5528
5529 <blockquote>
5530
5531 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
5532      basic_istream&lt;charT, traits&gt;&amp;&nbsp;<br>
5533      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;  is, complex&lt;T&gt;&amp;  x);<br>
5534 &nbsp;<br>
5535 Effects: Extracts a complex number x of the form: u, (u), or (u,v),
5536 where u is the real part and v is the imaginary part
5537 (lib.istream.formatted).&nbsp;<br>
5538 Requires: The input values be convertible to T. If bad input is
5539 encountered, calls is.setstate(ios::failbit) (which may throw
5540 ios::failure (lib.iostate.flags).&nbsp;<br>
5541 Returns: is .</p>
5542
5543 </blockquote>
5544 <p>Is it intended that the extractor for complex numbers does not skip
5545 whitespace, unlike all other extractors in the standard library do?
5546 Shouldn't a sentry be used?&nbsp;<br>
5547 <br>
5548 The inserter for complex numbers is specified as:</p>
5549
5550 <blockquote>
5551
5552 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
5553      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
5554      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;  o, const complex&lt;T&gt;&amp;  x);<br>
5555 <br>
5556 Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
5557 <br>
5558      template&lt;class T, class charT, class traits&gt;&nbsp;<br>
5559      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
5560      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; o, const complex&lt;T&gt;&amp; x)&nbsp;<br>
5561      {&nbsp;<br>
5562              basic_ostringstream&lt;charT, traits&gt; s;&nbsp;<br>
5563              s.flags(o.flags());&nbsp;<br>
5564              s.imbue(o.getloc());&nbsp;<br>
5565              s.precision(o.precision());&nbsp;<br>
5566              s &lt;&lt; '(' &lt;&lt; x.real() &lt;&lt; "," &lt;&lt; x.imag() &lt;&lt; ')';&nbsp;<br>
5567              return o &lt;&lt; s.str();&nbsp;<br>
5568      }</p>
5569
5570 </blockquote>
5571
5572 <p>Is it intended that the inserter for complex numbers ignores the
5573 field width and does not do any padding? If, with the suggested
5574 implementation above, the field width were set in the stream then the
5575 opening parentheses would be adjusted, but the rest not, because the
5576 field width is reset to zero after each insertion.</p>
5577
5578 <p>I think that both operations should use sentries, for sake of
5579 consistency with the other inserters and extractors in the
5580 library. Regarding the issue of padding in the inserter, I don't know
5581 what the intent was.&nbsp;</p>
5582
5583
5584 <p><b>Proposed resolution:</b></p>
5585 <p>After 26.3.6 [complex.ops] paragraph 14 (operator&gt;&gt;), add a
5586 Notes clause:</p>
5587
5588 <blockquote>
5589
5590 <p>Notes: This extraction is performed as a series of simpler
5591 extractions. Therefore, the skipping of whitespace is specified to be the
5592 same for each of the simpler extractions.</p>
5593
5594 </blockquote>
5595
5596
5597 <p><b>Rationale:</b></p>
5598 <p>For extractors, the note is added to make it clear that skipping whitespace
5599 follows an "all-or-none" rule.</p>
5600
5601 <p>For inserters, the LWG believes there is no defect; the standard is correct
5602 as written.</p>
5603
5604
5605
5606
5607 <hr>
5608 <h3><a name="147"></a>147. Library Intro refers to global functions that aren't global</h3>
5609 <p><b>Section:</b> 17.4.4.3 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5610  <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 1999-06-04</p>
5611 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#global.functions">issues</a> in [global.functions].</p>
5612 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5613 <p><b>Discussion:</b></p>
5614 <p>The library had many global functions until 17.4.1.1 [lib.contents]
5615 paragraph 2 was added: </p>
5616
5617 <blockquote>
5618
5619 <p>All library entities except macros, operator new and operator
5620 delete are defined within the namespace std or namespaces nested
5621 within namespace std. </p>
5622
5623 </blockquote>
5624
5625 <p>It appears "global function" was never updated in the following: </p>
5626
5627 <blockquote>
5628
5629 <p>17.4.4.3 - Global functions [lib.global.functions]<br>
5630 <br>
5631 -1- It is unspecified whether any global functions in the C++ Standard
5632 Library are defined as inline (dcl.fct.spec).<br>
5633 <br>
5634 -2- A call to a global function signature described in Clauses
5635 lib.language.support through lib.input.output behaves the same as if
5636 the implementation declares no additional global function
5637 signatures.*<br>
5638 <br>
5639     [Footnote: A valid C++ program always calls the expected library
5640     global function. An implementation may also define additional
5641     global functions that would otherwise not be called by a valid C++
5642     program. --- end footnote]<br>
5643 <br>
5644 -3- A global function cannot be declared by the implementation as
5645 taking additional default arguments.&nbsp;<br>
5646 <br>
5647 17.4.4.4 - Member functions [lib.member.functions]<br>
5648 <br>
5649 -2- An implementation can declare additional non-virtual member
5650 function signatures within a class: </p>
5651
5652   <blockquote>
5653
5654 <p>-- by adding arguments with default values to a member function
5655 signature; The same latitude does not extend to the implementation of
5656 virtual or global functions, however. </p>
5657
5658   </blockquote>
5659 </blockquote>
5660
5661
5662 <p><b>Proposed resolution:</b></p>
5663 <p>     Change "global" to "global or non-member" in:</p>
5664 <blockquote>
5665   <p>17.4.4.3 [lib.global.functions] section title,<br>
5666   17.4.4.3 [lib.global.functions] para 1,<br>
5667   17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2
5668            places in the footnote,<br>
5669   17.4.4.3 [lib.global.functions] para 3,<br>
5670   17.4.4.4 [lib.member.functions] para 2</p>
5671 </blockquote>
5672
5673
5674 <p><b>Rationale:</b></p>
5675 <p>
5676 Because operator new and delete are global, the proposed resolution
5677 was changed from "non-member" to "global or non-member.
5678 </p>
5679
5680
5681
5682
5683 <hr>
5684 <h3><a name="148"></a>148. Functions in the example facet BoolNames should be const</h3>
5685 <p><b>Section:</b> 22.2.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5686  <b>Submitter:</b> Jeremy Siek <b>Date:</b> 1999-06-03</p>
5687 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</p>
5688 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5689 <p><b>Discussion:</b></p>
5690 <p>In 22.2.8 [facets.examples] paragraph 13, the do_truename() and
5691 do_falsename() functions in the example facet BoolNames should be
5692 const. The functions they are overriding in
5693 numpunct_byname&lt;char&gt; are const. </p>
5694
5695
5696 <p><b>Proposed resolution:</b></p>
5697 <p>In 22.2.8 [facets.examples] paragraph 13, insert "const" in
5698 two places:</p>
5699 <blockquote>
5700   <p><tt>string do_truename() const { return "Oui Oui!"; }<br>
5701   string do_falsename() const { return "Mais Non!"; }</tt></p>
5702 </blockquote>
5703
5704
5705
5706
5707 <hr>
5708 <h3><a name="150"></a>150. Find_first_of says integer instead of iterator </h3>
5709 <p><b>Section:</b> 25.1.4 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5710  <b>Submitter:</b> Matt McClure <b>Date:</b> 1999-06-30</p>
5711 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</p>
5712 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5713 <p><b>Discussion:</b></p>
5714
5715
5716 <p><b>Proposed resolution:</b></p>
5717 <p>Change 25.1.4 [alg.find.first.of] paragraph 2 from:</p>
5718
5719 <blockquote>
5720 <p>Returns: The first iterator i in the range [first1, last1) such
5721 that for some integer j in the range [first2, last2) ...</p>
5722 </blockquote>
5723
5724 <p>to:</p>
5725
5726 <blockquote>
5727 <p>Returns: The first iterator i in the range [first1, last1) such
5728 that for some iterator j in the range [first2, last2) ...</p>
5729 </blockquote>
5730
5731
5732
5733
5734 <hr>
5735 <h3><a name="151"></a>151. Can't currently clear() empty container</h3>
5736 <p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5737  <b>Submitter:</b> Ed Brey <b>Date:</b> 1999-06-21</p>
5738 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
5739 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5740 <p><b>Discussion:</b></p>
5741 <p>For both sequences and associative containers, a.clear() has the
5742 semantics of erase(a.begin(),a.end()), which is undefined for an empty
5743 container since erase(q1,q2) requires that q1 be dereferenceable
5744 (23.1.1,3 and 23.1.2,7).  When the container is empty, a.begin() is
5745 not dereferenceable.<br>
5746 <br>
5747 The requirement that q1 be unconditionally dereferenceable causes many
5748 operations to be intuitively undefined, of which clearing an empty
5749 container is probably the most dire.<br>
5750 <br>
5751 Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
5752 q2) is required to be a valid range, stating that q1 and q2 must be
5753 iterators or certain kinds of iterators is unnecessary.
5754 </p>
5755
5756
5757 <p><b>Proposed resolution:</b></p>
5758 <p>In 23.1.1, paragraph 3, change:</p>
5759 <blockquote>
5760   <p>p and q2 denote valid iterators to a, q and q1 denote valid dereferenceable iterators to a, [q1, q2) denotes a valid range</p>
5761 </blockquote>
5762 <p>to:</p>
5763 <blockquote>
5764   <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range
5765   in a</p>
5766 </blockquote>
5767 <p>In 23.1.2, paragraph 7, change:</p>
5768 <blockquote>
5769   <p>p and q2 are valid iterators to a, q and q1 are valid dereferenceable
5770   iterators to a, [q1, q2) is a valid range</p>
5771 </blockquote>
5772 <p>to</p>
5773 <blockquote>
5774   <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
5775   into a</p>
5776 </blockquote>
5777
5778
5779
5780
5781 <hr>
5782 <h3><a name="152"></a>152. Typo in <tt>scan_is()</tt> semantics</h3>
5783 <p><b>Section:</b> 22.2.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5784  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
5785 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.virtuals].</p>
5786 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5787 <p><b>Discussion:</b></p>
5788 <p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
5789 because there is no function <tt>is()</tt> which only takes a character as
5790 argument. Also, in the effects clause (paragraph 3), the semantic is also kept
5791 vague.</p>
5792
5793
5794 <p><b>Proposed resolution:</b></p>
5795 <p>In 22.2.1.1.2 [locale.ctype.virtuals] paragraphs 4 and 6, change the returns
5796 clause from:</p>
5797 <blockquote>
5798   <p>"... such that <tt>is(*p)</tt>
5799 would..."</p>
5800 </blockquote>
5801 <p>to:&nbsp; "... such that <tt>is(m, *p)</tt>
5802  would...."</p>
5803
5804
5805
5806
5807
5808 <hr>
5809 <h3><a name="153"></a>153. Typo in <tt>narrow()</tt> semantics</h3>
5810 <p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
5811  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
5812 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p>
5813 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
5814 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a></p>
5815 <p><b>Discussion:</b></p>
5816 <p>The description of the array version of <tt>narrow()</tt> (in
5817 paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
5818 takes only three arguments because in addition to the range a default
5819 character is needed.</p>
5820
5821 <p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
5822 two signatures followed by a <b>Returns</b> clause that only addresses
5823 one of them.</p>
5824
5825
5826
5827 <p><b>Proposed resolution:</b></p>
5828 <p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members]
5829 paragraph 10 from:</p>
5830 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
5831
5832 <p>to:</p>
5833 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to),
5834 respectively.</p>
5835
5836 <p>Change 22.2.1.3.2 [facet.ctype.char.members] paragraph 10 and 11 from:</p>
5837 <pre>        char        narrow(char c, char /*dfault*/) const;
5838         const char* narrow(const char* low, const char* high,
5839                            char /*dfault*/, char* to) const;</pre>
5840 <pre>        Returns: do_narrow(low, high, to).</pre>
5841 <p>to:</p>
5842 <pre>        char        narrow(char c, char dfault) const;
5843         const char* narrow(const char* low, const char* high,
5844                            char dfault, char* to) const;</pre>
5845 <pre>        Returns: do_narrow(c, dfault) or
5846                  do_narrow(low, high, dfault, to), respectively.</pre>
5847
5848 <p><i>[Kona: 1) the problem occurs in additional places, 2) a user
5849 defined version could be different.]</i></p>
5850
5851
5852 <p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
5853 the LWG. He could find no other places the problem occurred. He
5854 asks for clarification of the Kona "a user defined
5855 version..." comment above.  Perhaps it was a circuitous way of
5856 saying "dfault" needed to be uncommented?]</i></p>
5857
5858
5859 <p><i>[Post-Toronto: the issues list maintainer has merged in the
5860 proposed resolution from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a>, which addresses the
5861 same paragraphs.]</i></p>
5862
5863
5864
5865
5866
5867
5868 <hr>
5869 <h3><a name="154"></a>154. Missing <tt>double</tt> specifier for <tt>do_get()</tt></h3>
5870 <p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5871  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
5872 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
5873 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
5874 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5875 <p><b>Discussion:</b></p>
5876 <p>The table in paragraph 7 for the length modifier does not list the length
5877 modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
5878 standard asks the implementation to do undefined things when using <tt>scanf()</tt>
5879 (the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
5880 is actually a problem I found quite often in production code, too).</p>
5881
5882
5883 <p><b>Proposed resolution:</b></p>
5884 <p>In 22.2.2.1.2 [facet.num.get.virtuals], paragraph 7, add a row in the Length
5885 Modifier table to say that for <tt>double</tt> a length modifier
5886 <tt>l</tt> is to be used.</p>
5887
5888
5889 <p><b>Rationale:</b></p>
5890 <p>The standard makes an embarrassing beginner's mistake.</p>
5891
5892
5893
5894
5895 <hr>
5896 <h3><a name="155"></a>155. Typo in naming the class defining the class <tt>Init</tt></h3>
5897 <p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5898  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
5899 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
5900 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5901 <p><b>Discussion:</b></p>
5902 <p>There are conflicting statements about where the class
5903 <tt>Init</tt> is defined. According to 27.3 [iostream.objects] paragraph 2
5904 it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 [ios.base] it is defined as <tt>ios_base::Init</tt>.</p>
5905
5906
5907 <p><b>Proposed resolution:</b></p>
5908 <p>Change 27.3 [iostream.objects] paragraph 2 from
5909 "<tt>basic_ios::Init"</tt> to
5910 "<tt>ios_base::Init"</tt>.</p>
5911
5912
5913 <p><b>Rationale:</b></p>
5914 <p>Although not strictly wrong, the standard was misleading enough to warrant
5915 the change.</p>
5916
5917
5918
5919
5920 <hr>
5921 <h3><a name="156"></a>156. Typo in <tt>imbue()</tt> description</h3>
5922 <p><b>Section:</b> 27.4.2.3 [ios.base.locales] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5923  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
5924 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.locales">issues</a> in [ios.base.locales].</p>
5925 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5926 <p><b>Discussion:</b></p>
5927 <p>There is a small discrepancy between the declarations of
5928 <tt>imbue()</tt>: in 27.4.2 [ios.base] the argument is passed as
5929 <tt>locale const&amp;</tt> (correct), in 27.4.2.3 [ios.base.locales] it
5930 is passed as <tt>locale const</tt> (wrong).</p>
5931
5932
5933 <p><b>Proposed resolution:</b></p>
5934 <p>In 27.4.2.3 [ios.base.locales] change the <tt>imbue</tt> argument
5935 from "<tt>locale const" to "locale
5936 const&amp;".</tt></p>
5937
5938
5939
5940
5941 <hr>
5942 <h3><a name="158"></a>158. Underspecified semantics for <tt>setbuf()</tt></h3>
5943 <p><b>Section:</b> 27.5.2.4.2 [streambuf.virt.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5944  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
5945 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.virt.buffer">issues</a> in [streambuf.virt.buffer].</p>
5946 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5947 <p><b>Discussion:</b></p>
5948 <p>The default behavior of <tt>setbuf()</tt> is described only for the
5949 situation that <tt>gptr() != 0 &amp;&amp; gptr() != egptr()</tt>:
5950 namely to do nothing.  What has to be done in other situations&nbsp;
5951 is not described although there is actually only one reasonable
5952 approach, namely to do nothing, too.</p>
5953
5954 <p>Since changing the buffer would almost certainly mess up most
5955 buffer management of derived classes unless these classes do it
5956 themselves, the default behavior of <tt>setbuf()</tt> should always be
5957 to do nothing.</p>
5958
5959
5960 <p><b>Proposed resolution:</b></p>
5961 <p>Change 27.5.2.4.2 [streambuf.virt.buffer], paragraph 3, Default behavior,
5962 to: "Default behavior: Does nothing. Returns this."</p>
5963
5964
5965
5966
5967 <hr>
5968 <h3><a name="159"></a>159. Strange use of <tt>underflow()</tt></h3>
5969 <p><b>Section:</b> 27.5.2.4.3 [streambuf.virt.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5970  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
5971 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5972 <p><b>Discussion:</b></p>
5973 <p>The description of the meaning of the result of
5974 <tt>showmanyc()</tt> seems to be rather strange: It uses calls to
5975 <tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
5976 this function only reads the current character but does not extract
5977 it, <tt>uflow()</tt> would extract the current character. This should
5978 be fixed to use <tt>sbumpc()</tt> instead.</p>
5979
5980
5981 <p><b>Proposed resolution:</b></p>
5982 <p>Change 27.5.2.4.3 [streambuf.virt.get] paragraph 1,
5983 <tt>showmanyc()</tt>returns clause, by replacing the word
5984 "supplied" with the words "extracted from the
5985 stream".</p>
5986
5987
5988
5989
5990 <hr>
5991 <h3><a name="160"></a>160. Typo: Use of non-existing function <tt>exception()</tt></h3>
5992 <p><b>Section:</b> 27.6.1.1 [istream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5993  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
5994 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream">issues</a> in [istream].</p>
5995 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5996 <p><b>Discussion:</b></p>
5997 <p>The paragraph 4 refers to the function <tt>exception()</tt> which
5998 is not defined. Probably, the referred function is
5999 <tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>
6000
6001
6002 <p><b>Proposed resolution:</b></p>
6003 <p>In 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted], paragraph 1,
6004 27.6.2.1 [ostream], paragraph 3, and 27.6.2.6.1 [ostream.formatted.reqmts],
6005 paragraph 1, change "<tt>exception()" to
6006 "exceptions()"</tt>.</p>
6007
6008 <p><i>[Note to Editor: "exceptions" with an "s"
6009 is the correct spelling.]</i></p>
6010
6011
6012
6013
6014
6015
6016 <hr>
6017 <h3><a name="161"></a>161. Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt></h3>
6018 <p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6019  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6020 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.formatted.arithmetic">active issues</a> in [istream.formatted.arithmetic].</p>
6021 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
6022 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6023 <p><b>Discussion:</b></p>
6024 <p>The note in the second paragraph pretends that the first argument
6025 is an object of type <tt>istream_iterator</tt>. This is wrong: It is
6026 an object of type <tt>istreambuf_iterator</tt>.</p>
6027
6028
6029 <p><b>Proposed resolution:</b></p>
6030 <p>Change 27.6.1.2.2 [istream.formatted.arithmetic] from:</p>
6031 <blockquote>
6032   <p>The first argument provides an object of the istream_iterator class...</p>
6033 </blockquote>
6034 <p>to</p>
6035 <blockquote>
6036   <p>The first argument provides an object of the istreambuf_iterator class...</p>
6037 </blockquote>
6038
6039
6040
6041
6042
6043 <hr>
6044 <h3><a name="164"></a>164. do_put() has apparently unused fill argument</h3>
6045 <p><b>Section:</b> 22.2.5.3.2 [locale.time.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6046  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-07-23</p>
6047 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6048 <p><b>Discussion:</b></p>
6049 <p>In 22.2.5.3.2 [locale.time.put.virtuals] the do_put() function is specified
6050 as taking a fill character as an argument, but the description of the
6051 function does not say whether the character is used at all and, if so,
6052 in which way. The same holds for any format control parameters that
6053 are accessible through the ios_base&amp; argument, such as the
6054 adjustment or the field width. Is strftime() supposed to use the fill
6055 character in any way? In any case, the specification of
6056 time_put.do_put() looks inconsistent to me.<br> <br> Is the
6057 signature of do_put() wrong, or is the effects clause incomplete?</p>
6058
6059
6060 <p><b>Proposed resolution:</b></p>
6061 <p>Add the following note after 22.2.5.3.2 [locale.time.put.virtuals]
6062 paragraph 2:</p>
6063 <blockquote>
6064   <p>  [Note: the <tt>fill</tt> argument may be used in the implementation-defined  formats, or by derivations.  A space character is a reasonable default
6065   for this argument. --end Note]</p>
6066 </blockquote>
6067
6068
6069 <p><b>Rationale:</b></p>
6070 <p>The LWG felt that while the normative text was correct,
6071 users need some guidance on what to pass for the <tt>fill</tt>
6072 argument since the standard doesn't say how it's used.</p>
6073
6074
6075
6076
6077 <hr>
6078 <h3><a name="165"></a>165. <tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3>
6079 <p><b>Section:</b> 27.6.2.1 [ostream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
6080  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6081 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream">issues</a> in [ostream].</p>
6082 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
6083 <p><b>Discussion:</b></p>
6084 <p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
6085 functions falling into one of the groups "formatted output functions"
6086 and "unformatted output functions" calls any stream buffer function
6087 which might call a virtual function other than <tt>overflow()</tt>. Basically
6088 this is fine but this implies that <tt>sputn()</tt> (this function would call
6089 the virtual function <tt>xsputn()</tt>) is never called by any of the standard
6090 output functions. Is this really intended? At minimum it would be convenient to
6091 call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
6092 is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
6093 with the definition of <tt>flush()</tt> which calls <tt>rdbuf()-&gt;pubsync()</tt>
6094 and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
6095 under "unformatted output functions").</p>
6096 <p>In addition, I guess that the sentence starting with "They may use other
6097 public members of <tt>basic_ostream</tt> ..." probably was intended to
6098 start with "They may use other public members of <tt>basic_streamuf</tt>..."
6099 although the problem with the virtual members exists in both cases.</p>
6100 <p>I see two obvious resolutions:</p>
6101 <ol>
6102   <li>state in a footnote that this means that <tt>xsputn()</tt> will never be
6103     called by any ostream member and that this is intended.</li>
6104   <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
6105     Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
6106 </ol>
6107
6108
6109 <p><b>Proposed resolution:</b></p>
6110 <p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
6111 <blockquote>
6112   <p>They may use other public members of basic_ostream except that they do not
6113   invoke any virtual members of rdbuf() except overflow().</p>
6114 </blockquote>
6115 <p>to:</p>
6116 <blockquote>
6117   <p>They may use other public members of basic_ostream except that they shall
6118   not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
6119   sync().</p>
6120 </blockquote>
6121
6122 <p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
6123 PJP why the standard is written this way.]</i></p>
6124
6125
6126 <p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
6127 LWG. He comments: The rules can be made a little bit more specific if
6128 necessary be explicitly spelling out what virtuals are allowed to be
6129 called from what functions and eg to state specifically that flush()
6130 is allowed to call sync() while other functions are not.]</i></p>
6131
6132
6133
6134
6135
6136
6137 <hr>
6138 <h3><a name="167"></a>167. Improper use of <tt>traits_type::length()</tt></h3>
6139 <p><b>Section:</b> 27.6.2.6.4 [ostream.inserters.character] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
6140  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6141 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.character">issues</a> in [ostream.inserters.character].</p>
6142 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
6143 <p><b>Discussion:</b></p>
6144 <p>Paragraph 4 states that the length is determined using
6145 <tt>traits::length(s)</tt>.  Unfortunately, this function is not
6146 defined for example if the character type is <tt>wchar_t</tt> and the
6147 type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
6148 the character type is <tt>char</tt> and the type of <tt>s</tt> is
6149 either <tt>signed char const*</tt> or <tt>unsigned char
6150 const*</tt>.</p>
6151
6152
6153 <p><b>Proposed resolution:</b></p>
6154 <p>Change 27.6.2.6.4 [ostream.inserters.character] paragraph 4 from:</p>
6155 <blockquote>
6156   <p>Effects: Behaves like an formatted inserter (as described in
6157   lib.ostream.formatted.reqmts) of out. After a sentry object is
6158   constructed it inserts characters. The number of characters starting
6159   at s to be inserted is traits::length(s). Padding is determined as
6160   described in lib.facet.num.put.virtuals. The traits::length(s)
6161   characters starting at s are widened using out.widen
6162   (lib.basic.ios.members). The widened characters and any required
6163   padding are inserted into out. Calls width(0).</p>
6164 </blockquote>
6165 <p>to:</p>
6166 <blockquote>
6167   <p>Effects: Behaves like a formatted inserter (as described in
6168   lib.ostream.formatted.reqmts) of out. After a sentry object is
6169   constructed it inserts <i>n</i> characters starting at <i>s</i>,
6170   where <i>n</i> is the number that would be computed as if by:</p>
6171   <ul>
6172   <li>traits::length(s) for the overload where the first argument is of
6173     type basic_ostream&lt;charT, traits&gt;&amp; and the second is
6174     of type const charT*, and also for the overload where the first
6175     argument is of type basic_ostream&lt;char, traits&gt;&amp; and
6176     the second is of type const char*.</li>
6177   <li>std::char_traits&lt;char&gt;::length(s)
6178     for the overload where the first argument is of type
6179     basic_ostream&lt;charT, traits&gt;&amp; and the second is of type
6180     const char*.</li>
6181   <li>traits::length(reinterpret_cast&lt;const char*&gt;(s))
6182     for the other two overloads.</li>
6183   </ul>
6184   <p>Padding is determined as described in
6185   lib.facet.num.put.virtuals. The <i>n</i> characters starting at
6186   <i>s</i> are widened using out.widen (lib.basic.ios.members).  The
6187   widened characters and any required padding are inserted into
6188   out. Calls width(0).</p>
6189 </blockquote>
6190
6191 <p><i>[Santa Cruz: Matt supplied new wording]</i></p>
6192
6193
6194 <p><i>[Kona: changed "where <i>n</i> is" to " where <i>n</i> is the
6195   number that would be computed as if by"]</i></p>
6196
6197
6198
6199
6200 <p><b>Rationale:</b></p>
6201 <p>We have five separate cases.  In two of them we can use the
6202 user-supplied traits class without any fuss.  In the other three we
6203 try to use something as close to that user-supplied class as possible.
6204 In two cases we've got a traits class that's appropriate for
6205 char and what we've got is a const signed char* or a const
6206 unsigned char*; that's close enough so we can just use a reinterpret
6207 cast, and continue to use the user-supplied traits class.  Finally,
6208 there's one case where we just have to give up: where we've got a
6209 traits class for some arbitrary charT type, and we somehow have to
6210 deal with a const char*.  There's nothing better to do but fall back
6211 to char_traits&lt;char&gt;</p>
6212
6213
6214
6215
6216
6217 <hr>
6218 <h3><a name="168"></a>168. Typo: formatted vs. unformatted</h3>
6219 <p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6220  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6221 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p>
6222 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6223 <p><b>Discussion:</b></p>
6224 <p>The first paragraph begins with a descriptions what has to be done
6225 in <i>formatted</i> output functions. Probably this is a typo and the
6226 paragraph really want to describe unformatted output functions...</p>
6227
6228
6229 <p><b>Proposed resolution:</b></p>
6230 <p>In 27.6.2.7 [ostream.unformatted] paragraph 1, the first and last
6231 sentences, change the word "formatted" to
6232 "unformatted":</p>
6233 <blockquote>
6234   <p>"Each <b>unformatted </b> output function begins ..."<br>
6235   "... value specified for the <b>unformatted </b>  output
6236   function."</p>
6237 </blockquote>
6238
6239
6240
6241
6242 <hr>
6243 <h3><a name="169"></a>169. Bad efficiency of <tt>overflow()</tt> mandated</h3>
6244 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6245  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6246 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
6247 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
6248 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6249 <p><b>Discussion:</b></p>
6250 <p>Paragraph 8, Notes, of this section seems to mandate an extremely
6251 inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
6252 especially in view of the restriction that <tt>basic_ostream</tt>
6253 member functions are not allowed to use <tt>xsputn()</tt> (see 27.6.2.1 [ostream]): For each character to be inserted, a new buffer
6254 is to be created.</p>
6255 <p>Of course, the resolution below requires some handling of
6256 simultaneous input and output since it is no longer possible to update
6257 <tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
6258 solution is to handle this in <tt>underflow()</tt>.</p>
6259
6260
6261 <p><b>Proposed resolution:</b></p>
6262 <p>In 27.7.1.4 [stringbuf.virtuals] paragraph 8, Notes, insert the words
6263 "at least" as in the following:</p>
6264 <blockquote>
6265   <p>To make a write position available, the function reallocates (or initially
6266   allocates) an array object with a sufficient number of elements to hold the
6267   current array object (if any), plus <b>at least</b> one additional write
6268   position.</p>
6269 </blockquote>
6270
6271
6272
6273
6274 <hr>
6275 <h3><a name="170"></a>170. Inconsistent definition of <tt>traits_type</tt></h3>
6276 <p><b>Section:</b> 27.7.4 [stringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6277  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6278 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6279 <p><b>Discussion:</b></p>
6280 <p>The classes <tt>basic_stringstream</tt> (27.7.4 [stringstream]),
6281 <tt>basic_istringstream</tt> (27.7.2 [istringstream]), and
6282 <tt>basic_ostringstream</tt> (27.7.3 [ostringstream]) are inconsistent
6283 in their definition of the type <tt>traits_type</tt>: For
6284 <tt>istringstream</tt>, this type is defined, for the other two it is
6285 not. This should be consistent.</p>
6286
6287
6288 <p><b>Proposed resolution:</b></p>
6289 <p><b>Proposed resolution:</b></p> <p>To the declarations of
6290 <tt>basic_ostringstream</tt> (27.7.3 [ostringstream]) and
6291 <tt>basic_stringstream</tt> (27.7.4 [stringstream]) add:</p>
6292 <blockquote>
6293 <pre>typedef traits traits_type;</pre>
6294 </blockquote>
6295
6296
6297
6298
6299 <hr>
6300 <h3><a name="171"></a>171. Strange <tt>seekpos()</tt> semantics due to joint position</h3>
6301 <p><b>Section:</b> 27.8.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
6302  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6303 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.virtuals">issues</a> in [filebuf.virtuals].</p>
6304 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
6305 <p><b>Discussion:</b></p>
6306 <p>Overridden virtual functions, seekpos()</p> <p>In 27.8.1.1 [filebuf] paragraph 3, it is stated that a joint input and
6307 output position is maintained by <tt>basic_filebuf</tt>. Still, the
6308 description of <tt>seekpos()</tt> seems to talk about different file
6309 positions. In particular, it is unclear (at least to me) what is
6310 supposed to happen to the output buffer (if there is one) if only the
6311 input position is changed. The standard seems to mandate that the
6312 output buffer is kept and processed as if there was no positioning of
6313 the output position (by changing the input position). Of course, this
6314 can be exactly what you want if the flag <tt>ios_base::ate</tt> is
6315 set. However, I think, the standard should say something like
6316 this:</p>
6317 <ul>
6318   <li>If <tt>(which &amp; mode) == 0</tt> neither read nor write position is
6319     changed and the call fails. Otherwise, the joint read and write position is
6320     altered to correspond to <tt>sp</tt>.</li>
6321   <li>If there is an output buffer, the output sequences is updated and any
6322     unshift sequence is written before the position is altered.</li>
6323   <li>If there is an input buffer, the input sequence is updated after the
6324     position is altered.</li>
6325 </ul>
6326 <p>Plus the appropriate error handling, that is...</p>
6327
6328
6329 <p><b>Proposed resolution:</b></p>
6330 <p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
6331 paragraph 14 from:</p>
6332 <blockquote>
6333   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
6334   ios_base::out);</p>
6335   <p>Alters the file position, if possible, to correspond to the position stored
6336   in sp (as described below).</p>
6337   <p>- if (which&amp;ios_base::in)!=0, set the file position to sp, then update
6338   the input sequence</p>
6339   <p>- if (which&amp;ios_base::out)!=0, then update the output sequence, write
6340   any unshift sequence, and set the file position to sp.</p>
6341 </blockquote>
6342 <p>to:</p>
6343 <blockquote>
6344   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
6345   ios_base::out);</p>
6346   <p>Alters the file position, if possible, to correspond to the position stored
6347   in sp (as described below). Altering the file position performs as follows:</p>
6348   <p>1. if (om &amp; ios_base::out)!=0, then update the output sequence and
6349   write any unshift sequence;</p>
6350   <p>2. set the file position to sp;</p>
6351   <p>3. if (om &amp; ios_base::in)!=0, then update the input sequence;</p>
6352   <p>where om is the open mode passed to the last call to open(). The operation
6353   fails if is_open() returns false.</p>
6354 </blockquote>
6355
6356 <p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
6357
6358 <p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
6359
6360
6361
6362
6363
6364
6365 <hr>
6366 <h3><a name="172"></a>172. Inconsistent types for <tt>basic_istream::ignore()</tt></h3>
6367 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6368  <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 1999-07-23</p>
6369 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
6370 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
6371 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6372 <p><b>Discussion:</b></p>
6373 <p>In 27.6.1.1 [istream] the function
6374 <tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
6375 argument. However, in 27.6.1.3 [istream.unformatted]
6376 paragraph 23 the first argument is of type <tt>int.</tt></p>
6377
6378 <p>As far as I can see this is not really a contradiction because
6379 everything is consistent if <tt>streamsize</tt> is typedef to be
6380 <tt>int</tt>. However, this is almost certainly not what was
6381 intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
6382 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>.</p>
6383
6384 <p>Darin Adler also
6385 submitted this issue, commenting: Either 27.6.1.1 should be modified
6386 to show a first parameter of type int, or 27.6.1.3 should be modified
6387 to show a first parameter of type streamsize and use
6388 numeric_limits&lt;streamsize&gt;::max.</p>
6389
6390
6391 <p><b>Proposed resolution:</b></p>
6392 <p>In 27.6.1.3 [istream.unformatted] paragraph 23 and 24, change both uses
6393 of <tt>int</tt> in the description of <tt>ignore()</tt> to
6394 <tt>streamsize</tt>.</p>
6395
6396
6397
6398
6399 <hr>
6400 <h3><a name="173"></a>173. Inconsistent types for <tt>basic_filebuf::setbuf()</tt></h3>
6401 <p><b>Section:</b> 27.8.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6402  <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 1999-07-23</p>
6403 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.virtuals">issues</a> in [filebuf.virtuals].</p>
6404 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6405 <p><b>Discussion:</b></p>
6406
6407 <p>
6408 In 27.8.1.1 [filebuf] the function <tt>setbuf()</tt> gets an
6409 object of type <tt>streamsize</tt> as second argument. However, in
6410 27.8.1.5 [filebuf.virtuals] paragraph 9 the second argument is of type
6411 <tt>int</tt>.
6412 </p>
6413
6414 <p>
6415 As far as I can see this is not really a contradiction because
6416 everything is consistent if <tt>streamsize</tt> is typedef to be
6417 <tt>int</tt>. However, this is almost certainly not what was
6418 intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
6419 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>.
6420 </p>
6421
6422
6423
6424 <p><b>Proposed resolution:</b></p>
6425 <p>In 27.8.1.5 [filebuf.virtuals] paragraph 9, change all uses of
6426 <tt>int</tt> in the description of <tt>setbuf()</tt> to
6427 <tt>streamsize</tt>.</p>
6428
6429
6430
6431
6432 <hr>
6433 <h3><a name="174"></a>174. Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt></h3>
6434 <p><b>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6435  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-23</p>
6436 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</p>
6437 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6438 <p><b>Discussion:</b></p>
6439 <p>According to paragraph 1 of this section, <tt>streampos</tt> is the
6440 type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
6441 paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt></p>
6442
6443
6444 <p><b>Proposed resolution:</b></p>
6445 <p>Change D.6 [depr.ios.members] paragraph 1 from "<tt>typedef
6446 OFF_T streampos;</tt>" to "<tt>typedef POS_T
6447 streampos;</tt>"</p>
6448
6449
6450
6451
6452 <hr>
6453 <h3><a name="175"></a>175. Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3>
6454 <p><b>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6455  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-23</p>
6456 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</p>
6457 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6458 <p><b>Discussion:</b></p>
6459 <p>According to paragraph 8 of this section, the methods
6460 <tt>basic_streambuf::pubseekpos()</tt>,
6461 <tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
6462 "may" be overloaded by a version of this function taking the
6463 type <tt>ios_base::open_mode</tt> as last argument argument instead of
6464 <tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
6465 in this section to be an alias for one of the integral types). The
6466 clause specifies, that the last argument has a default argument in
6467 three cases.  However, this generates an ambiguity with the overloaded
6468 version because now the arguments are absolutely identical if the last
6469 argument is not specified.</p>
6470
6471
6472 <p><b>Proposed resolution:</b></p>
6473 <p>In D.6 [depr.ios.members] paragraph 8, remove the default arguments for
6474 <tt>basic_streambuf::pubseekpos()</tt>,
6475 <tt>basic_ifstream::open()</tt>, and
6476 <tt>basic_ofstream::open().</tt></p>
6477
6478
6479
6480
6481 <hr>
6482 <h3><a name="176"></a>176. <tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3>
6483 <p><b>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6484  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-23</p>
6485 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</p>
6486 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6487 <p><b>Discussion:</b></p>
6488 <p>The "overload" for the function <tt>exceptions()</tt> in
6489 paragraph 8 gives the impression that there is another function of
6490 this function defined in class <tt>ios_base</tt>. However, this is not
6491 the case. Thus, it is hard to tell how the semantics (paragraph 9) can
6492 be implemented: "Call the corresponding member function specified
6493 in clause 27 [input.output]."</p>
6494
6495
6496 <p><b>Proposed resolution:</b></p>
6497 <p>In D.6 [depr.ios.members] paragraph 8, move the declaration of the
6498 function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
6499
6500
6501
6502
6503 <hr>
6504 <h3><a name="179"></a>179. Comparison of const_iterators to iterators doesn't work</h3>
6505 <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
6506  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-07-02</p>
6507 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
6508 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
6509 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
6510 <p><b>Discussion:</b></p>
6511 <p>Currently the following will not compile on two well-known standard
6512 library implementations:</p>
6513
6514 <blockquote>
6515   <pre>#include &lt;set&gt;
6516 using namespace std;
6517
6518 void f(const set&lt;int&gt; &amp;s)
6519 {
6520   set&lt;int&gt;::iterator i;
6521   if (i==s.end()); // s.end() returns a const_iterator
6522 }</pre>
6523 </blockquote>
6524
6525 <p>
6526 The reason this doesn't compile is because operator== was implemented
6527 as a member function of the nested classes set:iterator and
6528 set::const_iterator, and there is no conversion from const_iterator to
6529 iterator. Surprisingly, (s.end() == i) does work, though, because of
6530 the conversion from iterator to const_iterator.
6531 </p>
6532
6533 <p>
6534 I don't see a requirement anywhere in the standard that this must
6535 work. Should there be one?  If so, I think the requirement would need
6536 to be added to the tables in section 24.1.1. I'm not sure about the
6537 wording.  If this requirement existed in the standard, I would think
6538 that implementors would have to make the comparison operators
6539 non-member functions.</p>
6540
6541 <p>This issues was also raised on comp.std.c++ by Darin
6542 Adler.&nbsp; The example given was:</p>
6543
6544 <blockquote>
6545   <pre>bool check_equal(std::deque&lt;int&gt;::iterator i,
6546 std::deque&lt;int&gt;::const_iterator ci)
6547 {
6548 return i == ci;
6549 }</pre>
6550 </blockquote>
6551
6552 <p>Comment from John Potter:</p>
6553 <blockquote>
6554     <p>
6555     In case nobody has noticed, accepting it will break reverse_iterator.
6556     </p>
6557
6558     <p>
6559     The fix is to make the comparison operators templated on two types.
6560     </p>
6561
6562     <pre>    template &lt;class Iterator1, class Iterator2&gt;
6563     bool operator== (reverse_iterator&lt;Iterator1&gt; const&amp; x,
6564                      reverse_iterator&lt;Iterator2&gt; const&amp; y);
6565     </pre>
6566
6567     <p>
6568     Obviously:  return x.base() == y.base();
6569     </p>
6570
6571     <p>
6572     Currently, no reverse_iterator to const_reverse_iterator compares are
6573     valid.
6574     </p>
6575
6576     <p>
6577     BTW, I think the issue is in support of bad code.  Compares should be
6578     between two iterators of the same type.  All std::algorithms require
6579     the begin and end iterators to be of the same type.
6580     </p>
6581 </blockquote>
6582
6583
6584 <p><b>Proposed resolution:</b></p>
6585 <p>Insert this paragraph after 23.1 [container.requirements] paragraph 7:</p>
6586 <blockquote>
6587   <p>In the expressions</p>
6588   <pre>    i == j
6589     i != j
6590     i &lt; j
6591     i &lt;= j
6592     i &gt;= j
6593     i &gt; j
6594     i - j
6595   </pre>
6596   <p>Where i and j denote objects of a container's iterator type,
6597   either or both may be replaced by an object of the container's
6598   const_iterator type referring to the same element with no
6599   change in semantics.</p>
6600 </blockquote>
6601
6602 <p><i>[post-Toronto: Judy supplied a proposed resolution saying that
6603 <tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
6604 iterator comparison and difference operations.]</i></p>
6605
6606
6607 <p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
6608 explicitly listed expressions; there was concern that the previous
6609 proposed resolution was too informal.]</i></p>
6610
6611
6612
6613 <p><b>Rationale:</b></p>
6614 <p>
6615 The LWG believes it is clear that the above wording applies only to
6616 the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
6617 where <tt>X</tt> is a container.  There is no requirement that
6618 <tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
6619 can be mixed.  If mixing them is considered important, that's a
6620 separate issue.  (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>.)
6621 </p>
6622
6623
6624
6625
6626 <hr>
6627 <h3><a name="181"></a>181. make_pair() unintended behavior</h3>
6628 <p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6629  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-03</p>
6630 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
6631 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6632 <p><b>Discussion:</b></p>
6633 <p>The claim has surfaced in Usenet that expressions such as<br>
6634 <br>
6635 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>make_pair("abc", 3)</tt><br>
6636 <br>
6637 are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
6638 parameter to <tt> const char (&amp;)[4]</tt>, which type is uncopyable.<br>
6639 <br>
6640 I doubt anyone intended that behavior...
6641 </p>
6642
6643
6644 <p><b>Proposed resolution:</b></p>
6645 <p>In 20.2 [utility], paragraph 1 change the following
6646 declaration of make_pair():</p>
6647 <blockquote>
6648   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(const T1&amp;, const T2&amp;);</pre>
6649 </blockquote>
6650 <p>to:</p>
6651 <blockquote>
6652   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(T1, T2);</pre>
6653 </blockquote>
6654 <p>  In 20.2.3 [pairs] paragraph 7 and the line before, change:</p>
6655 <blockquote>
6656 <pre>template &lt;class T1, class T2&gt;
6657 pair&lt;T1, T2&gt; make_pair(const T1&amp; x, const T2&amp; y);</pre>
6658 </blockquote>
6659 <p>to:</p>
6660 <blockquote>
6661 <pre>template &lt;class T1, class T2&gt;
6662 pair&lt;T1, T2&gt; make_pair(T1 x, T2 y);</pre>
6663 </blockquote>
6664 <p>and add the following footnote to the effects clause:</p>
6665 <blockquote>
6666   <p> According to 12.8 [class.copy], an implementation is permitted
6667   to not perform a copy of an argument, thus avoiding unnecessary
6668   copies.</p>
6669 </blockquote>
6670
6671
6672 <p><b>Rationale:</b></p>
6673 <p>Two potential fixes were suggested by Matt Austern and Dietmar
6674 Kühl, respectively, 1) overloading with array arguments, and 2) use of
6675 a reference_traits class with a specialization for arrays.  Andy
6676 Koenig suggested changing to pass by value. In discussion, it appeared
6677 that this was a much smaller change to the standard that the other two
6678 suggestions, and any efficiency concerns were more than offset by the
6679 advantages of the solution. Two implementors reported that the
6680 proposed resolution passed their test suites.</p>
6681
6682
6683
6684
6685 <hr>
6686 <h3><a name="182"></a>182. Ambiguous references to size_t</h3>
6687 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
6688  <b>Submitter:</b> Al Stevens <b>Date:</b> 1999-08-15</p>
6689 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
6690 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
6691 <p><b>Discussion:</b></p>
6692 <p>Many references to <tt> size_t</tt> throughout the document
6693 omit the <tt> std::</tt> namespace qualification.</p> <p>For
6694 example, 17.4.3.4 [replacement.functions] paragraph 2:</p>
6695 <blockquote>
6696 <pre> operator new(size_t)
6697  operator new(size_t, const std::nothrow_t&amp;)
6698  operator new[](size_t)
6699  operator new[](size_t, const std::nothrow_t&amp;)</pre>
6700 </blockquote>
6701
6702
6703 <p><b>Proposed resolution:</b></p>
6704 <p>   In 17.4.3.4 [replacement.functions] paragraph 2: replace:</p>
6705 <blockquote>
6706 <p><tt>     - operator new(size_t)<br>
6707      - operator new(size_t, const std::nothrow_t&amp;)<br>
6708      - operator new[](size_t)<br>
6709      - operator new[](size_t, const std::nothrow_t&amp;)</tt></p>
6710 </blockquote>
6711 <p>    by:</p>
6712 <blockquote>
6713 <pre>- operator new(std::size_t)
6714 - operator new(std::size_t, const std::nothrow_t&amp;)
6715 - operator new[](std::size_t)
6716 - operator new[](std::size_t, const std::nothrow_t&amp;)</pre>
6717 </blockquote>
6718 <p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
6719 <blockquote>
6720   <p>The typedef members pointer, const_pointer, size_type, and difference_type
6721   are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
6722 </blockquote>
6723 <p>&nbsp;by:</p>
6724 <blockquote>
6725   <p>The typedef members pointer, const_pointer, size_type, and difference_type
6726   are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
6727   respectively.</p>
6728 </blockquote>
6729 <p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
6730 <blockquote>
6731   <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
6732   <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
6733   is unspecified when or how often this function is called. The use of hint is
6734   unspecified, but intended as an aid to locality if an implementation so
6735   desires.</p>
6736 </blockquote>
6737 <p>by:</p>
6738 <blockquote>
6739   <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
6740   <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
6741   it is unspecified when or how often this function is called. The use of hint
6742   is unspecified, but intended as an aid to locality if an implementation so
6743   desires.</p>
6744 </blockquote>
6745 <p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
6746 <blockquote>
6747   <p>In Table 37, X denotes a Traits class defining types and functions for the
6748   character container type CharT; c and d denote values of type CharT; p and q
6749   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
6750   j denote values of type size_t; e and f denote values of type X::int_type; pos
6751   denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
6752 </blockquote>
6753 <p>by:</p>
6754 <blockquote>
6755   <p>In Table 37, X denotes a Traits class defining types and functions for the
6756   character container type CharT; c and d denote values of type CharT; p and q
6757   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
6758   j denote values of type std::size_t; e and f denote values of type X::int_type;
6759   pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
6760 </blockquote>
6761 <p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
6762 X::length(p): "size_t" by "std::size_t".</p>
6763 <p>   In [lib.std.iterator.tags] 24.3.3, paragraph 2:    replace:<br>
6764 &nbsp;&nbsp;&nbsp; typedef ptrdiff_t difference_type;<br>
6765     by:<br>
6766 &nbsp;&nbsp;&nbsp; typedef std::ptrdiff_t difference_type;</p>
6767 <p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the
6768 declaration of template &lt;class charT&gt; class ctype.<br>
6769 <br>
6770    In [lib.iterator.traits] 24.3.1, paragraph 2    put namespace std { ...} around the declaration of:<br>
6771 <br>
6772 &nbsp;&nbsp;&nbsp; template&lt;class Iterator&gt; struct iterator_traits<br>
6773 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;T*&gt;<br>
6774 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;const T*&gt;</p>
6775
6776
6777 <p><b>Rationale:</b></p>
6778 <p>The LWG believes correcting names like <tt>size_t</tt> and
6779 <tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
6780 to be essentially editorial.  There there can't be another size_t or
6781 ptrdiff_t meant anyway because, according to 17.4.3.1.4 [extern.types],</p>
6782
6783 <blockquote><p>
6784 For each type T from the Standard C library, the types ::T and std::T
6785 are reserved to the implementation and, when defined, ::T shall be
6786 identical to std::T.
6787 </p></blockquote>
6788
6789 <p>The issue is treated as a Defect Report to make explicit the Project
6790 Editor's authority to make this change.</p>
6791
6792 <p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
6793 request of the LWG.]</i></p>
6794
6795
6796 <p><i>[Toronto: This is tangentially related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>, but only tangentially: the intent of this issue is to
6797 address use of the name <tt>size_t</tt> in contexts outside of
6798 namespace std, such as in the description of <tt>::operator new</tt>.
6799 The proposed changes should be reviewed to make sure they are
6800 correct.]</i></p>
6801
6802
6803 <p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
6804 them to be correct.]</i></p>
6805
6806
6807
6808
6809
6810
6811
6812 <hr>
6813 <h3><a name="183"></a>183. I/O stream manipulators don't work for wide character streams</h3>
6814 <p><b>Section:</b> 27.6.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
6815  <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1999-07-07</p>
6816 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#std.manip">issues</a> in [std.manip].</p>
6817 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
6818 <p><b>Discussion:</b></p>
6819 <p>27.6.3 [std.manip] paragraph 3 says (clause numbering added for
6820 exposition):</p>
6821 <blockquote>
6822 <p>Returns: An object s of unspecified type such that if [1] out is an (instance
6823 of) basic_ostream then the expression out&lt;&lt;s behaves as if f(s) were
6824 called, and if [2] in is an (instance of) basic_istream then the expression
6825 in&gt;&gt;s behaves as if f(s) were called. Where f can be defined as: ios_base&amp;
6826 f(ios_base&amp; str, ios_base::fmtflags mask) { // reset specified flags
6827 str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
6828 out&lt;&lt;s has type ostream&amp; and value out. [4] The expression in&gt;&gt;s
6829 has type istream&amp; and value in.</p>
6830 </blockquote>
6831 <p>Given the definitions [1] and [2] for out and in, surely [3] should read:
6832 "The expression out &lt;&lt; s has type basic_ostream&amp; ..." and
6833 [4] should read: "The expression in &gt;&gt; s has type basic_istream&amp;
6834 ..."</p>
6835 <p>If the wording in the standard is correct, I can see no way of implementing
6836 any of the manipulators so that they will work with wide character streams.</p>
6837 <p>e.g. wcout &lt;&lt; setbase( 16 );</p>
6838 <p>Must have value 'wcout' (which makes sense) and type 'ostream&amp;' (which
6839 doesn't).</p>
6840 <p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
6841 8. In addition, Para 6 [setfill] has a similar error, but relates only to
6842 ostreams.</p>
6843 <p>I'd be happier if there was a better way of saying this, to make it clear
6844 that the value of the expression is "the same specialization of
6845 basic_ostream as out"&amp;</p>
6846
6847
6848 <p><b>Proposed resolution:</b></p>
6849 <p>Replace section 27.6.3 [std.manip] except paragraph 1 with the
6850 following:</p>
6851 <blockquote>
6852 <p>2- The type designated smanip in each of the following function
6853 descriptions is implementation-specified and may be different for each
6854 function.<br>
6855 <br>
6856 <tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
6857 <br>
6858 -3- Returns: An object s of unspecified type such that if out is an
6859 instance of basic_ostream&lt;charT,traits&gt; then the expression
6860 out&lt;&lt;s behaves
6861 as if f(s, mask) were called, or if in is an instance of
6862 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
6863 behaves as if
6864 f(s, mask) were called. The function f can be defined as:*<br>
6865 <br>
6866 [Footnote: The expression cin &gt;&gt; resetiosflags(ios_base::skipws)
6867 clears ios_base::skipws in the format flags stored in the
6868 basic_istream&lt;charT,traits&gt; object cin (the same as cin &gt;&gt;
6869 noskipws), and the expression cout &lt;&lt;
6870 resetiosflags(ios_base::showbase) clears
6871 ios_base::showbase in the format flags stored in the
6872 basic_ostream&lt;charT,traits&gt; object cout (the same as cout
6873 &lt;&lt;
6874 noshowbase). --- end footnote]<br>
6875 <br>
6876 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
6877 &nbsp;&nbsp; {<br>
6878 &nbsp;&nbsp; //  reset specified flags<br>
6879 &nbsp;&nbsp; str.setf(ios_base::fmtflags(0), mask);<br>
6880 &nbsp;&nbsp; return str;<br>
6881 &nbsp;&nbsp; }<br>
6882 </tt><br>
6883 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
6884 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
6885 <br>
6886 &nbsp;<tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
6887 <br>
6888 -4- Returns: An object s of unspecified type such that if out is an
6889 instance of basic_ostream&lt;charT,traits&gt; then the expression
6890 out&lt;&lt;s behaves
6891 as if f(s, mask) were called, or if in is an instance of
6892 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
6893 behaves as if f(s,
6894 mask) were called. The function f can be defined as:<br>
6895 <br>
6896 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
6897 &nbsp;&nbsp; {<br>
6898 &nbsp;&nbsp; //  set specified flags<br>
6899 &nbsp;&nbsp; str.setf(mask);<br>
6900 &nbsp;&nbsp; return str;<br>
6901 &nbsp;&nbsp; }<br>
6902 </tt><br>
6903 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
6904 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
6905 <br>
6906 <tt>smanip setbase(int base);</tt><br>
6907 <br>
6908 -5- Returns: An object s of unspecified type such that if out is an
6909 instance of basic_ostream&lt;charT,traits&gt; then the expression
6910 out&lt;&lt;s behaves
6911 as if f(s, base) were called, or if in is an instance of
6912 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
6913 behaves as if f(s,
6914 base) were called. The function f can be defined as:<br>
6915 <br>
6916 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int base)<br>
6917 &nbsp;&nbsp; {<br>
6918 &nbsp;&nbsp; //  set  basefield<br>
6919 &nbsp;&nbsp; str.setf(base ==  8 ? ios_base::oct :<br>
6920 &nbsp;&nbsp; base == 10 ? ios_base::dec :<br>
6921 &nbsp;&nbsp; base == 16 ? ios_base::hex :<br>
6922 &nbsp;&nbsp; ios_base::fmtflags(0), ios_base::basefield);<br>
6923 &nbsp;&nbsp; return str;<br>
6924 &nbsp;&nbsp; }<br>
6925 </tt><br>
6926 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
6927 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
6928 <br>
6929 <tt>smanip setfill(char_type c);<br>
6930 </tt><br>
6931 -6- Returns: An object s of unspecified type such that if out is (or is
6932 derived from) basic_ostream&lt;charT,traits&gt; and c has type charT
6933 then the
6934 expression out&lt;&lt;s behaves as if f(s, c) were called. The function
6935 f can be
6936 defined as:<br>
6937 <br>
6938 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>template&lt;class charT, class traits&gt;<br>
6939 &nbsp;&nbsp; basic_ios&lt;charT,traits&gt;&amp; f(basic_ios&lt;charT,traits&gt;&amp; str, charT c)<br>
6940 &nbsp;&nbsp; {<br>
6941 &nbsp;&nbsp; //  set fill character<br>
6942 &nbsp;&nbsp; str.fill(c);<br>
6943 &nbsp;&nbsp; return str;<br>
6944 &nbsp;&nbsp; }<br>
6945 </tt><br>
6946 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.<br>
6947 <br>
6948 <tt>smanip setprecision(int n);</tt><br>
6949 <br>
6950 -7- Returns: An object s of unspecified type such that if out is an
6951 instance of basic_ostream&lt;charT,traits&gt; then the expression
6952 out&lt;&lt;s behaves
6953 as if f(s, n) were called, or if in is an instance of
6954 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
6955 behaves as if f(s, n)
6956 were called. The function f can be defined as:<br>
6957 <br>
6958 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
6959 &nbsp;&nbsp; {<br>
6960 &nbsp;&nbsp; //  set precision<br>
6961 &nbsp;&nbsp; str.precision(n);<br>
6962 &nbsp;&nbsp; return str;<br>
6963 &nbsp;&nbsp; }<br>
6964 </tt><br>
6965 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
6966 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in<br>
6967 .<br>
6968 <tt>smanip setw(int n);<br>
6969 </tt><br>
6970 -8- Returns: An object s of unspecified type such that if out is an
6971 instance of basic_ostream&lt;charT,traits&gt; then the expression
6972 out&lt;&lt;s behaves
6973 as if f(s, n) were called, or if in is an instance of
6974 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
6975 behaves as if f(s, n)
6976 were called. The function f can be defined as:<br>
6977 <br>
6978 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
6979 &nbsp;&nbsp; {<br>
6980 &nbsp;&nbsp; //  set width<br>
6981 &nbsp;&nbsp; str.width(n);<br>
6982 &nbsp;&nbsp; return str;<br>
6983 &nbsp;&nbsp; }<br>
6984 </tt><br>
6985 The expression out&lt;&lt;s has type
6986 basic_ostream&lt;charT,traits&gt;&amp; and value out.  The expression
6987 in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value
6988 in.
6989 </p>
6990 </blockquote>
6991
6992 <p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
6993 the proposed resolution.]</i></p>
6994
6995
6996 <p><i>[Tokyo - The LWG noted that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> involves
6997 the same paragraphs.]</i></p>
6998
6999
7000 <p><i>[Post-Tokyo: The issues list maintainer combined the proposed
7001 resolution of this issue with the proposed resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> as they both involved the same paragraphs, and were so
7002 intertwined that dealing with them separately appear fraught with
7003 error.  The full text was supplied by Bill Plauger; it was cross
7004 checked against changes supplied by Andy Sawyer. It should be further
7005 checked by the LWG.]</i></p>
7006
7007
7008
7009
7010
7011
7012 <hr>
7013 <h3><a name="184"></a>184. numeric_limits&lt;bool&gt; wording problems</h3>
7014 <p><b>Section:</b> 18.2.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7015  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 1999-07-21</p>
7016 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.special">issues</a> in [numeric.special].</p>
7017 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7018 <p><b>Discussion:</b></p>
7019 <p>bools are defined by the standard to be of integer types, as per
7020 3.9.1 [basic.fundamental] paragraph 7.  However "integer types"
7021 seems to have a special meaning for the author of 18.2. The net effect
7022 is an unclear and confusing specification for
7023 numeric_limits&lt;bool&gt; as evidenced below.</p>
7024
7025 <p>18.2.1.2/7 says numeric_limits&lt;&gt;::digits is, for built-in integer
7026 types, the number of non-sign bits in the representation.</p>
7027
7028 <p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
7029 arithmetical value converts to true.</p>
7030
7031 <p>I don't think it makes sense at all to require
7032 numeric_limits&lt;bool&gt;::digits and numeric_limits&lt;bool&gt;::digits10 to
7033 be meaningful.</p>
7034
7035 <p>The standard defines what constitutes a signed (resp. unsigned) integer
7036 types. It doesn't categorize bool as being signed or unsigned. And the set of
7037 values of bool type has only two elements.</p>
7038
7039 <p>I don't think it makes sense to require numeric_limits&lt;bool&gt;::is_signed
7040 to be meaningful.</p>
7041
7042 <p>18.2.1.2/18 for numeric_limits&lt;integer_type&gt;::radix&nbsp; says:</p>
7043 <blockquote>
7044   <p>For integer types, specifies the base of the representation.186)</p>
7045 </blockquote>
7046
7047 <p>This disposition is at best misleading and confusing for the standard
7048 requires a "pure binary numeration system" for integer types as per
7049 3.9.1/7</p>
7050
7051 <p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
7052 BCD)."&nbsp; This also erroneous as the standard never defines any integer
7053 types with base representation other than 2.</p>
7054
7055 <p>Furthermore, numeric_limits&lt;bool&gt;::is_modulo and
7056 numeric_limits&lt;bool&gt;::is_signed have similar problems.</p>
7057
7058
7059 <p><b>Proposed resolution:</b></p>
7060 <p>Append to the end of 18.2.1.5 [numeric.special]:</p>
7061 <blockquote>
7062   <p>The specialization for bool shall be provided as follows:</p>
7063   <pre>    namespace std {
7064        template&lt;&gt; class numeric_limits&lt;bool&gt; {
7065        public:
7066          static const bool is_specialized = true;
7067          static bool min() throw() { return false; }
7068          static bool max() throw() { return true; }
7069
7070          static const int  digits = 1;
7071          static const int  digits10 = 0;
7072          static const bool is_signed = false;
7073          static const bool is_integer = true;
7074          static const bool is_exact = true;
7075          static const int  radix = 2;
7076          static bool epsilon() throw() { return 0; }
7077          static bool round_error() throw() { return 0; }
7078
7079          static const int  min_exponent = 0;
7080          static const int  min_exponent10 = 0;
7081          static const int  max_exponent = 0;
7082          static const int  max_exponent10 = 0;
7083
7084          static const bool has_infinity = false;
7085          static const bool has_quiet_NaN = false;
7086          static const bool has_signaling_NaN = false;
7087          static const float_denorm_style has_denorm = denorm_absent;
7088          static const bool has_denorm_loss = false;
7089          static bool infinity() throw() { return 0; }
7090          static bool quiet_NaN() throw() { return 0; }
7091          static bool signaling_NaN() throw() { return 0; }
7092          static bool denorm_min() throw() { return 0; }
7093
7094          static const bool is_iec559 = false;
7095          static const bool is_bounded = true;
7096          static const bool is_modulo = false;
7097
7098          static const bool traps = false;
7099          static const bool tinyness_before = false;
7100          static const float_round_style round_style = round_toward_zero;
7101        };
7102      }</pre>
7103 </blockquote>
7104
7105 <p><i>[Tokyo:&nbsp; The LWG desires wording that specifies exact values
7106 rather than more general wording in the original proposed
7107 resolution.]</i></p>
7108
7109
7110 <p><i>[Post-Tokyo:&nbsp; At the request of the LWG in Tokyo, Nico
7111 Josuttis provided the above wording.]</i></p>
7112
7113
7114
7115
7116
7117
7118 <hr>
7119 <h3><a name="185"></a>185. Questionable use of term "inline"</h3>
7120 <p><b>Section:</b> 20.5 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7121  <b>Submitter:</b> UK Panel <b>Date:</b> 1999-07-26</p>
7122 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#function.objects">active issues</a> in [function.objects].</p>
7123 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
7124 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7125 <p><b>Discussion:</b></p>
7126 <p>Paragraph 4 of 20.5 [function.objects] says:</p>
7127 <blockquote>
7128   <p>&nbsp;[Example: To negate every element of a: transform(a.begin(), a.end(),
7129   a.begin(), negate&lt;double&gt;()); The corresponding functions will inline
7130   the addition and the negation. end example]</p>
7131 </blockquote>
7132 <p>(Note: The "addition" referred to in the above is in para 3) we can
7133 find no other wording, except this (non-normative) example which suggests that
7134 any "inlining" will take place in this case.</p>
7135 <p>Indeed both:</p>
7136 <blockquote>
7137   <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
7138   unspecified whether any global functions in the C++ Standard Library
7139   are defined as inline (7.1.2).</p>
7140 </blockquote>
7141 <p>and</p>
7142 <blockquote>
7143   <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
7144   unspecified whether any member functions in the C++ Standard Library
7145   are defined as inline (7.1.2).</p>
7146 </blockquote>
7147 <p>take care to state that this may indeed NOT be the case.</p>
7148 <p>Thus the example "mandates" behavior that is explicitly
7149 not required elsewhere.</p>
7150
7151
7152 <p><b>Proposed resolution:</b></p>
7153 <p>In 20.5 [function.objects] paragraph 1, remove the sentence:</p>
7154 <blockquote>
7155 <p>They are important for the effective use of the library.</p>
7156 </blockquote>
7157 <p>Remove 20.5 [function.objects] paragraph 2, which reads:</p>
7158 <blockquote>
7159   <p> Using function objects together with function templates
7160   increases the expressive power of the library as well as making the
7161   resulting code much more efficient.</p>
7162 </blockquote>
7163 <p>In 20.5 [function.objects] paragraph 4, remove the sentence:</p>
7164 <blockquote>
7165   <p>The corresponding functions will inline the addition and the
7166   negation.</p>
7167 </blockquote>
7168
7169 <p><i>[Kona: The LWG agreed there was a defect.]</i></p>
7170
7171 <p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
7172
7173
7174
7175
7176
7177
7178 <hr>
7179 <h3><a name="186"></a>186. bitset::set() second parameter should be bool</h3>
7180 <p><b>Section:</b> 23.3.5.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7181  <b>Submitter:</b> Darin Adler <b>Date:</b> 1999-08-13</p>
7182 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.members">issues</a> in [bitset.members].</p>
7183 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7184 <p><b>Discussion:</b></p>
7185 <p>In section 23.3.5.2 [bitset.members], paragraph 13 defines the
7186 bitset::set operation to take a second parameter of type int. The
7187 function tests whether this value is non-zero to determine whether to
7188 set the bit to true or false. The type of this second parameter should
7189 be bool. For one thing, the intent is to specify a Boolean value. For
7190 another, the result type from test() is bool. In addition, it's
7191 possible to slice an integer that's larger than an int. This can't
7192 happen with bool, since conversion to bool has the semantic of
7193 translating 0 to false and any non-zero value to true.</p>
7194
7195
7196 <p><b>Proposed resolution:</b></p>
7197 <p>In 23.3.5 [template.bitset] Para 1 Replace:</p>
7198 <blockquote>
7199 <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = true ); </pre>
7200 </blockquote>
7201 <p>With:</p>
7202 <blockquote>
7203   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
7204 </blockquote>
7205 <p>In 23.3.5.2 [bitset.members] Para 12(.5) Replace:</p>
7206 <blockquote>
7207   <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = 1 );</pre>
7208 </blockquote>
7209 <p>With:</p>
7210 <blockquote>
7211   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
7212 </blockquote>
7213
7214 <p><i>[Kona: The LWG agrees with the description.&nbsp; Andy Sawyer will work
7215 on better P/R wording.]</i></p>
7216
7217 <p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
7218
7219
7220
7221 <p><b>Rationale:</b></p>
7222 <p><tt>bool</tt> is a better choice.  It is believed that binary
7223 compatibility is not an issue, because this member function is
7224 usually implemented as <tt>inline</tt>, and because it is already
7225 the case that users cannot rely on the type of a pointer to a
7226 nonvirtual member of a standard library class.</p>
7227
7228
7229
7230
7231
7232 <hr>
7233 <h3><a name="187"></a>187. iter_swap underspecified</h3>
7234 <p><b>Section:</b> 25.2.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7235  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-14</p>
7236 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</p>
7237 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7238 <p><b>Discussion:</b></p>
7239 <p>The description of iter_swap in 25.2.2 paragraph 7,says that it
7240 ``exchanges the values'' of the objects to which two iterators
7241 refer.<br> <br> What it doesn't say is whether it does so using swap
7242 or using the assignment operator and copy constructor.<br> <br> This
7243 question is an important one to answer, because swap is specialized to
7244 work efficiently for standard containers.<br> For example:</p>
7245 <blockquote>
7246 <pre>vector&lt;int&gt; v1, v2;
7247 iter_swap(&amp;v1, &amp;v2);</pre>
7248 </blockquote>
7249 <p>Is this call to iter_swap equivalent to calling swap(v1, v2)?&nbsp;
7250 Or is it equivalent to</p>
7251 <blockquote>
7252 <pre>{
7253 vector&lt;int&gt; temp = v1;
7254 v1 = v2;
7255 v2 = temp;
7256 }</pre>
7257 </blockquote>
7258 <p>The first alternative is O(1); the second is O(n).</p>
7259 <p>A LWG member, Dave Abrahams, comments:</p>
7260 <blockquote>
7261 <p>Not an objection necessarily, but I want to point out the cost of
7262 that requirement:</p>
7263   <blockquote>
7264 <p><tt>iter_swap(list&lt;T&gt;::iterator, list&lt;T&gt;::iterator)</tt></p>
7265   </blockquote>
7266 <p>can currently be specialized to be more efficient than
7267 iter_swap(T*,T*) for many T (by using splicing). Your proposal would
7268 make that optimization illegal.&nbsp;</p>
7269 </blockquote>
7270
7271 <p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
7272 which are no longer permitted.]</i></p>
7273
7274
7275
7276 <p><b>Proposed resolution:</b></p>
7277 <p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
7278 <blockquote>
7279 <p>Exchanges the values pointed to by the two iterators a and b.</p>
7280 </blockquote>
7281 <p>to</p>
7282 <blockquote>
7283 <p><tt>swap(*a, *b)</tt>.</p>
7284 </blockquote>
7285
7286
7287
7288 <p><b>Rationale:</b></p>
7289 <p>It's useful to say just what <tt>iter_swap</tt> does.  There may be
7290   some iterators for which we want to specialize <tt>iter_swap</tt>,
7291   but the fully general version should have a general specification.</p>
7292
7293 <p>Note that in the specific case of <tt>list&lt;T&gt;::iterator</tt>,
7294 iter_swap should not be specialized as suggested above.  That would do
7295 much more than exchanging the two iterators' values: it would change
7296 predecessor/successor relationships, possibly moving the iterator from
7297 one list to another.  That would surely be inappropriate.</p>
7298
7299
7300
7301
7302
7303 <hr>
7304 <h3><a name="189"></a>189. setprecision() not specified correctly</h3>
7305 <p><b>Section:</b> 27.4.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
7306  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-25</p>
7307 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fmtflags.state">issues</a> in [fmtflags.state].</p>
7308 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
7309 <p><b>Discussion:</b></p>
7310 <p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
7311 and includes a parenthetical note saying that it is the number of
7312 digits after the decimal point.<br>
7313 <br>
7314 This claim is not strictly correct.  For example, in the default
7315 floating-point output format, setprecision sets the number of
7316 significant digits printed, not the number of digits after the decimal
7317 point.<br>
7318 <br>
7319 I would like the committee to look at the definition carefully and
7320 correct the statement in 27.4.2.2</p>
7321
7322
7323 <p><b>Proposed resolution:</b></p>
7324 <p>Remove from 27.4.2.2 [fmtflags.state], paragraph 9, the text
7325 "(number of digits after the decimal point)".</p>
7326
7327
7328
7329
7330 <hr>
7331 <h3><a name="193"></a>193. Heap operations description incorrect</h3>
7332 <p><b>Section:</b> 25.3.6 [alg.heap.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
7333  <b>Submitter:</b> Markus Mauhart <b>Date:</b> 1999-09-24</p>
7334 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
7335 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a></p>
7336 <p><b>Discussion:</b></p>
7337 <p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
7338 is<br>
7339 <br>
7340 &nbsp;&nbsp;&nbsp; `"(1) *a is the largest element"<br>
7341 <br>
7342 I think this is incorrect and should be changed to the wording in the proposed
7343 resolution.</p>
7344 <p>Actually there are two independent changes:</p>
7345 <blockquote>
7346   <p>A-"part of largest equivalence class" instead of "largest", cause 25.3
7347   [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
7348   <p>B-Take
7349 'an oldest' from that equivalence class, otherwise the heap functions
7350 could not be used for a priority queue as explained in 23.2.3.2.2
7351 [lib.priqueue.members] (where I assume that a "priority queue" respects
7352 priority AND time).</p>
7353 </blockquote>
7354
7355
7356 <p><b>Proposed resolution:</b></p>
7357 <p>Change 25.3.6 [alg.heap.operations] property (1) from:</p>
7358 <blockquote>
7359   <p>(1) *a is the largest element</p>
7360 </blockquote>
7361 <p>to:</p>
7362 <blockquote>
7363   <p>(1) There is no element greater than <tt>*a</tt></p>
7364 </blockquote>
7365
7366
7367
7368
7369
7370 <hr>
7371 <h3><a name="195"></a>195. Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3>
7372 <p><b>Section:</b> 27.6.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
7373  <b>Submitter:</b> Matt Austern <b>Date:</b> 1999-10-13</p>
7374 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
7375 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
7376 <p><b>Discussion:</b></p>
7377 <p>Suppose that <tt>is.flags() &amp; ios_base::skipws</tt> is nonzero.
7378 What should <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor do if it
7379 reaches eof while skipping whitespace?  27.6.1.1.2/5 suggests it
7380 should set failbit. Should it set eofbit as well?  The standard
7381 doesn't seem to answer that question.</p>
7382
7383 <p>On the one hand, nothing in 27.6.1.1.3 [istream::sentry] says that
7384 <tt>basic_istream&lt;&gt;::sentry</tt> should ever set eofbit.  On the
7385 other hand, 27.6.1.1 [istream] paragraph 4 says that if
7386 extraction from a <tt>streambuf</tt> "returns
7387 <tt>traits::eof()</tt>, then the input function, except as explicitly
7388 noted otherwise, completes its actions and does
7389 <tt>setstate(eofbit)"</tt>.  So the question comes down to
7390 whether <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor is an
7391 input function.</p>
7392
7393 <p>Comments from Jerry Schwarz:</p>
7394 <blockquote>
7395 <p>It was always my intention that eofbit should be set any time that a
7396 virtual returned something to indicate eof, no matter what reason
7397 iostream code had for calling the virtual.</p>
7398 <p>
7399 The motivation for this is that I did not want to require streambufs
7400 to behave consistently if their virtuals are called after they have
7401 signaled eof.</p>
7402 <p>
7403 The classic case is a streambuf reading from a UNIX file.  EOF isn't
7404 really a state for UNIX file descriptors.  The convention is that a
7405 read on UNIX returns 0 bytes to indicate "EOF", but the file
7406 descriptor isn't shut down in any way and future reads do not
7407 necessarily also return 0 bytes.  In particular, you can read from
7408 tty's on UNIX even after they have signaled "EOF".  (It
7409 isn't always understood that a ^D on UNIX is not an EOF indicator, but
7410 an EOL indicator.  By typing a "line" consisting solely of
7411 ^D you cause a read to return 0 bytes, and by convention this is
7412 interpreted as end of file.)</p>
7413 </blockquote>
7414
7415
7416 <p><b>Proposed resolution:</b></p>
7417 <p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
7418 <blockquote>
7419 <p>If <tt>is.rdbuf()-&gt;sbumpc()</tt> or <tt>is.rdbuf()-&gt;sgetc()</tt>
7420 returns <tt>traits::eof()</tt>, the function calls
7421 <tt>setstate(failbit | eofbit)</tt> (which may throw
7422 <tt>ios_base::failure</tt>).
7423 </p>
7424 </blockquote>
7425
7426
7427
7428
7429 <hr>
7430 <h3><a name="198"></a>198. Validity of pointers and references unspecified after iterator destruction</h3>
7431 <p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7432  <b>Submitter:</b> Beman Dawes <b>Date:</b> 1999-11-03</p>
7433 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
7434 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
7435 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7436 <p><b>Discussion:</b></p>
7437 <p>
7438 Is a pointer or reference obtained from an iterator still valid after
7439 destruction of the iterator?
7440 </p>
7441 <p>
7442 Is a pointer or reference obtained from an iterator still valid after the value
7443 of the iterator changes?
7444 </p>
7445 <blockquote>
7446 <pre>#include &lt;iostream&gt;
7447 #include &lt;vector&gt;
7448 #include &lt;iterator&gt;
7449
7450 int main()
7451 {
7452     typedef std::vector&lt;int&gt; vec_t;
7453     vec_t v;
7454     v.push_back( 1 );
7455
7456     // Is a pointer or reference obtained from an iterator still
7457     // valid after destruction of the iterator?
7458     int * p = &amp;*v.begin();
7459     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
7460
7461     // Is a pointer or reference obtained from an iterator still
7462     // valid after the value of the iterator changes?
7463     vec_t::iterator iter( v.begin() );
7464     p = &amp;*iter++;
7465     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
7466
7467     return 0;
7468 }
7469 </pre>
7470 </blockquote>
7471
7472 <p>The standard doesn't appear to directly address these
7473 questions. The standard needs to be clarified. At least two real-world
7474 cases have been reported where library implementors wasted
7475 considerable effort because of the lack of clarity in the
7476 standard. The question is important because requiring pointers and
7477 references to remain valid has the effect for practical purposes of
7478 prohibiting iterators from pointing to cached rather than actual
7479 elements of containers.</p>
7480
7481 <p>The standard itself assumes that pointers and references obtained
7482 from an iterator are still valid after iterator destruction or
7483 change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 [reverse.iter.conv], which returns a reference, defines
7484 effects:</p>
7485
7486 <blockquote>
7487   <pre>Iterator tmp = current;
7488 return *--tmp;</pre>
7489 </blockquote>
7490 <p>The definition of reverse_iterator::operator-&gt;(), 24.4.1.3.4
7491 [reverse.iter.op.star], which returns a pointer, defines effects:</p>
7492 <blockquote>
7493   <pre>return &amp;(operator*());</pre>
7494 </blockquote>
7495
7496 <p>Because the standard itself assumes pointers and references remain
7497 valid after iterator destruction or change, the standard should say so
7498 explicitly. This will also reduce the chance of user code breaking
7499 unexpectedly when porting to a different standard library
7500 implementation.</p>
7501
7502
7503 <p><b>Proposed resolution:</b></p>
7504 <p>Add a new paragraph to 24.1 [iterator.requirements]:</p>
7505 <blockquote><p>
7506 Destruction of an iterator may invalidate pointers and references
7507 previously obtained from that iterator.
7508 </p></blockquote>
7509
7510 <p>Replace paragraph 1 of 24.4.1.3.3 [reverse.iter.conv] with:</p>
7511
7512 <blockquote>
7513 <p><b>Effects:</b></p>
7514 <pre>  this-&gt;tmp = current;
7515   --this-&gt;tmp;
7516   return *this-&gt;tmp;
7517 </pre>
7518
7519 <p>
7520 [<i>Note:</i> This operation must use an auxiliary member variable,
7521 rather than a temporary variable, to avoid returning a reference that
7522 persists beyond the lifetime of its associated iterator.  (See
7523 24.1 [iterator.requirements].)  The name of this member variable is shown for
7524 exposition only.  <i>--end note</i>]
7525 </p>
7526 </blockquote>
7527
7528 <p><i>[Post-Tokyo: The issue has been reformulated purely
7529 in terms of iterators.]</i></p>
7530
7531
7532 <p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
7533 assumption by reverse_iterator. The issue and proposed resolution was
7534 reformulated yet again to reflect this reality.]</i></p>
7535
7536
7537 <p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
7538 assumes its underlying iterator has persistent pointers and
7539 references.  Andy Koenig pointed out that it is possible to rewrite
7540 reverse_iterator so that it no longer makes such an assupmption.
7541 However, this issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>.  If we
7542 decide it is intentional that <tt>p[n]</tt> may return by value
7543 instead of reference when <tt>p</tt> is a Random Access Iterator,
7544 other changes in reverse_iterator will be necessary.]</i></p>
7545
7546
7547
7548 <p><b>Rationale:</b></p>
7549 <p>This issue has been discussed extensively.  Note that it is
7550 <i>not</i> an issue about the behavior of predefined iterators.  It is
7551 asking whether or not user-defined iterators are permitted to have
7552 transient pointers and references.  Several people presented examples
7553 of useful user-defined iterators that have such a property; examples
7554 include a B-tree iterator, and an "iota iterator" that doesn't point
7555 to memory.  Library implementors already seem to be able to cope with
7556 such iterators: they take pains to avoid forming references to memory
7557 that gets iterated past.  The only place where this is a problem is
7558 <tt>reverse_iterator</tt>, so this issue changes
7559 <tt>reverse_iterator</tt> to make it work.</p>
7560
7561 <p>This resolution does not weaken any guarantees provided by
7562 predefined iterators like <tt>list&lt;int&gt;::iterator</tt>.
7563 Clause 23 should be reviewed to make sure that guarantees for
7564 predefined iterators are as strong as users expect.</p>
7565
7566
7567
7568
7569
7570
7571 <hr>
7572 <h3><a name="199"></a>199. What does <tt>allocate(0)</tt> return?</h3>
7573 <p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
7574  <b>Submitter:</b> Matt Austern <b>Date:</b> 1999-11-19</p>
7575 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
7576 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
7577 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
7578 <p><b>Discussion:</b></p>
7579 <p>
7580 Suppose that <tt>A</tt> is a class that conforms to the
7581 Allocator requirements of Table 32, and <tt>a</tt> is an
7582 object of class <tt>A</tt>  What should be the return
7583 value of <tt>a.allocate(0)</tt>?  Three reasonable
7584 possibilities: forbid the argument <tt>0</tt>, return
7585 a null pointer, or require that the return value be a
7586 unique non-null pointer.
7587 </p>
7588
7589
7590 <p><b>Proposed resolution:</b></p>
7591 <p>
7592 Add a note to the <tt>allocate</tt> row of Table 32:
7593 "[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
7594
7595
7596 <p><b>Rationale:</b></p>
7597 <p>A key to understanding this issue is that the ultimate use of
7598 allocate() is to construct an iterator, and that iterator for zero
7599 length sequences must be the container's past-the-end
7600 representation.  Since this already implies special case code, it
7601 would be over-specification to mandate the return value.
7602 </p>
7603
7604
7605
7606
7607 <hr>
7608 <h3><a name="200"></a>200. Forward iterator requirements don't allow constant iterators</h3>
7609 <p><b>Section:</b> 24.1.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7610  <b>Submitter:</b> Matt Austern <b>Date:</b> 1999-11-19</p>
7611 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
7612 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7613 <p><b>Discussion:</b></p>
7614 <p>
7615 In table 74, the return type of the expression <tt>*a</tt> is given
7616 as <tt>T&amp;</tt>, where <tt>T</tt> is the iterator's value type.
7617 For constant iterators, however, this is wrong.  ("Value type"
7618 is never defined very precisely, but it is clear that the value type
7619 of, say, <tt>std::list&lt;int&gt;::const_iterator</tt> is supposed to be
7620 <tt>int</tt>, not <tt>const int</tt>.)
7621 </p>
7622
7623
7624 <p><b>Proposed resolution:</b></p>
7625 <p>
7626 In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
7627 return type from "<tt>T&amp;</tt>" to "<tt>T&amp;</tt>
7628 if <tt>X</tt> is mutable, otherwise <tt>const T&amp;</tt>".
7629 In the <tt>a-&gt;m</tt> row, change the return type from
7630 "<tt>U&amp;</tt>" to "<tt>U&amp;</tt> if <tt>X</tt> is mutable,
7631 otherwise <tt>const U&amp;</tt>".
7632 </p>
7633
7634 <p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
7635 there are multiple const problems with the STL portion of the library
7636 and that these should be addressed as a single package.&nbsp; Note
7637 that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#180">180</a> has already been declared NAD Future for
7638 that very reason.]</i></p>
7639
7640
7641 <p><i>[Redmond: the LWG thinks this is separable from other constness
7642 issues.  This issue is just cleanup; it clarifies language that was
7643 written before we had iterator_traits.  Proposed resolution was
7644 modified: the original version only discussed *a.  It was pointed out
7645 that we also need to worry about *r++ and a-&gt;m.]</i></p>
7646
7647
7648
7649
7650
7651
7652
7653 <hr>
7654 <h3><a name="201"></a>201. Numeric limits terminology wrong</h3>
7655 <p><b>Section:</b> 18.2.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7656  <b>Submitter:</b> Stephen Cleary <b>Date:</b> 1999-12-21</p>
7657 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#limits">issues</a> in [limits].</p>
7658 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7659 <p><b>Discussion:</b></p>
7660 <p>
7661 In some places in this section, the terms "fundamental types" and
7662 "scalar types" are used when the term "arithmetic types" is intended.
7663 The current usage is incorrect because void is a fundamental type and
7664 pointers are scalar types, neither of which should have
7665 specializations of numeric_limits.
7666 </p>
7667 <p><i>[Lillehammer: it remains true that numeric_limits is using
7668   imprecise language. However, none of the proposals for changed
7669   wording are clearer.  A redesign of numeric_limits is needed, but this
7670   is more a task than an open issue.]</i></p>
7671
7672
7673
7674 <p><b>Proposed resolution:</b></p>
7675
7676 <p>
7677 Change 18.2 [support.limits] to:
7678 </p>
7679
7680 <blockquote>
7681 <p>
7682 -1- The headers <tt>&lt;limits&gt;</tt>, <tt>&lt;climits&gt;</tt>,
7683 <tt>&lt;cfloat&gt;</tt>, and <tt>&lt;cinttypes&gt;</tt> supply
7684 characteristics of implementation-dependent <del>fundamental</del>
7685 <ins>arithmetic</ins> types (3.9.1).
7686 </p>
7687 </blockquote>
7688
7689 <p>
7690 Change 18.2.1 [limits] to:
7691 </p>
7692
7693 <blockquote>
7694 <p>
7695 -1- The <tt>numeric_limits</tt> component provides a C++ program with
7696 information about various properties of the implementation's
7697 representation of the <del>fundamental</del> <ins>arithmetic</ins>
7698 types.
7699 </p>
7700 <p>
7701 -2- Specializations shall be provided for each <del>fundamental</del>
7702 <ins>arithmetic</ins> type, both floating point and integer, including
7703 <tt>bool</tt>. The member <tt>is_specialized</tt> shall be <tt>true</tt>
7704 for all such specializations of <tt>numeric_limits</tt>.
7705 </p>
7706 <p>
7707 -4- Non-<del>fundamental</del><ins>arithmetic</ins> standard types, such
7708 as <tt>complex&lt;T&gt;</tt> (26.3.2), shall not have specializations.
7709 </p>
7710 </blockquote>
7711
7712 <p>
7713 Change 18.2.1.1 [numeric.limits] to:
7714 </p>
7715
7716 <blockquote>
7717 <p>
7718 <del>-1- The member <tt>is_specialized</tt> makes it possible to distinguish
7719 between fundamental types, which have specializations, and non-scalar types,
7720 which do not.</del>
7721 </p>
7722 </blockquote>
7723
7724
7725
7726
7727
7728
7729 <hr>
7730 <h3><a name="202"></a>202. unique() effects unclear when predicate not an equivalence relation</h3>
7731 <p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7732  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-01-13</p>
7733 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
7734 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7735 <p><b>Discussion:</b></p>
7736 <p>
7737 What should unique() do if you give it a predicate that is not an
7738 equivalence relation?  There are at least two plausible answers:
7739 </p>
7740
7741 <blockquote>
7742
7743 <p>
7744    1. You can't, because 25.2.8 says that it it "eliminates all but
7745    the first element from every consecutive group of equal
7746    elements..." and it wouldn't make sense to interpret "equal" as
7747    meaning anything but an equivalence relation.  [It also doesn't
7748    make sense to interpret "equal" as meaning ==, because then there
7749    would never be any sense in giving a predicate as an argument at
7750    all.]
7751 </p>
7752
7753 <p>
7754    2. The word "equal" should be interpreted to mean whatever the
7755    predicate says, even if it is not an equivalence relation
7756    (and in particular, even if it is not transitive).
7757 </p>
7758
7759 </blockquote>
7760
7761 <p>
7762 The example that raised this question is from Usenet:
7763 </p>
7764
7765 <blockquote>
7766
7767 <pre>int f[] = { 1, 3, 7, 1, 2 };
7768 int* z = unique(f, f+5, greater&lt;int&gt;());</pre>
7769
7770 </blockquote>
7771
7772 <p>
7773 If one blindly applies the definition using the predicate
7774 greater&lt;int&gt;, and ignore the word "equal", you get:
7775 </p>
7776
7777 <blockquote>
7778
7779 <p>
7780     Eliminates all but the first element from every consecutive group
7781     of elements referred to by the iterator i in the range [first, last)
7782     for which *i &gt; *(i - 1).
7783 </p>
7784
7785 </blockquote>
7786
7787 <p>
7788 The first surprise is the order of the comparison.  If we wanted to
7789 allow for the predicate not being an equivalence relation, then we
7790 should surely compare elements the other way: pred(*(i - 1), *i).  If
7791 we do that, then the description would seem to say: "Break the
7792 sequence into subsequences whose elements are in strictly increasing
7793 order, and keep only the first element of each subsequence".  So the
7794 result would be 1, 1, 2.  If we take the description at its word, it
7795 would seem to call for strictly DEcreasing order, in which case the
7796 result should be 1, 3, 7, 2.<br>
7797 <br>
7798 In fact, the SGI implementation of unique() does neither: It yields 1,
7799 3, 7.
7800 </p>
7801
7802
7803 <p><b>Proposed resolution:</b></p>
7804 <p>Change 25.2.9 [alg.unique] paragraph 1 to:</p>
7805 <blockquote><p>
7806 For a nonempty range, eliminates all but the first element from every
7807 consecutive group of equivalent elements referred to by the iterator
7808 <tt>i</tt> in the range [first+1, last) for which the following
7809 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
7810 false</tt>.
7811 </p></blockquote>
7812
7813 <p>
7814 Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
7815 comparison function must be an equivalence relation."
7816 </p>
7817
7818 <p><i>[Redmond: discussed arguments for and against requiring the
7819 comparison function to be an equivalence relation.  Straw poll:
7820 14-2-5.  First number is to require that it be an equivalence
7821 relation, second number is to explicitly not require that it be an
7822 equivalence relation, third number is people who believe they need
7823 more time to consider the issue.  A separate issue: Andy Sawyer
7824 pointed out that "i-1" is incorrect, since "i" can refer to the first
7825 iterator in the range.  Matt provided wording to address this
7826 problem.]</i></p>
7827
7828
7829 <p><i>[Curaçao: The LWG changed "... the range (first,
7830 last)..." to "...  the range [first+1, last)..." for
7831 clarity. They considered this change close enough to editorial to not
7832 require another round of review.]</i></p>
7833
7834
7835
7836
7837 <p><b>Rationale:</b></p>
7838 <p>The LWG also considered an alternative resolution: change
7839 25.2.9 [alg.unique] paragraph 1 to:</p>
7840
7841 <blockquote><p>
7842 For a nonempty range, eliminates all but the first element from every
7843 consecutive group of elements referred to by the iterator
7844 <tt>i</tt> in the range (first, last) for which the following
7845 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
7846 false</tt>.
7847 </p></blockquote>
7848
7849 <p>
7850 Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
7851 comparison function need not be an equivalence relation."
7852 </p>
7853
7854
7855 <p>Informally: the proposed resolution imposes an explicit requirement
7856 that the comparison function be an equivalence relation.  The
7857 alternative resolution does not, and it gives enough information so
7858 that the behavior of unique() for a non-equivalence relation is
7859 specified.  Both resolutions are consistent with the behavior of
7860 existing implementations.</p>
7861
7862
7863
7864
7865
7866 <hr>
7867 <h3><a name="206"></a>206. operator new(size_t, nothrow) may become unlinked to ordinary operator new if ordinary version replaced</h3>
7868 <p><b>Section:</b> 18.5.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7869  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-08-29</p>
7870 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p>
7871 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7872 <p><b>Discussion:</b></p>
7873 <p>As specified, the implementation of the nothrow version of operator
7874 new does not necessarily call the ordinary operator new, but may
7875 instead simply call the same underlying allocator and return a null
7876 pointer instead of throwing an exception in case of failure.</p>
7877
7878 <p>Such an implementation breaks code that replaces the ordinary
7879 version of new, but not the nothrow version. If the ordinary version
7880 of new/delete is replaced, and if the replaced delete is not
7881 compatible with pointers returned from the library versions of new,
7882 then when the replaced delete receives a pointer allocated by the
7883 library new(nothrow), crash follows.</p>
7884
7885 <p>The fix appears to be that the lib version of new(nothrow) must
7886 call the ordinary new. Thus when the ordinary new gets replaced, the
7887 lib version will call the replaced ordinary new and things will
7888 continue to work.</p>
7889
7890 <p>An alternative would be to have the ordinary new call
7891 new(nothrow). This seems sub-optimal to me as the ordinary version of
7892 new is the version most commonly replaced in practice. So one would
7893 still need to replace both ordinary and nothrow versions if one wanted
7894 to replace the ordinary version.</p>
7895
7896 <p>Another alternative is to put in clear text that if one version is
7897 replaced, then the other must also be replaced to maintain
7898 compatibility. Then the proposed resolution below would just be a
7899 quality of implementation issue. There is already such text in
7900 paragraph 7 (under the new(nothrow) version). But this nuance is
7901 easily missed if one reads only the paragraphs relating to the
7902 ordinary new.</p>
7903
7904 <p>
7905 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2158.html">N2158</a>
7906 has been written explaining the rationale for the proposed resolution below.
7907 </p>
7908
7909
7910
7911 <p><b>Proposed resolution:</b></p>
7912 <p>
7913 Change 18.5.1.1 [new.delete.single]:
7914 </p>
7915
7916 <blockquote>
7917 <pre>void* operator new(std::size_t <i>size</i>, const std::nothrow_t&amp;) throw();
7918 </pre>
7919 <blockquote>
7920 <p>
7921 -5- <i>Effects:</i> Same as above, except that it is called by a placement
7922 version of a <i>new-expression</i> when a C++ program prefers a null pointer result as
7923 an error indication, instead of a <tt>bad_alloc</tt> exception.
7924 </p>
7925
7926 <p>
7927 -6- <i>Replaceable:</i> a C++ program may define a function with this function
7928 signature that displaces the default version defined by the C++ Standard
7929 library.
7930 </p>
7931
7932 <p>
7933 -7- <i>Required behavior:</i> Return a non-null pointer to suitably aligned
7934 storage (3.7.4), or else return a null pointer. This nothrow version of operator
7935 new returns a pointer obtained as if acquired from the <ins>(possibly
7936 replaced)</ins> ordinary version. This requirement is binding on a replacement
7937 version of this function.
7938 </p>
7939
7940 <p>
7941 -8- <i>Default behavior:</i>
7942 </p>
7943 <ul>
7944 <li><ins>
7945 Calls <tt>operator new(<i>size</i>)</tt>.
7946 </ins></li>
7947 <li><ins>
7948 If the call to <tt>operator new(<i>size</i>)</tt> returns normally, returns
7949 the result of that call, else
7950 </ins></li>
7951 <li><ins>
7952 if the call to <tt>operator new(<i>size</i>)</tt> throws an exception, returns
7953 a null pointer.
7954 </ins></li>
7955 <li><del>
7956 Executes a loop: Within the loop, the function first attempts to allocate the
7957 requested storage. Whether the attempt involves a call to the Standard C library
7958 function <tt>malloc</tt> is unspecified.
7959 </del></li>
7960 <li><del>
7961 Returns a pointer to the allocated storage if the attempt is successful.
7962 Otherwise, if the last argument to <tt>set_new_handler()</tt> was a null
7963 pointer, return a null pointer.
7964 </del></li>
7965 <li><del>
7966 Otherwise, the function calls the current <i>new_handler</i> (18.5.2.2). If the
7967 called function returns, the loop repeats.
7968 </del></li>
7969 <li><del>
7970 The loop terminates when an attempt to allocate the requested storage is
7971 successful or when a called <i>new_handler</i> function does not return. If the
7972 called <i>new_handler</i> function terminates by throwing a <tt>bad_alloc
7973 exception</tt>, the function returns a null pointer.
7974 </del></li>
7975 </ul>
7976 <p>
7977 -9- [<i>Example:</i>
7978 </p>
7979 <blockquote><pre>T* p1 = new T;                 <i>// throws bad_alloc if it fails</i>
7980 T* p2 = new(nothrow) T;        <i>// returns 0 if it fails</i>
7981 </pre></blockquote>
7982 <p>
7983 --<i>end example</i>]
7984 </p>
7985 </blockquote>
7986
7987 <pre>void operator delete(void* <i>ptr</i>) throw();
7988 <del>void operator delete(void* <i>ptr</i>, const std::nothrow_t&amp;) throw();</del>
7989 </pre>
7990
7991 <blockquote>
7992 <p>
7993 -10- <i>Effects:</i> The <i>deallocation function</i> (3.7.4.2) called by a
7994 <i>delete-expression</i> to render the value of <tt><i>ptr</i></tt> invalid.
7995 </p>
7996 <p>
7997 -11- <i>Replaceable:</i> a C++ program may define a function with this function
7998 signature that displaces the default version defined by the C++ Standard
7999 library.
8000 </p>
8001 <p>
8002 -12- <i>Requires:</i> the value of <tt><i>ptr</i></tt> is null or the value
8003 returned by an earlier call to the <del>default</del> <ins>(possibly
8004 replaced)</ins> <tt>operator new(std::size_t)</tt> or <tt>operator
8005 new(std::size_t, const std::nothrow_t&amp;)</tt>.
8006 </p>
8007 <p>
8008 -13- <i>Default behavior:</i>
8009 </p>
8010 <ul>
8011 <li>
8012 For a null value of <tt><i>ptr</i></tt>, do nothing.
8013 </li>
8014 <li>
8015 Any other value of <tt><i>ptr</i></tt> shall be a value returned earlier by a
8016 call to the default <tt>operator new</tt>, which was not invalidated by an
8017 intervening call to <tt>operator delete(void*)</tt> (17.4.3.7). For such a
8018 non-null value of <tt><i>ptr</i></tt>, reclaims storage allocated by the earlier
8019 call to the default <tt>operator new</tt>.
8020 </li>
8021 </ul>
8022 <p>
8023 -14- <i>Remarks:</i>  It is unspecified under what conditions part or all of
8024 such reclaimed storage is allocated by a subsequent call to <tt>operator
8025 new</tt> or any of <tt>calloc</tt>, <tt>malloc</tt>, or <tt>realloc</tt>,
8026 declared in <tt>&lt;cstdlib&gt;</tt>.
8027 </p>
8028 </blockquote>
8029
8030 <pre><ins>void operator delete(void* <i>ptr</i>, const std::nothrow_t&amp;) throw();</ins>
8031 </pre>
8032
8033 <blockquote>
8034 <p><ins>
8035 -15- <i>Effects:</i> Same as above, except that it is called by the
8036 implementation when an exception propagates from a nothrow placement version
8037 of the <i>new-expression</i> (i.e. when the constructor throws an exception).
8038 </ins></p>
8039 <p><ins>
8040 -16- <i>Replaceable:</i> a C++ program may define a function with this function
8041 signature that displaces the default version defined by the C++ Standard
8042 library.
8043 </ins></p>
8044 <p><ins>
8045 -17- <i>Requires:</i> the value of <tt><i>ptr</i></tt> is null or the
8046 value returned by an earlier call to the (possibly replaced) <tt>operator
8047 new(std::size_t)</tt> or <tt>operator new(std::size_t, const
8048 std::nothrow_t&amp;)</tt>. </ins></p>
8049 <p><ins>
8050 -18- <i>Default behavior:</i> Calls <tt>operator delete(<i>ptr</i>)</tt>.
8051 </ins></p>
8052 </blockquote>
8053
8054 </blockquote>
8055
8056 <p>
8057 Change 18.5.1.2 [new.delete.array]
8058 </p>
8059
8060 <blockquote>
8061 <pre>void* operator new[](std::size_t <i>size</i>, const std::nothrow_t&amp;) throw();
8062 </pre>
8063
8064 <blockquote>
8065 <p>
8066 -5- <i>Effects:</i> Same as above, except that it is called by a placement
8067 version of a <i>new-expression</i> when a C++ program prefers a null pointer result as
8068 an error indication, instead of a <tt>bad_alloc</tt> exception.
8069 </p>
8070
8071 <p>
8072 -6- <i>Replaceable:</i>  a C++ program can define a function with this function
8073 signature that displaces the default version defined by the C++ Standard
8074 library.
8075 </p>
8076
8077 <p>
8078 -7- <i>Required behavior:</i> <del>Same as for operator <tt>new(std::size_t,
8079 const std::nothrow_t&amp;)</tt>. This nothrow version of operator <tt>new[]</tt>
8080 returns a pointer obtained as if acquired from the ordinary version.</del>
8081 <ins>Return a non-null pointer to suitably aligned storage (3.7.4), or else
8082 return a null pointer. This nothrow version of operator new returns a pointer
8083 obtained as if acquired from the (possibly replaced) <tt>operator
8084 new[](std::size_t <i>size</i>)</tt>. This requirement is binding on a
8085 replacement version of this function.</ins>
8086 </p>
8087
8088 <p>
8089 -8- <i>Default behavior:</i> <del>Returns <tt>operator new(<i>size</i>,
8090 nothrow)</tt>.</del>
8091 </p>
8092
8093 <ul>
8094 <li><ins>
8095 Calls <tt>operator new[](<i>size</i>)</tt>.
8096 </ins></li>
8097 <li><ins>
8098 If the call to <tt>operator new[](<i>size</i>)</tt> returns normally, returns
8099 the result of that call, else
8100 </ins></li>
8101 <li><ins>
8102 if the call to <tt>operator new[](<i>size</i>)</tt> throws an exception, returns
8103 a null pointer.
8104 </ins></li>
8105 </ul>
8106 </blockquote>
8107
8108 <pre>void operator delete[](void* <i>ptr</i>) throw();
8109 void operator delete[](void* <i>ptr</i>, const std::nothrow_t&amp;) throw();
8110 </pre>
8111
8112 <blockquote>
8113 <p>
8114 -9- <i>Effects:</i> The <i>deallocation function</i> (3.7.4.2) called by the
8115 array form of a <i>delete-expression</i> to render the value of
8116 <tt><i>ptr</i></tt> invalid.
8117 </p>
8118
8119 <p>
8120 -10- <i>Replaceable:</i> a C++ program can define a function with this function
8121 signature that displaces the default version defined by the C++ Standard
8122 library.
8123 </p>
8124
8125 <p>
8126 -11- <i>Requires:</i> the value of
8127 <tt><i>ptr</i></tt> is null or the value returned by an earlier call to
8128 <tt>operator new[](std::size_t)</tt> or <tt>operator new[](std::size_t, const
8129 std::nothrow_t&amp;)</tt>.
8130 </p>
8131
8132 <p>
8133 -12- <i>Default behavior:</i> Calls <tt>operator delete(<i>ptr</i>)</tt> or
8134 <tt>operator delete<ins>[]</ins>(<i>ptr</i><del>, std::nothrow</del>)</tt> respectively.
8135 </p>
8136 </blockquote>
8137
8138 </blockquote>
8139
8140
8141
8142 <p><b>Rationale:</b></p>
8143 <p>Yes, they may become unlinked, and that is by design. If a user
8144 replaces one, the user should also replace the other.</p>
8145
8146 <p><i>[
8147 Reopened due to a gcc conversation between Howard, Martin and Gaby.  Forwarding
8148 or not is visible behavior to the client and it would be useful for the client
8149 to know which behavior it could depend on.
8150 ]</i></p>
8151
8152
8153 <p><i>[
8154 Batavia: Robert voiced serious reservations about backwards compatibility for
8155 his customers.
8156 ]</i></p>
8157
8158
8159
8160
8161
8162
8163 <hr>
8164 <h3><a name="208"></a>208. Unnecessary restriction on past-the-end iterators</h3>
8165 <p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8166  <b>Submitter:</b> Stephen Cleary <b>Date:</b> 2000-02-02</p>
8167 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
8168 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
8169 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8170 <p><b>Discussion:</b></p>
8171 <p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
8172 past-the-end values are always non-singular."</p>
8173 <p>This places an unnecessary restriction on past-the-end iterators for
8174 containers with forward iterators (for example, a singly-linked list). If the
8175 past-the-end value on such a container was a well-known singular value, it would
8176 still satisfy all forward iterator requirements.</p>
8177 <p>Removing this restriction would allow, for example, a singly-linked list
8178 without a "footer" node.</p>
8179 <p>This would have an impact on existing code that expects past-the-end
8180 iterators obtained from different (generic) containers being not equal.</p>
8181
8182
8183 <p><b>Proposed resolution:</b></p>
8184 <p>Change 24.1 [iterator.requirements] paragraph 5, the last sentence, from:</p>
8185 <blockquote>
8186 <p>Dereferenceable and past-the-end values are always non-singular.</p>
8187 </blockquote>
8188 <p>to:</p>
8189 <blockquote>
8190 <p>Dereferenceable values are always non-singular.&nbsp;</p>
8191 </blockquote>
8192
8193
8194 <p><b>Rationale:</b></p>
8195 <p>For some kinds of containers, including singly linked lists and
8196 zero-length vectors, null pointers are perfectly reasonable past-the-end
8197 iterators.  Null pointers are singular.
8198 </p>
8199
8200
8201
8202
8203 <hr>
8204 <h3><a name="209"></a>209. basic_string declarations inconsistent</h3>
8205 <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8206  <b>Submitter:</b> Igor Stauder <b>Date:</b> 2000-02-11</p>
8207 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
8208 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8209 <p><b>Discussion:</b></p>
8210 <p>In Section 21.3 [basic.string] the basic_string member function
8211 declarations use a consistent style except for the following functions:</p>
8212 <blockquote>
8213   <pre>void push_back(const charT);
8214 basic_string&amp; assign(const basic_string&amp;);
8215 void swap(basic_string&lt;charT,traits,Allocator&gt;&amp;);</pre>
8216 </blockquote>
8217 <p>- push_back, assign, swap: missing argument name&nbsp;<br>
8218 - push_back: use of const with charT (i.e. POD type passed by value
8219 not by reference - should be charT or const charT&amp; )<br>
8220 - swap: redundant use of template parameters in argument
8221 basic_string&lt;charT,traits,Allocator&gt;&amp;</p>
8222
8223
8224 <p><b>Proposed resolution:</b></p>
8225 <p>In Section 21.3 [basic.string] change the basic_string member
8226 function declarations push_back, assign, and swap to:</p>
8227 <blockquote>
8228   <pre>void push_back(charT c);
8229
8230 basic_string&amp; assign(const basic_string&amp; str);
8231 void swap(basic_string&amp; str);</pre>
8232 </blockquote>
8233
8234
8235 <p><b>Rationale:</b></p>
8236 <p>Although the standard is in general not consistent in declaration
8237 style, the basic_string declarations are consistent other than the
8238 above.  The LWG felt that this was sufficient reason to merit the
8239 change.
8240 </p>
8241
8242
8243
8244
8245 <hr>
8246 <h3><a name="210"></a>210. distance first and last confused</h3>
8247 <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8248  <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 2000-02-15</p>
8249 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
8250 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8251 <p><b>Discussion:</b></p>
8252 <p>In paragraph 9 of section 25 [algorithms], it is written:</p>
8253 <blockquote>
8254   <p>      In the description of the algorithms operators + and - are used
8255            for some of the iterator categories for which they do not have to
8256            be defined. In these cases the semantics of [...] a-b is the same
8257            as of<br>
8258   <br>
8259   &nbsp;&nbsp;&nbsp;&nbsp; <tt>return distance(a, b);</tt></p>
8260 </blockquote>
8261
8262
8263 <p><b>Proposed resolution:</b></p>
8264 <p>On the last line of paragraph 9 of section 25 [algorithms] change
8265 <tt>"a-b"</tt> to <tt>"b-a".</tt></p>
8266
8267
8268 <p><b>Rationale:</b></p>
8269 <p>There are two ways to fix the defect; change the description to b-a
8270 or change the return to distance(b,a).  The LWG preferred the
8271 former for consistency.</p>
8272
8273
8274
8275
8276 <hr>
8277 <h3><a name="211"></a>211. operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</h3>
8278 <p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8279  <b>Submitter:</b> Scott Snyder <b>Date:</b> 2000-02-04</p>
8280 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
8281 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8282 <p><b>Discussion:</b></p>
8283 <p>The description of the stream extraction operator for std::string (section
8284 21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
8285 the case that the operator fails to extract any characters from the input
8286 stream.</p>
8287 <p>This implies that the typical construction</p>
8288 <blockquote>
8289   <pre>std::istream is;
8290 std::string str;
8291 ...
8292 while (is &gt;&gt; str) ... ;</pre>
8293 </blockquote>
8294 <p>(which tests failbit) is not required to terminate at EOF.</p>
8295 <p>Furthermore, this is inconsistent with other extraction operators,
8296 which do include this requirement. (See sections 27.6.1.2 [istream.formatted] and 27.6.1.3 [istream.unformatted]), where this
8297 requirement is present, either explicitly or implicitly, for the
8298 extraction operators. It is also present explicitly in the description
8299 of getline (istream&amp;, string&amp;, charT) in section 21.3.8.9 [string.io] paragraph 8.)</p>
8300
8301
8302 <p><b>Proposed resolution:</b></p>
8303 <p>Insert new paragraph after paragraph 2 in section 21.3.8.9 [string.io]:</p>
8304 <blockquote>
8305
8306 <p>If the function extracts no characters, it calls
8307 is.setstate(ios::failbit) which may throw ios_base::failure
8308 (27.4.4.3).</p>
8309 </blockquote>
8310
8311
8312
8313
8314 <hr>
8315 <h3><a name="212"></a>212. Empty range behavior unclear for several algorithms</h3>
8316 <p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8317  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 2000-02-26</p>
8318 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
8319 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8320 <p><b>Discussion:</b></p>
8321 <p>The standard doesn't specify what min_element() and max_element() shall
8322 return if the range is empty (first equals last). The usual implementations
8323 return last. This problem seems also apply to partition(), stable_partition(),
8324 next_permutation(), and prev_permutation().</p>
8325
8326
8327 <p><b>Proposed resolution:</b></p>
8328 <p>In 25.3.7 [alg.min.max] - Minimum and maximum, paragraphs 7 and
8329 9, append: Returns last if first==last.</p>
8330
8331
8332 <p><b>Rationale:</b></p>
8333 <p>The LWG looked in some detail at all of the above mentioned
8334 algorithms, but believes that except for min_element() and
8335 max_element() it is already clear that last is returned if first ==
8336 last.</p>
8337
8338
8339
8340
8341 <hr>
8342 <h3><a name="214"></a>214. set::find() missing const overload</h3>
8343 <p><b>Section:</b> 23.3.3 [set], 23.3.4 [multiset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
8344  <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-02-28</p>
8345 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#set">issues</a> in [set].</p>
8346 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
8347 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#450">450</a></p>
8348 <p><b>Discussion:</b></p>
8349 <p>The specification for the associative container requirements in
8350 Table 69 state that the find member function should "return
8351 iterator; const_iterator for constant a". The map and multimap
8352 container descriptions have two overloaded versions of find, but set
8353 and multiset do not, all they have is:</p>
8354 <blockquote>
8355   <pre>iterator find(const key_type &amp; x) const;</pre>
8356 </blockquote>
8357
8358
8359 <p><b>Proposed resolution:</b></p>
8360 <p>Change the prototypes for find(), lower_bound(), upper_bound(), and
8361 equal_range() in section 23.3.3 [set] and section 23.3.4 [multiset] to each have two overloads:</p>
8362 <blockquote>
8363   <pre>iterator find(const key_type &amp; x);
8364 const_iterator find(const key_type &amp; x) const;</pre>
8365   <pre>iterator lower_bound(const key_type &amp; x);
8366 const_iterator lower_bound(const key_type &amp; x) const;</pre>
8367   <pre>iterator upper_bound(const key_type &amp; x);
8368 const_iterator upper_bound(const key_type &amp; x) const;</pre>
8369   <pre>pair&lt;iterator, iterator&gt; equal_range(const key_type &amp; x);
8370 pair&lt;const_iterator, const_iterator&gt; equal_range(const key_type &amp; x) const;</pre>
8371 </blockquote>
8372
8373 <p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
8374 extending the proposed resolution to lower_bound, upper_bound, and
8375 equal_range.]</i></p>
8376
8377
8378
8379
8380
8381
8382 <hr>
8383 <h3><a name="217"></a>217. Facets example (Classifying Japanese characters) contains errors</h3>
8384 <p><b>Section:</b> 22.2.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8385  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-02-29</p>
8386 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</p>
8387 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8388 <p><b>Discussion:</b></p>
8389 <p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
8390 <p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
8391 must be const in order for it to be callable on a const object (a reference to
8392 which which is what std::use_facet&lt;&gt;() returns).</p>
8393 <p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
8394 name of the namespace `My'.</p>
8395 <p>3) In the definition of `loc' and subsequently in the call to use_facet&lt;&gt;()
8396 in main(), the name of the facet is misspelled: it should read `My::JCtype'
8397 rather than `My::JCType'.</p>
8398
8399
8400 <p><b>Proposed resolution:</b></p>
8401 <p>Replace the "Classifying Japanese characters" example in 22.2.8,
8402 paragraph 11 with the following:</p>
8403 <pre>#include &lt;locale&gt;</pre>
8404 <pre>namespace My {
8405     using namespace std;
8406     class JCtype : public locale::facet {
8407     public:
8408         static locale::id id;     //  required for use as a new locale facet
8409         bool is_kanji (wchar_t c) const;
8410         JCtype() {}
8411     protected:
8412         ~JCtype() {}
8413     };
8414 }</pre>
8415 <pre>//  file:  filt.C
8416 #include &lt;iostream&gt;
8417 #include &lt;locale&gt;
8418 #include "jctype"                 //  above
8419 std::locale::id My::JCtype::id;   //  the static  JCtype  member
8420 declared above.</pre>
8421 <pre>int main()
8422 {
8423     using namespace std;
8424     typedef ctype&lt;wchar_t&gt; wctype;
8425     locale loc(locale(""),              //  the user's preferred locale...
8426                new My::JCtype);         //  and a new feature ...
8427     wchar_t c = use_facet&lt;wctype&gt;(loc).widen('!');
8428     if (!use_facet&lt;My::JCtype&gt;(loc).is_kanji(c))
8429         cout &lt;&lt; "no it isn't!" &lt;&lt; endl;
8430     return 0;
8431 }</pre>
8432
8433
8434
8435
8436 <hr>
8437 <h3><a name="220"></a>220. ~ios_base() usage valid?</h3>
8438 <p><b>Section:</b> 27.4.2.7 [ios.base.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8439  <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Date:</b> 2000-03-13</p>
8440 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8441 <p><b>Discussion:</b></p>
8442 <p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
8443 paragraph 2:</p>
8444 <blockquote>
8445   <p>Effects: Destroys an object of class ios_base. Calls each registered
8446   callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
8447   time that any ios_base member function called from within fn has well defined
8448   results.</p>
8449 </blockquote>
8450 <p>But what is not clear is: If no callback functions were ever registered, does
8451 it matter whether the ios_base members were ever initialized?</p>
8452 <p>For instance, does this program have defined behavior:</p>
8453 <blockquote>
8454   <pre>#include &lt;ios&gt;</pre>
8455   <pre>class D : public std::ios_base { };</pre>
8456   <pre>int main() { D d; }</pre>
8457 </blockquote>
8458 <p>It seems that registration of a callback function would surely affect the
8459 state of an ios_base. That is, when you register a callback function with an
8460 ios_base, the ios_base must record that fact somehow.</p>
8461 <p>But if after construction the ios_base is in an indeterminate state, and that
8462 state is not made determinate before the destructor is called, then how would
8463 the destructor know if any callbacks had indeed been registered? And if the
8464 number of callbacks that had been registered is indeterminate, then is not the
8465 behavior of the destructor undefined?</p>
8466 <p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
8467 it explicit that destruction before initialization results in undefined
8468 behavior.</p>
8469
8470
8471 <p><b>Proposed resolution:</b></p>
8472 <p>Modify 27.4.2.7 paragraph 1 from</p>
8473 <blockquote>
8474   <p>Effects: Each ios_base member has an indeterminate value after
8475   construction.</p>
8476 </blockquote>
8477 <p>to</p>
8478 <blockquote>
8479   <p>Effects: Each ios_base member has an indeterminate
8480 value after construction. These members must be initialized by calling
8481 basic_ios::init. If an ios_base object is destroyed before these
8482 initializations have taken place, the behavior is undefined.</p>
8483 </blockquote>
8484
8485
8486
8487
8488 <hr>
8489 <h3><a name="221"></a>221. num_get&lt;&gt;::do_get stage 2 processing broken</h3>
8490 <p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
8491  <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-03-14</p>
8492 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
8493 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
8494 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
8495 <p><b>Discussion:</b></p>
8496 <p>Stage 2 processing of numeric conversion is broken.</p>
8497
8498 <p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
8499 conversion specifier is %i. A %i specifier determines a number's base
8500 by its prefix (0 for octal, 0x for hex), so the intention is clearly
8501 that a 0x prefix is allowed.  Paragraph 8 in the same section,
8502 however, describes very precisely how characters are processed. (It
8503 must be done "as if" by a specified code fragment.) That
8504 description does not allow a 0x prefix to be recognized.</p>
8505
8506 <p>Very roughly, stage 2 processing reads a char_type ct. It converts
8507 ct to a char, not by using narrow but by looking it up in a
8508 translation table that was created by widening the string literal
8509 "0123456789abcdefABCDEF+-". The character "x" is
8510 not found in that table, so it can't be recognized by stage 2
8511 processing.</p>
8512
8513
8514 <p><b>Proposed resolution:</b></p>
8515 <p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
8516 <blockquote>
8517   <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
8518 </blockquote>
8519 <p>with the line:</p>
8520 <blockquote>
8521   <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
8522 </blockquote>
8523
8524
8525 <p><b>Rationale:</b></p>
8526 <p>If we're using the technique of widening a string literal, the
8527 string literal must contain every character we wish to recognize.
8528 This technique has the consequence that alternate representations
8529 of digits will not be recognized.  This design decision was made
8530 deliberately, with full knowledge of that limitation.</p>
8531
8532
8533
8534
8535
8536 <hr>
8537 <h3><a name="222"></a>222. Are throw clauses necessary if a throw is already implied by the effects clause?</h3>
8538 <p><b>Section:</b> 17.3.1.3 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8539  <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-03-17</p>
8540 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</p>
8541 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
8542 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8543 <p><b>Discussion:</b></p>
8544 <p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
8545 <blockquote>
8546   <pre>21.3.6.8 - basic_string::compare [lib.string::compare]
8547
8548 int compare(size_type pos1, size_type n1,
8549                 const basic_string&lt;charT,traits,Allocator&gt;&amp;  str ,
8550                 size_type  pos2 , size_type  n2 ) const;
8551
8552 -4- Returns:
8553
8554     basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
8555                  basic_string&lt;charT,traits,Allocator&gt;(str,pos2,n2)) .</pre>
8556 </blockquote>
8557 <p>and the constructor that's implicitly called by the above is
8558 defined to throw an out-of-range exception if pos &gt; str.size(). See
8559 section 21.3.1 [string.require] paragraph 4.</p>
8560
8561 <p>On the other hand, the compare function descriptions themselves don't have
8562 "Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
8563 that do not apply to a function are omitted.</p>
8564 <p>So it seems there is an inconsistency in the standard -- are the
8565 "Effects" clauses correct, or are the "Throws" clauses
8566 missing?</p>
8567
8568
8569 <p><b>Proposed resolution:</b></p>
8570 <p>In 17.3.1.3 [structure.specifications] paragraph 3, the footnote 148 attached to
8571 the sentence "Descriptions of function semantics contain the
8572 following elements (as appropriate):", insert the word
8573 "further" so that the foot note reads:</p>
8574 <blockquote>
8575   <p>To save space, items that do not apply to a function are
8576   omitted. For example, if a function does not specify any further
8577   preconditions, there will be no "Requires" paragraph.</p>
8578 </blockquote>
8579
8580
8581 <p><b>Rationale:</b></p>
8582 <p>The standard is somewhat inconsistent, but a failure to note a
8583 throw condition in a throws clause does not grant permission not to
8584 throw.  The inconsistent wording is in a footnote, and thus
8585 non-normative. The proposed resolution from the LWG clarifies the
8586 footnote.</p>
8587
8588
8589
8590
8591 <hr>
8592 <h3><a name="223"></a>223. reverse algorithm should use iter_swap rather than swap</h3>
8593 <p><b>Section:</b> 25.2.10 [alg.reverse] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8594  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-03-21</p>
8595 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8596 <p><b>Discussion:</b></p>
8597 <p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
8598
8599
8600 <p><b>Proposed resolution:</b></p>
8601 <p>In 25.2.10 [alg.reverse], replace:</p>
8602   <blockquote><p>
8603   Effects: For each non-negative integer i &lt;= (last - first)/2,
8604   applies swap to all pairs of iterators first + i, (last - i) - 1.
8605   </p></blockquote>
8606 <p>with:</p>
8607   <blockquote><p>
8608   Effects: For each non-negative integer i &lt;= (last - first)/2,
8609   applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
8610   </p></blockquote>
8611
8612
8613
8614
8615 <hr>
8616 <h3><a name="224"></a>224. clear() complexity for associative containers refers to undefined N</h3>
8617 <p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8618  <b>Submitter:</b> Ed Brey <b>Date:</b> 2000-03-23</p>
8619 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
8620 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8621 <p><b>Discussion:</b></p>
8622 <p>In the associative container requirements table in 23.1.2 paragraph 7,
8623 a.clear() has complexity "log(size()) + N". However, the meaning of N
8624 is not defined.</p>
8625
8626
8627 <p><b>Proposed resolution:</b></p>
8628 <p>In the associative container requirements table in 23.1.2 paragraph
8629 7, the complexity of a.clear(), change "log(size()) + N" to
8630 "linear in <tt>size()</tt>".</p>
8631
8632
8633 <p><b>Rationale:</b></p>
8634 <p>It's the "log(size())", not the "N", that is in
8635 error: there's no difference between <i>O(N)</i> and <i>O(N +
8636 log(N))</i>.  The text in the standard is probably an incorrect
8637 cut-and-paste from the range version of <tt>erase</tt>.</p>
8638
8639
8640
8641
8642 <hr>
8643 <h3><a name="225"></a>225. std:: algorithms use of other unqualified algorithms</h3>
8644 <p><b>Section:</b> 17.4.4.3 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
8645  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-01</p>
8646 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#global.functions">issues</a> in [global.functions].</p>
8647 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
8648 <p><b>Discussion:</b></p>
8649 <p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
8650 user namespaces might be found through Koenig lookup?</p>
8651 <p>For example, a popular standard library implementation includes this
8652 implementation of std::unique:</p>
8653 <blockquote>
8654 <pre>namespace std {
8655     template &lt;class _ForwardIter&gt;
8656     _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
8657       __first = adjacent_find(__first, __last);
8658       return unique_copy(__first, __last, __first);
8659     }
8660     }</pre>
8661 </blockquote>
8662 <p>Imagine two users on opposite sides of town, each using unique on his own
8663 sequences bounded by my_iterators . User1 looks at his standard library
8664 implementation and says, "I know how to implement a more efficient
8665 unique_copy for my_iterators", and writes:</p>
8666 <blockquote>
8667 <pre>namespace user1 {
8668     class my_iterator;
8669     // faster version for my_iterator
8670     my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
8671     }</pre>
8672 </blockquote>
8673 <p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
8674 <p>User2 has other needs, and writes:</p>
8675 <blockquote>
8676 <pre>namespace user2 {
8677     class my_iterator;
8678     // Returns true iff *c is a unique copy of *a and *b.
8679     bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
8680     }</pre>
8681 </blockquote>
8682 <p>User2 is shocked to find later that his fully-qualified use of
8683 std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
8684 compile (if he's lucky). Looking in the standard, he sees the following Effects
8685 clause for unique():</p>
8686 <blockquote>
8687   <p>Effects: Eliminates all but the first element from every consecutive group
8688   of equal elements referred to by the iterator i in the range [first, last) for
8689   which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
8690   *(i - 1)) != false</p>
8691 </blockquote>
8692 <p>The standard gives user2 absolutely no reason to think he can interfere with
8693 std::unique by defining names in namespace user2. His standard library has been
8694 built with the template export feature, so he is unable to inspect the
8695 implementation. User1 eventually compiles his code with another compiler, and
8696 his version of unique_copy silently stops being called. Eventually, he realizes
8697 that he was depending on an implementation detail of his library and had no
8698 right to expect his unique_copy() to be called portably.</p>
8699 <p>On the face of it, and given above scenario, it may seem obvious that the
8700 implementation of unique() shown is non-conforming because it uses unique_copy()
8701 rather than ::std::unique_copy(). Most standard library implementations,
8702 however, seem to disagree with this notion.</p>
8703 <p> <i>[Tokyo:&nbsp; Steve Adamczyk from
8704 the core working group indicates that "std::" is sufficient;&nbsp;
8705 leading "::" qualification is not required because any namespace
8706 qualification is sufficient to suppress Koenig lookup.]</i></p>
8707
8708
8709 <p><b>Proposed resolution:</b></p>
8710 <p>Add a paragraph and a note at the end of
8711 17.4.4.3 [global.functions]:</p>
8712 <blockquote>
8713
8714 <p>Unless otherwise specified, no global or non-member function in the
8715 standard library shall use a function from another namespace which is
8716 found through <i>argument-dependent name lookup</i> (3.4.2 [basic.lookup.argdep]).</p>
8717
8718 <p>[Note: the phrase "unless otherwise specified" is intended to
8719 allow Koenig lookup in cases like that of ostream_iterators:<br>
8720
8721 <br>
8722   Effects:</p>
8723   <blockquote>
8724 <p>*out_stream &lt;&lt; value;<br>
8725       if(delim != 0) *out_stream &lt;&lt; delim;<br>
8726       return (*this);</p>
8727     <p>--end note]</p>
8728   </blockquote>
8729 </blockquote>
8730
8731 <p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
8732 is as yet unsure if the proposed resolution is the best
8733 solution. Furthermore, the LWG believes that the same problem of
8734 unqualified library names applies to wording in the standard itself,
8735 and has opened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> accordingly. Any resolution of
8736 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be coordinated with the resolution of
8737 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>.]</i></p>
8738
8739
8740 <p><i>[Toronto: The LWG is not sure if this is a defect in the
8741 standard.  Most LWG members believe that an implementation of
8742 <tt>std::unique</tt> like the one quoted in this issue is already
8743 illegal, since, under certain circumstances, its semantics are not
8744 those specified in the standard.  The standard's description of
8745 <tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
8746 should have any effect.]</i></p>
8747
8748
8749 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
8750 225, 226, and 229.  Their conclusion was that the issues should be
8751 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
8752 EWG portion (Dave will write a proposal). The LWG and EWG had
8753 (separate) discussions of this plan the next day.  The proposed
8754 resolution for this issue is in accordance with Howard's paper.]</i></p>
8755
8756
8757
8758
8759 <p><b>Rationale:</b></p>
8760 <p>It could be argued that this proposed isn't strictly necessary,
8761   that the Standard doesn't grant implementors license to write a
8762   standard function that behaves differently than specified in the
8763   Standard just because of an unrelated user-defined name in some
8764   other namespace.  However, this is at worst a clarification.  It is
8765   surely right that algorithsm shouldn't pick up random names, that
8766   user-defined names should have no effect unless otherwise specified.
8767   Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> deals with the question of when it is
8768   appropriate for the standard to explicitly specify otherwise.</p>
8769
8770
8771
8772
8773
8774 <hr>
8775 <h3><a name="226"></a>226. User supplied specializations or overloads of namespace std function templates</h3>
8776 <p><b>Section:</b> 17.4.3.1 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
8777  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-01</p>
8778 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
8779 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
8780 <p><b>Discussion:</b></p>
8781 <p>The issues are:&nbsp;</p>
8782 <p>1. How can a 3rd party library implementor (lib1) write a version of a standard
8783 algorithm which is specialized to work with his own class template?&nbsp;</p>
8784 <p>2. How can another library implementor (lib2) write a generic algorithm which
8785 will take advantage of the specialized algorithm in lib1?</p>
8786 <p>This appears to be the only viable answer under current language rules:</p>
8787 <blockquote>
8788   <pre>namespace lib1
8789 {
8790     // arbitrary-precision numbers using T as a basic unit
8791     template &lt;class T&gt;
8792     class big_num { //...
8793     };
8794     </pre>
8795   <pre>    // defining this in namespace std is illegal (it would be an
8796     // overload), so we hope users will rely on Koenig lookup
8797     template &lt;class T&gt;
8798     void swap(big_int&lt;T&gt;&amp;, big_int&lt;T&gt;&amp;);
8799 }</pre>
8800   <pre>#include &lt;algorithm&gt;
8801 namespace lib2
8802 {
8803     template &lt;class T&gt;
8804     void generic_sort(T* start, T* end)
8805     {
8806             ...
8807         // using-declaration required so we can work on built-in types
8808         using std::swap;
8809         // use Koenig lookup to find specialized algorithm if available
8810         swap(*x, *y);
8811     }
8812 }</pre>
8813 </blockquote>
8814 <p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
8815 and somewhat slippery. The implementor needs to remember to write the
8816 using-declaration, or generic_sort will fail to compile when T is a built-in
8817 type. The second drawback is that the use of this style in lib2 effectively
8818 "reserves" names in any namespace which defines types which may
8819 eventually be used with lib2. This may seem innocuous at first when applied to
8820 names like swap, but consider more ambiguous names like unique_copy() instead.
8821 It is easy to imagine the user wanting to define these names differently in his
8822 own namespace. A definition with semantics incompatible with the standard
8823 library could cause serious problems (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>).</p>
8824 <p>Why, you may ask, can't we just partially specialize std::swap()? It's
8825 because the language doesn't allow for partial specialization of function
8826 templates. If you write:</p>
8827 <blockquote>
8828   <pre>namespace std
8829 {
8830     template &lt;class T&gt;
8831     void swap(lib1::big_int&lt;T&gt;&amp;, lib1::big_int&lt;T&gt;&amp;);
8832 }</pre>
8833 </blockquote>
8834 <p>You have just overloaded std::swap, which is illegal under the current
8835 language rules. On the other hand, the following full specialization is legal:</p>
8836 <blockquote>
8837   <pre>namespace std
8838 {
8839     template &lt;&gt;
8840     void swap(lib1::other_type&amp;, lib1::other_type&amp;);
8841 }</pre>
8842 </blockquote>
8843
8844 <p>This issue reflects concerns raised by the "Namespace issue
8845 with specialized swap" thread on comp.lang.c++.moderated. A
8846 similar set of concerns was earlier raised on the boost.org mailing
8847 list and the ACCU-general mailing list.  Also see library reflector
8848 message c++std-lib-7354.</p>
8849
8850 <p>
8851 J. C. van Winkel points out (in c++std-lib-9565) another unexpected
8852 fact: it's impossible to output a container of std::pair's using copy
8853 and an ostream_iterator, as long as both pair-members are built-in or
8854 std:: types.  That's because a user-defined operator&lt;&lt; for (for
8855 example) std::pair&lt;const std::string, int&gt; will not be found:
8856 lookup for operator&lt;&lt; will be performed only in namespace std.
8857 Opinions differed on whether or not this was a defect, and, if so,
8858 whether the defect is that something is wrong with user-defined
8859 functionality and std, or whether it's that the standard library does
8860 not provide an operator&lt;&lt; for std::pair&lt;&gt;.
8861 </p>
8862
8863
8864
8865 <p><b>Proposed resolution:</b></p>
8866
8867 <p>Adopt the wording proposed in Howard Hinnant's paper
8868   N1523=03-0106, "Proposed Resolution To LWG issues 225, 226, 229".</p>
8869
8870
8871 <p><i>[Tokyo: Summary, "There is no conforming way to extend
8872 std::swap for user defined templates."&nbsp; The LWG agrees that
8873 there is a problem.  Would like more information before
8874 proceeding. This may be a core issue.  Core issue 229 has been opened
8875 to discuss the core aspects of this problem. It was also noted that
8876 submissions regarding this issue have been received from several
8877 sources, but too late to be integrated into the issues list.
8878 ]</i></p>
8879
8880
8881 <p><i>[Post-Tokyo: A paper with several proposed resolutions,
8882 J16/00-0029==WG21/N1252, "Shades of namespace std functions
8883 " by Alan Griffiths, is in the Post-Tokyo mailing. It
8884 should be considered a part of this issue.]</i></p>
8885
8886
8887 <p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
8888 resolution that involves core changes: it would add partial
8889 specialization of function template.  The Core Working Group is
8890 reluctant to add partial specialization of function templates.  It is
8891 viewed as a large change, CWG believes that proposal presented leaves
8892 some syntactic issues unanswered; if the CWG does add partial
8893 specialization of function templates, it wishes to develop its own
8894 proposal.  The LWG continues to believe that there is a serious
8895 problem: there is no good way for users to force the library to use
8896 user specializations of generic standard library functions, and in
8897 certain cases (e.g. transcendental functions called by
8898 <tt>valarray</tt> and <tt>complex</tt>) this is important.  Koenig
8899 lookup isn't adequate, since names within the library must be
8900 qualified with <tt>std</tt> (see issue 225), specialization doesn't
8901 work (we don't have partial specialization of function templates), and
8902 users aren't permitted to add overloads within namespace std.
8903 ]</i></p>
8904
8905
8906 <p><i>[Copenhagen: Discussed at length, with no consensus.  Relevant
8907 papers in the pre-Copenhagen mailing: N1289, N1295, N1296.  Discussion
8908 focused on four options. (1) Relax restrictions on overloads within
8909 namespace std. (2) Mandate that the standard library use unqualified
8910 calls for <tt>swap</tt> and possibly other functions.  (3) Introduce
8911 helper class templates for <tt>swap</tt> and possibly other functions.
8912 (4) Introduce partial specialization of function templates.  Every
8913 option had both support and opposition.  Straw poll (first number is
8914 support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
8915 (4) 4, 4.]</i></p>
8916
8917
8918 <p><i>[Redmond: Discussed, again no consensus.  Herb presented an
8919 argument that a user who is defining a type <tt>T</tt> with an
8920 associated <tt>swap</tt> should not be expected to put that
8921 <tt>swap</tt> in namespace std, either by overloading or by partial
8922 specialization.  The argument is that <tt>swap</tt> is part of
8923 <tt>T</tt>'s interface, and thus should to in the same namespace as
8924 <tt>T</tt> and only in that namespace.  If we accept this argument,
8925 the consequence is that standard library functions should use
8926 unqualified call of <tt>swap</tt>.  (And which other functions? Any?)
8927 A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
8928 try to put together a proposal before the next meeting.]</i></p>
8929
8930
8931 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
8932 225, 226, and 229.  Their conclusion was that the issues should be
8933 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
8934 EWG portion (Dave will write a proposal). The LWG and EWG had
8935 (separate) discussions of this plan the next day.  The proposed
8936 resolution is the one proposed by Howard.]</i></p>
8937
8938
8939 <p><i>[Santa Cruz: the LWG agreed with the general direction of
8940   Howard's paper, N1387.  (Roughly: Koenig lookup is disabled unless
8941   we say otherwise; this issue is about when we do say otherwise.)
8942   However, there were concerns about wording.  Howard will provide new
8943   wording.  Bill and Jeremy will review it.]</i></p>
8944
8945
8946 <p><i>[Kona: Howard proposed the new wording.  The LWG accepted his
8947   proposed resolution.]</i></p>
8948
8949
8950
8951
8952 <p><b>Rationale:</b></p>
8953 <p>Informally: introduce a Swappable concept, and specify that the
8954   value types of the iterators passed to certain standard algorithms
8955   (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
8956   to that concept.  The Swappable concept will make it clear that
8957   these algorithms use unqualified lookup for the calls
8958   to <tt>swap</tt>.  Also, in 26.5.3.3 [valarray.transcend] paragraph 1,
8959   state that the valarray transcendentals use unqualified lookup.</p>
8960
8961
8962
8963
8964
8965 <hr>
8966 <h3><a name="227"></a>227. std::swap() should require CopyConstructible or DefaultConstructible arguments</h3>
8967 <p><b>Section:</b> 25.2.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8968  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-09</p>
8969 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</p>
8970 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8971 <p><b>Discussion:</b></p>
8972 <p>25.2.2 reads:</p>
8973 <blockquote>
8974   <p><tt>  template&lt;class T&gt; void swap(T&amp; a, T&amp; b);</tt><br>
8975   <br>
8976   Requires:    Type T is Assignable (_lib.container.requirements_).<br>
8977   Effects:    Exchanges values stored in two locations.</p>
8978 </blockquote>
8979 <p>The only reasonable** generic implementation of swap requires construction of a
8980    new temporary copy of one of its arguments:</p>
8981 <blockquote>
8982 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
8983   {
8984       T tmp(a);
8985       a = b;
8986       b = tmp;
8987   }</pre>
8988 </blockquote>
8989 <p>But a type which is only Assignable cannot be swapped by this implementation.</p>
8990 <p>**Yes, there's also an unreasonable implementation which would require T to be
8991    DefaultConstructible instead of CopyConstructible. I don't think this is worthy
8992    of consideration:</p>
8993 <blockquote>
8994 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
8995 {
8996     T tmp;
8997     tmp = a;
8998     a = b;
8999     b = tmp;
9000 }</pre>
9001 </blockquote>
9002
9003
9004 <p><b>Proposed resolution:</b></p>
9005 <p>Change 25.2.2 paragraph 1 from:</p>
9006 <blockquote>
9007 <p>  Requires: Type T is Assignable (23.1).</p>
9008 </blockquote>
9009 <p>to:</p>
9010 <blockquote>
9011 <p>  Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
9012 </blockquote>
9013
9014
9015
9016
9017
9018 <hr>
9019 <h3><a name="228"></a>228. Incorrect specification of "..._byname" facets</h3>
9020 <p><b>Section:</b> 22.2 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9021  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-20</p>
9022 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.categories">active issues</a> in [locale.categories].</p>
9023 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
9024 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9025 <p><b>Discussion:</b></p>
9026 <p>The sections 22.2.1.2 [locale.ctype.byname], 22.2.1.5
9027 [locale.codecvt.byname],
9028 sref ref="22.2.1.6", 22.2.3.2 [locale.numpunct.byname], 22.2.4.2
9029 [locale.collate.byname], 22.2.5.4 [locale.time.put.byname], 22.2.6.4
9030 [locale.moneypunct.byname], and 22.2.7.2 [locale.messages.byname]
9031 overspecify the
9032 definitions of the "..._byname" classes by listing a bunch
9033 of virtual functions. At the same time, no semantics of these
9034 functions are defined. Real implementations do not define these
9035 functions because the functional part of the facets is actually
9036 implemented in the corresponding base classes and the constructor of
9037 the "..._byname" version just provides suitable date used by
9038 these implementations. For example, the 'numpunct' methods just return
9039 values from a struct. The base class uses a statically initialized
9040 struct while the derived version reads the contents of this struct
9041 from a table. However, no virtual function is defined in
9042 'numpunct_byname'.</p>
9043
9044 <p>For most classes this does not impose a problem but specifically
9045 for 'ctype' it does: The specialization for 'ctype_byname&lt;char&gt;'
9046 is required because otherwise the semantics would change due to the
9047 virtual functions defined in the general version for 'ctype_byname':
9048 In 'ctype&lt;char&gt;' the method 'do_is()' is not virtual but it is
9049 made virtual in both 'ctype&lt;cT&gt;' and 'ctype_byname&lt;cT&gt;'.
9050 Thus, a class derived from 'ctype_byname&lt;char&gt;' can tell whether
9051 this class is specialized or not under the current specification:
9052 Without the specialization, 'do_is()' is virtual while with
9053 specialization it is not virtual.</p>
9054
9055
9056 <p><b>Proposed resolution:</b></p>
9057 <p>&nbsp; Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
9058 <pre>     namespace std {
9059        template &lt;class charT&gt;
9060        class ctype_byname : public ctype&lt;charT&gt; {
9061        public:
9062          typedef ctype&lt;charT&gt;::mask mask;
9063          explicit ctype_byname(const char*, size_t refs = 0);
9064        protected:
9065         ~ctype_byname();             //  virtual
9066        };
9067      }</pre>
9068 <p>&nbsp; Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
9069 <pre>    namespace std {
9070       template &lt;class internT, class externT, class stateT&gt;
9071       class codecvt_byname : public codecvt&lt;internT, externT, stateT&gt; {
9072       public:
9073        explicit codecvt_byname(const char*, size_t refs = 0);
9074       protected:
9075       ~codecvt_byname();             //  virtual
9076        };
9077      }
9078 </pre>
9079 <p>&nbsp; Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
9080 <pre>     namespace std {
9081        template &lt;class charT&gt;
9082        class numpunct_byname : public numpunct&lt;charT&gt; {
9083      //  this class is specialized for  char  and  wchar_t.
9084        public:
9085          typedef charT                char_type;
9086          typedef basic_string&lt;charT&gt;  string_type;
9087          explicit numpunct_byname(const char*, size_t refs = 0);
9088        protected:
9089         ~numpunct_byname();          //  virtual
9090        };
9091      }</pre>
9092 <p>&nbsp; Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
9093 <pre>     namespace std {
9094        template &lt;class charT&gt;
9095        class collate_byname : public collate&lt;charT&gt; {
9096        public:
9097          typedef basic_string&lt;charT&gt; string_type;
9098          explicit collate_byname(const char*, size_t refs = 0);
9099        protected:
9100         ~collate_byname();           //  virtual
9101        };
9102      }</pre>
9103 <p>&nbsp; Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
9104 <pre>     namespace std {
9105        template &lt;class charT, class InputIterator = istreambuf_iterator&lt;charT&gt; &gt;
9106        class time_get_byname : public time_get&lt;charT, InputIterator&gt; {
9107        public:
9108          typedef time_base::dateorder dateorder;
9109          typedef InputIterator        iter_type</pre>
9110 <pre>         explicit time_get_byname(const char*, size_t refs = 0);
9111        protected:
9112         ~time_get_byname();          //  virtual
9113        };
9114      }</pre>
9115 <p>&nbsp; Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
9116 <pre>     namespace std {
9117        template &lt;class charT, class OutputIterator = ostreambuf_iterator&lt;charT&gt; &gt;
9118        class time_put_byname : public time_put&lt;charT, OutputIterator&gt;
9119        {
9120        public:
9121          typedef charT          char_type;
9122          typedef OutputIterator iter_type;</pre>
9123 <pre>         explicit time_put_byname(const char*, size_t refs = 0);
9124        protected:
9125         ~time_put_byname();          //  virtual
9126        };
9127      }"</pre>
9128 <p>&nbsp; Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
9129 <pre>     namespace std {
9130        template &lt;class charT, bool Intl = false&gt;
9131        class moneypunct_byname : public moneypunct&lt;charT, Intl&gt; {
9132        public:
9133          typedef money_base::pattern pattern;
9134          typedef basic_string&lt;charT&gt; string_type;</pre>
9135 <pre>         explicit moneypunct_byname(const char*, size_t refs = 0);
9136        protected:
9137         ~moneypunct_byname();        //  virtual
9138        };
9139      }</pre>
9140 <p>&nbsp; Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
9141 <pre>     namespace std {
9142        template &lt;class charT&gt;
9143        class messages_byname : public messages&lt;charT&gt; {
9144        public:
9145          typedef messages_base::catalog catalog;
9146          typedef basic_string&lt;charT&gt;    string_type;</pre>
9147 <pre>         explicit messages_byname(const char*, size_t refs = 0);
9148        protected:
9149         ~messages_byname();          //  virtual
9150        };
9151      }</pre>
9152 <p>Remove section 22.2.1.4 [locale.codecvt] completely (because in
9153 this case only those members are defined to be virtual which are
9154 defined to be virtual in 'ctype&lt;cT&gt;'.)</p>
9155
9156 <p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of
9157 the LWG to solve the underlying problems raised by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>.]</i></p>
9158
9159
9160 <p><i>[Copenhagen: proposed resolution was revised slightly, to remove
9161 three last virtual functions from <tt>messages_byname</tt>.]</i></p>
9162
9163
9164
9165
9166
9167
9168
9169 <hr>
9170 <h3><a name="229"></a>229. Unqualified references of other library entities</h3>
9171 <p><b>Section:</b> 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9172  <b>Submitter:</b> Steve Clamage <b>Date:</b> 2000-04-19</p>
9173 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9174 <p><b>Discussion:</b></p>
9175 <p>Throughout the library chapters, the descriptions of library entities refer
9176 to other library entities without necessarily qualifying the names.</p>
9177
9178 <p>For example, section 25.2.2 "Swap" describes the effect of
9179 swap_ranges in terms of the unqualified name "swap". This section
9180 could reasonably be interpreted to mean that the library must be implemented so
9181 as to do a lookup of the unqualified name "swap", allowing users to
9182 override any ::std::swap function when Koenig lookup applies.</p>
9183
9184 <p>Although it would have been best to use explicit qualification with
9185 "::std::" throughout, too many lines in the standard would have to be
9186 adjusted to make that change in a Technical Corrigendum.</p>
9187
9188 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, which addresses qualification of
9189 <tt>size_t</tt>, is a special case of this.
9190 </p>
9191
9192
9193 <p><b>Proposed resolution:</b></p>
9194 <p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p>
9195 <blockquote>
9196   <p>Whenever a name x defined in the standard library is mentioned, the name x
9197   is assumed to be fully qualified as ::std::x, unless explicitly described
9198   otherwise. For example, if the Effects section for library function F is
9199   described as calling library function G, the function ::std::G is meant.</p>
9200 </blockquote>
9201
9202 <p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
9203 the LWG to solve a problem in the standard itself similar to the
9204 problem within implementations of library identified by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>.  Any resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be
9205 coordinated with the resolution of this issue.]</i></p>
9206
9207
9208 <p><i>[post-Toronto: Howard is undecided about whether it is
9209 appropriate for all standard library function names referred to in
9210 other standard library functions to be explicitly qualified by
9211 <tt>std</tt>: it is common advice that users should define global
9212 functions that operate on their class in the same namespace as the
9213 class, and this requires argument-dependent lookup if those functions
9214 are intended to be called by library code.  Several LWG members are
9215 concerned that valarray appears to require argument-dependent lookup,
9216 but that the wording may not be clear enough to fall under
9217 "unless explicitly described otherwise".]</i></p>
9218
9219
9220 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
9221 225, 226, and 229.  Their conclusion was that the issues should be
9222 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
9223 EWG portion (Dave will write a proposal). The LWG and EWG had
9224 (separate) discussions of this plan the next day.  This paper resolves
9225 issues 225 and 226.  In light of that resolution, the proposed
9226 resolution for the current issue makes sense.]</i></p>
9227
9228
9229
9230
9231
9232
9233
9234 <hr>
9235 <h3><a name="230"></a>230. Assignable specified without also specifying CopyConstructible</h3>
9236 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9237  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2000-04-26</p>
9238 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
9239 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9240 <p><b>Discussion:</b></p>
9241 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> identified an instance (std::swap) where
9242 Assignable was specified without also specifying
9243 CopyConstructible. The LWG asked that the standard be searched to
9244 determine if the same defect existed elsewhere.</p>
9245
9246 <p>There are a number of places (see proposed resolution below) where
9247 Assignable is specified without also specifying
9248 CopyConstructible. There are also several cases where both are
9249 specified. For example, 26.4.1 [rand.req].</p>
9250
9251
9252 <p><b>Proposed resolution:</b></p>
9253 <p>In  23.1 [container.requirements] table 65 for value_type:
9254 change "T is Assignable" to "T is CopyConstructible and
9255 Assignable"
9256 </p>
9257
9258 <p>In 23.1.2 [associative.reqmts] table 69 X::key_type; change
9259 "Key is Assignable" to "Key is
9260 CopyConstructible and Assignable"<br>
9261 </p>
9262
9263 <p>In 24.1.2 [output.iterators] paragraph 1, change:
9264 </p>
9265 <blockquote>
9266 <p> A class or a built-in type X satisfies the requirements of an
9267 output iterator if X is an Assignable type (23.1) and also the
9268 following expressions are valid, as shown in Table 73:
9269 </p>
9270 </blockquote>
9271 <p>to:
9272 </p>
9273 <blockquote>
9274 <p> A class or a built-in type X satisfies the requirements of an
9275 output iterator if X is a CopyConstructible (20.1.3) and Assignable
9276 type (23.1) and also the following expressions are valid, as shown in
9277 Table 73:
9278 </p>
9279 </blockquote>
9280
9281 <p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
9282 the LWG.  He asks that the 25.2.5 [alg.replace] and 25.2.6 [alg.fill] changes be studied carefully, as it is not clear that
9283 CopyConstructible is really a requirement and may be
9284 overspecification.]</i></p>
9285
9286
9287 <p><i>[Portions of the resolution for issue 230 have been superceded by
9288 the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.]</i></p>
9289
9290
9291
9292
9293 <p><b>Rationale:</b></p>
9294 <p>The original proposed resolution also included changes to input
9295 iterator, fill, and replace.  The LWG believes that those changes are
9296 not necessary.  The LWG considered some blanket statement, where an
9297 Assignable type was also required to be Copy Constructible, but
9298 decided against this because fill and replace really don't require the
9299 Copy Constructible property.</p>
9300
9301
9302
9303
9304 <hr>
9305 <h3><a name="231"></a>231. Precision in iostream?</h3>
9306 <p><b>Section:</b> 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9307  <b>Submitter:</b> James Kanze, Stephen Clamage <b>Date:</b> 2000-04-25</p>
9308 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
9309 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9310 <p><b>Discussion:</b></p>
9311 <p>What is the following program supposed to output?</p>
9312 <pre>#include &lt;iostream&gt;
9313
9314     int
9315     main()
9316     {
9317         std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
9318         std::cout.precision( 0 ) ;
9319         std::cout &lt;&lt; 1.00 &lt;&lt; '\n' ;
9320         return 0 ;
9321     }</pre>
9322 <p>From my C experience, I would expect "1e+00"; this is what
9323 <tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs
9324 "1.000000e+00".</p>
9325
9326 <p>The only indication I can find in the standard is 22.2.2.2.2/11,
9327 where it says "For conversion from a floating-point type, if
9328 (flags &amp; fixed) != 0 or if str.precision() &gt; 0, then
9329 str.precision() is specified in the conversion specification."
9330 This is an obvious error, however, fixed is not a mask for a field,
9331 but a value that a multi-bit field may take -- the results of and'ing
9332 fmtflags with ios::fixed are not defined, at least not if
9333 ios::scientific has been set. G++'s behavior corresponds to what might
9334 happen if you do use (flags &amp; fixed) != 0 with a typical
9335 implementation (floatfield == 3 &lt;&lt; something, fixed == 1
9336 &lt;&lt; something, and scientific == 2 &lt;&lt; something).</p>
9337
9338 <p>Presumably, the intent is either (flags &amp; floatfield) != 0, or
9339 (flags &amp; floatfield) == fixed; the first gives something more or
9340 less like the effect of precision in a printf floating point
9341 conversion. Only more or less, of course. In order to implement printf
9342 formatting correctly, you must know whether the precision was
9343 explicitly set or not. Say by initializing it to -1, instead of 6, and
9344 stating that for floating point conversions, if precision &lt; -1, 6
9345 will be used, for fixed point, if precision &lt; -1, 1 will be used,
9346 etc. Plus, of course, if precision == 0 and flags &amp; floatfield ==
9347 0, 1 should be = used. But it probably isn't necessary to emulate all
9348 of the anomalies of printf:-).</p>
9349
9350
9351 <p><b>Proposed resolution:</b></p>
9352 <p>
9353 Replace 22.2.2.2.2 [facet.num.put.virtuals], paragraph 11, with the following
9354 sentence:
9355 </p>
9356 <blockquote><p>
9357 For conversion from a floating-point type,
9358 <tt><i>str</i>.precision()</tt> is specified in the conversion
9359 specification.
9360 </p></blockquote>
9361
9362
9363 <p><b>Rationale:</b></p>
9364 <p>The floatfield determines whether numbers are formatted as if
9365 with %f, %e, or %g.  If the <tt>fixed</tt> bit is set, it's %f,
9366 if <tt>scientific</tt> it's %e, and if both bits are set, or
9367 neither, it's %g.</p>
9368 <p>Turning to the C standard, a precision of 0 is meaningful
9369 for %f and %e.  For %g, precision 0 is taken to be the same as
9370 precision 1.</p>
9371 <p>The proposed resolution has the effect that if neither
9372 <tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
9373 specifying a precision of 0, which will be internally
9374 turned into 1.  There's no need to call it out as a special
9375 case.</p>
9376 <p>The output of the above program will be "1e+00".</p>
9377
9378 <p><i>[Post-Curaçao: Howard provided improved wording covering the case
9379 where precision is 0 and mode is %g.]</i></p>
9380
9381
9382
9383
9384
9385
9386
9387 <hr>
9388 <h3><a name="232"></a>232. "depends" poorly defined in 17.4.3.1</h3>
9389 <p><b>Section:</b> 17.4.3.1 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9390  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2000-04-18</p>
9391 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
9392 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9393 <p><b>Discussion:</b></p>
9394 <p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
9395 specializations of standard templates to those that "depend on a
9396 user-defined name of external linkage."</p>
9397 <p>This term, however, is not adequately defined, making it possible to
9398 construct a specialization that is, I believe, technically legal according to
9399 17.4.3.1/1, but that specializes a standard template for a built-in type such as
9400 'int'.</p>
9401 <p>The following code demonstrates the problem:</p>
9402 <blockquote>
9403   <pre>#include &lt;algorithm&gt;</pre>
9404   <pre>template&lt;class T&gt; struct X
9405 {
9406  typedef T type;
9407 };</pre>
9408   <pre>namespace std
9409 {
9410  template&lt;&gt; void swap(::X&lt;int&gt;::type&amp; i, ::X&lt;int&gt;::type&amp; j);
9411 }</pre>
9412 </blockquote>
9413
9414
9415 <p><b>Proposed resolution:</b></p>
9416 <p>Change "user-defined name" to "user-defined
9417 type".</p>
9418
9419
9420 <p><b>Rationale:</b></p>
9421 <p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
9422 Programming Language</i>.  It disallows the example in the issue,
9423 since the underlying type itself is not user-defined.  The only
9424 possible problem I can see is for non-type templates, but there's no
9425 possible way for a user to come up with a specialization for bitset,
9426 for example, that might not have already been specialized by the
9427 implementor?</p>
9428
9429 <p><i>[Toronto: this may be related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a>.]</i></p>
9430
9431
9432 <p><i>[post-Toronto: Judy provided the above proposed resolution and
9433 rationale.]</i></p>
9434
9435
9436
9437
9438
9439
9440 <hr>
9441 <h3><a name="233"></a>233. Insertion hints in associative containers</h3>
9442 <p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9443  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-04-30</p>
9444 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
9445 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9446 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#192">192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#246">246</a></p>
9447 <p><b>Discussion:</b></p>
9448 <p>
9449 If <tt>mm</tt> is a multimap and <tt>p</tt> is an iterator
9450 into the multimap, then <tt>mm.insert(p, x)</tt> inserts
9451 <tt>x</tt> into <tt>mm</tt> with <tt>p</tt> as a hint as
9452 to where it should go.  Table 69 claims that the execution time is
9453 amortized constant if the insert winds up taking place adjacent to
9454 <tt>p</tt>, but does not say when, if ever, this is guaranteed to
9455 happen.  All it says it that <tt>p</tt> is a hint as to where to
9456 insert.
9457 </p>
9458 <p>
9459 The question is whether there is any guarantee about the relationship
9460 between <tt>p</tt> and the insertion point, and, if so, what it
9461 is.
9462 </p>
9463 <p>
9464 I believe the present state is that there is no guarantee: The user
9465 can supply <tt>p</tt>, and the implementation is allowed to
9466 disregard it entirely.
9467 </p>
9468
9469 <p><b>Additional comments from Nathan:</b><br>
9470
9471 The vote [in Redmond] was on whether to elaborately specify the use of
9472 the hint, or to require behavior only if the value could be inserted
9473 adjacent to the hint.  I would like to ensure that we have a chance to
9474 vote for a deterministic treatment: "before, if possible, otherwise
9475 after, otherwise anywhere appropriate", as an alternative to the
9476 proposed "before or after, if possible, otherwise [...]".
9477 </p>
9478
9479 <p><i>[Toronto: there was general agreement that this is a real defect:
9480 when inserting an element x into a multiset that already contains
9481 several copies of x, there is no way to know whether the hint will be
9482 used.  The proposed resolution was that the new element should always
9483 be inserted as close to the hint as possible.  So, for example, if
9484 there is a subsequence of equivalent values, then providing a.begin()
9485 as the hint means that the new element should be inserted before the
9486 subsequence even if a.begin() is far away.  JC van Winkel supplied
9487 precise wording for this proposed resolution, and also for an
9488 alternative resolution in which hints are only used when they are
9489 adjacent to the insertion point.]</i></p>
9490
9491
9492 <p><i>[Copenhagen: the LWG agreed to the original proposed resolution,
9493 in which an insertion hint would be used even when it is far from the
9494 insertion point.  This was contingent on seeing a reference
9495 implementation showing that it is possible to implement this
9496 requirement without loss of efficiency.  John Potter provided such a
9497 reference implementation.]</i></p>
9498
9499
9500 <p><i>[Redmond: The LWG was reluctant to adopt the proposal that
9501 emerged from Copenhagen: it seemed excessively complicated, and went
9502 beyond fixing the defect that we identified in Toronto.  PJP provided
9503 the new wording described in this issue.  Nathan agrees that we
9504 shouldn't adopt the more detailed semantics, and notes: "we know that
9505 you can do it efficiently enough with a red-black tree, but there are
9506 other (perhaps better) balanced tree techniques that might differ
9507 enough to make the detailed semantics hard to satisfy."]</i></p>
9508
9509
9510 <p><i>[Curaçao: Nathan should give us the alternative wording he
9511 suggests so the LWG can decide between the two options.]</i></p>
9512
9513
9514 <p><i>[Lillehammer: The LWG previously rejected the more detailed
9515   semantics, because it seemed more loike a new feature than like
9516   defect fixing.  We're now more sympathetic to it, but we (especially
9517   Bill) are still worried about performance.  N1780 describes a naive
9518   algorithm, but it's not clear whether there is a non-naive
9519   implementation. Is it possible to implement this as efficently as
9520   the current version of insert?]</i></p>
9521
9522
9523 <p><i>[Post Lillehammer:
9524 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">N1780</a>
9525 updated in post meeting mailing with
9526 feedback from Lillehammer with more information regarding performance.
9527 ]</i></p>
9528
9529
9530 <p><i>[
9531 Batavia:
9532 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>
9533 accepted with minor wording changes in the proposed wording (reflected in the
9534 proposed resolution below).  Concerns about the performance of the algorithm
9535 were satisfactorily met by
9536 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>.
9537 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a> already handles the stability of equal ranges
9538 and so that part of the resolution from
9539 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>
9540 is no longer needed (or reflected in the proposed wording below).
9541 ]</i></p>
9542
9543
9544
9545
9546 <p><b>Proposed resolution:</b></p>
9547
9548 <p>
9549 Change the indicated rows of the "Associative container requirements" Table in
9550 23.1.2 [associative.reqmts] to:
9551 </p>
9552
9553 <p></p><center>
9554 <table border="1">
9555 <caption>Associative container requirements</caption>
9556 <tbody><tr><th>expression</th> <th>return type</th>
9557 <th>assertion/note<br>pre/post-condition</th>
9558 <th>complexity</th></tr>
9559 <tr><td><tt>a_eq.insert(t)</tt></td>
9560 <td><tt>iterator</tt></td>
9561 <td>
9562 inserts <tt>t</tt> and returns the iterator pointing to the newly inserted
9563 element. <ins>If a range containing elements equivalent to <tt>t</tt> exists in
9564 <tt>a_eq</tt>, <tt>t</tt> is inserted at the end of that range.</ins>
9565 </td>
9566 <td>
9567 logarithmic
9568 </td></tr>
9569 <tr><td><tt>a.insert(p,t)</tt></td>
9570 <td><tt>iterator</tt></td>
9571 <td>
9572 inserts <tt>t</tt> if and only if there is no element with key equivalent to the
9573 key of <tt>t</tt> in containers with unique keys; always inserts <tt>t</tt> in containers
9574 with equivalent keys. always returns the iterator pointing to the element with key
9575 equivalent to the key of <tt>t</tt>. <del>iterator <tt>p</tt> is a hint pointing to where
9576 the insert should start to search.</del> <ins><tt>t</tt> is inserted as close as possible
9577 to the position just prior to <tt>p</tt>.</ins>
9578 </td>
9579 <td>
9580 logarithmic in general, but amortized constant if <tt>t</tt> is inserted right <del>after</del>
9581  <ins>before</ins> <tt>p</tt>.
9582 </td></tr>
9583 </tbody></table>
9584 </center>
9585
9586
9587
9588
9589
9590
9591 <hr>
9592 <h3><a name="234"></a>234. Typos in allocator definition</h3>
9593 <p><b>Section:</b> 20.6.1.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9594  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p>
9595 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
9596 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9597 <p><b>Discussion:</b></p>
9598 <p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
9599 <tt>destruct()</tt> are described as returns but the functions actually
9600 return <tt>void</tt>.</p>
9601
9602
9603 <p><b>Proposed resolution:</b></p>
9604 <p>Substitute "Returns" by "Effect".</p>
9605
9606
9607
9608
9609 <hr>
9610 <h3><a name="235"></a>235. No specification of default ctor for reverse_iterator</h3>
9611 <p><b>Section:</b> 24.4.1.1 [reverse.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9612  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p>
9613 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9614 <p><b>Discussion:</b></p>
9615 <p>The declaration of <tt>reverse_iterator</tt> lists a default
9616 constructor.  However, no specification is given what this constructor
9617 should do.</p>
9618
9619
9620 <p><b>Proposed resolution:</b></p>
9621   <p>In section 24.4.1.3.1 [reverse.iter.cons] add the following
9622   paragraph:</p>
9623       <blockquote>
9624       <p><tt>reverse_iterator()</tt></p>
9625
9626       <p>Default initializes <tt>current</tt>. Iterator operations
9627       applied to the resulting iterator have defined behavior if and
9628       only if the corresponding operations are defined on a default
9629       constructed iterator of type <tt>Iterator</tt>.</p>
9630       </blockquote>
9631   <p><i>[pre-Copenhagen: Dietmar provide wording for proposed
9632   resolution.]</i></p>
9633
9634
9635
9636
9637
9638
9639 <hr>
9640 <h3><a name="237"></a>237. Undefined expression in complexity specification</h3>
9641 <p><b>Section:</b> 23.2.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9642  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p>
9643 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.cons">issues</a> in [deque.cons].</p>
9644 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9645 <p><b>Discussion:</b></p>
9646 <p>The complexity specification in paragraph 6 says that the complexity
9647 is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
9648 defined on iterators this term is in general undefined because it
9649 would have to be <tt>last - first</tt>.</p>
9650
9651
9652 <p><b>Proposed resolution:</b></p>
9653   <p>Change paragraph 6 from</p>
9654      <blockquote><p>Linear in <i>first - last</i>.</p></blockquote>
9655   <p>to become</p>
9656      <blockquote><p>Linear in <i>distance(first, last)</i>.</p></blockquote>
9657
9658
9659
9660
9661 <hr>
9662 <h3><a name="238"></a>238. Contradictory results of stringbuf initialization.</h3>
9663 <p><b>Section:</b> 27.7.1.1 [stringbuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9664  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-05-11</p>
9665 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9666 <p><b>Discussion:</b></p>
9667 <p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
9668 'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
9669 that far but consider this code:</p>
9670
9671 <pre>  std::basic_stringbuf&lt;char&gt; sbuf("hello, world", std::ios_base::openmode(0));
9672   std::cout &lt;&lt; "'" &lt;&lt; sbuf.str() &lt;&lt; "'\n";
9673 </pre>
9674
9675 <p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
9676 the output sequence nor the input sequence is initialized and
9677 paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
9678 returns the input or the output sequence. None of them is initialized,
9679 ie. both are empty, in which case the return from <tt>str()</tt> is
9680 defined to be <tt>basic_string&lt;cT&gt;()</tt>.</p>
9681
9682 <p>However, probably only test cases in some testsuites will detect this
9683 "problem"...</p>
9684
9685
9686 <p><b>Proposed resolution:</b></p>
9687 <p>Remove 27.7.1.1 paragraph 4.</p>
9688
9689
9690 <p><b>Rationale:</b></p>
9691 <p>We could fix 27.7.1.1 paragraph 4, but there would be no point.  If
9692 we fixed it, it would say just the same thing as text that's already
9693 in the standard.</p>
9694
9695
9696
9697
9698 <hr>
9699 <h3><a name="239"></a>239. Complexity of unique() and/or unique_copy incorrect</h3>
9700 <p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9701  <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
9702 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
9703 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9704 <p><b>Discussion:</b></p>
9705 <p>The complexity of unique and unique_copy are inconsistent with each
9706 other and inconsistent with the implementations.&nbsp; The standard
9707 specifies:</p>
9708
9709 <p>for unique():</p>
9710
9711 <blockquote><p>-3- Complexity: If the range (last - first) is not empty, exactly
9712 (last - first) - 1 applications of the corresponding predicate, otherwise
9713 no applications of the predicate.</p></blockquote>
9714
9715 <p>for unique_copy():</p>
9716
9717 <blockquote><p>-7- Complexity: Exactly last - first applications of the corresponding
9718 predicate.</p></blockquote>
9719
9720 <p>
9721 The implementations do it the other way round: unique() applies the
9722 predicate last-first times and unique_copy() applies it last-first-1
9723 times.</p>
9724
9725 <p>As both algorithms use the predicate for pair-wise comparison of
9726 sequence elements I don't see a justification for unique_copy()
9727 applying the predicate last-first times, especially since it is not
9728 specified to which pair in the sequence the predicate is applied
9729 twice.</p>
9730
9731
9732 <p><b>Proposed resolution:</b></p>
9733 <p>Change both complexity sections in 25.2.9 [alg.unique] to:</p>
9734
9735 <blockquote><p>Complexity: For nonempty ranges, exactly last - first - 1
9736 applications of the corresponding predicate.</p></blockquote>
9737
9738
9739
9740
9741
9742
9743 <hr>
9744 <h3><a name="240"></a>240. Complexity of adjacent_find() is meaningless</h3>
9745 <p><b>Section:</b> 25.1.5 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9746  <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
9747 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9748 <p><b>Discussion:</b></p>
9749 <p>The complexity section of adjacent_find is defective:</p>
9750
9751 <blockquote>
9752 <pre>template &lt;class ForwardIterator&gt;
9753 ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
9754                               BinaryPredicate pred);
9755 </pre>
9756
9757 <p>-1- Returns: The first iterator i such that both i and i + 1 are in
9758 the range [first, last) for which the following corresponding
9759 conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
9760 last if no such iterator is found.</p>
9761
9762 <p>-2- Complexity: Exactly find(first, last, value) - first applications
9763 of the corresponding predicate.
9764 </p>
9765 </blockquote>
9766
9767 <p>In the Complexity section, it is not defined what "value"
9768 is supposed to mean. My best guess is that "value" means an
9769 object for which one of the conditions pred(*i,value) or
9770 pred(value,*i) is true, where i is the iterator defined in the Returns
9771 section. However, the value type of the input sequence need not be
9772 equality-comparable and for this reason the term find(first, last,
9773 value) - first is meaningless.</p>
9774
9775 <p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
9776 find_if(first, last, bind1st(pred,*i)) - first might come closer to
9777 the intended specification.  Binders can only be applied to function
9778 objects that have the function call operator declared const, which is
9779 not required of predicates because they can have non-const data
9780 members. For this reason, a specification using a binder could only be
9781 an "as-if" specification.</p>
9782
9783
9784 <p><b>Proposed resolution:</b></p>
9785 <p>Change the complexity section in 25.1.5 [alg.adjacent.find] to:</p>
9786 <blockquote><p>
9787 For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
9788 (<i>last</i> - <i>first</i>) - 1)</tt> applications of the
9789 corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
9790 return value.
9791 </p></blockquote>
9792
9793 <p><i>[Copenhagen: the original resolution specified an upper
9794 bound.  The LWG preferred an exact count.]</i></p>
9795
9796
9797
9798
9799
9800
9801
9802 <hr>
9803 <h3><a name="241"></a>241. Does unique_copy() require CopyConstructible and Assignable?</h3>
9804 <p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9805  <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
9806 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
9807 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9808 <p><b>Discussion:</b></p>
9809
9810 <p>Some popular implementations of unique_copy() create temporary
9811 copies of values in the input sequence, at least if the input iterator
9812 is a pointer.  Such an implementation is built on the assumption that
9813 the value type is CopyConstructible and Assignable.</p>
9814
9815 <p>It is common practice in the standard that algorithms explicitly
9816 specify any additional requirements that they impose on any of the
9817 types used by the algorithm. An example of an algorithm that creates
9818 temporary copies and correctly specifies the additional requirements
9819 is accumulate(), 26.4.1 [rand.req].</p>
9820
9821 <p>Since the specifications of unique() and unique_copy() do not
9822 require CopyConstructible and Assignable of the InputIterator's value
9823 type the above mentioned implementations are not standard-compliant. I
9824 cannot judge whether this is a defect in the standard or a defect in
9825 the implementations.</p>
9826
9827
9828 <p><b>Proposed resolution:</b></p>
9829 <p>In 25.2.8 change:</p>
9830
9831 <blockquote><p>
9832 -4- Requires: The ranges [first, last) and [result, result+(last-first))
9833 shall not overlap.
9834 </p></blockquote>
9835
9836 <p>to:</p>
9837
9838 <blockquote>
9839   <p>-4- Requires: The ranges [first, last) and [result,
9840   result+(last-first)) shall not overlap. The expression *result =
9841   *first must be valid. If neither InputIterator nor OutputIterator
9842   meets the requirements of forward iterator then the value type of
9843   InputIterator must be copy constructible. Otherwise copy
9844   constructible is not required. </p>
9845 </blockquote>
9846
9847 <p><i>[Redmond: the original proposed resolution didn't impose an
9848 explicit requirement that the iterator's value type must be copy
9849 constructible, on the grounds that an input iterator's value type must
9850 always be copy constructible.  Not everyone in the LWG thought that
9851 this requirement was clear from table 72.  It has been suggested that
9852 it might be possible to implement <tt>unique_copy</tt> without
9853 requiring assignability, although current implementations do impose
9854 that requirement.  Howard provided new wording.]</i></p>
9855
9856
9857 <p><i>[
9858 Curaçao: The LWG changed the PR editorially to specify
9859 "neither...nor...meet..." as clearer than
9860 "both...and...do not meet...". Change believed to be so
9861 minor as not to require re-review.
9862 ]</i></p>
9863
9864
9865
9866
9867
9868
9869
9870
9871 <hr>
9872 <h3><a name="242"></a>242. Side effects of function objects</h3>
9873 <p><b>Section:</b> 25.2.4 [alg.transform], 26.4 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9874  <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
9875 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.transform">issues</a> in [alg.transform].</p>
9876 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9877 <p><b>Discussion:</b></p>
9878 <p>The algorithms transform(), accumulate(), inner_product(),
9879 partial_sum(), and adjacent_difference() require that the function
9880 object supplied to them shall not have any side effects.</p>
9881
9882 <p>The standard defines a side effect in 1.9 [intro.execution] as:</p>
9883 <blockquote><p>-7- Accessing an object designated by a volatile lvalue (basic.lval),
9884 modifying an object, calling a library I/O function, or calling a function
9885 that does any of those operations are all side effects, which are changes
9886 in the state of the execution environment.</p></blockquote>
9887
9888 <p>As a consequence, the function call operator of a function object supplied
9889 to any of the algorithms listed above cannot modify data members, cannot
9890 invoke any function that has a side effect, and cannot even create and
9891 modify temporary objects.&nbsp; It is difficult to imagine a function object
9892 that is still useful under these severe limitations. For instance, any
9893 non-trivial transformator supplied to transform() might involve creation
9894 and modification of temporaries, which is prohibited according to the current
9895 wording of the standard.</p>
9896
9897 <p>On the other hand, popular implementations of these algorithms exhibit
9898 uniform and predictable behavior when invoked with a side-effect-producing
9899 function objects. It looks like the strong requirement is not needed for
9900 efficient implementation of these algorithms.</p>
9901
9902 <p>The requirement of&nbsp; side-effect-free function objects could be
9903 replaced by a more relaxed basic requirement (which would hold for all
9904 function objects supplied to any algorithm in the standard library):</p>
9905 <blockquote><p>A function objects supplied to an algorithm shall not invalidate
9906 any iterator or sequence that is used by the algorithm. Invalidation of
9907 the sequence includes destruction of the sorting order if the algorithm
9908 relies on the sorting order (see section 25.3 - Sorting and related operations
9909 [lib.alg.sorting]).</p></blockquote>
9910
9911 <p>I can't judge whether it is intended that the function objects supplied
9912 to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
9913 shall not modify sequence elements through dereferenced iterators.</p>
9914
9915 <p>It is debatable whether this issue is a defect or a change request.
9916 Since the consequences for user-supplied function objects are drastic and
9917 limit the usefulness of the algorithms significantly I would consider it
9918 a defect.</p>
9919
9920
9921 <p><b>Proposed resolution:</b></p>
9922
9923 <p><i>Things to notice about these changes:</i></p>
9924
9925 <ol>
9926 <li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
9927      are intentional. we want to prevent side-effects from
9928      invalidating the end iterators.</i></li>
9929
9930 <li> <i>That has the unintentional side-effect of prohibiting
9931      modification of the end element as a side-effect. This could
9932      conceivably be significant in some cases.</i></li>
9933
9934 <li> <i>The wording also prevents side-effects from modifying elements
9935      of the output sequence. I can't imagine why anyone would want
9936      to do this, but it is arguably a restriction that implementors
9937      don't need to place on users.</i></li>
9938
9939 <li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
9940      and simple, but would require more verbiage.</i></li>
9941 </ol>
9942
9943 <p>Change 25.2.3/2 from:</p>
9944
9945 <blockquote><p>
9946    -2- Requires: op and binary_op shall not have any side effects.
9947 </p></blockquote>
9948
9949 <p>to:</p>
9950
9951 <blockquote><p>
9952   -2- Requires: in the ranges [first1, last1], [first2, first2 +
9953   (last1 - first1)] and [result, result + (last1- first1)], op and
9954   binary_op shall neither modify elements nor invalidate iterators or
9955   subranges.
9956   [Footnote: The use of fully closed ranges is intentional --end footnote]
9957 </p></blockquote>
9958
9959
9960 <p>Change 25.2.3/2 from:</p>
9961
9962 <blockquote><p>
9963    -2- Requires: op and binary_op shall not have any side effects.
9964 </p></blockquote>
9965
9966 <p>to:</p>
9967
9968 <blockquote><p>
9969   -2- Requires: op and binary_op shall not invalidate iterators or
9970    subranges, or modify elements in the ranges [first1, last1],
9971    [first2, first2 + (last1 - first1)], and [result, result + (last1
9972    - first1)].
9973   [Footnote: The use of fully closed ranges is intentional --end footnote]
9974 </p></blockquote>
9975
9976
9977 <p>Change 26.4.1/2 from:</p>
9978
9979 <blockquote><p>
9980   -2- Requires: T must meet the requirements of CopyConstructible
9981    (lib.copyconstructible) and Assignable (lib.container.requirements)
9982    types. binary_op shall not cause side effects.
9983 </p></blockquote>
9984
9985 <p>to:</p>
9986
9987 <blockquote><p>
9988   -2- Requires: T must meet the requirements of CopyConstructible
9989    (lib.copyconstructible) and Assignable
9990    (lib.container.requirements) types. In the range [first, last],
9991    binary_op shall neither modify elements nor invalidate iterators
9992    or subranges.
9993   [Footnote: The use of a fully closed range is intentional --end footnote]
9994 </p></blockquote>
9995
9996 <p>Change 26.4.2/2 from:</p>
9997
9998 <blockquote><p>
9999   -2- Requires: T must meet the requirements of CopyConstructible
10000    (lib.copyconstructible) and Assignable (lib.container.requirements)
10001    types. binary_op1 and binary_op2 shall not cause side effects.
10002 </p></blockquote>
10003
10004 <p>to:</p>
10005
10006 <blockquote><p>
10007   -2- Requires: T must meet the requirements of CopyConstructible
10008    (lib.copyconstructible) and Assignable (lib.container.requirements)
10009    types. In the ranges [first, last] and [first2, first2 + (last -
10010    first)], binary_op1 and binary_op2 shall neither modify elements
10011    nor invalidate iterators or subranges.
10012   [Footnote: The use of fully closed ranges is intentional --end footnote]
10013 </p></blockquote>
10014
10015
10016 <p>Change 26.4.3/4 from:</p>
10017
10018 <blockquote><p>
10019   -4- Requires: binary_op is expected not to have any side effects.
10020 </p></blockquote>
10021
10022 <p>to:</p>
10023
10024 <blockquote><p>
10025   -4- Requires: In the ranges [first, last] and [result, result +
10026    (last - first)], binary_op shall neither modify elements nor
10027    invalidate iterators or subranges.
10028   [Footnote: The use of fully closed ranges is intentional --end footnote]
10029 </p></blockquote>
10030
10031 <p>Change 26.4.4/2 from:</p>
10032
10033 <blockquote><p>
10034   -2- Requires: binary_op shall not have any side effects.
10035 </p></blockquote>
10036
10037 <p>to:</p>
10038
10039 <blockquote><p>
10040   -2- Requires: In the ranges [first, last] and [result, result +
10041    (last - first)], binary_op shall neither modify elements nor
10042    invalidate iterators or subranges.
10043   [Footnote: The use of fully closed ranges is intentional --end footnote]
10044 </p></blockquote>
10045
10046 <p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
10047
10048
10049 <p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
10050 added footnotes pointing out that the use of closed ranges was
10051 intentional.]</i></p>
10052
10053
10054
10055
10056
10057
10058
10059 <hr>
10060 <h3><a name="243"></a>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3>
10061 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10062  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-05-15</p>
10063 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
10064 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
10065 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10066 <p><b>Discussion:</b></p>
10067 <p>basic_istream&lt;&gt;::get(), and basic_istream&lt;&gt;::getline(),
10068 are unclear with respect to the behavior and side-effects of the named
10069 functions in case of an error.</p>
10070
10071 <p>27.6.1.3, p1 states that "... If the sentry object returns
10072 true, when converted to a value of type bool, the function endeavors
10073 to obtain the requested input..." It is not clear from this (or
10074 the rest of the paragraph) what precisely the behavior should be when
10075 the sentry ctor exits by throwing an exception or when the sentry
10076 object returns false.  In particular, what is the number of characters
10077 extracted that gcount() returns supposed to be?</p>
10078
10079 <p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
10080 "...  In any case, it then stores a null character (using
10081 charT()) into the next successive location of the array." Is not
10082 clear whether this sentence applies if either of the conditions above
10083 holds (i.e., when sentry fails).</p>
10084
10085
10086 <p><b>Proposed resolution:</b></p>
10087 <p>Add to 27.6.1.3, p1 after the sentence</p>
10088
10089 <blockquote><p>
10090 "... If the sentry object returns true, when converted to a value of
10091 type bool, the function endeavors to obtain the requested input."
10092 </p></blockquote>
10093
10094 <p>the following</p>
10095
10096
10097 <blockquote><p>
10098 "Otherwise, if the sentry constructor exits by throwing an exception or
10099 if the sentry object returns false, when converted to a value of type
10100 bool, the function returns without attempting to obtain any input. In
10101 either case the number of extracted characters is set to 0; unformatted
10102 input functions taking a character array of non-zero size as an argument
10103 shall also store a null character (using charT()) in the first location
10104 of the array."
10105 </p></blockquote>
10106
10107
10108 <p><b>Rationale:</b></p>
10109 <p>Although the general philosophy of the input functions is that the
10110 argument should not be modified upon failure, <tt>getline</tt>
10111 historically added a terminating null unconditionally.  Most
10112 implementations still do that.  Earlier versions of the draft standard
10113 had language that made this an unambiguous requirement; those words
10114 were moved to a place where their context made them less clear.  See
10115 Jerry Schwarz's message c++std-lib-7618.</p>
10116
10117
10118
10119
10120 <hr>
10121 <h3><a name="247"></a>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3>
10122 <p><b>Section:</b> 23.2.5.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10123  <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 2000-06-06</p>
10124 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
10125 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10126 <p><b>Discussion:</b></p>
10127 <p>Paragraph 2 of 23.2.5.4 [vector.modifiers] describes the complexity
10128 of <tt>vector::insert</tt>:</p>
10129
10130    <blockquote><p>
10131    Complexity: If first and last are forward iterators, bidirectional
10132    iterators, or random access iterators, the complexity is linear in
10133    the number of elements in the range [first, last) plus the distance
10134    to the end of the vector. If they are input iterators, the complexity
10135    is proportional to the number of elements in the range [first, last)
10136    times the distance to the end of the vector.
10137    </p></blockquote>
10138
10139 <p>First, this fails to address the non-iterator forms of
10140 <tt>insert</tt>.</p>
10141
10142 <p>Second, the complexity for input iterators misses an edge case --
10143 it requires that an arbitrary number of elements can be added at
10144 the end of a <tt>vector</tt> in constant time.</p>
10145
10146 <p>I looked to see if <tt>deque</tt> had a similar problem, and was
10147 surprised to find that <tt>deque</tt> places no requirement on the
10148 complexity of inserting multiple elements (23.2.2.3 [deque.modifiers],
10149 paragraph 3):</p>
10150
10151    <blockquote><p>
10152    Complexity: In the worst case, inserting a single element into a
10153    deque takes time linear in the minimum of the distance from the
10154    insertion point to the beginning of the deque and the distance
10155    from the insertion point to the end of the deque. Inserting a
10156    single element either at the beginning or end of a deque always
10157    takes constant time and causes a single call to the copy constructor
10158    of T.
10159    </p></blockquote>
10160
10161
10162 <p><b>Proposed resolution:</b></p>
10163
10164 <p>Change Paragraph 2 of 23.2.5.4 [vector.modifiers] to</p>
10165    <blockquote><p>
10166    Complexity: The complexity is linear in the number of elements
10167    inserted plus the distance to the end of the vector.
10168    </p></blockquote>
10169
10170    <p><i>[For input iterators, one may achieve this complexity by first
10171    inserting at the end of the <tt>vector</tt>, and then using
10172    <tt>rotate</tt>.]</i></p>
10173
10174
10175 <p>Change 23.2.2.3 [deque.modifiers], paragraph 3, to:</p>
10176
10177    <blockquote><p>
10178    Complexity: The complexity is linear in the number of elements
10179    inserted plus the shorter of the distances to the beginning and
10180    end of the deque.  Inserting a single element at either the
10181    beginning or the end of a deque causes a single call to the copy
10182    constructor of T.
10183    </p></blockquote>
10184
10185
10186
10187 <p><b>Rationale:</b></p>
10188 <p>This is a real defect, and proposed resolution fixes it: some
10189   complexities aren't specified that should be.  This proposed
10190   resolution does constrain deque implementations (it rules out the
10191   most naive possible implementations), but the LWG doesn't see a
10192   reason to permit that implementation.</p>
10193
10194
10195
10196
10197
10198 <hr>
10199 <h3><a name="248"></a>248. time_get fails to set eofbit</h3>
10200 <p><b>Section:</b> 22.2.5 [category.time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10201  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-06-22</p>
10202 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10203 <p><b>Discussion:</b></p>
10204 <p>There is no requirement that any of time_get member functions set
10205 ios::eofbit when they reach the end iterator while parsing their input.
10206 Since members of both the num_get and money_get facets are required to
10207 do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
10208 should follow the same requirement for consistency.</p>
10209
10210
10211 <p><b>Proposed resolution:</b></p>
10212 <p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
10213
10214 <blockquote><p>
10215 If the end iterator is reached during parsing by any of the get()
10216 member functions, the member sets ios_base::eofbit in err.
10217 </p></blockquote>
10218
10219
10220 <p><b>Rationale:</b></p>
10221 <p>Two alternative resolutions were proposed.  The LWG chose this one
10222 because it was more consistent with the way eof is described for other
10223 input facets.</p>
10224
10225
10226
10227
10228 <hr>
10229 <h3><a name="250"></a>250. splicing invalidates iterators</h3>
10230 <p><b>Section:</b> 23.2.3.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10231  <b>Submitter:</b> Brian Parker  <b>Date:</b> 2000-07-14</p>
10232 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
10233 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10234 <p><b>Discussion:</b></p>
10235 <p>
10236 Section 23.2.3.4 [list.ops] states that
10237 </p>
10238 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
10239 </pre>
10240 <p>
10241 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
10242 </p>
10243
10244 <p>
10245 This is unnecessary and defeats an important feature of splice. In
10246 fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
10247 after <tt>splice</tt>.
10248 </p>
10249
10250
10251 <p><b>Proposed resolution:</b></p>
10252
10253 <p>Add a footnote to 23.2.3.4 [list.ops], paragraph 1:</p>
10254 <blockquote><p>
10255 [<i>Footnote:</i> As specified in  [default.con.req], paragraphs
10256 4-5, the semantics described in this clause applies only to the case
10257 where allocators compare equal.  --end footnote]
10258 </p></blockquote>
10259
10260 <p>In 23.2.3.4 [list.ops], replace paragraph 4 with:</p>
10261 <blockquote><p>
10262 Effects: Inserts the contents of x before position and x becomes
10263 empty.  Pointers and references to the moved elements of x now refer to
10264 those same elements but as members of *this.  Iterators referring to the
10265 moved elements will continue to refer to their elements, but they now
10266 behave as iterators into *this, not into x.
10267 </p></blockquote>
10268
10269 <p>In 23.2.3.4 [list.ops], replace paragraph 7 with:</p>
10270 <blockquote><p>
10271 Effects: Inserts an element pointed to by i from list x before
10272 position and removes the element from x. The result is unchanged if
10273 position == i or position == ++i.  Pointers and references to *i continue
10274 to refer to this same element but as a member of *this.  Iterators to *i
10275 (including i itself) continue to refer to the same element, but now
10276 behave as iterators into *this, not into x.
10277 </p></blockquote>
10278
10279 <p>In 23.2.3.4 [list.ops], replace paragraph 12 with:</p>
10280 <blockquote><p>
10281 Requires: [first, last) is a valid range in x. The result is
10282 undefined if position is an iterator in the range [first, last).
10283 Pointers and references to the moved elements of x now refer to those
10284 same elements but as members of *this.  Iterators referring to the moved
10285 elements will continue to refer to their elements, but they now behave as
10286 iterators into *this, not into x.
10287 </p></blockquote>
10288
10289 <p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
10290
10291
10292
10293 <p><b>Rationale:</b></p>
10294 <p>The original proposed resolution said that iterators and references
10295 would remain "valid".  The new proposed resolution clarifies what that
10296 means.  Note that this only applies to the case of equal allocators.
10297 From  [default.con.req] paragraph 4, the behavior of list when
10298 allocators compare nonequal is outside the scope of the standard.</p>
10299
10300
10301
10302
10303 <hr>
10304 <h3><a name="251"></a>251. basic_stringbuf missing allocator_type</h3>
10305 <p><b>Section:</b> 27.7.1 [stringbuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10306  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-07-28</p>
10307 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10308 <p><b>Discussion:</b></p>
10309 <p>The synopsis for the template class <tt>basic_stringbuf</tt>
10310 doesn't list a typedef for the template parameter
10311 <tt>Allocator</tt>. This makes it impossible to determine the type of
10312 the allocator at compile time. It's also inconsistent with all other
10313 template classes in the library that do provide a typedef for the
10314 <tt>Allocator</tt> parameter.</p>
10315
10316
10317 <p><b>Proposed resolution:</b></p>
10318 <p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
10319 basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and
10320 basic_stringstream (27.7.4) the typedef:</p>
10321 <pre>  typedef Allocator allocator_type;
10322 </pre>
10323
10324
10325
10326
10327 <hr>
10328 <h3><a name="252"></a>252. missing casts/C-style casts used in iostreams</h3>
10329 <p><b>Section:</b> 27.7 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10330  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-07-28</p>
10331 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p>
10332 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10333 <p><b>Discussion:</b></p>
10334 <p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
10335 const_cast&lt;&gt; in the Returns clause for basic_istringstream&lt;&gt;::rdbuf().
10336 The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
10337 D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
10338 the cast altogether.</p>
10339
10340 <p>C-style casts have not been deprecated, so the first part of this
10341 issue is stylistic rather than a matter of correctness.</p>
10342
10343
10344 <p><b>Proposed resolution:</b></p>
10345 <p>In 27.7.2.2, p1 replace </p>
10346 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
10347
10348 <p>with</p>
10349 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
10350
10351
10352 <p>In 27.7.3.2, p1 replace</p>
10353 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
10354
10355 <p>with</p>
10356 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
10357
10358 <p>In 27.7.6, p1, replace</p>
10359 <pre>  -1- Returns: &amp;sb</pre>
10360
10361 <p>with</p>
10362 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
10363
10364 <p>In D.7.2.2, p1 replace</p>
10365 <pre>  -2- Returns: &amp;sb. </pre>
10366
10367 <p>with</p>
10368 <pre>  -2- Returns: const_cast&lt;strstreambuf*&gt;(&amp;sb).</pre>
10369
10370
10371
10372
10373 <hr>
10374 <h3><a name="253"></a>253. valarray helper functions are almost entirely useless</h3>
10375 <p><b>Section:</b> 26.5.2.1 [valarray.cons], 26.5.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10376  <b>Submitter:</b> Robert Klarer <b>Date:</b> 2000-07-31</p>
10377 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p>
10378 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
10379 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10380 <p><b>Discussion:</b></p>
10381 <p>This discussion is adapted from message c++std-lib-7056 posted
10382 November 11, 1999.  I don't think that anyone can reasonably claim
10383 that the problem described below is NAD.</p>
10384
10385 <p>These valarray constructors can never be called:</p>
10386
10387 <pre>   template &lt;class T&gt;
10388          valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
10389    template &lt;class T&gt;
10390          valarray&lt;T&gt;::valarray(const gslice_array&lt;T&gt; &amp;);
10391    template &lt;class T&gt;
10392          valarray&lt;T&gt;::valarray(const mask_array&lt;T&gt; &amp;);
10393    template &lt;class T&gt;
10394          valarray&lt;T&gt;::valarray(const indirect_array&lt;T&gt; &amp;);
10395 </pre>
10396
10397 <p>Similarly, these valarray assignment operators cannot be
10398 called:</p>
10399
10400 <pre>     template &lt;class T&gt;
10401      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const slice_array&lt;T&gt; &amp;);
10402      template &lt;class T&gt;
10403      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const gslice_array&lt;T&gt; &amp;);
10404      template &lt;class T&gt;
10405      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const mask_array&lt;T&gt; &amp;);
10406      template &lt;class T&gt;
10407      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const indirect_array&lt;T&gt; &amp;);
10408 </pre>
10409
10410 <p>Please consider the following example:</p>
10411
10412 <pre>   #include &lt;valarray&gt;
10413    using namespace std;
10414
10415    int main()
10416    {
10417        valarray&lt;double&gt; va1(12);
10418        valarray&lt;double&gt; va2(va1[slice(1,4,3)]); // line 1
10419    }
10420 </pre>
10421
10422
10423 <p>Since the valarray va1 is non-const, the result of the sub-expression
10424 va1[slice(1,4,3)] at line 1 is an rvalue of type const
10425 std::slice_array&lt;double&gt;.  This slice_array rvalue is then used to
10426 construct va2.  The constructor that is used to construct va2 is
10427 declared like this:</p>
10428
10429 <pre>     template &lt;class T&gt;
10430      valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
10431 </pre>
10432
10433 <p>Notice the constructor's const reference parameter.  When the
10434 constructor is called, a slice_array must be bound to this reference.
10435 The rules for binding an rvalue to a const reference are in 8.5.3,
10436 paragraph 5 (see also 13.3.3.1.4).  Specifically, paragraph 5
10437 indicates that a second slice_array rvalue is constructed (in this
10438 case copy-constructed) from the first one; it is this second rvalue
10439 that is bound to the reference parameter.  Paragraph 5 also requires
10440 that the constructor that is used for this purpose be callable,
10441 regardless of whether the second rvalue is elided.  The
10442 copy-constructor in this case is not callable, however, because it is
10443 private.  Therefore, the compiler should report an error.</p>
10444
10445 <p>Since slice_arrays are always rvalues, the valarray constructor that has a
10446 parameter of type const slice_array&lt;T&gt; &amp; can never be called.  The
10447 same reasoning applies to the three other constructors and the four
10448 assignment operators that are listed at the beginning of this post.
10449 Furthermore, since these functions cannot be called, the valarray helper
10450 classes are almost entirely useless.</p>
10451
10452
10453 <p><b>Proposed resolution:</b></p>
10454 <p>slice_array:</p>
10455 <ul>
10456 <li> Make the copy constructor and copy-assignment operator declarations
10457      public in the slice_array class template definition in 26.5.5 [template.slice.array] </li>
10458 <li> remove paragraph 3 of 26.5.5 [template.slice.array]</li>
10459 <li> remove the copy constructor declaration from 26.5.5.1 [cons.slice.arr]</li>
10460 <li> change paragraph 1 of 26.5.5.1 [cons.slice.arr] to read "This constructor is declared
10461     to be private.  This constructor need not be defined."</li>
10462 <li> remove the first sentence of paragraph 1 of 26.5.5.2 [slice.arr.assign]</li>
10463 <li> Change the first three words of the second sentence of paragraph 1 of
10464     26.5.5.2 [slice.arr.assign] to "These assignment operators have"</li>
10465 </ul>
10466
10467 <p>gslice_array:</p>
10468 <ul>
10469 <li> Make the copy constructor and copy-assignment operator declarations
10470     public in the gslice_array class template definition in 26.5.7 [template.gslice.array] </li>
10471 <li> remove the note in paragraph 3 of 26.5.7 [template.gslice.array]</li>
10472 <li> remove the copy constructor declaration from 26.5.7.1 [gslice.array.cons]</li>
10473 <li> change paragraph 1 of 26.5.7.1 [gslice.array.cons] to read "This constructor is declared
10474     to be private.  This constructor need not be defined."</li>
10475 <li> remove the first sentence of paragraph 1 of 26.5.7.2 [gslice.array.assign]</li>
10476 <li> Change the first three words of the second sentence of paragraph 1 of
10477     26.5.7.2 [gslice.array.assign] to "These assignment operators have"</li>
10478 </ul>
10479
10480 <p>mask_array:</p>
10481 <ul>
10482 <li> Make the copy constructor and copy-assignment operator declarations
10483     public in the mask_array class template definition in 26.5.8 [template.mask.array] </li>
10484 <li> remove the note in paragraph 2 of 26.5.8 [template.mask.array]</li>
10485 <li> remove the copy constructor declaration from 26.5.8.1 [mask.array.cons]</li>
10486 <li> change paragraph 1 of 26.5.8.1 [mask.array.cons] to read "This constructor is declared
10487     to be private.  This constructor need not be defined."</li>
10488 <li> remove the first sentence of paragraph 1 of 26.5.8.2 [mask.array.assign]</li>
10489 <li> Change the first three words of the second sentence of paragraph 1 of
10490     26.5.8.2 [mask.array.assign] to "These assignment operators have"</li>
10491 </ul>
10492
10493 <p>indirect_array:</p>
10494 <ul>
10495 <li>Make the copy constructor and copy-assignment operator declarations
10496     public in the indirect_array class definition in 26.5.9 [template.indirect.array]</li>
10497 <li> remove the note in paragraph 2 of 26.5.9 [template.indirect.array]</li>
10498 <li> remove the copy constructor declaration from 26.5.9.1 [indirect.array.cons]</li>
10499 <li> change the descriptive text in 26.5.9.1 [indirect.array.cons] to read "This constructor is
10500     declared to be private.  This constructor need not be defined."</li>
10501 <li> remove the first sentence of paragraph 1 of 26.5.9.2 [indirect.array.assign]</li>
10502 <li> Change the first three words of the second sentence of paragraph 1 of
10503     26.5.9.2 [indirect.array.assign] to "These assignment operators have"</li>
10504 </ul>
10505 <p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
10506 copy constructor and copy assignment operators public, instead of
10507 removing them.]</i></p>
10508
10509
10510
10511 <p><b>Rationale:</b></p>
10512 <p>Keeping the valarray constructors private is untenable.  Merely
10513 making valarray a friend of the helper classes isn't good enough,
10514 because access to the copy constructor is checked in the user's
10515 environment.</p>
10516
10517 <p>Making the assignment operator public is not strictly necessary to
10518 solve this problem.  A majority of the LWG <i>(straw poll: 13-4)</i>
10519 believed we should make the assignment operators public, in addition
10520 to the copy constructors, for reasons of symmetry and user
10521 expectation.</p>
10522
10523
10524
10525
10526
10527 <hr>
10528 <h3><a name="254"></a>254. Exception types in clause 19 are constructed from <tt>std::string</tt></h3>
10529 <p><b>Section:</b> 19.1 [std.exceptions], 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10530  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-08-01</p>
10531 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10532 <p><b>Discussion:</b></p>
10533 <p>
10534 Many of the standard exception types which implementations are
10535 required to throw are constructed with a const std::string&amp;
10536 parameter. For example:
10537 </p>
10538
10539 <pre>     19.1.5  Class out_of_range                          [lib.out.of.range]
10540      namespace std {
10541        class out_of_range : public logic_error {
10542        public:
10543          explicit out_of_range(const string&amp; what_arg);
10544        };
10545      }
10546
10547    1 The class out_of_range defines the type of objects  thrown  as  excep-
10548      tions to report an argument value not in its expected range.
10549
10550      out_of_range(const string&amp; what_arg);
10551
10552      Effects:
10553        Constructs an object of class out_of_range.
10554      Postcondition:
10555        strcmp(what(), what_arg.c_str()) == 0.
10556 </pre>
10557
10558 <p>
10559 There are at least two problems with this:
10560 </p>
10561 <ol>
10562 <li>A program which is low on memory may end up throwing
10563 std::bad_alloc instead of out_of_range because memory runs out while
10564 constructing the exception object.</li>
10565 <li>An obvious implementation which stores a std::string data member
10566 may end up invoking terminate() during exception unwinding because the
10567 exception object allocates memory (or rather fails to) as it is being
10568 copied.</li>
10569 </ol>
10570
10571 <p>
10572 There may be no cure for (1) other than changing the interface to
10573 out_of_range, though one could reasonably argue that (1) is not a
10574 defect. Personally I don't care that much if out-of-memory is reported
10575 when I only have 20 bytes left, in the case when out_of_range would
10576 have been reported. People who use exception-specifications might care
10577 a lot, though.
10578 </p>
10579
10580 <p>
10581 There is a cure for (2), but it isn't completely obvious. I think a
10582 note for implementors should be made in the standard. Avoiding
10583 possible termination in this case shouldn't be left up to chance.  The
10584 cure is to use a reference-counted "string" implementation
10585 in the exception object. I am not necessarily referring to a
10586 std::string here; any simple reference-counting scheme for a NTBS
10587 would do.
10588 </p>
10589
10590 <p><b>Further discussion, in email:</b></p>
10591
10592 <p>
10593 ...I'm not so concerned about (1). After all, a library implementation
10594 can add const char* constructors as an extension, and users don't
10595 <i>need</i> to avail themselves of the standard exceptions, though this is
10596 a lame position to be forced into.  FWIW, std::exception and
10597 std::bad_alloc don't require a temporary basic_string.
10598 </p>
10599
10600 <p>
10601 ...I don't think the fixed-size buffer is a solution to the problem,
10602 strictly speaking, because you can't satisfy the postcondition
10603 <br>
10604     <tt>&nbsp;&nbsp;strcmp(what(), what_arg.c_str()) == 0</tt>
10605 <br>
10606 For all values of what_arg (i.e. very long values). That means that
10607 the only truly conforming solution requires a dynamic allocation.
10608 </p>
10609
10610 <p><b>Further discussion, from Redmond:</b></p>
10611
10612 <p>The most important progress we made at the Redmond meeting was
10613 realizing that there are two separable issues here: the const
10614 string&amp; constructor, and the copy constructor.  If a user writes
10615 something like <tt>throw std::out_of_range("foo")</tt>, the const
10616 string&amp; constructor is invoked before anything gets thrown.  The
10617 copy constructor is potentially invoked during stack unwinding.</p>
10618
10619 <p>The copy constructor is a more serious problem, becuase failure
10620 during stack unwinding invokes <tt>terminate</tt>.  The copy
10621 constructor must be nothrow. <i>Curaçao: Howard thinks this
10622 requirement may already be present.</i></p>
10623
10624 <p>The fundamental problem is that it's difficult to get the nothrow
10625 requirement to work well with the requirement that the exception
10626 objects store a string of unbounded size, particularly if you also try
10627 to make the const string&amp; constructor nothrow.  Options discussed
10628 include:</p>
10629
10630 <ul>
10631 <li>Limit the size of a string that exception objects are required to
10632 throw: change the postconditions of 19.1.2 [domain.error] paragraph 3
10633 and 19.1.6 [runtime.error] paragraph 3 to something like this:
10634 "strncmp(what(), what_arg._str(), N) == 0, where N is an
10635 implementation defined constant no smaller than 256".</li>
10636 <li>Allow the const string&amp; constructor to throw, but not the
10637 copy constructor.  It's the implementor's responsibility to get it
10638 right.  (An implementor might use a simple refcount class.)</li>
10639 <li>Compromise between the two: an implementation is not allowed to
10640 throw if the string's length is less than some N, but, if it doesn't
10641 throw, the string must compare equal to the argument.</li>
10642 <li>Add a new constructor that takes a const char*</li>
10643 </ul>
10644
10645 <p>(Not all of these options are mutually exclusive.)</p>
10646
10647
10648
10649 <p><b>Proposed resolution:</b></p>
10650
10651 <p>
10652 Change 19.1.1 [logic.error]
10653 </p>
10654
10655 <blockquote>
10656 <pre>namespace std {
10657   class logic_error : public exception {
10658   public:
10659     explicit logic_error(const string&amp; <i>what_arg</i>);
10660     <ins>explicit logic_error(const char* <i>what_arg</i>);</ins>
10661   };
10662 }
10663 </pre>
10664 <p>...</p>
10665 <p>
10666 <ins><tt>logic_error(const char* <i>what_arg</i>);</tt></ins>
10667 </p>
10668 <blockquote>
10669 <p><ins>
10670 -4- <i>Effects:</i> Constructs an object of class <tt>logic_error</tt>.
10671 </ins></p>
10672 <p><ins>
10673 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10674 </ins></p>
10675 </blockquote>
10676
10677 </blockquote>
10678
10679 <p>
10680 Change 19.1.2 [domain.error]
10681 </p>
10682
10683 <blockquote>
10684 <pre>namespace std {
10685   class domain_error : public logic_error {
10686   public:
10687     explicit domain_error(const string&amp; <i>what_arg</i>);
10688     <ins>explicit domain_error(const char* <i>what_arg</i>);</ins>
10689   };
10690 }
10691 </pre>
10692 <p>...</p>
10693 <p>
10694 <ins><tt>domain_error(const char* <i>what_arg</i>);</tt></ins>
10695 </p>
10696 <blockquote>
10697 <p><ins>
10698 -4- <i>Effects:</i> Constructs an object of class <tt>domain_error</tt>.
10699 </ins></p>
10700 <p><ins>
10701 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10702 </ins></p>
10703
10704 </blockquote>
10705 </blockquote>
10706
10707 <p>
10708 Change 19.1.3 [invalid.argument]
10709 </p>
10710
10711 <blockquote>
10712 <pre>namespace std {
10713   class invalid_argument : public logic_error {
10714   public:
10715     explicit invalid_argument(const string&amp; <i>what_arg</i>);
10716     <ins>explicit invalid_argument(const char* <i>what_arg</i>);</ins>
10717   };
10718 }
10719 </pre>
10720 <p>...</p>
10721 <p>
10722 <ins><tt>invalid_argument(const char* <i>what_arg</i>);</tt></ins>
10723 </p>
10724 <blockquote>
10725 <p><ins>
10726 -4- <i>Effects:</i> Constructs an object of class <tt>invalid_argument</tt>.
10727 </ins></p>
10728 <p><ins>
10729 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10730 </ins></p>
10731 </blockquote>
10732
10733 </blockquote>
10734
10735 <p>
10736 Change 19.1.4 [length.error]
10737 </p>
10738
10739 <blockquote>
10740 <pre>namespace std {
10741   class length_error : public logic_error {
10742   public:
10743     explicit length_error(const string&amp; <i>what_arg</i>);
10744     <ins>explicit length_error(const char* <i>what_arg</i>);</ins>
10745   };
10746 }
10747 </pre>
10748 <p>...</p>
10749 <p>
10750 <ins><tt>length_error(const char* <i>what_arg</i>);</tt></ins>
10751 </p>
10752 <blockquote>
10753 <p><ins>
10754 -4- <i>Effects:</i> Constructs an object of class <tt>length_error</tt>.
10755 </ins></p>
10756 <p><ins>
10757 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10758 </ins></p>
10759 </blockquote>
10760
10761 </blockquote>
10762
10763 <p>
10764 Change 19.1.5 [out.of.range]
10765 </p>
10766
10767 <blockquote>
10768 <pre>namespace std {
10769   class out_of_range : public logic_error {
10770   public:
10771     explicit out_of_range(const string&amp; <i>what_arg</i>);
10772     <ins>explicit out_of_range(const char* <i>what_arg</i>);</ins>
10773   };
10774 }
10775 </pre>
10776 <p>...</p>
10777 <p>
10778 <ins><tt>out_of_range(const char* <i>what_arg</i>);</tt></ins>
10779 </p>
10780 <blockquote>
10781 <p><ins>
10782 -4- <i>Effects:</i> Constructs an object of class <tt>out_of_range</tt>.
10783 </ins></p>
10784 <p><ins>
10785 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10786 </ins></p>
10787 </blockquote>
10788
10789 </blockquote>
10790
10791 <p>
10792 Change 19.1.6 [runtime.error]
10793 </p>
10794
10795 <blockquote>
10796 <pre>namespace std {
10797   class runtime_error : public exception {
10798   public:
10799     explicit runtime_error(const string&amp; <i>what_arg</i>);
10800     <ins>explicit runtime_error(const char* <i>what_arg</i>);</ins>
10801   };
10802 }
10803 </pre>
10804 <p>...</p>
10805 <p>
10806 <ins><tt>runtime_error(const char* <i>what_arg</i>);</tt></ins>
10807 </p>
10808 <blockquote>
10809 <p><ins>
10810 -4- <i>Effects:</i> Constructs an object of class <tt>runtime_error</tt>.
10811 </ins></p>
10812 <p><ins>
10813 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10814 </ins></p>
10815 </blockquote>
10816
10817 </blockquote>
10818
10819 <p>
10820 Change 19.1.7 [range.error]
10821 </p>
10822
10823 <blockquote>
10824 <pre>namespace std {
10825   class range_error : public runtime_error {
10826   public:
10827     explicit range_error(const string&amp; <i>what_arg</i>);
10828     <ins>explicit range_error(const char* <i>what_arg</i>);</ins>
10829   };
10830 }
10831 </pre>
10832 <p>...</p>
10833 <p>
10834 <ins><tt>range_error(const char* <i>what_arg</i>);</tt></ins>
10835 </p>
10836 <blockquote>
10837 <p><ins>
10838 -4- <i>Effects:</i> Constructs an object of class <tt>range_error</tt>.
10839 </ins></p>
10840 <p><ins>
10841 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10842 </ins></p>
10843 </blockquote>
10844
10845 </blockquote>
10846
10847 <p>
10848 Change 19.1.8 [overflow.error]
10849 </p>
10850
10851 <blockquote>
10852 <pre>namespace std {
10853   class overflow_error : public runtime_error {
10854   public:
10855     explicit overflow_error(const string&amp; <i>what_arg</i>);
10856     <ins>explicit overflow_error(const char* <i>what_arg</i>);</ins>
10857   };
10858 }
10859 </pre>
10860 <p>...</p>
10861 <p>
10862 <ins><tt>overflow_error(const char* <i>what_arg</i>);</tt></ins>
10863 </p>
10864 <blockquote>
10865 <p><ins>
10866 -4- <i>Effects:</i> Constructs an object of class <tt>overflow_error</tt>.
10867 </ins></p>
10868 <p><ins>
10869 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10870 </ins></p>
10871 </blockquote>
10872
10873 </blockquote>
10874
10875 <p>
10876 Change 19.1.9 [underflow.error]
10877 </p>
10878
10879 <blockquote>
10880 <pre>namespace std {
10881   class underflow_error : public runtime_error {
10882   public:
10883     explicit underflow_error(const string&amp; <i>what_arg</i>);
10884     <ins>explicit underflow_error(const char* <i>what_arg</i>);</ins>
10885   };
10886 }
10887 </pre>
10888 <p>...</p>
10889 <p>
10890 <ins><tt>underflow_error(const char* <i>what_arg</i>);</tt></ins>
10891 </p>
10892 <blockquote>
10893 <p><ins>
10894 -4- <i>Effects:</i> Constructs an object of class <tt>underflow_error</tt>.
10895 </ins></p>
10896 <p><ins>
10897 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10898 </ins></p>
10899 </blockquote>
10900
10901 </blockquote>
10902
10903 <p>
10904 Change 27.4.2.1.1 [ios::failure]
10905 </p>
10906
10907 <blockquote>
10908 <pre>namespace std {
10909   class ios_base::failure : public exception {
10910   public:
10911     explicit failure(const string&amp; <i>msg</i>);
10912     <ins>explicit failure(const char* <i>msg</i>);</ins>
10913     virtual const char* what() const throw();
10914 };
10915 }
10916 </pre>
10917 <p>...</p>
10918 <p>
10919 <ins><tt>failure(const char* <i>msg</i>);</tt></ins>
10920 </p>
10921 <blockquote>
10922 <p><ins>
10923 -4- <i>Effects:</i> Constructs an object of class <tt>failure</tt>.
10924 </ins></p>
10925 <p><ins>
10926 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>msg</i>) == 0</tt>.
10927 </ins></p>
10928 </blockquote>
10929
10930 </blockquote>
10931
10932
10933
10934 <p><b>Rationale:</b></p>
10935
10936 <p>Throwing a bad_alloc while trying to construct a message for another
10937 exception-derived class is not necessarily a bad thing.  And the
10938 bad_alloc constructor already has a no throw spec on it (18.4.2.1).</p>
10939
10940 <p><b>Future:</b></p>
10941
10942 <p>All involved would like to see const char* constructors added, but
10943 this should probably be done for C++0X as opposed to a DR.</p>
10944
10945 <p>I believe the no throw specs currently decorating these functions
10946 could be improved by some kind of static no throw spec checking
10947 mechanism (in a future C++ language).  As they stand, the copy
10948 constructors might fail via a call to unexpected.  I think what is
10949 intended here is that the copy constructors can't fail.</p>
10950
10951 <p><i>[Pre-Sydney: reopened at the request of Howard Hinnant.
10952   Post-Redmond: James Kanze noticed that the copy constructors of
10953   exception-derived classes do not have nothrow clauses.  Those
10954   classes have no copy constructors declared, meaning the
10955   compiler-generated implicit copy constructors are used, and those
10956   compiler-generated constructors might in principle throw anything.]</i></p>
10957
10958
10959 <p><i>[
10960 Batavia:  Merged copy constructor and assignment operator spec into <tt>exception</tt>
10961 and added <tt>ios::failure</tt> into the proposed resolution.
10962 ]</i></p>
10963
10964
10965 <p><i>[
10966 Oxford:  The proposed resolution simply addresses the issue of constructing
10967 the exception objects with <tt>const char*</tt> and string literals without
10968 the need to explicit include or construct a <tt>std::string</tt>.
10969 ]</i></p>
10970
10971
10972
10973
10974
10975
10976
10977 <hr>
10978 <h3><a name="256"></a>256. typo in 27.4.4.2, p17: copy_event does not exist</h3>
10979 <p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10980  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-21</p>
10981 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
10982 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10983 <p><b>Discussion:</b></p>
10984 <p>
10985 27.4.4.2, p17 says
10986 </p>
10987
10988 <blockquote><p>
10989 -17- Before copying any parts of rhs, calls each registered callback
10990 pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
10991 exceptions() have been replaced, calls each callback pair that was
10992 copied from rhs as (*fn)(copy_event,*this,index).
10993 </p></blockquote>
10994
10995 <p>
10996 The name copy_event isn't defined anywhere. The intended name was
10997 copyfmt_event.
10998 </p>
10999
11000
11001 <p><b>Proposed resolution:</b></p>
11002 <p>Replace copy_event with copyfmt_event in the named paragraph.</p>
11003
11004
11005
11006
11007 <hr>
11008 <h3><a name="258"></a>258. Missing allocator requirement</h3>
11009 <p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
11010  <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-08-22</p>
11011 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
11012 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
11013 <p><b>Discussion:</b></p>
11014 <p>
11015 From lib-7752:
11016 </p>
11017
11018 <p>
11019 I've been assuming (and probably everyone else has been assuming) that
11020 allocator instances have a particular property, and I don't think that
11021 property can be deduced from anything in Table 32.
11022 </p>
11023
11024 <p>
11025 I think we have to assume that allocator type conversion is a
11026 homomorphism.  That is, if x1 and x2 are of type X, where
11027 X::value_type is T, and if type Y is X::template
11028 rebind&lt;U&gt;::other, then Y(x1) == Y(x2) if and only if x1 == x2.
11029 </p>
11030
11031 <p>
11032 Further discussion: Howard Hinnant writes, in lib-7757:
11033 </p>
11034
11035 <p>
11036 I think I can prove that this is not provable by Table 32.  And I agree
11037 it needs to be true except for the "and only if".  If x1 != x2, I see no
11038 reason why it can't be true that Y(x1) == Y(x2).  Admittedly I can't
11039 think of a practical instance where this would happen, or be valuable.
11040 But I also don't see a need to add that extra restriction.  I think we
11041 only need:
11042 </p>
11043
11044 <blockquote><p>
11045      if (x1 == x2) then Y(x1) == Y(x2)
11046 </p></blockquote>
11047
11048 <p>
11049 If we decide that == on allocators is transitive, then I think I can
11050 prove the above.  But I don't think == is necessarily transitive on
11051 allocators.  That is:
11052 </p>
11053
11054 <p>
11055 Given x1 == x2  and x2 == x3, this does not mean x1 == x3.
11056 </p>
11057
11058 <p>Example:</p>
11059
11060 <blockquote>
11061 <p>
11062 x1 can deallocate pointers from:  x1, x2, x3    <br>
11063 x2 can deallocate pointers from:  x1, x2, x4    <br>
11064 x3 can deallocate pointers from:  x1, x3        <br>
11065 x4 can deallocate pointers from:  x2, x4
11066 </p>
11067
11068 <p>
11069 x1 == x2, and x2 == x4, but x1 != x4
11070 </p>
11071 </blockquote>
11072 <p><i>[Toronto: LWG members offered multiple opinions.  One
11073 opinion is that it should not be required that <tt>x1 == x2</tt>
11074 implies <tt>Y(x1) == Y(x2)</tt>, and that it should not even be
11075 required that <tt>X(x1) == x1</tt>.  Another opinion is that
11076 the second line from the bottom in table 32 already implies the
11077 desired property.  This issue should be considered in light of
11078 other issues related to allocator instances.]</i></p>
11079
11080
11081
11082 <p><b>Proposed resolution:</b></p>
11083 <p>
11084 Add row to Table 35: Allocator requirements, right after the row defining <tt>operator!=</tt>:
11085 </p>
11086
11087 <blockquote>
11088 <p>
11089 If <tt>a1 == a2</tt> then <tt>Y(a1) == Y(a2)</tt>
11090 </p>
11091 </blockquote>
11092
11093
11094
11095 <p><i>[Lillehammer: Same conclusion as before: this should be
11096   considered as part of an allocator redesign, not solved on its own.]</i></p>
11097
11098
11099 <p><i>[
11100 Batavia:  An allocator redesign is not forthcoming and thus we fixed this one issue.
11101 ]</i></p>
11102
11103
11104
11105
11106
11107 <hr>
11108 <h3><a name="259"></a>259. <tt>basic_string::operator[]</tt> and const correctness</h3>
11109 <p><b>Section:</b> 21.3.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11110  <b>Submitter:</b> Chris Newton  <b>Date:</b> 2000-08-27</p>
11111 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.capacity">issues</a> in [string.capacity].</p>
11112 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11113 <p><b>Discussion:</b></p>
11114 <p>
11115 <i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
11116 </p>
11117
11118 <p>
11119 The standard's description of <tt>basic_string&lt;&gt;::operator[]</tt>
11120 seems to violate const correctness.
11121 </p>
11122
11123 <p>
11124 The standard (21.3.4/1) says that "If <tt>pos &lt; size()</tt>,
11125 returns <tt>data()[pos]</tt>." The types don't work.  The
11126 return value of <tt>data()</tt> is <tt>const charT*</tt>, but
11127 <tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
11128 </p>
11129
11130
11131 <p><b>Proposed resolution:</b></p>
11132 <p>
11133 In section 21.3.4, paragraph 1, change
11134 "<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
11135 <i>pos</i>)</tt>".
11136 </p>
11137
11138
11139
11140
11141 <hr>
11142 <h3><a name="260"></a>260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt></h3>
11143 <p><b>Section:</b> 24.5.1.2 [istream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11144  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-27</p>
11145 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator.ops">issues</a> in [istream.iterator.ops].</p>
11146 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11147 <p><b>Discussion:</b></p>
11148 <p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
11149 it as returning the iterator by value. 24.5.1.2, p5 shows the same
11150 operator as returning the iterator by reference. That's incorrect
11151 given the Effects clause below (since a temporary is returned). The
11152 `&amp;' is probably just a typo.</p>
11153
11154
11155 <p><b>Proposed resolution:</b></p>
11156 <p>Change the declaration in 24.5.1.2, p5 from</p>
11157  <pre> istream_iterator&lt;T,charT,traits,Distance&gt;&amp; operator++(int);
11158  </pre>
11159 <p>to</p>
11160  <pre> istream_iterator&lt;T,charT,traits,Distance&gt; operator++(int);
11161  </pre>
11162 <p>(that is, remove the `&amp;').</p>
11163
11164
11165
11166
11167 <hr>
11168 <h3><a name="261"></a>261. Missing description of <tt>istream_iterator::operator!=</tt></h3>
11169 <p><b>Section:</b> 24.5.1.2 [istream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11170  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-27</p>
11171 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator.ops">issues</a> in [istream.iterator.ops].</p>
11172 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11173 <p><b>Discussion:</b></p>
11174 <p>
11175 24.5.1, p3 lists the synopsis for
11176 </p>
11177
11178 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
11179         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
11180                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
11181 </pre>
11182
11183 <p>
11184 but there is no description of what the operator does (i.e., no Effects
11185 or Returns clause) in 24.5.1.2.
11186 </p>
11187
11188
11189 <p><b>Proposed resolution:</b></p>
11190 <p>
11191 Add paragraph 7 to the end of section 24.5.1.2 with the following text:
11192 </p>
11193
11194 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
11195         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
11196                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
11197 </pre>
11198
11199 <p>-7- Returns: !(x == y).</p>
11200
11201
11202
11203
11204 <hr>
11205 <h3><a name="262"></a>262. Bitmask operator ~ specified incorrectly</h3>
11206 <p><b>Section:</b> 17.3.2.1.2 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11207  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2000-09-03</p>
11208 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11209 <p><b>Discussion:</b></p>
11210 <p>
11211 The ~ operation should be applied after the cast to int_type.
11212 </p>
11213
11214
11215 <p><b>Proposed resolution:</b></p>
11216 <p>
11217 Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
11218 </p>
11219
11220 <pre>   bitmask operator~ ( bitmask X )
11221      { return static_cast&lt; bitmask&gt;(static_cast&lt;int_type&gt;(~ X)); }
11222 </pre>
11223
11224 <p>
11225 to:
11226 </p>
11227
11228 <pre>   bitmask operator~ ( bitmask X )
11229      { return static_cast&lt; bitmask&gt;(~static_cast&lt;int_type&gt;(X)); }
11230 </pre>
11231
11232
11233
11234
11235 <hr>
11236 <h3><a name="263"></a>263. Severe restriction on <tt>basic_string</tt> reference counting</h3>
11237 <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11238  <b>Submitter:</b> Kevlin Henney <b>Date:</b> 2000-09-04</p>
11239 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
11240 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11241 <p><b>Discussion:</b></p>
11242 <p>
11243 The note in paragraph 6 suggests that the invalidation rules for
11244 references, pointers, and iterators in paragraph 5 permit a reference-
11245 counted implementation (actually, according to paragraph 6, they permit
11246 a "reference counted implementation", but this is a minor editorial fix).
11247 </p>
11248
11249 <p>
11250 However, the last sub-bullet is so worded as to make a reference-counted
11251 implementation unviable. In the following example none of the
11252 conditions for iterator invalidation are satisfied:
11253 </p>
11254
11255 <pre>    // first example: "*******************" should be printed twice
11256     string original = "some arbitrary text", copy = original;
11257     const string &amp; alias = original;
11258
11259     string::const_iterator i = alias.begin(), e = alias.end();
11260     for(string::iterator j = original.begin(); j != original.end(); ++j)
11261         *j = '*';
11262     while(i != e)
11263         cout &lt;&lt; *i++;
11264     cout &lt;&lt; endl;
11265     cout &lt;&lt; original &lt;&lt; endl;
11266 </pre>
11267
11268 <p>
11269 Similarly, in the following example:
11270 </p>
11271
11272 <pre>    // second example: "some arbitrary text" should be printed out
11273     string original = "some arbitrary text", copy = original;
11274     const string &amp; alias = original;
11275
11276     string::const_iterator i = alias.begin();
11277     original.begin();
11278     while(i != alias.end())
11279         cout &lt;&lt; *i++;
11280 </pre>
11281
11282 <p>
11283 I have tested this on three string implementations, two of which were
11284 reference counted. The reference-counted implementations gave
11285 "surprising behavior" because they invalidated iterators on
11286 the first call to non-const begin since construction. The current
11287 wording does not permit such invalidation because it does not take
11288 into account the first call since construction, only the first call
11289 since various member and non-member function calls.
11290 </p>
11291
11292
11293 <p><b>Proposed resolution:</b></p>
11294 <p>
11295 Change the following sentence in 21.3 paragraph 5 from
11296 </p>
11297
11298 <blockquote><p>
11299     Subsequent to any of the above uses except the forms of insert() and
11300     erase() which return iterators, the first call to non-const member
11301     functions operator[](), at(), begin(), rbegin(), end(), or rend().
11302 </p></blockquote>
11303
11304 <p>to</p>
11305
11306 <blockquote><p>
11307     Following construction or any of the above uses, except the forms of
11308     insert() and erase() that return iterators, the first call to non-
11309     const member functions operator[](), at(), begin(), rbegin(), end(),
11310     or rend().
11311 </p></blockquote>
11312
11313
11314
11315
11316 <hr>
11317 <h3><a name="264"></a>264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3>
11318 <p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11319  <b>Submitter:</b> John Potter <b>Date:</b> 2000-09-07</p>
11320 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
11321 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11322 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></p>
11323 <p><b>Discussion:</b></p>
11324 <p>
11325 Table 69 requires linear time if [i, j) is sorted.  Sorted is necessary but not sufficient.
11326 Consider inserting a sorted range of even integers into a set&lt;int&gt; containing the odd
11327 integers in the same range.
11328 </p>
11329
11330 <p><i>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></i></p>
11331
11332
11333 <p><b>Proposed resolution:</b></p>
11334 <p>
11335 In Table 69, in section 23.1.2, change the complexity clause for
11336 insertion of a range from "N log(size() + N) (N is the distance
11337 from i to j) in general; linear if [i, j) is sorted according to
11338 value_comp()" to "N log(size() + N), where N is the distance
11339 from i to j".
11340 </p>
11341
11342 <p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
11343 parens in the revised wording.]</i></p>
11344
11345
11346
11347
11348 <p><b>Rationale:</b></p>
11349 <p>
11350 Testing for valid insertions could be less efficient than simply
11351 inserting the elements when the range is not both sorted and between
11352 two adjacent existing elements; this could be a QOI issue.
11353 </p>
11354
11355 <p>
11356 The LWG considered two other options: (a) specifying that the
11357 complexity was linear if [i, j) is sorted according to value_comp()
11358 and between two adjacent existing elements; or (b) changing to
11359 Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
11360 number of elements which do not insert immediately after the previous
11361 element from [i, j) including the first).  The LWG felt that, since
11362 we can't guarantee linear time complexity whenever the range to be
11363 inserted is sorted, it's more trouble than it's worth to say that it's
11364 linear in some special cases.
11365 </p>
11366
11367
11368
11369
11370 <hr>
11371 <h3><a name="265"></a>265. std::pair::pair() effects overly restrictive</h3>
11372 <p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11373  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-09-11</p>
11374 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
11375 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11376 <p><b>Discussion:</b></p>
11377 <p>
11378 I don't see any requirements on the types of the elements of the
11379 std::pair container in 20.2.2. From the descriptions of the member
11380 functions it appears that they must at least satisfy the requirements of
11381 20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
11382 the case of the [in]equality operators also the requirements of 20.1.1
11383 [lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
11384 </p>
11385
11386 <p>
11387 I believe that the the CopyConstructible requirement is unnecessary in
11388 the case of 20.2.2, p2.
11389 </p>
11390
11391
11392 <p><b>Proposed resolution:</b></p>
11393 <p>Change the Effects clause in 20.2.2, p2 from</p>
11394
11395 <blockquote><p>
11396 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
11397 first(T1()), second(T2()) {} </tt>
11398 </p></blockquote>
11399
11400 <p>to</p>
11401
11402 <blockquote><p>
11403 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
11404 first(), second() {} </tt>
11405 </p></blockquote>
11406
11407
11408 <p><b>Rationale:</b></p>
11409 <p>The existing specification of pair's constructor appears to be a
11410 historical artifact: there was concern that pair's members be properly
11411 zero-initialized when they are built-in types.  At one time there was
11412 uncertainty about whether they would be zero-initialized if the
11413 default constructor was written the obvious way.  This has been
11414 clarified by core issue 178, and there is no longer any doubt that
11415 the straightforward implementation is correct.</p>
11416
11417
11418
11419
11420 <hr>
11421 <h3><a name="266"></a>266. bad_exception::~bad_exception() missing Effects clause</h3>
11422 <p><b>Section:</b> 18.7.2.1 [bad.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11423  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-09-24</p>
11424 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11425 <p><b>Discussion:</b></p>
11426 <p>
11427 The synopsis for std::bad_exception lists the function ~bad_exception()
11428 but there is no description of what the function does (the Effects
11429 clause is missing).
11430 </p>
11431
11432
11433 <p><b>Proposed resolution:</b></p>
11434 <p>
11435 Remove the destructor from the class synopses of
11436 <tt>bad_alloc</tt> (18.5.2.1 [bad.alloc]),
11437 <tt>bad_cast</tt> (18.6.2 [bad.cast]),
11438 <tt>bad_typeid</tt> (18.6.3 [bad.typeid]),
11439 and <tt>bad_exception</tt> (18.7.2.1 [bad.exception]).
11440 </p>
11441
11442
11443 <p><b>Rationale:</b></p>
11444 <p>
11445 This is a general problem with the exception classes in clause 18.
11446 The proposed resolution is to remove the destructors from the class
11447 synopses, rather than to document the destructors' behavior, because
11448 removing them is more consistent with how exception classes are
11449 described in clause 19.
11450 </p>
11451
11452
11453
11454
11455 <hr>
11456 <h3><a name="268"></a>268. Typo in locale synopsis</h3>
11457 <p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11458  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-10-05</p>
11459 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
11460 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11461 <p><b>Discussion:</b></p>
11462 <p>The synopsis of the class std::locale in 22.1.1 contains two typos:
11463 the semicolons after the declarations of the default ctor
11464 locale::locale() and the copy ctor locale::locale(const locale&amp;)
11465 are missing.</p>
11466
11467
11468 <p><b>Proposed resolution:</b></p>
11469 <p>Add the missing semicolons, i.e., change</p>
11470
11471 <pre>    //  construct/copy/destroy:
11472         locale() throw()
11473         locale(const locale&amp; other) throw()
11474 </pre>
11475
11476 <p>in the synopsis in 22.1.1 to</p>
11477
11478 <pre>    //  construct/copy/destroy:
11479         locale() throw();
11480         locale(const locale&amp; other) throw();
11481 </pre>
11482
11483
11484
11485
11486 <hr>
11487 <h3><a name="270"></a>270. Binary search requirements overly strict</h3>
11488 <p><b>Section:</b> 25.3.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11489  <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-10-18</p>
11490 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.binary.search">issues</a> in [alg.binary.search].</p>
11491 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11492 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#472">472</a></p>
11493 <p><b>Discussion:</b></p>
11494 <p>
11495 Each of the four binary search algorithms (lower_bound, upper_bound,
11496 equal_range, binary_search) has a form that allows the user to pass a
11497 comparison function object.  According to 25.3, paragraph 2, that
11498 comparison function object has to be a strict weak ordering.
11499 </p>
11500
11501 <p>
11502 This requirement is slightly too strict.  Suppose we are searching
11503 through a sequence containing objects of type X, where X is some
11504 large record with an integer key.  We might reasonably want to look
11505 up a record by key, in which case we would want to write something
11506 like this:
11507 </p>
11508 <pre>    struct key_comp {
11509       bool operator()(const X&amp; x, int n) const {
11510         return x.key() &lt; n;
11511       }
11512     }
11513
11514     std::lower_bound(first, last, 47, key_comp());
11515 </pre>
11516
11517 <p>
11518 key_comp is not a strict weak ordering, but there is no reason to
11519 prohibit its use in lower_bound.
11520 </p>
11521
11522 <p>
11523 There's no difficulty in implementing lower_bound so that it allows
11524 the use of something like key_comp.  (It will probably work unless an
11525 implementor takes special pains to forbid it.)  What's difficult is
11526 formulating language in the standard to specify what kind of
11527 comparison function is acceptable.  We need a notion that's slightly
11528 more general than that of a strict weak ordering, one that can encompass
11529 a comparison function that involves different types.  Expressing that
11530 notion may be complicated.
11531 </p>
11532
11533 <p><i>Additional questions raised at the Toronto meeting:</i></p>
11534 <ul>
11535 <li> Do we really want to specify what ordering the implementor must
11536      use when calling the function object?  The standard gives
11537      specific expressions when describing these algorithms, but it also
11538      says that other expressions (with different argument order) are
11539      equivalent.</li>
11540 <li> If we are specifying ordering, note that the standard uses both
11541      orderings when describing <tt>equal_range</tt>.</li>
11542 <li> Are we talking about requiring these algorithms to work properly
11543      when passed a binary function object whose two argument types
11544      are not the same, or are we talking about requirements when
11545      they are passed a binary function object with several overloaded
11546      versions of <tt>operator()</tt>?</li>
11547 <li> The definition of a strict weak ordering does not appear to give
11548      any guidance on issues of overloading; it only discusses expressions,
11549      and all of the values in these expressions are of the same type.
11550      Some clarification would seem to be in order.</li>
11551 </ul>
11552
11553 <p><i>Additional discussion from Copenhagen:</i></p>
11554 <ul>
11555 <li>It was generally agreed that there is a real defect here: if
11556 the predicate is merely required to be a Strict Weak Ordering, then
11557 it's possible to pass in a function object with an overloaded
11558 operator(), where the version that's actually called does something
11559 completely inappropriate.  (Such as returning a random value.)</li>
11560
11561 <li>An alternative formulation was presented in a paper distributed by
11562 David Abrahams at the meeting, "Binary Search with Heterogeneous
11563 Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
11564 predicate as a Strict Weak Ordering acting on a sorted sequence, view
11565 the predicate/value pair as something that partitions a sequence.
11566 This is almost equivalent to saying that we should view binary search
11567 as if we are given a unary predicate and a sequence, such that f(*p)
11568 is true for all p below a specific point and false for all p above it.
11569 The proposed resolution is based on that alternative formulation.</li>
11570 </ul>
11571
11572
11573 <p><b>Proposed resolution:</b></p>
11574
11575 <p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
11576
11577 <blockquote><p>
11578   3 For all algorithms that take Compare, there is a version that uses
11579   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i &lt;
11580   *j != false. For the algorithms to work correctly, comp has to
11581   induce a strict weak ordering on the values.
11582 </p></blockquote>
11583
11584 <p>to:</p>
11585
11586 <blockquote><p>
11587   3 For all algorithms that take Compare, there is a version that uses
11588   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i
11589   &lt; *j != false. For algorithms other than those described in
11590   lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
11591   a strict weak ordering on the values.
11592 </p></blockquote>
11593
11594 <p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
11595
11596 <blockquote><p>
11597   -6- A sequence [start, finish) is partitioned with respect to an
11598   expression f(e) if there exists an integer n such that
11599   for all 0 &lt;= i &lt; distance(start, finish), f(*(begin+i)) is true if
11600   and only if i &lt; n.
11601 </p></blockquote>
11602
11603 <p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
11604
11605 <blockquote><p>
11606   -1- All of the algorithms in this section are versions of binary
11607    search and assume that the sequence being searched is in order
11608    according to the implied or explicit comparison function. They work
11609    on non-random access iterators minimizing the number of
11610    comparisons, which will be logarithmic for all types of
11611    iterators. They are especially appropriate for random access
11612    iterators, because these algorithms do a logarithmic number of
11613    steps through the data structure. For non-random access iterators
11614    they execute a linear number of steps.
11615 </p></blockquote>
11616
11617 <p>to:</p>
11618
11619 <blockquote><p>
11620    -1- All of the algorithms in this section are versions of binary
11621     search and assume that the sequence being searched is partitioned
11622     with respect to an expression formed by binding the search key to
11623     an argument of the implied or explicit comparison function. They
11624     work on non-random access iterators minimizing the number of
11625     comparisons, which will be logarithmic for all types of
11626     iterators. They are especially appropriate for random access
11627     iterators, because these algorithms do a logarithmic number of
11628     steps through the data structure. For non-random access iterators
11629     they execute a linear number of steps.
11630 </p></blockquote>
11631
11632 <p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
11633
11634 <blockquote><p>
11635    -1- Requires: Type T is LessThanComparable
11636     (lib.lessthancomparable).
11637 </p></blockquote>
11638
11639 <p>to:</p>
11640
11641 <blockquote><p>
11642    -1- Requires: The elements e of [first, last) are partitioned with
11643    respect to the expression e &lt; value or comp(e, value)
11644 </p></blockquote>
11645
11646
11647 <p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
11648
11649 <blockquote><p>
11650    -2- Effects: Finds the first position into which value can be
11651     inserted without violating the ordering.
11652 </p></blockquote>
11653
11654 <p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
11655
11656 <blockquote><p>
11657   -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
11658 </p></blockquote>
11659
11660 <p>to:</p>
11661
11662 <blockquote><p>
11663    -1- Requires: The elements e of [first, last) are partitioned with
11664    respect to the expression !(value &lt; e) or !comp(value, e)
11665 </p></blockquote>
11666
11667 <p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
11668
11669 <blockquote><p>
11670    -2- Effects: Finds the furthermost position into which value can be
11671     inserted without violating the ordering.
11672 </p></blockquote>
11673
11674 <p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
11675
11676 <blockquote><p>
11677    -1- Requires: Type T is LessThanComparable
11678     (lib.lessthancomparable).
11679 </p></blockquote>
11680
11681 <p>to:</p>
11682
11683 <blockquote><p>
11684    -1- Requires: The elements e of [first, last) are partitioned with
11685    respect to the expressions e &lt; value and !(value &lt; e) or
11686    comp(e, value) and !comp(value, e).  Also, for all elements e of
11687    [first, last), e &lt; value implies !(value &lt; e) or comp(e,
11688    value) implies !comp(value, e)
11689 </p></blockquote>
11690
11691 <p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
11692
11693 <blockquote><p>
11694    -2- Effects: Finds the largest subrange [i, j) such that the value
11695     can be inserted at any iterator k in it without violating the
11696     ordering. k satisfies the corresponding conditions: !(*k &lt; value)
11697     &amp;&amp; !(value &lt; *k) or comp(*k, value) == false &amp;&amp; comp(value, *k) ==
11698     false.
11699 </p></blockquote>
11700
11701 <p>to:</p>
11702
11703 <pre>   -2- Returns:
11704          make_pair(lower_bound(first, last, value),
11705                    upper_bound(first, last, value))
11706        or
11707          make_pair(lower_bound(first, last, value, comp),
11708                    upper_bound(first, last, value, comp))
11709 </pre>
11710
11711 <p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
11712
11713 <blockquote><p>
11714    -1- Requires: Type T is LessThanComparable
11715     (lib.lessthancomparable).
11716 </p></blockquote>
11717
11718 <p>to:</p>
11719
11720 <blockquote><p>
11721    -1- Requires: The elements e of [first, last) are partitioned with
11722    respect to the expressions e &lt; value and !(value &lt; e) or comp(e,
11723    value) and !comp(value, e). Also, for all elements e of [first,
11724    last), e &lt; value implies !(value &lt; e) or comp(e, value) implies
11725    !comp(value, e)
11726 </p></blockquote>
11727
11728 <p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
11729
11730
11731 <p><i>[Redmond: Minor changes in wording.  (Removed "non-negative", and
11732 changed the "other than those described in" wording.) Also, the LWG
11733 decided to accept the "optional" part.]</i></p>
11734
11735
11736
11737
11738 <p><b>Rationale:</b></p>
11739 <p>The proposed resolution reinterprets binary search. Instead of
11740 thinking about searching for a value in a sorted range, we view that
11741 as an important special case of a more general algorithm: searching
11742 for the partition point in a partitioned range.</p>
11743
11744 <p>We also add a guarantee that the old wording did not: we ensure
11745 that the upper bound is no earlier than the lower bound, that
11746 the pair returned by equal_range is a valid range, and that the first
11747 part of that pair is the lower bound.</p>
11748
11749
11750
11751
11752
11753 <hr>
11754 <h3><a name="271"></a>271. basic_iostream missing typedefs</h3>
11755 <p><b>Section:</b> 27.6.1.5 [iostreamclass] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11756  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
11757 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11758 <p><b>Discussion:</b></p>
11759 <p>
11760 Class template basic_iostream has no typedefs.  The typedefs it
11761 inherits from its base classes can't be used, since (for example)
11762 basic_iostream&lt;T&gt;::traits_type is ambiguous.
11763 </p>
11764
11765
11766 <p><b>Proposed resolution:</b></p>
11767
11768 <p>Add the following to basic_iostream's class synopsis in
11769 27.6.1.5 [iostreamclass], immediately after <tt>public</tt>:</p>
11770
11771 <pre>  // types:
11772   typedef charT                     char_type;
11773   typedef typename traits::int_type int_type;
11774   typedef typename traits::pos_type pos_type;
11775   typedef typename traits::off_type off_type;
11776   typedef traits                    traits_type;
11777 </pre>
11778
11779
11780
11781
11782 <hr>
11783 <h3><a name="272"></a>272. Missing parentheses around subexpression</h3>
11784 <p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11785  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
11786 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
11787 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11788 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a></p>
11789 <p><b>Discussion:</b></p>
11790 <p>
11791 27.4.4.3, p4 says about the postcondition of the function: If
11792 rdbuf()!=0 then state == rdstate(); otherwise
11793 rdstate()==state|ios_base::badbit.
11794 </p>
11795
11796 <p>
11797 The expression on the right-hand-side of the operator==() needs to be
11798 parenthesized in order for the whole expression to ever evaluate to
11799 anything but non-zero.
11800 </p>
11801
11802
11803 <p><b>Proposed resolution:</b></p>
11804 <p>
11805 Add parentheses like so: rdstate()==(state|ios_base::badbit).
11806 </p>
11807
11808
11809
11810
11811 <hr>
11812 <h3><a name="273"></a>273. Missing ios_base qualification on members of a dependent class</h3>
11813 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11814  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
11815 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
11816 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11817 <p><b>Discussion:</b></p>
11818 <p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
11819 27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
11820 That's incorrect since the names are members of a dependent base
11821 class (14.6.2 [temp.dep]) and thus not visible.</p>
11822
11823
11824 <p><b>Proposed resolution:</b></p>
11825 <p>Qualify the names with the name of the class of which they are
11826 members, i.e., ios_base.</p>
11827
11828
11829
11830
11831 <hr>
11832 <h3><a name="274"></a>274. a missing/impossible allocator requirement</h3>
11833 <p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11834  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
11835 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
11836 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
11837 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11838 <p><b>Discussion:</b></p>
11839 <p>
11840 I see that table 31 in 20.1.5, p3 allows T in std::allocator&lt;T&gt; to be of
11841 any type. But the synopsis in 20.4.1 calls for allocator&lt;&gt;::address() to
11842 be overloaded on reference and const_reference, which is ill-formed for
11843 all T = const U. In other words, this won't work:
11844 </p>
11845
11846 <p>
11847 template class std::allocator&lt;const int&gt;;
11848 </p>
11849
11850 <p>
11851 The obvious solution is to disallow specializations of allocators on
11852 const types. However, while containers' elements are required to be
11853 assignable (which rules out specializations on const T's), I think that
11854 allocators might perhaps be potentially useful for const values in other
11855 contexts. So if allocators are to allow const types a partial
11856 specialization of std::allocator&lt;const T&gt; would probably have to be
11857 provided.
11858 </p>
11859
11860
11861 <p><b>Proposed resolution:</b></p>
11862 <p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
11863
11864     <blockquote><p>
11865     any type
11866     </p></blockquote>
11867
11868 <p>to</p>
11869     <blockquote><p>
11870     any non-const, non-reference type
11871     </p></blockquote>
11872
11873 <p><i>[Redmond: previous proposed resolution was "any non-const,
11874 non-volatile, non-reference type".  Got rid of the "non-volatile".]</i></p>
11875
11876
11877
11878
11879 <p><b>Rationale:</b></p>
11880 <p>
11881 Two resolutions were originally proposed: one that partially
11882 specialized std::allocator for const types, and one that said an
11883 allocator's value type may not be const.  The LWG chose the second.
11884 The first wouldn't be appropriate, because allocators are intended for
11885 use by containers, and const value types don't work in containers.
11886 Encouraging the use of allocators with const value types would only
11887 lead to unsafe code.
11888 </p>
11889 <p>
11890 The original text for proposed resolution 2 was modified so that it
11891 also forbids volatile types and reference types.
11892 </p>
11893
11894 <p><i>[Curaçao: LWG double checked and believes volatile is correctly
11895 excluded from the PR.]</i></p>
11896
11897
11898
11899
11900
11901
11902
11903 <hr>
11904 <h3><a name="275"></a>275. Wrong type in num_get::get() overloads</h3>
11905 <p><b>Section:</b> 22.2.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11906  <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-11-02</p>
11907 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.members">issues</a> in [facet.num.get.members].</p>
11908 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11909 <p><b>Discussion:</b></p>
11910 <p>
11911 In 22.2.2.1.1, we have a list of overloads for num_get&lt;&gt;::get().
11912 There are eight overloads, all of which are identical except for the
11913 last parameter.  The overloads are:
11914 </p>
11915 <ul>
11916 <li> long&amp; </li>
11917 <li> unsigned short&amp; </li>
11918 <li> unsigned int&amp; </li>
11919 <li> unsigned long&amp; </li>
11920 <li> short&amp; </li>
11921 <li> double&amp; </li>
11922 <li> long double&amp; </li>
11923 <li> void*&amp; </li>
11924 </ul>
11925
11926 <p>
11927 There is a similar list, in 22.2.2.1.2, of overloads for
11928 num_get&lt;&gt;::do_get().  In this list, the last parameter has
11929 the types:
11930 </p>
11931 <ul>
11932 <li> long&amp; </li>
11933 <li> unsigned short&amp; </li>
11934 <li> unsigned int&amp; </li>
11935 <li> unsigned long&amp; </li>
11936 <li> float&amp; </li>
11937 <li> double&amp; </li>
11938 <li> long double&amp; </li>
11939 <li> void*&amp; </li>
11940 </ul>
11941
11942 <p>
11943 These two lists are not identical.  They should be, since
11944 <tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
11945 the arguments it was given.
11946 </p>
11947
11948
11949 <p><b>Proposed resolution:</b></p>
11950 <p>In 22.2.2.1.1 [facet.num.get.members], change</p>
11951 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
11952                 ios_base::iostate&amp; err, short&amp; val) const;
11953 </pre>
11954 <p>to</p>
11955 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
11956                 ios_base::iostate&amp; err, float&amp; val) const;
11957 </pre>
11958
11959
11960
11961
11962 <hr>
11963 <h3><a name="276"></a>276. Assignable requirement for container value type overly strict</h3>
11964 <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11965  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2000-11-07</p>
11966 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
11967 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
11968 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11969 <p><b>Discussion:</b></p>
11970 <p>
11971 23.1/3 states that the objects stored in a container must be
11972 Assignable.  23.3.1 [map], paragraph 2,
11973 states that map satisfies all requirements for a container, while in
11974 the same time defining value_type as pair&lt;const Key, T&gt; - a type
11975 that is not Assignable.
11976 </p>
11977
11978 <p>
11979 It should be noted that there exists a valid and non-contradictory
11980 interpretation of the current text. The wording in 23.1/3 avoids
11981 mentioning value_type, referring instead to "objects stored in a
11982 container." One might argue that map does not store objects of
11983 type map::value_type, but of map::mapped_type instead, and that the
11984 Assignable requirement applies to map::mapped_type, not
11985 map::value_type.
11986 </p>
11987
11988 <p>
11989 However, this makes map a special case (other containers store objects of
11990 type value_type) and the Assignable requirement is needlessly restrictive in
11991 general.
11992 </p>
11993
11994 <p>
11995 For example, the proposed resolution of active library issue
11996 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> is to make set::iterator a constant iterator; this
11997 means that no set operations can exploit the fact that the stored
11998 objects are Assignable.
11999 </p>
12000
12001 <p>
12002 This is related to, but slightly broader than, closed issue
12003 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>.
12004 </p>
12005
12006
12007 <p><b>Proposed resolution:</b></p>
12008 <p>23.1/3: Strike the trailing part of the sentence:</p>
12009     <blockquote><p>
12010     , and the additional requirements of Assignable types from 23.1/3
12011     </p></blockquote>
12012 <p>so that it reads:</p>
12013     <blockquote><p>
12014     -3- The type of objects stored in these components must meet the
12015     requirements of CopyConstructible types (lib.copyconstructible).
12016     </p></blockquote>
12017
12018 <p>23.1/4: Modify to make clear that this requirement is not for all
12019 containers.  Change to:</p>
12020
12021 <blockquote><p>
12022 -4- Table 64 defines the Assignable requirement.  Some containers
12023 require this property of the types to be stored in the container.  T is
12024 the type used to instantiate the container. t is a value of T, and u is
12025 a value of (possibly const) T.
12026 </p></blockquote>
12027
12028 <p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
12029 CopyConstructible".</p>
12030
12031 <p>23.2.1/2: Add sentence for Assignable requirement.  Change to:</p>
12032
12033 <blockquote><p>
12034 -2- A deque satisfies all of the requirements of a container and of a
12035 reversible container (given in tables in lib.container.requirements) and
12036 of a sequence, including the optional sequence requirements
12037 (lib.sequence.reqmts).  In addition to the requirements on the stored
12038 object described in 23.1[lib.container.requirements], the stored object
12039 must also meet the requirements of Assignable.  Descriptions are
12040 provided here only for operations on deque that are not described in one
12041 of these tables or for operations where there is additional semantic
12042 information.
12043 </p></blockquote>
12044
12045 <p>23.2.2/2:  Add Assignable requirement to specific methods of list.
12046 Change to:</p>
12047
12048 <blockquote>
12049 <p>-2- A list satisfies all of the requirements of a container and of a
12050 reversible container (given in two tables in lib.container.requirements)
12051 and of a sequence, including most of the the optional sequence
12052 requirements (lib.sequence.reqmts). The exceptions are the operator[]
12053 and at member functions, which are not provided.
12054
12055 [Footnote: These member functions are only provided by containers whose
12056 iterators are random access iterators. --- end foonote]
12057 </p>
12058
12059 <p>list does not require the stored type T to be Assignable unless the
12060 following methods are instantiated:
12061
12062 [Footnote: Implementors are permitted but not required to take advantage
12063 of T's Assignable properties for these methods. -- end foonote]
12064 </p>
12065 <pre>     list&lt;T,Allocator&gt;&amp; operator=(const list&lt;T,Allocator&gt;&amp;  x );
12066      template &lt;class InputIterator&gt;
12067        void assign(InputIterator first, InputIterator last);
12068      void assign(size_type n, const T&amp; t);
12069 </pre>
12070
12071
12072 <p>Descriptions are provided here only for operations on list that are not
12073 described in one of these tables or for operations where there is
12074 additional semantic information.</p>
12075 </blockquote>
12076
12077 <p>23.2.4/2:   Add sentence for Assignable requirement.  Change to:</p>
12078
12079 <blockquote><p>
12080 -2- A vector satisfies all of the requirements of a container and of a
12081 reversible container (given in two tables in lib.container.requirements)
12082 and of a sequence, including most of the optional sequence requirements
12083 (lib.sequence.reqmts). The exceptions are the push_front and pop_front
12084 member functions, which are not provided.  In addition to the
12085 requirements on the stored object described in
12086 23.1[lib.container.requirements], the stored object must also meet the
12087 requirements of Assignable.  Descriptions are provided here only for
12088 operations on vector that are not described in one of these tables or
12089 for operations where there is additional semantic information.
12090 </p></blockquote>
12091
12092
12093 <p><b>Rationale:</b></p>
12094 <p>list, set, multiset, map, multimap are able to store non-Assignables.
12095 However, there is some concern about <tt>list&lt;T&gt;</tt>:
12096 although in general there's no reason for T to be Assignable, some
12097 implementations of the member functions <tt>operator=</tt> and
12098 <tt>assign</tt> do rely on that requirement.  The LWG does not want
12099 to forbid such implementations.</p>
12100
12101 <p>Note that the type stored in a standard container must still satisfy
12102 the requirements of the container's allocator; this rules out, for
12103 example, such types as "const int".  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274">274</a>
12104 for more details.
12105 </p>
12106
12107 <p>In principle we could also relax the "Assignable" requirement for
12108 individual <tt>vector</tt> member functions, such as
12109 <tt>push_back</tt>.  However, the LWG did not see great value in such
12110 selective relaxation.  Doing so would remove implementors' freedom to
12111 implement <tt>vector::push_back</tt> in terms of
12112 <tt>vector::insert</tt>.</p>
12113
12114
12115
12116
12117
12118 <hr>
12119 <h3><a name="278"></a>278. What does iterator validity mean?</h3>
12120 <p><b>Section:</b> 23.2.3.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12121  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2000-11-27</p>
12122 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
12123 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12124 <p><b>Discussion:</b></p>
12125 <p>
12126 Section 23.2.3.4 [list.ops] states that
12127 </p>
12128 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
12129 </pre>
12130 <p>
12131 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
12132 </p>
12133
12134 <p>
12135 But what does the C++ Standard mean by "invalidate"?  You
12136 can still dereference the iterator to a spliced list element, but
12137 you'd better not use it to delimit a range within the original
12138 list. For the latter operation, it has definitely lost some of its
12139 validity.
12140 </p>
12141
12142 <p>
12143 If we accept the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>,
12144 then we'd better clarify that a "valid" iterator need no
12145 longer designate an element within the same container as it once did.
12146 We then have to clarify what we mean by invalidating a past-the-end
12147 iterator, as when a vector or string grows by reallocation. Clearly,
12148 such an iterator has a different kind of validity. Perhaps we should
12149 introduce separate terms for the two kinds of "validity."
12150 </p>
12151
12152
12153 <p><b>Proposed resolution:</b></p>
12154 <p>Add the following text to the end of section 24.1 [iterator.requirements],
12155 after paragraph 5:</p>
12156 <blockquote><p>
12157 An <i>invalid</i> iterator is an iterator that may be
12158 singular. [Footnote: This definition applies to pointers, since
12159 pointers are iterators. The effect of dereferencing an iterator that
12160 has been invalidated is undefined.]
12161 </p></blockquote>
12162
12163 <p><i>[post-Copenhagen: Matt provided wording.]</i></p>
12164
12165
12166 <p><i>[Redmond: General agreement with the intent, some objections to
12167 the wording.  Dave provided new wording.]</i></p>
12168
12169
12170
12171 <p><b>Rationale:</b></p>
12172 <p>This resolution simply defines a term that the Standard uses but
12173   never defines, "invalid", in terms of a term that is defined,
12174   "singular".</p>
12175
12176 <p>Why do we say "may be singular", instead of "is singular"?  That's
12177   becuase a valid iterator is one that is known to be nonsingular.
12178   Invalidating an iterator means changing it in such a way that it's
12179   no longer known to be nonsingular.  An example: inserting an
12180   element into the middle of a vector is correctly said to invalidate
12181   all iterators pointing into the vector.  That doesn't necessarily
12182   mean they all become singular.</p>
12183
12184
12185
12186
12187
12188 <hr>
12189 <h3><a name="280"></a>280. Comparison of reverse_iterator to const reverse_iterator</h3>
12190 <p><b>Section:</b> 24.4.1 [reverse.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12191  <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-11-27</p>
12192 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12193 <p><b>Discussion:</b></p>
12194 <p>
12195 This came from an email from Steve Cleary to Fergus in reference to
12196 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
12197 this in Toronto and believed it should be a separate issue.  There was
12198 also some reservations about whether this was a worthwhile problem to
12199 fix.
12200 </p>
12201
12202 <p>
12203 Steve said: "Fixing reverse_iterator. std::reverse_iterator can
12204 (and should) be changed to preserve these additional
12205 requirements." He also said in email that it can be done without
12206 breaking user's code: "If you take a look at my suggested
12207 solution, reverse_iterator doesn't have to take two parameters; there
12208 is no danger of breaking existing code, except someone taking the
12209 address of one of the reverse_iterator global operator functions, and
12210 I have to doubt if anyone has ever done that. . .  <i>But</i>, just in
12211 case they have, you can leave the old global functions in as well --
12212 they won't interfere with the two-template-argument functions.  With
12213 that, I don't see how <i>any</i> user code could break."
12214 </p>
12215
12216
12217 <p><b>Proposed resolution:</b></p>
12218 <p>
12219 <b>Section:</b> 24.4.1.1 [reverse.iterator]
12220 add/change the following declarations:</p>
12221 <pre>  A) Add a templated assignment operator, after the same manner
12222         as the templated copy constructor, i.e.:
12223
12224   template &lt; class U &gt;
12225   reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
12226
12227   B) Make all global functions (except the operator+) have
12228   two template parameters instead of one, that is, for
12229   operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
12230
12231        template &lt; class Iterator &gt;
12232        typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
12233                  const reverse_iterator&lt; Iterator &gt;&amp; x,
12234                  const reverse_iterator&lt; Iterator &gt;&amp; y);
12235
12236   with:
12237
12238       template &lt; class Iterator1, class Iterator2 &gt;
12239       typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
12240                  const reverse_iterator &lt; Iterator1 &gt; &amp; x,
12241                  const reverse_iterator &lt; Iterator2 &gt; &amp; y);
12242 </pre>
12243 <p>
12244 Also make the addition/changes for these signatures in
12245 24.4.1.3 [reverse.iter.ops].
12246 </p>
12247
12248 <p><i>[
12249 Copenhagen: The LWG is concerned that the proposed resolution
12250 introduces new overloads.  Experience shows that introducing
12251 overloads is always risky, and that it would be inappropriate to
12252 make this change without implementation experience.  It may be
12253 desirable to provide this feature in a different way.
12254 ]</i></p>
12255
12256
12257 <p><i>[
12258 Lillehammer: We now have implementation experience, and agree that
12259 this solution is safe and correct.
12260 ]</i></p>
12261
12262
12263
12264
12265
12266
12267
12268 <hr>
12269 <h3><a name="281"></a>281. std::min() and max() requirements overly restrictive</h3>
12270 <p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12271  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-02</p>
12272 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
12273 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12274 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#486">486</a></p>
12275 <p><b>Discussion:</b></p>
12276 <p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
12277 requirements of <tt>LessThanComparable</tt> ( [lessthancomparable])
12278 and <tt>CopyConstructible</tt> (20.1.1 [utility.arg.requirements]).
12279 Since the functions take and return their arguments and result by
12280 const reference, I believe the <tt>CopyConstructible</tt> requirement
12281 is unnecessary.
12282 </p>
12283
12284
12285 <p><b>Proposed resolution:</b></p>
12286 <p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
12287 25.3.7, p1 with</p>
12288 <p><b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt>
12289 ( [lessthancomparable]).
12290 </p>
12291 <p>and replace 25.3.7, p4 with</p>
12292 <p><b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt>
12293 ( [lessthancomparable]).
12294 </p>
12295
12296
12297
12298
12299 <hr>
12300 <h3><a name="282"></a>282. What types does numpunct grouping refer to?</h3>
12301 <p><b>Section:</b> 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12302  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2000-12-05</p>
12303 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
12304 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12305 <p><b>Discussion:</b></p>
12306 <p>
12307 Paragraph 16 mistakenly singles out integral types for inserting
12308 thousands_sep() characters.  This conflicts with the syntax for floating
12309 point numbers described under 22.2.3.1/2.
12310 </p>
12311
12312
12313 <p><b>Proposed resolution:</b></p>
12314 <p>Change paragraph 16 from:</p>
12315
12316 <blockquote><p>
12317 For integral types, punct.thousands_sep() characters are inserted into
12318 the sequence as determined by the value returned by punct.do_grouping()
12319 using the method described in 22.2.3.1.2 [facet.numpunct.virtuals].
12320 </p></blockquote>
12321
12322 <p>To:</p>
12323
12324 <blockquote><p>
12325 For arithmetic types, punct.thousands_sep() characters are inserted into
12326 the sequence as determined by the value returned by punct.do_grouping()
12327 using the method described in 22.2.3.1.2 [facet.numpunct.virtuals].
12328 </p></blockquote>
12329
12330 <p><i>[
12331 Copenhagen: Opinions were divided about whether this is actually an
12332 inconsistency, but at best it seems to have been unintentional.  This
12333 is only an issue for floating-point output: The standard is
12334 unambiguous that implementations must parse thousands_sep characters
12335 when performing floating-point.  The standard is also unambiguous that
12336 this requirement does not apply to the "C" locale.
12337 ]</i></p>
12338
12339
12340 <p><i>[
12341 A survey of existing practice is needed; it is believed that some
12342 implementations do insert thousands_sep characters for floating-point
12343 output and others fail to insert thousands_sep characters for
12344 floating-point input even though this is unambiguously required by the
12345 standard.
12346 ]</i></p>
12347
12348
12349 <p><i>[Post-Curaçao: the above proposed resolution is the consensus of
12350 Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
12351
12352
12353
12354
12355
12356
12357 <hr>
12358 <h3><a name="283"></a>283. std::replace() requirement incorrect/insufficient</h3>
12359 <p><b>Section:</b> 25.2.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12360  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-15</p>
12361 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</p>
12362 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12363 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#483">483</a></p>
12364 <p><b>Discussion:</b></p>
12365 <p>
12366 (revision of the further discussion)
12367 There are a number of problems with the requires clauses for the
12368 algorithms in 25.1 and 25.2. The requires clause of each algorithm
12369 should describe the necessary and sufficient requirements on the inputs
12370 to the algorithm such that the algorithm compiles and runs properly.
12371 Many of the requires clauses fail to do this. Here is a summary of the kinds
12372 of mistakes:
12373 </p>
12374
12375 <ol>
12376 <li>
12377 Use of EqualityComparable, which only puts requirements on a single
12378 type, when in fact an equality operator is required between two
12379 different types, typically either T and the iterator's value type
12380 or between the value types of two different iterators.
12381 </li>
12382 <li>
12383 Use of Assignable for T when in fact what was needed is Assignable
12384 for the value_type of the iterator, and convertability from T to the
12385 value_type of the iterator. Or for output iterators, the requirement
12386 should be that T is writable to the iterator (output iterators do
12387 not have value types).
12388 </li>
12389 </ol>
12390
12391 <p>
12392 Here is the list of algorithms that contain mistakes:
12393 </p>
12394
12395 <ul>
12396 <li>25.1.2 std::find</li>
12397 <li>25.1.6 std::count</li>
12398 <li>25.1.8 std::equal</li>
12399 <li>25.1.9 std::search, std::search_n</li>
12400 <li>25.2.4 std::replace, std::replace_copy</li>
12401 <li>25.2.5 std::fill</li>
12402 <li>25.2.7 std::remove, std::remove_copy</li>
12403 </ul>
12404
12405 <p>
12406 Also, in the requirements for EqualityComparable, the requirement that
12407 the operator be defined for const objects is lacking.
12408 </p>
12409
12410
12411
12412 <p><b>Proposed resolution:</b></p>
12413
12414 <p>20.1.1 Change p1 from</p>
12415
12416 <p>In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
12417 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
12418 values of type <tt>T</tt>.
12419 </p>
12420
12421 <p>to</p>
12422
12423 <p>
12424 In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
12425 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
12426 values of type <tt>const T</tt>.
12427 </p>
12428
12429 <p>25 Between p8 and p9</p>
12430
12431 <p>Add the following sentence:</p>
12432
12433 <p>When the description of an algorithm gives an expression such as
12434 <tt>*first == value</tt> for a condition, it is required that the expression
12435 evaluate to either true or false in boolean contexts.</p>
12436
12437 <p>25.1.2 Change p1 by deleting the requires clause.</p>
12438
12439 <p>25.1.6 Change p1 by deleting the requires clause.</p>
12440
12441 <p>25.1.9</p>
12442
12443 <p>Change p4 from</p>
12444
12445 <p>-4- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt>
12446 (20.1.1), type Size is convertible to integral type (4.7.12.3).
12447 </p>
12448
12449 <p>to</p>
12450
12451 <p>-4- Requires: The type <tt>Size</tt> is convertible to integral
12452 type (4.7.12.3).</p>
12453
12454 <p>25.2.4 Change p1 from</p>
12455
12456 <p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1 ) (and, for <tt>replace()</tt>, <tt>EqualityComparable</tt> (20.1.1 )).</p>
12457
12458 <p>to</p>
12459
12460 <p>-1- Requires: The expression <tt>*first = new_value</tt> must be valid.</p>
12461
12462 <p>and change p4 from</p>
12463
12464 <p>-4- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1) (and,
12465 for <tt>replace_copy()</tt>, <tt>EqualityComparable</tt>
12466 (20.1.1)). The ranges <tt>[first, last)</tt> and <tt>[result, result +
12467 (last - first))</tt> shall not overlap.</p>
12468
12469 <p>to</p>
12470
12471 <p>-4- Requires: The results of the expressions <tt>*first</tt> and
12472 <tt>new_value</tt> must be writable to the result output iterator. The
12473 ranges <tt>[first, last)</tt> and <tt>[result, result + (last -
12474 first))</tt> shall not overlap.</p>
12475
12476
12477 <p>25.2.5 Change p1 from</p>
12478
12479 <p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1). The
12480 type <tt>Size</tt> is convertible to an integral type (4.7.12.3).</p>
12481
12482 <p>to</p>
12483
12484 <p>-1- Requires: The expression <tt>value</tt> must be is writable to
12485 the output iterator. The type <tt>Size</tt> is convertible to an
12486 integral type (4.7.12.3).</p>
12487
12488 <p>25.2.7 Change p1 from</p>
12489
12490 <p>-1- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> (20.1.1).</p>
12491
12492 <p>to</p>
12493
12494 <p>
12495 -1- Requires: The value type of the iterator must be
12496 <tt>Assignable</tt> (23.1).
12497 </p>
12498
12499
12500
12501 <p><b>Rationale:</b></p>
12502 <p>
12503 The general idea of the proposed solution is to remove the faulty
12504 requires clauses and let the returns and effects clauses speak for
12505 themselves. That is, the returns clauses contain expressions that must
12506 be valid, and therefore already imply the correct requirements. In
12507 addition, a sentence is added at the beginning of chapter 25 saying
12508 that expressions given as conditions must evaluate to true or false in
12509 a boolean context. An alternative would be to say that the type of
12510 these condition expressions must be literally bool, but that would be
12511 imposing a greater restriction that what the standard currently says
12512 (which is convertible to bool).
12513 </p>
12514
12515
12516
12517
12518
12519 <hr>
12520 <h3><a name="284"></a>284. unportable example in 20.3.7, p6</h3>
12521 <p><b>Section:</b> 20.5.7 [comparisons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12522  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-26</p>
12523 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12524 <p><b>Discussion:</b></p>
12525 <p>The example in 20.5.7 [comparisons], p6 shows how to use the C
12526 library function <tt>strcmp()</tt> with the function pointer adapter
12527 <tt>ptr_fun()</tt>. But since it's unspecified whether the C library
12528 functions have <tt>extern "C"</tt> or <tt>extern
12529 "C++"</tt> linkage [17.4.2.2 [using.linkage]], and since
12530 function pointers with different the language linkage specifications
12531 (7.5 [dcl.link]) are incompatible, whether this example is
12532 well-formed is unspecified.
12533 </p>
12534
12535
12536 <p><b>Proposed resolution:</b></p>
12537 <p>Change 20.5.7 [comparisons] paragraph 6 from:</p>
12538 <blockquote>
12539   <p>[<i>Example:</i></p>
12540   <pre>    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
12541   </pre>
12542   <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
12543 </blockquote>
12544
12545
12546 <p>to:</p>
12547 <blockquote>
12548   <p>[<i>Example:</i></p>
12549   <pre>    int compare(const char*, const char*);
12550     replace_if(v.begin(), v.end(),
12551                not1(bind2nd(ptr_fun(compare), "abc")), "def");
12552   </pre>
12553   <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
12554 </blockquote>
12555
12556 <p>Also, remove footnote 215 in that same paragraph.</p>
12557
12558 <p><i>[Copenhagen: Minor change in the proposed resolution.  Since this
12559 issue deals in part with C and C++ linkage, it was believed to be too
12560 confusing for the strings in the example to be "C" and "C++".
12561 ]</i></p>
12562
12563
12564 <p><i>[Redmond: More minor changes.  Got rid of the footnote (which
12565 seems to make a sweeping normative requirement, even though footnotes
12566 aren't normative), and changed the sentence after the footnote so that
12567 it corresponds to the new code fragment.]</i></p>
12568
12569
12570
12571
12572
12573
12574 <hr>
12575 <h3><a name="285"></a>285. minor editorial errors in fstream ctors</h3>
12576 <p><b>Section:</b> 27.8.1.7 [ifstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12577  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-31</p>
12578 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12579 <p><b>Discussion:</b></p>
12580 <p>27.8.1.7 [ifstream.cons], p2, 27.8.1.11 [ofstream.cons], p2, and
12581 27.8.1.15 [fstream.cons], p2 say about the effects of each constructor:
12582 </p>
12583
12584 <p>... If that function returns a null pointer, calls
12585 <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
12586 </p>
12587
12588 <p>The parenthetical note doesn't apply since the ctors cannot throw an
12589 exception due to the requirement in 27.4.4.1 [basic.ios.cons], p3
12590 that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
12591 </p>
12592
12593
12594 <p><b>Proposed resolution:</b></p>
12595 <p>
12596 Strike the parenthetical note from the Effects clause in each of the
12597 paragraphs mentioned above.
12598 </p>
12599
12600
12601
12602
12603 <hr>
12604 <h3><a name="286"></a>286. &lt;cstdlib&gt; requirements missing size_t typedef</h3>
12605 <p><b>Section:</b> 25.4 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12606  <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
12607 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.c.library">issues</a> in [alg.c.library].</p>
12608 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12609 <p><b>Discussion:</b></p>
12610 <p>
12611 The &lt;cstdlib&gt; header file contains prototypes for bsearch and
12612 qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
12613 prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
12614 require the typedef size_t. Yet size_t is not listed in the
12615 &lt;cstdlib&gt; synopsis table 78 in section 25.4.
12616 </p>
12617
12618
12619 <p><b>Proposed resolution:</b></p>
12620 <p>
12621 Add the type size_t to Table 78 (section 25.4) and add
12622 the type size_t &lt;cstdlib&gt; to Table 97 (section C.2).
12623 </p>
12624
12625
12626 <p><b>Rationale:</b></p>
12627 <p>Since size_t is in &lt;stdlib.h&gt;, it must also be in &lt;cstdlib&gt;.</p>
12628
12629
12630
12631
12632
12633 <hr>
12634 <h3><a name="288"></a>288. &lt;cerrno&gt; requirements missing macro EILSEQ</h3>
12635 <p><b>Section:</b> 19.3 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12636  <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
12637 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12638 <p><b>Discussion:</b></p>
12639 <p>
12640 ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
12641 of macros defined in &lt;errno.h&gt; is adjusted to include a new
12642 macro, EILSEQ"
12643 </p>
12644
12645 <p>
12646 ISO/IEC 14882:1998(E) section 19.3 does not refer
12647 to the above amendment.
12648 </p>
12649
12650
12651
12652 <p><b>Proposed resolution:</b></p>
12653 <p>
12654 Update Table 26 (section 19.3) "Header  &lt;cerrno&gt; synopsis"
12655 and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
12656 </p>
12657
12658
12659
12660
12661
12662 <hr>
12663 <h3><a name="291"></a>291. Underspecification of set algorithms</h3>
12664 <p><b>Section:</b> 25.3.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12665  <b>Submitter:</b> Matt Austern <b>Date:</b> 2001-01-03</p>
12666 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.set.operations">issues</a> in [alg.set.operations].</p>
12667 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12668 <p><b>Discussion:</b></p>
12669 <p>
12670 The standard library contains four algorithms that compute set
12671 operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
12672 <tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>.  Each
12673 of these algorithms takes two sorted ranges as inputs, and writes the
12674 output of the appropriate set operation to an output range.  The elements
12675 in the output range are sorted.
12676 </p>
12677
12678 <p>
12679 The ordinary mathematical definitions are generalized so that they
12680 apply to ranges containing multiple copies of a given element.  Two
12681 elements are considered to be "the same" if, according to an
12682 ordering relation provided by the user, neither one is less than the
12683 other.  So, for example, if one input range contains five copies of an
12684 element and another contains three, the output range of <tt>set_union</tt>
12685 will contain five copies, the output range of
12686 <tt>set_intersection</tt> will contain three, the output range of
12687 <tt>set_difference</tt> will contain two, and the output range of
12688 <tt>set_symmetric_difference</tt> will contain two.
12689 </p>
12690
12691 <p>
12692 Because two elements can be "the same" for the purposes
12693 of these set algorithms, without being identical in other respects
12694 (consider, for example, strings under case-insensitive comparison),
12695 this raises a number of unanswered questions:
12696 </p>
12697
12698 <ul>
12699 <li>If we're copying an element that's present in both of the
12700 input ranges, which one do we copy it from?</li>
12701 <li>If there are <i>n</i> copies of an element in the relevant
12702 input range, and the output range will contain fewer copies (say
12703 <i>m</i>) which ones do we choose?  The first <i>m</i>, or the last
12704 <i>m</i>, or something else?</li>
12705 <li>Are these operations stable?  That is, does a run of equivalent
12706 elements appear in the output range in the same order as as it
12707 appeared in the input range(s)?</li>
12708 </ul>
12709
12710 <p>
12711 The standard should either answer these questions, or explicitly
12712 say that the answers are unspecified.  I prefer the former option,
12713 since, as far as I know, all existing implementations behave the
12714 same way.
12715 </p>
12716
12717
12718
12719 <p><b>Proposed resolution:</b></p>
12720
12721 <p>Add the following to the end of 25.3.5.2 [set.union] paragraph 5:</p>
12722 <blockquote><p>
12723 If [first1, last1) contains <i>m</i> elements that are equivalent to
12724 each other and [first2, last2) contains <i>n</i> elements that are
12725 equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
12726 will be copied to the output range: all <i>m</i> of these elements
12727 from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
12728 [first2, last2), in that order.
12729 </p></blockquote>
12730
12731 <p>Add the following to the end of 25.3.5.3 [set.intersection] paragraph 5:</p>
12732 <blockquote><p>
12733 If [first1, last1) contains <i>m</i> elements that are equivalent to each
12734 other and [first2, last2) contains <i>n</i> elements that are
12735 equivalent to them, the first min(<i>m</i>, <i>n</i>) of those
12736 elements from [first1, last1) are copied to the output range.
12737 </p></blockquote>
12738
12739 <p>Add a new paragraph, <b>Notes</b>, after 25.3.5.4 [set.difference]
12740 paragraph 4:</p>
12741 <blockquote><p>
12742 If [first1, last1) contains <i>m</i> elements that are equivalent to each
12743 other and [first2, last2) contains <i>n</i> elements that are
12744 equivalent to them, the last max(<i>m-n</i>, 0) elements from
12745 [first1, last1) are copied to the output range.
12746 </p></blockquote>
12747
12748 <p>Add a new paragraph, <b>Notes</b>, after 25.3.5.5 [set.symmetric.difference]
12749 paragraph 4:</p>
12750 <blockquote><p>
12751 If [first1, last1) contains <i>m</i> elements that are equivalent to
12752 each other and [first2, last2) contains <i>n</i> elements that are
12753 equivalent to them, then |<i>m - n</i>| of those elements will be
12754 copied to the output range: the last <i>m - n</i> of these elements
12755 from [first1, last1) if <i>m</i> &gt; <i>n</i>, and the last <i>n -
12756 m</i> of these elements from [first2, last2) if <i>m</i> &lt; <i>n</i>.
12757 </p></blockquote>
12758
12759 <p><i>[Santa Cruz: it's believed that this language is clearer than
12760   what's in the Standard.  However, it's also believed that the
12761   Standard may already make these guarantees (although not quite in
12762   these words).  Bill and Howard will check and see whether they think
12763   that some or all of these changes may be redundant.  If so, we may
12764   close this issue as NAD.]</i></p>
12765
12766
12767
12768
12769 <p><b>Rationale:</b></p>
12770 <p>For simple cases, these descriptions are equivalent to what's
12771   already in the Standard.  For more complicated cases, they describe
12772   the behavior of existing implementations.</p>
12773
12774
12775
12776
12777
12778 <hr>
12779 <h3><a name="292"></a>292. effects of a.copyfmt (a)</h3>
12780 <p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12781  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-05</p>
12782 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
12783 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12784 <p><b>Discussion:</b></p>
12785 <p>The Effects clause of the member function <tt>copyfmt()</tt> in
12786 27.4.4.2, p15 doesn't consider the case where the left-hand side
12787 argument is identical to the argument on the right-hand side, that is
12788 <tt>(this == &amp;rhs)</tt>.  If the two arguments are identical there
12789 is no need to copy any of the data members or call any callbacks
12790 registered with <tt>register_callback()</tt>.  Also, as Howard Hinnant
12791 points out in message c++std-lib-8149 it appears to be incorrect to
12792 allow the object to fire <tt>erase_event</tt> followed by
12793 <tt>copyfmt_event</tt> since the callback handling the latter event
12794 may inadvertently attempt to access memory freed by the former.
12795 </p>
12796
12797
12798 <p><b>Proposed resolution:</b></p>
12799 <p>Change the Effects clause in 27.4.4.2, p15 from</p>
12800
12801 <blockquote><p>
12802 <b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
12803 the corresponding member objects of <tt>rhs</tt>, except that...
12804 </p></blockquote>
12805
12806 <p>to</p>
12807
12808 <blockquote><p>
12809 <b>-15- Effects:</b>If <tt>(this == &amp;rhs)</tt> does nothing. Otherwise
12810 assigns to the member objects of <tt>*this</tt> the corresponding member
12811 objects of <tt>rhs</tt>, except that...
12812 </p></blockquote>
12813
12814
12815
12816
12817 <hr>
12818 <h3><a name="294"></a>294. User defined macros and standard headers</h3>
12819 <p><b>Section:</b> 17.4.3.1.1 [macro.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12820  <b>Submitter:</b> James Kanze <b>Date:</b> 2001-01-11</p>
12821 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12822 <p><b>Discussion:</b></p>
12823 <p>Paragraph 2 of 17.4.3.1.1 [macro.names] reads: "A
12824 translation unit that includes a header shall not contain any macros
12825 that define names declared in that header." As I read this, it
12826 would mean that the following program is legal:</p>
12827
12828 <pre>  #define npos 3.14
12829   #include &lt;sstream&gt;
12830 </pre>
12831
12832 <p>since npos is not defined in &lt;sstream&gt;.  It is, however, defined
12833 in &lt;string&gt;, and it is hard to imagine an implementation in
12834 which &lt;sstream&gt; didn't include &lt;string&gt;.</p>
12835
12836 <p>I think that this phrase was probably formulated before it was
12837 decided that a standard header may freely include other standard
12838 headers.  The phrase would be perfectly appropriate for C, for
12839 example.  In light of 17.4.4.1 [res.on.headers] paragraph 1, however,
12840 it isn't stringent enough.</p>
12841
12842
12843 <p><b>Proposed resolution:</b></p>
12844 <p>For 17.4.3.1.1 [macro.names], replace the current wording, which reads:</p>
12845 <blockquote>
12846      <p>Each name defined as a macro in a header is reserved to the
12847      implementation for any use if the translation unit includes
12848      the header.168)</p>
12849
12850      <p>A translation unit that includes a header shall not contain any
12851      macros that define names declared or defined in that header. Nor shall
12852      such a translation unit define macros for names lexically
12853      identical to keywords.</p>
12854
12855      <p>168) It is not permissible to remove a library macro definition by
12856      using the #undef directive.</p>
12857 </blockquote>
12858
12859 <p>with the wording:</p>
12860
12861 <blockquote>
12862      <p>A translation unit that includes a standard library header shall not
12863      #define or #undef names declared in any standard library header.</p>
12864
12865      <p>A translation unit shall not #define or #undef names lexically
12866      identical to keywords.</p>
12867 </blockquote>
12868
12869 <p><i>[Lillehammer: Beman provided new wording]</i></p>
12870
12871
12872
12873
12874
12875
12876 <hr>
12877 <h3><a name="295"></a>295. Is abs defined in &lt;cmath&gt;?</h3>
12878 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12879  <b>Submitter:</b> Jens Maurer <b>Date:</b> 2001-01-12</p>
12880 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
12881 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
12882 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12883 <p><b>Discussion:</b></p>
12884 <p>
12885 Table 80 lists the contents of the &lt;cmath&gt; header.  It does not
12886 list <tt>abs()</tt>.  However, 26.5, paragraph 6, which lists added
12887 signatures present in &lt;cmath&gt;, does say that several overloads
12888 of <tt>abs()</tt> should be defined in &lt;cmath&gt;.
12889 </p>
12890
12891
12892 <p><b>Proposed resolution:</b></p>
12893 <p>
12894 Add <tt>abs</tt> to Table 80.  Also, remove the parenthetical list
12895 of functions "(abs(), div(), rand(), srand())" from 26.5 [numarray],
12896 paragraph 1.
12897 </p>
12898
12899 <p><i>[Copenhagen: Modified proposed resolution so that it also gets
12900 rid of that vestigial list of functions in paragraph 1.]</i></p>
12901
12902
12903
12904
12905 <p><b>Rationale:</b></p>
12906 <p>All this DR does is fix a typo; it's uncontroversial.  A
12907 separate question is whether we're doing the right thing in
12908 putting some overloads in &lt;cmath&gt; that we aren't also
12909 putting in &lt;cstdlib&gt;.  That's issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</p>
12910
12911
12912
12913
12914
12915 <hr>
12916 <h3><a name="297"></a>297. const_mem_fun_t&lt;&gt;::argument_type should be const T*</h3>
12917 <p><b>Section:</b> 20.5.8 [logical.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12918  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-06</p>
12919 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12920 <p><b>Discussion:</b></p>
12921 <p>The class templates <tt>const_mem_fun_t</tt> in 20.5.8, p8 and
12922 <tt>const_mem_fun1_t</tt>
12923 in 20.5.8, p9 derive from <tt>unary_function&lt;T*, S&gt;</tt>, and
12924 <tt>binary_function&lt;T*,
12925 A, S&gt;</tt>, respectively. Consequently, their <tt>argument_type</tt>, and
12926 <tt>first_argument_type</tt>
12927 members, respectively, are both defined to be <tt>T*</tt> (non-const).
12928 However, their function call member operator takes a <tt>const T*</tt>
12929 argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
12930 T*</tt> instead, so that one can easily refer to it in generic code. The
12931 example below derived from existing code fails to compile due to the
12932 discrepancy:
12933 </p>
12934
12935 <p><tt>template &lt;class T&gt;</tt>
12936 <br><tt>void foo (typename T::argument_type arg)&nbsp;&nbsp; // #1</tt>
12937 <br><tt>{</tt>
12938 <br><tt>&nbsp;&nbsp;&nbsp; typename T::result_type (T::*pf) (typename
12939 T::argument_type)
12940 const =&nbsp;&nbsp; // #2</tt>
12941 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;T::operator();</tt>
12942 <br><tt>}</tt>
12943 </p>
12944
12945 <p><tt>struct X { /* ... */ };</tt></p>
12946
12947 <p><tt>int main ()</tt>
12948 <br><tt>{</tt>
12949 <br><tt>&nbsp;&nbsp;&nbsp; const X x;</tt>
12950 <br><tt>&nbsp;&nbsp;&nbsp; foo&lt;std::const_mem_fun_t&lt;void, X&gt;
12951 &gt;(&amp;x);&nbsp;&nbsp;
12952 // #3</tt>
12953 <br><tt>}</tt>
12954 </p>
12955
12956 <p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
12957 <br>#2 the type of the pointer is incompatible with the type of the member
12958 function
12959 <br>#3 the address of a constant being passed to a function taking a non-const
12960 <tt>X*</tt>
12961 </p>
12962
12963
12964 <p><b>Proposed resolution:</b></p>
12965 <p>Replace the top portion of the definition of the class template
12966 const_mem_fun_t in 20.5.8, p8
12967 </p>
12968 <p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
12969 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
12970 unary_function&lt;T*, S&gt; {</tt>
12971 </p>
12972 <p>with</p>
12973 <p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
12974 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
12975 unary_function&lt;<b>const</b> T*, S&gt; {</tt>
12976 </p>
12977 <p>Also replace the top portion of the definition of the class template
12978 const_mem_fun1_t in 20.5.8, p9</p>
12979 <p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
12980 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
12981 binary_function&lt;T*, A, S&gt; {</tt>
12982 </p>
12983 <p>with</p>
12984 <p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
12985 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
12986 binary_function&lt;<b>const</b> T*, A, S&gt; {</tt>
12987 </p>
12988
12989
12990 <p><b>Rationale:</b></p>
12991 <p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
12992 and the argument type itself, are not the same.</p>
12993
12994
12995
12996
12997
12998 <hr>
12999 <h3><a name="298"></a>298. ::operator delete[] requirement incorrect/insufficient</h3>
13000 <p><b>Section:</b> 18.5.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13001  <b>Submitter:</b> John A. Pedretti <b>Date:</b> 2001-01-10</p>
13002 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13003 <p><b>Discussion:</b></p>
13004 <p>
13005 The default behavior of <tt>operator delete[]</tt> described in 18.5.1.2, p12 -
13006 namely that for non-null value of <i>ptr</i>, the operator reclaims storage
13007 allocated by the earlier call to the default <tt>operator new[]</tt> - is not
13008 correct in all cases. Since the specified <tt>operator new[]</tt> default
13009 behavior is to call <tt>operator new</tt> (18.5.1.2, p4, p8), which can be
13010 replaced, along with <tt>operator delete</tt>, by the user, to implement their
13011 own memory management, the specified default behavior of<tt> operator
13012 delete[]</tt> must be to call <tt>operator delete</tt>.
13013 </p>
13014
13015
13016 <p><b>Proposed resolution:</b></p>
13017 <p>Change 18.5.1.2, p12 from</p>
13018 <blockquote><p>
13019 <b>-12-</b> <b>Default behavior:</b></p>
13020 <ul>
13021 <li>
13022 For a null value of <i><tt>ptr</tt></i> , does nothing.
13023 </li>
13024 <li>
13025 Any other value of <i><tt>ptr</tt></i> shall be a value returned
13026 earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
13027 [Footnote: The value must not have been invalidated by an intervening
13028 call to <tt>operator delete[](void*)</tt> (17.4.3.7 [res.on.arguments]).
13029 --- end footnote]
13030 For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
13031 allocated by the earlier call to the default <tt>operator new[]</tt>.
13032 </li>
13033 </ul>
13034 </blockquote>
13035
13036 <p>to</p>
13037
13038 <blockquote><p>
13039 <b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
13040 delete(</tt><i>ptr</i>)
13041 or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
13042 </p></blockquote>
13043 <p>and expunge paragraph 13.</p>
13044
13045
13046
13047
13048 <hr>
13049 <h3><a name="300"></a>300. list::merge() specification incomplete</h3>
13050 <p><b>Section:</b> 23.2.3.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13051  <b>Submitter:</b> John Pedretti <b>Date:</b> 2001-01-23</p>
13052 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
13053 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13054 <p><b>Discussion:</b></p>
13055 <p>
13056 The "Effects" clause for list::merge() (23.2.3.4 [list.ops], p23)
13057 appears to be incomplete: it doesn't cover the case where the argument
13058 list is identical to *this (i.e., this == &amp;x). The requirement in the
13059 note in p24 (below) is that x be empty after the merge which is surely
13060 unintended in this case.
13061 </p>
13062
13063
13064 <p><b>Proposed resolution:</b></p>
13065 <p>In 23.2.3.4 [list.ops], replace paragraps 23-25 with:</p>
13066 <blockquote>
13067 <p>
13068 23 Effects: if (&amp;x == this) does nothing; otherwise, merges the two
13069 sorted ranges [begin(), end()) and [x.begin(), x.end()).  The result
13070 is a range in which the elements will be sorted in non-decreasing
13071 order according to the ordering defined by comp; that is, for every
13072 iterator i in the range other than the first, the condition comp(*i,
13073 *(i - 1)) will be false.
13074 </p>
13075
13076 <p>
13077 24 Notes: Stable: if (&amp;x != this), then for equivalent elements in the
13078 two original ranges, the elements from the original range [begin(),
13079 end()) always precede the elements from the original range [x.begin(),
13080 x.end()).  If (&amp;x != this) the range [x.begin(), x.end()) is empty
13081 after the merge.
13082 </p>
13083
13084 <p>
13085 25 Complexity: At most size() + x.size() - 1 applications of comp if
13086 (&amp;x !  = this); otherwise, no applications of comp are performed.  If
13087 an exception is thrown other than by a comparison there are no
13088 effects.
13089 </p>
13090
13091 </blockquote>
13092
13093 <p><i>[Copenhagen: The original proposed resolution did not fix all of
13094 the problems in 23.2.3.4 [list.ops], p22-25.  Three different
13095 paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
13096 Changing p23, without changing the other two, appears to introduce
13097 contradictions.  Additionally, "merges the argument list into the
13098 list" is excessively vague.]</i></p>
13099
13100
13101 <p><i>[Post-Curaçao: Robert Klarer provided new wording.]</i></p>
13102
13103
13104
13105
13106
13107
13108
13109 <hr>
13110 <h3><a name="301"></a>301. basic_string template ctor effects clause omits allocator argument</h3>
13111 <p><b>Section:</b> 21.3.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13112  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-27</p>
13113 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
13114 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13115 <p><b>Discussion:</b></p>
13116 <p>
13117 The effects clause for the basic_string template ctor in 21.3.1, p15
13118 leaves out the third argument of type Allocator. I believe this to be
13119 a mistake.
13120 </p>
13121
13122
13123 <p><b>Proposed resolution:</b></p>
13124 <p>Replace</p>
13125
13126 <blockquote>
13127     <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
13128     type, equivalent to</p>
13129
13130     <blockquote><p><tt>basic_string(static_cast&lt;size_type&gt;(begin),
13131     static_cast&lt;value_type&gt;(end))</tt></p></blockquote>
13132 </blockquote>
13133
13134 <p>with</p>
13135
13136 <blockquote>
13137     <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
13138     type, equivalent to</p>
13139
13140     <blockquote><p><tt>basic_string(static_cast&lt;size_type&gt;(begin),
13141     static_cast&lt;value_type&gt;(end), <b>a</b>)</tt></p></blockquote>
13142 </blockquote>
13143
13144
13145
13146
13147 <hr>
13148 <h3><a name="303"></a>303. Bitset input operator underspecified</h3>
13149 <p><b>Section:</b> 23.3.5.3 [bitset.operators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13150  <b>Submitter:</b> Matt Austern <b>Date:</b> 2001-02-05</p>
13151 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13152 <p><b>Discussion:</b></p>
13153 <p>
13154 In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
13155 "Extracts up to <i>N</i> (single-byte) characters from
13156 <i>is</i>.", where <i>is</i> is a stream of type
13157 <tt>basic_istream&lt;charT, traits&gt;</tt>.
13158 </p>
13159
13160 <p>
13161 The standard does not say what it means to extract single byte
13162 characters from a stream whose character type, <tt>charT</tt>, is in
13163 general not a single-byte character type.  Existing implementations
13164 differ.
13165 </p>
13166
13167 <p>
13168 A reasonable solution will probably involve <tt>widen()</tt> and/or
13169 <tt>narrow()</tt>, since they are the supplied mechanism for
13170 converting a single character between <tt>char</tt> and
13171 arbitrary <tt>charT</tt>.
13172 </p>
13173
13174 <p>Narrowing the input characters is not the same as widening the
13175 literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
13176 locales in which more than one wide character maps to the narrow
13177 character <tt>'0'</tt>.  Narrowing means that alternate
13178 representations may be used for bitset input, widening means that
13179 they may not be.</p>
13180
13181 <p>Note that for numeric input, <tt>num_get&lt;&gt;</tt>
13182 (22.2.2.1.2/8) compares input characters to widened version of narrow
13183 character literals.</p>
13184
13185 <p>From Pete Becker, in c++std-lib-8224:</p>
13186 <blockquote>
13187 <p>
13188 Different writing systems can have different representations for the
13189 digits that represent 0 and 1. For example, in the Unicode representation
13190 of the Devanagari script (used in many of the Indic languages) the digit 0
13191 is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
13192 into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
13193 0x0031 for for the Latin representations of '0' and '1', as well as code
13194 points for the same numeric values in several other scripts (Tamil has no
13195 character for 0, but does have the digits 1-9), and any of these values
13196 would also be narrowed to '0' and '1'.
13197 </p>
13198
13199 <p>...</p>
13200
13201 <p>
13202 It's fairly common to intermix both native and Latin
13203 representations of numbers in a document. So I think the rule has to be
13204 that if a wide character represents a digit whose value is 0 then the bit
13205 should be cleared; if it represents a digit whose value is 1 then the bit
13206 should be set; otherwise throw an exception. So in a Devanagari locale,
13207 both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
13208 would set it. Widen can't do that. It would pick one of those two values,
13209 and exclude the other one.
13210 </p>
13211
13212 </blockquote>
13213
13214 <p>From Jens Maurer, in c++std-lib-8233:</p>
13215
13216 <blockquote>
13217 <p>
13218 Whatever we decide, I would find it most surprising if
13219 bitset conversion worked differently from int conversion
13220 with regard to alternate local representations of
13221 numbers.
13222 </p>
13223
13224 <p>Thus, I think the options are:</p>
13225 <ul>
13226  <li> Have a new defect issue for 22.2.2.1.2/8 so that it will
13227 require the use of narrow().</li>
13228
13229  <li> Have a defect issue for bitset() which describes clearly
13230 that widen() is to be used.</li>
13231 </ul>
13232 </blockquote>
13233
13234
13235
13236 <p><b>Proposed resolution:</b></p>
13237
13238     <p>Replace the first two sentences of paragraph 5 with:</p>
13239
13240     <blockquote><p>
13241     Extracts up to <i>N</i> characters from <i>is</i>. Stores these
13242     characters in a temporary object <i>str</i> of type
13243     <tt>basic_string&lt;charT, traits&gt;</tt>, then evaluates the
13244     expression <tt><i>x</i> = bitset&lt;N&gt;(<i>str</i>)</tt>.
13245     </p></blockquote>
13246
13247     <p>Replace the third bullet item in paragraph 5 with:</p>
13248     <ul><li>
13249     the next input character is neither <tt><i>is</i>.widen(0)</tt>
13250     nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
13251     is not extracted).
13252     </li></ul>
13253
13254
13255
13256 <p><b>Rationale:</b></p>
13257 <p>Input for <tt>bitset</tt> should work the same way as numeric
13258 input.  Using <tt>widen</tt> does mean that alternative digit
13259 representations will not be recognized, but this was a known
13260 consequence of the design choice.</p>
13261
13262
13263
13264
13265
13266 <hr>
13267 <h3><a name="305"></a>305. Default behavior of codecvt&lt;wchar_t, char, mbstate_t&gt;::length()</h3>
13268 <p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13269  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-01-24</p>
13270 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
13271 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13272 <p><b>Discussion:</b></p>
13273 <p>22.2.1.5/3 introduces codecvt in part with:</p>
13274
13275 <blockquote><p>
13276   codecvt&lt;wchar_t,char,mbstate_t&gt; converts between the native
13277   character sets for tiny and wide characters. Instantiations on
13278   mbstate_t perform conversion between encodings known to the library
13279   implementor.
13280 </p></blockquote>
13281
13282 <p>But 22.2.1.5.2/10 describes do_length in part with:</p>
13283
13284 <blockquote><p>
13285   ... codecvt&lt;wchar_t, char, mbstate_t&gt; ... return(s) the lesser of max and
13286   (from_end-from).
13287 </p></blockquote>
13288
13289 <p>
13290 The semantics of do_in and do_length are linked.  What one does must
13291 be consistent with what the other does.  22.2.1.5/3 leads me to
13292 believe that the vendor is allowed to choose the algorithm that
13293 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in performs so that it makes
13294 his customers happy on a given platform.  But 22.2.1.5.2/10 explicitly
13295 says what codecvt&lt;wchar_t,char,mbstate_t&gt;::do_length must
13296 return.  And thus indirectly specifies the algorithm that
13297 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in must perform.  I believe
13298 that this is not what was intended and is a defect.
13299 </p>
13300
13301 <p>Discussion from the -lib reflector:
13302
13303 <br>This proposal would have the effect of making the semantics of
13304 all of the virtual functions in <tt>codecvt&lt;wchar_t, char,
13305 mbstate_t&gt;</tt> implementation specified.  Is that what we want, or
13306 do we want to mandate specific behavior for the base class virtuals
13307 and leave the implementation specified behavior for the codecvt_byname
13308 derived class?  The tradeoff is that former allows implementors to
13309 write a base class that actually does something useful, while the
13310 latter gives users a way to get known and specified---albeit
13311 useless---behavior, and is consistent with the way the standard
13312 handles other facets.  It is not clear what the original intention
13313 was.</p>
13314
13315 <p>
13316 Nathan has suggest a compromise: a character that is a widened version
13317 of the characters in the basic execution character set must be
13318 converted to a one-byte sequence, but there is no such requirement
13319 for characters that are not part of the basic execution character set.
13320 </p>
13321
13322
13323 <p><b>Proposed resolution:</b></p>
13324 <p>
13325 Change 22.2.1.5.2/5 from:
13326 </p>
13327 <p>
13328 The instantiations required in Table 51 (lib.locale.category), namely
13329 codecvt&lt;wchar_t,char,mbstate_t&gt; and
13330 codecvt&lt;char,char,mbstate_t&gt;, store no characters. Stores no more
13331 than (to_limit-to) destination elements. It always leaves the to_next
13332 pointer pointing one beyond the last element successfully stored.
13333 </p>
13334 <p>
13335 to:
13336 </p>
13337 <p>
13338 Stores no more than (to_limit-to) destination elements, and leaves the
13339 to_next pointer pointing one beyond the last element successfully
13340 stored.  codecvt&lt;char,char,mbstate_t&gt; stores no characters.
13341 </p>
13342
13343 <p>Change 22.2.1.5.2/10 from:</p>
13344
13345 <blockquote><p>
13346 -10- Returns: (from_next-from) where from_next is the largest value in
13347 the range [from,from_end] such that the sequence of values in the
13348 range [from,from_next) represents max or fewer valid complete
13349 characters of type internT. The instantiations required in Table 51
13350 (21.1.1.1.1), namely codecvt&lt;wchar_t, char, mbstate_t&gt; and
13351 codecvt&lt;char, char, mbstate_t&gt;, return the lesser of max and
13352 (from_end-from).
13353 </p></blockquote>
13354
13355 <p>to:</p>
13356
13357 <blockquote><p>
13358 -10- Returns: (from_next-from) where from_next is the largest value in
13359 the range [from,from_end] such that the sequence of values in the range
13360 [from,from_next) represents max or fewer valid complete characters of
13361 type internT. The instantiation codecvt&lt;char, char, mbstate_t&gt; returns
13362 the lesser of max and (from_end-from).
13363 </p></blockquote>
13364
13365 <p><i>[Redmond: Nathan suggested an alternative resolution: same as
13366 above, but require that, in the default encoding, a character from the
13367 basic execution character set would map to a single external
13368 character.  The straw poll was 8-1 in favor of the proposed
13369 resolution.]</i></p>
13370
13371
13372
13373
13374 <p><b>Rationale:</b></p>
13375 <p>The default encoding should be whatever users of a given platform
13376 would expect to be the most natural.  This varies from platform to
13377 platform.  In many cases there is a preexisting C library, and users
13378 would expect the default encoding to be whatever C uses in the default
13379 "C" locale.  We could impose a guarantee like the one Nathan suggested
13380 (a character from the basic execution character set must map to a
13381 single external character), but this would rule out important
13382 encodings that are in common use: it would rule out JIS, for
13383 example, and it would rule out a fixed-width encoding of UCS-4.</p>
13384
13385 <p><i>[Curaçao: fixed rationale typo at the request of Ichiro Koshida;
13386 "shift-JIS" changed to "JIS".]</i></p>
13387
13388
13389
13390
13391
13392
13393
13394 <hr>
13395 <h3><a name="306"></a>306. offsetof macro and non-POD types</h3>
13396 <p><b>Section:</b> 18.1 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13397  <b>Submitter:</b> Steve Clamage <b>Date:</b> 2001-02-21</p>
13398 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p>
13399 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13400 <p><b>Discussion:</b></p>
13401 <p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
13402
13403 <p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
13404 accepts a restricted set of <i>type</i> arguments in this
13405 International Standard. <i>type</i> shall be a POD structure or a POD
13406 union (clause 9). The result of applying the offsetof macro to a field
13407 that is a static data member or a function member is
13408 undefined."</p>
13409
13410 <p>For the POD requirement, it doesn't say "no diagnostic
13411 required" or "undefined behavior". I read 1.4 [intro.compliance], paragraph 1, to mean that a diagnostic is required.
13412 It's not clear whether this requirement was intended.  While it's
13413 possible to provide such a diagnostic, the extra complication doesn't
13414 seem to add any value.
13415 </p>
13416
13417
13418 <p><b>Proposed resolution:</b></p>
13419 <p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
13420 structure or a POD union the results are undefined."</p>
13421
13422 <p><i>[Copenhagen: straw poll was 7-4 in favor.  It was generally
13423 agreed that requiring a diagnostic was inadvertent, but some LWG
13424 members thought that diagnostics should be required whenever
13425 possible.]</i></p>
13426
13427
13428
13429
13430
13431
13432 <hr>
13433 <h3><a name="307"></a>307. Lack of reference typedefs in container adaptors</h3>
13434 <p><b>Section:</b> 23.2.3 [list] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13435  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-03-13</p>
13436 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13437 <p><b>Discussion:</b></p>
13438
13439 <p>From reflector message c++std-lib-8330.  See also lib-8317.</p>
13440
13441 <p>
13442 The standard is currently inconsistent in 23.2.3.2 [list.capacity]
13443 paragraph 1 and 23.2.3.3 [list.modifiers] paragraph 1.
13444 23.2.3.3/1, for example, says:
13445 </p>
13446
13447 <blockquote><p>
13448 -1- Any sequence supporting operations back(), push_back() and pop_back()
13449 can be used to instantiate stack. In particular, vector (lib.vector), list
13450 (lib.list) and deque (lib.deque) can be used.
13451 </p></blockquote>
13452
13453 <p>But this is false: vector&lt;bool&gt; can not be used, because the
13454 container adaptors return a T&amp; rather than using the underlying
13455 container's reference type.</p>
13456
13457 <p>This is a contradiction that can be fixed by:</p>
13458
13459 <ol>
13460 <li>Modifying these paragraphs to say that vector&lt;bool&gt;
13461     is an exception.</li>
13462 <li>Removing the vector&lt;bool&gt; specialization.</li>
13463 <li>Changing the return types of stack and priority_queue to use
13464     reference typedef's.</li>
13465 </ol>
13466
13467 <p>
13468 I propose 3.  This does not preclude option 2 if we choose to do it
13469 later (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>); the issues are independent.  Option
13470 3 offers a small step towards support for proxied containers.  This
13471 small step fixes a current contradiction, is easy for vendors to
13472 implement, is already implemented in at least one popular lib, and
13473 does not break any code.
13474 </p>
13475
13476
13477
13478 <p><b>Proposed resolution:</b></p>
13479 <p>Summary: Add reference and const_reference typedefs to queue,
13480 priority_queue and stack.  Change return types of "value_type&amp;" to
13481 "reference".  Change return types of "const value_type&amp;" to
13482 "const_reference".  Details:</p>
13483
13484 <p>Change 23.2.3.1/1 from:</p>
13485
13486 <pre>  namespace std {
13487     template &lt;class T, class Container = deque&lt;T&gt; &gt;
13488     class queue {
13489     public:
13490       typedef typename Container::value_type            value_type;
13491       typedef typename Container::size_type             size_type;
13492       typedef          Container                        container_type;
13493     protected:
13494       Container c;
13495
13496     public:
13497       explicit queue(const Container&amp; = Container());
13498
13499       bool      empty() const             { return c.empty(); }
13500       size_type size()  const             { return c.size(); }
13501       value_type&amp;       front()           { return c.front(); }
13502       const value_type&amp; front() const     { return c.front(); }
13503       value_type&amp;       back()            { return c.back(); }
13504       const value_type&amp; back() const      { return c.back(); }
13505       void push(const value_type&amp; x)      { c.push_back(x); }
13506       void pop()                          { c.pop_front(); }
13507     };
13508 </pre>
13509
13510 <p>to:</p>
13511
13512 <pre>  namespace std {
13513     template &lt;class T, class Container = deque&lt;T&gt; &gt;
13514     class queue {
13515     public:
13516       typedef typename Container::value_type            value_type;
13517       typedef typename Container::reference             reference;
13518       typedef typename Container::const_reference       const_reference;
13519       typedef typename Container::value_type            value_type;
13520       typedef typename Container::size_type             size_type;
13521       typedef          Container                        container_type;
13522     protected:
13523       Container c;
13524
13525     public:
13526       explicit queue(const Container&amp; = Container());
13527
13528       bool      empty() const             { return c.empty(); }
13529       size_type size()  const             { return c.size(); }
13530       reference         front()           { return c.front(); }
13531       const_reference   front() const     { return c.front(); }
13532       reference         back()            { return c.back(); }
13533       const_reference   back() const      { return c.back(); }
13534       void push(const value_type&amp; x)      { c.push_back(x); }
13535       void pop()                          { c.pop_front(); }
13536     };
13537 </pre>
13538
13539 <p>Change 23.2.3.2/1 from:</p>
13540
13541 <pre>  namespace std {
13542     template &lt;class T, class Container = vector&lt;T&gt;,
13543               class Compare = less&lt;typename Container::value_type&gt; &gt;
13544     class priority_queue {
13545     public:
13546       typedef typename Container::value_type            value_type;
13547       typedef typename Container::size_type             size_type;
13548       typedef          Container                        container_type;
13549     protected:
13550       Container c;
13551       Compare comp;
13552
13553     public:
13554       explicit priority_queue(const Compare&amp; x = Compare(),
13555                               const Container&amp; = Container());
13556       template &lt;class InputIterator&gt;
13557         priority_queue(InputIterator first, InputIterator last,
13558                        const Compare&amp; x = Compare(),
13559                        const Container&amp; = Container());
13560
13561       bool      empty() const       { return c.empty(); }
13562       size_type size()  const       { return c.size(); }
13563       const value_type&amp; top() const { return c.front(); }
13564       void push(const value_type&amp; x);
13565       void pop();
13566     };
13567                                   //  no equality is provided
13568   }
13569 </pre>
13570
13571 <p>to:</p>
13572
13573 <pre>  namespace std {
13574     template &lt;class T, class Container = vector&lt;T&gt;,
13575               class Compare = less&lt;typename Container::value_type&gt; &gt;
13576     class priority_queue {
13577     public:
13578       typedef typename Container::value_type            value_type;
13579       typedef typename Container::reference             reference;
13580       typedef typename Container::const_reference       const_reference;
13581       typedef typename Container::size_type             size_type;
13582       typedef          Container                        container_type;
13583     protected:
13584       Container c;
13585       Compare comp;
13586
13587     public:
13588       explicit priority_queue(const Compare&amp; x = Compare(),
13589                               const Container&amp; = Container());
13590       template &lt;class InputIterator&gt;
13591         priority_queue(InputIterator first, InputIterator last,
13592                        const Compare&amp; x = Compare(),
13593                        const Container&amp; = Container());
13594
13595       bool      empty() const       { return c.empty(); }
13596       size_type size()  const       { return c.size(); }
13597       const_reference   top() const { return c.front(); }
13598       void push(const value_type&amp; x);
13599       void pop();
13600     };
13601                                   //  no equality is provided
13602   }
13603 </pre>
13604
13605 <p>And change 23.2.3.3/1 from:</p>
13606
13607 <pre>  namespace std {
13608     template &lt;class T, class Container = deque&lt;T&gt; &gt;
13609     class stack {
13610     public:
13611       typedef typename Container::value_type            value_type;
13612       typedef typename Container::size_type             size_type;
13613       typedef          Container                        container_type;
13614     protected:
13615       Container c;
13616
13617     public:
13618       explicit stack(const Container&amp; = Container());
13619
13620       bool      empty() const             { return c.empty(); }
13621       size_type size()  const             { return c.size(); }
13622       value_type&amp;       top()             { return c.back(); }
13623       const value_type&amp; top() const       { return c.back(); }
13624       void push(const value_type&amp; x)      { c.push_back(x); }
13625       void pop()                          { c.pop_back(); }
13626     };
13627
13628     template &lt;class T, class Container&gt;
13629       bool operator==(const stack&lt;T, Container&gt;&amp; x,
13630                       const stack&lt;T, Container&gt;&amp; y);
13631     template &lt;class T, class Container&gt;
13632       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
13633                       const stack&lt;T, Container&gt;&amp; y);
13634     template &lt;class T, class Container&gt;
13635       bool operator!=(const stack&lt;T, Container&gt;&amp; x,
13636                       const stack&lt;T, Container&gt;&amp; y);
13637     template &lt;class T, class Container&gt;
13638       bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
13639                       const stack&lt;T, Container&gt;&amp; y);
13640     template &lt;class T, class Container&gt;
13641       bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
13642                       const stack&lt;T, Container&gt;&amp; y);
13643     template &lt;class T, class Container&gt;
13644       bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
13645                       const stack&lt;T, Container&gt;&amp; y);
13646   }
13647 </pre>
13648
13649 <p>to:</p>
13650
13651 <pre>  namespace std {
13652     template &lt;class T, class Container = deque&lt;T&gt; &gt;
13653     class stack {
13654     public:
13655       typedef typename Container::value_type            value_type;
13656       typedef typename Container::reference             reference;
13657       typedef typename Container::const_reference       const_reference;
13658       typedef typename Container::size_type             size_type;
13659       typedef          Container                        container_type;
13660     protected:
13661       Container c;
13662
13663     public:
13664       explicit stack(const Container&amp; = Container());
13665
13666       bool      empty() const             { return c.empty(); }
13667       size_type size()  const             { return c.size(); }
13668       reference         top()             { return c.back(); }
13669       const_reference   top() const       { return c.back(); }
13670       void push(const value_type&amp; x)      { c.push_back(x); }
13671       void pop()                          { c.pop_back(); }
13672     };
13673
13674     template &lt;class T, class Container&gt;
13675       bool operator==(const stack&lt;T, Container&gt;&amp; x,
13676                       const stack&lt;T, Container&gt;&amp; y);
13677     template &lt;class T, class Container&gt;
13678       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
13679                       const stack&lt;T, Container&gt;&amp; y);
13680     template &lt;class T, class Container&gt;
13681       bool operator!=(const stack&lt;T, Container&gt;&amp; x,
13682                       const stack&lt;T, Container&gt;&amp; y);
13683     template &lt;class T, class Container&gt;
13684       bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
13685                       const stack&lt;T, Container&gt;&amp; y);
13686     template &lt;class T, class Container&gt;
13687       bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
13688                       const stack&lt;T, Container&gt;&amp; y);
13689     template &lt;class T, class Container&gt;
13690       bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
13691                       const stack&lt;T, Container&gt;&amp; y);
13692   }
13693 </pre>
13694
13695 <p><i>[Copenhagen: This change was discussed before the IS was released
13696 and it was deliberately not adopted.  Nevertheless, the LWG believes
13697 (straw poll: 10-2) that it is a genuine defect.]</i></p>
13698
13699
13700
13701
13702
13703
13704 <hr>
13705 <h3><a name="308"></a>308. Table 82 mentions unrelated headers</h3>
13706 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13707  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-15</p>
13708 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
13709 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13710 <p><b>Discussion:</b></p>
13711 <p>
13712 Table 82 in section 27 mentions the header &lt;cstdlib&gt; for String
13713 streams (27.7 [string.streams]) and the headers &lt;cstdio&gt; and
13714 &lt;cwchar&gt; for File streams (27.8 [file.streams]). It's not clear
13715 why these headers are mentioned in this context since they do not
13716 define any of the library entities described by the
13717 subclauses. According to 17.4.1.1 [contents], only such headers
13718 are to be listed in the summary.
13719 </p>
13720
13721
13722 <p><b>Proposed resolution:</b></p>
13723 <p>Remove &lt;cstdlib&gt; and &lt;cwchar&gt; from
13724 Table 82.</p>
13725
13726 <p><i>[Copenhagen: changed the proposed resolution slightly.  The
13727 original proposed resolution also said to remove &lt;cstdio&gt; from
13728 Table 82.  However, &lt;cstdio&gt; is mentioned several times within
13729 section 27.8 [file.streams], including 27.8.2 [c.files].]</i></p>
13730
13731
13732
13733
13734
13735
13736 <hr>
13737 <h3><a name="310"></a>310. Is errno a macro?</h3>
13738 <p><b>Section:</b> 17.4.1.2 [headers], 19.3 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13739  <b>Submitter:</b> Steve Clamage <b>Date:</b> 2001-03-21</p>
13740 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</p>
13741 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13742 <p><b>Discussion:</b></p>
13743   <p>
13744   Exactly how should errno be declared in a conforming C++ header?
13745   </p>
13746
13747   <p>
13748   The C standard says in 7.1.4 that it is unspecified whether errno is a
13749   macro or an identifier with external linkage.  In some implementations
13750   it can be either, depending on compile-time options.  (E.g., on
13751   Solaris in multi-threading mode, errno is a macro that expands to a
13752   function call, but is an extern int otherwise.  "Unspecified" allows
13753   such variability.)
13754   </p>
13755
13756   <p>The C++ standard:</p>
13757   <ul>
13758   <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
13759   <li>17.4.3.1.3 footnote 166 says errno is reserved as an external
13760       name (true), and implies that it is an identifier.</li>
13761   <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
13762       on to say that the contents of of C++ &lt;errno.h&gt; are the
13763       same as in C, begging the question.</li>
13764   <li>C.2, table 95 lists errno as a macro, without comment.</li>
13765   </ul>
13766
13767   <p>I find no other references to errno.</p>
13768
13769   <p>We should either explicitly say that errno must be a macro, even
13770   though it need not be a macro in C, or else explicitly leave it
13771   unspecified.  We also need to say something about namespace std.
13772   A user who includes &lt;cerrno&gt; needs to know whether to write
13773   <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
13774   else &lt;cerrno&gt; is useless.</p>
13775
13776   <p>Two acceptable fixes:</p>
13777   <ul>
13778     <li><p>errno must be a macro. This is trivially satisfied by adding<br>
13779         &nbsp;&nbsp;#define errno (::std::errno)<br>
13780         to the headers if errno is not already a macro. You then always
13781         write errno without any scope qualification, and it always expands
13782         to a correct reference. Since it is always a macro, you know to
13783         avoid using errno as a local identifer.</p></li>
13784     <li><p>errno is in the global namespace. This fix is inferior, because
13785         ::errno is not guaranteed to be well-formed.</p></li>
13786   </ul>
13787
13788   <p><i>[
13789     This issue was first raised in 1999, but it slipped through
13790     the cracks.
13791   ]</i></p>
13792
13793
13794
13795 <p><b>Proposed resolution:</b></p>
13796   <p>Change the Note in section 17.4.1.2p5 from</p>
13797
13798     <blockquote><p>
13799     Note: the names defined as macros in C include the following:
13800     assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
13801     </p></blockquote>
13802
13803   <p>to</p>
13804
13805     <blockquote><p>
13806     Note: the names defined as macros in C include the following:
13807     assert, offsetof, setjmp, va_arg, va_end, and va_start.
13808     </p></blockquote>
13809
13810   <p>In section 19.3, change paragraph 2 from</p>
13811
13812     <blockquote><p>
13813     The contents are the same as the Standard C library header
13814     &lt;errno.h&gt;.
13815     </p></blockquote>
13816
13817   <p>to</p>
13818
13819     <blockquote><p>
13820     The contents are the same as the Standard C library header
13821     &lt;errno.h&gt;, except that errno shall be defined as a macro.
13822     </p></blockquote>
13823
13824
13825 <p><b>Rationale:</b></p>
13826 <p>C++ must not leave it up to the implementation to decide whether or
13827 not a name is a macro; it must explicitly specify exactly which names
13828 are required to be macros.  The only one that really works is for it
13829 to be a macro.</p>
13830
13831 <p><i>[Curaçao: additional rationale added.]</i></p>
13832
13833
13834
13835
13836
13837
13838
13839 <hr>
13840 <h3><a name="311"></a>311. Incorrect wording in basic_ostream class synopsis</h3>
13841 <p><b>Section:</b> 27.6.2.1 [ostream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13842  <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-03-21</p>
13843 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream">issues</a> in [ostream].</p>
13844 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13845 <p><b>Discussion:</b></p>
13846
13847 <p>In 27.6.2.1 [ostream], the synopsis of class basic_ostream says:</p>
13848
13849 <pre>  // partial specializationss
13850   template&lt;class traits&gt;
13851     basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;( basic_ostream&lt;char,traits&gt;&amp;,
13852                                             const char * );
13853 </pre>
13854
13855 <p>Problems:</p>
13856 <ul>
13857 <li>Too many 's's at the end of "specializationss" </li>
13858 <li>This is an overload, not a partial specialization</li>
13859 </ul>
13860
13861
13862
13863 <p><b>Proposed resolution:</b></p>
13864 <p>In the synopsis in 27.6.2.1 [ostream], remove the
13865 <i>// partial specializationss</i> comment.  Also remove the same
13866 comment (correctly spelled, but still incorrect) from the synopsis in
13867 27.6.2.6.4 [ostream.inserters.character].
13868 </p>
13869
13870 <p><i>[
13871 Pre-Redmond: added 27.6.2.6.4 [ostream.inserters.character] because of Martin's
13872 comment in c++std-lib-8939.
13873 ]</i></p>
13874
13875
13876
13877
13878
13879
13880
13881 <hr>
13882 <h3><a name="312"></a>312. Table 27 is missing headers</h3>
13883 <p><b>Section:</b> 20 [utilities] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13884  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-29</p>
13885 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13886 <p><b>Discussion:</b></p>
13887 <p>Table 27 in section 20 lists the header &lt;memory&gt; (only) for
13888 Memory (lib.memory) but neglects to mention the headers
13889 &lt;cstdlib&gt; and &lt;cstring&gt; that are discussed in 20.4.5 [meta.rel].</p>
13890
13891
13892 <p><b>Proposed resolution:</b></p>
13893 <p>Add &lt;cstdlib&gt; and &lt;cstring&gt; to Table 27, in the same row
13894 as &lt;memory&gt;.</p>
13895
13896
13897
13898
13899
13900 <hr>
13901 <h3><a name="315"></a>315. Bad "range" in list::unique complexity</h3>
13902 <p><b>Section:</b> 23.2.3.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13903  <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-05-01</p>
13904 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
13905 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13906 <p><b>Discussion:</b></p>
13907 <p>
13908 23.2.3.4 [list.ops], Para 21 describes the complexity of
13909 list::unique as: "If the range (last - first) is not empty, exactly
13910 (last - first) -1 applications of the corresponding predicate,
13911 otherwise no applications of the predicate)".
13912 </p>
13913
13914 <p>
13915 "(last - first)" is not a range.
13916 </p>
13917
13918
13919 <p><b>Proposed resolution:</b></p>
13920 <p>
13921 Change the "range" from (last - first) to [first, last).
13922 </p>
13923
13924
13925
13926
13927 <hr>
13928 <h3><a name="316"></a>316. Vague text in Table 69</h3>
13929 <p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13930  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-04</p>
13931 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
13932 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13933 <p><b>Discussion:</b></p>
13934 <p>Table 69 says this about a_uniq.insert(t):</p>
13935
13936 <blockquote><p>
13937 inserts t if and only if there is no element in the container with key
13938 equivalent to the key of t. The bool component of the returned pair
13939 indicates whether the insertion takes place and the iterator component of the
13940 pair points to the element with key equivalent to the key of t.
13941 </p></blockquote>
13942
13943 <p>The description should be more specific about exactly how the bool component
13944 indicates whether the insertion takes place.</p>
13945
13946
13947 <p><b>Proposed resolution:</b></p>
13948 <p>Change the text in question to</p>
13949
13950 <blockquote><p>
13951 ...The bool component of the returned pair is true if and only if the insertion
13952 takes place...
13953 </p></blockquote>
13954
13955
13956
13957
13958
13959 <hr>
13960 <h3><a name="317"></a>317. Instantiation vs. specialization of facets</h3>
13961 <p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13962  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-04</p>
13963 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
13964 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13965 <p><b>Discussion:</b></p>
13966 <p>
13967 The localization section of the standard refers to specializations of
13968 the facet templates as instantiations even though the required facets
13969 are typically specialized rather than explicitly (or implicitly)
13970 instantiated. In the case of ctype&lt;char&gt; and
13971 ctype_byname&lt;char&gt; (and the wchar_t versions), these facets are
13972 actually required to be specialized. The terminology should be
13973 corrected to make it clear that the standard doesn't mandate explicit
13974 instantiation (the term specialization encompasses both explicit
13975 instantiations and specializations).
13976 </p>
13977
13978
13979 <p><b>Proposed resolution:</b></p>
13980 <p>
13981 In the following paragraphs, replace all occurrences of the word
13982 instantiation or instantiations with specialization or specializations,
13983 respectively:
13984 </p>
13985
13986 <blockquote><p>
13987 22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
13988 22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3,
13989 22.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and
13990 Footnote 242.
13991 </p></blockquote>
13992
13993 <p>And change the text in 22.1.1.1.1, p4 from</p>
13994
13995 <blockquote><p>
13996     An implementation is required to provide those instantiations
13997     for facet templates identified as members of a category, and
13998     for those shown in Table 52:
13999 </p></blockquote>
14000
14001 <p>to</p>
14002
14003 <blockquote><p>
14004     An implementation is required to provide those specializations...
14005 </p></blockquote>
14006
14007 <p><i>[Nathan will review these changes, and will look for places where
14008 explicit specialization is necessary.]</i></p>
14009
14010
14011
14012
14013 <p><b>Rationale:</b></p>
14014 <p>This is a simple matter of outdated language.  The language to
14015 describe templates was clarified during the standardization process,
14016 but the wording in clause 22 was never updated to reflect that
14017 change.</p>
14018
14019
14020
14021
14022
14023
14024
14025 <hr>
14026 <h3><a name="318"></a>318. Misleading comment in definition of numpunct_byname</h3>
14027 <p><b>Section:</b> 22.2.3.2 [locale.numpunct.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14028  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-12</p>
14029 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14030 <p><b>Discussion:</b></p>
14031 <p>The definition of the numpunct_byname template contains the following
14032 comment:</p>
14033
14034 <pre>    namespace std {
14035         template &lt;class charT&gt;
14036         class numpunct_byname : public numpunct&lt;charT&gt; {
14037     // this class is specialized for char and wchar_t.
14038         ...
14039 </pre>
14040
14041 <p>There is no documentation of the specializations and it seems
14042 conceivable that an implementation will not explicitly specialize the
14043 template at all, but simply provide the primary template.</p>
14044
14045
14046 <p><b>Proposed resolution:</b></p>
14047 <p>Remove the comment from the text in 22.2.3.2 and from the proposed
14048 resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
14049
14050
14051
14052
14053 <hr>
14054 <h3><a name="319"></a>319. Storage allocation wording confuses "Required behavior", "Requires"</h3>
14055 <p><b>Section:</b> 18.5.1.1 [new.delete.single], 18.5.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14056  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2001-05-15</p>
14057 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p>
14058 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14059 <p><b>Discussion:</b></p>
14060 <p>The standard specifies 17.3.1.3 [structure.specifications] that "Required
14061 behavior" elements describe "the semantics of a function definition
14062 provided by either the implementation or a C++ program."</p>
14063
14064 <p>The standard specifies 17.3.1.3 [structure.specifications] that "Requires"
14065 elements describe "the preconditions for calling the function."</p>
14066
14067 <p>In the sections noted below, the current wording specifies
14068 "Required Behavior" for what are actually preconditions, and thus
14069 should be specified as "Requires".</p>
14070
14071
14072
14073 <p><b>Proposed resolution:</b></p>
14074
14075 <p>In 18.5.1.1 [new.delete.single] Para 12 Change:</p>
14076 <blockquote>
14077   <p>Required behavior: accept a value of ptr that is null or that was
14078   returned by an earlier call ...</p>
14079 </blockquote>
14080 <p>to:</p>
14081 <blockquote>
14082   <p>Requires: the value of ptr is null or the value returned by an
14083   earlier call ...</p>
14084 </blockquote>
14085
14086 <p>In 18.5.1.2 [new.delete.array] Para 11 Change:</p>
14087 <blockquote>
14088   <p>Required behavior: accept a value of ptr that is null or that was
14089   returned by an earlier call ...</p>
14090 </blockquote>
14091 <p>to:</p>
14092 <blockquote>
14093   <p>Requires: the value of ptr is null or the value returned by an
14094   earlier call ...</p>
14095 </blockquote>
14096
14097
14098
14099
14100
14101 <hr>
14102 <h3><a name="320"></a>320. list::assign overspecified</h3>
14103 <p><b>Section:</b> 23.2.3.1 [list.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14104  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-05-17</p>
14105 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.cons">issues</a> in [list.cons].</p>
14106 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14107 <p><b>Discussion:</b></p>
14108 <p>
14109 Section 23.2.3.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have
14110 the "effects" of a call to erase followed by a call to insert.
14111 </p>
14112
14113 <p>
14114 I would like to document that implementers have the freedom to implement
14115 assign by other methods, as long as the end result is the same and the
14116 exception guarantee is as good or better than the basic guarantee.
14117 </p>
14118
14119 <p>
14120 The motivation for this is to use T's assignment operator to recycle
14121 existing nodes in the list instead of erasing them and reallocating
14122 them with new values.  It is also worth noting that, with careful
14123 coding, most common cases of assign (everything but assignment with
14124 true input iterators) can elevate the exception safety to strong if
14125 T's assignment has a nothrow guarantee (with no extra memory cost).
14126 Metrowerks does this.  However I do not propose that this subtlety be
14127 standardized.  It is a QoI issue.  </p>
14128
14129 <p>Existing practise:
14130 Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
14131 </p>
14132
14133
14134 <p><b>Proposed resolution:</b></p>
14135 <p>Change 23.2.3.1 [list.cons]/7 from:</p>
14136
14137 <blockquote>
14138 <p>Effects:</p>
14139
14140 <pre>   erase(begin(), end());
14141    insert(begin(), first, last);
14142 </pre>
14143 </blockquote>
14144
14145 <p>to:</p>
14146
14147 <blockquote>
14148 <p>Effects: Replaces the contents of the list with the range [first, last).</p>
14149 </blockquote>
14150
14151 <p>In 23.1.1 [sequence.reqmts], in Table 67 (sequence requirements),
14152 add two new rows:</p>
14153 <pre>      a.assign(i,j)     void      pre: i,j are not iterators into a.
14154                                   Replaces elements in a with a copy
14155                                   of [i, j).
14156
14157       a.assign(n,t)     void      pre: t is not a reference into a.
14158                                   Replaces elements in a with n copies
14159                                   of t.
14160 </pre>
14161
14162 <p>Change 23.2.3.1 [list.cons]/8 from:</p>
14163
14164 <blockquote>
14165 <p>Effects:</p>
14166 <pre>   erase(begin(), end());
14167    insert(begin(), n, t);
14168 </pre>
14169 </blockquote>
14170 <p>to:</p>
14171
14172 <blockquote>
14173 <p>Effects: Replaces the contents of the list with n copies of t.</p>
14174 </blockquote>
14175
14176 <p><i>[Redmond: Proposed resolution was changed slightly.  Previous
14177 version made explicit statement about exception safety, which wasn't
14178 consistent with the way exception safety is expressed elsewhere.
14179 Also, the change in the sequence requirements is new.  Without that
14180 change, the proposed resolution would have required that assignment of
14181 a subrange would have to work.  That too would have been
14182 overspecification; it would effectively mandate that assignment use a
14183 temporary.  Howard provided wording.
14184 ]</i></p>
14185
14186
14187 <p><i>[Curaçao: Made editorial improvement in wording; changed
14188 "Replaces elements in a with copies of elements in [i, j)."
14189 with "Replaces the elements of a with a copy of [i, j)."
14190 Changes not deemed serious enough to requre rereview.]</i></p>
14191
14192
14193
14194
14195
14196
14197
14198 <hr>
14199 <h3><a name="321"></a>321. Typo in num_get</h3>
14200 <p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14201  <b>Submitter:</b> Kevin Djang <b>Date:</b> 2001-05-17</p>
14202 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
14203 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
14204 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14205 <p><b>Discussion:</b></p>
14206 <p>
14207 Section 22.2.2.1.2 at p7 states that "A length specifier is added to
14208 the conversion function, if needed, as indicated in Table 56."
14209 However, Table 56 uses the term "length modifier", not "length
14210 specifier".
14211 </p>
14212
14213
14214 <p><b>Proposed resolution:</b></p>
14215 <p>
14216 In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
14217 to be "A length modifier is added ..."
14218 </p>
14219
14220
14221 <p><b>Rationale:</b></p>
14222 <p>C uses the term "length modifier".  We should be consistent.</p>
14223
14224
14225
14226
14227
14228
14229 <hr>
14230 <h3><a name="322"></a>322. iterator and const_iterator should have the same value type</h3>
14231 <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14232  <b>Submitter:</b> Matt Austern <b>Date:</b> 2001-05-17</p>
14233 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
14234 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
14235 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14236 <p><b>Discussion:</b></p>
14237 <p>
14238 It's widely assumed that, if X is a container,
14239 iterator_traits&lt;X::iterator&gt;::value_type and
14240 iterator_traits&lt;X::const_iterator&gt;::value_type should both be
14241 X::value_type.  However, this is nowhere stated.  The language in
14242 Table 65 is not precise about the iterators' value types (it predates
14243 iterator_traits), and could even be interpreted as saying that
14244 iterator_traits&lt;X::const_iterator&gt;::value_type should be "const
14245 X::value_type".
14246 </p>
14247
14248 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a>.</p>
14249
14250
14251 <p><b>Proposed resolution:</b></p>
14252 <p>In Table 65 ("Container Requirements"), change the return type for
14253 X::iterator to "iterator type whose value type is T".  Change the
14254 return type for X::const_iterator to "constant iterator type whose
14255 value type is T".</p>
14256
14257
14258 <p><b>Rationale:</b></p>
14259 <p>
14260 This belongs as a container requirement, rather than an iterator
14261 requirement, because the whole notion of iterator/const_iterator
14262 pairs is specific to containers' iterator.
14263 </p>
14264 <p>
14265 It is existing practice that (for example)
14266 iterator_traits&lt;list&lt;int&gt;::const_iterator&gt;::value_type
14267 is "int", rather than "const int".  This is consistent with
14268 the way that const pointers are handled: the standard already
14269 requires that iterator_traits&lt;const int*&gt;::value_type is int.
14270 </p>
14271
14272
14273
14274
14275
14276 <hr>
14277 <h3><a name="324"></a>324. Do output iterators have value types?</h3>
14278 <p><b>Section:</b> 24.1.2 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14279  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-06-07</p>
14280 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
14281 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14282 <p><b>Discussion:</b></p>
14283
14284 <p>Table 73 suggests that output iterators have value types.  It
14285 requires the expression "*a = t".  Additionally, although Table 73
14286 never lists "a = t" or "X(a) = t" in the "expressions" column, it
14287 contains a note saying that "a = t" and "X(a) = t" have equivalent
14288 (but nowhere specified!) semantics.</p>
14289
14290 <p>According to 24.1/9, t is supposed to be "a value of value type
14291 T":</p>
14292
14293     <blockquote><p>
14294     In the following sections, a and b denote values of X, n denotes a
14295     value of the difference type Distance, u, tmp, and m denote
14296     identifiers, r denotes a value of X&amp;, t denotes a value of
14297     value type T.
14298     </p></blockquote>
14299
14300 <p>Two other parts of the standard that are relevant to whether
14301 output iterators have value types:</p>
14302
14303 <ul>
14304     <li>24.1/1 says "All iterators i support the expression *i,
14305     resulting in a value of some class, enumeration, or built-in type
14306     T, called the value type of the iterator".</li>
14307
14308     <li>
14309     24.3.1/1, which says "In the case of an output iterator, the types
14310     iterator_traits&lt;Iterator&gt;::difference_type
14311     iterator_traits&lt;Iterator&gt;::value_type are both defined as void."
14312     </li>
14313 </ul>
14314
14315 <p>The first of these passages suggests that "*i" is supposed to
14316 return a useful value, which contradicts the note in 24.1.2/2 saying
14317 that the only valid use of "*i" for output iterators is in an
14318 expression of the form "*i = t".  The second of these passages appears
14319 to contradict Table 73, because it suggests that "*i"'s return value
14320 should be void.  The second passage is also broken in the case of a an
14321 iterator type, like non-const pointers, that satisfies both the output
14322 iterator requirements and the forward iterator requirements.</p>
14323
14324 <p>What should the standard say about <tt>*i</tt>'s return value when
14325 i is an output iterator, and what should it say about that t is in the
14326 expression "*i = t"?  Finally, should the standard say anything about
14327 output iterators' pointer and reference types?</p>
14328
14329
14330
14331 <p><b>Proposed resolution:</b></p>
14332 <p>24.1 p1, change</p>
14333
14334 <blockquote>
14335 <p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
14336 in a value of some class, enumeration, or built-in type <tt>T</tt>,
14337 called the value type of the iterator.</p>
14338 </blockquote>
14339
14340 <p>to</p>
14341
14342 <blockquote>
14343 <p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
14344 resulting in a value of some class, enumeration, or built-in type
14345 <tt>T</tt>, called the value type of the iterator. All output
14346 iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
14347 value of some type that is in the set of types that are <i>writable</i> to
14348 the particular iterator type of <tt>i</tt>.
14349 </p>
14350 </blockquote>
14351
14352 <p>24.1 p9, add</p>
14353
14354 <blockquote>
14355 <p><tt>o</tt> denotes a value of some type that is writable to the
14356 output iterator.
14357 </p>
14358 </blockquote>
14359
14360 <p>Table 73, change</p>
14361
14362 <blockquote>
14363 <pre>*a = t
14364 </pre>
14365 </blockquote>
14366
14367 <p>to</p>
14368
14369 <blockquote>
14370 <pre>*r = o
14371 </pre>
14372 </blockquote>
14373
14374 <p>and change</p>
14375
14376 <blockquote>
14377 <pre>*r++ = t
14378 </pre>
14379 </blockquote>
14380
14381 <p>to</p>
14382
14383 <blockquote>
14384 <pre>*r++ = o
14385 </pre>
14386 </blockquote>
14387
14388 <p><i>[post-Redmond: Jeremy provided wording]</i></p>
14389
14390
14391
14392
14393 <p><b>Rationale:</b></p>
14394 <p>The LWG considered two options: change all of the language that
14395 seems to imply that output iterators have value types, thus making it
14396 clear that output iterators have no value types, or else define value
14397 types for output iterator consistently.  The LWG chose the former
14398 option, because it seems clear that output iterators were never
14399 intended to have value types.  This was a deliberate design decision,
14400 and any language suggesting otherwise is simply a mistake.</p>
14401
14402 <p>A future revision of the standard may wish to revisit this design
14403 decision.</p>
14404
14405
14406
14407
14408
14409 <hr>
14410 <h3><a name="325"></a>325. Misleading text in moneypunct&lt;&gt;::do_grouping</h3>
14411 <p><b>Section:</b> 22.2.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14412  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-02</p>
14413 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.moneypunct.virtuals">issues</a> in [locale.moneypunct.virtuals].</p>
14414 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14415 <p><b>Discussion:</b></p>
14416 <p>The Returns clause in 22.2.6.3.2, p3 says about
14417 moneypunct&lt;charT&gt;::do_grouping()
14418 </p>
14419
14420 <blockquote><p>
14421     Returns: A pattern defined identically as the result of
14422     numpunct&lt;charT&gt;::do_grouping().241)
14423 </p></blockquote>
14424
14425 <p>Footnote 241 then reads</p>
14426
14427 <blockquote><p>
14428     This is most commonly the value "\003" (not "3").
14429 </p></blockquote>
14430
14431 <p>
14432 The returns clause seems to imply that the two member functions must
14433 return an identical value which in reality may or may not be true,
14434 since the facets are usually implemented in terms of struct std::lconv
14435 and return the value of the grouping and mon_grouping, respectively.
14436 The footnote also implies that the member function of the moneypunct
14437 facet (rather than the overridden virtual functions in moneypunct_byname)
14438 most commonly return "\003", which contradicts the C standard which
14439 specifies the value of "" for the (most common) C locale.
14440 </p>
14441
14442
14443
14444 <p><b>Proposed resolution:</b></p>
14445 <p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>
14446
14447 <blockquote><p>
14448     Returns: A pattern defined identically as, but not necessarily
14449     equal to, the result of numpunct&lt;charT&gt;::do_grouping().241)
14450 </p></blockquote>
14451
14452 <p>and replace the text in Footnote 241 with the following:</p>
14453
14454 <blockquote><p>
14455     To specify grouping by 3s the value is "\003", not "3".
14456 </p></blockquote>
14457
14458
14459 <p><b>Rationale:</b></p>
14460 <p>
14461 The fundamental problem is that the description of the locale facet
14462 virtuals serves two purposes: describing the behavior of the base
14463 class, and describing the meaning of and constraints on the behavior
14464 in arbitrary derived classes.  The new wording makes that separation a
14465 little bit clearer.  The footnote (which is nonnormative) is not
14466 supposed to say what the grouping is in the "C" locale or in any other
14467 locale. It is just a reminder that the values are interpreted as small
14468 integers, not ASCII characters.
14469 </p>
14470
14471
14472
14473
14474 <hr>
14475 <h3><a name="327"></a>327. Typo in time_get facet in table 52</h3>
14476 <p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14477  <b>Submitter:</b> Tiki Wan <b>Date:</b> 2001-07-06</p>
14478 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
14479 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14480 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#447">447</a></p>
14481 <p><b>Discussion:</b></p>
14482 <p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
14483 <tt>time_get_byname</tt> are listed incorrectly in table 52,
14484 required instantiations.  In both cases the second template
14485 parameter is given as OutputIterator.  It should instead be
14486 InputIterator, since these are input facets.</p>
14487
14488
14489 <p><b>Proposed resolution:</b></p>
14490 <p>
14491 In table 52, required instantiations, in
14492 22.1.1.1.1 [locale.category], change</p>
14493 <pre>    time_get&lt;wchar_t, OutputIterator&gt;
14494     time_get_byname&lt;wchar_t, OutputIterator&gt;
14495 </pre>
14496 <p>to</p>
14497 <pre>    time_get&lt;wchar_t, InputIterator&gt;
14498     time_get_byname&lt;wchar_t, InputIterator&gt;
14499 </pre>
14500
14501 <p><i>[Redmond: Very minor change in proposed resolution.  Original had
14502 a typo, wchart instead of wchar_t.]</i></p>
14503
14504
14505
14506
14507
14508
14509 <hr>
14510 <h3><a name="328"></a>328. Bad sprintf format modifier in money_put&lt;&gt;::do_put()</h3>
14511 <p><b>Section:</b> 22.2.6.2.2 [locale.money.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14512  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-07</p>
14513 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14514 <p><b>Discussion:</b></p>
14515 <p>The sprintf format string , "%.01f" (that's the digit one), in the
14516 description of the do_put() member functions of the money_put facet in
14517 22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
14518 for values of type long double, and second, the precision of 01
14519 doesn't seem to make sense. What was most likely intended was
14520 "%.0Lf"., that is a precision of zero followed by the L length
14521 modifier.</p>
14522
14523
14524 <p><b>Proposed resolution:</b></p>
14525 <p>Change the format string to "%.0Lf".</p>
14526
14527
14528 <p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
14529
14530
14531
14532
14533 <hr>
14534 <h3><a name="329"></a>329. vector capacity, reserve and reallocation</h3>
14535 <p><b>Section:</b> 23.2.5.2 [vector.capacity], 23.2.5.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14536  <b>Submitter:</b> Anthony Williams <b>Date:</b> 2001-07-13</p>
14537 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
14538 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14539 <p><b>Discussion:</b></p>
14540 <p>
14541 There is an apparent contradiction about which circumstances can cause
14542 a reallocation of a vector in Section 23.2.5.2 [vector.capacity] and
14543 section 23.2.5.4 [vector.modifiers].
14544 </p>
14545
14546 <p>23.2.5.2 [vector.capacity],p5 says:</p>
14547 <blockquote><p>
14548 Notes: Reallocation invalidates all the references, pointers, and iterators
14549 referring to the elements in the sequence. It is guaranteed that no
14550 reallocation takes place during insertions that happen after a call to
14551 reserve() until the time when an insertion would make the size of the vector
14552 greater than the size specified in the most recent call to reserve().
14553 </p></blockquote>
14554
14555 <p>Which implies if I do</p>
14556
14557 <pre>  std::vector&lt;int&gt; vec;
14558   vec.reserve(23);
14559   vec.reserve(0);
14560   vec.insert(vec.end(),1);
14561 </pre>
14562
14563 <p>then the implementation may reallocate the vector for the insert,
14564 as the size specified in the previous call to reserve was zero.</p>
14565
14566 <p>However, the previous paragraphs (23.2.5.2 [vector.capacity], p1-2) state:</p>
14567 <blockquote>
14568 <p>
14569 (capacity) Returns: The total number of elements the vector
14570 can hold without requiring reallocation
14571 </p>
14572 <p>
14573 ...After reserve(), capacity() is greater or equal to the
14574 argument of reserve if reallocation happens; and equal to the previous value
14575 of capacity() otherwise...
14576 </p>
14577 </blockquote>
14578
14579 <p>
14580 This implies that vec.capacity() is still 23, and so the insert()
14581 should not require a reallocation, as vec.size() is 0. This is backed
14582 up by 23.2.5.4 [vector.modifiers], p1:
14583 </p>
14584 <blockquote><p>
14585 (insert) Notes: Causes reallocation if the new size is greater than the old
14586 capacity.
14587 </p></blockquote>
14588
14589 <p>
14590 Though this doesn't rule out reallocation if the new size is less
14591 than the old capacity, I think the intent is clear.
14592 </p>
14593
14594
14595
14596 <p><b>Proposed resolution:</b></p>
14597 <p>Change the wording of 23.2.5.2 [vector.capacity] paragraph 5 to:</p>
14598
14599 <blockquote><p>
14600 Notes: Reallocation invalidates all the references, pointers, and
14601 iterators referring to the elements in the sequence. It is guaranteed
14602 that no reallocation takes place during insertions that happen after a
14603 call to reserve() until the time when an insertion would make the size
14604 of the vector greater than the value of capacity().
14605 </p></blockquote>
14606
14607 <p><i>[Redmond: original proposed resolution was modified slightly.  In
14608 the original, the guarantee was that there would be no reallocation
14609 until the size would be greater than the value of capacity() after the
14610 most recent call to reserve().  The LWG did not believe that the
14611 "after the most recent call to reserve()" added any useful
14612 information.]</i></p>
14613
14614
14615
14616
14617 <p><b>Rationale:</b></p>
14618 <p>There was general agreement that, when reserve() is called twice in
14619 succession and the argument to the second invocation is smaller than
14620 the argument to the first, the intent was for the second invocation to
14621 have no effect.  Wording implying that such cases have an effect on
14622 reallocation guarantees was inadvertant.</p>
14623
14624
14625
14626
14627
14628 <hr>
14629 <h3><a name="331"></a>331. bad declaration of destructor for ios_base::failure</h3>
14630 <p><b>Section:</b> 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14631  <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-23</p>
14632 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</p>
14633 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14634 <p><b>Discussion:</b></p>
14635 <p>
14636 With the change in 17.4.4.8 [res.on.exception.handling] to state
14637    "An implementation may strengthen the exception-specification for a
14638     non-virtual function by removing listed exceptions."
14639 (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>)
14640 and the following declaration of ~failure() in ios_base::failure
14641 </p>
14642 <pre>    namespace std {
14643        class ios_base::failure : public exception {
14644        public:
14645            ...
14646            virtual ~failure();
14647            ...
14648        };
14649      }
14650 </pre>
14651 <p>the class failure cannot be implemented since in 18.6.1 [type.info] the destructor of class exception has an empty
14652 exception specification:</p>
14653 <pre>    namespace std {
14654        class exception {
14655        public:
14656          ...
14657          virtual ~exception() throw();
14658          ...
14659        };
14660      }
14661 </pre>
14662
14663
14664 <p><b>Proposed resolution:</b></p>
14665 <p>Remove the declaration of ~failure().</p>
14666
14667
14668 <p><b>Rationale:</b></p>
14669 <p>The proposed resolution is consistent with the way that destructors
14670 of other classes derived from <tt>exception</tt> are handled.</p>
14671
14672
14673
14674
14675
14676
14677
14678 <hr>
14679 <h3><a name="333"></a>333. does endl imply synchronization with the device?</h3>
14680 <p><b>Section:</b> 27.6.2.8 [ostream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14681  <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-27</p>
14682 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14683 <p><b>Discussion:</b></p>
14684 <p>A footnote in 27.6.2.8 [ostream.manip] states:</p>
14685 <blockquote><p>
14686     [Footnote: The effect of executing cout &lt;&lt; endl is to insert a
14687      newline character in the output sequence controlled by cout, then
14688      synchronize it with any external file with which it might be
14689      associated. --- end foonote]
14690 </p></blockquote>
14691
14692 <p>
14693 Does the term "file" here refer to the external device?
14694 This leads to some implementation ambiguity on systems with fully
14695 buffered files where a newline does not cause a flush to the device.
14696 </p>
14697
14698 <p>
14699 Choosing to sync with the device leads to significant performance
14700 penalties for each call to endl, while not sync-ing leads to
14701 errors under special circumstances.
14702 </p>
14703
14704 <p>
14705 I could not find any other statement that explicitly defined
14706 the behavior one way or the other.
14707 </p>
14708
14709
14710 <p><b>Proposed resolution:</b></p>
14711 <p>Remove footnote 300 from section 27.6.2.8 [ostream.manip].</p>
14712
14713
14714 <p><b>Rationale:</b></p>
14715 <p>We already have normative text saying what <tt>endl</tt> does: it
14716 inserts a newline character and calls <tt>flush</tt>.  This footnote
14717 is at best redundant, at worst (as this issue says) misleading,
14718 because it appears to make promises about what <tt>flush</tt>
14719 does.</p>
14720
14721
14722
14723
14724
14725
14726
14727 <hr>
14728 <h3><a name="334"></a>334. map::operator[] specification forces inefficient implementation</h3>
14729 <p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14730  <b>Submitter:</b> Andrea Griffini <b>Date:</b> 2001-09-02</p>
14731 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14732 <p><b>Discussion:</b></p>
14733 <p>
14734 The current standard describes map::operator[] using a
14735 code example. That code example is however quite
14736 inefficient because it requires several useless copies
14737 of both the passed key_type value and of default
14738 constructed mapped_type instances.
14739 My opinion is that was not meant by the comitee to
14740 require all those temporary copies.
14741 </p>
14742
14743 <p>Currently map::operator[] behaviour is specified as: </p>
14744 <pre>  Returns:
14745     (*((insert(make_pair(x, T()))).first)).second.
14746 </pre>
14747
14748 <p>
14749 This specification however uses make_pair that is a
14750 template function of which parameters in this case
14751 will be deduced being of type const key_type&amp; and
14752 const T&amp;. This will create a pair&lt;key_type,T&gt; that
14753 isn't the correct type expected by map::insert so
14754 another copy will be required using the template
14755 conversion constructor available in pair to build
14756 the required pair&lt;const key_type,T&gt; instance.
14757 </p>
14758
14759 <p>If we consider calling of key_type copy constructor
14760 and mapped_type default constructor and copy
14761 constructor as observable behaviour (as I think we
14762 should) then the standard is in this place requiring
14763 two copies of a key_type element plus a default
14764 construction and two copy construction of a mapped_type
14765 (supposing the addressed element is already present
14766 in the map; otherwise at least another copy
14767 construction for each type).
14768 </p>
14769
14770 <p>A simple (half) solution would be replacing the description with:</p>
14771 <pre>  Returns:
14772     (*((insert(value_type(x, T()))).first)).second.
14773 </pre>
14774
14775 <p>This will remove the wrong typed pair construction that
14776 requires one extra copy of both key and value.</p>
14777
14778 <p>However still the using of map::insert requires temporary
14779 objects while the operation, from a logical point of view,
14780 doesn't require any. </p>
14781
14782 <p>I think that a better solution would be leaving free an
14783 implementer to use a different approach than map::insert
14784 that, because of its interface, forces default constructed
14785 temporaries and copies in this case.
14786 The best solution in my opinion would be just requiring
14787 map::operator[] to return a reference to the mapped_type
14788 part of the contained element creating a default element
14789 with the specified key if no such an element is already
14790 present in the container. Also a logarithmic complexity
14791 requirement should be specified for the operation.
14792 </p>
14793
14794 <p>
14795 This would allow library implementers to write alternative
14796 implementations not using map::insert and reaching optimal
14797 performance in both cases of the addressed element being
14798 present or absent from the map (no temporaries at all and
14799 just the creation of a new pair inside the container if
14800 the element isn't present).
14801 Some implementer has already taken this option but I think
14802 that the current wording of the standard rules that as
14803 non-conforming.
14804 </p>
14805
14806
14807
14808 <p><b>Proposed resolution:</b></p>
14809
14810 <p>
14811 Replace 23.3.1.2 [map.access] paragraph 1 with
14812 </p>
14813 <blockquote>
14814 <p>
14815 -1- Effects:  If there is no key equivalent to x in the map, inserts
14816 value_type(x, T()) into the map.
14817 </p>
14818 <p>
14819 -2- Returns: A reference to the mapped_type corresponding to x in *this.
14820 </p>
14821 <p>
14822 -3- Complexity: logarithmic.
14823 </p>
14824 </blockquote>
14825
14826 <p><i>[This is the second option mentioned above.  Howard provided
14827 wording.  We may also wish to have a blanket statement somewhere in
14828 clause 17 saying that we do not intend the semantics of sample code
14829 fragments to be interpreted as specifing exactly how many copies are
14830 made.  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a> for a similar problem.]</i></p>
14831
14832
14833
14834
14835 <p><b>Rationale:</b></p>
14836 <p>
14837 This is the second solution described above; as noted, it is
14838 consistent with existing practice.
14839 </p>
14840
14841 <p>Note that we now need to specify the complexity explicitly, because
14842 we are no longer defining <tt>operator[]</tt> in terms of
14843 <tt>insert</tt>.</p>
14844
14845
14846
14847
14848
14849 <hr>
14850 <h3><a name="335"></a>335. minor issue with char_traits, table 37</h3>
14851 <p><b>Section:</b> 21.1.1 [char.traits.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14852  <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-09-06</p>
14853 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14854 <p><b>Discussion:</b></p>
14855 <p>
14856 Table 37, in 21.1.1 [char.traits.require], descibes char_traits::assign
14857 as:
14858 </p>
14859 <pre>  X::assign(c,d)   assigns c = d.
14860 </pre>
14861
14862 <p>And para 1 says:</p>
14863
14864 <blockquote><p>
14865  [...] c and d denote values of type CharT [...]
14866 </p></blockquote>
14867
14868 <p>
14869 Naturally, if c and d are <i>values</i>, then the assignment is
14870 (effectively) meaningless. It's clearly intended that (in the case of
14871 assign, at least), 'c' is intended to be a reference type.
14872 </p>
14873
14874 <p>I did a quick survey of the four implementations I happened to have
14875 lying around, and sure enough they all have signatures:</p>
14876 <pre>    assign( charT&amp;, const charT&amp; );
14877 </pre>
14878
14879 <p>(or the equivalent). It's also described this way in Nico's book.
14880 (Not to mention the synopses of char_traits&lt;char&gt; in 21.1.3.1
14881 and char_traits&lt;wchar_t&gt; in 21.1.3.2...)
14882 </p>
14883
14884
14885 <p><b>Proposed resolution:</b></p>
14886 <p>Add the following to 21.1.1 para 1:</p>
14887 <blockquote><p>
14888  r denotes an lvalue of CharT
14889 </p></blockquote>
14890
14891 <p>and change the description of assign in the table to:</p>
14892 <pre>  X::assign(r,d)   assigns r = d
14893 </pre>
14894
14895
14896
14897
14898
14899 <hr>
14900 <h3><a name="336"></a>336. Clause 17 lack of references to deprecated headers</h3>
14901 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14902  <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-09-05</p>
14903 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
14904 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14905 <p><b>Discussion:</b></p>
14906 <p>From c++std-edit-873:</p>
14907
14908 <p>17.4.1.2 [headers], Table 11.  In this table, the header
14909 &lt;strstream&gt; is missing.</p>
14910
14911 <p>This shows a general problem: The whole clause 17 refers quite
14912 often to clauses 18 through 27, but D.7 is also a part of the standard
14913 library (though a deprecated one).</p>
14914
14915
14916
14917 <p><b>Proposed resolution:</b></p>
14918
14919 <p>To 17.4.1.2 [headers] Table 11, C++ Library Headers, add
14920 "&lt;strstream&gt;".</p>
14921
14922 <p>In the following places, change "clauses 17 through 27" to "clauses
14923 17 through 27 and Annex D":</p>
14924
14925 <ul>
14926 <li>1.2 [intro.refs] Normative references/1/footnote 1</li>
14927 <li>1.3 [intro.defs] Definitions/1</li>
14928 <li>7 [dcl.dcl] Library introduction/9</li>
14929 <li>17.3 [description] Method of description (Informative)/1</li>
14930 <li>17.3.2.1.3 [character.seq] Character sequences/1/bullet 2</li>
14931 <li>17.3.2.2 [functions.within.classes] Functions within classes/1</li>
14932 <li>17.3.2.3 [objects.within.classes] Private members/1/(2 places)</li>
14933 <li>17.4 [requirements] Library-wide requirements/1</li>
14934 <li>17.4.1.2 [headers] Headers/4</li>
14935 <li>17.4.3.4 [replacement.functions] Replacement functions/1</li>
14936 <li>17.4.4.3 [global.functions] Global or non-member functions/2</li>
14937 <li>17.4.4.6 [protection.within.classes] Protection within classes/1</li>
14938 </ul>
14939
14940
14941
14942
14943
14944
14945
14946 <hr>
14947 <h3><a name="337"></a>337. replace_copy_if's template parameter should be InputIterator</h3>
14948 <p><b>Section:</b> 25.2.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14949  <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-09-07</p>
14950 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</p>
14951 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14952 <p><b>Discussion:</b></p>
14953 <p>From c++std-edit-876:</p>
14954
14955 <p>
14956 In section 25.2.5 [alg.replace] before p4: The name of the first
14957 parameter of template replace_copy_if should be "InputIterator"
14958 instead of "Iterator".  According to 17.3.2.1 [type.descriptions] p1 the
14959 parameter name conveys real normative meaning.
14960 </p>
14961
14962
14963 <p><b>Proposed resolution:</b></p>
14964 <p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
14965
14966
14967
14968
14969
14970 <hr>
14971 <h3><a name="338"></a>338.  is whitespace allowed between `-' and a digit?</h3>
14972 <p><b>Section:</b> 22.2 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14973  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-09-17</p>
14974 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.categories">active issues</a> in [locale.categories].</p>
14975 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
14976 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14977 <p><b>Discussion:</b></p>
14978 <p>
14979 From Stage 2 processing in 22.2.2.1.2 [facet.num.get.virtuals], p8 and 9 (the
14980 original text or the text corrected by the proposed resolution of
14981 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>) it seems clear that no whitespace is allowed
14982 within a number, but 22.2.3.1 [locale.numpunct], p2, which gives the
14983 format for integer and floating point values, says that whitespace is
14984 optional between a plusminus and a sign.
14985 </p>
14986
14987 <p>
14988 The text needs to be clarified to either consistently allow or
14989 disallow whitespace between a plusminus and a sign. It might be
14990 worthwhile to consider the fact that the C library stdio facility does
14991 not permit whitespace embedded in numbers and neither does the C or
14992 C++ core language (the syntax of integer-literals is given in 2.13.1
14993 [lex.icon], that of floating-point-literals in 2.13.3 [lex.fcon] of the
14994 C++ standard).
14995 </p>
14996
14997
14998 <p><b>Proposed resolution:</b></p>
14999 <p>Change the first part of 22.2.3.1 [locale.numpunct] paragraph 2 from:</p>
15000 <blockquote>
15001 <p>
15002 The syntax for number formats is as follows, where <tt>digit</tt>
15003 represents the radix set specified by the <tt>fmtflags</tt> argument
15004 value, <tt>whitespace</tt> is as determined by the facet
15005 <tt>ctype&lt;charT&gt;</tt> (22.2.1.1), and <tt>thousands-sep</tt> and
15006 <tt>decimal-point</tt> are the results of corresponding
15007 <tt>numpunct&lt;charT&gt;</tt> members.  Integer values have the
15008 format:
15009 </p>
15010 <pre>  integer   ::= [sign] units
15011   sign      ::= plusminus [whitespace]
15012   plusminus ::= '+' | '-'
15013   units     ::= digits [thousands-sep units]
15014   digits    ::= digit [digits]
15015 </pre>
15016 </blockquote>
15017 <p>to:</p>
15018 <blockquote>
15019 <p>
15020 The syntax for number formats is as follows, where <tt>digit</tt>
15021 represents the radix set specified by the <tt>fmtflags</tt> argument
15022 value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
15023 results of corresponding <tt>numpunct&lt;charT&gt;</tt> members.
15024 Integer values have the format:
15025 </p>
15026 <pre>  integer   ::= [sign] units
15027   sign      ::= plusminus
15028   plusminus ::= '+' | '-'
15029   units     ::= digits [thousands-sep units]
15030   digits    ::= digit [digits]
15031 </pre>
15032 </blockquote>
15033
15034
15035 <p><b>Rationale:</b></p>
15036 <p>It's not clear whether the format described in 22.2.3.1 [locale.numpunct] paragraph 2 has any normative weight: nothing in the
15037 standard says how, or whether, it's used.  However, there's no reason
15038 for it to differ gratuitously from the very specific description of
15039 numeric processing in 22.2.2.1.2 [facet.num.get.virtuals].  The proposed
15040 resolution removes all mention of "whitespace" from that format.</p>
15041
15042
15043
15044
15045
15046 <hr>
15047 <h3><a name="339"></a>339. definition of bitmask type restricted to clause 27</h3>
15048 <p><b>Section:</b> 22.2.1 [category.ctype], 17.3.2.1.2 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15049  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-09-17</p>
15050 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#category.ctype">issues</a> in [category.ctype].</p>
15051 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15052 <p><b>Discussion:</b></p>
15053 <p>The ctype_category::mask type is declared to be an enum in 22.2.1
15054 [category.ctype] with p1 then stating that it is a bitmask type, most
15055 likely referring to the definition of bitmask type in 17.3.2.1.2
15056 [bitmask.types], p1. However, the said definition only applies to
15057 clause 27, making the reference in 22.2.1 somewhat dubious.
15058 </p>
15059
15060
15061 <p><b>Proposed resolution:</b></p>
15062 <p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
15063     <blockquote><p>
15064     Several types defined in clause 27 are bitmask types. Each bitmask type
15065     can be implemented as an enumerated type that overloads certain operators,
15066     as an integer type, or as a bitset (23.3.5 [template.bitset]).
15067     </p></blockquote>
15068 <p>to read</p>
15069     <blockquote><p>
15070     Several types defined in clauses lib.language.support through
15071     lib.input.output and Annex D are bitmask types. Each bitmask type can
15072     be implemented as an enumerated type that overloads certain operators,
15073     as an integer  type, or as a bitset (lib.template.bitset).
15074     </p></blockquote>
15075
15076 <p>
15077 Additionally, change the definition in 22.2.1 to adopt the same
15078 convention as in clause 27 by replacing the existing text with the
15079 following (note, in particluar, the cross-reference to 17.3.2.1.2 in
15080 22.2.1, p1):
15081 </p>
15082
15083 <blockquote>
15084 <p>22.2.1 The ctype category [lib.category.ctype]</p>
15085 <pre>namespace std {
15086     class ctype_base {
15087     public:
15088         typedef <b><i>T</i></b> mask;
15089
15090         // numeric values are for exposition only.
15091         static const mask space = 1 &lt;&lt; 0;
15092         static const mask print = 1 &lt;&lt; 1;
15093         static const mask cntrl = 1 &lt;&lt; 2;
15094         static const mask upper = 1 &lt;&lt; 3;
15095         static const mask lower = 1 &lt;&lt; 4;
15096         static const mask alpha = 1 &lt;&lt; 5;
15097         static const mask digit = 1 &lt;&lt; 6;
15098         static const mask punct = 1 &lt;&lt; 7;
15099         static const mask xdigit = 1 &lt;&lt; 8;
15100         static const mask alnum = alpha | digit;
15101         static const mask graph = alnum | punct;
15102     };
15103 }
15104 </pre>
15105
15106 <p>The type <tt>mask</tt> is a bitmask type (17.3.2.1.2 [bitmask.types]).</p>
15107 </blockquote>
15108
15109 <p><i>[Curaçao: The LWG notes that T above should be bold-italics to be
15110 consistent with the rest of the standard.]</i></p>
15111
15112
15113
15114
15115
15116
15117
15118
15119
15120 <hr>
15121 <h3><a name="340"></a>340. interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt></h3>
15122 <p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15123  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-09-18</p>
15124 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
15125 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15126 <p><b>Discussion:</b></p>
15127 <p>
15128 It's unclear whether 22.1.1.1.1, p3 says that
15129 <tt>has_facet&lt;Facet&gt;(loc)</tt> returns true for any <tt>Facet</tt>
15130 from Table 51 or whether it includes Table 52 as well:
15131 </p>
15132
15133 <blockquote><p>
15134 For any locale <tt>loc</tt> either constructed, or returned by
15135 locale::classic(), and any facet <tt>Facet</tt> that is a member of a
15136 standard category, <tt>has_facet&lt;Facet&gt;(loc)</tt> is true. Each
15137 locale member function which takes a <tt>locale::category</tt>
15138 argument operates on the corresponding set of facets.
15139 </p></blockquote>
15140
15141 <p>
15142 It seems that it comes down to which facets are considered to be members of a
15143 standard category. Intuitively, I would classify all the facets in Table 52 as
15144 members of their respective standard categories, but there are an unbounded set
15145 of them...
15146 </p>
15147
15148 <p>
15149 The paragraph implies that, for instance, <tt>has_facet&lt;num_put&lt;C,
15150 OutputIterator&gt; &gt;(loc)</tt> must always return true. I don't think that's
15151 possible. If it were, then <tt>use_facet&lt;num_put&lt;C, OutputIterator&gt;
15152 &gt;(loc)</tt> would have to return a reference to a distinct object for each
15153 valid specialization of <tt>num_put&lt;C, OutputIteratory&gt;</tt>, which is
15154 clearly impossible.
15155 </p>
15156
15157 <p>
15158 On the other hand, if none of the facets in Table 52 is a member of a standard
15159 category then none of the locale member functions that operate on entire
15160 categories of facets will work properly.
15161 </p>
15162
15163 <p>
15164 It seems that what p3 should mention that it's required (permitted?)
15165 to hold only for specializations of <tt>Facet</tt> from Table 52 on
15166 <tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
15167 <tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
15168 {
15169 {i,o}<tt>streambuf_iterator</tt>&lt;{<tt>char</tt>,<tt>wchar_t</tt>}<tt>&gt;</tt>
15170 }.
15171 </p>
15172
15173
15174 <p><b>Proposed resolution:</b></p>
15175 <p>In 22.1.1.1.1 [locale.category], paragraph 3, change
15176 "that is a member of a standard category" to "shown in Table 51".</p>
15177
15178
15179 <p><b>Rationale:</b></p>
15180 <p>The facets in Table 52 are an unbounded set.  Locales should not be
15181 required to contain an infinite number of facets.</p>
15182
15183 <p>It's not necessary to talk about which values of InputIterator and
15184 OutputIterator must be supported.  Table 51 already contains a
15185 complete list of the ones we need.</p>
15186
15187
15188
15189
15190
15191
15192 <hr>
15193 <h3><a name="341"></a>341. Vector reallocation and swap</h3>
15194 <p><b>Section:</b> 23.2.5.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15195  <b>Submitter:</b> Anthony Williams <b>Date:</b> 2001-09-27</p>
15196 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
15197 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15198 <p><b>Discussion:</b></p>
15199 <p>It is a common idiom to reduce the capacity of a vector by swapping it with
15200 an empty one:</p>
15201 <pre>  std::vector&lt;SomeType&gt; vec;
15202   // fill vec with data
15203   std::vector&lt;SomeType&gt;().swap(vec);
15204   // vec is now empty, with minimal capacity
15205 </pre>
15206
15207 <p>However, the wording of 23.2.5.2 [vector.capacity]paragraph 5 prevents
15208 the capacity of a vector being reduced, following a call to
15209 reserve(). This invalidates the idiom, as swap() is thus prevented
15210 from reducing the capacity. The proposed wording for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a> does not affect this.  Consequently, the example above
15211 requires the temporary to be expanded to cater for the contents of
15212 vec, and the contents be copied across. This is a linear-time
15213 operation.</p>
15214
15215 <p>However, the container requirements state that swap must have constant
15216 complexity (23.1 [container.requirements] note to table 65).</p>
15217
15218 <p>This is an important issue, as reallocation affects the validity of
15219 references and iterators.</p>
15220
15221 <p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
15222 references and iterators remain valid after a call to swap, if they refer to
15223 an element before the new end() of the vector into which they originally
15224 pointed, in which case they refer to the element at the same index position.
15225 Iterators and references that referred to an element whose index position
15226 was beyond the new end of the vector are invalidated.</p>
15227
15228 <p>If the note to table 65 is taken as the desired intent, then there are two
15229 possibilities with regard to iterators and references:</p>
15230
15231 <ol>
15232 <li>All Iterators and references into both vectors are invalidated.</li>
15233 <li>Iterators and references into either vector remain valid, and remain
15234 pointing to the same element. Consequently iterators and references that
15235 referred to one vector now refer to the other, and vice-versa.</li>
15236 </ol>
15237
15238
15239 <p><b>Proposed resolution:</b></p>
15240 <p>Add a new paragraph after 23.2.5.2 [vector.capacity] paragraph 5:</p>
15241 <blockquote>
15242 <pre>  void swap(vector&lt;T,Allocator&gt;&amp; x);
15243 </pre>
15244 <p><b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
15245 with that of <tt>x</tt>.</p>
15246 <p><b>Complexity:</b> Constant time.</p>
15247 </blockquote>
15248
15249 <p><i>[This solves the problem reported for this issue.  We may also
15250 have a problem with a circular definition of swap() for other
15251 containers.]</i></p>
15252
15253
15254
15255
15256 <p><b>Rationale:</b></p>
15257 <p>
15258 swap should be constant time.  The clear intent is that it should just
15259 do pointer twiddling, and that it should exchange all properties of
15260 the two vectors, including their reallocation guarantees.
15261 </p>
15262
15263
15264
15265
15266
15267 <hr>
15268 <h3><a name="345"></a>345. type tm in &lt;cwchar&gt;</h3>
15269 <p><b>Section:</b> 21.4 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15270  <b>Submitter:</b> Clark Nelson <b>Date:</b> 2001-10-19</p>
15271 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.strings">issues</a> in [c.strings].</p>
15272 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15273 <p><b>Discussion:</b></p>
15274 <p>C99, and presumably amendment 1 to C90, specify that &lt;wchar.h&gt;
15275 declares struct tm as an incomplete type. However, table 48 in 21.4
15276 [c.strings] does not mention the type tm as being declared in
15277 &lt;cwchar&gt;. Is this omission intentional or accidental?
15278 </p>
15279
15280
15281 <p><b>Proposed resolution:</b></p>
15282 <p>In section 21.4 [c.strings], add "tm" to table 48.</p>
15283
15284
15285
15286
15287
15288 <hr>
15289 <h3><a name="346"></a>346. Some iterator member functions should be const</h3>
15290 <p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15291  <b>Submitter:</b> Jeremy Siek <b>Date:</b> 2001-10-20</p>
15292 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
15293 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
15294 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15295 <p><b>Discussion:</b></p>
15296 <p>Iterator member functions and operators that do not change the state
15297 of the iterator should be defined as const member functions or as
15298 functions that take iterators either by const reference or by
15299 value. The standard does not explicitly state which functions should
15300 be const.  Since this a fairly common mistake, the following changes
15301 are suggested to make this explicit.</p>
15302
15303 <p>The tables almost indicate constness properly through naming: r
15304 for non-const and a,b for const iterators. The following changes
15305 make this more explicit and also fix a couple problems.</p>
15306
15307
15308 <p><b>Proposed resolution:</b></p>
15309 <p>In 24.1 [iterator.requirements] Change the first section of p9 from
15310 "In the following sections, a and b denote values of X..." to
15311 "In the following sections, a and b denote values of type const X...".</p>
15312
15313 <p>In Table 73, change</p>
15314 <pre>    a-&gt;m   U&amp;         ...
15315 </pre>
15316
15317 <p>to</p>
15318
15319 <pre>    a-&gt;m   const U&amp;   ...
15320     r-&gt;m   U&amp;         ...
15321 </pre>
15322
15323 <p>In Table 73 expression column, change</p>
15324
15325 <pre>    *a = t
15326 </pre>
15327
15328 <p>to</p>
15329
15330 <pre>    *r = t
15331 </pre>
15332
15333 <p><i>[Redmond: The container requirements should be reviewed to see if
15334 the same problem appears there.]</i></p>
15335
15336
15337
15338
15339
15340
15341
15342 <hr>
15343 <h3><a name="347"></a>347. locale::category and bitmask requirements</h3>
15344 <p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15345  <b>Submitter:</b> P.J. Plauger, Nathan Myers <b>Date:</b> 2001-10-23</p>
15346 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
15347 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15348 <p><b>Discussion:</b></p>
15349 <p>
15350 In 22.1.1.1.1 [locale.category] paragraph 1, the category members
15351 are described as bitmask elements.  In fact, the bitmask requirements
15352 in 17.3.2.1.2 [bitmask.types] don't seem quite right: <tt>none</tt>
15353 and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
15354
15355 <p>In particular, the requirements for <tt>none</tt> interact poorly
15356 with the requirement that the LC_* constants from the C library must
15357 be recognizable as C++ locale category constants.  LC_* values should
15358 not be mixed with these values to make category values.</p>
15359
15360 <p>We have two options for the proposed resolution.  Informally:
15361 option 1 removes the requirement that LC_* values be recognized as
15362 category arguments.  Option 2 changes the category type so that this
15363 requirement is implementable, by allowing <tt>none</tt> to be some
15364 value such as 0x1000 instead of 0.</p>
15365
15366 <p>Nathan writes: "I believe my proposed resolution [Option 2] merely
15367 re-expresses the status quo more clearly, without introducing any
15368 changes beyond resolving the DR.</p>
15369
15370
15371
15372 <p><b>Proposed resolution:</b></p>
15373 <p>Replace the first two paragraphs of 22.1.1.1 [locale.types] with:</p>
15374 <blockquote>
15375 <pre>    typedef int category;
15376 </pre>
15377
15378 <p>Valid category values include the <tt>locale</tt> member bitmask
15379 elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
15380 <tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
15381 represents a single locale category. In addition, <tt>locale</tt> member
15382 bitmask constant <tt>none</tt> is defined as zero and represents no
15383 category. And locale member bitmask constant <tt>all</tt> is defined such that
15384 the expression</p>
15385 <pre>    (collate | ctype | monetary | numeric | time | messages | all) == all
15386 </pre>
15387 <p>
15388 is <tt>true</tt>, and represents the union of all categories.  Further
15389 the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
15390 represent a single category, represents the union of the two
15391 categories.
15392 </p>
15393
15394 <p>
15395 <tt>locale</tt> member functions expecting a <tt>category</tt>
15396 argument require one of the <tt>category</tt> values defined above, or
15397 the union of two or more such values. Such a <tt>category</tt>
15398 argument identifies a set of locale categories. Each locale category,
15399 in turn, identifies a set of locale facets, including at least those
15400 shown in Table 51:
15401 </p>
15402 </blockquote>
15403 <p><i>[Curaçao: need input from locale experts.]</i></p>
15404
15405
15406
15407
15408 <p><b>Rationale:</b></p>
15409
15410 <p>The LWG considered, and rejected, an alternate proposal (described
15411   as "Option 2" in the discussion).  The main reason for rejecting it
15412   was that library implementors were concerened about implementation
15413   difficult, given that getting a C++ library to work smoothly with a
15414   separately written C library is already a delicate business.  Some
15415   library implementers were also concerned about the issue of adding
15416   extra locale categories.</p>
15417
15418 <blockquote>
15419 <p><b>Option 2:</b> <br>
15420 Replace the first paragraph of 22.1.1.1 [locale.types] with:</p>
15421 <blockquote>
15422 <p>
15423 Valid category values include the enumerated values.  In addition, the
15424 result of applying commutative operators | and &amp; to any two valid
15425 values is valid, and results in the setwise union and intersection,
15426 respectively, of the argument categories.  The values <tt>all</tt> and
15427 <tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
15428 expressions <tt>(cat | all == all)</tt>, <tt>(cat &amp; all == cat)</tt>,
15429 <tt>(cat | none == cat)</tt> and <tt>(cat &amp; none == none)</tt> are
15430 true.  For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
15431 remaining enumerated values, <tt>(cat1 &amp; cat2 == none)</tt> is true.
15432 For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
15433 of <tt>(cat1 &amp; ~cat2)</tt> is valid, and equals the setwise union of
15434 those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
15435 [Footnote: it is not required that <tt>all</tt> equal the setwise union
15436 of the other enumerated values; implementations may add extra categories.]
15437 </p>
15438 </blockquote>
15439 </blockquote>
15440
15441
15442
15443
15444
15445 <hr>
15446 <h3><a name="349"></a>349. Minor typographical error in ostream_iterator</h3>
15447 <p><b>Section:</b> 24.5.2 [ostream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15448  <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-10-24</p>
15449 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15450 <p><b>Discussion:</b></p>
15451 <p>24.5.2 [lib.ostream.iterator] states:</p>
15452 <pre>    [...]
15453
15454     private:
15455     // basic_ostream&lt;charT,traits&gt;* out_stream; exposition only
15456     // const char* delim; exposition only
15457 </pre>
15458
15459 <p>Whilst it's clearly marked "exposition only", I suspect 'delim'
15460 should be of type 'const charT*'.</p>
15461
15462
15463 <p><b>Proposed resolution:</b></p>
15464 <p>
15465 In 24.5.2 [ostream.iterator], replace <tt>const char* delim</tt> with
15466 <tt>const charT* delim</tt>.
15467 </p>
15468
15469
15470
15471
15472
15473 <hr>
15474 <h3><a name="352"></a>352. missing fpos requirements</h3>
15475 <p><b>Section:</b> 21.1.2 [char.traits.typedefs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15476  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-12-02</p>
15477 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15478 <p><b>Discussion:</b></p>
15479 <p>
15480 <i>(1)</i>
15481 There are no requirements on the <tt>stateT</tt> template parameter of
15482 <tt>fpos</tt> listed in 27.4.3. The interface appears to require that
15483 the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
15484 and I think also DefaultConstructible (to implement the operations in
15485 Table 88).
15486 </p>
15487 <p>
15488 21.1.2, p3, however, only requires that
15489 <tt>char_traits&lt;charT&gt;::state_type</tt> meet the requirements of
15490 CopyConstructible types.
15491 </p>
15492 <p>
15493 <i>(2)</i>
15494 Additionally, the <tt>stateT</tt> template argument has no
15495 corresponding typedef in fpos which might make it difficult to use in
15496 generic code.
15497 </p>
15498
15499
15500 <p><b>Proposed resolution:</b></p>
15501 <p>
15502 Modify 21.1.2, p4 from
15503 </p>
15504 <p>
15505     Requires: <tt>state_type</tt> shall meet the requirements of
15506               CopyConstructible types (20.1.3).
15507 </p>
15508 <p>
15509     Requires: state_type shall meet the requirements of Assignable
15510               (23.1, p4), CopyConstructible (20.1.3), and
15511               DefaultConstructible  (20.1.4) types.
15512 </p>
15513
15514
15515
15516 <p><b>Rationale:</b></p>
15517 <p>The LWG feels this is two issues, as indicated above. The first is
15518 a defect---std::basic_fstream is unimplementable without these
15519 additional requirements---and the proposed resolution fixes it.  The
15520 second is questionable; who would use that typedef?  The class
15521 template fpos is used only in a very few places, all of which know the
15522 state type already.  Unless motivation is provided, the second should
15523 be considered NAD.</p>
15524
15525
15526
15527
15528
15529 <hr>
15530 <h3><a name="354"></a>354. Associative container lower/upper bound requirements</h3>
15531 <p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15532  <b>Submitter:</b> Hans Aberg <b>Date:</b> 2001-12-17</p>
15533 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
15534 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15535 <p><b>Discussion:</b></p>
15536 <p>
15537 Discussions in the thread "Associative container lower/upper bound
15538 requirements" on comp.std.c++ suggests that there is a defect in the
15539 C++ standard, Table 69 of section 23.1.2, "Associative containers",
15540 [lib.associative.reqmts].  It currently says:</p>
15541
15542 <blockquote>
15543 <p>
15544 a.find(k): returns an iterator pointing to an element with the key equivalent to
15545 k, or a.end() if such an element is not found.
15546 </p>
15547
15548 <p>
15549 a.lower_bound(k): returns an iterator pointing to the first element with
15550 key not less than k.
15551 </p>
15552
15553 <p>
15554 a.upper_bound(k): returns an iterator pointing to the first element with
15555 key greater than k.
15556 </p>
15557 </blockquote>
15558
15559 <p>
15560 We have "or a.end() if such an element is not found" for
15561 <tt>find</tt>, but not for <tt>upper_bound</tt> or
15562 <tt>lower_bound</tt>.  As the text stands, one would be forced to
15563 insert a new element into the container and return an iterator to that
15564 in case the sought iterator does not exist, which does not seem to be
15565 the intention (and not possible with the "const" versions).
15566 </p>
15567
15568
15569 <p><b>Proposed resolution:</b></p>
15570
15571 <p>Change Table 69 of section 23.1.2 [associative.reqmts] indicated entries
15572 to:</p>
15573
15574 <blockquote>
15575 <p>
15576 a.lower_bound(k): returns an iterator pointing to the first element with
15577 key not less than k, or a.end() if such an element is not found.
15578 </p>
15579
15580 <p>
15581 a.upper_bound(k): returns an iterator pointing to the first element with
15582 key greater than k, or a.end() if such an element is not found.
15583 </p>
15584 </blockquote>
15585
15586 <p><i>[Curaçao: LWG reviewed PR.]</i></p>
15587
15588
15589
15590
15591
15592
15593
15594
15595 <hr>
15596 <h3><a name="355"></a>355. Operational semantics for a.back()</h3>
15597 <p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15598  <b>Submitter:</b> Yaroslav Mironov <b>Date:</b> 2002-01-23</p>
15599 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
15600 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15601 <p><b>Discussion:</b></p>
15602
15603 <p>Table 68 "Optional Sequence Operations" in 23.1.1/12
15604 specifies operational semantics for "a.back()" as
15605 "*--a.end()", which may be ill-formed <i>[because calling
15606 operator-- on a temporary (the return) of a built-in type is
15607 ill-formed]</i>, provided a.end() returns a simple pointer rvalue
15608 (this is almost always the case for std::vector::end(), for
15609 example). Thus, the specification is not only incorrect, it
15610 demonstrates a dangerous construct: "--a.end()" may
15611 successfully compile and run as intended, but after changing the type
15612 of the container or the mode of compilation it may produce
15613 compile-time error. </p>
15614
15615
15616
15617 <p><b>Proposed resolution:</b></p>
15618 <p>Change the specification in table 68 "Optional Sequence
15619 Operations" in 23.1.1/12 for "a.back()" from</p>
15620
15621
15622 <blockquote><pre>*--a.end()
15623 </pre></blockquote>
15624
15625 <p>to</p>
15626
15627 <blockquote><pre>  { iterator tmp = a.end(); --tmp; return *tmp; }
15628 </pre></blockquote>
15629
15630 <p>and the specification for "a.pop_back()" from</p>
15631
15632 <blockquote><pre>a.erase(--a.end())
15633 </pre></blockquote>
15634
15635 <p>to</p>
15636
15637 <blockquote><pre>  { iterator tmp = a.end(); --tmp; a.erase(tmp); }
15638 </pre></blockquote>
15639
15640 <p><i>[Curaçao: LWG changed PR from "{ X::iterator tmp =
15641 a.end(); return *--tmp; }" to "*a.rbegin()", and from
15642 "{ X::iterator tmp = a.end(); a.erase(--tmp); }" to
15643 "a.erase(rbegin())".]</i></p>
15644
15645
15646 <p><i>[There is a second possible defect; table 68 "Optional
15647 Sequence Operations" in the "Operational Semantics"
15648 column uses operations present only in the "Reversible
15649 Container" requirements, yet there is no stated dependency
15650 between these separate requirements tables. Ask in Santa Cruz if the
15651 LWG would like a new issue opened.]</i></p>
15652
15653
15654 <p><i>[Santa Cruz: the proposed resolution is even worse than what's in
15655   the current standard: erase is undefined for reverse iterator.  If
15656   we're going to make the change, we need to define a temporary and
15657   use operator--.  Additionally, we don't know how prevalent this is:
15658   do we need to make this change in more than one place?  Martin has
15659   volunteered to review the standard and see if this problem occurs
15660   elsewhere.]</i></p>
15661
15662
15663 <p><i>[Oxford: Matt provided new wording to address the concerns raised
15664   in Santa Cruz.  It does not appear that this problem appears
15665   anywhere else in clauses 23 or 24.]</i></p>
15666
15667
15668 <p><i>[Kona: In definition of operational semantics of back(), change
15669 "*tmp" to "return *tmp;"]</i></p>
15670
15671
15672
15673
15674
15675
15676
15677 <hr>
15678 <h3><a name="358"></a>358. interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt></h3>
15679 <p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15680  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
15681 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
15682 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
15683 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15684 <p><b>Discussion:</b></p>
15685 <p>
15686 I don't think <tt>thousands_sep</tt> is being treated correctly after
15687 decimal_point has been seen. Since grouping applies only to the
15688 integral part of the number, the first such occurrence should, IMO,
15689 terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
15690 and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
15691 interpreted in the fractional part of a number.)
15692 </p>
15693
15694 <p>
15695 The easiest change I can think of that resolves this issue would be
15696 something like below.
15697 </p>
15698
15699
15700 <p><b>Proposed resolution:</b></p>
15701 <p>
15702 Change the first sentence of 22.2.2.1.2, p9 from
15703 </p>
15704
15705 <blockquote><p>
15706     If discard is true then the position of the character is
15707     remembered, but the character is otherwise ignored. If it is not
15708     discarded, then a check is made to determine if c is allowed as
15709     the next character of an input field of the conversion specifier
15710     returned by stage 1. If so it is accumulated.
15711 </p></blockquote>
15712
15713 <p>to</p>
15714
15715 <blockquote><p>
15716     If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
15717     accumulated, then the position of the character is remembered, but
15718     the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
15719     already been accumulated, the character is discarded and Stage 2
15720      terminates. ...
15721 </p></blockquote>
15722
15723
15724
15725 <p><b>Rationale:</b></p>
15726 <p>We believe this reflects the intent of the Standard.  Thousands sep
15727   characters after the decimal point are not useful in any locale.
15728   Some formatting conventions do group digits that follow the decimal
15729   point, but they usually introduce a different grouping character
15730   instead of reusing the thousand sep character.  If we want to add
15731   support for such conventions, we need to do so explicitly.</p>
15732
15733
15734
15735
15736
15737
15738 <hr>
15739 <h3><a name="359"></a>359. num_put&lt;&gt;::do_put (..., bool) undocumented</h3>
15740 <p><b>Section:</b> 22.2.2.2.1 [facet.num.put.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15741  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
15742 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15743 <p><b>Discussion:</b></p>
15744 <p>22.2.2.2.1, p1:</p>
15745
15746     <pre>    iter_type put (iter_type out, ios_base&amp; str, char_type fill,
15747                    bool val) const;
15748     ...
15749
15750     1   Returns: do_put (out, str, fill, val).
15751     </pre>
15752
15753 <p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
15754 however, 22.2.2.2.2, p23:</p>
15755
15756 <blockquote>
15757 <pre>iter_type put (iter_type out, ios_base&amp; str, char_type fill,
15758                bool val) const;
15759 </pre>
15760
15761
15762         <p>Effects: If (str.flags() &amp; ios_base::boolalpha) == 0 then do
15763              out = do_put(out, str, fill, (int)val)
15764            Otherwise do</p>
15765 <pre>             string_type s =
15766                  val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
15767                      : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
15768 </pre>
15769            <p>and then insert the characters of s into out. <i>out</i>.</p>
15770 </blockquote>
15771
15772 <p>
15773 This means that the bool overload of <tt>do_put()</tt> will never be called,
15774 which contradicts the first paragraph. Perhaps the declaration
15775 should read <tt>do_put()</tt>, and not <tt>put()</tt>?
15776 </p>
15777
15778 <p>
15779 Note also that there is no <b>Returns</b> clause for this function, which
15780 should probably be corrected, just as should the second occurrence
15781 of <i>"out."</i> in the text.
15782 </p>
15783
15784 <p>
15785 I think the least invasive change to fix it would be something like
15786 the following:
15787 </p>
15788
15789
15790 <p><b>Proposed resolution:</b></p>
15791 <p>In 22.2.2.2.2 [facet.num.put.virtuals], just above paragraph 1, remove
15792   the <tt>bool</tt> overload.</p>
15793
15794 <p>
15795 In 22.2.2.2.2 [facet.num.put.virtuals], p23, make the following changes
15796 </p>
15797
15798 <blockquote><p>
15799      Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
15800      of the member function.
15801 </p></blockquote>
15802
15803 <blockquote><p>
15804     Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
15805     avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
15806     do_put (..., bool))</tt>
15807     like so:
15808 </p></blockquote>
15809
15810 <blockquote><p>
15811     23   <b>Returns</b>: If <tt>(str.flags() &amp;
15812          ios_base::boolalpha) == 0</tt> then
15813          <tt>do_put (out, str, fill, (long)val)</tt>
15814          Otherwise the function obtains a string <tt>s</tt> as if by</p>
15815 <pre>             string_type s =
15816                 val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
15817                     : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
15818 </pre>
15819          <p>and then inserts each character <tt>c</tt> of s into out via
15820            <tt>*out++ = c</tt>
15821          and returns <tt>out</tt>.</p>
15822 </blockquote>
15823
15824
15825
15826 <p><b>Rationale:</b></p><p>
15827 This fixes a couple of obvious typos, and also fixes what appears to
15828 be a requirement of gratuitous inefficiency.
15829 </p>
15830
15831
15832
15833
15834 <hr>
15835 <h3><a name="360"></a>360. locale mandates inefficient implementation</h3>
15836 <p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15837  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
15838 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
15839 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15840 <p><b>Discussion:</b></p>
15841 <p>
15842 22.1.1, p7 (copied below) allows iostream formatters and extractors
15843 to make assumptions about the values returned from facet members.
15844 However, such assumptions are apparently not guaranteed to hold
15845 in other cases (e.g., when the facet members are being called directly
15846 rather than as a result of iostream calls, or between successive
15847 calls to the same iostream functions with no interevening calls to
15848 <tt>imbue()</tt>, or even when the facet member functions are called
15849 from other member functions of other facets). This restriction
15850 prevents locale from being implemented efficiently.
15851 </p>
15852
15853
15854 <p><b>Proposed resolution:</b></p>
15855 <p>Change the first sentence in 22.1.1, p7 from</p>
15856 <blockquote><p>
15857     In successive calls to a locale facet member function during
15858     a call to an iostream inserter or extractor or a streambuf member
15859     function, the returned result shall be identical. [Note: This
15860     implies that such results may safely be reused without calling
15861     the locale facet member function again, and that member functions
15862     of iostream classes cannot safely call <tt>imbue()</tt>
15863     themselves, except as specified elsewhere. --end note]
15864 </p></blockquote>
15865
15866 <p>to</p>
15867
15868 <blockquote><p>
15869     In successive calls to a locale facet member function on a facet
15870     object installed in the same locale, the returned result shall be
15871     identical. ...
15872 </p></blockquote>
15873
15874
15875
15876 <p><b>Rationale:</b></p>
15877 <p>This change is reasonable becuase it clarifies the intent of this
15878   part of the standard.</p>
15879
15880
15881
15882
15883
15884 <hr>
15885 <h3><a name="362"></a>362. bind1st/bind2nd type safety</h3>
15886 <p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15887  <b>Submitter:</b> Andrew Demkin <b>Date:</b> 2002-04-26</p>
15888 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
15889 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15890 <p><b>Discussion:</b></p>
15891 <p>
15892 The definition of bind1st() (D.8 [depr.lib.binders]) can result in
15893 the construction of an unsafe binding between incompatible pointer
15894 types. For example, given a function whose first parameter type is
15895 'pointer to T', it's possible without error to bind an argument of
15896 type 'pointer to U' when U does not derive from T:
15897 </p>
15898 <pre>   foo(T*, int);
15899
15900    struct T {};
15901    struct U {};
15902
15903    U u;
15904
15905    int* p;
15906    int* q;
15907
15908    for_each(p, q, bind1st(ptr_fun(foo), &amp;u));    // unsafe binding
15909 </pre>
15910
15911 <p>
15912 The definition of bind1st() includes a functional-style conversion to
15913 map its argument to the expected argument type of the bound function
15914 (see below):
15915 </p>
15916 <pre>  typename Operation::first_argument_type(x)
15917 </pre>
15918
15919 <p>A functional-style conversion (D.8 [depr.lib.binders]) is defined to
15920 be
15921 semantically equivalent to an explicit cast expression (D.8
15922 [depr.lib.binders]), which may (according to 5.4, paragraph 5) be
15923 interpreted
15924 as a reinterpret_cast, thus masking the error.
15925 </p>
15926
15927 <p>The problem and proposed change also apply to D.8 [depr.lib.binders].</p>
15928
15929
15930 <p><b>Proposed resolution:</b></p>
15931 <p>Add this sentence to the end of D.8 [depr.lib.binders]/1:
15932   "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in
15933   favor of <tt>std::tr1::bind</tt>."</p>
15934
15935 <p>(Notes to editor: (1) when and if tr1::bind is incorporated into
15936   the standard, "std::tr1::bind" should be changed to "std::bind". (2)
15937   20.5.6 should probably be moved to Annex D.</p>
15938
15939
15940 <p><b>Rationale:</b></p>
15941 <p>There is no point in fixing bind1st and bind2nd.  tr1::bind is a
15942   superior solution.  It solves this problem and others.</p>
15943
15944
15945
15946
15947
15948 <hr>
15949 <h3><a name="363"></a>363. Missing exception specification in 27.4.2.1.1</h3>
15950 <p><b>Section:</b> 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15951  <b>Submitter:</b> Walter Brown and Marc Paterno <b>Date:</b> 2002-05-20</p>
15952 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</p>
15953 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15954 <p><b>Discussion:</b></p>
15955 <p>
15956 The destructor of ios_base::failure should have an empty throw
15957 specification, because the destructor of its base class, exception, is
15958 declared in this way.
15959 </p>
15960
15961
15962 <p><b>Proposed resolution:</b></p>
15963 <p>Change the destructor to</p>
15964 <pre>  virtual ~failure() throw();
15965 </pre>
15966
15967
15968 <p><b>Rationale:</b></p>
15969 <p>Fixes an obvious glitch.  This is almost editorial.</p>
15970
15971
15972
15973
15974
15975 <hr>
15976 <h3><a name="364"></a>364. Inconsistent wording in 27.5.2.4.2</h3>
15977 <p><b>Section:</b> 27.5.2.4.2 [streambuf.virt.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15978  <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 2002-05-10</p>
15979 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.virt.buffer">issues</a> in [streambuf.virt.buffer].</p>
15980 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15981 <p><b>Discussion:</b></p>
15982 <p>
15983 27.5.2.4.2 [streambuf.virt.buffer] paragraph 1 is inconsistent with the Effects
15984 clause for seekoff.
15985 </p>
15986
15987
15988 <p><b>Proposed resolution:</b></p>
15989 <p>
15990 Make this paragraph, the Effects clause for setbuf, consistent in wording
15991 with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
15992 to indicate the purpose of setbuf:
15993 </p>
15994
15995 <p>Original text:</p>
15996
15997 <blockquote><p>
15998 1 Effects: Performs an operation that is defined separately for each
15999 class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
16000 </p></blockquote>
16001
16002 <p>Proposed text:</p>
16003
16004 <blockquote><p>
16005 1 Effects: Influences stream buffering in a way that is defined separately
16006 for each class derived from basic_streambuf in this clause
16007 (27.7.1.3, 27.8.1.4).
16008 </p></blockquote>
16009
16010
16011
16012 <p><b>Rationale:</b></p>
16013 <p>The LWG doesn't believe there is any normative difference between
16014   the existing wording and what's in the proposed resolution, but the
16015   change may make the intent clearer.</p>
16016
16017
16018
16019
16020
16021 <hr>
16022 <h3><a name="365"></a>365. Lack of const-qualification in clause 27</h3>
16023 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16024  <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 2002-05-10</p>
16025 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
16026 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16027 <p><b>Discussion:</b></p>
16028 <p>
16029 Some stream and streambuf member functions are declared non-const,
16030 even thought they appear only to report information rather than to
16031 change an object's logical state.  They should be declared const.  See
16032 document N1360 for details and rationale.
16033 </p>
16034
16035 <p>The list of member functions under discussion: <tt>in_avail</tt>,
16036 <tt>showmanyc</tt>, <tt>tellg</tt>, <tt>tellp</tt>, <tt>is_open</tt>.</p>
16037
16038 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a></p>
16039
16040
16041
16042 <p><b>Proposed resolution:</b></p>
16043 <p>In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p>
16044 <p>Replace</p>
16045 <pre>  bool is_open();
16046 </pre>
16047 <p>with</p>
16048 <pre>  bool is_open() const;
16049 </pre>
16050
16051
16052 <p><b>Rationale:</b></p>
16053 <p>Of the changes proposed in N1360, the only one that is safe is
16054 changing the filestreams' is_open to const.  The LWG believed that
16055 this was NAD the first time it considered this issue (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a>), but now thinks otherwise.  The corresponding streambuf
16056 member function, after all,is already const.</p>
16057
16058 <p>The other proposed changes are less safe, because some streambuf
16059 functions that appear merely to report a value do actually perform
16060 mutating operations.  It's not even clear that they should be
16061 considered "logically const", because streambuf has two interfaces, a
16062 public one and a protected one.  These functions may, and often do,
16063 change the state as exposed by the protected interface, even if the
16064 state exposed by the public interface is unchanged.</p>
16065
16066 <p>Note that implementers can make this change in a binary compatible
16067 way by providing both overloads; this would be a conforming extension.</p>
16068
16069
16070
16071
16072
16073
16074 <hr>
16075 <h3><a name="369"></a>369. io stream objects and static ctors</h3>
16076 <p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16077  <b>Submitter:</b> Ruslan Abdikeev <b>Date:</b> 2002-07-08</p>
16078 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
16079 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16080 <p><b>Discussion:</b></p>
16081 <p>
16082 Is it safe to use standard iostream objects from constructors of
16083 static objects?  Are standard iostream objects constructed and are
16084 their associations established at that time?
16085 </p>
16086
16087 <p>Surpisingly enough, Standard does NOT require that.</p>
16088
16089 <p>
16090 27.3/2 [lib.iostream.objects] guarantees that standard iostream
16091 objects are constructed and their associations are established before
16092 the body of main() begins execution.  It also refers to ios_base::Init
16093 class as the panacea for constructors of static objects.
16094 </p>
16095
16096 <p>
16097 However, there's nothing in 27.3 [lib.iostream.objects],
16098 in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
16099 that would require implementations to allow access to standard
16100 iostream objects from constructors of static objects.
16101 </p>
16102
16103 <p>Details:</p>
16104
16105 <p>Core text refers to some magic object ios_base::Init, which will
16106 be discussed below:</p>
16107
16108 <blockquote><p>
16109     "The [standard iostream] objects are constructed, and their
16110     associations are established at some time prior to or during
16111     first time an object of class basic_ios&lt;charT,traits&gt;::Init
16112     is constructed, and in any case before the body of main
16113     begins execution." (27.3/2 [lib.iostream.objects])
16114 </p></blockquote>
16115
16116 <p>
16117 The first <i>non-normative</i> footnote encourages implementations
16118 to initialize standard iostream objects earlier than required.
16119 </p>
16120
16121 <p>However, the second <i>non-normative</i> footnote makes an explicit
16122 and unsupported claim:</p>
16123
16124 <blockquote><p>
16125   "Constructors and destructors for static objects can access these
16126   [standard iostream] objects to read input from stdin or write output
16127   to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects])
16128 </p></blockquote>
16129
16130 <p>
16131 The only bit of magic is related to that ios_base::Init class.  AFAIK,
16132 the rationale behind ios_base::Init was to bring an instance of this
16133 class to each translation unit which #included &lt;iostream&gt; or
16134 related header.  Such an inclusion would support the claim of footnote
16135 quoted above, because in order to use some standard iostream object it
16136 is necessary to #include &lt;iostream&gt;.
16137 </p>
16138
16139 <p>
16140 However, while Standard explicitly describes ios_base::Init as
16141 an appropriate class for doing the trick, I failed to found a
16142 mention of an _instance_ of ios_base::Init in Standard.
16143 </p>
16144
16145
16146 <p><b>Proposed resolution:</b></p>
16147
16148 <p>Add to 27.3 [iostream.objects], p2, immediately before the last sentence
16149 of the paragraph, the following two sentences:</p>
16150
16151 <blockquote><p>
16152 If a translation unit includes &lt;iostream&gt;, or explicitly
16153 constructs an ios_base::Init object, these stream objects shall
16154 be constructed before dynamic initialization of non-local
16155 objects defined later in that translation unit, and these stream
16156 objects shall be destroyed after the destruction of dynamically
16157 initialized non-local objects defined later in that translation unit.
16158 </p></blockquote>
16159
16160 <p><i>[Lillehammer: Matt provided wording.]</i></p>
16161
16162 <p><i>[Mont Tremblant: Matt provided revised wording.]</i></p>
16163
16164
16165
16166 <p><b>Rationale:</b></p>
16167 <p>
16168 The original proposed resolution unconditionally required
16169 implementations to define an ios_base::Init object of some
16170 implementation-defined name in the header &lt;iostream&gt;. That's an
16171 overspecification. First, defining the object may be unnecessary
16172 and even detrimental to performance if an implementation can
16173 guarantee that the 8 standard iostream objects will be initialized
16174 before any other user-defined object in a program. Second, there
16175 is no need to require implementations to document the name of the
16176 object.</p>
16177
16178 <p>
16179 The new proposed resolution gives users guidance on what they need to
16180 do to ensure that stream objects are constructed during startup.</p>
16181
16182
16183
16184
16185
16186 <hr>
16187 <h3><a name="370"></a>370. Minor error in basic_istream::get</h3>
16188 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16189  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-07-15</p>
16190 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
16191 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
16192 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16193 <p><b>Discussion:</b></p>
16194 <p>Defect report for description of basic_istream::get (section
16195 27.6.1.3 [istream.unformatted]), paragraph 15. The description for the
16196 get function
16197 with the following signature:</p>
16198
16199 <pre>  basic_istream&lt;charT,traits&gt;&amp; get(basic_streambuf&lt;char_type,traits&gt;&amp;
16200   sb);
16201 </pre>
16202
16203 <p>is incorrect. It reads</p>
16204
16205 <blockquote><p>
16206   Effects: Calls get(s,n,widen('\n'))
16207 </p></blockquote>
16208
16209 <p>which I believe should be:</p>
16210
16211 <blockquote><p>
16212   Effects: Calls get(sb,widen('\n'))
16213 </p></blockquote>
16214
16215
16216 <p><b>Proposed resolution:</b></p>
16217 <p>Change the <b>Effects</b> paragraph to:</p>
16218 <blockquote><p>
16219   Effects: Calls get(sb,this-&gt;widen('\n'))
16220 </p></blockquote>
16221
16222 <p><i>[Pre-Oxford: Minor correction from Howard: replaced 'widen'
16223       with 'this-&gt;widen'.]</i></p>
16224
16225
16226
16227
16228 <p><b>Rationale:</b></p><p>Fixes an obvious typo.</p>
16229
16230
16231
16232
16233 <hr>
16234 <h3><a name="371"></a>371. Stability of multiset and multimap member functions</h3>
16235 <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16236  <b>Submitter:</b> Frank Compagner <b>Date:</b> 2002-07-20</p>
16237 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
16238 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
16239 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16240 <p><b>Discussion:</b></p>
16241 <p>
16242 The requirements for multiset and multimap containers (23.1
16243 [lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
16244 23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
16245 the stability of the required (mutating) member functions. It appears
16246 the standard allows these functions to reorder equivalent elements of
16247 the container at will, yet the pervasive red-black tree implementation
16248 appears to provide stable behaviour.
16249 </p>
16250
16251 <p>This is of most concern when considering the behaviour of erase().
16252 A stability requirement would guarantee the correct working of the
16253 following 'idiom' that removes elements based on a certain predicate
16254 function.
16255 </p>
16256
16257 <pre>  multimap&lt;int, int&gt; m;
16258   multimap&lt;int, int&gt;::iterator i = m.begin();
16259   while (i != m.end()) {
16260       if (pred(i))
16261           m.erase (i++);
16262       else
16263           ++i;
16264   }
16265 </pre>
16266
16267 <p>
16268 Although clause 23.1.2/8 guarantees that i remains a valid iterator
16269 througout this loop, absence of the stability requirement could
16270 potentially result in elements being skipped. This would make
16271 this code incorrect, and, furthermore, means that there is no way
16272 of erasing these elements without iterating first over the entire
16273 container, and second over the elements to be erased. This would
16274 be unfortunate, and have a negative impact on both performance and
16275 code simplicity.
16276 </p>
16277
16278 <p>
16279 If the stability requirement is intended, it should be made explicit
16280 (probably through an extra paragraph in clause 23.1.2).
16281 </p>
16282 <p>
16283 If it turns out stability cannot be guaranteed, i'd argue that a
16284 remark or footnote is called for (also somewhere in clause 23.1.2) to
16285 warn against relying on stable behaviour (as demonstrated by the code
16286 above).  If most implementations will display stable behaviour, any
16287 problems emerging on an implementation without stable behaviour will
16288 be hard to track down by users. This would also make the need for an
16289 erase_if() member function that much greater.
16290 </p>
16291
16292 <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>
16293
16294
16295
16296 <p><b>Proposed resolution:</b></p>
16297
16298 <p>Add the following to the end of 23.1.2 [associative.reqmts] paragraph 4:
16299 "For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt>
16300   are <i>stable</i>: they preserve the relative ordering of equivalent
16301   elements.</p>
16302
16303 <p><i>[Lillehammer: Matt provided wording]</i></p>
16304
16305 <p><i>[Joe Gottman points out that the provided wording does not address
16306 multimap and multiset.  N1780 also addresses this issue and suggests
16307 wording.]</i></p>
16308
16309
16310 <p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p>
16311
16312
16313
16314
16315 <p><b>Rationale:</b></p>
16316 <p>The LWG agrees that this guarantee is necessary for common user
16317   idioms to work, and that all existing implementations provide this
16318   property.  Note that this resolution guarantees stability for
16319   multimap and multiset, not for all associative containers in
16320   general.</p>
16321
16322
16323
16324
16325
16326
16327 <hr>
16328 <h3><a name="373"></a>373. Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</h3>
16329 <p><b>Section:</b> 27.6.1.2.1 [istream.formatted.reqmts], 27.6.2.6.1 [ostream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16330  <b>Submitter:</b> Keith Baker <b>Date:</b> 2002-07-23</p>
16331 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.reqmts">issues</a> in [istream.formatted.reqmts].</p>
16332 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16333 <p><b>Discussion:</b></p>
16334
16335 <p>
16336 In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmts]
16337 (exception()&amp;badbit) != 0 is used in testing for rethrow, yet
16338 exception() is the constructor to class std::exception in 18.6.1 [type.info] that has no return type. Should member function
16339 exceptions() found in 27.4.4 [ios] be used instead?
16340 </p>
16341
16342
16343
16344 <p><b>Proposed resolution:</b></p>
16345 <p>
16346 In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmts], change
16347 "(exception()&amp;badbit) != 0" to "(exceptions()&amp;badbit) != 0".
16348 </p>
16349
16350
16351 <p><b>Rationale:</b></p>
16352 <p>Fixes an obvious typo.</p>
16353
16354
16355
16356
16357
16358 <hr>
16359 <h3><a name="375"></a>375. basic_ios should be ios_base in 27.7.1.3</h3>
16360 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16361  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-14</p>
16362 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
16363 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
16364 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16365 <p><b>Discussion:</b></p>
16366 <p>
16367 In Section 27.7.1.4 [stringbuf.virtuals]: Table 90, Table 91, and paragraph
16368 14 all contain references to "basic_ios::" which should be
16369 "ios_base::".
16370 </p>
16371
16372
16373 <p><b>Proposed resolution:</b></p>
16374 <p>
16375 Change all references to "basic_ios" in Table 90, Table 91, and
16376 paragraph 14 to "ios_base".
16377 </p>
16378
16379
16380 <p><b>Rationale:</b></p><p>Fixes an obvious typo.</p>
16381
16382
16383
16384
16385 <hr>
16386 <h3><a name="376"></a>376. basic_streambuf semantics</h3>
16387 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16388  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-14</p>
16389 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
16390 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
16391 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16392 <p><b>Discussion:</b></p>
16393 <p>
16394 In Section 27.7.1.4 [stringbuf.virtuals], Table 90, the implication is that
16395 the four conditions should be mutually exclusive, but they are not.
16396 The first two cases, as written, are subcases of the third.</p>
16397
16398 <p>
16399 As written, it is unclear what should be the result if cases 1 and 2
16400 are both true, but case 3 is false.
16401 </p>
16402
16403
16404
16405 <p><b>Proposed resolution:</b></p>
16406
16407 <p>Rewrite these conditions as:</p>
16408 <blockquote>
16409 <p>
16410   (which &amp; (ios_base::in|ios_base::out)) == ios_base::in
16411 </p>
16412
16413 <p>
16414   (which &amp; (ios_base::in|ios_base::out)) == ios_base::out
16415 </p>
16416
16417 <p>
16418   (which &amp; (ios_base::in|ios_base::out)) ==
16419 (ios_base::in|ios_base::out)
16420    and way == either ios_base::beg or ios_base::end
16421 </p>
16422
16423 <p>Otherwise</p>
16424 </blockquote>
16425
16426
16427
16428 <p><b>Rationale:</b></p>
16429 <p>It's clear what we wanted to say, we just failed to say it.  This
16430   fixes it.</p>
16431
16432
16433
16434
16435
16436 <hr>
16437 <h3><a name="379"></a>379. nonsensical ctype::do_widen() requirement</h3>
16438 <p><b>Section:</b> 22.2.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16439  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p>
16440 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.virtuals].</p>
16441 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16442 <p><b>Discussion:</b></p>
16443 <p>
16444 The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
16445 </p>
16446 <pre>  charT do_widen (char c) const;
16447
16448   -11- Effects: Applies the simplest reasonable transformation from
16449        a char value or sequence of char values to the corresponding
16450        charT value or values. The only characters for which unique
16451        transformations are required are those in the basic source
16452        character set (2.2). For any named ctype category with a
16453        ctype&lt;charT&gt; facet ctw and valid ctype_base::mask value
16454        M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
16455 </pre>
16456 <p>
16457 Shouldn't the last sentence instead read
16458 </p>
16459 <pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
16460        and valid ctype_base::mask value M
16461        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
16462 </pre>
16463 <p>
16464 I.e., if the narrow character c is not a member of a class of
16465 characters then neither is the widened form of c. (To paraphrase
16466 footnote 224.)
16467 </p>
16468
16469
16470 <p><b>Proposed resolution:</b></p>
16471 <p>
16472 Replace the last sentence of 22.2.1.1.2 [locale.ctype.virtuals], p11 with the
16473 following text:
16474 </p>
16475 <pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
16476        and valid ctype_base::mask value M,
16477        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
16478 </pre>
16479
16480 <p><i>[Kona: Minor edit. Added a comma after the <i>M</i> for clarity.]</i></p>
16481
16482
16483
16484
16485 <p><b>Rationale:</b></p>
16486 <p>The LWG believes this is just a typo, and that this is the correct fix.</p>
16487
16488
16489
16490
16491
16492 <hr>
16493 <h3><a name="380"></a>380. typos in codecvt tables 53 and 54</h3>
16494 <p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16495  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p>
16496 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
16497 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16498 <p><b>Discussion:</b></p>
16499 <p>
16500 Tables 53 and 54 in 22.2.1.5 [locale.codecvt.byname] are both titled "convert
16501 result values," when surely "do_in/do_out result values" must have
16502 been intended for Table 53 and "do_unshift result values" for Table
16503 54.
16504 </p>
16505 <p>
16506 Table 54, row 3 says that the meaning of partial is "more characters
16507 needed to be supplied to complete termination." The function is not
16508 supplied any characters, it is given a buffer which it fills with
16509 characters or, more precisely, destination elements (i.e., an escape
16510 sequence). So partial means that space for more than (to_limit - to)
16511 destination elements was needed to terminate a sequence given the
16512 value of state.
16513 </p>
16514
16515
16516 <p><b>Proposed resolution:</b></p>
16517 <p>
16518 Change the title of Table 53 to "do_in/do_out result values" and
16519 the title of Table 54 to "do_unshift result values."
16520 </p>
16521 <p>
16522 Change the text in Table 54, row 3 (the <b>partial</b> row), under the
16523 heading Meaning, to "space for more than (to_limit - to) destination
16524 elements was needed to terminate a sequence given the value of state."
16525 </p>
16526
16527
16528
16529
16530 <hr>
16531 <h3><a name="381"></a>381. detection of invalid mbstate_t in codecvt</h3>
16532 <p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16533  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p>
16534 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
16535 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16536 <p><b>Discussion:</b></p>
16537 <p>
16538 All but one codecvt member functions that take a state_type argument
16539 list as one of their preconditions that the state_type argument have
16540 a valid value. However, according to 22.2.1.5.2, p6,
16541 codecvt::do_unshift() is the only codecvt member that is supposed to
16542 return error if the state_type object is invalid.
16543 </p>
16544
16545 <p>
16546 It seems to me that the treatment of state_type by all codecvt member
16547 functions should be the same and the current requirements should be
16548 changed. Since the detection of invalid state_type values may be
16549 difficult in general or computationally expensive in some specific
16550 cases, I propose the following:
16551 </p>
16552
16553
16554 <p><b>Proposed resolution:</b></p>
16555 <p>
16556 Add a new paragraph before 22.2.1.5.2, p5, and after the function
16557 declaration below
16558 </p>
16559 <pre>    result do_unshift(stateT&amp; state,
16560     externT* to, externT* to_limit, externT*&amp; to_next) const;
16561 </pre>
16562 <p>
16563 as follows:
16564 </p>
16565 <pre>    Requires: (to &lt;= to_end) well defined and true; state initialized,
16566     if at the beginning of a sequence, or else equal to the result of
16567     converting the preceding characters in the sequence.
16568 </pre>
16569 <p>
16570 and change the text in Table 54, row 4, the <b>error</b> row, under
16571 the heading Meaning, from
16572 </p>
16573 <pre>    state has invalid value
16574 </pre>
16575 <p>
16576 to
16577 </p>
16578 <pre>    an unspecified error has occurred
16579 </pre>
16580
16581
16582 <p><b>Rationale:</b></p>
16583 <p>The intent is that implementations should not be required to detect
16584 invalid state values; such a requirement appears nowhere else.  An
16585 invalid state value is a precondition violation, <i>i.e.</i> undefined
16586 behavior.  Implementations that do choose to detect invalid state
16587 values, or that choose to detect any other kind of error, may return
16588 <b>error</b> as an indication.</p>
16589
16590
16591
16592
16593
16594 <hr>
16595 <h3><a name="383"></a>383. Bidirectional iterator assertion typo</h3>
16596 <p><b>Section:</b> 24.1.4 [bidirectional.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16597  <b>Submitter:</b> ysapir (submitted via comp.std.c++) <b>Date:</b> 2002-10-17</p>
16598 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bidirectional.iterators">issues</a> in [bidirectional.iterators].</p>
16599 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16600 <p><b>Discussion:</b></p>
16601 <p>
16602 Following a discussion on the boost list regarding end iterators and
16603 the possibility of performing operator--() on them, it seems to me
16604 that there is a typo in the standard.  This typo has nothing to do
16605 with that discussion.
16606 </p>
16607
16608 <p>
16609 I have checked this newsgroup, as well as attempted a search of the
16610 Active/Defect/Closed Issues List on the site for the words "s is
16611 derefer" so I believe this has not been proposed before.  Furthermore,
16612 the "Lists by Index" mentions only DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a> on section
16613 24.1.4, and DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a> is not related to this issue.
16614 </p>
16615
16616 <p>
16617 The standard makes the following assertion on bidirectional iterators,
16618 in section 24.1.4 [lib.bidirectional.iterators], Table 75:
16619 </p>
16620
16621 <pre>                         operational  assertion/note
16622 expression  return type   semantics    pre/post-condition
16623
16624 --r          X&amp;                        pre: there exists s such
16625                                        that r == ++s.
16626                                        post: s is dereferenceable.
16627                                        --(++r) == r.
16628                                        --r == --s implies r == s.
16629                                        &amp;r == &amp;--r.
16630 </pre>
16631
16632 <p>
16633 (See <a href="http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763">http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763</a>.)
16634 </p>
16635
16636 <p>
16637 In particular, "s is dereferenceable" seems to be in error.  It seems
16638 that the intention was to say "r is dereferenceable".
16639 </p>
16640
16641 <p>
16642 If it were to say "r is dereferenceable" it would
16643 make perfect sense.  Since s must be dereferenceable prior to
16644 operator++, then the natural result of operator-- (to undo operator++)
16645 would be to make r dereferenceable.  Furthermore, without other
16646 assertions, and basing only on precondition and postconditions, we
16647 could not otherwise know this.  So it is also interesting information.
16648 </p>
16649
16650
16651
16652 <p><b>Proposed resolution:</b></p>
16653 <p>
16654 Change the guarantee to "postcondition: r is dereferenceable."
16655 </p>
16656
16657
16658 <p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
16659
16660
16661
16662
16663 <hr>
16664 <h3><a name="384"></a>384. equal_range has unimplementable runtime complexity</h3>
16665 <p><b>Section:</b> 25.3.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16666  <b>Submitter:</b> Hans Bos <b>Date:</b> 2002-10-18</p>
16667 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#equal.range">issues</a> in [equal.range].</p>
16668 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16669 <p><b>Discussion:</b></p>
16670 <p>
16671 Section 25.3.3.3 [equal.range]
16672 states that at most 2 * log(last - first) + 1
16673 comparisons are allowed for equal_range.
16674 </p>
16675
16676 <p>It is not possible to implement equal_range with these constraints.</p>
16677
16678 <p>In a range of one element as in:</p>
16679 <pre>    int x = 1;
16680     equal_range(&amp;x, &amp;x + 1, 1)
16681 </pre>
16682
16683 <p>it is easy to see that at least 2 comparison operations are needed.</p>
16684
16685 <p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p>
16686
16687 <p>I have checked a few libraries and they all use the same (nonconforming)
16688 algorithm for equal_range that has a complexity of</p>
16689 <pre>     2* log(distance(first, last)) + 2.
16690 </pre>
16691 <p>I guess this is the algorithm that the standard assumes for equal_range.</p>
16692
16693 <p>
16694 It is easy to see that 2 * log(distance) + 2 comparisons are enough
16695 since equal range can be implemented with lower_bound and upper_bound
16696 (both log(distance) + 1).
16697 </p>
16698
16699 <p>
16700 I think it is better to require something like 2log(distance) + O(1)  (or
16701 even logarithmic as multiset::equal_range).
16702 Then an implementation has more room to optimize for certain cases (e.g.
16703 have log(distance) characteristics when at most match is found in the range
16704 but 2log(distance) + 4 for the worst case).
16705 </p>
16706
16707
16708
16709 <p><b>Proposed resolution:</b></p>
16710 <p>In 25.3.3.1 [lower.bound]/4, change <tt>log(last - first) + 1</tt>
16711 to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
16712
16713 <p>In 25.3.3.2 [upper.bound]/4, change <tt>log(last - first) + 1</tt>
16714 to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
16715
16716 <p>In 25.3.3.3 [equal.range]/4, change <tt>2*log(last - first) + 1</tt>
16717 to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
16718
16719 <p><i>[Matt provided wording]</i></p>
16720
16721
16722
16723 <p><b>Rationale:</b></p>
16724 <p>The LWG considered just saying <i>O</i>(log n) for all three, but
16725   decided that threw away too much valuable information.  The fact
16726   that lower_bound is twice as fast as equal_range is important.
16727   However, it's better to allow an arbitrary additive constant than to
16728   specify an exact count.  An exact count would have to
16729   involve <tt>floor</tt> or <tt>ceil</tt>.  It would be too easy to
16730   get this wrong, and don't provide any substantial value for users.</p>
16731
16732
16733
16734
16735 <hr>
16736 <h3><a name="386"></a>386. Reverse iterator's operator[] has impossible return type</h3>
16737 <p><b>Section:</b> 24.4.1.3.11 [reverse.iter.op-=] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
16738  <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-10-23</p>
16739 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
16740 <p><b>Discussion:</b></p>
16741 <p>In 24.4.1.3.11 [reverse.iter.op-=], <tt>reverse_iterator&lt;&gt;::operator[]</tt>
16742 is specified as having a return type of <tt>reverse_iterator::reference</tt>,
16743 which is the same as <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.
16744 (Where <tt>Iterator</tt> is the underlying iterator type.)</p>
16745
16746 <p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't
16747   necessarily have a return type
16748   of <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.   Its
16749   return type is merely required to be convertible
16750   to <tt>Iterator</tt>'s value type.  The return type specified for
16751   reverse_iterator's operator[] would thus appear to be impossible.</p>
16752
16753 <p>With the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>, the type of
16754   <tt>a[n]</tt> will continue to be required (for random access
16755   iterators) to be convertible to the value type, and also <tt>a[n] =
16756   t</tt> will be a valid expression.  Implementations of
16757   <tt>reverse_iterator</tt> will likely need to return a proxy from
16758   <tt>operator[]</tt> to meet these requirements. As mentioned in the
16759   comment from Dave Abrahams, the simplest way to specify that
16760   <tt>reverse_iterator</tt> meet this requirement to just mandate
16761   it and leave the return type of <tt>operator[]</tt> unspecified.</p>
16762
16763
16764
16765 <p><b>Proposed resolution:</b></p>
16766
16767 <p>In 24.4.1.2 [reverse.iter.requirements] change:</p>
16768
16769 <blockquote>
16770 <pre>reference operator[](difference_type n) const;
16771 </pre>
16772 </blockquote>
16773
16774 <p>to:</p>
16775
16776 <blockquote>
16777 <pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see 24.1.5 [random.access.iterators]
16778 </pre>
16779 </blockquote>
16780
16781
16782
16783
16784 <p><i>[
16785 Comments from Dave Abrahams: IMO we should resolve 386 by just saying
16786     that the return type of reverse_iterator's operator[] is
16787     unspecified, allowing the random access iterator requirements to
16788     impose an appropriate return type.  If we accept 299's proposed
16789     resolution (and I think we should), the return type will be
16790     readable and writable, which is about as good as we can do.
16791 ]</i></p>
16792
16793
16794
16795
16796
16797
16798 <hr>
16799 <h3><a name="389"></a>389. Const overload of valarray::operator[] returns by value</h3>
16800 <p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16801  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
16802 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
16803 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16804 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a></p>
16805 <p><b>Discussion:</b></p>
16806 <p>Consider the following program:</p>
16807 <pre>    #include &lt;iostream&gt;
16808     #include &lt;ostream&gt;
16809     #include &lt;vector&gt;
16810     #include &lt;valarray&gt;
16811     #include &lt;algorithm&gt;
16812     #include &lt;iterator&gt;
16813     template&lt;typename Array&gt;
16814     void print(const Array&amp; a)
16815     {
16816     using namespace std;
16817     typedef typename Array::value_type T;
16818     copy(&amp;a[0], &amp;a[0] + a.size(),
16819     ostream_iterator&lt;T&gt;(std::cout, " "));
16820     }
16821     template&lt;typename T, unsigned N&gt;
16822     unsigned size(T(&amp;)[N]) { return N; }
16823     int main()
16824     {
16825     double array[] = { 0.89, 9.3, 7, 6.23 };
16826     std::vector&lt;double&gt; v(array, array + size(array));
16827     std::valarray&lt;double&gt; w(array, size(array));
16828     print(v); // #1
16829     std::cout &lt;&lt; std::endl;
16830     print(w); // #2
16831     std::cout &lt;&lt; std::endl;
16832     }
16833 </pre>
16834
16835 <p>While the call numbered #1 succeeds, the call numbered #2 fails
16836 because the const version of the member function
16837 valarray&lt;T&gt;::operator[](size_t) returns a value instead of a
16838 const-reference. That seems to be so for no apparent reason, no
16839 benefit. Not only does that defeats users' expectation but it also
16840 does hinder existing software (written either in C or Fortran)
16841 integration within programs written in C++.  There is no reason why
16842 subscripting an expression of type valarray&lt;T&gt; that is const-qualified
16843 should not return a const T&amp;.</p>
16844
16845
16846 <p><b>Proposed resolution:</b></p>
16847 <p>In the class synopsis in 26.5.2 [template.valarray], and in
16848 26.5.2.3 [valarray.access] just above paragraph 1, change</p>
16849 <pre>  T operator[](size_t const);
16850 </pre>
16851 <p>to</p>
16852 <pre>  const T&amp; operator[](size_t const);
16853 </pre>
16854
16855 <p><i>[Kona: fixed a minor typo: put semicolon at the end of the line
16856   wehre it belongs.]</i></p>
16857
16858
16859
16860
16861 <p><b>Rationale:</b></p>
16862 <p>Return by value seems to serve no purpose.  Valaray was explicitly
16863 designed to have a specified layout so that it could easily be
16864 integrated with libraries in other languages, and return by value
16865 defeats that purpose.  It is believed that this change will have no
16866 impact on allowable optimizations.</p>
16867
16868
16869
16870
16871
16872 <hr>
16873 <h3><a name="391"></a>391. non-member functions specified as const</h3>
16874 <p><b>Section:</b> 22.1.3.2 [conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16875  <b>Submitter:</b> James Kanze <b>Date:</b> 2002-12-10</p>
16876 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16877 <p><b>Discussion:</b></p>
16878 <p>
16879 The specifications of toupper and tolower both specify the functions as
16880 const, althought they are not member functions, and are not specified as
16881 const in the header file synopsis in section 22.1 [locales].
16882 </p>
16883
16884
16885 <p><b>Proposed resolution:</b></p>
16886 <p>In 22.1.3.2 [conversions], remove <tt>const</tt> from the function
16887   declarations of std::toupper and std::tolower</p>
16888
16889
16890 <p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
16891
16892
16893
16894
16895 <hr>
16896 <h3><a name="395"></a>395. inconsistencies in the definitions of rand() and random_shuffle()</h3>
16897 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16898  <b>Submitter:</b> James Kanze <b>Date:</b> 2003-01-03</p>
16899 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
16900 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
16901 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16902 <p><b>Discussion:</b></p>
16903 <p>
16904 In 26.7 [c.math], the C++ standard refers to the C standard for the
16905 definition of rand(); in the C standard, it is written that "The
16906 implementation shall behave as if no library function calls the rand
16907 function."
16908 </p>
16909
16910 <p>
16911 In 25.2.12 [alg.random.shuffle], there is no specification as to
16912 how the two parameter version of the function generates its random
16913 value.  I believe that all current implementations in fact call rand()
16914 (in contradiction with the requirement avove); if an implementation does
16915 not call rand(), there is the question of how whatever random generator
16916 it does use is seeded.  Something is missing.
16917 </p>
16918
16919
16920
16921 <p><b>Proposed resolution:</b></p>
16922 <p>
16923 In [lib.c.math], add a paragraph specifying that the C definition of
16924 rand shal be modified to say that "Unless otherwise specified, the
16925 implementation shall behave as if no library function calls the rand
16926 function."
16927 </p>
16928
16929 <p>
16930 In [lib.alg.random.shuffle], add a sentence to the effect that "In
16931 the two argument form of the function, the underlying source of
16932 random numbers is implementation defined. [Note: in particular, an
16933 implementation is permitted to use <tt>rand</tt>.]
16934 </p>
16935
16936
16937 <p><b>Rationale:</b></p>
16938 <p>The original proposed resolution proposed requiring the
16939   two-argument from of <tt>random_shuffle</tt> to
16940   use <tt>rand</tt>. We don't want to do that, because some existing
16941   implementations already use something else: gcc
16942   uses <tt>lrand48</tt>, for example.  Using <tt>rand</tt> presents a
16943   problem if the number of elements in the sequence is greater than
16944   RAND_MAX.</p>
16945
16946
16947
16948
16949
16950 <hr>
16951 <h3><a name="400"></a>400. redundant type cast in lib.allocator.members</h3>
16952 <p><b>Section:</b> 20.6.1.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16953  <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
16954 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
16955 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16956 <p><b>Discussion:</b></p>
16957 <p>
16958 20.6.1.1 [allocator.members] allocator members, contains
16959 the following 3 lines:
16960 </p>
16961
16962 <pre>  12 Returns: new((void *) p) T( val)
16963      void destroy(pointer p);
16964   13 Returns: ((T*) p)-&gt;~T()
16965 </pre>
16966
16967 <p>
16968 The type cast "(T*) p" in the last line is redundant cause
16969 we know that std::allocator&lt;T&gt;::pointer is a typedef for T*.
16970 </p>
16971
16972
16973 <p><b>Proposed resolution:</b></p>
16974 <p>
16975 Replace "((T*) p)" with "p".
16976 </p>
16977
16978
16979 <p><b>Rationale:</b></p><p>Just a typo, this is really editorial.</p>
16980
16981
16982
16983
16984 <hr>
16985 <h3><a name="402"></a>402. wrong new expression in [some_]allocator::construct</h3>
16986 <p><b>Section:</b> 20.1.2 [allocator.requirements], 20.6.1.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16987  <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
16988 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
16989 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
16990 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16991 <p><b>Discussion:</b></p>
16992 <p>
16993 This applies to the new expression that is contained in both par12 of
16994 20.6.1.1 [allocator.members] and in par2 (table 32) of  [default.con.req].
16995 I think this new expression is wrong, involving unintended side
16996 effects.
16997 </p>
16998
16999
17000 <p>20.6.1.1 [allocator.members]  contains the following 3 lines:</p>
17001
17002 <pre>  11 Returns: the largest value N for which the call allocate(N,0) might succeed.
17003      void construct(pointer p, const_reference val);
17004   12 Returns: new((void *) p) T( val)
17005 </pre>
17006
17007
17008 <p> [default.con.req] in table 32 has the following line:</p>
17009 <pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
17010 </pre>
17011
17012 <p>
17013 .... with the prerequisits coming from the preceding two paragraphs,
17014 especially from table 31:
17015 </p>
17016
17017 <pre>  alloc&lt;T&gt;             a     ;// an allocator for T
17018   alloc&lt;T&gt;::pointer    p     ;// random access iterator
17019                               // (may be different from T*)
17020   alloc&lt;T&gt;::reference  r = *p;// T&amp;
17021   T const&amp;             t     ;
17022 </pre>
17023
17024 <p>
17025 Cause of using "new" but not "::new", any existing "T::operator new"
17026 function will hide the global placement new function. When there is no
17027 "T::operator new" with adequate signature,
17028 every_alloc&lt;T&gt;::construct(..) is ill-formed, and most
17029 std::container&lt;T,every_alloc&lt;T&gt;&gt; use it; a workaround
17030 would be adding placement new and delete functions with adequate
17031 signature and semantic to class T, but class T might come from another
17032 party. Maybe even worse is the case when T has placement new and
17033 delete functions with adequate signature but with "unknown" semantic:
17034 I dont like to speculate about it, but whoever implements
17035 any_container&lt;T,any_alloc&gt; and wants to use construct(..)
17036 probably must think about it.
17037 </p>
17038
17039
17040 <p><b>Proposed resolution:</b></p>
17041 <p>
17042 Replace "new" with "::new" in both cases.
17043 </p>
17044
17045
17046
17047
17048
17049
17050
17051 <hr>
17052 <h3><a name="403"></a>403. basic_string::swap should not throw exceptions</h3>
17053 <p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17054  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2003-03-25</p>
17055 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p>
17056 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17057 <p><b>Discussion:</b></p>
17058
17059 <p>
17060 std::basic_string, 21.3 [basic.string] paragraph 2 says that
17061 basic_string "conforms to the requirements of a Sequence, as specified
17062 in (23.1.1)." The sequence requirements specified in (23.1.1) to not
17063 include any prohibition on swap members throwing exceptions.
17064 </p>
17065
17066 <p>
17067 Section 23.1 [container.requirements] paragraph 10 does limit conditions under
17068 which exceptions may be thrown, but applies only to "all container
17069 types defined in this clause" and so excludes basic_string::swap
17070 because it is defined elsewhere.
17071 </p>
17072
17073 <p>
17074 Eric Niebler points out that 21.3 [basic.string] paragraph 5 explicitly
17075 permits basic_string::swap to invalidates iterators, which is
17076 disallowed by 23.1 [container.requirements] paragraph 10. Thus the standard would
17077 be contradictory if it were read or extended to read as having
17078 basic_string meet 23.1 [container.requirements] paragraph 10 requirements.
17079 </p>
17080
17081 <p>
17082 Yet several LWG members have expressed the belief that the original
17083 intent was that basic_string::swap should not throw exceptions as
17084 specified by 23.1 [container.requirements] paragraph 10, and that the standard is
17085 unclear on this issue. The complexity of basic_string::swap is
17086 specified as "constant time", indicating the intent was to avoid
17087 copying (which could cause a bad_alloc or other exception). An
17088 important use of swap is to ensure that exceptions are not thrown in
17089 exception-safe code.
17090 </p>
17091
17092 <p>
17093 Note: There remains long standing concern over whether or not it is
17094 possible to reasonably meet the 23.1 [container.requirements] paragraph 10 swap
17095 requirements when allocators are unequal. The specification of
17096 basic_string::swap exception requirements is in no way intended to
17097 address, prejudice, or otherwise impact that concern.
17098 </p>
17099
17100
17101
17102
17103
17104
17105
17106 <p><b>Proposed resolution:</b></p>
17107 <p>
17108 In 21.3.6.8 [string::swap], add a throws clause:
17109 </p>
17110
17111 <p>
17112 Throws: Shall not throw exceptions.
17113 </p>
17114
17115
17116
17117
17118
17119 <hr>
17120 <h3><a name="404"></a>404. May a replacement allocation function be declared inline?</h3>
17121 <p><b>Section:</b> 17.4.3.4 [replacement.functions], 18.5.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17122  <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-04-24</p>
17123 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17124 <p><b>Discussion:</b></p>
17125 <p>
17126 The eight basic dynamic memory allocation functions (single-object
17127 and array versions of ::operator new and ::operator delete, in the
17128 ordinary and nothrow forms) are replaceable.  A C++ program may
17129 provide an alternative definition for any of them, which will be used
17130 in preference to the implementation's definition.
17131 </p>
17132
17133 <p>
17134 Three different parts of the standard mention requirements on
17135 replacement functions: 17.4.3.4 [replacement.functions], 18.5.1.1 [new.delete.single]
17136 and 18.5.1.2 [new.delete.array], and 3.7.2 [basic.stc.auto].
17137 </p>
17138
17139 <p>None of these three places say whether a replacement function may
17140   be declared inline.  18.5.1.1 [new.delete.single] paragraph 2 specifies a
17141   signature for the replacement function, but that's not enough:
17142   the <tt>inline</tt> specifier is not part of a function's signature.
17143   One might also reason from 7.1.2 [dcl.fct.spec] paragraph 2, which
17144   requires that "an inline function shall be defined in every
17145   translation unit in which it is used," but this may not be quite
17146   specific enough either.  We should either explicitly allow or
17147   explicitly forbid inline replacement memory allocation
17148   functions.</p>
17149
17150
17151 <p><b>Proposed resolution:</b></p>
17152 <p>
17153 Add a new sentence to the end of 17.4.3.4 [replacement.functions] paragraph 3:
17154 "The program's definitions shall not be specified as <tt>inline</tt>.
17155 No diagnostic is required."
17156 </p>
17157
17158 <p><i>[Kona: added "no diagnostic is required"]</i></p>
17159
17160
17161
17162
17163 <p><b>Rationale:</b></p>
17164 <p>
17165 The fact that <tt>inline</tt> isn't mentioned appears to have been
17166 nothing more than an oversight.  Existing implementations do not
17167 permit inline functions as replacement memory allocation functions.
17168 Providing this functionality would be difficult in some cases, and is
17169 believed to be of limited value.
17170 </p>
17171
17172
17173
17174
17175
17176 <hr>
17177 <h3><a name="405"></a>405. qsort and POD</h3>
17178 <p><b>Section:</b> 25.4 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17179  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2003-04-08</p>
17180 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.c.library">issues</a> in [alg.c.library].</p>
17181 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17182 <p><b>Discussion:</b></p>
17183 <p>
17184 Section 25.4 [alg.c.library] describes bsearch and qsort, from the C
17185 standard library. Paragraph 4 does not list any restrictions on qsort,
17186 but it should limit the base parameter to point to POD.  Presumably,
17187 qsort sorts the array by copying bytes, which requires POD.
17188 </p>
17189
17190
17191 <p><b>Proposed resolution:</b></p>
17192 <p>
17193 In 25.4 [alg.c.library] paragraph 4, just after the declarations and
17194 before the nonnormative note, add these words: "both of which have the
17195 same behavior as the original declaration.  The behavior is undefined
17196 unless the objects in the array pointed to by <i>base</i> are of POD
17197 type."
17198 </p>
17199
17200 <p><i>[Something along these lines is clearly necessary.  Matt
17201   provided wording.]</i></p>
17202
17203
17204
17205
17206
17207
17208 <hr>
17209 <h3><a name="406"></a>406. vector::insert(s) exception safety</h3>
17210 <p><b>Section:</b> 23.2.5.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
17211  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2003-04-27</p>
17212 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
17213 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
17214 <p><b>Discussion:</b></p>
17215 <p>
17216 There is a possible defect in the standard: the standard text was
17217 never intended to prevent arbitrary ForwardIterators, whose operations
17218 may throw exceptions, from being passed, and it also wasn't intended
17219 to require a temporary buffer in the case where ForwardIterators were
17220 passed (and I think most implementations don't use one).  As is, the
17221 standard appears to impose requirements that aren't met by any
17222 existing implementation.
17223 </p>
17224
17225
17226 <p><b>Proposed resolution:</b></p>
17227 <p>Replace 23.2.5.4 [vector.modifiers] paragraph 1 with:</p>
17228 <blockquote><p>
17229   1- Notes: Causes reallocation if the new size is greater than the
17230   old capacity. If no reallocation happens, all the iterators and
17231   references before the insertion point remain valid. If an exception
17232   is thrown other than by the copy constructor or assignment operator
17233   of T or by any InputIterator operation there are no effects.
17234 </p></blockquote>
17235
17236 <p><i>[We probably need to say something similar for deque.]</i></p>
17237
17238
17239
17240
17241
17242
17243
17244 <hr>
17245 <h3><a name="407"></a>407. Can singular iterators be destroyed?</h3>
17246 <p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17247  <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
17248 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
17249 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
17250 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17251 <p><b>Discussion:</b></p>
17252 <p>
17253 Clause 24.1 [iterator.requirements], paragraph 5, says that the only expression
17254 that is defined for a singular iterator is "an assignment of a
17255 non-singular value to an iterator that holds a singular value".  This
17256 means that destroying a singular iterator (e.g. letting an automatic
17257 variable go out of scope) is technically undefined behavior.  This
17258 seems overly strict, and probably unintentional.
17259 </p>
17260
17261
17262 <p><b>Proposed resolution:</b></p>
17263 <p>
17264 Change the sentence in question to "... the only exceptions are
17265 destroying an iterator that holds a singular value, or the assignment
17266 of a non-singular value to an iterator that holds a singular value."
17267 </p>
17268
17269
17270
17271
17272
17273 <hr>
17274 <h3><a name="409"></a>409. Closing an fstream should clear error state</h3>
17275 <p><b>Section:</b> 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
17276  <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
17277 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
17278 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
17279 <p><b>Discussion:</b></p>
17280 <p>
17281 A strict reading of 27.8.1 [fstreams] shows that opening or
17282 closing a basic_[io]fstream does not affect the error bits.  This
17283 means, for example, that if you read through a file up to EOF, and
17284 then close the stream and reopen it at the beginning of the file,
17285 the EOF bit in the stream's error state is still set.  This is
17286 counterintuitive.
17287 </p>
17288 <p>
17289 The LWG considered this issue once before, as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>,
17290 and put in a footnote to clarify that the strict reading was indeed
17291 correct.  We did that because we believed the standard was
17292 unambiguous and consistent, and that we should not make architectural
17293 changes in a TC.  Now that we're working on a new revision of the
17294 language, those considerations no longer apply.
17295 </p>
17296
17297
17298 <p><b>Proposed resolution:</b></p>
17299
17300 <p>Change 27.8.1.9 [ifstream.members], para. 3 from:</p>
17301
17302 <blockquote><p>
17303 Calls rdbuf()-&gt;open(s,mode|in). If that function returns a null
17304 pointer, calls setstate(failbit) (which may throw ios_base::failure
17305 [Footnote: (lib.iostate.flags)].
17306 </p></blockquote>
17307
17308 <p>to:</p>
17309
17310 <blockquote><p>Calls rdbuf()-&gt;open(s,mode|in). If that function
17311 returns a null pointer, calls setstate(failbit) (which may throw
17312 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
17313 </p></blockquote>
17314
17315 <p>Change 27.8.1.13 [ofstream.members], para. 3 from:</p>
17316
17317 <blockquote><p>Calls rdbuf()-&gt;open(s,mode|out). If that function
17318 returns a null pointer, calls setstate(failbit) (which may throw
17319 ios_base::failure [Footnote: (lib.iostate.flags)).
17320 </p></blockquote>
17321
17322 <p>to:</p>
17323
17324 <blockquote><p>Calls rdbuf()-&gt;open(s,mode|out). If that function
17325 returns a null pointer, calls setstate(failbit) (which may throw
17326 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
17327 </p></blockquote>
17328
17329 <p>Change 27.8.1.17 [fstream.members], para. 3 from:</p>
17330
17331 <blockquote><p>Calls rdbuf()-&gt;open(s,mode), If that function returns
17332 a null pointer, calls setstate(failbit), (which may throw
17333 ios_base::failure). (lib.iostate.flags) )
17334 </p></blockquote>
17335
17336 <p>to:</p>
17337
17338 <blockquote><p>Calls rdbuf()-&gt;open(s,mode), If that function returns
17339 a null pointer, calls setstate(failbit), (which may throw
17340 ios_base::failure). (lib.iostate.flags) ), else calls clear().
17341 </p></blockquote>
17342
17343
17344
17345 <p><i>[Kona: the LWG agrees this is a good idea.  Post-Kona: Bill
17346 provided wording.  He suggests having open, not close, clear the error
17347 flags.]</i></p>
17348
17349
17350 <p><i>[Post-Sydney: Howard provided a new proposed resolution.  The
17351   old one didn't make sense because it proposed to fix this at the
17352   level of basic_filebuf, which doesn't have access to the stream's
17353   error state.  Howard's proposed resolution fixes this at the level
17354   of the three fstream class template instead.]</i></p>
17355
17356
17357
17358
17359
17360
17361
17362
17363 <hr>
17364 <h3><a name="410"></a>410. Missing semantics for stack and queue comparison operators</h3>
17365 <p><b>Section:</b> 23.2.3.1 [list.cons], 23.2.3.3 [list.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17366  <b>Submitter:</b> Hans Bos <b>Date:</b> 2003-06-07</p>
17367 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.cons">issues</a> in [list.cons].</p>
17368 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17369 <p><b>Discussion:</b></p>
17370 <p>
17371 Sections 23.2.3.1 [list.cons] and 23.2.3.3 [list.modifiers] list
17372 comparison operators (==, !=, &lt;, &lt;=, &gt;, =&gt;) for queue and
17373 stack.  Only the semantics for queue::operator== (23.2.3.1 [list.cons] par2) and queue::operator&lt; (23.2.3.1 [list.cons]
17374 par3) are defined.
17375 </p>
17376
17377
17378 <p><b>Proposed resolution:</b></p>
17379
17380 <p>Add the following new paragraphs after 23.2.3.1 [list.cons]
17381   paragraph 3:</p>
17382
17383 <blockquote>
17384
17385 <pre>  operator!=
17386 </pre>
17387 <p>Returns: <tt>x.c != y.c</tt></p>
17388
17389 <pre>  operator&gt;
17390 </pre>
17391 <p>Returns: <tt>x.c &gt; y.c</tt></p>
17392
17393 <pre>  operator&lt;=
17394 </pre>
17395 <p>Returns: <tt>x.c &lt;= y.c</tt></p>
17396
17397 <pre>  operator&gt;=
17398 </pre>
17399 <p>Returns: <tt>x.c &gt;= y.c</tt></p>
17400
17401 </blockquote>
17402
17403 <p>Add the following paragraphs at the end of 23.2.3.3 [list.modifiers]:</p>
17404
17405 <blockquote>
17406
17407 <pre>  operator==
17408 </pre>
17409 <p>Returns: <tt>x.c == y.c</tt></p>
17410
17411 <pre>  operator&lt;
17412 </pre>
17413 <p>Returns: <tt>x.c &lt; y.c</tt></p>
17414
17415 <pre>  operator!=
17416 </pre>
17417 <p>Returns: <tt>x.c != y.c</tt></p>
17418
17419 <pre>  operator&gt;
17420 </pre>
17421 <p>Returns: <tt>x.c &gt; y.c</tt></p>
17422
17423 <pre>  operator&lt;=
17424 </pre>
17425 <p>Returns: <tt>x.c &lt;= y.c</tt></p>
17426
17427 <pre>  operator&gt;=
17428 </pre>
17429 <p>Returns: <tt>x.c &gt;= y.c</tt></p>
17430
17431 </blockquote>
17432
17433
17434 <p><i>[Kona: Matt provided wording.]</i></p>
17435
17436
17437
17438
17439 <p><b>Rationale:</b></p>
17440 <p>There isn't any real doubt about what these operators are
17441 supposed to do, but we ought to spell it out.</p>
17442
17443
17444
17445
17446
17447 <hr>
17448 <h3><a name="411"></a>411. Wrong names of set member functions</h3>
17449 <p><b>Section:</b> 25.3.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17450  <b>Submitter:</b> Daniel Frey <b>Date:</b> 2003-07-09</p>
17451 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.set.operations">issues</a> in [alg.set.operations].</p>
17452 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17453 <p><b>Discussion:</b></p>
17454 <p>
17455 25.3.5 [alg.set.operations] paragraph 1 reads:
17456 "The semantics of the set operations are generalized to multisets in a
17457 standard way by defining union() to contain the maximum number of
17458 occurrences of every element, intersection() to contain the minimum, and
17459 so on."
17460 </p>
17461
17462 <p>
17463 This is wrong.  The name of the functions are set_union() and
17464 set_intersection(), not union() and intersection().
17465 </p>
17466
17467
17468 <p><b>Proposed resolution:</b></p>
17469 <p>Change that sentence to use the correct names.</p>
17470
17471
17472
17473
17474
17475 <hr>
17476 <h3><a name="412"></a>412. Typo in 27.4.4.3</h3>
17477 <p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17478  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-07-10</p>
17479 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
17480 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17481 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#429">429</a></p>
17482 <p><b>Discussion:</b></p>
17483 <p>
17484 The Effects clause in 27.4.4.3 [iostate.flags] paragraph 5 says that the
17485 function only throws if the respective bits are already set prior to
17486 the function call. That's obviously not the intent. The typo ought to
17487 be corrected and the text reworded as: "If (<i>state</i> &amp;
17488 exceptions()) == 0, returns. ..."
17489 </p>
17490
17491
17492 <p><b>Proposed resolution:</b></p>
17493 <p>
17494 In 27.4.4.3 [iostate.flags] paragraph 5, replace "If (rdstate() &amp;
17495 exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
17496 &amp; exceptions()) == 0".
17497 </p>
17498
17499 <p><i>[Kona: the original proposed resolution wasn't quite right.  We
17500   really do mean rdstate(); the ambiguity is that the wording in the
17501   standard doesn't make it clear whether we mean rdstate() before
17502   setting the new state, or rdsate() after setting it.  We intend the
17503   latter, of course. Post-Kona: Martin provided wording.]</i></p>
17504
17505
17506
17507
17508
17509
17510
17511 <hr>
17512 <h3><a name="413"></a>413. Proposed resolution to LDR#64 still wrong</h3>
17513 <p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
17514  <b>Submitter:</b> Bo Persson <b>Date:</b> 2003-07-13</p>
17515 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
17516 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
17517 <p><b>Discussion:</b></p>
17518 <p>
17519 The second sentence of the proposed resolution says:
17520 </p>
17521
17522 <p>
17523 "If it inserted no characters because it caught an exception thrown
17524 while extracting characters from sb and ..."
17525 </p>
17526
17527 <p>
17528 However, we are not extracting from sb, but extracting from the
17529 basic_istream (*this) and inserting into sb. I can't really tell if
17530 "extracting" or "sb" is a typo.
17531 </p>
17532
17533 <p><i>[
17534 Sydney: Definitely a real issue. We are, indeed, extracting characters
17535 from an istream and not from sb. The problem was there in the FDIS and
17536 wasn't fixed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>. Probably what was intended was
17537 to have *this instead of sb. We're talking about the exception flag
17538 state of a basic_istream object, and there's only one basic_istream
17539 object in this discussion, so that would be a consistent
17540 interpretation.  (But we need to be careful: the exception policy of
17541 this member function must be consistent with that of other
17542 extractors.)  PJP will provide wording.
17543 ]</i></p>
17544
17545
17546
17547
17548 <p><b>Proposed resolution:</b></p>
17549 <p>Change the sentence from:</p>
17550
17551 <blockquote><p>
17552 If it inserted no characters because it caught an exception thrown
17553 while extracting characters from sb and failbit is on in exceptions(),
17554 then the caught exception is rethrown.
17555 </p></blockquote>
17556
17557 <p>to:</p>
17558
17559 <blockquote><p>
17560 If it inserted no characters because it caught an exception thrown
17561 while extracting characters from *this and failbit is on in exceptions(),
17562 then the caught exception is rethrown.
17563 </p></blockquote>
17564
17565
17566
17567
17568
17569 <hr>
17570 <h3><a name="414"></a>414. Which iterators are invalidated by v.erase()?</h3>
17571 <p><b>Section:</b> 23.2.5.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17572  <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-08-19</p>
17573 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
17574 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17575 <p><b>Discussion:</b></p>
17576 <p>
17577 Consider the following code fragment:
17578 </p>
17579 <blockquote>
17580 <pre>int A[8] = { 1,3,5,7,9,8,4,2 };
17581 std::vector&lt;int&gt; v(A, A+8);
17582
17583 std::vector&lt;int&gt;::iterator i1 = v.begin() + 3;
17584 std::vector&lt;int&gt;::iterator i2 = v.begin() + 4;
17585 v.erase(i1);
17586 </pre>
17587 </blockquote>
17588
17589 <p>
17590 Which iterators are invalidated by <tt>v.erase(i1)</tt>: i1, i2,
17591 both, or neither?
17592 </p>
17593
17594 <p>
17595 On all existing implementations that I know of, the status of i1 and
17596 i2 is the same: both of them will be iterators that point to some
17597 elements of the vector (albeit not the same elements they did
17598 before).  You won't get a crash if you use them.  Depending on
17599 exactly what you mean by "invalidate", you might say that neither one
17600 has been invalidated because they still point to <i>something</i>,
17601 or you might say that both have been invalidated because in both
17602 cases the elements they point to have been changed out from under the
17603 iterator.
17604 </p>
17605
17606 <p>
17607 The standard doesn't say either of those things.  It says that erase
17608 invalidates all iterators and references "after the point of the
17609 erase".  This doesn't include i1, since it's at the point of the
17610 erase instead of after it.  I can't think of any sensible definition
17611 of invalidation by which one can say that i2 is invalidated but i1
17612 isn't.
17613 </p>
17614
17615 <p>
17616 (This issue is important if you try to reason about iterator validity
17617 based only on the guarantees in the standard, rather than reasoning
17618 from typical implementation techniques.  Strict debugging modes,
17619 which some programmers find useful, do not use typical implementation
17620 techniques.)
17621 </p>
17622
17623
17624 <p><b>Proposed resolution:</b></p>
17625 <p>
17626 In 23.2.5.4 [vector.modifiers] paragraph 3, change "Invalidates all the
17627 iterators and references after the point of the erase" to
17628 "Invalidates iterators and references at or after the point of the
17629 erase".
17630 </p>
17631
17632
17633 <p><b>Rationale:</b></p>
17634 <p>I believe this was essentially a typographical error, and that it
17635   was taken for granted that erasing an element invalidates iterators
17636   that point to it.  The effects clause in question treats iterators
17637   and references in parallel, and it would seem counterintuitive to
17638   say that a reference to an erased value remains valid.</p>
17639
17640
17641
17642
17643
17644 <hr>
17645 <h3><a name="415"></a>415. behavior of std::ws</h3>
17646 <p><b>Section:</b> 27.6.1.4 [istream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17647  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
17648 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17649 <p><b>Discussion:</b></p>
17650 <p>
17651 According to 27.6.1.4, the ws() manipulator is not required to construct
17652 the sentry object. The manipulator is also not a member function so the
17653 text in 27.6.1, p1 through 4 that describes the exception policy for
17654 istream member functions does not apply. That seems inconsistent with
17655 the rest of extractors and all the other input functions (i.e., ws will
17656 not cause a tied stream to be flushed before extraction, it doesn't check
17657 the stream's exceptions or catch exceptions thrown during input, and it
17658 doesn't affect the stream's gcount).
17659 </p>
17660
17661
17662 <p><b>Proposed resolution:</b></p>
17663 <p>
17664 Add to 27.6.1.4 [istream.manip], immediately before the first sentence
17665 of paragraph 1, the following text:
17666 </p>
17667
17668     <blockquote><p>
17669     Behaves as an unformatted input function (as described in
17670     27.6.1.3, paragraph 1), except that it does not count the number
17671     of characters extracted and does not affect the value returned by
17672     subsequent calls to is.gcount(). After constructing a sentry
17673     object...
17674     </p></blockquote>
17675
17676 <p><i>[Post-Kona: Martin provided wording]</i></p>
17677
17678
17679
17680
17681
17682
17683 <hr>
17684 <h3><a name="416"></a>416. definitions of XXX_MIN and XXX_MAX macros in climits</h3>
17685 <p><b>Section:</b> 18.2.2 [c.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17686  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
17687 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17688 <p><b>Discussion:</b></p>
17689         <p>
17690
17691 Given two overloads of the function foo(), one taking an argument of type
17692 int and the other taking a long, which one will the call foo(LONG_MAX)
17693 resolve to? The expected answer should be foo(long), but whether that
17694 is true depends on the #defintion of the LONG_MAX macro, specifically
17695 its type. This issue is about the fact that the type of these macros
17696 is not actually required to be the same as the the type each respective
17697 limit.
17698 <br>
17699
17700 Section 18.2.2 of the C++ Standard does not specify the exact types of
17701 the XXX_MIN and XXX_MAX macros #defined in the &lt;climits&gt; and &lt;limits.h&gt;
17702 headers such as INT_MAX and LONG_MAX and instead defers to the C standard.
17703 <br>
17704
17705 Section 5.2.4.2.1, p1 of the C standard specifies that "The values [of
17706 these constants] shall be replaced by constant expressions suitable for use
17707 in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX,
17708 the following shall be replaced by expressions that have the same type as
17709 would an expression that is an object of the corresponding type converted
17710 according to the integer promotions."
17711 <br>
17712
17713 The "corresponding type converted according to the integer promotions" for
17714 LONG_MAX is, according to 6.4.4.1, p5 of the C standard, the type of long
17715 converted to the first of the following set of types that can represent it:
17716 int, long int, long long int. So on an implementation where (sizeof(long)
17717 == sizeof(int)) this type is actually int, while on an implementation where
17718 (sizeof(long) &gt; sizeof(int)) holds this type will be long.
17719 <br>
17720
17721 This is not an issue in C since the type of the macro cannot be detected
17722 by any conforming C program, but it presents a portability problem in C++
17723 where the actual type is easily detectable by overload resolution.
17724
17725         </p>
17726 <p><i>[Kona: the LWG does not believe this is a defect.  The C macro
17727   definitions are what they are; we've got a better
17728   mechanism, <tt>std::numeric_limits</tt>, that is specified more
17729   precisely than the C limit macros.  At most we should add a
17730   nonnormative note recommending that users who care about the exact
17731   types of limit quantities should use &lt;limits&gt; instead of
17732   &lt;climits&gt;.]</i></p>
17733
17734
17735
17736
17737 <p><b>Proposed resolution:</b></p>
17738
17739 <p>
17740 Change 18.2.2 [c.limits], paragraph 2:
17741 </p>
17742
17743 <blockquote><p>
17744 -2- The contents are the same as the Standard C library header <tt>&lt;limits.h&gt;</tt>.
17745 <ins>[<i>Note:</i> The types of the macros in <tt>&lt;climits&gt;</tt> are not guaranteed
17746 to match the type to which they refer.<i>--end note</i>]</ins>
17747 </p></blockquote>
17748
17749
17750
17751
17752
17753 <hr>
17754 <h3><a name="420"></a>420. is std::FILE a complete type?</h3>
17755 <p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17756  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
17757 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
17758 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17759 <p><b>Discussion:</b></p>
17760 <p>
17761 7.19.1, p2, of C99 requires that the FILE type only be declared in
17762 &lt;stdio.h&gt;.  None of the (implementation-defined) members of the
17763 struct is mentioned anywhere for obvious reasons.
17764 </p>
17765
17766 <p>
17767 C++ says in 27.8.1, p2 that FILE is a type that's defined in &lt;cstdio&gt;. Is
17768 it really the intent that FILE be a complete type or is an implementation
17769 allowed to just declare it without providing a full definition?
17770 </p>
17771
17772
17773 <p><b>Proposed resolution:</b></p>
17774 <p>In the first sentence of 27.8.1 [fstreams] paragraph 2, change
17775   "defined" to "declared".</p>
17776
17777
17778 <p><b>Rationale:</b></p>
17779 <p>We don't want to impose any restrictions beyond what the C standard
17780   already says. We don't want to make anything implementation defined,
17781   because that imposes new requirements in implementations.</p>
17782
17783
17784
17785
17786
17787 <hr>
17788 <h3><a name="422"></a>422. explicit specializations of member functions of class templates</h3>
17789 <p><b>Section:</b> 17.4.3.1 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17790  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
17791 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
17792 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17793 <p><b>Discussion:</b></p>
17794 <p>
17795 It has been suggested that 17.4.3.1, p1 may or may not allow programs to
17796 explicitly specialize members of standard templates on user-defined types.
17797 The answer to the question might have an impact where library requirements
17798 are given using the "as if" rule. I.e., if programs are allowed to specialize
17799 member functions they will be able to detect an implementation's strict
17800 conformance to Effects clauses that describe the behavior of the function
17801 in terms of the other member function (the one explicitly specialized by
17802 the program) by relying on the "as if" rule.
17803 </p>
17804
17805
17806 <p><b>Proposed resolution:</b></p>
17807
17808 <p>
17809   Add the following sentence to 17.4.3.1 [reserved.names], p1:
17810 </p>
17811
17812 <blockquote><p>
17813 It is undefined for a C++ program to add declarations or definitions to
17814 namespace std or namespaces within namespace <tt>std</tt> unless otherwise specified. A
17815 program may add template specializations for any standard library template to
17816 namespace <tt>std</tt>. Such a specialization (complete or partial) of a standard library
17817 template results in undefined behavior unless the declaration depends on a
17818 user-defined type of external linkage and unless the specialization meets the
17819 standard library requirements for the original template.<sup>168)</sup>
17820 <ins>A program has undefined behavior if it declares</ins>
17821 </p>
17822 <ul>
17823 <li><ins>an explicit specialization of any member function of a standard
17824             library class template, or</ins></li>
17825 <li><ins>an explicit specialization of any member function template of a
17826             standard library class or class template, or</ins></li>
17827 <li><ins>an explicit or partial specialization of any member class
17828             template of a standard library class or class template.</ins></li>
17829 </ul>
17830 <p>
17831 A program may explicitly instantiate any templates in the standard library only
17832 if the declaration depends on the name of a user-defined type of external
17833 linkage and the instantiation meets the standard library requirements for the
17834 original template.
17835 </p></blockquote>
17836
17837 <p><i>[Kona: straw poll was 6-1 that user programs should not be
17838   allowed to specialize individual member functions of standard
17839   library class templates, and that doing so invokes undefined
17840   behavior. Post-Kona: Martin provided wording.]</i></p>
17841
17842
17843 <p><i>[Sydney: The LWG agrees that the standard shouldn't permit users
17844 to specialize individual member functions unless they specialize the
17845 whole class, but we're not sure these words say what we want them to;
17846 they could be read as prohibiting the specialization of any standard
17847 library class templates. We need to consult with CWG to make sure we
17848 use the right wording.]</i></p>
17849
17850
17851
17852
17853
17854
17855 <hr>
17856 <h3><a name="425"></a>425. return value of std::get_temporary_buffer</h3>
17857 <p><b>Section:</b> 20.6.3 [temporary.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17858  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
17859 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17860 <p><b>Discussion:</b></p>
17861 <p>
17862 The standard is not clear about the requirements on the value returned from
17863 a call to get_temporary_buffer(0). In particular, it fails to specify whether
17864 the call should return a distinct pointer each time it is called (like
17865 operator new), or whether the value is unspecified (as if returned by
17866 malloc). The standard also fails to mention what the required behavior
17867 is when the argument is less than 0.
17868 </p>
17869
17870
17871 <p><b>Proposed resolution:</b></p>
17872 <p>Change 20.4.3 [meta.help] paragraph 2 from "...or a pair of 0
17873 values if no storage can be obtained" to "...or a pair of 0 values if
17874 no storage can be obtained or if <i>n</i> &lt;= 0."</p>
17875 <p><i>[Kona: Matt provided wording]</i></p>
17876
17877
17878
17879
17880
17881 <hr>
17882 <h3><a name="426"></a>426. search_n(), fill_n(), and generate_n() with negative n</h3>
17883 <p><b>Section:</b> 25.1.9 [alg.search], 25.2.6 [alg.fill], 25.2.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17884  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
17885 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17886 <p><b>Discussion:</b></p>
17887 <p>
17888 The complexity requirements for these function templates are incorrect
17889 (or don't even make sense) for negative n:</p>
17890
17891 <p>25.1.9, p7 (search_n):
17892 <br>
17893 Complexity: At most (last1 - first1) * count applications
17894 of the corresponding predicate.</p>
17895
17896 <p>25.2.5, p3 (fill_n):
17897 <br>
17898 Complexity: Exactly last - first (or n) assignments.</p>
17899
17900 <p>25.2.6, p3 (generate_n):
17901 <br>
17902 Complexity: Exactly last - first (or n) assignments.</p>
17903
17904 <p>
17905 In addition, the Requirements or the Effects clauses for the latter two
17906 templates don't say anything about the behavior when n is negative.
17907 </p>
17908
17909
17910 <p><b>Proposed resolution:</b></p>
17911 <p>Change 25.1.9, p7 to</p>
17912
17913 <blockquote><p>
17914 Complexity: At most (last1 - first1) * count applications
17915 of the corresponding predicate if count is positive,
17916 or 0 otherwise.
17917 </p></blockquote>
17918
17919 <p>Change 25.2.5, p2 to</p>
17920 <blockquote><p>
17921 Effects: Assigns value through all the iterators in the range [first,
17922 last), or [first, first + n) if n is positive, none otherwise.
17923 </p></blockquote>
17924
17925 <p>Change 25.2.5, p3 to:</p>
17926 <blockquote><p>
17927 Complexity: Exactly last - first (or n if n is positive,
17928 or 0 otherwise) assignments.
17929 </p></blockquote>
17930
17931 <p>
17932 Change 25.2.6, p1
17933 to (notice the correction for the misspelled "through"):
17934 </p>
17935 <blockquote><p>
17936 Effects: Invokes the function object genand assigns the return
17937 value of gen through all the iterators in the range [first, last),
17938 or [first, first + n) if n is positive, or [first, first)
17939 otherwise.
17940 </p></blockquote>
17941
17942 <p>Change 25.2.6, p3 to:</p>
17943 <blockquote><p>
17944 Complexity: Exactly last - first (or n if n is positive,
17945 or 0 otherwise) assignments.
17946 </p></blockquote>
17947
17948
17949 <p><b>Rationale:</b></p>
17950 <p>Informally, we want to say that whenever we see a negative number
17951   we treat it the same as if it were zero.  We believe the above
17952   changes do that (although they may not be the minimal way of saying
17953   so).  The LWG considered and rejected the alternative of saying that
17954   negative numbers are undefined behavior.</p>
17955
17956
17957
17958
17959
17960 <hr>
17961 <h3><a name="428"></a>428. string::erase(iterator) validity</h3>
17962 <p><b>Section:</b> 21.3.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17963  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
17964 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::erase">issues</a> in [string::erase].</p>
17965 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17966 <p><b>Discussion:</b></p>
17967 <p>
17968 23.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q)
17969 that q must be a valid dereferenceable iterator into the sequence a.
17970 </p>
17971
17972 <p>
17973 However, 21.3.5.5, p5 describing string::erase(p) only requires that
17974 p be a valid iterator.
17975 </p>
17976
17977 <p>
17978 This may be interepreted as a relaxation of the general requirement,
17979 which is most likely not the intent.
17980 </p>
17981
17982
17983 <p><b>Proposed resolution:</b></p>
17984 <p>Remove 21.3.6.5 [string::erase] paragraph 5.</p>
17985
17986
17987 <p><b>Rationale:</b></p>
17988 <p>The LWG considered two options: changing the string requirements to
17989   match the general container requirements, or just removing the
17990   erroneous string requirements altogether.  The LWG chose the latter
17991   option, on the grounds that duplicating text always risks the
17992   possibility that it might be duplicated incorrectly.</p>
17993
17994
17995
17996
17997
17998 <hr>
17999 <h3><a name="432"></a>432. stringbuf::overflow() makes only one write position available</h3>
18000 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
18001  <b>Submitter:</b> Christian W Brock <b>Date:</b> 2003-09-24</p>
18002 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
18003 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
18004 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
18005 <p><b>Discussion:</b></p>
18006 <p>27.7.1.3 par 8 says:</p>
18007 <blockquote><p>
18008 Notes: The function can make a write position available only if
18009     ( mode &amp; ios_base::out) != 0. To make a write position
18010     available, the function reallocates (or initially allocates) an
18011     array object with a sufficient number of elements to hold the
18012     current array object (if any), plus one additional write position.
18013     If ( mode &amp; ios_base::in) != 0, the function alters the read end
18014     pointer egptr() to point just past the new write position (as
18015     does the write end pointer epptr()).
18016 </p></blockquote>
18017
18018 <p>
18019 The sentences "plus one additional write position." and especially
18020     "(as does the write end pointer epptr())" COULD by interpreted
18021     (and is interpreted by at least my library vendor) as:
18022 </p>
18023
18024 <blockquote><p>
18025     post-condition: epptr() == pptr()+1
18026 </p></blockquote>
18027
18028 <p>
18029 This WOULD force sputc() to call the virtual overflow() each time.
18030 </p>
18031
18032 <p>The proposed change also affects Defect Report 169.</p>
18033
18034
18035
18036 <p><b>Proposed resolution:</b></p>
18037 <p>27.7.1.1/2 Change:</p>
18038
18039 <blockquote><p>
18040 2- Notes: The function allocates no array object.
18041 </p></blockquote>
18042
18043 <p>
18044 to:
18045 </p>
18046
18047 <blockquote><p>
18048 2- Postcondition: str() == "".
18049 </p></blockquote>
18050
18051 <p>
18052 27.7.1.1/3 Change:
18053 </p>
18054
18055 <blockquote>
18056 <p>
18057 -3- Effects: Constructs an object of class basic_stringbuf,
18058 initializing the base class with basic_streambuf()
18059 (lib.streambuf.cons), and initializing mode with which . Then copies
18060 the content of str into the basic_stringbuf underlying character
18061 sequence and initializes the input and output sequences according to
18062 which. If which &amp; ios_base::out is true, initializes the output
18063 sequence with the underlying sequence. If which &amp; ios_base::in is
18064 true, initializes the input sequence with the underlying sequence.
18065 </p>
18066 </blockquote>
18067
18068 <p>to:</p>
18069
18070 <blockquote>
18071 <p>
18072 -3- Effects: Constructs an object of class basic_stringbuf,
18073 initializing the base class with basic_streambuf()
18074 (lib.streambuf.cons), and initializing mode with which. Then copies
18075 the content of str into the basic_stringbuf underlying character
18076 sequence. If which &amp; ios_base::out is true, initializes the output
18077 sequence such that pbase() points to the first underlying character,
18078 epptr() points one past the last underlying character, and if (which &amp;
18079 ios_base::ate) is true, pptr() is set equal to
18080 epptr() else pptr() is set equal to pbase(). If which &amp; ios_base::in
18081 is true, initializes the input sequence such that eback() and gptr()
18082 point to the first underlying character and egptr() points one past
18083 the last underlying character.
18084 </p>
18085 </blockquote>
18086
18087 <p>27.7.1.2/1 Change:</p>
18088
18089 <blockquote>
18090 <p>
18091 -1- Returns: A basic_string object whose content is equal to the
18092 basic_stringbuf underlying character sequence. If the buffer is only
18093 created in input mode, the underlying character sequence is equal to
18094 the input sequence; otherwise, it is equal to the output sequence. In
18095 case of an empty underlying character sequence, the function returns
18096 basic_string&lt;charT,traits,Allocator&gt;().
18097 </p>
18098 </blockquote>
18099
18100 <p>to:</p>
18101
18102 <blockquote>
18103 <p>
18104 -1- Returns: A basic_string object whose content is equal to the
18105 basic_stringbuf underlying character sequence. If the basic_stringbuf
18106 was created only in input mode, the resultant basic_string contains
18107 the character sequence in the range [eback(), egptr()).  If the
18108 basic_stringbuf was created with (which &amp; ios_base::out) being true
18109 then the resultant basic_string contains the character sequence in the
18110 range [pbase(), high_mark) where high_mark represents the position one
18111 past the highest initialized character in the buffer.  Characters can
18112 be initialized either through writing to the stream, or by
18113 constructing the basic_stringbuf with a basic_string, or by calling
18114 the str(basic_string) member function.  In the case of calling the
18115 str(basic_string) member function, all characters initialized prior to
18116 the call are now considered uninitialized (except for those
18117 characters re-initialized by the new basic_string).  Otherwise the
18118 basic_stringbuf has been created in neither input nor output mode and
18119 a zero length basic_string is returned.
18120 </p>
18121 </blockquote>
18122
18123 <p>
18124 27.7.1.2/2 Change:
18125 </p>
18126
18127 <blockquote>
18128 <p>
18129 -2- Effects: If the basic_stringbuf's underlying character sequence is
18130 not empty, deallocates it. Then copies the content of s into the
18131 basic_stringbuf underlying character sequence and initializes the
18132 input and output sequences according to the mode stored when creating
18133 the basic_stringbuf object. If (mode&amp;ios_base::out) is true, then
18134 initializes the output sequence with the underlying sequence. If
18135 (mode&amp;ios_base::in) is true, then initializes the input sequence with
18136 the underlying sequence.
18137 </p>
18138 </blockquote>
18139
18140 <p>to:</p>
18141
18142 <blockquote>
18143 <p>
18144 -2- Effects: Copies the content of s into the basic_stringbuf
18145 underlying character sequence. If mode &amp; ios_base::out is true,
18146 initializes the output sequence such that pbase() points to the first
18147 underlying character, epptr() points one past the last underlying
18148 character, and if (mode &amp; ios_base::ate) is true,
18149 pptr() is set equal to epptr() else pptr() is set equal to pbase(). If
18150 mode &amp; ios_base::in is true, initializes the input sequence such that
18151 eback() and gptr() point to the first underlying character and egptr()
18152 points one past the last underlying character.
18153 </p>
18154 </blockquote>
18155
18156 <p>Remove 27.2.1.2/3.  (Same rationale as issue 238: incorrect and unnecessary.)</p>
18157
18158 <p>27.7.1.3/1 Change:</p>
18159
18160 <blockquote>
18161 <p>
18162 1- Returns: If the input sequence has a read position available,
18163 returns traits::to_int_type(*gptr()).  Otherwise, returns
18164 traits::eof().
18165 </p>
18166 </blockquote>
18167
18168 <p>to:</p>
18169
18170 <blockquote>
18171 <p>
18172 1- Returns: If the input sequence has a read position available,
18173 returns traits::to_int_type(*gptr()).  Otherwise, returns
18174 traits::eof().  Any character in the underlying buffer which has been
18175 initialized is considered to be part of the input sequence.
18176 </p>
18177 </blockquote>
18178
18179 <p>27.7.1.3/9 Change:</p>
18180
18181 <blockquote>
18182 <p>
18183 -9- Notes: The function can make a write position available only if (
18184 mode &amp; ios_base::out) != 0. To make a write position available, the
18185 function reallocates (or initially allocates) an array object with a
18186 sufficient number of elements to hold the current array object (if
18187 any), plus one additional write position. If ( mode &amp; ios_base::in) !=
18188 0, the function alters the read end pointer egptr() to point just past
18189 the new write position (as does the write end pointer epptr()).
18190 </p>
18191 </blockquote>
18192
18193 <p>to:</p>
18194
18195 <blockquote>
18196 <p>
18197 -9- The function can make a write position available only if ( mode &amp;
18198 ios_base::out) != 0. To make a write position available, the function
18199 reallocates (or initially allocates) an array object with a sufficient
18200 number of elements to hold the current array object (if any), plus one
18201 additional write position. If ( mode &amp; ios_base::in) != 0, the
18202 function alters the read end pointer egptr() to point just past the
18203 new write position.
18204 </p>
18205 </blockquote>
18206
18207 <p>27.7.1.3/12 Change:</p>
18208
18209 <blockquote>
18210 <p>
18211 -12- _ If (newoff + off) &lt; 0, or (xend - xbeg) &lt; (newoff + off), the
18212 positioning operation fails. Otherwise, the function assigns xbeg +
18213 newoff + off to the next pointer xnext .
18214 </p>
18215 </blockquote>
18216
18217 <p>to:</p>
18218
18219 <blockquote>
18220 <p>
18221 -12- _ If (newoff + off) &lt; 0, or if (newoff + off) refers to an
18222 uninitialized character (as defined in 27.7.1.3 [stringbuf.members]
18223 paragraph 1), the positioning operation fails. Otherwise, the function
18224 assigns xbeg + newoff + off to the next pointer xnext .
18225 </p>
18226 </blockquote>
18227
18228 <p><i>[post-Kona: Howard provided wording.  At Kona the LWG agreed that
18229   something along these lines was a good idea, but the original
18230   proposed resolution didn't say enough about the effect of various
18231   member functions on the underlying character sequences.]</i></p>
18232
18233
18234
18235
18236 <p><b>Rationale:</b></p>
18237 <p>The current basic_stringbuf description is over-constrained in such
18238 a way as to prohibit vendors from making this the high-performance
18239 in-memory stream it was meant to be.  The fundamental problem is that
18240 the pointers: eback(), gptr(), egptr(), pbase(), pptr(), epptr() are
18241 observable from a derived client, and the current description
18242 restricts the range [pbase(), epptr()) from being grown geometrically.
18243 This change allows, but does not require, geometric growth of this
18244 range.</p>
18245
18246 <p>Backwards compatibility issues: These changes will break code that
18247 derives from basic_stringbuf, observes epptr(), and depends upon
18248 [pbase(), epptr()) growing by one character on each call to overflow()
18249 (i.e. test suites).  Otherwise there are no backwards compatibility
18250 issues.</p>
18251
18252 <p>27.7.1.1/2: The non-normative note is non-binding, and if it were
18253 binding, would be over specification.  The recommended change focuses
18254 on the important observable fact.</p>
18255
18256 <p>27.7.1.1/3: This change does two things: 1.  It describes exactly
18257 what must happen in terms of the sequences.  The terms "input
18258 sequence" and "output sequence" are not well defined.  2.  It
18259 introduces a common extension: open with app or ate mode.  I concur
18260 with issue 238 that paragraph 4 is both wrong and unnecessary.</p>
18261
18262 <p>27.7.1.2/1: This change is the crux of the efficiency issue.  The
18263 resultant basic_string is not dependent upon epptr(), and thus
18264 implementors are free to grow the underlying buffer geometrically
18265 during overflow() *and* place epptr() at the end of that buffer.</p>
18266
18267 <p>27.7.1.2/2:  Made consistent with the proposed 27.7.1.1/3.</p>
18268
18269 <p>27.7.1.3/1: Clarifies that characters written to the stream beyond
18270 the initially specified string are available for reading in an i/o
18271 basic_streambuf.</p>
18272
18273 <p>27.7.1.3/9: Made normative by removing "Notes:", and removed the
18274 trailing parenthetical comment concerning epptr().</p>
18275
18276 <p>27.7.1.3/12: Restricting the positioning to [xbeg, xend) is no
18277 longer allowable since [pbase(), epptr()) may now contain
18278 uninitialized characters.  Positioning is only allowable over the
18279 initialized range.</p>
18280
18281
18282
18283
18284
18285 <hr>
18286 <h3><a name="434"></a>434. bitset::to_string() hard to use</h3>
18287 <p><b>Section:</b> 23.3.5.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
18288  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-10-15</p>
18289 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.members">issues</a> in [bitset.members].</p>
18290 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
18291 <p><b>Discussion:</b></p>
18292 <p>
18293 It has been pointed out a number of times that the bitset to_string() member
18294 function template is tedious to use since callers must explicitly specify the
18295 entire template argument list (3 arguments). At least two implementations
18296 provide a number of overloads of this template to make it easier to use.
18297 </p>
18298
18299
18300
18301 <p><b>Proposed resolution:</b></p>
18302 <p>In order to allow callers to specify no template arguments at all, just the
18303 first one (charT), or the first 2 (charT and traits), in addition to all
18304 three template arguments, add the following three overloads to both the
18305 interface (declarations only) of the class template bitset as well as to
18306 section 23.3.5.2, immediately after p34, the Returns clause of the existing
18307 to_string() member function template:</p>
18308
18309 <pre>    template &lt;class charT, class traits&gt;
18310     basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
18311     to_string () const;
18312
18313     -34.1- Returns: to_string&lt;charT, traits, allocator&lt;charT&gt; &gt;().
18314
18315     template &lt;class charT&gt;
18316     basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
18317     to_string () const;
18318
18319     -34.2- Returns: to_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;().
18320
18321     basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
18322     to_string () const;
18323
18324     -34.3- Returns: to_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;().
18325 </pre>
18326
18327 <p><i>[Kona: the LWG agrees that this is an improvement over the
18328   status quo.  Dietmar thought about an alternative using a proxy
18329   object but now believes that the proposed resolution above is the
18330   right choice.
18331 ]</i></p>
18332
18333
18334
18335
18336
18337
18338
18339
18340 <hr>
18341 <h3><a name="435"></a>435. bug in DR 25</h3>
18342 <p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
18343  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-10-15</p>
18344 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
18345 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
18346 <p><b>Discussion:</b></p>
18347
18348 <p>
18349 It has been pointed out that the proposed resolution in DR 25 may not be
18350 quite up to snuff: <br>
18351 http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html
18352 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#25<br>
18353 </p>
18354
18355 <p>
18356 It looks like Petur is right. The complete corrected text is copied below.
18357 I think we may have have been confused by the reference to 22.2.2.2.2 and
18358 the subsequent description of `n' which actually talks about the second
18359 argument to sputn(), not about the number of fill characters to pad with.
18360 </p>
18361
18362 <p>
18363 So the question is: was the original text correct? If the intent was to
18364 follow classic iostreams then it most likely wasn't, since setting width()
18365 to less than the length of the string doesn't truncate it on output. This
18366 is also the behavior of most implementations (except for SGI's standard
18367 iostreams where the operator does truncate).
18368 </p>
18369
18370
18371
18372 <p><b>Proposed resolution:</b></p>
18373 <p>Change the text in 21.3.7.9, p4 from</p>
18374     <blockquote><p>
18375     If bool(k) is true, inserts characters as if by calling
18376     os.rdbuf()-&gt;sputn(str.data(), n), padding as described in stage 3
18377     of lib.facet.num.put.virtuals, where n is the larger of os.width()
18378     and str.size();
18379     </p></blockquote>
18380 <p>to</p>
18381     <blockquote><p>
18382     If bool(k) is true, determines padding as described in
18383     lib.facet.num.put.virtuals, and then inserts the resulting
18384     sequence of characters <tt>seq</tt> as if by calling
18385     <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where <tt>n</tt> is the larger of
18386     <tt>os.width()</tt> and <tt>str.size()</tt>;
18387      </p></blockquote>
18388
18389 <p><i>[Kona: it appears that neither the original wording, DR25, nor the
18390   proposed resolution, is quite what we want.  We want to say that
18391   the string will be output, padded to os.width() if necessary.  We
18392   don't want to duplicate the padding rules in clause 22, because
18393   they're complicated, but we need to be careful because they weren't
18394   quite written with quite this case in mind.  We need to say what
18395   the character sequence is, and then defer to clause 22.  Post-Kona:
18396   Benjamin provided wording.]</i></p>
18397
18398
18399
18400
18401
18402
18403
18404 <hr>
18405 <h3><a name="436"></a>436. are cv-qualified facet types valid facets?</h3>
18406 <p><b>Section:</b> 22.1.1.1.2 [locale.facet] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
18407  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-10-15</p>
18408 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
18409 <p><b>Discussion:</b></p>
18410 <p>
18411 Is "const std::ctype&lt;char&gt;" a valid template argument to has_facet, use_facet,
18412 and the locale template ctor? And if so, does it designate the same Facet as
18413 the non-const "std::ctype&lt;char&gt;?" What about "volatile std::ctype&lt;char&gt;?"
18414 Different implementations behave differently: some fail to compile, others
18415 accept such types but behave inconsistently.
18416 </p>
18417
18418
18419 <p><b>Proposed resolution:</b></p>
18420 <p>Change 22.1.1.1.2, p1 to read:</p>
18421
18422 <p>Template parameters in this clause which are required to be facets
18423 are those named Facet in declarations. A program that passes a type
18424 that is not a facet, or a type that refers to volatile-qualified
18425 facet, as an (explicit or deduced) template parameter to a locale
18426 function expecting a facet, is ill-formed.  A const-qualified facet is
18427 a valid template argument to any locale function that expects a Facet
18428 template parameter.</p>
18429
18430 <p><i>[Kona: changed the last sentence from a footnote to normative
18431 text.]</i></p>
18432
18433
18434
18435
18436
18437
18438 <hr>
18439 <h3><a name="438"></a>438. Ambiguity in the "do the right thing" clause</h3>
18440 <p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
18441  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2003-10-20</p>
18442 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
18443 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
18444 <p><b>Discussion:</b></p>
18445
18446 <p>Section 23.1.1 [sequence.reqmts], paragraphs 9-11, fixed up the problem
18447 noticed with statements like:</p>
18448 <pre>vector&lt;int&gt; v(10, 1);
18449 </pre>
18450
18451 <p>The intent of the above statement was to construct with:</p>
18452 <pre>vector(size_type, const value_type&amp;);
18453 </pre>
18454
18455 <p>but early implementations failed to compile as they bound to:</p>
18456 <pre>template &lt;class InputIterator&gt;
18457 vector(InputIterator f, InputIterator l);
18458 </pre>
18459 <p>instead.</p>
18460
18461 <p>Paragraphs 9-11 say that if InputIterator is an integral type, then the
18462 member template constructor will have the same effect as:</p>
18463 <pre>vector&lt;static_cast&lt;size_type&gt;(f), static_cast&lt;value_type&gt;(l));
18464 </pre>
18465 <p>(and similarly for the other member template functions of sequences).</p>
18466
18467 <p>There is also a note that describes one implementation technique:</p>
18468 <blockquote><p>
18469    One way that sequence implementors can satisfy this requirement is to
18470    specialize the member template for every integral type.
18471 </p></blockquote>
18472
18473 <p>This might look something like:</p>
18474 <blockquote>
18475 <pre>template &lt;class T&gt;
18476 struct vector
18477 {
18478      typedef unsigned size_type;
18479
18480      explicit vector(size_type) {}
18481      vector(size_type, const T&amp;) {}
18482
18483      template &lt;class I&gt;
18484      vector(I, I);
18485
18486      // ...
18487 };
18488
18489 template &lt;class T&gt;
18490 template &lt;class I&gt;
18491 vector&lt;T&gt;::vector(I, I) { ... }
18492
18493 template &lt;&gt;
18494 template &lt;&gt;
18495 vector&lt;int&gt;::vector(int, int) { ... }
18496
18497 template &lt;&gt;
18498 template &lt;&gt;
18499 vector&lt;int&gt;::vector(unsigned, unsigned) { ... }
18500
18501 //  ...
18502 </pre>
18503 </blockquote>
18504
18505 <p>Label this solution 'A'.</p>
18506
18507 <p>The standard also says:</p>
18508 <blockquote><p>
18509  Less cumbersome implementation techniques also exist.
18510 </p></blockquote>
18511 <p>
18512 A popular technique is to not specialize as above, but instead catch
18513 every call with the member template, detect the type of InputIterator,
18514 and then redirect to the correct logic.  Something like:
18515 </p>
18516 <blockquote>
18517 <pre>template &lt;class T&gt;
18518 template &lt;class I&gt;
18519 vector&lt;T&gt;::vector(I f, I l)
18520 {
18521      choose_init(f, l, int2type&lt;is_integral&lt;I&gt;::value&gt;());
18522 }
18523
18524 template &lt;class T&gt;
18525 template &lt;class I&gt;
18526 vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;false&gt;)
18527 {
18528     // construct with iterators
18529 }
18530
18531 template &lt;class T&gt;
18532 template &lt;class I&gt;
18533 vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;true&gt;)
18534 {
18535     size_type sz = static_cast&lt;size_type&gt;(f);
18536     value_type v = static_cast&lt;value_type&gt;(l);
18537     // construct with sz,v
18538 }
18539 </pre>
18540 </blockquote>
18541
18542 <p>Label this solution 'B'.</p>
18543
18544 <p>Both of these solutions solve the case the standard specifically
18545 mentions:</p>
18546 <pre>vector&lt;int&gt; v(10, 1);  // ok, vector size 10, initialized to 1
18547 </pre>
18548
18549 <p>
18550 However, (and here is the problem), the two solutions have different
18551 behavior in some cases where the value_type of the sequence is not an
18552 integral type.  For example consider:
18553 </p>
18554 <blockquote><pre>     pair&lt;char, char&gt;                     p('a', 'b');
18555      vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
18556 </pre></blockquote>
18557 <p>
18558 The second line of this snippet is likely an error.  Solution A catches
18559 the error and refuses to compile.  The reason is that there is no
18560 specialization of the member template constructor that looks like:
18561 </p>
18562 <pre>template &lt;&gt;
18563 template &lt;&gt;
18564 vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;::vector(char, char) { ... }
18565 </pre>
18566
18567 <p>
18568 So the expression binds to the unspecialized member template
18569 constructor, and then fails (compile time) because char is not an
18570 InputIterator.
18571 </p>
18572
18573 <p>
18574 Solution B compiles the above example though.  'a' is casted to an
18575 unsigned integral type and used to size the outer vector.  'b' is
18576 static casted to the inner vector using it's explicit constructor:
18577 </p>
18578
18579 <pre>explicit vector(size_type n);
18580 </pre>
18581
18582 <p>
18583 and so you end up with a static_cast&lt;size_type&gt;('a') by
18584 static_cast&lt;size_type&gt;('b') matrix.
18585 </p>
18586
18587 <p>
18588 It is certainly possible that this is what the coder intended.  But the
18589 explicit qualifier on the inner vector has been thwarted at any rate.
18590 </p>
18591
18592 <p>
18593 The standard is not clear whether the expression:
18594 </p>
18595
18596 <pre>     vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
18597 </pre>
18598
18599 <p>
18600 (and similar expressions) are:
18601 </p>
18602
18603 <ol>
18604 <li>  undefined behavior.</li>
18605 <li>  illegal and must be rejected.</li>
18606 <li>  legal and must be accepted.</li>
18607 </ol>
18608
18609 <p>My preference is listed in the order presented.</p>
18610
18611 <p>There are still other techniques for implementing the requirements of
18612 paragraphs 9-11, namely the "restricted template technique" (e.g.
18613 enable_if).  This technique is the most compact and easy way of coding
18614 the requirements, and has the behavior of #2 (rejects the above
18615 expression).
18616 </p>
18617
18618 <p>
18619 Choosing 1 would allow all implementation techniques I'm aware of.
18620 Choosing 2 would allow only solution 'A' and the enable_if technique.
18621 Choosing 3 would allow only solution 'B'.
18622 </p>
18623
18624 <p>
18625 Possible wording for a future standard if we wanted to actively reject
18626 the expression above would be to change "static_cast" in paragraphs
18627 9-11 to "implicit_cast" where that is defined by:
18628 </p>
18629
18630 <blockquote>
18631 <pre>template &lt;class T, class U&gt;
18632 inline
18633 T implicit_cast(const U&amp; u)
18634 {
18635      return u;
18636 }
18637 </pre>
18638 </blockquote>
18639
18640
18641
18642 <p><b>Proposed resolution:</b></p>
18643
18644 <p>Replace 23.1.1 [sequence.reqmts] paragraphs 9 - 11 with:</p>
18645
18646 <p>For every sequence defined in this clause and in clause lib.strings:</p>
18647
18648 <ul>
18649   <li>
18650     <p>If the constructor</p>
18651        <pre>       template &lt;class InputIterator&gt;
18652        X(InputIterator f, InputIterator l,
18653          const allocator_type&amp; a = allocator_type())
18654        </pre>
18655     <p>is called with a type InputIterator that does not qualify as
18656     an input iterator, then the constructor will behave as if the
18657     overloaded constructor:</p>
18658        <pre>       X(size_type, const value_type&amp; = value_type(),
18659          const allocator_type&amp; = allocator_type())
18660        </pre>
18661     <p>were called instead, with the arguments static_cast&lt;size_type&gt;(f), l and a, respectively.</p>
18662   </li>
18663
18664   <li>
18665     <p>If the member functions of the forms:</p>
18666        <pre>       template &lt;class InputIterator&gt;          //  such as  insert()
18667        rt fx1(iterator p, InputIterator f, InputIterator l);
18668
18669        template &lt;class InputIterator&gt;          //  such as  append(), assign()
18670        rt fx2(InputIterator f, InputIterator l);
18671
18672        template &lt;class InputIterator&gt;          //  such as  replace()
18673        rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l);
18674        </pre>
18675     <p>are called with a type InputIterator that does not qualify as
18676     an input iterator, then these functions will behave as if the
18677     overloaded member functions:</p>
18678        <pre>       rt fx1(iterator, size_type, const value_type&amp;);
18679
18680        rt fx2(size_type, const value_type&amp;);
18681
18682        rt fx3(iterator, iterator, size_type, const value_type&amp;);
18683        </pre>
18684     <p>were called instead, with the same arguments.</p>
18685   </li>
18686 </ul>
18687
18688 <p>In the previous paragraph the alternative binding will fail if f
18689 is not implicitly convertible to X::size_type or if l is not implicitly
18690 convertible to X::value_type.</p>
18691
18692 <p>
18693 The extent to which an implementation determines that a type cannot be
18694 an input iterator is unspecified, except that as a minimum integral
18695 types shall not qualify as input iterators.
18696 </p>
18697
18698
18699
18700 <p><i>[
18701 Kona: agreed that the current standard requires <tt>v('a', 'b')</tt>
18702 to be accepted, and also agreed that this is surprising behavior.  The
18703 LWG considered several options, including something like
18704 implicit_cast, which doesn't appear to be quite what we want.  We
18705 considered Howards three options: allow acceptance or rejection,
18706 require rejection as a compile time error, and require acceptance.  By
18707 straw poll (1-6-1), we chose to require a compile time error.
18708 Post-Kona: Howard provided wording.
18709 ]</i></p>
18710
18711
18712 <p><i>[
18713 Sydney: The LWG agreed with this general direction, but there was some
18714 discomfort with the wording in the original proposed resolution.
18715 Howard submitted new wording, and we will review this again in
18716 Redmond.
18717 ]</i></p>
18718
18719
18720 <p><i>[Redmond: one very small change in wording: the first argument
18721   is cast to size_t.  This fixes the problem of something like
18722   <tt>vector&lt;vector&lt;int&gt; &gt;(5, 5)</tt>, where int is not
18723   implicitly convertible to the value type.]</i></p>
18724
18725
18726
18727
18728 <p><b>Rationale:</b></p>
18729 <p>The proposed resolution fixes:</p>
18730
18731 <pre>  vector&lt;int&gt; v(10, 1);
18732 </pre>
18733
18734 <p>
18735 since as integral types 10 and 1 must be disqualified as input
18736 iterators and therefore the (size,value) constructor is called (as
18737 if).</p>
18738
18739 <p>The proposed resolution breaks:</p>
18740
18741 <pre>  vector&lt;vector&lt;T&gt; &gt; v(10, 1);
18742 </pre>
18743
18744 <p>
18745 because the integral type 1 is not *implicitly* convertible to
18746 vector&lt;T&gt;.  The wording above requires a diagnostic.</p>
18747
18748 <p>
18749 The proposed resolution leaves the behavior of the following code
18750 unspecified.
18751 </p>
18752
18753 <pre>  struct A
18754   {
18755     operator int () const {return 10;}
18756   };
18757
18758   struct B
18759   {
18760     B(A) {}
18761   };
18762
18763   vector&lt;B&gt; v(A(), A());
18764 </pre>
18765
18766 <p>
18767 The implementation may or may not detect that A is not an input
18768 iterator and employee the (size,value) constructor.  Note though that
18769 in the above example if the B(A) constructor is qualified explicit,
18770 then the implementation must reject the constructor as A is no longer
18771 implicitly convertible to B.
18772 </p>
18773
18774
18775
18776
18777
18778 <hr>
18779 <h3><a name="441"></a>441. Is fpos::state const?</h3>
18780 <p><b>Section:</b> 27.4.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
18781  <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-17</p>
18782 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p>
18783 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
18784 <p><b>Discussion:</b></p>
18785 <p>
18786 In section 27.4.3.1 [fpos.members] fpos&lt;stateT&gt;::state() is declared
18787 non const, but in section 27.4.3 [fpos] it is declared const.
18788 </p>
18789
18790
18791 <p><b>Proposed resolution:</b></p>
18792 <p>
18793 In section 27.4.3.1 [fpos.members], change the declaration of
18794 <tt>fpos&lt;stateT&gt;::state()</tt> to const.
18795 </p>
18796
18797
18798
18799
18800
18801 <hr>
18802 <h3><a name="442"></a>442. sentry::operator bool() inconsistent signature</h3>
18803 <p><b>Section:</b> 27.6.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
18804  <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-18</p>
18805 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ostream::sentry">active issues</a> in [ostream::sentry].</p>
18806 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
18807 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
18808 <p><b>Discussion:</b></p>
18809 <p>
18810 In section 27.6.2.4 [ostream::sentry] paragraph 4, in description part
18811 basic_ostream&lt;charT, traits&gt;::sentry::operator bool() is declared
18812 as non const, but in section 27.6.2.3, in synopsis it is declared
18813 const.
18814 </p>
18815
18816
18817 <p><b>Proposed resolution:</b></p>
18818 <p>
18819 In section 27.6.2.4 [ostream::sentry] paragraph 4, change the declaration
18820 of <tt>sentry::operator bool()</tt> to const.
18821 </p>
18822
18823
18824
18825
18826
18827 <hr>
18828 <h3><a name="443"></a>443. filebuf::close() inconsistent use of EOF</h3>
18829 <p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
18830  <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-20</p>
18831 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#filebuf.members">active issues</a> in [filebuf.members].</p>
18832 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.members].</p>
18833 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
18834 <p><b>Discussion:</b></p>
18835 <p>
18836 In section 27.8.1.4 [filebuf.members] par6, in effects description of
18837 basic_filebuf&lt;charT, traits&gt;::close(), overflow(EOF) is used twice;
18838 should be overflow(traits::eof()).
18839 </p>
18840
18841
18842 <p><b>Proposed resolution:</b></p>
18843 <p>
18844 Change overflow(EOF) to overflow(traits::eof()).
18845 </p>
18846
18847
18848
18849
18850
18851 <hr>
18852 <h3><a name="444"></a>444. Bad use of casts in fstream</h3>
18853 <p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
18854  <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-20</p>
18855 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
18856 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
18857 <p><b>Discussion:</b></p>
18858 <p>27.8.1.9 [ifstream.members] p1, 27.8.1.13 [ofstream.members] p1,
18859 27.8.1.17 [fstream.members] p1 seems have same problem as exposed in
18860 LWG issue
18861 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>.
18862 </p>
18863
18864
18865 <p><b>Proposed resolution:</b></p>
18866
18867 <p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away
18868  constness. The other two places are stylistic: we could change the
18869  C-style casts to const_cast. Post-Sydney: Howard provided wording.
18870 ]</i></p>
18871
18872
18873 <p>Change 27.8.1.7/1 from:</p>
18874 <blockquote><p>
18875   Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
18876 </p></blockquote>
18877
18878 <p>to:</p>
18879 <blockquote><p>
18880   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
18881 </p></blockquote>
18882
18883 <p>Change 27.8.1.10/1 from:</p>
18884 <blockquote><p>
18885   Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
18886 </p></blockquote>
18887
18888 <p>to:</p>
18889 <blockquote><p>
18890   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
18891 </p></blockquote>
18892
18893 <p>Change 27.8.1.13/1 from:</p>
18894 <blockquote><p>
18895   Returns: &amp;sb.
18896 </p></blockquote>
18897
18898 <p>to:</p>
18899 <blockquote><p>
18900   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
18901 </p></blockquote>
18902
18903
18904
18905
18906
18907
18908
18909
18910 <hr>
18911 <h3><a name="445"></a>445. iterator_traits::reference unspecified for some iterator categories</h3>
18912 <p><b>Section:</b> 24.3.1 [iterator.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
18913  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2003-12-09</p>
18914 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
18915 <p><b>Discussion:</b></p>
18916 <p>
18917 The standard places no restrictions at all on the reference type
18918 of input, output, or forward iterators (for forward iterators it
18919 only specifies that *x must be value_type&amp; and doesn't mention
18920 the reference type).  Bidirectional iterators' reference type is
18921 restricted only by implication, since the base iterator's
18922 reference type is used as the return type of reverse_iterator's
18923 operator*, which must be T&amp; in order to be a conforming forward
18924 iterator.
18925 </p>
18926
18927 <p>
18928 Here's what I think we ought to be able to expect from an input
18929 or forward iterator's reference type R, where a is an iterator
18930 and V is its value_type
18931 </p>
18932
18933 <ul>
18934   <li>
18935       *a is convertible to R
18936   </li>
18937
18938   <li>
18939       R is convertible to V
18940   </li>
18941
18942   <li>
18943       static_cast&lt;V&gt;(static_cast&lt;R&gt;(*a)) is equivalent to
18944       static_cast&lt;V&gt;(*a)
18945   </li>
18946 </ul>
18947
18948 <p>A mutable forward iterator ought to satisfy, for x of type V:</p>
18949   <pre>      { R r = *a; r = x; } is equivalent to *a = x;
18950   </pre>
18951
18952 <p>
18953 I think these requirements capture existing container iterators
18954 (including vector&lt;bool&gt;'s), but render istream_iterator invalid;
18955 its reference type would have to be changed to a constant
18956 reference.
18957 </p>
18958
18959
18960 <p>
18961 (Jeremy Siek) During the discussion in Sydney, it was felt that a
18962 simpler long term solution for this was needed. The solution proposed
18963 was to require <tt>reference</tt> to be the same type as <tt>*a</tt>
18964 and <tt>pointer</tt> to be the same type as <tt>a-&gt;</tt>.  Most
18965 iterators in the Standard Library already meet this requirement. Some
18966 iterators are output iterators, and do not need to meet the
18967 requirement, and others are only specified through the general
18968 iterator requirements (which will change with this resolution). The
18969 sole case where there is an explicit definition of the reference type
18970 that will need to change is <tt>istreambuf_iterator</tt> which returns
18971 <tt>charT</tt> from <tt>operator*</tt> but has a reference type of
18972 <tt>charT&amp;</tt>. We propose changing the reference type of
18973 <tt>istreambuf_iterator</tt> to <tt>charT</tt>.
18974 </p>
18975
18976 <p>The other option for resolving the issue with <tt>pointer</tt>,
18977   mentioned in the note below, is to remove <tt>pointer</tt>
18978   altogether. I prefer placing requirements on <tt>pointer</tt> to
18979   removing it for two reasons. First, <tt>pointer</tt> will become
18980   useful for implementing iterator adaptors and in particular,
18981   <tt>reverse_iterator</tt> will become more well defined. Second,
18982   removing <tt>pointer</tt> is a rather drastic and publicly-visible
18983   action to take.</p>
18984
18985 <p>The proposed resolution technically enlarges the requirements for
18986 iterators, which means there are existing iterators (such as
18987 <tt>istreambuf_iterator</tt>, and potentially some programmer-defined
18988 iterators) that will no longer meet the requirements. Will this break
18989 existing code? The scenario in which it would is if an algorithm
18990 implementation (say in the Standard Library) is changed to rely on
18991 <tt>iterator_traits::reference</tt>, and then is used with one of the
18992 iterators that do not have an appropriately defined
18993 <tt>iterator_traits::reference</tt>.
18994 </p>
18995
18996
18997 <p>The proposed resolution makes one other subtle change. Previously,
18998 it was required that output iterators have a <tt>difference_type</tt>
18999 and <tt>value_type</tt> of <tt>void</tt>, which means that a forward
19000 iterator could not be an output iterator. This is clearly a mistake,
19001 so I've changed the wording to say that those types may be
19002 <tt>void</tt>.
19003 </p>
19004
19005
19006
19007 <p><b>Proposed resolution:</b></p>
19008
19009 <p>In 24.3.1 [iterator.traits], after:</p>
19010
19011 <blockquote><p>
19012 be defined as the iterator's difference type, value type and iterator
19013 category, respectively.
19014 </p></blockquote>
19015
19016 <p>add</p>
19017
19018 <blockquote><p>
19019 In addition, the types</p>
19020 <pre>iterator_traits&lt;Iterator&gt;::reference
19021 iterator_traits&lt;Iterator&gt;::pointer
19022 </pre>
19023 <p>must be defined as the iterator's reference and pointer types, that
19024 is, the same type as the type of <tt>*a</tt> and <tt>a-&gt;</tt>,
19025 respectively.</p>
19026 </blockquote>
19027
19028 <p>In 24.3.1 [iterator.traits], change:</p>
19029
19030 <blockquote><p>
19031 In the case of an output iterator, the types</p>
19032 <pre>iterator_traits&lt;Iterator&gt;::difference_type
19033 iterator_traits&lt;Iterator&gt;::value_type
19034 </pre>
19035 <p>are both defined as <tt>void</tt>.</p>
19036 </blockquote>
19037
19038 <p>to:</p>
19039 <blockquote><p>
19040 In the case of an output iterator, the types</p>
19041 <pre>iterator_traits&lt;Iterator&gt;::difference_type
19042 iterator_traits&lt;Iterator&gt;::value_type
19043 iterator_traits&lt;Iterator&gt;::reference
19044 iterator_traits&lt;Iterator&gt;::pointer
19045 </pre>
19046 <p>may be defined as <tt>void</tt>.</p>
19047 </blockquote>
19048
19049 <p>In 24.5.3 [istreambuf.iterator], change:</p>
19050 <blockquote>
19051 <pre>typename traits::off_type, charT*, charT&amp;&gt;
19052 </pre>
19053 </blockquote>
19054 <p>to:</p>
19055 <blockquote>
19056 <pre>typename traits::off_type, charT*, charT&gt;
19057 </pre>
19058 </blockquote>
19059
19060 <p><i>[
19061 Redmond: there was concern in Sydney that this might not be the only place
19062 where things were underspecified and needed to be changed.  Jeremy
19063 reviewed iterators in the standard and confirmed that nothing else
19064 needed to be changed.
19065 ]</i></p>
19066
19067
19068
19069
19070
19071
19072
19073
19074
19075 <hr>
19076 <h3><a name="448"></a>448. Random Access Iterators over abstract classes</h3>
19077 <p><b>Section:</b> 24.1.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19078  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-01-07</p>
19079 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
19080 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19081 <p><b>Discussion:</b></p>
19082 <p>
19083 Table 76, the random access iterator requirement table, says that the
19084 return type of a[n] must be "convertible to T".  When an iterator's
19085 value_type T is an abstract class, nothing is convertible to T.
19086 Surely this isn't an intended restriction?
19087 </p>
19088
19089
19090 <p><b>Proposed resolution:</b></p>
19091 <p>
19092 Change the return type to "convertible to T const&amp;".
19093 </p>
19094
19095
19096
19097
19098
19099 <hr>
19100 <h3><a name="449"></a>449. Library Issue 306 Goes Too Far</h3>
19101 <p><b>Section:</b> 18.1 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19102  <b>Submitter:</b> Pete Becker <b>Date:</b> 2004-01-15</p>
19103 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p>
19104 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19105 <p><b>Discussion:</b></p>
19106 <p>Original text:</p>
19107 <blockquote><p>
19108 The macro offsetof accepts a restricted set of type arguments in this
19109 International Standard. type shall be a POD structure or a POD union
19110 (clause 9). The result of applying the offsetof macro to a field that
19111 is a static data member or a function member is undefined."
19112 </p></blockquote>
19113
19114 <p>Revised text:</p>
19115 <blockquote><p>
19116 "If type is not a POD structure or a POD union the results are undefined."
19117 </p></blockquote>
19118
19119 <p>
19120 Looks to me like the revised text should have replaced only the second
19121 sentence. It doesn't make sense standing alone.
19122 </p>
19123
19124
19125
19126 <p><b>Proposed resolution:</b></p>
19127 <p>Change 18.1, paragraph 5, to:</p>
19128
19129 <blockquote><p>
19130 The macro offsetof accepts a restricted set of type arguments in this
19131 International Standard.  If type is not a POD structure or a POD union
19132 the results are undefined.  The result of applying the offsetof macro
19133 to a field that is a static data member or a function member is
19134 undefined."
19135 </p></blockquote>
19136
19137
19138
19139
19140
19141 <hr>
19142 <h3><a name="453"></a>453. basic_stringbuf::seekoff need not always fail for an empty stream</h3>
19143 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
19144  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
19145 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
19146 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
19147 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
19148 <p><b>Discussion:</b></p>
19149 <pre>  pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
19150                                     ios_base::openmode);
19151 </pre>
19152 <p>
19153 is obliged to fail if nothing has been inserted into the stream. This
19154 is unnecessary and undesirable. It should be permissible to seek to
19155 an effective offset of zero.</p>
19156
19157 <p><i>[
19158  Sydney: Agreed that this is an annoying problem: seeking to zero should be
19159  legal. Bill will provide wording.
19160 ]</i></p>
19161
19162
19163
19164
19165 <p><b>Proposed resolution:</b></p>
19166 <p>Change the sentence from:</p>
19167 <blockquote><p>
19168 For a sequence to be positioned, if its next pointer (either
19169 gptr() or pptr()) is a null pointer, the positioning operation
19170 fails.
19171 </p></blockquote>
19172
19173 <p>to:</p>
19174
19175 <blockquote><p>
19176 For a sequence to be positioned, if its next pointer (either
19177 gptr() or pptr()) is a null pointer and the new offset newoff
19178 is nonzero, the positioning operation fails.
19179 </p></blockquote>
19180
19181
19182
19183
19184
19185 <hr>
19186 <h3><a name="455"></a>455. cerr::tie() and wcerr::tie() are overspecified</h3>
19187 <p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
19188  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
19189 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
19190 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
19191 <p><b>Discussion:</b></p>
19192 <p>
19193 Both cerr::tie() and wcerr::tie() are obliged to be null at program
19194 startup. This is overspecification and overkill. It is both traditional
19195 and useful to tie cerr to cout, to ensure that standard output is drained
19196 whenever an error message is written. This behavior should at least be
19197 permitted if not required. Same for wcerr::tie().
19198 </p>
19199
19200
19201 <p><b>Proposed resolution:</b></p>
19202
19203 <p>Add to the description of cerr:</p>
19204 <blockquote><p>
19205 After the object cerr is initialized, cerr.tie() returns &amp;cout.
19206 Its state is otherwise the same as required for basic_ios&lt;char&gt;::init
19207 (lib.basic.ios.cons).
19208 </p></blockquote>
19209
19210 <p>Add to the description of wcerr:</p>
19211
19212 <blockquote><p>
19213 After the object wcerr is initialized, wcerr.tie() returns &amp;wcout.
19214 Its state is otherwise the same as required for basic_ios&lt;wchar_t&gt;::init
19215 (lib.basic.ios.cons).
19216 </p></blockquote>
19217
19218 <p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just
19219   permit, cout and cerr to be tied on startup.  Pre-Redmond: Bill will
19220   provide wording.]</i></p>
19221
19222
19223
19224
19225
19226
19227 <hr>
19228 <h3><a name="456"></a>456. Traditional C header files are overspecified</h3>
19229 <p><b>Section:</b> 17.4.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19230  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
19231 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</p>
19232 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19233 <p><b>Discussion:</b></p>
19234
19235 <p>The C++ Standard effectively requires that the traditional C headers
19236 (of the form &lt;xxx.h&gt;) be defined in terms of the newer C++
19237 headers (of the form &lt;cxxx&gt;). Clauses 17.4.1.2/4 and D.5 combine
19238 to require that:</p>
19239
19240 <ul>
19241  <li>Including the header &lt;cxxx&gt; declares a C name in namespace std.</li>
19242
19243  <li> Including the header &lt;xxx.h&gt; declares a C name in namespace std
19244     (effectively by including &lt;cxxx&gt;), then imports it into the global
19245     namespace with an individual using declaration.</li>
19246 </ul>
19247
19248 <p>
19249 The rules were left in this form despited repeated and heated objections
19250 from several compiler vendors. The C headers are often beyond the direct
19251 control of C++ implementors. In some organizations, it's all they can do
19252 to get a few #ifdef __cplusplus tests added. Third-party library vendors
19253 can perhaps wrap the C headers. But neither of these approaches supports
19254 the drastic restructuring required by the C++ Standard. As a result, it is
19255 still widespread practice to ignore this conformance requirement, nearly
19256 seven years after the committee last debated this topic. Instead, what is
19257 often implemented is:
19258 </p>
19259
19260 <ul>
19261  <li> Including the header &lt;xxx.h&gt; declares a C name in the
19262  global namespace.</li>
19263
19264  <li> Including the header &lt;cxxx&gt; declares a C name in the
19265  global namespace (effectively by including &lt;xxx.h&gt;), then
19266  imports it into namespace std with an individual using declaration.</li>
19267 </ul>
19268
19269 <p>
19270 The practical benefit for implementors with the second approach is that
19271 they can use existing C library headers, as they are pretty much obliged
19272 to do. The practical cost for programmers facing a mix of implementations
19273 is that they have to assume weaker rules:</p>
19274
19275 <ul>
19276   <li> If you want to assuredly declare a C name in the global
19277   namespace, include &lt;xxx.h&gt;. You may or may not also get the
19278   declaration in namespace std.</li>
19279
19280   <li> If you want to assuredly declare a C name in namespace std,
19281   include &lt;cxxx&gt;. You may or may not also get the declaration in
19282   the global namespace.</li>
19283 </ul>
19284
19285 <p>
19286 There also exists the <i>possibility</i> of subtle differences due to
19287 Koenig lookup, but there are so few non-builtin types defined in the C
19288 headers that I've yet to see an example of any real problems in this
19289 area.
19290 </p>
19291
19292 <p>
19293 It is worth observing that the rate at which programmers fall afoul of
19294 these differences has remained small, at least as measured by newsgroup
19295 postings and our own bug reports. (By an overwhelming margin, the
19296 commonest problem is still that programmers include &lt;string&gt; and can't
19297 understand why the typename string isn't defined -- this a decade after
19298 the committee invented namespace std, nominally for the benefit of all
19299 programmers.)
19300 </p>
19301
19302 <p>
19303 We should accept the fact that we made a serious mistake and rectify it,
19304 however belatedly, by explicitly allowing either of the two schemes for
19305 declaring C names in headers.
19306 </p>
19307
19308 <p><i>[Sydney: This issue has been debated many times, and will
19309   certainly have to be discussed in full committee before any action
19310   can be taken.  However, the preliminary sentiment of the LWG was in
19311   favor of the change.  (6 yes, 0 no, 2 abstain) Robert Klarer
19312   suggests that we might also want to undeprecate the
19313   C-style <tt>.h</tt> headers.]</i></p>
19314
19315
19316
19317
19318 <p><b>Proposed resolution:</b></p>
19319 <p>
19320 Add to 17.4.1.2 [headers], para. 4:
19321 </p>
19322
19323 <blockquote><p>
19324 Except as noted in clauses 18 through 27 and Annex D, the contents of each
19325 header <i>cname</i> shall be the same as that of the corresponding header
19326 <i>name.h</i>, as specified in ISO/IEC 9899:1990 Programming Languages C (Clause
19327 7), or ISO/IEC:1990 Programming Languages-C AMENDMENT 1: C Integrity, (Clause
19328 7), as appropriate, as if by inclusion. In the C++ Standard Library, however,
19329 the declarations <del>and definitions</del> (except for names which are defined
19330 as macros in C) are within namespace scope (3.3.5) of the namespace std.
19331 <ins>It is unspecified whether these names are first declared within the global
19332 namespace scope and are then injected into namespace std by explicit
19333 using-declarations (7.3.3 [namespace.udecl]).</ins>
19334 </p></blockquote>
19335
19336 <p>
19337 Change D.5 [depr.c.headers], para. 2-3:
19338 </p>
19339
19340 <blockquote>
19341 <p>
19342 -2- Every C header, each of which has a name of the form <i>name.h</i>, behaves
19343 as if each name placed in the Standard library namespace by the corresponding
19344 <i>cname</i> header is <del>also</del> placed within the <ins>global</ins>
19345 namespace scope<ins>.</ins> <del>of the namespace <tt>std</tt> and is followed
19346 by an explicit <i>using-declaration</i> (7.3.3 [namespace.udecl]).</del>
19347 <ins>It is unspecified whether these names are first declared or defined within
19348 namespace scope (3.3.5 [basic.scope.namespace]) of the namespace
19349 <tt>std</tt> and are then injected into the global namespace scope by explicit
19350 using-declarations (7.3.3 [namespace.udecl]).</ins>
19351 </p>
19352 <p>
19353 -3- [<i>Example:</i> The header <tt>&lt;cstdlib&gt;</tt> <ins>assuredly</ins>
19354 provides its declarations and definitions within the namespace <tt>std</tt>.
19355 <ins>It may also provide these names within the global namespace.</ins> The
19356 header <tt>&lt;stdlib.h&gt;</tt> <del>makes these available also in</del>
19357 <ins>assuredly provides the same declarations and definitions within</ins> the
19358 global namespace, much as in the C Standard. <ins>It may also provide these
19359 names within the namespace <tt>std</tt>.</ins> <i>-- end example</i>]
19360 </p>
19361 </blockquote>
19362
19363
19364
19365
19366
19367 <hr>
19368 <h3><a name="457"></a>457. bitset constructor: incorrect number of initialized bits</h3>
19369 <p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
19370  <b>Submitter:</b> Dag Henriksson <b>Date:</b> 2004-01-30</p>
19371 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
19372 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
19373 <p><b>Discussion:</b></p>
19374 <p>
19375 The constructor from unsigned long says it initializes "the first M
19376 bit positions to the corresponding bit values in val. M is the smaller
19377 of N and the value CHAR_BIT * sizeof(unsigned long)."
19378 </p>
19379
19380 <p>
19381 Object-representation vs. value-representation strikes again. CHAR_BIT *
19382 sizeof (unsigned long) does not give us the number of bits an unsigned long
19383 uses to hold the value. Thus, the first M bit position above is not
19384 guaranteed to have any corresponding bit values in val.
19385 </p>
19386
19387
19388 <p><b>Proposed resolution:</b></p>
19389 <p>In 23.3.5.1 [bitset.cons] paragraph 2, change "M is the smaller of
19390   N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
19391   "<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in
19392   the value representation (section 3.9 [basic.types]) of <tt>unsigned
19393   long</tt>."
19394 </p>
19395
19396
19397
19398
19399
19400 <hr>
19401 <h3><a name="460"></a>460. Default modes missing from basic_fstream member specifications</h3>
19402 <p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
19403  <b>Submitter:</b> Ben Hutchings <b>Date:</b> 2004-04-01</p>
19404 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
19405 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
19406 <p><b>Discussion:</b></p>
19407 <p>
19408 The second parameters of the non-default constructor and of the open
19409 member function for basic_fstream, named "mode", are optional
19410 according to the class declaration in 27.8.1.11 [lib.fstream].  The
19411 specifications of these members in 27.8.1.12 [lib.fstream.cons] and
19412 27.8.1.13 lib.fstream.members] disagree with this, though the
19413 constructor declaration has the "explicit" function-specifier implying
19414 that it is intended to be callable with one argument.
19415 </p>
19416
19417
19418 <p><b>Proposed resolution:</b></p>
19419 <p>In 27.8.1.15 [fstream.cons], change</p>
19420 <pre>  explicit basic_fstream(const char* s, ios_base::openmode mode);
19421 </pre>
19422 <p>to</p>
19423 <pre>  explicit basic_fstream(const char* s,
19424                          ios_base::openmode mode = ios_base::in|ios_base::out);
19425 </pre>
19426 <p>In 27.8.1.17 [fstream.members], change</p>
19427 <pre>  void open(const char*s, ios_base::openmode mode);
19428 </pre>
19429 <p>to</p>
19430 <pre>  void open(const char*s,
19431             ios_base::openmode mode = ios_base::in|ios_base::out);
19432 </pre>
19433
19434
19435
19436
19437
19438 <hr>
19439 <h3><a name="461"></a>461. time_get hard or impossible to implement</h3>
19440 <p><b>Section:</b> 22.2.5.1.2 [locale.time.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19441  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-03-23</p>
19442 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19443 <p><b>Discussion:</b></p>
19444 <p>
19445 Template time_get currently contains difficult, if not impossible,
19446 requirements for do_date_order, do_get_time, and do_get_date. All require
19447 the implementation to scan a field generated by the %x or %X conversion
19448 specifier in strftime. Yes, do_date_order can always return no_order, but
19449 that doesn't help the other functions. The problem is that %x can be
19450 nearly anything, and it can vary widely with locales. It's horribly
19451 onerous to have to parse "third sunday after Michaelmas in the year of
19452 our Lord two thousand and three," but that's what we currently ask of
19453 do_get_date. More practically, it leads some people to think that if
19454 %x produces 10.2.04, we should know to look for dots as separators. Still
19455 not easy.
19456 </p>
19457
19458 <p>
19459 Note that this is the <i>opposite</i> effect from the intent stated in the
19460 footnote earlier in this subclause:
19461 </p>
19462
19463 <blockquote><p>
19464 "In other words, user confirmation is required for reliable parsing of
19465 user-entered dates and times, but machine-generated formats can be
19466 parsed reliably. This allows parsers to be aggressive about interpreting
19467 user variations on standard formats."
19468 </p></blockquote>
19469
19470 <p>
19471 We should give both implementers and users an easier and more reliable
19472 alternative: provide a (short) list of alternative delimiters and say
19473 what the default date order is for no_order. For backward compatibility,
19474 and maximum latitude, we can permit an implementation to parse whatever
19475 %x or %X generates, but we shouldn't require it.
19476 </p>
19477
19478
19479 <p><b>Proposed resolution:</b></p>
19480
19481 <p><b>In the description:</b></p>
19482 <pre>iter_type do_get_time(iter_type s, iter_type end, ios_base&amp; str,
19483         ios_base::iostate&amp; err, tm* t) const;
19484 </pre>
19485
19486 <p>
19487 2 Effects: Reads characters starting at suntil it has extracted those
19488 struct tm members, and remaining format characters, used by
19489 time_put&lt;&gt;::put to produce the format specified by 'X', or until it
19490 encounters an error or end of sequence.
19491 </p>
19492
19493 <p><b>change:</b> 'X'</p>
19494
19495 <p><b>to:</b> "%H:%M:%S"</p>
19496
19497
19498 <p>Change</p>
19499 <pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
19500         ios_base::iostate&amp; err, tm* t) const;
19501
19502 4 Effects: Reads characters starting at s until it has extracted those
19503 struct tm members, and remaining format characters, used by
19504 time_put&lt;&gt;::put to produce the format specified by 'x', or until it
19505 encounters an error.
19506 </pre>
19507
19508 <p>to</p>
19509 <pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
19510         ios_base::iostate&amp; err, tm* t) const;
19511 </pre>
19512
19513 <p>
19514 4 Effects: Reads characters starting at s until it has extracted those
19515 struct tm members, and remaining format characters, used by
19516 time_put&lt;&gt;::put to produce one of the following formats, or until it
19517 encounters an error. The format depends on the value returned by
19518 date_order() as follows:
19519 </p>
19520
19521 <pre>        date_order()  format
19522
19523         no_order      "%m/%d/%y"
19524         dmy           "%d/%m/%y"
19525         mdy           "%m/%d/%y"
19526         ymd           "%y/%m/%d"
19527         ydm           "%y/%d/%m"
19528 </pre>
19529 <p>
19530 An implementation may also accept additional implementation-defined formats.
19531 </p>
19532
19533 <p><i>[Redmond: agreed that this is a real problem.  The solution is
19534   probably to match C99's parsing rules.  Bill provided wording.
19535 ]</i></p>
19536
19537
19538
19539
19540
19541
19542
19543 <hr>
19544 <h3><a name="464"></a>464. Suggestion for new member functions in standard containers</h3>
19545 <p><b>Section:</b> 23.2.5 [vector], 23.3.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19546  <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2004-05-12</p>
19547 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
19548 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19549 <p><b>Discussion:</b></p>
19550
19551 <p>To add slightly more convenience to vector&lt;T&gt; and map&lt;Key,T&gt; we should consider to add</p>
19552 <ol>
19553 <li> add vector&lt;T&gt;::data() member (const and non-const version)
19554 semantics: if( empty() ) return 0; else return buffer_;</li>
19555 <li> add map&lt;Key,T&gt;::at( const Key&amp; k ) member (const and non-const version)
19556 <i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
19557 </ol>
19558
19559 <p>Rationale:</p>
19560
19561 <ul>
19562 <li>To obtain a pointer to the vector's buffer, one must use either
19563 operator[]() (which can give undefined behavior for empty vectors) or
19564 at() (which will then throw if the vector is empty). </li>
19565 <li>tr1::array&lt;T,sz&gt; already has a data() member</li>
19566 <li>e cannot use operator[]() when T is not DefaultDonstructible</li>
19567 <li>Neither when the map is const.</li>
19568 <li>when we want to make sure we don't add an element accidently</li>
19569 <li>when it should be considered an error if a key is not in the map</li>
19570 </ul>
19571
19572
19573
19574 <p><b>Proposed resolution:</b></p>
19575 <p>In 23.2.5 [vector], add the following to the <tt>vector</tt>
19576   synopsis after "element access" and before "modifiers":</p>
19577 <pre>  // <i>[lib.vector.data] data access</i>
19578   pointer       data();
19579   const_pointer data() const;
19580 </pre>
19581
19582 <p>Add a new subsection of 23.2.5 [vector]:</p>
19583 <blockquote>
19584 <p>23.2.4.x <tt>vector</tt> data access</p>
19585 <pre>   pointer       data();
19586    const_pointer data() const;
19587 </pre>
19588 <p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
19589    range.  For a non-empty vector, data() == &amp;front().</p>
19590 <p><b>Complexity:</b> Constant time.</p>
19591 <p><b>Throws:</b> Nothing.</p>
19592 </blockquote>
19593
19594 <p>In 23.3.1 [map], add the following to the <tt>map</tt>
19595 synopsis immediately after the line for operator[]:</p>
19596 <pre>  T&amp;       at(const key_type&amp; x);
19597   const T&amp; at(const key_type&amp; x) const;
19598 </pre>
19599
19600 <p>Add the following to 23.3.1.2 [map.access]:</p>
19601 <blockquote>
19602 <pre>  T&amp;       at(const key_type&amp; x);
19603   const T&amp; at(const key_type&amp; x) const;
19604 </pre>
19605
19606 <p><b>Returns:</b> A reference to the element whose key is equivalent
19607   to x, if such an element is present in the map.</p>
19608 <p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
19609
19610 </blockquote>
19611
19612
19613
19614 <p><b>Rationale:</b></p>
19615 <p>Neither of these additions provides any new functionality but the
19616   LWG agreed that they are convenient, especially for novices.  The
19617   exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
19618   was chosen to match <tt>vector::at</tt>.</p>
19619
19620
19621
19622
19623
19624 <hr>
19625 <h3><a name="465"></a>465. Contents of &lt;ciso646&gt;</h3>
19626 <p><b>Section:</b> 17.4.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19627  <b>Submitter:</b> Steve Clamage <b>Date:</b> 2004-06-03</p>
19628 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</p>
19629 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19630 <p><b>Discussion:</b></p>
19631 <p>C header &lt;iso646.h&gt; defines macros for some operators, such as
19632 not_eq for !=.</p>
19633
19634 <p>Section 17.4.1.2 [headers] "Headers" says that except as noted in
19635 clauses 18 through 27, the &lt;cname&gt; C++ header contents are the same
19636 as the C header &lt;name.h&gt;. In particular, table 12 lists
19637 &lt;ciso646&gt; as a C++ header.</p>
19638
19639 <p>I don't find any other mention of &lt;ciso646&gt;, or any mention of
19640 &lt;iso646.h&gt;, in clauses 17 thorough 27. That implies that the
19641 contents of &lt;ciso646&gt; are the same as C header &lt;iso646.h&gt;.</p>
19642
19643 <p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
19644 "Header &lt;iso646.h&gt;" says that the alternative tokens are not
19645 defined as macros in &lt;ciso646&gt;, but does not mention the contents
19646 of &lt;iso646.h&gt;.</p>
19647
19648 <p>I don't find any normative text to support C.2.2.2.</p>
19649
19650
19651
19652 <p><b>Proposed resolution:</b></p>
19653 <p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
19654   paragraph 6 (the one about functions must be functions):</p>
19655
19656 <blockquote>
19657 <p>Identifiers that are keywords or operators in C++ shall not be defined
19658 as macros in C++ standard library headers.
19659 [Footnote:In particular, including the standard header &lt;iso646.h&gt;
19660 or &lt;ciso646&gt; has no effect. </p>
19661 </blockquote>
19662
19663 <p><i>[post-Redmond: Steve provided wording.]</i></p>
19664
19665
19666
19667
19668
19669
19670
19671 <hr>
19672 <h3><a name="467"></a>467. char_traits::lt(), compare(), and memcmp()</h3>
19673 <p><b>Section:</b> 21.1.3.1 [char.traits.specializations.char] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19674  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
19675 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19676 <p><b>Discussion:</b></p>
19677
19678 <p>
19679 Table 37 describes the requirements on Traits::compare() in terms of
19680 those on Traits::lt(). 21.1.3.1, p6 requires char_traits&lt;char&gt;::lt()
19681 to yield the same result as operator&lt;(char, char).
19682 </p>
19683
19684 <p>
19685 Most, if not all, implementations of char_traits&lt;char&gt;::compare()
19686 call memcmp() for efficiency. However, the C standard requires both
19687 memcmp() and strcmp() to interpret characters under comparison as
19688 unsigned, regardless of the signedness of char. As a result, all
19689 these char_traits implementations fail to meet the requirement
19690 imposed by Table 37 on compare() when char is signed.
19691 </p>
19692
19693
19694 <p>Read email thread starting with c++std-lib-13499 for more. </p>
19695
19696
19697 <p><b>Proposed resolution:</b></p>
19698
19699
19700 <p>Change 21.1.3.1, p6 from</p>
19701 <blockquote><p>
19702     The two-argument members assign, eq, and lt are defined identically
19703     to the built-in operators =, ==, and &lt; respectively.
19704 </p></blockquote>
19705 <p>to</p>
19706 <blockquote><p>
19707   The two-argument member assign is defined identically to
19708   the built-in operator =. The two
19709   argument members eq and lt are defined identically to
19710   the built-in operators == and &lt; for type unsigned char.
19711 </p></blockquote>
19712
19713 <p><i>[Redmond: The LWG agreed with this general direction, but we
19714   also need to change <tt>eq</tt> to be consistent with this change.
19715   Post-Redmond: Martin provided wording.]</i></p>
19716
19717
19718
19719
19720
19721
19722 <hr>
19723 <h3><a name="468"></a>468. unexpected consequences of ios_base::operator void*()</h3>
19724 <p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19725  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
19726 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
19727 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19728 <p><b>Discussion:</b></p>
19729
19730 <p>The program below is required to compile but when run it typically
19731 produces unexpected results due to the user-defined conversion from
19732 std::cout or any object derived from basic_ios to void*.
19733 </p>
19734
19735 <pre>    #include &lt;cassert&gt;
19736     #include &lt;iostream&gt;
19737
19738     int main ()
19739     {
19740         assert (std::cin.tie () == std::cout);
19741         // calls std::cout.ios::operator void*()
19742     }
19743 </pre>
19744
19745
19746 <p><b>Proposed resolution:</b></p>
19747
19748 <p>
19749 Replace std::basic_ios&lt;charT, traits&gt;::operator void*() with another
19750 conversion operator to some unspecified type that is guaranteed not
19751 to be convertible to any other type except for bool (a pointer-to-member
19752 might be one such suitable type). In addition, make it clear that the
19753 pointer type need not be a pointer to a complete type and when non-null,
19754 the value need not be valid.
19755 </p>
19756
19757 <p>Specifically, change in [lib.ios] the signature of</p>
19758 <pre>    operator void*() const;
19759 </pre>
19760 <p>to</p>
19761 <pre>    operator unspecified-bool-type() const;
19762 </pre>
19763 <p>and change [lib.iostate.flags], p1 from</p>
19764 <pre>    operator void*() const;
19765 </pre>
19766 <p>to</p>
19767 <pre>operator unspecified-bool-type() const;
19768
19769      -1- Returns: if fail() then a value that will evaluate false in a
19770       boolean context; otherwise a value that will evaluate true in a
19771       boolean context. The value type returned shall not be
19772       convertible to int.
19773
19774      -2- [Note: This conversion can be used in contexts where a bool
19775       is expected (e.g., an if condition); however, implicit
19776       conversions (e.g., to int) that can occur with bool are not
19777       allowed, eliminating some sources of user error. One possible
19778       implementation choice for this type is pointer-to-member.  - end
19779       note]
19780 </pre>
19781
19782 <p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
19783
19784 <p><i>[Lillehammer: Doug provided revised wording for
19785   "unspecified-bool-type".]</i></p>
19786
19787
19788
19789
19790
19791
19792
19793
19794 <hr>
19795 <h3><a name="469"></a>469. vector&lt;bool&gt; ill-formed relational operators</h3>
19796 <p><b>Section:</b> 23.2.5 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
19797  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
19798 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
19799 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
19800 <p><b>Discussion:</b></p>
19801
19802 <p>
19803 The overloads of relational operators for vector&lt;bool&gt; specified
19804 in [lib.vector.bool] are redundant (they are semantically identical
19805 to those provided for the vector primary template) and may even be
19806 diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation
19807 in c++std-lib-13647).
19808 </p>
19809
19810
19811
19812 <p><b>Proposed resolution:</b></p>
19813 <p>
19814 Remove all overloads of overloads of relational operators for
19815 vector&lt;bool&gt; from [lib.vector.bool].
19816 </p>
19817
19818
19819
19820
19821 <hr>
19822 <h3><a name="474"></a>474. confusing Footnote 297</h3>
19823 <p><b>Section:</b> 27.6.2.6.4 [ostream.inserters.character] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19824  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-07-01</p>
19825 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.character">issues</a> in [ostream.inserters.character].</p>
19826 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19827 <p><b>Discussion:</b></p>
19828
19829 <p>
19830 I think Footnote 297 is confused. The paragraph it applies to seems
19831 quite clear in that widen() is only called if the object is not a char
19832 stream (i.e., not basic_ostream&lt;char&gt;), so it's irrelevant what the
19833 value of widen(c) is otherwise.
19834 </p>
19835
19836
19837 <p><b>Proposed resolution:</b></p>
19838 <p>
19839 I propose to strike the Footnote.
19840 </p>
19841
19842
19843
19844
19845 <hr>
19846 <h3><a name="475"></a>475. May the function object passed to for_each modify the elements of the iterated sequence?</h3>
19847 <p><b>Section:</b> 25.1.1 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19848  <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Date:</b> 2004-07-09</p>
19849 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
19850 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19851 <p><b>Discussion:</b></p>
19852 <p>
19853 It is not clear whether the function object passed to for_each is allowed to
19854 modify the elements of the sequence being iterated over.
19855 </p>
19856
19857 <p>
19858 for_each is classified without explanation in [lib.alg.nonmodifying], "25.1
19859 Non-modifying sequence operations". 'Non-modifying sequence operation' is
19860 never defined.
19861 </p>
19862
19863 <p>
19864 25(5) says: "If an algorithm's Effects section says that a value pointed to
19865 by any iterator passed as an argument is modified, then that algorithm has
19866 an additional type requirement: The type of that argument shall satisfy the
19867 requirements of a mutable iterator (24.1)."
19868 </p>
19869
19870 <p>for_each's Effects section does not mention whether arguments can be
19871 modified:</p>
19872
19873 <blockquote><p>
19874   "Effects: Applies f to the result of dereferencing every iterator in the
19875    range [first, last), starting from first and proceeding to last - 1."
19876 </p></blockquote>
19877
19878 <p>
19879 Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in
19880 the sense that neither the algorithms themselves nor the function objects
19881 passed to the algorithms may modify the sequences or elements in any way.
19882 This DR affects only for_each.
19883 </p>
19884
19885 <p>
19886 We suspect that for_each's classification in "non-modifying sequence
19887 operations" means that the algorithm itself does not inherently modify the
19888 sequence or the elements in the sequence, but that the function object
19889 passed to it may modify the elements it operates on.
19890 </p>
19891
19892 <p>
19893 The original STL document by Stepanov and Lee explicitly prohibited the
19894 function object from modifying its argument.
19895 The "obvious" implementation of for_each found in several standard library
19896 implementations, however, does not impose this restriction.
19897 As a result, we suspect that the use of for_each with function objects that modify
19898 their arguments is wide-spread.
19899 If the restriction was reinstated, all such code would become non-conforming.
19900 Further, none of the other algorithms in the Standard
19901 could serve the purpose of for_each (transform does not guarantee the order in
19902 which its function object is called).
19903 </p>
19904
19905 <p>
19906 We suggest that the standard be clarified to explicitly allow the function object
19907 passed to for_each modify its argument.</p>
19908
19909
19910
19911 <p><b>Proposed resolution:</b></p>
19912 <p>Add a nonnormative note to the Effects in 25.1.1 [alg.foreach]: If
19913 the type of 'first' satisfies the requirements of a mutable iterator,
19914 'f' may apply nonconstant functions through the dereferenced iterators
19915 passed to it.
19916 </p>
19917
19918
19919
19920 <p><b>Rationale:</b></p>
19921 <p>The LWG believes that nothing in the standard prohibits function
19922   objects that modify the sequence elements. The problem is that
19923   for_each is in a secion entitled "nonmutating algorithms", and the
19924   title may be confusing.  A nonnormative note should clarify that.</p>
19925
19926
19927
19928
19929
19930 <hr>
19931 <h3><a name="478"></a>478. Should forward iterator requirements table have a line for r-&gt;m?</h3>
19932 <p><b>Section:</b> 24.1.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19933  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-07-11</p>
19934 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
19935 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19936 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
19937 <p><b>Discussion:</b></p>
19938 <p>
19939 The Forward Iterator requirements table contains the following:
19940 </p>
19941 <pre> expression  return type         operational  precondition
19942                                   semantics
19943   ==========  ==================  ===========  ==========================
19944   a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
19945               otherwise const U&amp;
19946
19947   r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
19948 </pre>
19949
19950 <p>The second line may be unnecessary.  Paragraph 11 of
19951   [lib.iterator.requirements] says:
19952 </p>
19953
19954 <blockquote><p>
19955    In the following sections, a and b denote values of type const X, n
19956    denotes a value of the difference type Distance, u, tmp, and m
19957    denote identifiers, r denotes a value of X&amp;, t denotes a value of
19958    value type T, o denotes a value of some type that is writable to
19959    the output iterator.
19960 </p></blockquote>
19961
19962 <p>
19963 Because operators can be overloaded on an iterator's const-ness, the
19964 current requirements allow iterators to make many of the operations
19965 specified using the identifiers a and b invalid for non-const
19966 iterators.</p>
19967
19968 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
19969
19970
19971 <p><b>Proposed resolution:</b></p>
19972
19973 <p>Remove the "r-&gt;m" line from the Forward Iterator requirements
19974 table. Change</p>
19975 <blockquote><p>
19976     "const X"
19977 </p></blockquote>
19978
19979 <p> to </p>
19980
19981 <blockquote><p>
19982     "X or const X"
19983 </p></blockquote>
19984
19985 <p>in paragraph 11 of [lib.iterator.requirements].</p>
19986
19987
19988
19989
19990 <p><b>Rationale:</b></p>
19991 <p>
19992 This is a defect because it constrains an lvalue to returning a modifiable lvalue.
19993 </p>
19994
19995
19996
19997
19998
19999 <hr>
20000 <h3><a name="495"></a>495. Clause 22 template parameter requirements</h3>
20001 <p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20002  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2005-01-10</p>
20003 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
20004 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20005 <p><b>Discussion:</b></p>
20006 <p>It appears that there are no requirements specified for many of the
20007 template parameters in clause 22. It looks like this issue has never
20008 come up, except perhaps for Facet.</p>
20009
20010 <p>Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions],
20011 either, which is the wording that allows requirements on template
20012 parameters to be identified by name.</p>
20013
20014 <p>So one issue is that 17.3.2.1 [lib.type.descriptions] Should be
20015 changed to cover clause 22. A better change, which will cover us in
20016 the future, would be to say that it applies to all the library
20017 clauses. Then if a template gets added to any library clause we are
20018 covered.</p>
20019
20020 <p>charT, InputIterator, and other names with requirements defined
20021 elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix.
20022 But there are a few template arguments names which I don't think have
20023 requirements given elsewhere:</p>
20024
20025 <ul>
20026 <li>internT and externT.  The fix is to add wording saying that internT
20027 and externT must meet the same requirements as template arguments
20028 named charT.</li>
20029
20030 <li>stateT.  I'm not sure about this one. There already is some wording,
20031 but it seems a bit vague.</li>
20032
20033 <li>Intl.  [lib.locale.moneypunct.byname] The fix for this one is to
20034 rename "Intl" to "International". The name is important because other
20035 text identifies the requirements for the name International but not
20036 for Intl.</li>
20037 </ul>
20038
20039 <p><b>Proposed resolution:</b></p>
20040 <p>Change 17.3.2.1 [type.descriptions], paragraph 1, from:</p>
20041 <blockquote><p>
20042 The Requirements subclauses may describe names that are used to
20043 specify constraints on template arguments.153) These names are used in
20044 clauses 20, 23, 25, and 26 to describe the types that may be supplied
20045 as arguments by a C++ program when instantiating template components
20046 from the library.
20047 </p></blockquote>
20048 <p>to:</p>
20049 <blockquote><p>
20050 The Requirements subclauses may describe names that are used to
20051 specify constraints on template arguments.153) These names are used in
20052 library clauses to describe the types that may be supplied as
20053 arguments by a C++ program when instantiating template components from
20054 the library.
20055 </p></blockquote>
20056
20057 <p>In the front matter of class 22, locales, add:</p>
20058 <blockquote><p>
20059 Template parameter types internT and externT shall meet the
20060 requirements of charT (described in 21 [strings]).
20061 </p></blockquote>
20062
20063
20064 <p><b>Rationale:</b></p>
20065 <p>
20066  Again, a blanket clause isn't blanket enough. Also, we've got a
20067  couple of names that we don't have blanket requirement statements
20068  for. The only issue is what to do about stateT. This wording is
20069  thin, but probably adequate.</p>
20070
20071
20072
20073
20074
20075 <hr>
20076 <h3><a name="496"></a>496. Illegal use of "T" in vector&lt;bool&gt;</h3>
20077 <p><b>Section:</b> 23.2.5 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20078  <b>Submitter:</b> richard@ex-parrot.com <b>Date:</b> 2005-02-10</p>
20079 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
20080 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20081 <p><b>Discussion:</b></p>
20082 <p>
20083 In the synopsis of the std::vector&lt;bool&gt; specialisation in 23.2.5 [vector],
20084 the non-template assign() function has the signature</p>
20085
20086 <pre>  void assign( size_type n, const T&amp; t );
20087 </pre>
20088
20089 <p>The type, T, is not defined in this context.</p>
20090
20091
20092 <p><b>Proposed resolution:</b></p>
20093 <p>Replace "T" with "value_type".</p>
20094
20095
20096
20097
20098
20099 <hr>
20100 <h3><a name="497"></a>497. meaning of numeric_limits::traps for floating point types</h3>
20101 <p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20102  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-03-02</p>
20103 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
20104 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20105 <p><b>Discussion:</b></p>
20106
20107 <p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p>
20108
20109 <blockquote>
20110 <p>static const bool traps;<br>
20111 -59- true if trapping is implemented for the type.204)
20112 <br>
20113 Footnote 204: Required by LIA-1.
20114 </p>
20115 </blockquote>
20116
20117 <p>It's not clear what is meant by "is implemented" here.</p>
20118
20119 <p>
20120 In the context of floating point numbers it seems reasonable to expect
20121 to be able to use traps to determine whether a program can "safely" use
20122 infinity(), quiet_NaN(), etc., in arithmetic expressions, that is
20123 without causing a trap (i.e., on UNIX without having to worry about
20124 getting a signal). When traps is true, I would expect any of the
20125 operations in section 7 of IEEE 754 to cause a trap (and my program
20126 to get a SIGFPE). So, for example, on Alpha, I would expect traps
20127 to be true by default (unless I compiled my program with the -ieee
20128 option), false by default on most other popular architectures,
20129 including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require
20130 traps to be explicitly enabled by the program.
20131 </p>
20132
20133 <p>
20134 Another possible interpretation of p59 is that traps should be true
20135 on any implementation that supports traps regardless of whether they
20136 are enabled by default or not. I don't think such an interpretation
20137 makes the traps member very useful, even though that is how traps is
20138 implemented on several platforms. It is also the only way to implement
20139 traps on platforms that allow programs to enable and disable trapping
20140 at runtime.
20141 </p>
20142
20143
20144 <p><b>Proposed resolution:</b></p>
20145 <p>Change p59 to read:</p>
20146 <blockquote><p>True if, at program startup, there exists a value of the type that
20147   would cause an arithmetic operation using that value to trap.</p></blockquote>
20148
20149
20150 <p><b>Rationale:</b></p>
20151 <p>
20152  Real issue, since trapping can be turned on and off. Unclear what a
20153  static query can say about a dynamic issue. The real advice we should
20154  give users is to use cfenv for these sorts of queries. But this new
20155  proposed resolution is at least consistent and slightly better than
20156  nothing.</p>
20157
20158
20159
20160
20161
20162 <hr>
20163 <h3><a name="505"></a>505. Result_type in random distribution requirements</h3>
20164 <p><b>Section:</b> 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20165  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
20166 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.req].</p>
20167 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20168 <p><b>Discussion:</b></p>
20169 <p>
20170 Table 17: Random distribution requirements
20171 </p>
20172 <p>
20173 Row 1 requires that each random distribution provide a nested type "input_type";
20174 this type denotes the type of the values that the distribution consumes.
20175 </p>
20176 <p>
20177 Inspection of all distributions in [tr.rand.dist] reveals that each distribution
20178 provides a second typedef ("result_type") that denotes the type of the values the
20179 distribution produces when called.
20180 </p>
20181
20182
20183 <p><b>Proposed resolution:</b></p>
20184 <p>
20185 It seems to me that this is also a requirement
20186 for all distributions and should therefore be  indicated as such via a new second
20187 row to this table 17:
20188 </p>
20189 <table border="1" cellpadding="5">
20190 <tbody><tr><td>X::result_type</td><td>T</td><td>---</td><td>compile-time</td></tr>
20191 </tbody></table>
20192
20193 <p><i>[
20194 Berlin:  Voted to WP.  N1932 adopts the proposed resolution:  see Table 5 row 1.
20195 ]</i></p>
20196
20197
20198
20199
20200
20201
20202
20203 <hr>
20204 <h3><a name="507"></a>507. Missing requirement for variate_generator::operator()</h3>
20205 <p><b>Section:</b> 26.4 [rand], TR1 5.1.3 [tr.rand.var] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20206  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
20207 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
20208 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20209 <p><b>Discussion:</b></p>
20210 <p>
20211 Paragraph 11 of [tr.rand.var] equires that the member template
20212 </p>
20213 <blockquote><pre>template&lt;class T&gt; result_type operator() (T value);
20214 </pre></blockquote>
20215 <p>
20216 return
20217 </p>
20218 <blockquote><pre>distribution()(e, value)
20219 </pre></blockquote>
20220 <p>
20221 However, not all distributions have an operator() with a corresponding signature.
20222 </p>
20223
20224 <p><i>[
20225 Berlin:  As a working group we voted in favor of N1932 which makes this moot:
20226 variate_generator has been eliminated.  Then in full committee we voted to give
20227 this issue WP status (mistakenly).
20228 ]</i></p>
20229
20230
20231
20232
20233 <p><b>Proposed resolution:</b></p>
20234 <p>
20235 We therefore  recommend that we insert the following precondition before paragraph 11:
20236 </p>
20237 <blockquote><p>
20238 Precondition:  <tt>distribution().operator()(e,value)</tt> is well-formed.
20239 </p></blockquote>
20240
20241
20242
20243
20244
20245 <hr>
20246 <h3><a name="508"></a>508. Bad parameters for ranlux64_base_01</h3>
20247 <p><b>Section:</b> 26.4.5 [rand.predef], TR1 5.1.5 [tr.rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20248  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
20249 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20250 <p><b>Discussion:</b></p>
20251 <p>
20252 The fifth of these engines with predefined parameters, ranlux64_base_01,
20253 appears to have an unintentional error for which there is a simple correction.
20254 The two pre-defined  subtract_with_carry_01 engines are given as:
20255 </p>
20256 <blockquote><pre>typedef subtract_with_carry_01&lt;float,  24, 10, 24&gt; ranlux_base_01;
20257 typedef subtract_with_carry_01&lt;double, 48, 10, 24&gt; ranlux64_base_01;
20258 </pre></blockquote>
20259 <p>
20260 We demonstrate below that ranlux64_base_01 fails to meet the intent of the
20261 random number generation proposal, but that the simple correction to
20262 </p>
20263 <blockquote><pre>typedef subtract_with_carry_01&lt;double, 48,  5, 12&gt; ranlux64_base_01;
20264 </pre></blockquote>
20265 <p>
20266 does meet the intent of defining well-known good parameterizations.
20267 </p>
20268 <p>
20269 The ranlux64_base_01 engine as presented fails to meet the intent for
20270 predefined engines, stated in proposal N1398 (section E):
20271 </p>
20272 <blockquote><p>
20273 In order to make good random numbers available to a large number of library
20274 users, this proposal not only defines generic random-number engines, but also
20275 provides a number of predefined well-known good parameterizations for those.
20276 </p></blockquote>
20277 <p>
20278 The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very
20279 long period and so meets this criterion.  This property makes it suitable for
20280 use in the excellent discard_block  engines defined subsequently.  The proof
20281 of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s)
20282 + 1 is prime (w, r, and s are template parameters to subtract_with_carry_01,
20283 as defined in [tr.rand.eng.sub1]).
20284 </p>
20285 <p>
20286 The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10.
20287 For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though
20288 explicit factorization  would be a challenge).  In consequence, while it is
20289 certainly possible for some seeding states that this engine would have a very
20290 long period, it is not at all "well-known" that this is the case. The intent
20291 in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy
20292 use in the physics community.  This is isomorphic to the predefined ranlux_base_01,
20293 but exploits the ability of double variables to hold (at least) 48 bits of mantissa,
20294 to deliver 48 random bits at a time rather than 24.
20295 </p>
20296
20297
20298 <p><b>Proposed resolution:</b></p>
20299 <p>
20300 To achieve this intended behavior, the correct template parameteriztion  would be:
20301 </p>
20302 <blockquote><pre>typedef subtract_with_carry_01&lt;double, 48, 5, 12&gt; ranlux64_base_01;
20303 </pre></blockquote>
20304 <p>
20305 The sequence of mantissa bits delivered by this is isomorphic (treating each
20306 double as having the  bits of two floats) to that delivered by ranlux_base_01.
20307 </p>
20308 <p>
20309 <b>References:</b>
20310 </p>
20311 <ol>
20312 <li>F. James, Comput. Phys. Commun. 60(1990) 329</li>
20313 <li>G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462</li>
20314 <li>M. Luscher, Comput. Phys. Commun. 79(1994) 100-110</li>
20315 </ol>
20316
20317 <p><i>[
20318 Berlin: Voted to WP.  N1932 adopts the proposed resolution in 26.3.5,
20319 just above paragraph 5.
20320 ]</i></p>
20321
20322
20323
20324
20325
20326
20327
20328 <hr>
20329 <h3><a name="519"></a>519. Data() undocumented</h3>
20330 <p><b>Section:</b> 23.2.1 [array], TR1 6.2.2 [tr.array.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20331  <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
20332 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
20333 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
20334 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20335 <p><b>Discussion:</b></p>
20336 <p>
20337 <tt>array&lt;&gt;::data()</tt> is present in the class synopsis, but not documented.
20338 </p>
20339
20340
20341 <p><b>Proposed resolution:</b></p>
20342 <p>
20343 Add a new section, after 6.2.2.3:
20344 </p>
20345 <blockquote><pre>T*       data()
20346 const T* data() const;
20347 </pre></blockquote>
20348 <p>
20349 <b>Returns:</b> <tt>elems</tt>.
20350 </p>
20351 <p>
20352 Change 6.2.2.4/2 to:
20353 </p>
20354 <blockquote><p>
20355 In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value
20356 of <tt>data()</tt> is unspecified.
20357 </p></blockquote>
20358
20359
20360
20361
20362
20363 <hr>
20364 <h3><a name="520"></a>520. Result_of and pointers to data members</h3>
20365 <p><b>Section:</b> 20.5.10.1 [func.bind], TR1 3.6 [tr.func.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20366  <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
20367 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20368 <p><b>Discussion:</b></p>
20369 <p>
20370 In the original proposal for binders, the return type of bind() when
20371 called with a pointer to member data as it's callable object was
20372 defined to be mem_fn(ptr); when Peter Dimov and I  unified the
20373 descriptions of the TR1 function objects we hoisted the descriptions
20374 of return types into the INVOKE pseudo-function and into result_of.
20375 Unfortunately, we left pointer to member data out of result_of, so
20376 bind doesn't have any specified behavior when called with a pointer
20377 to  member data.
20378 </p>
20379
20380
20381 <p><b>Proposed resolution:</b></p>
20382 <p><i>[
20383 Pete and Peter will provide wording.
20384 ]</i></p>
20385
20386
20387 <p>
20388 In 20.5.4 [lib.func.ret] ([tr.func.ret]) p3 add the following bullet after bullet 2:
20389 </p>
20390 <ol start="3">
20391 <li>If <tt>F</tt> is a member data pointer type <tt>R T::*</tt>, <tt>type</tt>
20392 shall be <tt><i>cv</i> R&amp;</tt> when <tt>T1</tt> is <tt><i>cv</i> U1&amp;</tt>,
20393 <tt>R</tt> otherwise.</li>
20394 </ol>
20395
20396 <p><i>[
20397 Peter provided wording.
20398 ]</i></p>
20399
20400
20401
20402
20403
20404
20405
20406 <hr>
20407 <h3><a name="521"></a>521. Garbled requirements for argument_type in reference_wrapper</h3>
20408 <p><b>Section:</b> 20.5.5 [refwrap], TR1 2.1.2 [tr.util.refwrp.refwrp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20409  <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
20410 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20411 <p><b>Discussion:</b></p>
20412 <p>
20413 2.1.2/3, second bullet item currently says that reference_wrapper&lt;T&gt; is
20414 derived from unary_function&lt;T, R&gt; if T is:
20415 </p>
20416 <blockquote><p>
20417 a pointer to member function type with cv-qualifier cv and no arguments;
20418 the type T1 is cv T* and R is the return type of the pointer to member function;
20419 </p></blockquote>
20420 <p>
20421 The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member
20422 function. It should be a pointer to the class that T is a pointer to member of.
20423 Like this:
20424 </p>
20425 <blockquote><p>
20426 a pointer to a member function R T0::f() cv (where cv represents the member
20427 function's cv-qualifiers); the type T1 is cv T0*
20428 </p></blockquote>
20429 <p>
20430 Similarly, bullet item 2 in 2.1.2/4 should be:
20431 </p>
20432 <blockquote><p>
20433 a pointer to a member function R T0::f(T2) cv (where cv represents the member
20434 function's cv-qualifiers); the type T1 is cv T0*
20435 </p></blockquote>
20436
20437
20438 <p><b>Proposed resolution:</b></p>
20439
20440 <p>
20441 Change bullet item 2 in 2.1.2/3:
20442 </p>
20443
20444 <blockquote>
20445 <ul>
20446 <li>
20447 a pointer to member function <del>type with cv-qualifier <tt><i>cv</i></tt> and no arguments;
20448 the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and <tt>R</tt> is the return
20449 type of the pointer to member function</del> <ins><tt>R T0::f() <i>cv</i></tt>
20450 (where <tt><i>cv</i></tt> represents the member function's cv-qualifiers);
20451 the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
20452 </li>
20453 </ul>
20454 </blockquote>
20455
20456 <p>
20457 Change bullet item 2 in 2.1.2/4:
20458 </p>
20459
20460 <blockquote>
20461 <ul>
20462 <li>
20463 a pointer to member function <del>with cv-qualifier <tt><i>cv</i></tt> and taking one argument
20464 of type <tt>T2</tt>; the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and
20465 <tt>R</tt> is the return type of the pointer to member function</del>
20466 <ins><tt>R T0::f(T2) <i>cv</i></tt> (where <tt><i>cv</i></tt> represents the member
20467 function's cv-qualifiers); the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
20468 </li>
20469 </ul>
20470 </blockquote>
20471
20472
20473
20474
20475
20476
20477 <hr>
20478 <h3><a name="530"></a>530. Must elements of a string be contiguous?</h3>
20479 <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20480  <b>Submitter:</b> Matt Austern <b>Date:</b> 2005-11-15</p>
20481 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
20482 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20483 <p><b>Discussion:</b></p>
20484 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, which was incorporated into C++03, mandated
20485    that the elements of a vector must be stored in contiguous memory.
20486    Should the same also apply to <tt>basic_string</tt>?</p>
20487
20488 <p>We almost require contiguity already. Clause 23.3.4 [multiset]
20489   defines <tt>operator[]</tt> as <tt>data()[pos]</tt>. What's missing
20490   is a similar guarantee if we access the string's elements via the
20491   iterator interface.</p>
20492
20493 <p>Given the existence of <tt>data()</tt>, and the definition of
20494   <tt>operator[]</tt> and <tt>at</tt> in terms of <tt>data</tt>,
20495   I don't believe it's possible to write a useful and standard-
20496   conforming <tt>basic_string</tt> that isn't contiguous. I'm not
20497   aware of any non-contiguous implementation. We should just require
20498   it.
20499 </p>
20500
20501
20502 <p><b>Proposed resolution:</b></p>
20503 <p>Add the following text to the end of 21.3 [basic.string],
20504 paragraph 2. </p>
20505
20506 <blockquote>
20507   <p>The characters in a string are stored contiguously, meaning that if
20508   <tt>s</tt> is a <tt>basic_string&lt;charT, Allocator&gt;</tt>, then
20509   it obeys the identity
20510   <tt>&amp;*(s.begin() + n) == &amp;*s.begin() + n</tt>
20511   for all <tt>0 &lt;= n &lt; s.size()</tt>.
20512   </p>
20513 </blockquote>
20514
20515
20516 <p><b>Rationale:</b></p>
20517 <p>
20518 Not standardizing this existing practice does not give implementors more
20519 freedom.  We thought it might a decade ago.  But the vendors have spoken
20520 both with their implementations, and with their voice at the LWG
20521 meetings.  The implementations are going to be contiguous no matter what
20522 the standard says.  So the standard might as well give string clients
20523 more design choices.
20524 </p>
20525
20526
20527
20528
20529
20530 <hr>
20531 <h3><a name="533"></a>533. typo in 2.2.3.10/1</h3>
20532 <p><b>Section:</b> 20.6.6.2.10 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
20533  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2005-11-09</p>
20534 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
20535 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
20536 <p><b>Discussion:</b></p>
20537 <p>
20538 I'm seeing something that looks like a typo. The Return of <tt>get_deleter</tt>
20539 says:
20540 </p>
20541 <blockquote><p>
20542 If <tt>*this</tt> <i>owns</i> a deleter <tt>d</tt>...
20543 </p></blockquote>
20544 <p>
20545 but <tt>get_deleter</tt> is a free function!
20546 </p>
20547
20548
20549 <p><b>Proposed resolution:</b></p>
20550 <p>
20551 Therefore, I think should be:
20552 </p>
20553 <blockquote><p>
20554 If <tt><del>*this</del> <ins>p</ins></tt> <i>owns</i> a deleter <tt>d</tt>...
20555 </p></blockquote>
20556
20557
20558
20559
20560
20561 <hr>
20562 <h3><a name="534"></a>534. Missing basic_string members</h3>
20563 <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20564  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2005-11-16</p>
20565 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
20566 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20567 <p><b>Discussion:</b></p>
20568 <p>
20569 OK, we all know std::basic_string is bloated and already has way too
20570 many members.  However, I propose it is missing 3 useful members that
20571 are often expected by users believing it is a close approximation of the
20572 container concept.  All 3 are listed in table 71 as 'optional'
20573 </p>
20574
20575 <p>
20576 i/  pop_back.
20577 </p>
20578
20579 <p>
20580 This is the one I feel most strongly about, as I only just discovered it
20581 was missing as we are switching to a more conforming standard library
20582 &lt;g&gt;
20583 </p>
20584
20585 <p>
20586 I find it particularly inconsistent to support push_back, but not
20587 pop_back.
20588 </p>
20589
20590 <p>
20591 ii/ back.
20592 </p>
20593
20594 <p>
20595 There are certainly cases where I want to examine the last character of
20596 a string before deciding to append, or to trim trailing path separators
20597 from directory names etc.  *rbegin() somehow feels inelegant.
20598 </p>
20599
20600 <p>
20601 iii/ front
20602 </p>
20603
20604 <p>
20605 This one I don't feel strongly about, but if I can get the first two,
20606 this one feels that it should be added as a 'me too' for consistency.
20607 </p>
20608
20609 <p>
20610 I believe this would be similarly useful to the data() member recently
20611 added to vector, or at() member added to the maps.
20612 </p>
20613
20614
20615 <p><b>Proposed resolution:</b></p>
20616 <p>
20617 Add the following members to definition of class template basic_string, 21.3p7
20618 </p>
20619 <blockquote><pre>void pop_back ()
20620
20621 const charT &amp; front() const
20622 charT &amp; front()
20623
20624 const charT &amp; back() const
20625 charT &amp; back()
20626 </pre></blockquote>
20627 <p>
20628 Add the following paragraphs to basic_string description
20629 </p>
20630
20631 <p>
20632 21.3.4p5
20633 </p>
20634 <blockquote>
20635 <pre>const charT &amp; front() const
20636 charT &amp; front()
20637 </pre>
20638 <p>
20639 <i>Precondition:</i> <tt>!empty()</tt>
20640 </p>
20641 <p>
20642 <i>Effects:</i> Equivalent to <tt>operator[](0)</tt>.
20643 </p>
20644 </blockquote>
20645
20646 <p>
20647 21.3.4p6
20648 </p>
20649 <blockquote>
20650 <pre>const charT &amp; back() const
20651 charT &amp; back()
20652 </pre>
20653 <p>
20654 <i>Precondition:</i> <tt>!empty()</tt>
20655 </p>
20656 <p>
20657 <i>Effects:</i> Equivalent to <tt>operator[]( size() - 1)</tt>.
20658 </p>
20659 </blockquote>
20660
20661 <p>
20662 21.3.5.5p10
20663 </p>
20664 <blockquote>
20665 <pre>void pop_back ()
20666 </pre>
20667 <p>
20668 <i>Precondition:</i> <tt>!empty()</tt>
20669 </p>
20670 <p>
20671 <i>Effects:</i> Equivalent to <tt>erase( size() - 1, 1 )</tt>.
20672 </p>
20673 </blockquote>
20674
20675 <p>
20676 Update Table 71: (optional sequence operations)
20677 Add basic_string to the list of containers for the following operations.
20678 </p>
20679 <blockquote><pre>a.front()
20680 a.back()
20681 a.push_back()
20682 a.pop_back()
20683 a[n]
20684 </pre></blockquote>
20685
20686 <p><i>[
20687 Berlin: Has support.  Alisdair provided wording.
20688 ]</i></p>
20689
20690
20691
20692
20693
20694
20695 <hr>
20696 <h3><a name="535"></a>535. std::string::swap specification poorly worded</h3>
20697 <p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20698  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2005-12-14</p>
20699 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p>
20700 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20701 <p><b>Discussion:</b></p>
20702 <p>
20703 std::string::swap currently says for effects and postcondition:
20704 </p>
20705
20706 <blockquote>
20707 <p>
20708 <i>Effects:</i> Swaps the contents of the two strings.
20709 </p>
20710
20711 <p>
20712 <i>Postcondition:</i> <tt>*this</tt> contains the characters that were in <tt><i>s</i></tt>,
20713 <tt><i>s</i></tt> contains the characters that were in <tt>*this</tt>.
20714 </p>
20715 </blockquote>
20716
20717 <p>
20718 Specifying both Effects and Postcondition seems redundant, and the postcondition
20719 needs to be made stronger. Users would be unhappy if the characters were not in
20720 the same order after the swap.
20721 </p>
20722
20723
20724 <p><b>Proposed resolution:</b></p>
20725 <blockquote>
20726 <p>
20727 <del><i>Effects:</i> Swaps the contents of the two strings.</del>
20728 </p>
20729
20730 <p>
20731 <i>Postcondition:</i> <tt>*this</tt> contains the <ins>same sequence of</ins>
20732 characters that <del>were</del> <ins>was</ins> in <tt><i>s</i></tt>,
20733 <tt><i>s</i></tt> contains the <ins>same sequence of</ins> characters that
20734 <del>were</del> <ins>was</ins> in <tt>*this</tt>.
20735 </p>
20736 </blockquote>
20737
20738
20739
20740
20741
20742 <hr>
20743 <h3><a name="537"></a>537. Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</h3>
20744 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20745  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-12</p>
20746 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
20747 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
20748 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20749 <p><b>Discussion:</b></p>
20750 <p>
20751 In the most recent working draft, I'm still seeing:
20752 </p>
20753
20754 <blockquote><pre>seekg(off_type&amp; off, ios_base::seekdir dir)
20755 </pre></blockquote>
20756
20757 <p>
20758 and
20759 </p>
20760
20761 <blockquote><pre>seekp(pos_type&amp; pos)
20762
20763 seekp(off_type&amp; off, ios_base::seekdir dir)
20764 </pre></blockquote>
20765
20766 <p>
20767 that is, by reference off and pos arguments.
20768 </p>
20769
20770
20771 <p><b>Proposed resolution:</b></p>
20772 <p>
20773 After 27.6.1.3p42 change:
20774 </p>
20775
20776 <blockquote><pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
20777 </pre></blockquote>
20778
20779 <p>
20780 After 27.6.2.4p1 change:
20781 </p>
20782
20783 <blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(pos_type<del>&amp;</del> <i>pos</i>);
20784 </pre></blockquote>
20785
20786 <p>
20787 After 27.6.2.4p3 change:
20788 </p>
20789
20790 <blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
20791 </pre></blockquote>
20792
20793
20794
20795
20796
20797 <hr>
20798 <h3><a name="538"></a>538. 241 again: Does unique_copy() require CopyConstructible and Assignable?</h3>
20799 <p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20800  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-02-09</p>
20801 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
20802 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20803 <p><b>Discussion:</b></p>
20804 <p>
20805 I believe I botched the resolution of
20806 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">
20807 241 "Does unique_copy() require CopyConstructible and Assignable?"</a> which now
20808 has WP status.
20809 </p>
20810
20811 <p>
20812 This talks about <tt>unique_copy</tt> requirements and currently reads:
20813 </p>
20814
20815 <blockquote><p>
20816 -5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
20817 <tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
20818 shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt> shall
20819 be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
20820 requirements of forward iterator then the value type of <tt>InputIterator</tt>
20821 must be CopyConstructible (20.1.3). Otherwise CopyConstructible is not required.
20822 </p></blockquote>
20823
20824 <p>
20825 The problem (which Paolo discovered) is that when the iterators are at their
20826 most restrictive (<tt>InputIterator</tt>, <tt>OutputIterator</tt>), then we want
20827 <tt>InputIterator::value_type</tt> to be both <tt>CopyConstructible</tt> and
20828 <tt>CopyAssignable</tt> (for the most efficient implementation).  However this
20829 proposed resolution only makes it clear that it is <tt>CopyConstructible</tt>,
20830 and that one can assign from <tt>*<i>first</i></tt> to <tt>*<i>result</i></tt>.
20831 This latter requirement does not necessarily imply that you can:
20832 </p>
20833
20834 <blockquote><pre>*<i>first</i> = *<i>first</i>;
20835 </pre></blockquote>
20836
20837
20838 <p><b>Proposed resolution:</b></p>
20839 <blockquote><p>
20840 -5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
20841 <tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
20842 shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt>
20843 shall
20844 be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
20845 requirements of forward iterator then the <del>value type</del>
20846 <ins><tt>value_type</tt></ins> of <tt>InputIterator</tt>
20847 must be CopyConstructible (20.1.3) <ins>and Assignable</ins>.
20848 Otherwise CopyConstructible is not required.
20849 </p></blockquote>
20850
20851
20852
20853
20854
20855 <hr>
20856 <h3><a name="540"></a>540. shared_ptr&lt;void&gt;::operator*()</h3>
20857 <p><b>Section:</b> 20.6.6.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20858  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-15</p>
20859 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
20860 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20861 <p><b>Discussion:</b></p>
20862 <p>
20863 I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6
20864 that talks about the operator*() member function of shared_ptr:
20865 </p>
20866
20867 <blockquote><p>
20868   Notes: When T is void, attempting to instantiate this member function
20869   renders the program ill-formed. [Note: Instantiating shared_ptr&lt;void&gt;
20870   does not necessarily result in instantiating this member function.
20871   --end note]
20872 </p></blockquote>
20873
20874 <p>
20875 with the requirement in temp.inst, p1:
20876 </p>
20877
20878 <blockquote><p>
20879   The implicit instantiation of a class template specialization causes
20880   the implicit instantiation of the declarations, but not of the
20881   definitions...
20882 </p></blockquote>
20883
20884 <p>
20885 I assume that what the note is really trying to say is that
20886 "instantiating shared_ptr&lt;void&gt; *must not* result in instantiating
20887 this member function." That is, that this function must not be
20888 declared a member of shared_ptr&lt;void&gt;. Is my interpretation
20889 correct?
20890 </p>
20891
20892
20893 <p><b>Proposed resolution:</b></p>
20894 <p>
20895 Change 2.2.3.5p6
20896 </p>
20897
20898 <blockquote><p>
20899 -6- <del><i>Notes:</i></del> When <tt>T</tt> is <tt>void</tt>, <del>attempting to instantiate
20900 this member function renders the program ill-formed. [<i>Note:</i>
20901 Instantiating <tt>shared_ptr&lt;void&gt;</tt> does not necessarily result in
20902 instantiating this member function. <i>--end note</i>]</del> <ins>it is
20903 unspecified whether this member function is declared or not, and if so, what its
20904 return type is, except that the declaration (although not necessarily the
20905 definition) of the function shall be well-formed.</ins>
20906 </p></blockquote>
20907
20908
20909
20910
20911
20912
20913 <hr>
20914 <h3><a name="541"></a>541. shared_ptr template assignment and void</h3>
20915 <p><b>Section:</b> 20.6.6.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20916  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-16</p>
20917 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
20918 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20919 <p><b>Discussion:</b></p>
20920 <p>
20921 Is the void specialization of the template assignment operator taking
20922 a shared_ptr&lt;void&gt; as an argument supposed be well-formed?
20923 </p>
20924 <p>
20925 I.e., is this snippet well-formed:
20926 </p>
20927 <blockquote><pre>shared_ptr&lt;void&gt; p;
20928 p.operator=&lt;void&gt;(p);
20929 </pre></blockquote>
20930
20931 <p>
20932 Gcc complains about auto_ptr&lt;void&gt;::operator*() returning a reference
20933 to void. I suspect it's because shared_ptr has two template assignment
20934 operators, one of which takes auto_ptr, and the auto_ptr template gets
20935 implicitly instantiated in the process of overload resolution.
20936 </p>
20937
20938 <p>
20939 The only way I see around it is to do the same trick with auto_ptr&lt;void&gt;
20940 operator*() as with the same operator in shared_ptr&lt;void&gt;.
20941 </p>
20942
20943 <p>
20944 PS Strangely enough, the EDG front end doesn't mind the code, even
20945 though in a small test case (below) I can reproduce the error with
20946 it as well.
20947 </p>
20948
20949 <blockquote><pre>template &lt;class T&gt;
20950 struct A { T&amp; operator*() { return *(T*)0; } };
20951
20952 template &lt;class T&gt;
20953 struct B {
20954     void operator= (const B&amp;) { }
20955     template &lt;class U&gt;
20956     void operator= (const B&lt;U&gt;&amp;) { }
20957     template &lt;class U&gt;
20958     void operator= (const A&lt;U&gt;&amp;) { }
20959 };
20960
20961 int main ()
20962 {
20963     B&lt;void&gt; b;
20964     b.operator=&lt;void&gt;(b);
20965 }
20966 </pre></blockquote>
20967
20968
20969 <p><b>Proposed resolution:</b></p>
20970 <p>
20971 In [lib.memory] change:
20972 </p>
20973 <blockquote><pre>template&lt;class X&gt; class auto_ptr;
20974 <ins>template&lt;&gt; class auto_ptr&lt;void&gt;;</ins>
20975 </pre></blockquote>
20976
20977 <p>
20978 In [lib.auto.ptr]/2 add the following before the last closing brace:
20979 </p>
20980
20981 <blockquote><pre>template&lt;&gt; class auto_ptr&lt;void&gt;
20982 {
20983 public:
20984     typedef void element_type;
20985 };
20986 </pre></blockquote>
20987
20988
20989
20990
20991
20992
20993 <hr>
20994 <h3><a name="542"></a>542. shared_ptr observers</h3>
20995 <p><b>Section:</b> 20.6.6.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20996  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-18</p>
20997 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
20998 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20999 <p><b>Discussion:</b></p>
21000 <p>
21001 Peter Dimov wrote:
21002 To: C++ libraries mailing list
21003 Message c++std-lib-15614
21004 [...]
21005 The intent is for both use_count() and unique() to work in a threaded environment.
21006 They are intrinsically prone to race conditions, but they never return garbage.
21007 </p>
21008
21009 <p>
21010 This is a crucial piece of information that I really wish were
21011 captured in the text. Having this in a non-normative note would
21012 have made everything crystal clear to me and probably stopped
21013 me from ever starting this discussion :) Instead, the sentence
21014 in p12 "use only for debugging and testing purposes, not for
21015 production code" very strongly suggests that implementations
21016 can and even are encouraged to return garbage (when threads
21017 are involved) for performance reasons.
21018 </p>
21019 <p>
21020 How about adding an informative note along these lines:
21021 </p>
21022 <blockquote><p>
21023   Note: Implementations are encouraged to provide well-defined
21024   behavior for use_count() and unique() even in the presence of
21025   multiple threads.
21026 </p></blockquote>
21027 <p>
21028 I don't necessarily insist on the exact wording, just that we
21029 capture the intent.
21030 </p>
21031
21032
21033 <p><b>Proposed resolution:</b></p>
21034 <p>
21035 Change 20.6.6.2.5 [util.smartptr.shared.obs] p12:
21036 </p>
21037 <blockquote><p>
21038 [<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
21039 debugging and testing purposes, not for production code.</del> --<i>end note</i>]
21040 </p></blockquote>
21041
21042 <p>
21043 Change 20.6.6.3.5 [util.smartptr.weak.obs] p3:
21044 </p>
21045 <blockquote><p>
21046 [<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
21047 debugging and testing purposes, not for production code.</del> --<i>end note</i>]
21048 </p></blockquote>
21049
21050
21051
21052
21053
21054 <hr>
21055 <h3><a name="543"></a>543. valarray slice default constructor</h3>
21056 <p><b>Section:</b> 26.5.4 [class.slice] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21057  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2005-11-03</p>
21058 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21059 <p><b>Discussion:</b></p>
21060 <p>
21061 If one explicitly constructs a slice or glice with the default
21062 constructor, does the standard require this slice to have any usable
21063 state?  It says "creates a slice which specifies no elements", which
21064 could be interpreted two ways:
21065 </p>
21066 <ol>
21067 <li>There are no elements to which the slice refers (i.e. undefined).</li>
21068 <li>The slice specifies an array with no elements in it (i.e. defined).</li>
21069 </ol>
21070 <p>
21071 Here is a bit of code to illustrate:
21072 </p>
21073 <blockquote><pre>#include &lt;iostream&gt;
21074 #include &lt;valarray&gt;
21075
21076 int main()
21077 {
21078     std::valarray&lt;int&gt; v(10);
21079     std::valarray&lt;int&gt; v2 = v[std::slice()];
21080     std::cout &lt;&lt; "v[slice()].size() = " &lt;&lt; v2.size() &lt;&lt; '\n';
21081 }
21082 </pre></blockquote>
21083
21084 <p>
21085 Is the behavior undefined?  Or should the output be:
21086 </p>
21087
21088 <blockquote><pre>v[slice()].size() = 0
21089 </pre></blockquote>
21090
21091 <p>
21092 There is a similar question and wording for gslice at 26.3.6.1p1.
21093 </p>
21094
21095
21096 <p><b>Proposed resolution:</b></p>
21097
21098 <p><i>[Martin suggests removing the second sentence in 26.5.4.1 [cons.slice] as well.]</i></p>
21099
21100
21101 <p>
21102 Change 26.5.4.1 [cons.slice]:
21103 </p>
21104
21105 <blockquote><p>
21106 1 - <del>The default constructor for <tt>slice</tt> creates a <tt>slice</tt>
21107 which specifies no elements.</del> <ins>The default constructor is equivalent to
21108 <tt>slice(0, 0, 0)</tt>.</ins> A default constructor is provided only to permit
21109 the declaration of arrays of slices. The constructor with arguments for a slice
21110 takes a start, length, and stride parameter.
21111 </p></blockquote>
21112
21113 <p>
21114 Change 26.5.6.1 [gslice.cons]:
21115 </p>
21116
21117 <blockquote><p>
21118 1 - <del>The default constructor creates a <tt>gslice</tt> which specifies no
21119 elements.</del> <ins>The default constructor is equivalent to <tt>gslice(0,
21120 valarray&lt;size_t&gt;(), valarray&lt;size_t&gt;())</tt>.</ins> The constructor
21121 with arguments builds a <tt>gslice</tt> based on a specification of start,
21122 lengths, and strides, as explained in the previous section.
21123 </p></blockquote>
21124
21125
21126
21127
21128
21129
21130 <hr>
21131 <h3><a name="545"></a>545. When is a deleter deleted?</h3>
21132 <p><b>Section:</b> 20.6.6.2.10 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21133  <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
21134 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
21135 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21136 <p><b>Discussion:</b></p>
21137 <p>
21138 The description of ~shared_ptr doesn't say when the shared_ptr's deleter, if
21139 any, is destroyed. In principle there are two possibilities: it is destroyed
21140 unconditionally whenever ~shared_ptr is executed (which, from an implementation
21141 standpoint, means that the deleter is copied whenever the shared_ptr is copied),
21142 or it is destroyed immediately after the owned pointer is destroyed (which, from
21143 an implementation standpoint, means that the deleter object is shared between
21144 instances). We should say which it is.
21145 </p>
21146
21147
21148 <p><b>Proposed resolution:</b></p>
21149 <p>
21150 Add after the first sentence of 20.6.6.2.10 [util.smartptr.getdeleter]/1:
21151 </p>
21152 <blockquote>
21153 <p>
21154 The returned pointer remains valid as long as there exists a <tt>shared_ptr</tt> instance
21155 that owns <tt><i>d</i></tt>.
21156 </p>
21157 <p>
21158 [<i>Note:</i> it is unspecified whether the pointer remains valid longer than that.
21159 This can happen if the implementation doesn't destroy the deleter until all
21160 <tt>weak_ptr</tt> instances in the ownership group are destroyed. <i>-- end note</i>]
21161 </p>
21162 </blockquote>
21163
21164
21165
21166
21167
21168 <hr>
21169 <h3><a name="559"></a>559. numeric_limits&lt;const T&gt;</h3>
21170 <p><b>Section:</b> 18.2.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21171  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-19</p>
21172 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#limits">issues</a> in [limits].</p>
21173 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21174 <p><b>Discussion:</b></p>
21175         <p>
21176
21177 18.2.1 [limits], p2 requires implementations  to provide specializations of the
21178 <code>numeric_limits</code> template for  each scalar type. While this
21179 could be interepreted to include cv-qualified forms of such types such
21180 an  interepretation   is  not  reflected   in  the  synopsis   of  the
21181 <code>&lt;limits&gt;</code> header.
21182
21183         </p>
21184         <p>
21185
21186 The absence  of specializations of the template  on cv-qualified forms
21187 of  fundamental types  makes <code>numeric_limits</code>  difficult to
21188 use in generic  code where the constness (or volatility)  of a type is
21189 not  always  immediately  apparent.  In  such  contexts,  the  primary
21190 template  ends   up  being   instantiated  instead  of   the  provided
21191 specialization, typically yielding unexpected behavior.
21192
21193         </p>
21194         <p>
21195
21196 Require   that  specializations   of   <code>numeric_limits</code>  on
21197 cv-qualified fundamental types have the same semantics as those on the
21198 unqualifed forms of the same types.
21199
21200         </p>
21201
21202
21203 <p><b>Proposed resolution:</b></p>
21204         <p>
21205
21206 Add  to  the   synopsis  of  the  <code>&lt;limits&gt;</code>  header,
21207 immediately  below  the  declaration  of  the  primary  template,  the
21208 following:
21209 </p>
21210
21211 <pre>
21212 template &lt;class T&gt; class numeric_limits&lt;const T&gt;;
21213 template &lt;class T&gt; class numeric_limits&lt;volatile T&gt;;
21214 template &lt;class T&gt; class numeric_limits&lt;const volatile T&gt;;
21215
21216 </pre>
21217
21218         <p>
21219
21220 Add  a new paragraph  to the  end of  18.2.1.1 [numeric.limits], with  the following
21221 text:
21222
21223         </p>
21224         <p>
21225
21226 -new-para- The  value of each member  of a <code>numeric_limits</code>
21227 specialization on a  cv-qualified T is equal to the  value of the same
21228 member of <code>numeric_limits&lt;T&gt;</code>.
21229
21230         </p>
21231
21232 <p><i>[
21233 Portland: Martin will clarify that user-defined types get cv-specializations
21234 automatically.
21235 ]</i></p>
21236
21237
21238
21239
21240
21241
21242
21243 <hr>
21244 <h3><a name="575"></a>575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions</h3>
21245 <p><b>Section:</b> 20.6.6.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21246  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-04-23</p>
21247 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21248 <p><b>Discussion:</b></p>
21249 <p>
21250 [tr.util.smartptr.shared.dest] says in its second bullet:
21251 </p>
21252
21253 <p>
21254 "If *this shares ownership with another shared_ptr instance (use_count() &gt; 1),
21255 decrements that instance's use count."
21256 </p>
21257
21258 <p>
21259 The problem with this formulation is that it presupposes the existence of an
21260 "use count" variable that can be decremented and that is part of the state of a
21261 shared_ptr instance (because of the "that instance's use count".)
21262 </p>
21263
21264 <p>
21265 This is contrary to the spirit of the rest of the specification that carefully
21266 avoids to require an use count variable. Instead, use_count() is specified to
21267 return a value, a number of instances.
21268 </p>
21269
21270 <p>
21271 In multithreaded code, the usual implicit assumption is that a shared variable
21272 should not be accessed by more than one thread without explicit synchronization,
21273 and by introducing the concept of an "use count" variable, the current wording
21274 implies that two shared_ptr instances that share ownership cannot be destroyed
21275 simultaneously.
21276 </p>
21277
21278 <p>
21279 In addition, if we allow the interpretation that an use count variable is part
21280 of shared_ptr's state, this would lead to other undesirable consequences WRT
21281 multiple threads. For example,
21282 </p>
21283
21284 <blockquote><pre>p1 = p2;
21285 </pre></blockquote>
21286
21287 <p>
21288 would now visibly modify the state of p2, a "write" operation, requiring a lock.
21289 </p>
21290
21291
21292 <p><b>Proposed resolution:</b></p>
21293 <p>
21294 Change the first two bullets of [lib.util.smartptr.shared.dest]/1 to:
21295 </p>
21296
21297 <blockquote>
21298 <ul>
21299 <li>If <tt>*this</tt> is <i>empty</i> <ins>or shares ownership with another
21300 <tt>shared_ptr</tt> instance (<tt>use_count() &gt; 1</tt>)</ins>, there are no side effects.</li>
21301 <li><del>If <tt>*this</tt> <i>shares ownership</i> with another <tt>shared_ptr</tt> instance
21302 (<tt>use_count() &gt; 1</tt>), decrements that instance's use count.</del></li>
21303 </ul>
21304 </blockquote>
21305
21306 <p>
21307 Add the following paragraph after [lib.util.smartptr.shared.dest]/1:
21308 </p>
21309
21310 <blockquote><p>
21311 [<i>Note:</i> since the destruction of <tt>*this</tt> decreases the number of instances in
21312 <tt>*this</tt>'s ownership group by one, all <tt>shared_ptr</tt> instances that share ownership
21313 with <tt>*this</tt> will report an <tt>use_count()</tt> that is one lower than its previous value
21314 after <tt>*this</tt> is destroyed. <i>--end note</i>]
21315 </p></blockquote>
21316
21317
21318
21319
21320
21321 <hr>
21322 <h3><a name="576"></a>576. find_first_of is overconstrained</h3>
21323 <p><b>Section:</b> 25.1.4 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21324  <b>Submitter:</b> Doug Gregor <b>Date:</b> 2006-04-25</p>
21325 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</p>
21326 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21327 <p><b>Discussion:</b></p>
21328 <p>
21329 In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to
21330 find_first_of are specified to require Forward Iterators, as follows:
21331 </p>
21332
21333 <blockquote><pre>template&lt;class ForwardIterator1, class ForwardIterator2&gt;
21334   ForwardIterator1
21335   find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
21336                         ForwardIterator2 first2, ForwardIterator2 last2);
21337 template&lt;class ForwardIterator1, class ForwardIterator2,
21338                   class BinaryPredicate&gt;
21339 ForwardIterator1
21340   find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
21341                          ForwardIterator2 first2, ForwardIterator2 last2,
21342                         BinaryPredicate pred);
21343 </pre></blockquote>
21344
21345 <p>
21346 However, ForwardIterator1 need not actually be a Forward Iterator; an Input
21347 Iterator suffices, because we do not need the multi-pass property of the Forward
21348 Iterator or a true reference.
21349 </p>
21350
21351
21352 <p><b>Proposed resolution:</b></p>
21353 <p>
21354 Change the declarations of <tt>find_first_of</tt> to:
21355 </p>
21356
21357 <blockquote><pre>template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2&gt;
21358   <del>ForwardIterator1</del><ins>InputIterator1</ins>
21359   find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
21360                         ForwardIterator2 first2, ForwardIterator2 last2);
21361 template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2,
21362                   class BinaryPredicate&gt;
21363 <del>ForwardIterator1</del><ins>InputIterator1</ins>
21364   find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
21365                          ForwardIterator2 first2, ForwardIterator2 last2,
21366                         BinaryPredicate pred);
21367 </pre></blockquote>
21368
21369
21370
21371
21372
21373
21374 <hr>
21375 <h3><a name="578"></a>578. purpose of hint to allocator::allocate()</h3>
21376 <p><b>Section:</b> 20.6.1.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21377  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-17</p>
21378 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
21379 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21380 <p><b>Discussion:</b></p>
21381         <p>
21382
21383 The     description    of     the     allocator    member     function
21384 <code>allocate()</code>  requires  that  the <i>hint</i>  argument  be
21385 either 0 or a  value previously returned from <code>allocate()</code>.
21386 Footnote 227 further suggests that  containers may pass the address of
21387 an adjacent element as this argument.
21388
21389         </p>
21390         <p>
21391
21392 I  believe  that  either  the  footnote  is  wrong  or  the  normative
21393 requirement that  the argument be  a value previously returned  from a
21394 call to  <code>allocate()</code> is wrong. The latter  is supported by
21395 the resolution  to issue 20-004 proposed in  c++std-lib-3736 by Nathan
21396 Myers. In addition,  the <i>hint</i> is an ordinary  void* and not the
21397 <code>pointer</code>  type returned  by  <code>allocate()</code>, with
21398 the  two  types potentially  being  incompatible  and the  requirement
21399 impossible to satisfy.
21400
21401         </p>
21402         <p>
21403
21404 See also c++std-lib-14323 for some  more context on where this came up
21405 (again).
21406
21407         </p>
21408
21409
21410     <p><b>Proposed resolution:</b></p>
21411         <p>
21412
21413 Remove  the requirement  in  20.6.1.1, p4  that  the hint  be a  value
21414 previously returned from <code>allocate()</code>. Specifically, change
21415 the paragraph as follows:
21416
21417         </p>
21418 <p>
21419 <del><i>Requires</i>: <i>hint</i> either 0 or previously obtained  from  member
21420 <code>allocate</code>  and  not  yet passed  to member  <code>deallocate</code>.
21421 The value hint may be used by an implementation to help improve performance
21422 <sup>223)</sup>.</del> <ins>[<i>Note:</i> The value <i>hint</i> may be used by an
21423 implementation to help improve performance. -- <i>end note</i>]</ins>
21424 </p>
21425 <blockquote><p>
21426 <del>[Footnote: <sup>223)</sup>In a container member function, the address of an
21427 adjacent element is often a good choice to pass for this argument.</del>
21428 </p></blockquote>
21429
21430
21431
21432
21433 <hr>
21434 <h3><a name="586"></a>586. string inserter not a formatted function</h3>
21435 <p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21436  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-22</p>
21437 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
21438 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21439 <p><b>Discussion:</b></p>
21440         <p>
21441
21442 Section  and paragraph  numbers  in  this paper  are  relative to  the
21443 working draft document number N2009 from 4/21/2006.
21444
21445         </p>
21446
21447         <p>
21448
21449 The  <code>basic_string</code> extractor  in 21.3.7.9,  p1  is clearly
21450 required  to  behave  as  a   formatted  input  function,  as  is  the
21451 <code>std::getline()</code> overload for string described in p7.
21452
21453         </p>
21454         <p>
21455
21456 However, the <code>basic_string</code> inserter described in p5 of the
21457 same section has no such requirement. This has implications on how the
21458 operator  responds  to  exceptions thrown  from  <code>xsputn()</code>
21459 (formatted  output functions are  required to  set <code>badbit</code>
21460 and swallow  the exception unless  <code>badbit</code> is also  set in
21461 <code>exceptions()</code>; the  string inserter doesn't  have any such
21462 requirement).
21463
21464         </p>
21465         <p>
21466
21467 I don't  see anything in the  spec for the string  inserter that would
21468 justify requiring  it to treat  exceptions differently from  all other
21469 similar operators. (If it did, I think it should be made this explicit
21470 by saying  that the  operator "does not  behave as a  formatted output
21471 function" as has been made customary by the adoption of the resolution
21472 of issue 60).
21473
21474         </p>
21475
21476
21477     <p><b>Proposed resolution:</b></p>
21478         <p>
21479
21480 I propose to change the Effects clause in 21.3.7.9, p5, as follows:
21481
21482         </p>
21483             <blockquote>
21484         <p>
21485
21486 <i>Effects</i>: <del>Begins by constructing a  sentry object k as if k
21487 were    constructed    by    typename    <code>basic_ostream&lt;charT,
21488 traits&gt;::sentry   k   (os)</code>.    If  <code>bool(k)</code>   is
21489 <code>true</code>, </del><ins>Behaves  as a formatted  output function
21490 (27.6.2.5.1).   After constructing  a  <code>sentry</code> object,  if
21491 this  object returns <code>true</code>  when converted  to a  value of
21492 type   <code>bool</code>,   determines   padding   as   described   in
21493 22.2.2.2.2</ins>,  then inserts the  resulting sequence  of characters
21494 <code><i>seq</i></code> as if by calling <code>os.rdbuf()-&gt;sputn(seq ,
21495 n)</code>,    where   <code><i>n</i></code>    is   the    larger   of
21496 <code>os.width()</code>   and   <code>str.size()</code>;  then   calls
21497 <code>os.width(0)</code>.  <del>If  the  call  to sputn  fails,  calls
21498 <code>os.setstate(ios_base::failbit)</code>.</del>
21499
21500         </p>
21501             </blockquote>
21502         <p>
21503
21504 This proposed  resilution assumes the  resolution of issue  394 (i.e.,
21505 that   all   formatted   output   functions  are   required   to   set
21506 <code>ios_base::badbit</code>  in response  to any  kind  of streambuf
21507 failure),   and   implicitly   assumes   that  a   return   value   of
21508 <code>sputn(seq,  <i>n</i>)</code>  other  than  <code><i>n</i></code>
21509 indicates a failure.
21510
21511         </p>
21512
21513
21514
21515
21516 <hr>
21517 <h3><a name="589"></a>589. Requirements on iterators of member template functions of containers</h3>
21518 <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21519  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-08-02</p>
21520 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
21521 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
21522 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21523 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a></p>
21524 <p><b>Discussion:</b></p>
21525 <p>
21526 There appears to be no requirements on the InputIterators used in sequences in 23.1.1 in
21527 terms of their value_type, and the requirements in 23.1.2 appear to be overly strict
21528 (requires InputIterator::value_type be the same type as the container's value_type).
21529 </p>
21530
21531
21532 <p><b>Proposed resolution:</b></p>
21533 <p>
21534 Change 23.1.1 p3:
21535 </p>
21536
21537 <blockquote><p>
21538 In Tables 82 and 83, <tt>X</tt> denotes a sequence class, <tt>a</tt> denotes a
21539 value of <tt>X</tt>, <tt>i</tt> and <tt>j</tt> denote iterators satisfying input
21540 iterator requirements <ins>and refer to elements <ins>implicitly
21541 convertible to</ins> <tt>value_type</tt></ins>, <tt>[i, j)</tt> denotes a valid
21542 range, <tt>n</tt> denotes a value of <tt>X::size_type</tt>, <tt>p</tt> denotes a
21543 valid iterator to <tt>a</tt>, <tt>q</tt> denotes a valid dereferenceable
21544 iterator to <tt>a</tt>, <tt>[q1, q2)</tt> denotes a valid range in <tt>a</tt>,
21545 and <tt>t</tt> denotes a value of <tt>X::value_type</tt>.
21546 </p></blockquote>
21547
21548 <p>
21549 Change 23.1.2 p7:
21550 </p>
21551
21552 <blockquote><p>
21553 In Table 84, <tt>X</tt> is an associative container class, <tt>a</tt> is a value
21554 of <tt>X</tt>, <tt>a_uniq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
21555 unique keys, and <tt>a_eq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
21556 multiple keys, <tt>i</tt> and <tt>j</tt> satisfy input iterator requirements and
21557 refer to elements <del>of</del> <ins>implicitly convertible to</ins>
21558 <tt>value_type</tt>, <tt>[i, j)</tt> is a valid range, <tt>p</tt> is a valid
21559 iterator to <tt>a</tt>, <tt>q</tt> is a valid dereferenceable iterator to
21560 <tt>a</tt>, <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <tt>t</tt> is a
21561 value of <tt>X::value_type</tt>, <tt>k</tt> is a value of <tt>X::key_type</tt>
21562 and <tt>c</tt> is a value of type <tt>X::key_compare</tt>.
21563 </p></blockquote>
21564
21565
21566
21567 <p><b>Rationale:</b></p>
21568 <p>
21569 Concepts will probably come in and rewrite this section anyway.  But just in case it is
21570 easy to fix this up as a safety net and as a clear statement of intent.
21571 </p>
21572
21573
21574
21575
21576
21577 <hr>
21578 <h3><a name="593"></a>593. __STDC_CONSTANT_MACROS</h3>
21579 <p><b>Section:</b> 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21580  <b>Submitter:</b> Walter Brown <b>Date:</b> 2006-08-28</p>
21581 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint">issues</a> in [cstdint].</p>
21582 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21583 <p><b>Discussion:</b></p>
21584 <p>
21585 Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers
21586 &lt;cstdint&gt; and &lt;stdint.h&gt;.  These are of course based on the C99 header
21587 &lt;stdint.h&gt;, and were part of TR1.
21588 </p>
21589
21590 <p>
21591 Per 18.3.1/1, these headers define a number of macros and function macros.
21592 While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99
21593 footnotes do mention __STDC_CONSTANT_MACROS.  Further, 18.3.1/2 states that "The
21594 header defines all ... macros the same as C99 subclause 7.18."
21595 </p>
21596
21597 <p>
21598 Therefore, if I wish to have the above-referenced macros and function macros
21599 defined, must I #define __STDC_CONSTANT_MACROS before I #include &lt;cstdint&gt;, or
21600 does the C++ header define these macros/function macros unconditionally?
21601 </p>
21602
21603
21604 <p><b>Proposed resolution:</b></p>
21605 <p>
21606 To put this issue to rest for C++0X, I propose the following addition to
21607 18.3.1/2 of the Working Paper N2009:
21608 </p>
21609
21610 <blockquote><p>
21611 [Note: The macros defined by &lt;cstdint&gt; are provided unconditionally: in
21612 particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
21613 (mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note]
21614 </p></blockquote>
21615
21616
21617
21618
21619
21620 <hr>
21621 <h3><a name="598"></a>598. Decimal: Conversion to integral should truncate, not round.</h3>
21622 <p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
21623  <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
21624 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
21625 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
21626 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
21627 <p><b>Discussion:</b></p>
21628
21629 <p>
21630 In a private email, Daniel writes:
21631 </p>
21632 <blockquote>
21633 <p>
21634 I would like to
21635 ask, what where the reason for the decision to
21636 define the semantics of the integral conversion of the decimal types, namely
21637 </p>
21638 <pre>"operator long long() const;
21639
21640      Returns: Returns the result of the
21641 conversion of *this to the type long long, as if
21642 performed by the expression llrounddXX(*this)."
21643 </pre>
21644 <p>
21645 where XX stands for either 32, 64, or 128,
21646 corresponding to the proper decimal type. The
21647 exact meaning of llrounddXX is not given in that
21648 paper, so I compared it to the corresponding
21649 definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2:
21650 </p>
21651 <p>
21652 "The lround and llround functions round their
21653 argument to the nearest integer value,
21654 rounding halfway cases away from zero, regardless
21655 of the current rounding direction. [..]"
21656 </p>
21657 <p>
21658 Now considering the fact that integral conversion
21659 of the usual floating-point types ("4.9
21660 Floating-integral conversions") has truncation
21661 semantic I wonder why this conversion behaviour
21662 has not been transferred for the decimal types.
21663 </p>
21664 </blockquote>
21665 <p>
21666 Robert comments:
21667 </p>
21668 <p>
21669 Also, there is a further error in the <b>Returns:</b> clause for converting <code>decimal::decimal128</code> to <code>long long</code>.  It currently calls <code>llroundd64</code>, not <code>llroundd128</code>.
21670 </p>
21671
21672
21673
21674 <p><b>Proposed resolution:</b></p>
21675 <p>
21676 Change the <b>Returns:</b> clause in 3.2.2.4 to:
21677 </p>
21678 <blockquote><p>
21679 <b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd32(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
21680 </p></blockquote>
21681 <p>
21682 Change the <b>Returns:</b> clause in 3.2.3.4 to:
21683 </p>
21684 <blockquote><p>
21685 <b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd64(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code></ins></p></blockquote></body></html>