l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.3.3/doc/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
   5
   6 <style type="text/css">
   7 p {text-align:justify}
   8 li {text-align:justify}
   9 ins {background-color:#A0FFA0}
  10 del {background-color:#FFA0A0}
  11 </style></head><body>
  12 <table>
  13 <tbody><tr>
  14 <td align="left">Doc. no.</td>
  15 <td align="left">N2457=07-0327</td>
  16 </tr>
  17 <tr>
  18 <td align="left">Date:</td>
  19 <td align="left">2007-10-20</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 R52)</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>R52:
  53 2007-10-19 post-Kona mailing.
  54 <ul>
  55 <li><b>Summary:</b><ul>
  56 <li>172 open issues, up by 4.</li>
  57 <li>582 closed issues, up by 27.</li>
  58 <li>754 issues total, up by 31.</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#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#754">754</a>.</li>
  62 <li>Changed the following issues from NAD Future to Dup: <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#350">350</a>.</li>
  63 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>.</li>
  64 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>.</li>
  65 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</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#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#632">632</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-active.html#653">653</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#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#673">673</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#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
  66 <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#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
  67 <li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li>
  68 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#563">563</a>, <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-active.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#595">595</a>, <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#661">661</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#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>, <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#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#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#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>.</li>
  69 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>.</li>
  70 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#618">618</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#645">645</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#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#691">691</a>.</li>
  71 <li>Changed the following issues from New to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>.</li>
  72 <li>Changed the following issues from Open to WP: <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-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>.</li>
  73 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li>
  74 </ul></li>
  75 </ul>
  76 </li>
  77 <li>R51:
  78 2007-09-09 pre-Kona mailing.
  79 <ul>
  80 <li><b>Summary:</b><ul>
  81 <li>168 open issues, up by 15.</li>
  82 <li>555 closed issues, up by 0.</li>
  83 <li>723 issues total, up by 15.</li>
  84 </ul></li>
  85 <li><b>Details:</b><ul>
  86 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
  87 </ul></li>
  88 </ul>
  89 </li>
  90 <li>R50:
  91 2007-08-05 post-Toronto mailing.
  92 <ul>
  93 <li><b>Summary:</b><ul>
  94 <li>153 open issues, down by 5.</li>
  95 <li>555 closed issues, up by 17.</li>
  96 <li>708 issues total, up by 12.</li>
  97 </ul></li>
  98 <li><b>Details:</b><ul>
  99 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
 100 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>.</li>
 101 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.</li>
 102 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>.</li>
 103 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>.</li>
 104 <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <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#633">633</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-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-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-closed.html#656">656</a>.</li>
 105 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#579">579</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#680">680</a>.</li>
 106 <li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
 107 <li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#644">644</a>.</li>
 108 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li>
 109 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>.</li>
 110 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>.</li>
 111 <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
 112 <li>Changed the following issues from DR to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>.</li>
 113 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
 114 </ul></li>
 115 </ul>
 116 </li>
 117 <li>R49:
 118 2007-06-23 pre-Toronto mailing.
 119 <ul>
 120 <li><b>Summary:</b><ul>
 121 <li>158 open issues, up by 13.</li>
 122 <li>538 closed issues, up by 7.</li>
 123 <li>696 issues total, up by 20.</li>
 124 </ul></li>
 125 <li><b>Details:</b><ul>
 126 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.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>
 127 <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>
 128 <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>
 129 <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>
 130 <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>
 131 </ul></li>
 132 </ul>
 133 </li>
 134 <li>R48:
 135 2007-05-06 post-Oxford mailing.
 136 <ul>
 137 <li><b>Summary:</b><ul>
 138 <li>145 open issues, down by 33.</li>
 139 <li>531 closed issues, up by 53.</li>
 140 <li>676 issues total, up by 20.</li>
 141 </ul></li>
 142 <li><b>Details:</b><ul>
 143 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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>
 144 <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>
 145 <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>
 146 <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>
 147 <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>
 148 <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>
 149 <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>
 150 <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>
 151 <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>
 152 <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>
 153 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
 154 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
 155 <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>
 156 <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>
 157 <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>
 158 </ul></li>
 159 </ul>
 160 </li>
 161 <li>R47:
 162 2007-03-09 pre-Oxford mailing.
 163 <ul>
 164 <li><b>Summary:</b><ul>
 165 <li>178 open issues, up by 37.</li>
 166 <li>478 closed issues, up by 0.</li>
 167 <li>656 issues total, up by 37.</li>
 168 </ul></li>
 169 <li><b>Details:</b><ul>
 170 <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-defects.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-defects.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-closed.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-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
 171 <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>
 172 <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>
 173 <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>
 174 <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>
 175 <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>
 176 </ul></li>
 177 </ul>
 178 </li>
 179 <li>R46:
 180 2007-01-12 mid-term mailing.
 181 <ul>
 182 <li><b>Summary:</b><ul>
 183 <li>141 open issues, up by 11.</li>
 184 <li>478 closed issues, down by 1.</li>
 185 <li>619 issues total, up by 10.</li>
 186 </ul></li>
 187 <li><b>Details:</b><ul>
 188 <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>
 189 </ul></li>
 190 </ul>
 191 </li>
 192 <li>R45:
 193 2006-11-03 post-Portland mailing.
 194 <ul>
 195 <li><b>Summary:</b><ul>
 196 <li>130 open issues, up by 0.</li>
 197 <li>479 closed issues, up by 17.</li>
 198 <li>609 issues total, up by 17.</li>
 199 </ul></li>
 200 <li><b>Details:</b><ul>
 201 <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>
 202 <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>
 203 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
 204 <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-defects.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>
 205 <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>
 206 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a> to Review.</li>
 207 <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>
 208 </ul></li>
 209 </ul>
 210 </li>
 211 <li>R44:
 212 2006-09-08 pre-Portland mailing.
 213 <ul>
 214 <li><b>Summary:</b><ul>
 215 <li>130 open issues, up by 6.</li>
 216 <li>462 closed issues, down by 1.</li>
 217 <li>592 issues total, up by 5.</li>
 218 </ul></li>
 219 <li><b>Details:</b><ul>
 220 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
 221 </ul></li>
 222 </ul>
 223 </li>
 224 <li>R43:
 225 2006-06-23 mid-term mailing.
 226 <ul>
 227 <li><b>Summary:</b><ul>
 228 <li>124 open issues, up by 14.</li>
 229 <li>463 closed issues, down by 1.</li>
 230 <li>587 issues total, up by 13.</li>
 231 </ul></li>
 232 <li><b>Details:</b><ul>
 233 <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>
 234 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
 235 <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>
 236 </ul></li>
 237 </ul>
 238 </li>
 239 <li>R42:
 240 2006-04-21 post-Berlin mailing.
 241 <ul>
 242 <li><b>Summary:</b><ul>
 243 <li>110 open issues, down by 16.</li>
 244 <li>464 closed issues, up by 24.</li>
 245 <li>574 issues total, up by 8.</li>
 246 </ul></li>
 247 <li><b>Details:</b><ul>
 248 <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>
 249 <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>
 250 <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-closed.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-closed.html#548">548</a> to Open.</li>
 251 <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-defects.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>
 252 <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>
 253 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
 254 </ul></li>
 255 </ul>
 256 </li>
 257 <li>R41:
 258 2006-02-24 pre-Berlin mailing.
 259 <ul>
 260 <li><b>Summary:</b><ul>
 261 <li>126 open issues, up by 31.</li>
 262 <li>440 closed issues, up by 0.</li>
 263 <li>566 issues total, up by 31.</li>
 264 </ul></li>
 265 <li><b>Details:</b><ul>
 266 <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-defects.html#566">566</a>.</li>
 267 <li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
 268 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
 269 </ul></li>
 270 </ul>
 271 </li>
 272 <li>R40:
 273 2005-12-16 mid-term mailing.
 274 <ul>
 275 <li><b>Summary:</b><ul>
 276 <li>95 open issues.</li>
 277 <li>440 closed issues.</li>
 278 <li>535 issues total.</li>
 279 </ul></li>
 280 <li><b>Details:</b><ul>
 281 <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>
 282 </ul></li>
 283 </ul>
 284 </li>
 285 <li>R39:
 286 2005-10-14 post-Mont Tremblant mailing.
 287 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-closed.html#528">528</a>.
 288 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.
 289 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.
 290 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.
 291 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.
 292 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
 293 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
 294 </li>
 295 <li>R38:
 296 2005-07-03 pre-Mont Tremblant mailing.
 297 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>.
 298 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>
 299 </li>
 300 <li>R37:
 301 2005-06 mid-term mailing.
 302 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>.
 303 </li>
 304 <li>R36:
 305 2005-04 post-Lillehammer mailing. All issues in "ready" status except
 306 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
 307 previously in "DR" status were moved to "WP".
 308 </li>
 309 <li>R35:
 310 2005-03 pre-Lillehammer mailing.
 311 </li>
 312 <li>R34:
 313 2005-01 mid-term mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
 314 </li>
 315 <li>R33:
 316 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
 317 </li>
 318 <li>R32:
 319 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
 320 new issues received after the 2004-07 mailing.  Added
 321 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>.
 322 </li>
 323 <li>R31:
 324 2004-07 mid-term mailing: reflects new proposed resolutions and
 325 new issues received after the post-Sydney mailing.  Added
 326 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>.
 327 </li>
 328 <li>R30:
 329 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 330 Voted all "Ready" issues from R29 into the working paper.
 331 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>.
 332 </li>
 333 <li>R29:
 334 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>.
 335 </li>
 336 <li>R28:
 337 Post-Kona mailing: reflects decisions made at the Kona meeting.
 338 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>.
 339 </li>
 340 <li>R27:
 341 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>.
 342 </li>
 343 <li>R26:
 344 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
 345 All issues in Ready status were voted into DR status.  All issues in
 346 DR status were voted into WP status.
 347 </li>
 348 <li>R25:
 349 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>.
 350 </li>
 351 <li>R24:
 352 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
 353 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
 354 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
 355 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
 356 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
 357 </li>
 358 <li>R23:
 359 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>.
 360 Moved issues in the TC to TC status.
 361 </li>
 362 <li>R22:
 363 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>.
 364 </li>
 365 <li>R21:
 366 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>.
 367 </li>
 368 <li>R20:
 369 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 370 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
 371 <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
 372 not discussed at the meeting.
 373
 374 All Ready issues were moved to DR status, with the exception of issues
 375 <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>.
 376
 377 Noteworthy issues discussed at Redmond include
 378 <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>,
 379 <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>.
 380 </li>
 381 <li>R19:
 382 Pre-Redmond mailing.  Added new issues
 383 <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>.
 384 </li>
 385 <li>R18:
 386 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
 387 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
 388 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>.
 389
 390 Changed status of issues
 391 <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>
 392 <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>
 393 <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>
 394 <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>
 395 <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>
 396 <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>
 397 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
 398 to DR.
 399
 400 Changed status of issues
 401 <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>
 402 <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>
 403 <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>
 404 <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>
 405 <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>
 406 <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>
 407 <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>
 408 <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>
 409 <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>
 410 to Ready.
 411
 412 Closed issues
 413 <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>
 414 <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>
 415 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
 416 as NAD.
 417
 418 </li>
 419 <li>R17:
 420 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 421 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>.
 422 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>.
 423 </li>
 424 <li>R16:
 425 post-Toronto mailing; reflects actions taken in Toronto. Added new
 426 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
 427 <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>,
 428 <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>,
 429 <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>,
 430 <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>,
 431 <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>,
 432 <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>,
 433 <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>,
 434 <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>,
 435 <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>,
 436 <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>,
 437 <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>,
 438 <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>,
 439 <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
 440 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
 441 <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
 442 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
 443 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
 444 the bug in enough places.
 445 </li>
 446 <li>R15:
 447 pre-Toronto mailing. Added issues
 448 <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
 449 changes so that we pass Weblint tests.
 450 </li>
 451 <li>R14:
 452 post-Tokyo II mailing; reflects committee actions taken in
 453 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)
 454 </li>
 455 <li>R13:
 456 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>.
 457 </li>
 458 <li>R12:
 459 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
 460 <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
 461 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
 462 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
 463 </li>
 464 <li>R11:
 465 post-Kona mailing: Updated to reflect LWG and full committee actions
 466 in Kona (99-0048/N1224). Note changed resolution of issues
 467 <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>
 468 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
 469 "closed" documents.  Changed the proposed resolution of issue
 470 <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
 471 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
 472 </li>
 473 <li>R10:
 474 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 475 <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>,
 476 <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
 477 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 478 </li>
 479 <li>R9:
 480 pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
 481 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
 482 "closed" documents. (99-0030/N1206, 25 Aug 99)
 483 </li>
 484 <li>R8:
 485 post-Dublin mailing. Updated to reflect LWG and full committee actions
 486 in Dublin. (99-0016/N1193, 21 Apr 99)
 487 </li>
 488 <li>R7:
 489 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>,
 490 <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>,
 491 <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>,
 492 <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)
 493 </li>
 494 <li>R6:
 495 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>,
 496 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 497 </li>
 498 <li>R5:
 499 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
 500 <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
 501 for making list public. (30 Dec 98)
 502 </li>
 503 <li>R4:
 504 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
 505 <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
 506 issues corrected. (22 Oct 98)
 507 </li>
 508 <li>R3:
 509 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>
 510 added, many issues updated to reflect LWG consensus (12 Oct 98)
 511 </li>
 512 <li>R2:
 513 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,
 514 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
 515 </li>
 516 <li>R1:
 517 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
 518 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
 519 </li>
 520 </ul>
 521
 522 <h2>Defect Reports</h2>
 523 <hr>
 524 <h3><a name="1"></a>1. C library linkage editing oversight</h3>
 525 <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>
 526  <b>Submitter:</b> Beman Dawes <b>Date:</b> 1997-11-16</p>
 527 <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>
 528 <p><b>Discussion:</b></p>
 529 <p>The change specified in the proposed resolution below did not make
 530 it into the Standard. This change was accepted in principle at the
 531 London meeting, and the exact wording below was accepted at the
 532 Morristown meeting.</p>
 533
 534
 535 <p><b>Proposed resolution:</b></p>
 536 <p>Change 17.4.2.2 [using.linkage] paragraph 2
 537 from:</p>
 538
 539 <blockquote>
 540   <p>It is unspecified whether a name from the Standard C library
 541   declared with external linkage has either extern "C" or
 542   extern "C++" linkage.</p>
 543 </blockquote>
 544
 545 <p>to:</p>
 546
 547 <blockquote>
 548   <p>Whether a name from the Standard C library declared with external
 549   linkage has extern "C" or extern "C++" linkage
 550   is implementation defined. It is recommended that an implementation
 551   use extern "C++" linkage for this purpose.</p>
 552 </blockquote>
 553
 554
 555
 556
 557
 558 <hr>
 559 <h3><a name="3"></a>3. Atexit registration during atexit() call is not described</h3>
 560 <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>
 561  <b>Submitter:</b> Steve Clamage <b>Date:</b> 1997-12-12</p>
 562 <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>
 563 <p><b>Discussion:</b></p>
 564 <p>We appear not to have covered all the possibilities of
 565  exit processing with respect to
 566 atexit registration. <br>
 567 <br>
 568 Example 1: (C and C++)</p>
 569
 570 <pre>    #include &lt;stdlib.h&gt;
 571     void f1() { }
 572     void f2() { atexit(f1); }
 573
 574     int main()
 575     {
 576         atexit(f2); // the only use of f2
 577         return 0; // for C compatibility
 578     }</pre>
 579
 580 <p>At program exit, f2 gets called due to its registration in
 581 main. Running f2 causes f1 to be newly registered during the exit
 582 processing. Is this a valid program? If so, what are its
 583 semantics?</p>
 584
 585 <p>
 586 Interestingly, neither the C standard, nor the C++ draft standard nor
 587 the forthcoming C9X Committee Draft says directly whether you can
 588 register a function with atexit during exit processing.</p>
 589
 590 <p>
 591 All 3 standards say that functions are run in reverse order of their
 592 registration. Since f1 is registered last, it ought to be run first,
 593 but by the time it is registered, it is too late to be first.</p>
 594
 595 <p>If the program is valid, the standards are self-contradictory about
 596 its semantics.</p>
 597
 598 <p>Example 2: (C++ only)</p>
 599
 600 <pre>
 601     void F() { static T t; } // type T has a destructor
 602
 603     int main()
 604     {
 605         atexit(F); // the only use of F
 606     }
 607 </pre>
 608
 609 <p>Function F registered with atexit has a local static variable t,
 610 and F is called for the first time during exit processing. A local
 611 static object is initialized the first time control flow passes
 612 through its definition, and all static objects are destroyed during
 613 exit processing. Is the code valid? If so, what are its semantics?</p>
 614
 615 <p>
 616 Section 18.3 "Start and termination" says that if a function
 617 F is registered with atexit before a static object t is initialized, F
 618 will not be called until after t's destructor completes.</p>
 619
 620 <p>
 621 In example 2, function F is registered with atexit before its local
 622 static object O could possibly be initialized. On that basis, it must
 623 not be called by exit processing until after O's destructor
 624 completes. But the destructor cannot be run until after F is called,
 625 since otherwise the object could not be constructed in the first
 626 place.</p>
 627
 628 <p>If the program is valid, the standard is self-contradictory about
 629 its semantics.</p>
 630
 631 <p>I plan to submit Example 1 as a public comment on the C9X CD, with
 632 a recommendation that the results be undefined. (Alternative: make it
 633 unspecified. I don't think it is worthwhile to specify the case where
 634 f1 itself registers additional functions, each of which registers
 635 still more functions.)</p>
 636
 637 <p>I think we should resolve the situation in the whatever way the C
 638 committee decides. </p>
 639
 640 <p>For Example 2, I recommend we declare the results undefined.</p>
 641
 642 <p><i>[See reflector message lib-6500 for further discussion.]</i></p>
 643
 644
 645
 646
 647 <p><b>Proposed resolution:</b></p>
 648 <p>Change section 18.3/8 from:</p>
 649 <blockquote><p>
 650   First, objects with static storage duration are destroyed and
 651   functions registered by calling atexit are called. Objects with
 652   static storage duration are destroyed in the reverse order of the
 653   completion of their constructor.  (Automatic objects are not
 654   destroyed as a result of calling exit().) Functions registered with
 655   atexit are called in the reverse order of their registration.  A
 656   function registered with atexit before an object obj1 of static
 657   storage duration is initialized will not be called until obj1's
 658   destruction has completed. A function registered with atexit after
 659   an object obj2 of static storage duration is initialized will be
 660   called before obj2's destruction starts.
 661 </p></blockquote>
 662 <p>to:</p>
 663 <blockquote><p>
 664   First, objects with static storage duration are destroyed and
 665   functions registered by calling atexit are called. Non-local objects
 666   with static storage duration are destroyed in the reverse order of
 667   the completion of their constructor. (Automatic objects are not
 668   destroyed as a result of calling exit().) Functions registered with
 669   atexit are called in the reverse order of their registration, except
 670   that a function is called after any previously registered functions
 671   that had already been called at the time it was registered. A
 672   function registered with atexit before a non-local object obj1 of
 673   static storage duration is initialized will not be called until
 674   obj1's destruction has completed. A function registered with atexit
 675   after a non-local object obj2 of static storage duration is
 676   initialized will be called before obj2's destruction starts. A local
 677   static object obj3 is destroyed at the same time it would be if a
 678   function calling the obj3 destructor were registered with atexit at
 679   the completion of the obj3 constructor.
 680 </p></blockquote>
 681
 682
 683 <p><b>Rationale:</b></p>
 684 <p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
 685 supporting to the proposed resolution.</p>
 686
 687
 688
 689
 690
 691 <hr>
 692 <h3><a name="5"></a>5. String::compare specification questionable</h3>
 693 <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>
 694  <b>Submitter:</b> Jack Reeves <b>Date:</b> 1997-12-11</p>
 695 <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>
 696 <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>
 697 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#87">87</a></p>
 698 <p><b>Discussion:</b></p>
 699 <p>At the very end of the basic_string class definition is the signature: int
 700 compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
 701 following text this is defined as: returns
 702 basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
 703 basic_string&lt;charT,traits,Allocator&gt;(s,n2); </p>
 704
 705 <p>Since the constructor basic_string(const charT* s, size_type n, const Allocator&amp; a
 706 = Allocator()) clearly requires that s != NULL and n &lt; npos and further states that it
 707 throws length_error if n == npos, it appears the compare() signature above should always
 708 throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
 709 null terminated character array. </p>
 710
 711 <p>This appears to be a typo since the obvious intent is to allow either the call above or
 712 something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
 713
 714 <p>This would imply that what was really intended was two signatures int compare(size_type
 715 pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
 716 charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
 717
 718
 719 <p><b>Proposed resolution:</b></p>
 720 <p>Replace the compare signature in 21.3 [basic.string]
 721 (at the very end of the basic_string synopsis) which reads:</p>
 722
 723 <blockquote>
 724   <p><tt>int compare(size_type pos1, size_type n1,<br>
 725   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
 726   size_type n2 = npos) const;</tt></p>
 727 </blockquote>
 728
 729 <p>with:</p>
 730
 731 <blockquote>
 732   <p><tt>int compare(size_type pos1, size_type n1,<br>
 733   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s) const;<br>
 734   int compare(size_type pos1, size_type n1,<br>
 735   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
 736   size_type n2) const;</tt></p>
 737 </blockquote>
 738
 739 <p>Replace the portion of 21.3.6.8 [string::swap]
 740 paragraphs 5 and 6 which read:</p>
 741
 742 <blockquote>
 743   <p><tt>int compare(size_type pos, size_type n1,<br>
 744   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; charT * s, size_type n2
 745   = npos) const;<br>
 746   </tt>Returns:<tt><br>
 747   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 748   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 749   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
 750 </blockquote>
 751
 752 <p>with:</p>
 753
 754 <blockquote>
 755   <p><tt>int compare(size_type pos, size_type n1,<br>
 756   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s) const;<br>
 757   </tt>Returns:<tt><br>
 758   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 759   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 760   basic_string&lt;charT,traits,Allocator&gt;( s ))<br>
 761   <br>
 762   int compare(size_type pos, size_type n1,<br>
 763   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s,
 764   size_type n2) const;<br>
 765   </tt>Returns:<tt><br>
 766   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 767   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 768   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
 769 </blockquote>
 770
 771 <p>Editors please note that in addition to splitting the signature, the third argument
 772 becomes const, matching the existing synopsis.</p>
 773
 774
 775 <p><b>Rationale:</b></p>
 776 <p>While the LWG dislikes adding signatures, this is a clear defect in
 777 the Standard which must be fixed.&nbsp; The same problem was also
 778 identified in issues 7 (item 5) and 87.</p>
 779
 780
 781
 782
 783
 784 <hr>
 785 <h3><a name="7"></a>7. String clause minor problems</h3>
 786 <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>
 787  <b>Submitter:</b> Matt Austern <b>Date:</b> 1997-12-15</p>
 788 <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>
 789 <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>
 790 <p><b>Discussion:</b></p>
 791 <p>(1) In 21.3.6.4 [string::insert], the description of template
 792 &lt;class InputIterator&gt; insert(iterator, InputIterator,
 793 InputIterator) makes no sense. It refers to a member function that
 794 doesn't exist. It also talks about the return value of a void
 795 function. </p>
 796
 797 <p>(2) Several versions of basic_string::replace don't appear in the
 798 class synopsis. </p>
 799
 800 <p>(3) basic_string::push_back appears in the synopsis, but is never
 801 described elsewhere.  In the synopsis its argument is const charT,
 802 which doesn't makes much sense; it should probably be charT, or
 803 possible const charT&amp;. </p>
 804
 805 <p>(4) basic_string::pop_back is missing. </p>
 806
 807 <p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
 808 = npos) make no sense. First, it's const charT* in the synopsis and
 809 charT* in the description. Second, given what it says in RETURNS,
 810 leaving out the final argument will always result in an exception
 811 getting thrown. This is paragraphs 5 and 6 of
 812 21.3.6.8 [string::swap]</p>
 813
 814 <p>(6) In table 37, in section 21.1.1 [char.traits.require],
 815 there's a note for X::move(s, p, n). It says "Copies correctly
 816 even where p is in [s, s+n)". This is correct as far as it goes,
 817 but it doesn't go far enough; it should also guarantee that the copy
 818 is correct even where s in in [p, p+n). These are two orthogonal
 819 guarantees, and neither one follows from the other. Both guarantees
 820 are necessary if X::move is supposed to have the same sort of
 821 semantics as memmove (which was clearly the intent), and both
 822 guarantees are necessary if X::move is actually supposed to be
 823 useful. </p>
 824
 825
 826 <p><b>Proposed resolution:</b></p>
 827 <p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
 828 <br>
 829 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
 830 <br>
 831 ITEM 2:&nbsp; Not a defect; the Standard is clear.. There are ten versions of replace() in
 832 the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
 833 <br>
 834 ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
 835 [lib.basic.string]) from:</p>
 836
 837 <p>&nbsp;&nbsp;&nbsp;&nbsp; void push_back(const charT)<br>
 838 <br>
 839 to<br>
 840 <br>
 841 &nbsp;&nbsp;&nbsp;&nbsp; void push_back(charT)<br>
 842 <br>
 843 Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
 844 <br>
 845 &nbsp;&nbsp;&nbsp; void basic_string::push_back(charT c);<br>
 846 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to append(static_cast&lt;size_type&gt;(1), c);<br>
 847 <br>
 848 ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
 849 <br>
 850 ITEM 5: Duplicate; see issue 5 (and 87).<br>
 851 <br>
 852 ITEM 6: In table 37, Replace:<br>
 853 <br>
 854 &nbsp;&nbsp;&nbsp; "Copies correctly even where p is in [s, s+n)."<br>
 855 <br>
 856 with:<br>
 857 <br>
 858 &nbsp;&nbsp;&nbsp;&nbsp; "Copies correctly even where the ranges [p, p+n) and [s,
 859 s+n) overlap."</p>
 860
 861
 862
 863
 864
 865 <hr>
 866 <h3><a name="8"></a>8. Locale::global lacks guarantee</h3>
 867 <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>
 868  <b>Submitter:</b> Matt Austern <b>Date:</b> 1997-12-24</p>
 869 <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>
 870 <p><b>Discussion:</b></p>
 871 <p>It appears there's an important guarantee missing from clause
 872 22. We're told that invoking locale::global(L) sets the C locale if L
 873 has a name. However, we're not told whether or not invoking
 874 setlocale(s) sets the global C++ locale. </p>
 875
 876 <p>The intent, I think, is that it should not, but I can't find any
 877 such words anywhere. </p>
 878
 879
 880 <p><b>Proposed resolution:</b></p>
 881 <p>Add a sentence at the end of 22.1.1.5 [locale.statics],
 882 paragraph 2:&nbsp; </p>
 883
 884 <blockquote>
 885   <p>No library function other than <tt>locale::global()</tt> shall affect
 886   the value returned by <tt>locale()</tt>. </p>
 887
 888 </blockquote>
 889
 890
 891
 892
 893
 894 <hr>
 895 <h3><a name="9"></a>9. Operator new(0) calls should not yield the same pointer</h3>
 896 <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>
 897  <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-01-04</p>
 898 <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>
 899 <p><b>Discussion:</b></p>
 900 <p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
 901 section 3.7.3.1 of CD2 seems to allow for the possibility that all
 902 calls to operator new(0) yield the same pointer, an implementation
 903 technique specifically prohibited by ARM 5.3.3.Was this prohibition
 904 really lifted? Does the FDIS agree with CD2 in the regard? [Issues
 905 list maintainer's note: the IS is the same.]</p>
 906
 907
 908 <p><b>Proposed resolution:</b></p>
 909 <p>Change the last paragraph of 3.7.3 from:</p>
 910 <blockquote>
 911   <p>Any allocation and/or deallocation functions defined in a C++ program shall
 912   conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
 913 </blockquote>
 914 <p>to:</p>
 915 <blockquote>
 916   <p>Any allocation and/or deallocation functions defined in a C++ program,
 917   including the default versions in the library, shall conform to the semantics
 918   specified in 3.7.3.1 and 3.7.3.2.</p>
 919 </blockquote>
 920 <p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
 921 <blockquote>
 922   <p>If the size of the space requested is zero, the value returned shall not be
 923   a null pointer value (4.10).</p>
 924 </blockquote>
 925 <p>to:</p>
 926 <blockquote>
 927   <p>Even if the size of the space requested is zero, the request can fail. If
 928   the request succeeds, the value returned shall be a non-null pointer value
 929   (4.10) p0 different from any previously returned value p1, unless that value
 930   p1 was since passed to an operator delete.</p>
 931 </blockquote>
 932 <p>5.3.4/7 currently reads:</p>
 933 <blockquote>
 934   <p>When the value of the expression in a direct-new-declarator is zero, the
 935   allocation function is called to allocate an array with no elements. The
 936   pointer returned by the new-expression is non-null. [Note: If the library
 937   allocation function is called, the pointer returned is distinct from the
 938   pointer to any other object.]</p>
 939 </blockquote>
 940 <p>Retain the first sentence, and delete the remainder.</p>
 941 <p>18.5.1 currently has no text. Add the following:</p>
 942 <blockquote>
 943   <p>Except where otherwise specified, the provisions of 3.7.3 apply to the
 944   library versions of operator new and operator delete.</p>
 945 </blockquote>
 946 <p>To 18.5.1.3, add the following text:</p>
 947 <blockquote>
 948   <p>The provisions of 3.7.3 do not apply to these reserved placement forms of
 949   operator new and operator delete.</p>
 950 </blockquote>
 951
 952
 953 <p><b>Rationale:</b></p>
 954 <p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
 955 supporting to the proposed resolution.</p>
 956
 957
 958
 959
 960
 961 <hr>
 962 <h3><a name="11"></a>11. Bitset minor problems</h3>
 963 <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>
 964  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-22</p>
 965 <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>
 966 <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>
 967 <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>
 968 <p><b>Discussion:</b></p>
 969 <p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is
 970 not documented in 23.3.5.2. </p>
 971
 972 <p>(2) The class synopsis only gives a single signature for bitset&lt;&gt;::operator[],
 973 reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
 974 on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
 975
 976 <p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
 977 trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
 978 go in the Effects clause.</p>
 979
 980
 981 <p><b>Proposed resolution:</b></p>
 982 <p>ITEMS 1 AND 2:<br>
 983 <br>
 984 In the bitset synopsis (23.3.5 [template.bitset]),
 985 replace the member function <br>
 986 <br>
 987 <tt>&nbsp;&nbsp;&nbsp; reference operator[](size_t pos);<br>
 988 </tt><br>
 989 with the two member functions<br>
 990 <br>
 991 <tt>&nbsp;&nbsp;&nbsp; bool operator[](size_t pos) const; <br>
 992 &nbsp;&nbsp;&nbsp; reference operator[](size_t pos); <br>
 993 </tt><br>
 994 Add the following text at the end of 23.3.5.2 [bitset.members],
 995 immediately after paragraph 45:</p>
 996
 997 <blockquote>
 998   <p><tt>bool operator[](size_t pos) const;</tt><br>
 999   Requires: pos is valid<br>
1000   Throws: nothing<br>
1001   Returns: <tt>test(pos)</tt><br>
1002   <br>
1003   <tt>bitset&lt;N&gt;::reference operator[](size_t pos);</tt> <br>
1004   Requires: pos is valid<br>
1005   Throws: nothing<br>
1006   Returns: An object of type <tt>bitset&lt;N&gt;::reference</tt> such that <tt>(*this)[pos]
1007   == this-&gt;test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this-&gt;set(pos,
1008   val);</tt></p>
1009 </blockquote>
1010
1011
1012 <p><b>Rationale:</b></p>
1013 <p>The LWG believes Item 3 is not a defect. "Formatted
1014 input" implies the desired semantics. See 27.6.1.2 [istream.formatted].
1015 </p>
1016
1017
1018
1019
1020
1021 <hr>
1022 <h3><a name="13"></a>13. Eos refuses to die</h3>
1023 <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>
1024  <b>Submitter:</b> William M. Miller <b>Date:</b> 1998-03-03</p>
1025 <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>
1026 <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>
1027 <p><b>Discussion:</b></p>
1028 <p>In 27.6.1.2.3, there is a reference to "eos", which is
1029 the only one in the whole draft (at least using Acrobat search), so
1030 it's undefined. </p>
1031
1032
1033 <p><b>Proposed resolution:</b></p>
1034 <p>In 27.6.1.2.3 [istream::extractors], replace "eos" with
1035 "charT()"</p>
1036
1037
1038
1039
1040
1041 <hr>
1042 <h3><a name="14"></a>14. Locale::combine should be const</h3>
1043 <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>
1044  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1045 <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>
1046 <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>
1047 <p><b>Discussion:</b></p>
1048 <p>locale::combine is the only member function of locale (other than constructors and
1049 destructor) that is not const. There is no reason for it not to be const, and good reasons
1050 why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
1051 paragraph 6: "An instance of a locale is immutable." </p>
1052
1053 <p>History: this member function originally was a constructor. it happened that the
1054 interface it specified had no corresponding language syntax, so it was changed to a member
1055 function. As constructors are never const, there was no "const" in the interface
1056 which was transformed into member "combine". It should have been added at that
1057 time, but the omission was not noticed. </p>
1058
1059
1060 <p><b>Proposed resolution:</b></p>
1061 <p>In 22.1.1 [locale] and also in 22.1.1.3 [locale.members], add
1062 "const" to the declaration of member combine: </p>
1063 <blockquote>
1064   <pre>template &lt;class Facet&gt; locale combine(const locale&amp; other) const; </pre>
1065 </blockquote>
1066
1067
1068
1069
1070
1071 <hr>
1072 <h3><a name="15"></a>15. Locale::name requirement inconsistent</h3>
1073 <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>
1074  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1075 <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>
1076 <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>
1077 <p><b>Discussion:</b></p>
1078 <p>locale::name() is described as returning a string that can be passed to a locale
1079 constructor, but there is no matching constructor. </p>
1080
1081
1082 <p><b>Proposed resolution:</b></p>
1083 <p>In 22.1.1.3 [locale.members], paragraph 5, replace
1084 "<tt>locale(name())</tt>" with
1085 "<tt>locale(name().c_str())</tt>".
1086 </p>
1087
1088
1089
1090
1091
1092 <hr>
1093 <h3><a name="16"></a>16. Bad ctype_byname&lt;char&gt; decl</h3>
1094 <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>
1095  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1096 <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>
1097 <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>
1098 <p><b>Discussion:</b></p>
1099 <p>The new virtual members ctype_byname&lt;char&gt;::do_widen and do_narrow did not get
1100 edited in properly. Instead, the member do_widen appears four times, with wrong argument
1101 lists. </p>
1102
1103
1104 <p><b>Proposed resolution:</b></p>
1105 <p>The correct declarations for the overloaded members
1106 <tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
1107 from 22.2.1.3 [facet.ctype.special].</p>
1108
1109
1110
1111
1112
1113 <hr>
1114 <h3><a name="17"></a>17. Bad bool parsing</h3>
1115 <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>
1116  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1117 <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>
1118 <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>
1119 <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>
1120 <p><b>Discussion:</b></p>
1121 <p>This section describes the process of parsing a text boolean value from the input
1122 stream. It does not say it recognizes either of the sequences "true" or
1123 "false" and returns the corresponding bool value; instead, it says it recognizes
1124 only one of those sequences, and chooses which according to the received value of a
1125 reference argument intended for returning the result, and reports an error if the other
1126 sequence is found. (!) Furthermore, it claims to get the names from the ctype&lt;&gt;
1127 facet rather than the numpunct&lt;&gt; facet, and it examines the "boolalpha"
1128 flag wrongly; it doesn't define the value "loc"; and finally, it computes
1129 wrongly whether to use numeric or "alpha" parsing.<br>
1130 <br>
1131 I believe the correct algorithm is "as if": </p>
1132
1133 <pre>  // in, err, val, and str are arguments.
1134   err = 0;
1135   const numpunct&lt;charT&gt;&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(str.getloc());
1136   const string_type t = np.truename(), f = np.falsename();
1137   bool tm = true, fm = true;
1138   size_t pos = 0;
1139   while (tm &amp;&amp; pos &lt; t.size() || fm &amp;&amp; pos &lt; f.size()) {
1140     if (in == end) { err = str.eofbit; }
1141     bool matched = false;
1142     if (tm &amp;&amp; pos &lt; t.size()) {
1143       if (!err &amp;&amp; t[pos] == *in) matched = true;
1144       else tm = false;
1145     }
1146     if (fm &amp;&amp; pos &lt; f.size()) {
1147       if (!err &amp;&amp; f[pos] == *in) matched = true;
1148       else fm = false;
1149     }
1150     if (matched) { ++in; ++pos; }
1151     if (pos &gt; t.size()) tm = false;
1152     if (pos &gt; f.size()) fm = false;
1153   }
1154   if (tm == fm || pos == 0) { err |= str.failbit; }
1155   else                      { val = tm; }
1156   return in;</pre>
1157
1158 <p>Notice this works reasonably when the candidate strings are both empty, or equal, or
1159 when one is a substring of the other. The proposed text below captures the logic of the
1160 code above.</p>
1161
1162
1163 <p><b>Proposed resolution:</b></p>
1164 <p>In 22.2.2.1.2 [facet.num.get.virtuals], in the first line of paragraph 14,
1165 change "&amp;&amp;" to "&amp;".</p>
1166
1167 <p>Then, replace paragraphs 15 and 16 as follows:</p>
1168
1169 <blockquote>
1170
1171   <p>Otherwise target sequences are determined "as if" by
1172   calling the members <tt>falsename()</tt> and
1173   <tt>truename()</tt> of the facet obtained by
1174   <tt>use_facet&lt;numpunct&lt;charT&gt;&nbsp;&gt;(str.getloc())</tt>.
1175   Successive characters in the range <tt>[in,end)</tt> (see
1176   [lib.sequence.reqmts]) are obtained and matched against
1177   corresponding positions in the target sequences only as necessary to
1178   identify a unique match. The input iterator <tt>in</tt> is
1179   compared to <tt>end</tt> only when necessary to obtain a
1180   character. If and only if a target sequence is uniquely matched,
1181   <tt>val</tt> is set to the corresponding value.</p>
1182
1183 </blockquote>
1184
1185 <blockquote>
1186   <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
1187   successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
1188   <tt>str.eofbit</tt> if, when seeking another character to match, it is found that
1189   <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
1190   <tt>(str.failbit|str.eofbit)</tt>if
1191   the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
1192   <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
1193   <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
1194   <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
1195   <tt>true</tt>:"1"
1196   and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
1197   and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
1198   <tt>err==str.failbit</tt>. --end example]</p>
1199 </blockquote>
1200
1201
1202
1203
1204
1205 <hr>
1206 <h3><a name="18"></a>18. Get(...bool&amp;) omitted</h3>
1207 <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>
1208  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1209 <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>
1210 <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>
1211 <p><b>Discussion:</b></p>
1212 <p>In the list of num_get&lt;&gt; non-virtual members on page 22-23, the member
1213 that parses bool values was omitted from the list of definitions of non-virtual
1214 members, though it is listed in the class definition and the corresponding
1215 virtual is listed everywhere appropriate. </p>
1216
1217
1218 <p><b>Proposed resolution:</b></p>
1219 <p>Add at the beginning of 22.2.2.1.1 [facet.num.get.members]
1220 another get member for bool&amp;, copied from the entry in
1221 22.2.2.1 [locale.num.get].</p>
1222
1223
1224
1225
1226
1227 <hr>
1228 <h3><a name="19"></a>19. "Noconv" definition too vague</h3>
1229 <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>
1230  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1231 <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>
1232 <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>
1233 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#10">10</a></p>
1234 <p><b>Discussion:</b></p>
1235 <p>
1236 In the definitions of codecvt&lt;&gt;::do_out and do_in, they are
1237 specified to return noconv if "no conversion is
1238 needed". This definition is too vague, and does not say
1239 normatively what is done with the buffers.
1240 </p>
1241
1242
1243 <p><b>Proposed resolution:</b></p>
1244 <p>
1245 Change the entry for noconv in the table under paragraph 4 in section
1246 22.2.1.4.2 [locale.codecvt.virtuals] to read:
1247 </p>
1248 <blockquote>
1249   <p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
1250   and input sequence is identical to converted sequence.</p>
1251 </blockquote>
1252 <p>Change the Note in paragraph 2 to normative text as follows:</p>
1253 <blockquote>
1254   <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
1255   same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
1256   <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
1257   unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
1258 </blockquote>
1259
1260
1261
1262
1263
1264 <hr>
1265 <h3><a name="20"></a>20. Thousands_sep returns wrong type</h3>
1266 <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>
1267  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1268 <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>
1269 <p><b>Discussion:</b></p>
1270 <p>The synopsis for numpunct&lt;&gt;::do_thousands_sep, and the
1271 definition of numpunct&lt;&gt;::thousands_sep which calls it, specify
1272 that it returns a value of type char_type. Here it is erroneously
1273 described as returning a "string_type". </p>
1274
1275
1276 <p><b>Proposed resolution:</b></p>
1277 <p>In 22.2.3.1.2 [facet.numpunct.virtuals], above paragraph 2, change
1278 "string_type" to "char_type". </p>
1279
1280
1281
1282
1283
1284 <hr>
1285 <h3><a name="21"></a>21. Codecvt_byname&lt;&gt; instantiations</h3>
1286 <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>
1287  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1288 <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>
1289 <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>
1290 <p><b>Discussion:</b></p>
1291 <p>In the second table in the section, captioned "Required
1292 instantiations", the instantiations for codecvt_byname&lt;&gt;
1293 have been omitted. These are necessary to allow users to construct a
1294 locale by name from facets. </p>
1295
1296
1297 <p><b>Proposed resolution:</b></p>
1298 <p>Add in 22.1.1.1.1 [locale.category] to the table captioned
1299 "Required instantiations", in the category "ctype"
1300 the lines </p>
1301
1302 <blockquote>
1303   <pre>codecvt_byname&lt;char,char,mbstate_t&gt;,
1304 codecvt_byname&lt;wchar_t,char,mbstate_t&gt; </pre>
1305 </blockquote>
1306
1307
1308
1309
1310
1311 <hr>
1312 <h3><a name="22"></a>22. Member open vs. flags</h3>
1313 <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>
1314  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1315 <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>
1316 <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>
1317 <p><b>Discussion:</b></p>
1318 <p>The description of basic_istream&lt;&gt;::open leaves unanswered questions about how it
1319 responds to or changes flags in the error status for the stream. A strict reading
1320 indicates that it ignores the bits and does not change them, which confuses users who do
1321 not expect eofbit and failbit to remain set after a successful open. There are three
1322 reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
1323 and eofbit on call to open(). </p>
1324
1325
1326 <p><b>Proposed resolution:</b></p>
1327 <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:
1328 </p>
1329
1330 <blockquote>
1331   <p>A successful open does not change the error state.</p>
1332 </blockquote>
1333
1334
1335 <p><b>Rationale:</b></p>
1336 <p>This may seem surprising to some users, but it's just an instance
1337 of a general rule: error flags are never cleared by the
1338 implementation. The only way error flags are are ever cleared is if
1339 the user explicitly clears them by hand.</p>
1340
1341 <p>The LWG believed that preserving this general rule was
1342 important enough so that an exception shouldn't be made just for this
1343 one case.  The resolution of this issue clarifies what the LWG
1344 believes to have been the original intent.</p>
1345
1346
1347
1348
1349
1350
1351 <hr>
1352 <h3><a name="24"></a>24. "do_convert" doesn't exist</h3>
1353 <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>
1354  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1355 <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>
1356 <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>
1357 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#72">72</a></p>
1358 <p><b>Discussion:</b></p>
1359 <p>The description of codecvt&lt;&gt;::do_out and do_in mentions a
1360 symbol "do_convert" which is not defined in the
1361 standard. This is a leftover from an edit, and should be "do_in
1362 and do_out". </p>
1363
1364
1365 <p><b>Proposed resolution:</b></p>
1366 <p>In 22.2.1.4 [locale.codecvt], paragraph 3, change
1367 "do_convert" to "do_in or do_out". Also, in 22.2.1.4.2 [locale.codecvt.virtuals], change "do_convert()" to "do_in
1368 or do_out". </p>
1369
1370
1371
1372
1373
1374 <hr>
1375 <h3><a name="25"></a>25. String operator&lt;&lt; uses width() value wrong</h3>
1376 <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>
1377  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1378 <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>
1379 <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>
1380 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#67">67</a></p>
1381 <p><b>Discussion:</b></p>
1382 <p>In the description of operator&lt;&lt; applied to strings, the standard says that uses
1383 the smaller of os.width() and str.size(), to pad "as described in stage 3"
1384 elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
1385
1386
1387 <p><b>Proposed resolution:</b></p>
1388 <p>Change 21.3.8.9 [string.io]  paragraph 4 from:<br>
1389 <br>
1390 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
1391 ..."<br>
1392 <br>
1393 to: <br>
1394 <br>
1395 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
1396 ..."</p>
1397
1398
1399
1400
1401
1402 <hr>
1403 <h3><a name="26"></a>26. Bad sentry example</h3>
1404 <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>
1405  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1406 <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>
1407 <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>
1408 <p><b>Discussion:</b></p>
1409 <p>In paragraph 6, the code in the example: </p>
1410
1411 <pre>  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
1412   basic_istream&lt;charT,traits&gt;::sentry(
1413            basic_istream&lt;charT,traits&gt;&amp; is, bool noskipws = false) {
1414       ...
1415       int_type c;
1416       typedef ctype&lt;charT&gt; ctype_type;
1417       const ctype_type&amp; ctype = use_facet&lt;ctype_type&gt;(is.getloc());
1418       while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
1419         if (ctype.is(ctype.space,c)==0) {
1420           is.rdbuf()-&gt;sputbackc (c);
1421           break;
1422         }
1423       }
1424       ...
1425    }</pre>
1426
1427 <p>fails to demonstrate correct use of the facilities described. In
1428 particular, it fails to use traits operators, and specifies incorrect
1429 semantics. (E.g. it specifies skipping over the first character in the
1430 sequence without examining it.) </p>
1431
1432
1433 <p><b>Proposed resolution:</b></p>
1434 <p>Remove the example above from 27.6.1.1.3 [istream::sentry]
1435 paragraph 6.</p>
1436
1437
1438 <p><b>Rationale:</b></p>
1439 <p>The originally proposed replacement code for the example was not
1440 correct. The LWG tried in Kona and again in Tokyo to correct it
1441 without success. In Tokyo, an implementor reported that actual working
1442 code ran over one page in length and was quite complicated. The LWG
1443 decided that it would be counter-productive to include such a lengthy
1444 example, which might well still contain errors.</p>
1445
1446
1447
1448
1449
1450 <hr>
1451 <h3><a name="27"></a>27. String::erase(range) yields wrong iterator</h3>
1452 <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>
1453  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1454 <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>
1455 <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>
1456 <p><b>Discussion:</b></p>
1457 <p>The string::erase(iterator first, iterator last) is specified to return an element one
1458 place beyond the next element after the last one erased. E.g. for the string
1459 "abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
1460 while 'd' has not been erased. </p>
1461
1462
1463 <p><b>Proposed resolution:</b></p>
1464 <p>In 21.3.6.5 [string::erase], paragraph 10, change: </p>
1465
1466 <blockquote>
1467   <p>Returns: an iterator which points to the element immediately following _last_ prior to
1468   the element being erased. </p>
1469 </blockquote>
1470
1471 <p>to read </p>
1472
1473 <blockquote>
1474   <p>Returns: an iterator which points to the element pointed to by _last_ prior to the
1475   other elements being erased. </p>
1476 </blockquote>
1477
1478
1479
1480
1481
1482 <hr>
1483 <h3><a name="28"></a>28. Ctype&lt;char&gt;is ambiguous</h3>
1484 <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>
1485  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1486 <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>
1487 <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>
1488 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#236">236</a></p>
1489 <p><b>Discussion:</b></p>
1490 <p>The description of the vector form of ctype&lt;char&gt;::is can be interpreted to mean
1491 something very different from what was intended. Paragraph 4 says </p>
1492
1493 <blockquote>
1494   <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
1495   table()[(unsigned char)*p]. </p>
1496 </blockquote>
1497
1498 <p>This is intended to copy the value indexed from table()[] into the place identified in
1499 vec[]. </p>
1500
1501
1502 <p><b>Proposed resolution:</b></p>
1503 <p>Change 22.2.1.3.2 [facet.ctype.char.members], paragraph 4, to read </p>
1504
1505 <blockquote>
1506   <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
1507   the value table()[(unsigned char)*p]. </p>
1508 </blockquote>
1509
1510
1511
1512
1513
1514 <hr>
1515 <h3><a name="29"></a>29. Ios_base::init doesn't exist</h3>
1516 <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>
1517  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1518 <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>
1519 <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>
1520 <p><b>Discussion:</b></p>
1521 <p>Sections 27.3.1 [narrow.stream.objects] and 27.3.2 [wide.stream.objects] mention
1522 a function ios_base::init, which is not defined. Probably they mean
1523 basic_ios&lt;&gt;::init, defined in 27.4.4.1 [basic.ios.cons],
1524 paragraph 3. </p>
1525
1526
1527 <p><b>Proposed resolution:</b></p>
1528 <p>[R12: modified to include paragraph 5.]</p>
1529
1530 <p>In 27.3.1 [narrow.stream.objects] paragraph 2 and 5, change </p>
1531
1532 <blockquote>
1533   <p>ios_base::init </p>
1534 </blockquote>
1535
1536 <p>to </p>
1537
1538 <blockquote>
1539   <p>basic_ios&lt;char&gt;::init </p>
1540 </blockquote>
1541
1542 <p>Also, make a similar change in 27.3.2 [wide.stream.objects] except it
1543 should read </p>
1544
1545 <blockquote>
1546   <p>basic_ios&lt;wchar_t&gt;::init </p>
1547 </blockquote>
1548
1549
1550
1551
1552
1553 <hr>
1554 <h3><a name="30"></a>30. Wrong header for LC_*</h3>
1555 <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>
1556  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1557 <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>
1558 <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>
1559 <p><b>Discussion:</b></p>
1560 <p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in &lt;cctype&gt;,
1561 where they are in fact defined elsewhere to appear in &lt;clocale&gt;. </p>
1562
1563
1564 <p><b>Proposed resolution:</b></p>
1565 <p>In 22.1.1.1.1 [locale.category], paragraph 2, change
1566 "&lt;cctype&gt;" to read "&lt;clocale&gt;". </p>
1567
1568
1569
1570
1571
1572 <hr>
1573 <h3><a name="31"></a>31. Immutable locale values</h3>
1574 <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>
1575  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1576 <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>
1577 <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>
1578 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#378">378</a></p>
1579 <p><b>Discussion:</b></p>
1580 <p>Paragraph 6, says "An instance of <tt>locale</tt> is
1581 <i>immutable</i>; once a facet reference is obtained from it,
1582 ...". This has caused some confusion, because locale variables
1583 are manifestly assignable. </p>
1584
1585
1586 <p><b>Proposed resolution:</b></p>
1587 <p>In 22.1.1 [locale] replace paragraph 6</p>
1588
1589 <blockquote>
1590   <p>An instance of <tt>locale</tt> is immutable; once a facet
1591   reference is obtained from it, that reference remains usable as long
1592   as the locale value itself exists.</p>
1593 </blockquote>
1594
1595 <p>with</p>
1596
1597 <blockquote>
1598   <p>Once a facet reference is obtained from a locale object by
1599   calling use_facet&lt;&gt;, that reference remains usable, and the
1600   results from member functions of it may be cached and re-used, as
1601   long as some locale object refers to that facet.</p>
1602 </blockquote>
1603
1604
1605
1606
1607
1608 <hr>
1609 <h3><a name="32"></a>32. Pbackfail description inconsistent</h3>
1610 <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>
1611  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1612 <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>
1613 <p><b>Discussion:</b></p>
1614 <p>The description of the required state before calling virtual member
1615 basic_streambuf&lt;&gt;::pbackfail requirements is inconsistent with the conditions
1616 described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
1617 Specifically, the latter says it calls pbackfail if: </p>
1618
1619 <p>&nbsp;&nbsp;&nbsp; traits::eq(c,gptr()[-1]) is false </p>
1620
1621 <p>where pbackfail claims to require: </p>
1622
1623 <p>&nbsp;&nbsp;&nbsp; traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
1624
1625 <p>It appears that the pbackfail description is wrong. </p>
1626
1627
1628 <p><b>Proposed resolution:</b></p>
1629 <p>In 27.5.2.4.4 [streambuf.virt.pback], paragraph 1, change:</p>
1630
1631 <blockquote>
1632   <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
1633 </blockquote>
1634
1635 <p>to </p>
1636
1637 <blockquote>
1638   <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
1639   </p>
1640 </blockquote>
1641
1642
1643 <p><b>Rationale:</b></p>
1644 <p>Note deliberate reordering of arguments for clarity in addition to the correction of
1645 the argument value.</p>
1646
1647
1648
1649
1650
1651 <hr>
1652 <h3><a name="33"></a>33. Codecvt&lt;&gt; mentions from_type</h3>
1653 <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>
1654  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1655 <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>
1656 <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>
1657 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#43">43</a></p>
1658 <p><b>Discussion:</b></p>
1659 <p>In the table defining the results from do_out and do_in, the specification for the
1660 result <i>error</i> says </p>
1661
1662 <blockquote>
1663   <p>encountered a from_type character it could not convert </p>
1664 </blockquote>
1665
1666 <p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
1667 an internT for do_out. </p>
1668
1669
1670 <p><b>Proposed resolution:</b></p>
1671 <p>In 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 4, replace the definition
1672 in the table for the case of _error_ with </p>
1673
1674 <blockquote>
1675   <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
1676 </blockquote>
1677
1678
1679
1680
1681
1682 <hr>
1683 <h3><a name="34"></a>34. True/falsename() not in ctype&lt;&gt;</h3>
1684 <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>
1685  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1686 <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>
1687 <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>
1688 <p><b>Discussion:</b></p>
1689 <p>In paragraph 19, Effects:, members truename() and falsename are used from facet
1690 ctype&lt;charT&gt;, but it has no such members. Note that this is also a problem in
1691 22.2.2.1.2, addressed in (4). </p>
1692
1693
1694 <p><b>Proposed resolution:</b></p>
1695 <p>In 22.2.2.2.2 [facet.num.put.virtuals], paragraph 19, in the Effects:
1696 clause for member put(...., bool), replace the initialization of the
1697 string_type value s as follows: </p>
1698
1699 <blockquote>
1700   <pre>const numpunct&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(loc);
1701 string_type s = val ? np.truename() : np.falsename(); </pre>
1702 </blockquote>
1703
1704
1705
1706
1707
1708 <hr>
1709 <h3><a name="35"></a>35. No manipulator unitbuf in synopsis</h3>
1710 <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>
1711  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1712 <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>
1713 <p><b>Discussion:</b></p>
1714 <p>In 27.4.5.1 [fmtflags.manip], we have a definition for a manipulator
1715 named "unitbuf". Unlike other manipulators, it's not listed
1716 in synopsis. Similarly for "nounitbuf". </p>
1717
1718
1719 <p><b>Proposed resolution:</b></p>
1720 <p>Add to the synopsis for &lt;ios&gt; in 27.4 [iostreams.base], after
1721 the entry for "nouppercase", the prototypes: </p>
1722
1723 <blockquote>
1724   <pre>ios_base&amp; unitbuf(ios_base&amp; str);
1725 ios_base&amp; nounitbuf(ios_base&amp; str); </pre>
1726 </blockquote>
1727
1728
1729
1730
1731
1732 <hr>
1733 <h3><a name="36"></a>36. Iword &amp; pword storage lifetime omitted</h3>
1734 <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>
1735  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1736 <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>
1737 <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>
1738 <p><b>Discussion:</b></p>
1739 <p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
1740 specified badly, so that an implementation which only keeps the last value stored appears
1741 to conform. In particular, it says: </p>
1742
1743 <p>The reference returned may become invalid after another call to the object's iword
1744 member with a different index ... </p>
1745
1746 <p>This is not idle speculation; at least one implementation was done this way. </p>
1747
1748
1749 <p><b>Proposed resolution:</b></p>
1750 <p>Add in 27.4.2.5 [ios.base.storage], in both paragraph 2 and also in
1751 paragraph 4, replace the sentence: </p>
1752
1753 <blockquote>
1754   <p>The reference returned may become invalid after another call to the object's iword
1755   [pword] member with a different index, after a call to its copyfmt member, or when the
1756   object is destroyed. </p>
1757 </blockquote>
1758
1759 <p>with: </p>
1760
1761 <blockquote>
1762   <p>The reference returned is invalid after any other operations on the object. However,
1763   the value of the storage referred to is retained, so that until the next call to copyfmt,
1764   calling iword [pword] with the same index yields another reference to the same value. </p>
1765 </blockquote>
1766
1767 <p>substituting "iword" or "pword" as appropriate. </p>
1768
1769
1770
1771
1772
1773 <hr>
1774 <h3><a name="37"></a>37. Leftover "global" reference</h3>
1775 <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>
1776  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1777 <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>
1778 <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>
1779 <p><b>Discussion:</b></p>
1780 <p>In the overview of locale semantics, paragraph 4, is the sentence </p>
1781
1782 <blockquote>
1783   <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
1784   the standard exception bad_cast. </p>
1785 </blockquote>
1786
1787 <p>This is not supported by the definition of use_facet&lt;&gt;, and represents semantics
1788 from an old draft. </p>
1789
1790
1791 <p><b>Proposed resolution:</b></p>
1792 <p>In 22.1.1 [locale], paragraph 4, delete the parenthesized
1793 expression </p>
1794
1795 <blockquote>
1796   <p>(or, failing that, in the global locale) </p>
1797 </blockquote>
1798
1799
1800
1801
1802
1803 <hr>
1804 <h3><a name="38"></a>38. Facet definition incomplete</h3>
1805 <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>
1806  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1807 <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>
1808 <p><b>Discussion:</b></p>
1809 <p>It has been noticed by Esa Pulkkinen that the definition of
1810 "facet" is incomplete. In particular, a class derived from
1811 another facet, but which does not define a member <i>id</i>, cannot
1812 safely serve as the argument <i>F</i> to use_facet&lt;F&gt;(loc),
1813 because there is no guarantee that a reference to the facet instance
1814 stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
1815
1816
1817 <p><b>Proposed resolution:</b></p>
1818 <p>In the definition of std::use_facet&lt;&gt;(), replace the text in paragraph 1 which
1819 reads: </p>
1820
1821 <blockquote>
1822   <p>Get a reference to a facet of a locale. </p>
1823 </blockquote>
1824
1825 <p>with: </p>
1826
1827 <blockquote>
1828   <p>Requires: <tt>Facet</tt> is a facet class whose definition
1829   contains the public static member <tt>id</tt> as defined in 22.1.1.1.2 [locale.facet]. </p>
1830 </blockquote>
1831
1832 <p><i>[
1833 Kona: strike as overspecification the text "(not inherits)"
1834 from the original resolution, which read "... whose definition
1835 contains (not inherits) the public static member
1836 <tt>id</tt>..."
1837 ]</i></p>
1838
1839
1840
1841
1842
1843
1844
1845 <hr>
1846 <h3><a name="39"></a>39. istreambuf_iterator&lt;&gt;::operator++(int) definition garbled</h3>
1847 <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>
1848  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1849 <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>
1850 <p><b>Discussion:</b></p>
1851 <p>Following the definition of istreambuf_iterator&lt;&gt;::operator++(int) in paragraph
1852 3, the standard contains three lines of garbage text left over from a previous edit. </p>
1853
1854 <blockquote>
1855   <pre>istreambuf_iterator&lt;charT,traits&gt; tmp = *this;
1856 sbuf_-&gt;sbumpc();
1857 return(tmp); </pre>
1858 </blockquote>
1859
1860
1861 <p><b>Proposed resolution:</b></p>
1862 <p>In 24.5.3.4 [istreambuf.iterator::op++], delete the three lines of code at the
1863 end of paragraph 3. </p>
1864
1865
1866
1867
1868
1869 <hr>
1870 <h3><a name="40"></a>40. Meaningless normative paragraph in examples</h3>
1871 <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>
1872  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1873 <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>
1874 <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>
1875 <p><b>Discussion:</b></p>
1876 <p>Paragraph 3 of the locale examples is a description of part of an
1877 implementation technique that has lost its referent, and doesn't mean
1878 anything. </p>
1879
1880
1881 <p><b>Proposed resolution:</b></p>
1882 <p>Delete 22.2.8 [facets.examples] paragraph 3 which begins "This
1883 initialization/identification system depends...", or (at the
1884 editor's option) replace it with a place-holder to keep the paragraph
1885 numbering the same. </p>
1886
1887
1888
1889
1890
1891 <hr>
1892 <h3><a name="41"></a>41. Ios_base needs clear(), exceptions()</h3>
1893 <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>
1894  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1895 <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>
1896 <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>
1897 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#157">157</a></p>
1898 <p><b>Discussion:</b></p>
1899 <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,
1900 which may throw an exception". However, ios_base offers no
1901 interface to set or to test badbit; those interfaces are defined in
1902 basic_ios&lt;&gt;. </p>
1903
1904
1905 <p><b>Proposed resolution:</b></p>
1906 <p>Change the description in 27.4.2.5 [ios.base.storage] in
1907 paragraph 2, and also in paragraph 4, as follows. Replace</p>
1908
1909 <blockquote>
1910   <p>If the function fails it sets badbit, which may throw an exception.</p>
1911 </blockquote>
1912
1913 <p>with</p>
1914
1915 <blockquote>
1916   <p>If the function fails, and <tt>*this</tt> is a base sub-object of
1917   a <tt>basic_ios&lt;&gt;</tt> object or sub-object, the effect is
1918   equivalent to calling <tt>basic_ios&lt;&gt;::setstate(badbit)</tt>
1919   on the derived object (which may throw <tt>failure</tt>).</p>
1920 </blockquote>
1921
1922 <p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
1923 setstate(badbit).]</i></p>
1924
1925
1926
1927
1928
1929
1930
1931 <hr>
1932 <h3><a name="42"></a>42. String ctors specify wrong default allocator</h3>
1933 <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>
1934  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1935 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
1936 <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>
1937 <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>
1938 <p><b>Discussion:</b></p>
1939 <p>The basic_string&lt;&gt; copy constructor: </p>
1940
1941 <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1942              size_type n = npos, const Allocator&amp; a = Allocator()); </pre>
1943
1944 <p>specifies an Allocator argument default value that is
1945 counter-intuitive. The natural choice for a the allocator to copy from
1946 is str.get_allocator(). Though this cannot be expressed in
1947 default-argument notation, overloading suffices. </p>
1948
1949 <p>Alternatively, the other containers in Clause 23 (deque, list,
1950 vector) do not have this form of constructor, so it is inconsistent,
1951 and an evident source of confusion, for basic_string&lt;&gt; to have
1952 it, so it might better be removed. </p>
1953
1954
1955 <p><b>Proposed resolution:</b></p>
1956 <p> In 21.3 [basic.string], replace the declaration of the copy
1957 constructor as follows: </p>
1958
1959 <blockquote>
1960   <pre>basic_string(const basic_string&amp; str);
1961 basic_string(const basic_string&amp; str, size_type pos, size_type n = npos,
1962              const Allocator&amp; a = Allocator());</pre>
1963 </blockquote>
1964
1965 <p>In 21.3.1 [string.require], replace the copy constructor declaration
1966 as above. Add to paragraph 5, Effects:</p>
1967
1968 <blockquote>
1969   <p>In the first form, the Allocator value used is copied from
1970   <tt>str.get_allocator()</tt>.</p>
1971 </blockquote>
1972
1973
1974 <p><b>Rationale:</b></p>
1975 <p>The LWG believes the constructor is actually broken, rather than
1976 just an unfortunate design choice.</p>
1977
1978 <p>The LWG considered two other possible resolutions:</p>
1979
1980 <p>A. In 21.3 [basic.string], replace the declaration of the copy
1981 constructor as follows:</p>
1982
1983 <blockquote>
1984   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1985              size_type n = npos);
1986 basic_string(const basic_string&amp; str, size_type pos,
1987              size_type n, const Allocator&amp; a); </pre>
1988 </blockquote>
1989
1990 <p>In 21.3.1 [string.require], replace the copy constructor declaration
1991 as above. Add to paragraph 5, Effects: </p>
1992
1993 <blockquote>
1994   <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
1995   value <tt>str.get_allocator()</tt>. </p>
1996 </blockquote>
1997
1998 <p>B. In 21.3 [basic.string], and also in 21.3.1 [string.require], replace
1999 the declaration of the copy constructor as follows: </p>
2000
2001 <blockquote>
2002   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
2003              size_type n = npos); </pre>
2004 </blockquote>
2005
2006 <p>The proposed resolution reflects the original intent of the LWG. It
2007 was also noted by Pete Becker that this fix "will cause
2008 a small amount of existing code to now work correctly."</p>
2009
2010 <p><i>[
2011 Kona: issue editing snafu fixed - the proposed resolution now correctly
2012 reflects the LWG consensus.
2013 ]</i></p>
2014
2015
2016
2017
2018
2019
2020 <hr>
2021 <h3><a name="44"></a>44. Iostreams use operator== on int_type values</h3>
2022 <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>
2023  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
2024 <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>
2025 <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>
2026 <p><b>Discussion:</b></p>
2027 <p>Many of the specifications for iostreams specify that character
2028 values or their int_type equivalents are compared using operators ==
2029 or !=, though in other places traits::eq() or traits::eq_int_type is
2030 specified to be used throughout. This is an inconsistency; we should
2031 change uses of == and != to use the traits members instead. </p>
2032
2033
2034 <p><b>Proposed resolution:</b></p>
2035
2036 <p><i>[Pre-Kona: Dietmar supplied wording]</i></p>
2037
2038
2039 <p>List of changes to clause 27:</p>
2040 <ol>
2041 <li>
2042    In lib.basic.ios.members paragraph 13 (postcondition clause for
2043    'fill(cT)') change
2044
2045 <blockquote><pre>     fillch == fill()
2046 </pre></blockquote>
2047
2048    to
2049
2050 <blockquote><pre>     traits::eq(fillch, fill())
2051 </pre></blockquote>
2052
2053
2054 </li>
2055 <li>
2056    In lib.istream.unformatted paragraph 7 (effects clause for
2057    'get(cT,streamsize,cT)'), third bullet, change
2058
2059 <blockquote><pre>     c == delim for the next available input character c
2060 </pre></blockquote>
2061
2062    to
2063
2064 <blockquote><pre>     traits::eq(c, delim) for the next available input character c
2065 </pre></blockquote>
2066
2067 </li>
2068 <li>
2069    In lib.istream.unformatted paragraph 12 (effects clause for
2070    'get(basic_streambuf&lt;cT,Tr&gt;&amp;,cT)'), third bullet, change
2071
2072 <blockquote><pre>     c == delim for the next available input character c
2073 </pre></blockquote>
2074
2075    to
2076
2077 <blockquote><pre>     traits::eq(c, delim) for the next available input character c
2078 </pre></blockquote>
2079
2080 </li>
2081 <li>
2082    In lib.istream.unformatted paragraph 17 (effects clause for
2083    'getline(cT,streamsize,cT)'), second bullet, change
2084
2085 <blockquote><pre>     c == delim for the next available input character c
2086 </pre></blockquote>
2087
2088    to
2089
2090 <blockquote><pre>     traits::eq(c, delim) for the next available input character c
2091   </pre></blockquote>
2092
2093 </li>
2094 <li>
2095    In lib.istream.unformatted paragraph 24 (effects clause for
2096    'ignore(int,int_type)'), second bullet, change
2097
2098 <blockquote><pre>     c == delim for the next available input character c
2099 </pre></blockquote>
2100
2101    to
2102
2103 <blockquote><pre>     traits::eq_int_type(c, delim) for the next available input
2104      character c
2105 </pre></blockquote>
2106
2107 </li>
2108 <li>
2109    In lib.istream.unformatted paragraph 25 (notes clause for
2110    'ignore(int,int_type)'), second bullet, change
2111
2112 <blockquote><pre>     The last condition will never occur if delim == traits::eof()
2113 </pre></blockquote>
2114
2115    to
2116
2117 <blockquote><pre>     The last condition will never occur if
2118      traits::eq_int_type(delim, traits::eof()).
2119 </pre></blockquote>
2120
2121 </li>
2122 <li>
2123    In lib.istream.sentry paragraph 6 (example implementation for the
2124    sentry constructor) change
2125
2126 <blockquote><pre>     while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
2127 </pre></blockquote>
2128
2129    to
2130
2131 <blockquote><pre>     while (!traits::eq_int_type(c = is.rdbuf()-&gt;snextc(), traits::eof())) {
2132 </pre></blockquote>
2133
2134 </li>
2135 </ol>
2136
2137 <p>List of changes to Chapter 21:</p>
2138
2139 <ol>
2140 <li>
2141    In lib.string::find paragraph 1 (effects clause for find()),
2142    second bullet, change
2143
2144 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2145 </pre></blockquote>
2146
2147    to
2148
2149 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2150 </pre></blockquote>
2151
2152 </li>
2153 <li>
2154    In lib.string::rfind paragraph 1 (effects clause for rfind()),
2155    second bullet, change
2156
2157 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2158 </pre></blockquote>
2159
2160    to
2161
2162 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2163 </pre></blockquote>
2164
2165 </li>
2166 <li>
2167    In lib.string::find.first.of paragraph 1 (effects clause for
2168    find_first_of()), second bullet, change
2169
2170 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2171 </pre></blockquote>
2172
2173    to
2174
2175 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2176 </pre></blockquote>
2177
2178 </li>
2179 <li>
2180    In lib.string::find.last.of paragraph 1 (effects clause for
2181    find_last_of()), second bullet, change
2182
2183 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2184 </pre></blockquote>
2185
2186    to
2187
2188 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2189 </pre></blockquote>
2190
2191 </li>
2192 <li>
2193    In lib.string::find.first.not.of paragraph 1 (effects clause for
2194    find_first_not_of()), second bullet, change
2195
2196 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2197 </pre></blockquote>
2198
2199    to
2200
2201 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2202 </pre></blockquote>
2203 </li>
2204
2205 <li>
2206    In lib.string::find.last.not.of paragraph 1 (effects clause for
2207    find_last_not_of()), second bullet, change
2208
2209 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2210 </pre></blockquote>
2211
2212    to
2213
2214 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2215 </pre></blockquote>
2216 </li>
2217
2218 <li>
2219    In lib.string.ios paragraph 5 (effects clause for getline()),
2220    second bullet, change
2221
2222 <blockquote><pre>     c == delim for the next available input character c
2223 </pre></blockquote>
2224
2225    to
2226
2227 <blockquote><pre>     traits::eq(c, delim) for the next available input character c
2228 </pre></blockquote>
2229 </li>
2230
2231 </ol>
2232
2233 <p>Notes:</p>
2234 <ul>
2235 <li>
2236   Fixing this issue highlights another sloppyness in
2237   lib.istream.unformatted paragraph 24: this clause mentions a "character"
2238   which is then compared to an 'int_type' (see item 5. in the list
2239   below). It is not clear whether this requires explicit words and
2240   if so what these words are supposed to be. A similar issue exists,
2241   BTW, for operator*() of istreambuf_iterator which returns the result
2242   of sgetc() as a character type (see lib.istreambuf.iterator::op*
2243   paragraph 1), and for operator++() of istreambuf_iterator which
2244   passes the result of sbumpc() to a constructor taking a char_type
2245   (see lib.istreambuf.iterator::operator++ paragraph 3). Similarily, the
2246   assignment operator ostreambuf_iterator passes a char_type to a function
2247   taking an int_type (see lib.ostreambuf.iter.ops paragraph 1).
2248 </li>
2249 <li>
2250   It is inconsistent to use comparisons using the traits functions in
2251   Chapter 27 while not using them in Chapter 21, especially as some
2252   of the inconsistent uses actually involve streams (eg. getline() on
2253   streams). To avoid leaving this issue open still longer due to this
2254   inconsistency (it is open since 1998), a list of changes to Chapter
2255   21 is below.
2256 </li>
2257 <li>
2258   In Chapter 24 there are several places with statements like "the end
2259   of stream is reached (streambuf_type::sgetc() returns traits::eof())"
2260   (lib.istreambuf.iterator paragraph 1, lib.ostreambuf.iter.ops
2261   paragraph 5). It is unclear whether these should be clarified to use
2262   traits::eq_int_type() for detecting traits::eof().
2263 </li>
2264 </ul>
2265
2266
2267
2268
2269
2270
2271 <hr>
2272 <h3><a name="46"></a>46. Minor Annex D errors</h3>
2273 <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>
2274  <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1998-06-01</p>
2275 <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>
2276 <p><b>Discussion:</b></p><p>See lib-6522 and edit-814.</p>
2277
2278 <p><b>Proposed resolution:</b></p>
2279 <p>Change D.7.1 [depr.strstreambuf] (since streambuf is a typedef of
2280 basic_streambuf&lt;char&gt;) from:</p>
2281
2282 <pre>         virtual streambuf&lt;char&gt;* setbuf(char* s, streamsize n);</pre>
2283
2284 <p>to:</p>
2285
2286 <pre>         virtual streambuf* setbuf(char* s, streamsize n);</pre>
2287
2288 <p>In D.7.4 [depr.strstream] insert the semicolon now missing after
2289 int_type:</p>
2290
2291 <pre>     namespace std {
2292        class strstream
2293          : public basic_iostream&lt;char&gt; {
2294        public:
2295          // Types
2296          typedef char                                char_type;
2297          typedef typename char_traits&lt;char&gt;::int_type int_type
2298          typedef typename char_traits&lt;char&gt;::pos_type pos_type;</pre>
2299
2300
2301
2302
2303
2304 <hr>
2305 <h3><a name="47"></a>47. Imbue() and getloc() Returns clauses swapped</h3>
2306 <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>
2307  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p>
2308 <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>
2309 <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>
2310 <p><b>Discussion:</b></p>
2311 <p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
2312 section has two RETURNS clauses, and they make no sense as
2313 stated. They make perfect sense, though, if you swap them. Am I
2314 correct in thinking that paragraphs 2 and 4 just got mixed up by
2315 accident?</p>
2316
2317
2318 <p><b>Proposed resolution:</b></p>
2319 <p>In 27.4.2.3 [ios.base.locales] swap paragraphs 2 and 4.</p>
2320
2321
2322
2323
2324
2325 <hr>
2326 <h3><a name="48"></a>48. Use of non-existent exception constructor</h3>
2327 <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>
2328  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p>
2329 <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>
2330 <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>
2331 <p><b>Discussion:</b></p>
2332 <p>27.4.2.1.1, paragraph 2, says that class failure initializes the
2333 base class, exception, with exception(msg). Class exception (see
2334 18.6.1) has no such constructor.</p>
2335
2336
2337 <p><b>Proposed resolution:</b></p>
2338 <p>Replace 27.4.2.1.1 [ios::failure], paragraph 2, with</p>
2339
2340 <blockquote>
2341   <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
2342 </blockquote>
2343
2344
2345
2346
2347
2348 <hr>
2349 <h3><a name="49"></a>49. Underspecification of ios_base::sync_with_stdio</h3>
2350 <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>
2351  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p>
2352 <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>
2353 <p><b>Discussion:</b></p>
2354 <p>Two problems</p>
2355
2356 <p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
2357 returns. Does it return f, or does it return the previous
2358 synchronization state? My guess is the latter, but the standard
2359 doesn't say so.</p>
2360
2361 <p>(2) 27.4.2.4 doesn't say what it means for streams to be
2362 synchronized with stdio.  Again, of course, I can make some
2363 guesses. (And I'm unhappy about the performance implications of those
2364 guesses, but that's another matter.)</p>
2365
2366
2367 <p><b>Proposed resolution:</b></p>
2368 <p>Change the following sentence in 27.4.2.4 [ios.members.static]
2369 returns clause from:</p>
2370
2371 <blockquote>
2372   <p><tt>true</tt> if the standard iostream objects (27.3) are
2373   synchronized and otherwise returns <tt>false</tt>.</p>
2374 </blockquote>
2375
2376 <p>to:</p>
2377
2378 <blockquote>
2379   <p><tt>true</tt> if the previous state of the standard iostream
2380   objects (27.3) was synchronized and otherwise returns
2381   <tt>false</tt>.</p>
2382 </blockquote>
2383
2384 <p>Add the following immediately after 27.4.2.4 [ios.members.static],
2385 paragraph 2:</p>
2386
2387 <blockquote>
2388 <p>When a standard iostream object str is <i>synchronized</i> with a
2389 standard stdio stream f, the effect of inserting a character c by</p>
2390 <pre>  fputc(f, c);
2391 </pre>
2392
2393 <p>is the same as the effect of</p>
2394 <pre>  str.rdbuf()-&gt;sputc(c);
2395 </pre>
2396
2397 <p>for any sequence of characters; the effect of extracting a
2398 character c by</p>
2399 <pre>  c = fgetc(f);
2400 </pre>
2401
2402 <p>is the same as the effect of:</p>
2403 <pre>  c = str.rdbuf()-&gt;sbumpc(c);
2404 </pre>
2405
2406 <p>for any sequences of characters; and the effect of pushing
2407 back a character c by</p>
2408 <pre>  ungetc(c, f);
2409 </pre>
2410
2411 <p>is the same as the effect of</p>
2412 <pre>  str.rdbuf()-&gt;sputbackc(c);
2413 </pre>
2414
2415 <p>for any sequence of characters.  [<i>Footnote</i>: This implies
2416 that operations on a standard iostream object can be mixed arbitrarily
2417 with operations on the corresponding stdio stream.  In practical
2418 terms, synchronization usually means that a standard iostream object
2419 and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
2420 </blockquote>
2421
2422 <p><i>[pre-Copenhagen: PJP and Matt contributed the definition
2423 of "synchronization"]</i></p>
2424
2425
2426 <p><i>[post-Copenhagen: proposed resolution was revised slightly:
2427 text was added in the non-normative footnote to say that operations
2428 on the two streams can be mixed arbitrarily.]</i></p>
2429
2430
2431
2432
2433
2434
2435 <hr>
2436 <h3><a name="50"></a>50. Copy constructor and assignment operator of ios_base</h3>
2437 <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>
2438  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p>
2439 <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>
2440 <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>
2441 <p><b>Discussion:</b></p>
2442 <p>As written, ios_base has a copy constructor and an assignment
2443 operator. (Nothing in the standard says it doesn't have one, and all
2444 classes have copy constructors and assignment operators unless you
2445 take specific steps to avoid them.) However, nothing in 27.4.2 says
2446 what the copy constructor and assignment operator do. </p>
2447
2448 <p>My guess is that this was an oversight, that ios_base is, like
2449 basic_ios, not supposed to have a copy constructor or an assignment
2450 operator.</p>
2451
2452 <p>
2453 Jerry Schwarz comments: Yes, its an oversight, but in the opposite
2454 sense to what you're suggesting. At one point there was a definite
2455 intention that you could copy ios_base. It's an easy way to save the
2456 entire state of a stream for future use. As you note, to carry out
2457 that intention would have required a explicit description of the
2458 semantics (e.g. what happens to the iarray and parray stuff).
2459 </p>
2460
2461
2462 <p><b>Proposed resolution:</b></p>
2463 <p>In 27.4.2 [ios.base], class ios_base, specify the copy
2464 constructor and operator= members as being private.</p>
2465
2466
2467 <p><b>Rationale:</b></p>
2468 <p>The LWG believes the difficulty of specifying correct semantics
2469 outweighs any benefit of allowing ios_base objects to be copyable.</p>
2470
2471
2472
2473
2474
2475 <hr>
2476 <h3><a name="51"></a>51. Requirement to not invalidate iterators missing</h3>
2477 <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>
2478  <b>Submitter:</b> David Vandevoorde <b>Date:</b> 1998-06-23</p>
2479 <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>
2480 <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>
2481 <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>
2482 <p><b>Discussion:</b></p>
2483 <p>The std::sort algorithm can in general only sort a given sequence
2484 by moving around values. The list&lt;&gt;::sort() member on the other
2485 hand could move around values or just update internal pointers. Either
2486 method can leave iterators into the list&lt;&gt; dereferencable, but
2487 they would point to different things. </p>
2488
2489 <p>Does the FDIS mandate anywhere which method should be used for
2490 list&lt;&gt;::sort()?</p>
2491
2492 <p>Matt Austern comments:</p>
2493
2494 <p>I think you've found an omission in the standard. </p>
2495
2496 <p>The library working group discussed this point, and there was
2497 supposed to be a general requirement saying that list, set, map,
2498 multiset, and multimap may not invalidate iterators, or change the
2499 values that iterators point to, except when an operation does it
2500 explicitly. So, for example, insert() doesn't invalidate any iterators
2501 and erase() and remove() only invalidate iterators pointing to the
2502 elements that are being erased. </p>
2503
2504 <p>I looked for that general requirement in the FDIS, and, while I
2505 found a limited form of it for the sorted associative containers, I
2506 didn't find it for list. It looks like it just got omitted. </p>
2507
2508 <p>The intention, though, is that list&lt;&gt;::sort does not
2509 invalidate any iterators and does not change the values that any
2510 iterator points to. There would be no reason to have the member
2511 function otherwise.</p>
2512
2513
2514 <p><b>Proposed resolution:</b></p>
2515 <p>Add a new paragraph at the end of 23.1:</p>
2516
2517 <blockquote>
2518   <p>Unless otherwise specified (either explicitly or by defining a function in terms of
2519   other functions), invoking a container member function or passing a container as an
2520   argument to a library function shall not invalidate iterators to, or change the values of,
2521   objects within that container. </p>
2522 </blockquote>
2523
2524
2525 <p><b>Rationale:</b></p>
2526 <p>This was US issue CD2-23-011; it was accepted in London but the
2527 change was not made due to an editing oversight. The wording in the
2528 proposed resolution below is somewhat updated from CD2-23-011,
2529 particularly the addition of the phrase "or change the values
2530 of"</p>
2531
2532
2533
2534
2535
2536 <hr>
2537 <h3><a name="52"></a>52. Small I/O problems</h3>
2538 <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>
2539  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-23</p>
2540 <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>
2541 <p><b>Discussion:</b></p>
2542 <p>First, 27.4.4.1 [basic.ios.cons], table 89. This is pretty obvious:
2543 it should be titled "basic_ios&lt;&gt;() effects", not
2544 "ios_base() effects". </p>
2545
2546 <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
2547 resolution.]</p>
2548
2549 <p>Second, 27.4.3.2 [fpos.operations] table 88 . There are a couple
2550 different things wrong with it, some of which I've already discussed
2551 with Jerry, but the most obvious mechanical sort of error is that it
2552 uses expressions like P(i) and p(i), without ever defining what sort
2553 of thing "i" is.
2554 </p>
2555
2556 <p>(The other problem is that it requires support for streampos
2557 arithmetic. This is impossible on some systems, i.e. ones where file
2558 position is a complicated structure rather than just a number. Jerry
2559 tells me that the intention was to require syntactic support for
2560 streampos arithmetic, but that it wasn't actually supposed to do
2561 anything meaningful except on platforms, like Unix, where genuine
2562 arithmetic is possible.) </p>
2563
2564
2565 <p><b>Proposed resolution:</b></p>
2566 <p>Change 27.4.4.1 [basic.ios.cons] table 89 title from
2567 "ios_base() effects" to "basic_ios&lt;&gt;()
2568 effects". </p>
2569
2570
2571
2572
2573
2574 <hr>
2575 <h3><a name="53"></a>53. Basic_ios destructor unspecified</h3>
2576 <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>
2577  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-23</p>
2578 <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>
2579 <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>
2580 <p><b>Discussion:</b></p>
2581 <p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
2582 The important question is whether basic_ios::~basic_ios() destroys
2583 rdbuf().</p>
2584
2585
2586 <p><b>Proposed resolution:</b></p>
2587 <p>Add after 27.4.4.1 [basic.ios.cons] paragraph 2:</p>
2588
2589 <blockquote>
2590   <p><tt>virtual ~basic_ios();</tt></p>
2591   <p><b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
2592 </blockquote>
2593
2594
2595 <p><b>Rationale:</b></p>
2596 <p>The LWG reviewed the additional question of whether or not
2597 <tt>rdbuf(0)</tt> may set <tt>badbit</tt>.  The answer is
2598 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
2599 by the LWG, which removed from the original proposed resolution a
2600 footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
2601 <tt>badbit</tt>".</p>
2602
2603
2604
2605
2606
2607 <hr>
2608 <h3><a name="54"></a>54. Basic_streambuf's destructor</h3>
2609 <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>
2610  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-25</p>
2611 <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>
2612 <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>
2613 <p><b>Discussion:</b></p>
2614 <p>The class synopsis for basic_streambuf shows a (virtual)
2615 destructor, but the standard doesn't say what that destructor does. My
2616 assumption is that it does nothing, but the standard should say so
2617 explicitly. </p>
2618
2619
2620 <p><b>Proposed resolution:</b></p>
2621 <p>Add after 27.5.2.1 [streambuf.cons] paragraph 2:</p>
2622
2623 <blockquote>
2624   <p><tt>virtual&nbsp; ~basic_streambuf();</tt></p>
2625   <p><b>Effects</b>: None.</p>
2626 </blockquote>
2627
2628
2629
2630
2631
2632 <hr>
2633 <h3><a name="55"></a>55. Invalid stream position is undefined</h3>
2634 <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>
2635  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-26</p>
2636 <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>
2637 <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>
2638 <p><b>Discussion:</b></p>
2639 <p>Several member functions in clause 27 are defined in certain
2640 circumstances to return an "invalid stream position", a term
2641 that is defined nowhere in the standard. Two places (27.5.2.4.2,
2642 paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
2643 a definition in _lib.iostreams.definitions_, a nonexistent
2644 section. </p>
2645
2646 <p>I suspect that the invalid stream position is just supposed to be
2647 pos_type(-1).  Probably best to say explicitly in (for example)
2648 27.5.2.4.2 that the return value is pos_type(-1), rather than to use
2649 the term "invalid stream position", define that term
2650 somewhere, and then put in a cross-reference. </p>
2651
2652 <p>The phrase "invalid stream position" appears ten times in
2653 the C++ Standard.  In seven places it refers to a return value, and it
2654 should be changed. In three places it refers to an argument, and it
2655 should not be changed. Here are the three places where "invalid
2656 stream position" should not be changed:</p>
2657
2658 <blockquote>
2659   <p>27.7.1.4 [stringbuf.virtuals], paragraph 14<br>
2660   27.8.1.5 [filebuf.virtuals], paragraph 14<br>
2661   D.7.1.3 [depr.strstreambuf.virtuals], paragraph 17
2662   </p>
2663 </blockquote>
2664
2665
2666 <p><b>Proposed resolution:</b></p>
2667 <p>In 27.5.2.4.2 [streambuf.virt.buffer], paragraph 4, change "Returns an
2668 object of class pos_type that stores an invalid stream position
2669 (_lib.iostreams.definitions_)" to "Returns
2670 <tt>pos_type(off_type(-1))</tt>".
2671 </p>
2672
2673 <p>In 27.5.2.4.2 [streambuf.virt.buffer], paragraph 6, change "Returns
2674 an object of class pos_type that stores an invalid stream
2675 position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
2676
2677 <p>In 27.7.1.4 [stringbuf.virtuals], paragraph 13, change "the object
2678 stores an invalid stream position" to "the return value is
2679 <tt>pos_type(off_type(-1))</tt>". </p>
2680
2681 <p>In 27.8.1.5 [filebuf.virtuals], paragraph 13, change "returns an
2682 invalid stream position (27.4.3)" to "returns
2683 <tt>pos_type(off_type(-1))</tt>" </p>
2684
2685 <p>In 27.8.1.5 [filebuf.virtuals], paragraph 15, change "Otherwise
2686 returns an invalid stream position (_lib.iostreams.definitions_)"
2687 to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
2688 </p>
2689
2690 <p>In D.7.1.3 [depr.strstreambuf.virtuals], paragraph 15, change "the object
2691 stores an invalid stream position" to "the return value is
2692 <tt>pos_type(off_type(-1))</tt>" </p>
2693
2694 <p>In D.7.1.3 [depr.strstreambuf.virtuals], paragraph 18, change "the object
2695 stores an invalid stream position" to "the return value is
2696 <tt>pos_type(off_type(-1))</tt>"</p>
2697
2698
2699
2700
2701
2702 <hr>
2703 <h3><a name="56"></a>56. Showmanyc's return type</h3>
2704 <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>
2705  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-29</p>
2706 <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>
2707 <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>
2708 <p><b>Discussion:</b></p>
2709 <p>The class summary for basic_streambuf&lt;&gt;, in 27.5.2, says that
2710 showmanyc has return type int. However, 27.5.2.4.3 says that its
2711 return type is streamsize. </p>
2712
2713
2714 <p><b>Proposed resolution:</b></p>
2715 <p>Change <tt>showmanyc</tt>'s return type in the
2716 27.5.2 [streambuf] class summary to <tt>streamsize</tt>.</p>
2717
2718
2719
2720
2721
2722 <hr>
2723 <h3><a name="57"></a>57. Mistake in char_traits</h3>
2724 <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>
2725  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-07-01</p>
2726 <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>
2727 <p><b>Discussion:</b></p>
2728 <p>21.1.3.2, paragraph 3, says "The types streampos and
2729 wstreampos may be different if the implementation supports no shift
2730 encoding in narrow-oriented iostreams but supports one or more shift
2731 encodings in wide-oriented streams". </p>
2732
2733 <p>That's wrong: the two are the same type. The &lt;iosfwd&gt; summary
2734 in 27.2 says that streampos and wstreampos are, respectively, synonyms
2735 for fpos&lt;char_traits&lt;char&gt;::state_type&gt; and
2736 fpos&lt;char_traits&lt;wchar_t&gt;::state_type&gt;, and, flipping back
2737 to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
2738 char_traits&lt;char&gt;::state_type and
2739 char_traits&lt;wchar_t&gt;::state_type must both be mbstate_t. </p>
2740
2741
2742 <p><b>Proposed resolution:</b></p>
2743 <p>Remove the sentence in 21.1.3.4 [char.traits.specializations.wchar.t] paragraph 3 which
2744 begins "The types streampos and wstreampos may be
2745 different..." . </p>
2746
2747
2748
2749
2750
2751 <hr>
2752 <h3><a name="59"></a>59. Ambiguity in specification of gbump</h3>
2753 <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>
2754  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-07-28</p>
2755 <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>
2756 <p><b>Discussion:</b></p>
2757 <p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
2758 next pointer for the input sequence by n." </p>
2759
2760 <p>The straightforward interpretation is that it is just gptr() +=
2761 n. An alternative interpretation, though, is that it behaves as if it
2762 calls sbumpc n times. (The issue, of course, is whether it might ever
2763 call underflow.) There is a similar ambiguity in the case of
2764 pbump. </p>
2765
2766 <p>(The "classic" AT&amp;T implementation used the
2767 former interpretation.)</p>
2768
2769
2770 <p><b>Proposed resolution:</b></p>
2771 <p>Change 27.5.2.3.2 [streambuf.get.area] paragraph 4 gbump effects from:</p>
2772
2773 <blockquote>
2774   <p>Effects: Advances the next pointer for the input sequence by n.</p>
2775 </blockquote>
2776
2777 <p>to:</p>
2778
2779 <blockquote>
2780   <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
2781 </blockquote>
2782
2783 <p>Make the same change to 27.5.2.3.3 [streambuf.put.area] paragraph 4 pbump
2784 effects.</p>
2785
2786
2787
2788
2789
2790 <hr>
2791 <h3><a name="60"></a>60. What is a formatted input function?</h3>
2792 <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>
2793  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-03</p>
2794 <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>
2795 <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>
2796 <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>
2797 <p><b>Discussion:</b></p>
2798 <p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
2799 formatted input functions. Some of the functions defined in section
2800 27.6.1.2 explicitly say that those requirements apply ("Behaves
2801 like a formatted input member (as described in 27.6.1.2.1)"), but
2802 others don't. The question: is 27.6.1.2.1 supposed to apply to
2803 everything in 27.6.1.2, or only to those member functions that
2804 explicitly say "behaves like a formatted input member"? Or
2805 to put it differently: are we to assume that everything that appears
2806 in a section called "Formatted input functions" really is a
2807 formatted input function? I assume that 27.6.1.2.1 is intended to
2808 apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
2809 is not intended to apply to extractors like </p>
2810
2811 <pre>    basic_istream&amp; operator&gt;&gt;(basic_istream&amp; (*pf)(basic_istream&amp;));</pre>
2812
2813 <p>and </p>
2814
2815 <pre>    basic_istream&amp; operator&gt;&gt;(basic_streammbuf*);</pre>
2816
2817 <p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
2818 output. </p>
2819
2820 <p>Comments from Judy Ward: It seems like the problem is that the
2821 basic_istream and basic_ostream operator &lt;&lt;()'s that are used
2822 for the manipulators and streambuf* are in the wrong section and
2823 should have their own separate section or be modified to make it clear
2824 that the "Common requirements" listed in section 27.6.1.2.1
2825 (for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
2826 apply to them. </p>
2827
2828 <p>Additional comments from Dietmar Kühl: It appears to be somewhat
2829 nonsensical to consider the functions defined in 27.6.1.2.3
2830 [istream::extractors] paragraphs 1 to 5 to be "Formatted input
2831 function" but since these functions are defined in a section
2832 labeled "Formatted input functions" it is unclear to me
2833 whether these operators are considered formatted input functions which
2834 have to conform to the "common requirements" from 27.6.1.2.1
2835 [istream.formatted.reqmts]: If this is the case, all manipulators, not
2836 just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
2837 set (... but setting <tt>noskipws</tt> using the manipulator syntax
2838 would also skip whitespace :-)</p> <p>It is not clear which functions
2839 are to be considered unformatted input functions. As written, it seems
2840 that all functions in 27.6.1.3 [istream.unformatted] are unformatted input
2841 functions. However, it does not really make much sense to construct a
2842 sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
2843 unclear what happens to the <tt>gcount()</tt> if
2844 eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
2845 <tt>sync()</tt> is called: These functions don't extract characters,
2846 some of them even "unextract" a character. Should this still
2847 be reflected in <tt>gcount()</tt>? Of course, it could be read as if
2848 after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
2849 (the last unformatted input function, <tt>gcount()</tt>, didn't
2850 extract any character) and after a call to <tt>putback()</tt>
2851 <tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
2852 function <tt>putback()</tt> did "extract" back into the
2853 stream). Correspondingly for <tt>unget()</tt>. Is this what is
2854 intended?  If so, this should be clarified. Otherwise, a corresponding
2855 clarification should be used.</p>
2856
2857
2858 <p><b>Proposed resolution:</b></p>
2859 <p>
2860 In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
2861 Change the beginning of the second sentence from "The conversion
2862 occurs" to "These extractors behave as formatted input functions (as
2863 described in 27.6.1.2.1).  After a sentry object is constructed,
2864 the conversion occurs"
2865 </p>
2866
2867 <p>
2868 In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
2869 Add an effects clause.  "Effects: None.  This extractor does
2870 not behave as a formatted input function (as described in
2871 27.6.1.2.1).
2872 </p>
2873
2874 <p>
2875 In 27.6.1.2.3, [lib.istream::extractors], paragraph 2.  Change the
2876 effects clause to "Effects: Calls pf(*this).  This extractor does not
2877 behave as a formatted input function (as described in 27.6.1.2.1).
2878 </p>
2879
2880 <p>
2881 In 27.6.1.2.3, [lib.istream::extractors], paragraph 4.  Change the
2882 effects clause to "Effects: Calls pf(*this).  This extractor does not
2883 behave as a formatted input function (as described in 27.6.1.2.1).
2884 </p>
2885
2886 <p>
2887 In 27.6.1.2.3, [lib.istream::extractors], paragraph 12.  Change the
2888 first two sentences from "If sb is null, calls setstate(failbit),
2889 which may throw ios_base::failure (27.4.4.3).  Extracts characters
2890 from *this..." to "Behaves as a formatted input function (as described
2891 in 27.6.1.2.1).  If sb is null, calls setstate(failbit), which may
2892 throw ios_base::failure (27.4.4.3).  After a sentry object is
2893 constructed, extracts characters from *this...".
2894 </p>
2895
2896 <p>
2897 In 27.6.1.3, [lib.istream.unformatted], before paragraph 2.  Add an
2898 effects clause.  "Effects: none. This member function does not behave
2899 as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
2900 </p>
2901
2902 <p>
2903 In 27.6.1.3, [lib.istream.unformatted], paragraph 3.  Change the
2904 beginning of the first sentence of the effects clause from "Extracts a
2905 character" to "Behaves as an unformatted input function (as described
2906 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
2907 character"
2908 </p>
2909
2910 <p>
2911 In 27.6.1.3, [lib.istream.unformatted], paragraph 5.  Change the
2912 beginning of the first sentence of the effects clause from "Extracts a
2913 character" to "Behaves as an unformatted input function (as described
2914 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
2915 character"
2916 </p>
2917
2918 <p>
2919 In 27.6.1.3, [lib.istream.unformatted], paragraph 7.  Change the
2920 beginning of the first sentence of the effects clause from "Extracts
2921 characters" to "Behaves as an unformatted input function (as described
2922 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2923 characters"
2924 </p>
2925
2926 <p>
2927 [No change needed in paragraph 10, because it refers to paragraph 7.]
2928 </p>
2929
2930 <p>
2931 In 27.6.1.3, [lib.istream.unformatted], paragraph 12.  Change the
2932 beginning of the first sentence of the effects clause from "Extracts
2933 characters" to "Behaves as an unformatted input function (as described
2934 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2935 characters"
2936 </p>
2937
2938 <p>
2939 [No change needed in paragraph 15.]
2940 </p>
2941
2942 <p>
2943 In 27.6.1.3, [lib.istream.unformatted], paragraph 17.  Change the
2944 beginning of the first sentence of the effects clause from "Extracts
2945 characters" to "Behaves as an unformatted input function (as described
2946 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2947 characters"
2948 </p>
2949
2950 <p>
2951 [No change needed in paragraph 23.]
2952 </p>
2953
2954 <p>
2955 In 27.6.1.3, [lib.istream.unformatted], paragraph 24.  Change the
2956 beginning of the first sentence of the effects clause from "Extracts
2957 characters" to "Behaves as an unformatted input function (as described
2958 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2959 characters"
2960 </p>
2961
2962 <p>
2963 In 27.6.1.3, [lib.istream.unformatted], before paragraph 27.  Add an
2964 Effects clause: "Effects: Behaves as an unformatted input function (as
2965 described in 27.6.1.3, paragraph 1).  After constructing a sentry
2966 object, reads but does not extract the current input character."
2967 </p>
2968
2969 <p>
2970 In 27.6.1.3, [lib.istream.unformatted], paragraph 28.  Change the
2971 first sentence of the Effects clause from "If !good() calls" to
2972 Behaves as an unformatted input function (as described in 27.6.1.3,
2973 paragraph 1).  After constructing a sentry object, if !good() calls"
2974 </p>
2975
2976 <p>
2977 In 27.6.1.3, [lib.istream.unformatted], paragraph 30.  Change the
2978 first sentence of the Effects clause from "If !good() calls" to
2979 "Behaves as an unformatted input function (as described in 27.6.1.3,
2980 paragraph 1).  After constructing a sentry object, if !good() calls"
2981 </p>
2982
2983 <p>
2984 In 27.6.1.3, [lib.istream.unformatted], paragraph 32.  Change the
2985 first sentence of the Effects clause from "If !good() calls..." to
2986 "Behaves as an unformatted input function (as described in 27.6.1.3,
2987 paragraph 1).  After constructing a sentry object, if !good()
2988 calls..."  Add a new sentence to the end of the Effects clause:
2989 "[Note: this function extracts no characters, so the value returned
2990 by the next call to gcount() is 0.]"
2991 </p>
2992
2993 <p>
2994 In 27.6.1.3, [lib.istream.unformatted], paragraph 34.  Change the
2995 first sentence of the Effects clause from "If !good() calls" to
2996 "Behaves as an unformatted input function (as described in 27.6.1.3,
2997 paragraph 1).  After constructing a sentry object, if !good() calls".
2998 Add a new sentence to the end of the Effects clause: "[Note: this
2999 function extracts no characters, so the value returned by the next
3000 call to gcount() is 0.]"
3001 </p>
3002
3003 <p>
3004 In 27.6.1.3, [lib.istream.unformatted], paragraph 36.  Change the
3005 first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
3006 as an unformatted input function (as described in 27.6.1.3, paragraph
3007 1), except that it does not count the number of characters extracted
3008 and does not affect the value returned by subsequent calls to
3009 gcount().  After constructing a sentry object, if rdbuf() is"
3010 </p>
3011
3012 <p>
3013 In 27.6.1.3, [lib.istream.unformatted], before paragraph 37.  Add an
3014 Effects clause: "Effects: Behaves as an unformatted input function (as
3015 described in 27.6.1.3, paragraph 1), except that it does not count the
3016 number of characters extracted and does not affect the value returned
3017 by subsequent calls to gcount()."  Change the first sentence of
3018 paragraph 37 from "if fail()" to "after constructing a sentry object,
3019 if fail()".
3020 </p>
3021
3022 <p>
3023 In 27.6.1.3, [lib.istream.unformatted], paragraph 38.  Change the
3024 first sentence of the Effects clause from "If fail()" to "Behaves
3025 as an unformatted input function (as described in 27.6.1.3, paragraph
3026 1), except that it does not count the number of characters extracted
3027 and does not affect the value returned by subsequent calls to
3028 gcount().  After constructing a sentry object, if fail()
3029 </p>
3030
3031 <p>
3032 In 27.6.1.3, [lib.istream.unformatted], paragraph 40.  Change the
3033 first sentence of the Effects clause from "If fail()" to "Behaves
3034 as an unformatted input function (as described in 27.6.1.3, paragraph
3035 1), except that it does not count the number of characters extracted
3036 and does not affect the value returned by subsequent calls to
3037 gcount().  After constructing a sentry object, if fail()
3038 </p>
3039
3040 <p>
3041 In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1.  Change
3042 the beginning of the third sentence from "The formatting conversion"
3043 to "These extractors behave as formatted output functions (as
3044 described in 27.6.2.5.1).  After the sentry object is constructed, the
3045 conversion occurs".
3046 </p>
3047
3048 <p>
3049 In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1.  Add an
3050 effects clause: "Effects: None. Does not behave as a formatted output
3051 function (as described in 27.6.2.5.1).".
3052 </p>
3053
3054 <p>
3055 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2.  Change the
3056 effects clause to "Effects: calls pf(*this).  This extractor does not
3057 behave as a formatted output function (as described in 27.6.2.5.1).".
3058 </p>
3059
3060 <p>
3061 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4.  Change the
3062 effects clause to "Effects: calls pf(*this).  This extractor does not
3063 behave as a formatted output function (as described in 27.6.2.5.1).".
3064 </p>
3065
3066 <p>
3067 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6.  Change the first
3068 sentence from "If sb" to "Behaves as a formatted output function (as
3069 described in 27.6.2.5.1).  After the sentry object is constructed, if
3070 sb".
3071 </p>
3072
3073 <p>
3074 In 27.6.2.6 [lib.ostream.unformatted], paragraph 2.  Change the first
3075 sentence from "Inserts the character" to "Behaves as an unformatted
3076 output function (as described in 27.6.2.6, paragraph 1).  After
3077 constructing a sentry object, inserts the character".
3078 </p>
3079
3080 <p>
3081 In 27.6.2.6 [lib.ostream.unformatted], paragraph 5.  Change the first
3082 sentence from "Obtains characters" to "Behaves as an unformatted
3083 output function (as described in 27.6.2.6, paragraph 1).  After
3084 constructing a sentry object, obtains characters".
3085 </p>
3086
3087 <p>
3088 In 27.6.2.6 [lib.ostream.unformatted], paragraph 7.  Add a new
3089 sentence at the end of the paragraph: "Does not behave as an
3090 unformatted output function (as described in 27.6.2.6, paragraph 1)."
3091 </p>
3092
3093
3094 <p><b>Rationale:</b></p>
3095 <p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
3096 by Judy Ward and Matt Austern.  This proposed resolution is section
3097 VI of that paper.</p>
3098
3099
3100
3101
3102
3103 <hr>
3104 <h3><a name="61"></a>61. Ambiguity in iostreams exception policy</h3>
3105 <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>
3106  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-06</p>
3107 <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>
3108 <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>
3109 <p><b>Discussion:</b></p>
3110 <p>The introduction to the section on unformatted input (27.6.1.3)
3111 says that every unformatted input function catches all exceptions that
3112 were thrown during input, sets badbit, and then conditionally rethrows
3113 the exception. That seems clear enough. Several of the specific
3114 functions, however, such as get() and read(), are documented in some
3115 circumstances as setting eofbit and/or failbit. (The standard notes,
3116 correctly, that setting eofbit or failbit can sometimes result in an
3117 exception being thrown.) The question: if one of these functions
3118 throws an exception triggered by setting failbit, is this an exception
3119 "thrown during input" and hence covered by 27.6.1.3, or does
3120 27.6.1.3 only refer to a limited class of exceptions? Just to make
3121 this concrete, suppose you have the following snippet. </p>
3122
3123 <pre>
3124   char buffer[N];
3125   istream is;
3126   ...
3127   is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
3128   is.read(buffer, N);</pre>
3129
3130 <p>Now suppose we reach EOF before we've read N characters. What
3131 iostate bits can we expect to be set, and what exception (if any) will
3132 be thrown? </p>
3133
3134
3135 <p><b>Proposed resolution:</b></p>
3136 <p>
3137 In 27.6.1.3, paragraph 1, after the sentence that begins
3138 "If an exception is thrown...", add the following
3139 parenthetical comment: "(Exceptions thrown from
3140 <tt>basic_ios&lt;&gt;::clear()</tt> are not caught or rethrown.)"
3141 </p>
3142
3143
3144 <p><b>Rationale:</b></p>
3145 <p>The LWG looked to two alternative wordings, and choose the proposed
3146 resolution as better standardese.</p>
3147
3148
3149
3150
3151
3152 <hr>
3153 <h3><a name="62"></a>62. <tt>Sync</tt>'s return value</h3>
3154 <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>
3155  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-06</p>
3156 <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>
3157 <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>
3158 <p><b>Discussion:</b></p>
3159 <p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
3160 "calls rdbuf()-&gt;pubsync() and, if that function returns -1
3161 ... returns traits::eof()." </p>
3162
3163 <p>That looks suspicious, because traits::eof() is of type
3164 traits::int_type while the return type of sync() is int. </p>
3165
3166
3167 <p><b>Proposed resolution:</b></p>
3168 <p>In 27.6.1.3 [istream.unformatted], paragraph 36, change "returns
3169 <tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
3170 </p>
3171
3172
3173
3174
3175
3176 <hr>
3177 <h3><a name="63"></a>63. Exception-handling policy for unformatted output</h3>
3178 <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>
3179  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-11</p>
3180 <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>
3181 <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>
3182 <p><b>Discussion:</b></p>
3183 <p>Clause 27 details an exception-handling policy for formatted input,
3184 unformatted input, and formatted output. It says nothing for
3185 unformatted output (27.6.2.6). 27.6.2.6 should either include the same
3186 kind of exception-handling policy as in the other three places, or
3187 else it should have a footnote saying that the omission is
3188 deliberate. </p>
3189
3190
3191 <p><b>Proposed resolution:</b></p>
3192 <p>
3193 In 27.6.2.6, paragraph 1, replace the last sentence ("In any
3194 case, the unformatted output function ends by destroying the sentry
3195 object, then returning the value specified for the formatted output
3196 function.") with the following text:
3197 </p>
3198 <blockquote><p>
3199 If an exception is thrown during output, then <tt>ios::badbit</tt> is
3200 turned on [Footnote: without causing an <tt>ios::failure</tt> to be
3201 thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &amp;
3202 badbit) != 0</tt> then the exception is rethrown.  In any case, the
3203 unformatted output function ends by destroying the sentry object,
3204 then, if no exception was thrown, returning the value specified for
3205 the formatted output function.
3206 </p></blockquote>
3207
3208
3209 <p><b>Rationale:</b></p>
3210 <p>
3211 This exception-handling policy is consistent with that of formatted
3212 input, unformatted input, and formatted output.
3213 </p>
3214
3215
3216
3217
3218
3219 <hr>
3220 <h3><a name="64"></a>64. Exception handling in <tt>basic_istream::operator&gt;&gt;(basic_streambuf*)</tt></h3>
3221 <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>
3222  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-11</p>
3223 <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>
3224 <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>
3225 <p><b>Discussion:</b></p>
3226 <p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
3227 different ways, depending on whether the second sentence is read as an
3228 elaboration of the first. </p>
3229
3230
3231 <p><b>Proposed resolution:</b></p>
3232 <p>Replace 27.6.1.2.3 [istream::extractors], paragraph 13, which begins
3233 "If the function inserts no characters ..." with:</p>
3234
3235 <blockquote>
3236   <p>If the function inserts no characters, it calls
3237   <tt>setstate(failbit)</tt>, which may throw
3238   <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
3239   because it caught an exception thrown while extracting characters
3240   from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
3241   (27.4.4.3), then the caught exception is rethrown. </p>
3242 </blockquote>
3243
3244
3245
3246
3247
3248 <hr>
3249 <h3><a name="66"></a>66. Strstreambuf::setbuf</h3>
3250 <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>
3251  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-18</p>
3252 <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>
3253 <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>
3254 <p><b>Discussion:</b></p>
3255 <p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
3256 "Performs an operation that is defined separately for each class
3257 derived from strstreambuf". This is obviously an incorrect
3258 cut-and-paste from basic_streambuf. There are no classes derived from
3259 strstreambuf. </p>
3260
3261
3262 <p><b>Proposed resolution:</b></p>
3263 <p>D.7.1.3 [depr.strstreambuf.virtuals], paragraph 19, replace the setbuf effects
3264 clause which currently says "Performs an operation that is
3265 defined separately for each class derived from strstreambuf"
3266 with:</p>
3267
3268 <blockquote>
3269   <p><b>Effects</b>: implementation defined, except that
3270   <tt>setbuf(0,0)</tt> has no effect.</p>
3271 </blockquote>
3272
3273
3274
3275
3276
3277 <hr>
3278 <h3><a name="68"></a>68. Extractors for char* should store null at end</h3>
3279 <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>
3280  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1998-07-14</p>
3281 <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>
3282 <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>
3283 <p><b>Discussion:</b></p>
3284 <p>Extractors for char* (27.6.1.2.3) do not store a null character
3285 after the extracted character sequence whereas the unformatted
3286 functions like get() do. Why is this?</p>
3287
3288 <p>Comment from Jerry Schwarz: There is apparently an editing
3289 glitch. You'll notice that the last item of the list of what stops
3290 extraction doesn't make any sense. It was supposed to be the line that
3291 said a null is stored.</p>
3292
3293
3294 <p><b>Proposed resolution:</b></p>
3295 <p>27.6.1.2.3 [istream::extractors], paragraph 7, change the last list
3296 item from:</p>
3297
3298 <blockquote><p>
3299   A null byte (<tt>charT()</tt>) in the next position, which may be
3300   the first position if no characters were extracted.
3301 </p></blockquote>
3302
3303 <p>to become a new paragraph which reads:</p>
3304
3305 <blockquote><p>
3306   Operator&gt;&gt; then stores a null byte (<tt>charT()</tt>) in the
3307   next position, which may be the first position if no characters were
3308   extracted.
3309 </p></blockquote>
3310
3311
3312
3313
3314
3315 <hr>
3316 <h3><a name="69"></a>69. Must elements of a vector be contiguous?</h3>
3317 <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>
3318  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1998-07-29</p>
3319 <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>
3320 <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>
3321 <p><b>Discussion:</b></p>
3322 <p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
3323
3324 <p>(Please note that this is entirely separate from the question of
3325 whether a vector iterator is required to be a pointer; the answer to
3326 that question is clearly "no," as it would rule out
3327 debugging implementations)</p>
3328
3329
3330 <p><b>Proposed resolution:</b></p>
3331 <p>Add the following text to the end of 23.2.5 [vector],
3332 paragraph 1. </p>
3333
3334 <blockquote>
3335   <p>The elements of a vector are stored contiguously, meaning that if
3336   v is a <tt>vector&lt;T, Allocator&gt;</tt> where T is some type
3337   other than <tt>bool</tt>, then it obeys the identity <tt>&amp;v[n]
3338   == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt; v.size()</tt>.</p>
3339 </blockquote>
3340
3341
3342 <p><b>Rationale:</b></p>
3343 <p>The LWG feels that as a practical matter the answer is clearly
3344 "yes".  There was considerable discussion as to the best way
3345 to express the concept of "contiguous", which is not
3346 directly defined in the standard.  Discussion included:</p>
3347
3348 <ul>
3349   <li>An operational definition similar to the above proposed resolution is
3350     already used for valarray (26.5.2.3 [valarray.access]).</li>
3351   <li>There is no need to explicitly consider a user-defined operator&amp;
3352     because elements must be copyconstructible (23.1 [container.requirements] para 3)
3353     and copyconstructible (20.1.1 [utility.arg.requirements]) specifies
3354     requirements for operator&amp;.</li>
3355   <li>There is no issue of one-past-the-end because of language rules.</li>
3356 </ul>
3357
3358
3359
3360
3361
3362 <hr>
3363 <h3><a name="70"></a>70. Uncaught_exception() missing throw() specification</h3>
3364 <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>
3365  <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-08-03</p>
3366 <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>
3367 <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>
3368 <p><b>Discussion:</b></p>
3369 <p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
3370
3371 <p>uncaught_exception() doesn't have a throw specification.</p>
3372
3373 <p>It is intentional ? Does it means that one should be prepared to
3374 handle exceptions thrown from uncaught_exception() ?</p>
3375
3376 <p>uncaught_exception() is called in exception handling contexts where
3377 exception safety is very important.</p>
3378
3379
3380 <p><b>Proposed resolution:</b></p>
3381 <p>In 15.5.3 [except.uncaught], paragraph 1, 18.7 [support.exception],
3382 and 18.7.4 [uncaught], add "throw()" to uncaught_exception().</p>
3383
3384
3385
3386
3387 <hr>
3388 <h3><a name="71"></a>71. Do_get_monthname synopsis missing argument</h3>
3389 <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>
3390  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-13</p>
3391 <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>
3392 <p><b>Discussion:</b></p>
3393 <p>The locale facet member <tt>time_get&lt;&gt;::do_get_monthname</tt>
3394 is described in 22.2.5.1.2 [locale.time.get.virtuals] with five arguments,
3395 consistent with do_get_weekday and with its specified use by member
3396 get_monthname. However, in the synopsis, it is specified instead with
3397 four arguments. The missing argument is the "end" iterator
3398 value.</p>
3399
3400
3401 <p><b>Proposed resolution:</b></p>
3402 <p>In 22.2.5.1 [locale.time.get], add an "end" argument to
3403 the declaration of member do_monthname as follows:</p>
3404
3405 <pre>  virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&amp;,
3406                                      ios_base::iostate&amp; err, tm* t) const;</pre>
3407
3408
3409
3410
3411 <hr>
3412 <h3><a name="74"></a>74. Garbled text for <tt>codecvt::do_max_length</tt></h3>
3413 <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>
3414  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-09-08</p>
3415 <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>
3416 <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>
3417 <p><b>Discussion:</b></p>
3418 <p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
3419 clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
3420 parentheses and a spurious <b>n</b>.</p>
3421
3422
3423 <p><b>Proposed resolution:</b></p>
3424 <p>Replace 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 11 with the
3425 following:</p>
3426
3427 <blockquote><p>
3428   <b>Returns</b>: The maximum value that
3429   <tt>do_length(state, from, from_end, 1)</tt> can return for any
3430   valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
3431   <tt>state</tt>. The specialization <tt>codecvt&lt;char, char,
3432   mbstate_t&gt;::do_max_length()</tt> returns 1.
3433 </p></blockquote>
3434
3435
3436
3437
3438 <hr>
3439 <h3><a name="75"></a>75. Contradiction in <tt>codecvt::length</tt>'s argument types</h3>
3440 <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>
3441  <b>Submitter:</b>  Matt
3442 Austern <b>Date:</b> 1998-09-18</p>
3443 <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>
3444 <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>
3445 <p><b>Discussion:</b></p>
3446 <p>The class synopses for classes <tt>codecvt&lt;&gt;</tt> (22.2.1.5)
3447 and <tt>codecvt_byname&lt;&gt;</tt> (22.2.1.6) say that the first
3448 parameter of the member functions <tt>length</tt> and
3449 <tt>do_length</tt> is of type <tt>const stateT&amp;</tt>. The member
3450 function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
3451 paragraph 9) say that the type is <tt>stateT&amp;</tt>.  Either the
3452 synopsis or the summary must be changed. </p>
3453
3454 <p>If (as I believe) the member function descriptions are correct,
3455 then we must also add text saying how <tt>do_length</tt> changes its
3456 <tt>stateT</tt> argument. </p>
3457
3458
3459 <p><b>Proposed resolution:</b></p>
3460 <p>In 22.2.1.4 [locale.codecvt], and also in 22.2.1.5 [locale.codecvt.byname],
3461 change the <tt>stateT</tt> argument type on both member
3462 <tt>length()</tt> and member <tt>do_length()</tt> from </p>
3463
3464 <blockquote>
3465   <p><tt>const stateT&amp;</tt></p>
3466 </blockquote>
3467
3468 <p>to</p>
3469
3470 <blockquote>
3471   <p><tt>stateT&amp;</tt></p>
3472 </blockquote>
3473
3474 <p>In 22.2.1.4.2 [locale.codecvt.virtuals], add to the definition for member
3475 <tt>do_length</tt> a paragraph:</p>
3476
3477 <blockquote>
3478   <p>Effects: The effect on the <tt>state</tt> argument is ``as if''
3479   it called <tt>do_in(state, from, from_end, from, to, to+max,
3480   to)</tt> for <tt>to</tt> pointing to a buffer of at least
3481   <tt>max</tt> elements.</p>
3482 </blockquote>
3483
3484
3485
3486
3487 <hr>
3488 <h3><a name="76"></a>76. Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3>
3489 <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>
3490  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-09-25</p>
3491 <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>
3492 <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>
3493 <p><b>Discussion:</b></p>
3494 <p>This issue concerns the requirements on classes derived from
3495 <tt>codecvt</tt>, including user-defined classes. What are the
3496 restrictions on the conversion from external characters
3497 (e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
3498 Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
3499 the I/O library make? </p>
3500
3501 <p>The question is whether it's possible to convert from internal
3502 characters to external characters one internal character at a time,
3503 and whether, given a valid sequence of external characters, it's
3504 possible to pick off internal characters one at a time. Or, to put it
3505 differently: given a sequence of external characters and the
3506 corresponding sequence of internal characters, does a position in the
3507 internal sequence correspond to some position in the external
3508 sequence? </p>
3509
3510 <p>To make this concrete, suppose that <tt>[first, last)</tt> is a
3511 sequence of <i>M</i> external characters and that <tt>[ifirst,
3512 ilast)</tt> is the corresponding sequence of <i>N</i> internal
3513 characters, where <i>N &gt; 1</i>. That is, <tt>my_encoding.in()</tt>,
3514 applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
3515 ilast)</tt>. Now the question: does there necessarily exist a
3516 subsequence of external characters, <tt>[first, last_1)</tt>, such
3517 that the corresponding sequence of internal characters is the single
3518 character <tt>*ifirst</tt>?
3519 </p>
3520
3521 <p>(What a "no" answer would mean is that
3522 <tt>my_encoding</tt> translates sequences only as blocks. There's a
3523 sequence of <i>M</i> external characters that maps to a sequence of
3524 <i>N</i> internal characters, but that external sequence has no
3525 subsequence that maps to <i>N-1</i> internal characters.) </p>
3526
3527 <p>Some of the wording in the standard, such as the description of
3528 <tt>codecvt::do_max_length</tt> (22.2.1.4.2 [locale.codecvt.virtuals],
3529 paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.8.1.5 [filebuf.virtuals], paragraph 3) suggests that it must always be
3530 possible to pick off internal characters one at a time from a sequence
3531 of external characters. However, this is never explicitly stated one
3532 way or the other. </p>
3533
3534 <p>This issue seems (and is) quite technical, but it is important if
3535 we expect users to provide their own encoding facets. This is an area
3536 where the standard library calls user-supplied code, so a well-defined
3537 set of requirements for the user-supplied code is crucial. Users must
3538 be aware of the assumptions that the library makes. This issue affects
3539 positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
3540 and several of <tt>codecvt</tt>'s member functions. </p>
3541
3542
3543 <p><b>Proposed resolution:</b></p>
3544 <p>Add the following text as a new paragraph, following 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 2:</p>
3545
3546 <blockquote>
3547 <p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
3548 (27.8 [file.streams]) must have the property that if</p>
3549 <pre>    do_out(state, from, from_end, from_next, to, to_lim, to_next)
3550 </pre>
3551 <p>would return <tt>ok</tt>, where <tt>from != from_end</tt>, then </p>
3552 <pre>    do_out(state, from, from + 1, from_next, to, to_end, to_next)
3553 </pre>
3554 <p>must also return <tt>ok</tt>, and that if</p>
3555 <pre>    do_in(state, from, from_end, from_next, to, to_lim, to_next)
3556 </pre>
3557 <p>would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then</p>
3558 <pre>    do_in(state, from, from_end, from_next, to, to + 1, to_next)
3559 </pre>
3560 <p>must also return <tt>ok</tt>.  [<i>Footnote:</i> Informally, this
3561 means that <tt>basic_filebuf</tt> assumes that the mapping from
3562 internal to external characters is 1 to N: a <tt>codecvt</tt> that is
3563 used by <tt>basic_filebuf</tt> must be able to translate characters
3564 one internal character at a time.  <i>--End Footnote</i>]</p>
3565 </blockquote>
3566
3567 <p><i>[Redmond: Minor change in proposed resolution.  Original
3568 proposed resolution talked about "success", with a parenthetical
3569 comment that success meant returning <tt>ok</tt>.  New wording
3570 removes all talk about "success", and just talks about the
3571 return value.]</i></p>
3572
3573
3574
3575
3576 <p><b>Rationale:</b></p>
3577
3578   <p>The proposed resoluion says that conversions can be performed one
3579   internal character at a time.  This rules out some encodings that
3580   would otherwise be legal.  The alternative answer would mean there
3581   would be some internal positions that do not correspond to any
3582   external file position.</p>
3583   <p>
3584   An example of an encoding that this rules out is one where the
3585   <tt>internT</tt> and <tt>externT</tt> are of the same type, and
3586   where the internal sequence <tt>c1 c2</tt> corresponds to the
3587   external sequence <tt>c2 c1</tt>.
3588   </p>
3589   <p>It was generally agreed that <tt>basic_filebuf</tt> relies
3590   on this property: it was designed under the assumption that
3591   the external-to-internal mapping is N-to-1, and it is not clear
3592   that <tt>basic_filebuf</tt> is implementable without that
3593   restriction.
3594   </p>
3595   <p>
3596   The proposed resolution is expressed as a restriction on
3597   <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
3598   than a blanket restriction on all <tt>codecvt</tt> facets,
3599   because <tt>basic_filebuf</tt> is the only other part of the
3600   library that uses <tt>codecvt</tt>.  If a user wants to define
3601   a <tt>codecvt</tt> facet that implements a more general N-to-M
3602   mapping, there is no reason to prohibit it, so long as the user
3603   does not expect <tt>basic_filebuf</tt> to be able to use it.
3604   </p>
3605
3606
3607
3608
3609
3610 <hr>
3611 <h3><a name="78"></a>78. Typo: event_call_back</h3>
3612 <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>
3613  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3614 <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>
3615 <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>
3616 <p><b>Discussion:</b></p>
3617 <p>typo: event_call_back should be event_callback &nbsp; </p>
3618
3619
3620 <p><b>Proposed resolution:</b></p>
3621 <p>In the 27.4.2 [ios.base] synopsis change
3622 "event_call_back" to "event_callback". </p>
3623
3624
3625
3626
3627 <hr>
3628 <h3><a name="79"></a>79. Inconsistent declaration of polar()</h3>
3629 <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>
3630  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3631 <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>
3632 <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>
3633 <p><b>Discussion:</b></p>
3634 <p>In 26.3.1 [complex.synopsis] polar is declared as follows:</p>
3635 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;); </pre>
3636
3637 <p>In 26.3.7 [complex.value.ops] it is declared as follows:</p>
3638 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
3639
3640 <p>Thus whether the second parameter is optional is not clear. </p>
3641
3642
3643 <p><b>Proposed resolution:</b></p>
3644 <p>In 26.3.1 [complex.synopsis] change:</p>
3645 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;);</pre>
3646
3647 <p>to:</p>
3648 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
3649
3650
3651
3652
3653
3654 <hr>
3655 <h3><a name="80"></a>80. Global Operators of complex declared twice</h3>
3656 <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>
3657  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3658 <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>
3659 <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>
3660 <p><b>Discussion:</b></p>
3661 <p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
3662 class complex. This redundancy should be removed.</p>
3663
3664
3665 <p><b>Proposed resolution:</b></p>
3666 <p>Reduce redundancy according to the general style of the standard. </p>
3667
3668
3669
3670
3671 <hr>
3672 <h3><a name="83"></a>83. String::npos vs. string::max_size()</h3>
3673 <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>
3674  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3675 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
3676 <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>
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>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#89">89</a></p>
3679 <p><b>Discussion:</b></p>
3680 <p>Many string member functions throw if size is getting or exceeding
3681 npos. However, I wonder why they don't throw if size is getting or
3682 exceeding max_size() instead of npos.  May be npos is known at compile
3683 time, while max_size() is known at runtime. However, what happens if
3684 size exceeds max_size() but not npos, then? It seems the standard
3685 lacks some clarifications here.</p>
3686
3687
3688 <p><b>Proposed resolution:</b></p>
3689 <p>After 21.3 [basic.string] paragraph 4 ("The functions
3690 described in this clause...") add a new paragraph:</p>
3691
3692 <blockquote>
3693   <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
3694   <tt> max_size()</tt> then
3695   the operation throws <tt>length_error</tt>.</p>
3696 </blockquote>
3697
3698
3699 <p><b>Rationale:</b></p>
3700 <p>The LWG believes length_error is the correct exception to throw.</p>
3701
3702
3703
3704
3705 <hr>
3706 <h3><a name="86"></a>86. String constructors don't describe exceptions</h3>
3707 <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>
3708  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3709 <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>
3710 <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>
3711 <p><b>Discussion:</b></p>
3712 <p>The constructor from a range:</p>
3713
3714 <pre>template&lt;class InputIterator&gt;
3715          basic_string(InputIterator begin, InputIterator end,
3716                       const Allocator&amp; a = Allocator());</pre>
3717
3718 <p>lacks a throws clause. However, I would expect that it throws
3719 according to the other constructors if the numbers of characters in
3720 the range equals npos (or exceeds max_size(), see above). </p>
3721
3722
3723 <p><b>Proposed resolution:</b></p>
3724 <p>In 21.3.1 [string.require], Strike throws paragraphs for
3725 constructors which say "Throws: length_error if n ==
3726 npos."</p>
3727
3728
3729 <p><b>Rationale:</b></p>
3730 <p>Throws clauses for length_error if n == npos are no longer needed
3731 because they are subsumed by the general wording added by the
3732 resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
3733
3734
3735
3736
3737 <hr>
3738 <h3><a name="90"></a>90. Incorrect description of operator &gt;&gt; for strings</h3>
3739 <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>
3740  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3741 <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>
3742 <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>
3743 <p><b>Discussion:</b></p>
3744 <p>The effect of operator &gt;&gt; for strings contain the following item:</p>
3745
3746 <p>&nbsp;&nbsp;&nbsp; <tt>isspace(c,getloc())</tt> is true for the next available input
3747 character c.</p>
3748
3749 <p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
3750
3751
3752 <p><b>Proposed resolution:</b></p>
3753 <p>In 21.3.8.9 [string.io] paragraph 1 Effects clause replace:</p>
3754
3755 <blockquote>
3756   <p><tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
3757 </blockquote>
3758
3759 <p>with:</p>
3760
3761 <blockquote>
3762   <p><tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
3763 </blockquote>
3764
3765
3766
3767
3768
3769 <hr>
3770 <h3><a name="91"></a>91. Description of operator&gt;&gt; and getline() for string&lt;&gt; might cause endless loop</h3>
3771 <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>
3772  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3773 <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>
3774 <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>
3775 <p><b>Discussion:</b></p>
3776 <p>Operator &gt;&gt; and getline() for strings read until eof()
3777 in the input stream is true. However, this might never happen, if the
3778 stream can't read anymore without reaching EOF. So shouldn't it be
3779 changed into that it reads until !good() ? </p>
3780
3781
3782 <p><b>Proposed resolution:</b></p>
3783 <p>In 21.3.8.9 [string.io], paragraph 1, replace:</p>
3784 <blockquote><p>
3785 Effects: Begins by constructing a sentry object k as if k were
3786 constructed by typename basic_istream&lt;charT,traits&gt;::sentry k( is). If
3787 bool( k) is true, it calls str.erase() and then extracts characters
3788 from is and appends them to str as if by calling str.append(1, c). If
3789 is.width() is greater than zero, the maximum number n of characters
3790 appended is is.width(); otherwise n is str.max_size(). Characters are
3791 extracted and appended until any of the following occurs:
3792 </p></blockquote>
3793 <p>with:</p>
3794 <blockquote><p>
3795 Effects: Behaves as a formatted input function (27.6.1.2.1
3796 [istream.formatted.reqmts]). After constructing a sentry object, if the
3797 sentry converts to true, calls str.erase() and then extracts
3798 characters from is and appends them to str as if by calling
3799 str.append(1,c). If is.width() is greater than zero, the maximum
3800 number n of characters appended is is.width(); otherwise n is
3801 str.max_size(). Characters are extracted and appended until any of the
3802 following occurs:
3803 </p></blockquote>
3804
3805 <p>In 21.3.8.9 [string.io], paragraph 6, replace</p>
3806 <blockquote><p>
3807 Effects: Begins by constructing a sentry object k as if by typename
3808 basic_istream&lt;charT,traits&gt;::sentry k( is, true). If bool( k) is true,
3809 it calls str.erase() and then extracts characters from is and appends
3810 them to str as if by calling str.append(1, c) until any of the
3811 following occurs:
3812 </p></blockquote>
3813 <p>with:</p>
3814 <blockquote><p>Effects: Behaves as an unformatted input function
3815 (27.6.1.3 [istream.unformatted]), except that it does not affect the
3816 value returned
3817 by subsequent calls to basic_istream&lt;&gt;::gcount(). After
3818 constructing a sentry object, if the sentry converts to true, calls
3819 str.erase() and then extracts characters from is and appends them to
3820 str as if by calling str.append(1,c) until any of the following
3821 occurs:
3822 </p></blockquote>
3823
3824 <p><i>[Redmond: Made changes in proposed resolution.  <tt>operator&gt;&gt;</tt>
3825 should be a formatted input function, not an unformatted input function.
3826 <tt>getline</tt> should not be required to set <tt>gcount</tt>, since
3827 there is no mechanism for <tt>gcount</tt> to be set except by one of
3828 <tt>basic_istream</tt>'s member functions.]</i></p>
3829
3830
3831 <p><i>[Curaçao: Nico agrees with proposed resolution.]</i></p>
3832
3833
3834
3835
3836 <p><b>Rationale:</b></p>
3837 <p>The real issue here is whether or not these string input functions
3838 get their characters from a streambuf, rather than by calling an
3839 istream's member functions, a streambuf signals failure either by
3840 returning eof or by throwing an exception; there are no other
3841 possibilities.  The proposed resolution makes it clear that these two
3842 functions do get characters from a streambuf.</p>
3843
3844
3845
3846
3847
3848 <hr>
3849 <h3><a name="92"></a>92. Incomplete Algorithm Requirements</h3>
3850 <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>
3851  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3852 <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>
3853 <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>
3854 <p><b>Discussion:</b></p>
3855 <p>The standard does not state, how often a function object is copied,
3856 called, or the order of calls inside an algorithm. This may lead to
3857 surprising/buggy behavior. Consider the following example: </p>
3858
3859 <pre>class Nth {    // function object that returns true for the nth element
3860   private:
3861     int nth;     // element to return true for
3862     int count;   // element counter
3863   public:
3864     Nth (int n) : nth(n), count(0) {
3865     }
3866     bool operator() (int) {
3867         return ++count == nth;
3868     }
3869 };
3870 ....
3871 // remove third element
3872     list&lt;int&gt;::iterator pos;
3873     pos = remove_if(coll.begin(),coll.end(),  // range
3874                     Nth(3)),                  // remove criterion
3875     coll.erase(pos,coll.end()); </pre>
3876
3877 <p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
3878 happens because the usual implementation of the algorithm copies the
3879 function object internally: </p>
3880
3881 <pre>template &lt;class ForwIter, class Predicate&gt;
3882 ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op)
3883 {
3884     beg = find_if(beg, end, op);
3885     if (beg == end) {
3886         return beg;
3887     }
3888     else {
3889         ForwIter next = beg;
3890         return remove_copy_if(++next, end, beg, op);
3891     }
3892 } </pre>
3893
3894 <p>The algorithm uses find_if() to find the first element that should
3895 be removed. However, it then uses a copy of the passed function object
3896 to process the resulting elements (if any). Here, Nth is used again
3897 and removes also the sixth element. This behavior compromises the
3898 advantage of function objects being able to have a state. Without any
3899 cost it could be avoided (just implement it directly instead of
3900 calling find_if()). </p>
3901
3902
3903 <p><b>Proposed resolution:</b></p>
3904
3905 <p>Add a new paragraph following 25 [algorithms] paragraph 8:</p>
3906 <blockquote><p>
3907 [Note: Unless otherwise specified, algorithms that take function
3908 objects as arguments are permitted to copy those function objects
3909 freely.  Programmers for whom object identity is important should
3910 consider using a wrapper class that points to a noncopied
3911 implementation object, or some equivalent solution.]
3912 </p></blockquote>
3913
3914 <p><i>[Dublin: Pete Becker felt that this may not be a defect,
3915 but rather something that programmers need to be educated about.
3916 There was discussion of adding wording to the effect that the number
3917 and order of calls to function objects, including predicates, not
3918 affect the behavior of the function object.]</i></p>
3919
3920
3921 <p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
3922 have a clear statement of "predicate" in the
3923 standard. People including me seemed to think "a function
3924 returning a Boolean value and being able to be called by an STL
3925 algorithm or be used as sorting criterion or ... is a
3926 predicate". But a predicate has more requirements: It should
3927 never change its behavior due to a call or being copied. IMHO we have
3928 to state this in the standard. If you like, see section 8.1.4 of my
3929 library book for a detailed discussion.]</i></p>
3930
3931
3932 <p><i>[Kona: Nico will provide wording to the effect that "unless
3933 otherwise specified, the number of copies of and calls to function
3934 objects by algorithms is unspecified".&nbsp; Consider placing in
3935 25 [algorithms] after paragraph 9.]</i></p>
3936
3937
3938 <p><i>[Santa Cruz: The standard doesn't currently guarantee that
3939   functions object won't be copied, and what isn't forbidden is
3940   allowed.  It is believed (especially since implementations that were
3941   written in concert with the standard do make copies of function
3942   objects) that this was intentional.  Thus, no normative change is
3943   needed.  What we should put in is a non-normative note suggesting to
3944   programmers that if they want to guarantee the lack of copying they
3945   should use something like the <tt>ref</tt> wrapper.]</i></p>
3946
3947
3948 <p><i>[Oxford: Matt provided wording.]</i></p>
3949
3950
3951
3952
3953
3954
3955
3956
3957 <hr>
3958 <h3><a name="98"></a>98. Input iterator requirements are badly written</h3>
3959 <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>
3960  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
3961 <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>
3962 <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>
3963 <p><b>Discussion:</b></p>
3964 <p>Table 72 in 24.1.1 [input.iterators] specifies semantics for
3965 <tt>*r++</tt> of:</p>
3966
3967 <p>&nbsp;&nbsp; <tt>{ T tmp = *r; ++r; return tmp; }</tt></p>
3968
3969 <p>There are two problems with this.  First, the return type is
3970 specified to be "T", as opposed to something like "convertible to T".
3971 This is too specific: we want to allow *r++ to return an lvalue.</p>
3972
3973 <p>Second, writing the semantics in terms of code misleadingly
3974 suggests that the effects *r++ should precisely replicate the behavior
3975 of this code, including side effects.  (Does this mean that *r++
3976 should invoke the copy constructor exactly as many times as the sample
3977 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
3978 problem.</p>
3979
3980
3981
3982 <p><b>Proposed resolution:</b></p>
3983 <p>In Table 72 in 24.1.1 [input.iterators], change the return type
3984 for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".</p>
3985
3986
3987 <p><b>Rationale:</b></p>
3988 <p>This issue has two parts: the return type, and the number of times
3989   the copy constructor is invoked.</p>
3990
3991 <p>The LWG believes the the first part is a real issue.  It's
3992   inappropriate for the return type to be specified so much more
3993   precisely for *r++ than it is for *r.  In particular, if r is of
3994   (say) type <tt>int*</tt>, then *r++ isn't <tt>int</tt>,
3995   but <tt>int&amp;</tt>.</p>
3996
3997 <p>The LWG does not believe that the number of times the copy
3998   constructor is invoked is a real issue.  This can vary in any case,
3999   because of language rules on copy constructor elision.  That's too
4000   much to read into these semantics clauses.</p>
4001
4002 <p>Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since
4003    we're told (24.1/3) that forward iterators satisfy all the requirements
4004    of input iterators, we can't impose any requirements in the Input
4005    Iterator requirements table that forward iterators don't satisfy.</p>
4006
4007
4008
4009
4010
4011 <hr>
4012 <h3><a name="103"></a>103. set::iterator is required to be modifiable, but this allows modification of keys</h3>
4013 <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>
4014  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
4015 <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>
4016 <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>
4017 <p><b>Discussion:</b></p>
4018 <p>Set::iterator is described as implementation-defined with a
4019 reference to the container requirement; the container requirement says
4020 that const_iterator is an iterator pointing to const T and iterator an
4021 iterator pointing to T.</p>
4022
4023 <p>23.1.2 paragraph 2 implies that the keys should not be modified to
4024 break the ordering of elements. But that is not clearly
4025 specified. Especially considering that the current standard requires
4026 that iterator for associative containers be different from
4027 const_iterator. Set, for example, has the following: </p>
4028
4029 <p><tt>typedef implementation defined iterator;<br>
4030 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // See _lib.container.requirements_</tt></p>
4031
4032 <p>23.1 [container.requirements] actually requires that iterator type pointing
4033 to T (table 65). Disallowing user modification of keys by changing the
4034 standard to require an iterator for associative container to be the
4035 same as const_iterator would be overkill since that will unnecessarily
4036 significantly restrict the usage of associative container. A class to
4037 be used as elements of set, for example, can no longer be modified
4038 easily without either redesigning the class (using mutable on fields
4039 that have nothing to do with ordering), or using const_cast, which
4040 defeats requiring iterator to be const_iterator. The proposed solution
4041 goes in line with trusting user knows what he is doing. </p>
4042
4043 <p><b>Other Options Evaluated:</b> </p>
4044
4045 <p>Option A.&nbsp;&nbsp; In 23.1.2 [associative.reqmts], paragraph 2, after
4046 first sentence, and before "In addition,...", add one line:
4047 </p>
4048
4049 <blockquote>
4050   <p>Modification of keys shall not change their strict weak ordering. </p>
4051 </blockquote>
4052
4053 <p>Option B.&nbsp;Add three new sentences to 23.1.2 [associative.reqmts]:</p>
4054
4055 <blockquote>
4056   <p>At the end of paragraph 5: "Keys in an associative container
4057   are immutable." At the end of paragraph 6: "For
4058   associative containers where the value type is the same as the key
4059   type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
4060   constant iterators. It is unspecified whether or not
4061   <tt>iterator</tt> and <tt>const_iterator</tt> are the same
4062   type."</p>
4063 </blockquote>
4064
4065 <p>Option C.&nbsp;To 23.1.2 [associative.reqmts], paragraph 3, which
4066 currently reads:</p>
4067
4068 <blockquote>
4069   <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
4070   comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
4071   container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
4072   == false &amp;&amp; comp(k2, k1) == false.</p>
4073 </blockquote>
4074
4075 <p>&nbsp; add the following:</p>
4076
4077 <blockquote>
4078   <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
4079   value whenever it is evaluated. [Note: If k2 is removed from the container and later
4080   reinserted, comp(k1, k2) must still return a consistent value but this value may be
4081   different than it was the first time k1 and k2 were in the same container. This is
4082   intended to allow usage like a string key that contains a filename, where comp compares
4083   file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
4084   reinserted, comp(k1, k2) must again return a consistent value but this value may be
4085   different than it was the previous time k2 was in the container.]</p>
4086 </blockquote>
4087
4088
4089
4090 <p><b>Proposed resolution:</b></p>
4091 <p>Add the following to 23.1.2 [associative.reqmts] at
4092 the indicated location:</p>
4093
4094 <blockquote>
4095   <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
4096   calling comp(k1, k2) shall always return the same
4097   value."</p>
4098   <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
4099   <p>At the end of paragraph 6: "For associative containers where the value type is the
4100   same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
4101   iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
4102   are the same type."</p>
4103 </blockquote>
4104
4105
4106 <p><b>Rationale:</b></p>
4107 <p>Several arguments were advanced for and against allowing set elements to be
4108 mutable as long as the ordering was not effected. The argument which swayed the
4109 LWG was one of safety; if elements were mutable, there would be no compile-time
4110 way to detect of a simple user oversight which caused ordering to be
4111 modified.  There was a report that this had actually happened in practice,
4112 and had been painful to diagnose.  If users need to modify elements,
4113 it is possible to use mutable members or const_cast.</p>
4114
4115 <p>Simply requiring that keys be immutable is not sufficient, because the comparison
4116 object may indirectly (via pointers) operate on values outside of the keys.</p>
4117
4118 <p>
4119 The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
4120 to be different types to allow for potential future work in which some
4121 member functions might be overloaded between the two types.  No such
4122 member functions exist now, and the LWG believes that user functionality
4123 will not be impaired by permitting the two types to be the same.  A
4124 function that operates on both iterator types can be defined for
4125 <tt>const_iterator</tt> alone, and can rely on the automatic
4126 conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
4127 </p>
4128
4129 <p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
4130
4131
4132
4133
4134
4135
4136 <hr>
4137 <h3><a name="106"></a>106. Numeric library private members are implementation defined</h3>
4138 <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>
4139  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
4140 <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>
4141 <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>
4142 <p><b>Discussion:</b></p>
4143 <p>This is the only place in the whole standard where the implementation has to document
4144 something private.</p>
4145
4146
4147 <p><b>Proposed resolution:</b></p>
4148 <p>
4149 Remove the comment which says "// remainder implementation defined" from:
4150 </p>
4151
4152 <ul>
4153   <li>26.5.5 [template.slice.array]</li>
4154   <li>26.5.7 [template.gslice.array]</li>
4155   <li>26.5.8 [template.mask.array]</li>
4156   <li>26.5.9 [template.indirect.array]</li>
4157 </ul>
4158
4159
4160
4161
4162
4163 <hr>
4164 <h3><a name="108"></a>108. Lifetime of exception::what() return unspecified</h3>
4165 <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>
4166  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
4167 <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>
4168 <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>
4169 <p><b>Discussion:</b></p>
4170 <p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
4171 exception::what() is left unspecified. This issue has implications
4172 with exception safety of exception handling: some exceptions should
4173 not throw bad_alloc.</p>
4174
4175
4176 <p><b>Proposed resolution:</b></p>
4177 <p>Add to 18.6.1 [type.info] paragraph 9 (exception::what notes
4178 clause) the sentence:</p>
4179
4180 <blockquote>
4181   <p>The return value remains valid until the exception object from which it is obtained is
4182   destroyed or a non-const member function of the exception object is called.</p>
4183 </blockquote>
4184
4185
4186 <p><b>Rationale:</b></p>
4187 <p>If an exception object has non-const members, they may be used
4188 to set internal state that should affect the contents of the string
4189 returned by <tt>what()</tt>.
4190 </p>
4191
4192
4193
4194
4195
4196 <hr>
4197 <h3><a name="109"></a>109. Missing binders for non-const sequence elements</h3>
4198 <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>
4199  <b>Submitter:</b> Bjarne Stroustrup <b>Date:</b> 1998-10-07</p>
4200 <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>
4201 <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>
4202 <p><b>Discussion:</b></p>
4203
4204 <p>There are no versions of binders that apply to non-const elements
4205 of a sequence. This makes examples like for_each() using bind2nd() on
4206 page 521 of "The C++ Programming Language (3rd)"
4207 non-conforming. Suitable versions of the binders need to be added.</p>
4208
4209 <p>Further discussion from Nico:</p>
4210
4211 <p>What is probably meant here is shown in the following example:</p>
4212
4213 <pre>class Elem {
4214   public:
4215     void print (int i) const { }
4216     void modify (int i) { }
4217 }; </pre>
4218 <pre>int main()
4219 {
4220     vector&lt;Elem&gt; coll(2);
4221     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::print),42));    // OK
4222     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::modify),42));   // ERROR
4223 }</pre>
4224
4225 <p>The error results from the fact that bind2nd() passes its first
4226 argument (the argument of the sequence) as constant reference. See the
4227 following typical implementation:</p>
4228
4229 <blockquote>
4230   <pre>template &lt;class Operation&gt;
4231 class binder2nd
4232   : public unary_function&lt;typename Operation::first_argument_type,
4233                           typename Operation::result_type&gt; {
4234 protected:
4235   Operation op;
4236   typename Operation::second_argument_type value;
4237 public:
4238   binder2nd(const Operation&amp; o,
4239             const typename Operation::second_argument_type&amp; v)
4240       : op(o), value(v) {} </pre>
4241   <pre> typename Operation::result_type
4242   operator()(const typename Operation::first_argument_type&amp; x) const {
4243     return op(x, value);
4244   }
4245 };</pre>
4246 </blockquote>
4247
4248 <p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
4249
4250 <blockquote>
4251   <pre>template &lt;class Operation&gt;
4252 class binder2nd
4253   : public unary_function&lt;typename Operation::first_argument_type,
4254                           typename Operation::result_type&gt; {
4255 protected:
4256   Operation op;
4257   typename Operation::second_argument_type value;
4258 public:
4259   binder2nd(const Operation&amp; o,
4260             const typename Operation::second_argument_type&amp; v)
4261       : op(o), value(v) {} </pre>
4262   <pre> typename Operation::result_type
4263   operator()(const typename Operation::first_argument_type&amp; x) const {
4264     return op(x, value);
4265   }
4266   typename Operation::result_type
4267   operator()(typename Operation::first_argument_type&amp; x) const {
4268     return op(x, value);
4269   }
4270 };</pre>
4271 </blockquote>
4272
4273
4274 <p><b>Proposed resolution:</b></p>
4275
4276 <p><b>Howard believes there is a flaw</b> in this resolution.
4277 See c++std-lib-9127.  We may need to reopen this issue.</p>
4278
4279 <p>In D.8 [depr.lib.binders] in the declaration of binder1st after:</p>
4280 <blockquote>
4281   <p><tt>typename Operation::result_type<br>
4282   &nbsp;operator()(const typename Operation::second_argument_type&amp; x) const;</tt></p>
4283 </blockquote>
4284 <p>insert:</p>
4285 <blockquote>
4286   <p><tt>typename Operation::result_type<br>
4287   &nbsp;operator()(typename Operation::second_argument_type&amp; x) const;</tt></p>
4288 </blockquote>
4289 <p>In D.8 [depr.lib.binders] in the declaration of binder2nd after:</p>
4290 <blockquote>
4291   <p><tt>typename Operation::result_type<br>
4292   &nbsp;operator()(const typename Operation::first_argument_type&amp; x) const;</tt></p>
4293 </blockquote>
4294 <p>insert:</p>
4295 <blockquote>
4296   <p><tt>typename Operation::result_type<br>
4297   &nbsp;operator()(typename Operation::first_argument_type&amp; x) const;</tt></p>
4298 </blockquote>
4299
4300 <p><i>[Kona: The LWG discussed this at some length.It was agreed that
4301 this is a mistake in the design, but there was no consensus on whether
4302 it was a defect in the Standard.  Straw vote: NAD - 5.  Accept
4303 proposed resolution - 3.  Leave open - 6.]</i></p>
4304
4305
4306 <p><i>[Copenhagen: It was generally agreed that this was a defect.
4307 Strap poll: NAD - 0.  Accept proposed resolution - 10.
4308 Leave open - 1.]</i></p>
4309
4310
4311
4312
4313
4314
4315
4316 <hr>
4317 <h3><a name="110"></a>110. istreambuf_iterator::equal not const</h3>
4318 <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>
4319  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-10-15</p>
4320 <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>
4321 <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>
4322 <p><b>Discussion:</b></p>
4323 <p>Member istreambuf_iterator&lt;&gt;::equal is not declared
4324 "const", yet 24.5.3.6 [istreambuf.iterator::op==] says that operator==,
4325 which is const, calls it. This is contradictory. </p>
4326
4327
4328 <p><b>Proposed resolution:</b></p>
4329 <p>In 24.5.3 [istreambuf.iterator] and also in 24.5.3.5 [istreambuf.iterator::equal],
4330 replace:</p>
4331
4332 <blockquote>
4333   <pre>bool equal(istreambuf_iterator&amp; b);</pre>
4334 </blockquote>
4335
4336 <p>with:</p>
4337
4338 <blockquote>
4339   <pre>bool equal(const istreambuf_iterator&amp; b) const;</pre>
4340 </blockquote>
4341
4342
4343
4344
4345
4346 <hr>
4347 <h3><a name="112"></a>112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3>
4348 <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>
4349  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-10-20</p>
4350 <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>
4351 <p><b>Discussion:</b></p>
4352 <p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
4353 constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
4354 reads "<i>s</i> is not null". However, <i>s</i> is a
4355 reference, and references can't be null. </p>
4356
4357
4358 <p><b>Proposed resolution:</b></p>
4359 <p>In 24.5.4.1 [ostreambuf.iter.cons]:</p>
4360
4361 <p>Move the current paragraph 1, which reads "Requires: s is not
4362 null.", from the first constructor to the second constructor.</p>
4363
4364 <p>Insert a new paragraph 1 Requires clause for the first constructor
4365 reading:</p>
4366
4367 <blockquote>
4368   <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
4369 </blockquote>
4370
4371
4372
4373
4374
4375 <hr>
4376 <h3><a name="114"></a>114. Placement forms example in error twice</h3>
4377 <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>
4378  <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-10-28</p>
4379 <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>
4380 <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>
4381 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a></p>
4382 <p><b>Discussion:</b></p>
4383 <p>Section 18.5.1.3 contains the following example: </p>
4384
4385 <pre>[Example: This can be useful for constructing an object at a known address:
4386         char place[sizeof(Something)];
4387         Something* p = new (place) Something();
4388  -end example]</pre>
4389
4390 <p>First code line: "place" need not have any special alignment, and the
4391 following constructor could fail due to misaligned data.</p>
4392
4393 <p>Second code line: Aren't the parens on Something() incorrect?&nbsp; [Dublin: the LWG
4394 believes the () are correct.]</p>
4395
4396 <p>Examples are not normative, but nevertheless should not show code that is invalid or
4397 likely to fail.</p>
4398
4399
4400 <p><b>Proposed resolution:</b></p>
4401 <p>Replace the first line of code in the example in
4402 18.5.1.3 [new.delete.placement] with:
4403 </p>
4404
4405 <blockquote>
4406   <pre>void* place = operator new(sizeof(Something));</pre>
4407 </blockquote>
4408
4409
4410
4411
4412
4413 <hr>
4414 <h3><a name="115"></a>115. Typo in strstream constructors</h3>
4415 <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>
4416  <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-11-02</p>
4417 <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>
4418 <p><b>Discussion:</b></p>
4419 <p>D.7.4.1 strstream constructors paragraph 2 says: </p>
4420
4421 <blockquote>
4422   <p>Effects: Constructs an object of class strstream, initializing the base class with
4423   iostream(&amp; sb) and initializing sb with one of the two constructors: </p>
4424   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
4425   elements. The constructor is strstreambuf(s, n, s). </p>
4426   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
4427   elements that contains an NTBS whose first element is designated by s. The constructor is
4428   strstreambuf(s, n, s+std::strlen(s)).</p>
4429 </blockquote>
4430
4431 <p>Notice the second condition is the same as the first. I think the second condition
4432 should be "If mode&amp;app==app", or "mode&amp;app!=0", meaning that
4433 the append bit is set.</p>
4434
4435
4436 <p><b>Proposed resolution:</b></p>
4437 <p>In D.7.3.1 [depr.ostrstream.cons] paragraph 2 and D.7.4.1 [depr.strstream.cons]
4438 paragraph 2, change the first condition to <tt>(mode&amp;app)==0</tt>
4439 and the second condition to <tt>(mode&amp;app)!=0</tt>.</p>
4440
4441
4442
4443
4444
4445 <hr>
4446 <h3><a name="117"></a>117. <tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</h3>
4447 <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>
4448  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-11-20</p>
4449 <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>
4450 <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>
4451 <p><b>Discussion:</b></p>
4452 <p>The <b>effects</b> clause for numeric inserters says that
4453 insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
4454 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
4455 int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
4456 <tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
4457 delegated to <tt>num_put</tt>, and that insertion is performed as if
4458 through the following code fragment: </p>
4459
4460 <pre>bool failed = use_facet&lt;
4461    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
4462    &gt;(getloc()).put(*this, *this, fill(), val). failed();</pre>
4463
4464 <p>This doesn't work, because <tt>num_put&lt;&gt;</tt>::put is only
4465 overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
4466 long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
4467 void*</tt>. That is, the code fragment in the standard is incorrect
4468 (it is diagnosed as ambiguous at compile time) for the types
4469 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
4470 int</tt>, and <tt>float</tt>. </p>
4471
4472 <p>We must either add new member functions to <tt>num_put</tt>, or
4473 else change the description in <tt>ostream</tt> so that it only calls
4474 functions that are actually there. I prefer the latter. </p>
4475
4476
4477 <p><b>Proposed resolution:</b></p>
4478 <p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
4479
4480 <blockquote>
4481 <p>
4482 The classes num_get&lt;&gt; and num_put&lt;&gt; handle locale-dependent numeric
4483 formatting and parsing.  These inserter functions use the imbued
4484 locale value to perform numeric formatting.  When val is of type bool,
4485 long, unsigned long, double, long double, or const void*, the
4486 formatting conversion occurs as if it performed the following code
4487 fragment:
4488 </p>
4489
4490 <pre>bool failed = use_facet&lt;
4491    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
4492    &gt;(getloc()).put(*this, *this, fill(), val). failed();
4493 </pre>
4494
4495 <p>
4496 When val is of type short the formatting conversion occurs as if it
4497 performed the following code fragment:
4498 </p>
4499
4500 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
4501 bool failed = use_facet&lt;
4502    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
4503    &gt;(getloc()).put(*this, *this, fill(),
4504       baseflags == ios_base::oct || baseflags == ios_base::hex
4505          ? static_cast&lt;long&gt;(static_cast&lt;unsigned short&gt;(val))
4506          : static_cast&lt;long&gt;(val)). failed();
4507 </pre>
4508
4509 <p>
4510 When val is of type int the formatting conversion occurs as if it performed
4511 the following code fragment:
4512 </p>
4513
4514 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
4515 bool failed = use_facet&lt;
4516    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
4517    &gt;(getloc()).put(*this, *this, fill(),
4518       baseflags == ios_base::oct || baseflags == ios_base::hex
4519          ? static_cast&lt;long&gt;(static_cast&lt;unsigned int&gt;(val))
4520          : static_cast&lt;long&gt;(val)). failed();
4521 </pre>
4522
4523 <p>
4524 When val is of type unsigned short or unsigned int the formatting conversion
4525 occurs as if it performed the following code fragment:
4526 </p>
4527
4528 <pre>bool failed = use_facet&lt;
4529    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
4530    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;unsigned long&gt;(val)).
4531 failed();
4532 </pre>
4533
4534 <p>
4535 When val is of type float the formatting conversion occurs as if it
4536 performed the following code fragment:
4537 </p>
4538
4539 <pre>bool failed = use_facet&lt;
4540    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
4541    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;double&gt;(val)).
4542 failed();
4543 </pre>
4544
4545 </blockquote>
4546
4547 <p><i>[post-Toronto: This differs from the previous proposed
4548 resolution; PJP provided the new wording.  The differences are in
4549 signed short and int output.]</i></p>
4550
4551
4552
4553 <p><b>Rationale:</b></p>
4554 <p>The original proposed resolution was to cast int and short to long,
4555 unsigned int and unsigned short to unsigned long, and float to double,
4556 thus ensuring that we don't try to use nonexistent num_put&lt;&gt;
4557 member functions.  The current proposed resolution is more
4558 complicated, but gives more expected results for hex and octal output
4559 of signed short and signed int.  (On a system with 16-bit short, for
4560 example, printing short(-1) in hex format should yield 0xffff.)</p>
4561
4562
4563
4564
4565
4566 <hr>
4567 <h3><a name="118"></a>118. <tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3>
4568 <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>
4569  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-11-20</p>
4570 <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>
4571 <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>
4572 <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>
4573 <p><b>Discussion:</b></p>
4574 <p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
4575 <tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
4576 <tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
4577 formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
4578
4579 <pre>typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
4580 iostate err = 0;
4581 use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, val);
4582 setstate(err);</pre>
4583
4584 <p>According to section 22.2.2.1.1 [facet.num.get.members], however,
4585 <tt>num_get&lt;&gt;::get()</tt> is only overloaded for the types
4586 <tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
4587 int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
4588 <tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
4589 <tt>void*</tt>. Comparing the lists from the two sections, we find
4590 that 27.6.1.2.2 is using a nonexistent function for types
4591 <tt>short</tt> and <tt>int</tt>. </p>
4592
4593
4594 <p><b>Proposed resolution:</b></p>
4595 <p>In 27.6.1.2.2 [istream.formatted.arithmetic] Arithmetic Extractors, remove the
4596 two lines (1st and 3rd) which read:</p>
4597 <blockquote>
4598   <pre>operator&gt;&gt;(short&amp; val);
4599 ...
4600 operator&gt;&gt;(int&amp; val);</pre>
4601 </blockquote>
4602
4603 <p>And add the following at the end of that section (27.6.1.2.2) :</p>
4604
4605 <blockquote>
4606   <pre>operator&gt;&gt;(short&amp; val);</pre>
4607   <p>The conversion occurs as if performed by the following code fragment (using
4608   the same notation as for the preceding code fragment):</p>
4609   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
4610   iostate err = 0;
4611   long lval;
4612   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
4613         if (err == 0
4614                 &amp;&amp; (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval))
4615                 err = ios_base::failbit;
4616   setstate(err);</pre>
4617   <pre>operator&gt;&gt;(int&amp; val);</pre>
4618   <p>The conversion occurs as if performed by the following code fragment (using
4619   the same notation as for the preceding code fragment):</p>
4620   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
4621   iostate err = 0;
4622   long lval;
4623   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
4624         if (err == 0
4625                 &amp;&amp; (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval))
4626                 err = ios_base::failbit;
4627   setstate(err);</pre>
4628 </blockquote>
4629
4630 <p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
4631
4632
4633
4634
4635
4636
4637 <hr>
4638 <h3><a name="119"></a>119. Should virtual functions be allowed to strengthen the exception specification?</h3>
4639 <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>
4640  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4641 <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>
4642 <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>
4643 <p><b>Discussion:</b></p>
4644 <p>Section 17.4.4.8 [res.on.exception.handling] states: </p>
4645
4646 <p>"An implementation may strengthen the exception-specification
4647 for a function by removing listed exceptions." </p>
4648
4649 <p>The problem is that if an implementation is allowed to do this for
4650 virtual functions, then a library user cannot write a class that
4651 portably derives from that class. </p>
4652
4653 <p>For example, this would not compile if ios_base::failure::~failure
4654 had an empty exception specification: </p>
4655
4656 <pre>#include &lt;ios&gt;
4657 #include &lt;string&gt;
4658
4659 class D : public std::ios_base::failure {
4660 public:
4661         D(const std::string&amp;);
4662         ~D(); // error - exception specification must be compatible with
4663               // overridden virtual function ios_base::failure::~failure()
4664 };</pre>
4665
4666
4667 <p><b>Proposed resolution:</b></p>
4668 <p>Change Section 17.4.4.8 [res.on.exception.handling] from:</p>
4669
4670 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
4671 exception-specification for a function"</p>
4672
4673 <p>to:</p>
4674
4675 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
4676 exception-specification for a non-virtual function". </p>
4677
4678
4679
4680
4681
4682 <hr>
4683 <h3><a name="120"></a>120. Can an implementor add specializations?</h3>
4684 <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>
4685  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4686 <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>
4687 <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>
4688 <p><b>Discussion:</b></p>
4689
4690 <p>The original issue asked whether a library implementor could
4691 specialize standard library templates for built-in types.  (This was
4692 an issue because users are permitted to explicitly instantiate
4693 standard library templates.)</p>
4694
4695 <p>Specializations are no longer a problem, because of the resolution
4696 to core issue 259.  Under the proposed resolution, it will be legal
4697 for a translation unit to contain both a specialization and an
4698 explicit instantiation of the same template, provided that the
4699 specialization comes first.  In such a case, the explicit
4700 instantiation will be ignored.  Further discussion of library issue
4701 120 assumes that the core 259 resolution will be adopted.</p>
4702
4703 <p>However, as noted in lib-7047, one piece of this issue still
4704 remains: what happens if a standard library implementor explicitly
4705 instantiates a standard library templates?  It's illegal for a program
4706 to contain two different explicit instantiations of the same template
4707 for the same type in two different translation units (ODR violation),
4708 and the core working group doesn't believe it is practical to relax
4709 that restriction.</p>
4710
4711 <p>The issue, then, is: are users allowed to explicitly instantiate
4712 standard library templates for non-user defined types?  The status quo
4713 answer is 'yes'.  Changing it to 'no' would give library implementors
4714 more freedom.</p>
4715
4716 <p>This is an issue because, for performance reasons, library
4717 implementors often need to explicitly instantiate standard library
4718 templates.  (for example, std::basic_string&lt;char&gt;)  Does giving
4719 users freedom to explicitly instantiate standard library templates for
4720 non-user defined types make it impossible or painfully difficult for
4721 library implementors to do this?</p>
4722
4723 <p>John Spicer suggests, in lib-8957, that library implementors have a
4724 mechanism they can use for explicit instantiations that doesn't
4725 prevent users from performing their own explicit instantiations: put
4726 each explicit instantiation in its own object file.  (Different
4727 solutions might be necessary for Unix DSOs or MS-Windows DLLs.)  On
4728 some platforms, library implementors might not need to do anything
4729 special: the "undefined behavior" that results from having two
4730 different explicit instantiations might be harmless.</p>
4731
4732
4733
4734 <p><b>Proposed resolution:</b></p>
4735   <p>Append to 17.4.3.1 [reserved.names] paragraph 1: </p>
4736   <blockquote><p>
4737     A program may explicitly instantiate any templates in the standard
4738     library only if the declaration depends on the name of a user-defined
4739     type of external linkage and the instantiation meets the standard library
4740     requirements for the original template.
4741   </p></blockquote>
4742
4743 <p><i>[Kona: changed the wording from "a user-defined name" to "the name of
4744   a user-defined type"]</i></p>
4745
4746
4747
4748
4749 <p><b>Rationale:</b></p>
4750 <p>The LWG considered another possible resolution:</p>
4751 <blockquote>
4752   <p>In light of the resolution to core issue 259, no normative changes
4753   in the library clauses are necessary.  Add the following non-normative
4754   note to the end of 17.4.3.1 [reserved.names] paragraph 1:</p>
4755   <blockquote><p>
4756     [<i>Note:</i> A program may explicitly instantiate standard library
4757     templates, even when an explicit instantiation does not depend on
4758     a user-defined name. <i>--end note</i>]
4759   </p></blockquote>
4760 </blockquote>
4761
4762 <p>The LWG rejected this because it was believed that it would make
4763   it unnecessarily difficult for library implementors to write
4764   high-quality implementations.  A program may not include an
4765   explicit instantiation of the same template, for the same template
4766   arguments, in two different translation units.  If users are
4767   allowed to provide explicit instantiations of Standard Library
4768   templates for built-in types, then library implementors aren't,
4769   at least not without nonportable tricks.</p>
4770
4771 <p>The most serious problem is a class template that has writeable
4772   static member variables.  Unfortunately, such class templates are
4773   important and, in existing Standard Library implementations, are
4774   often explicitly specialized by library implementors: locale facets,
4775   which have a writeable static member variable <tt>id</tt>.  If a
4776   user's explicit instantiation collided with the implementations
4777   explicit instantiation, iostream initialization could cause locales
4778   to be constructed in an inconsistent state.</p>
4779
4780 <p>One proposed implementation technique was for Standard Library
4781   implementors to provide explicit instantiations in separate object
4782   files, so that they would not be picked up by the linker when the
4783   user also provides an explicit instantiation.  However, this
4784   technique only applies for Standard Library implementations that
4785   are packaged as static archives.  Most Standard Library
4786   implementations nowadays are packaged as dynamic libraries, so this
4787   technique would not apply.</p>
4788
4789 <p>The Committee is now considering standardization of dynamic
4790   linking.  If there are such changes in the future, it may be
4791   appropriate to revisit this issue later.</p>
4792
4793
4794
4795
4796
4797 <hr>
4798 <h3><a name="122"></a>122. streambuf/wstreambuf description should not say they are specializations</h3>
4799 <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>
4800  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4801 <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>
4802 <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>
4803 <p><b>Discussion:</b></p>
4804 <p>Section 27.5.2 describes the streambuf classes this way: </p>
4805
4806 <blockquote>
4807
4808 <p>The class streambuf is a specialization of the template class basic_streambuf
4809 specialized for the type char. </p>
4810
4811 <p>The class wstreambuf is a specialization of the template class basic_streambuf
4812 specialized for the type wchar_t. </p>
4813
4814 </blockquote>
4815
4816 <p>This implies that these classes must be template specializations, not typedefs. </p>
4817
4818 <p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
4819
4820
4821 <p><b>Proposed resolution:</b></p>
4822 <p>Remove 27.5.2 [streambuf] paragraphs 2 and 3 (the above two
4823 sentences). </p>
4824
4825
4826 <p><b>Rationale:</b></p>
4827 <p>The <tt>streambuf</tt>  synopsis already has a declaration for the
4828 typedefs and that is sufficient. </p>
4829
4830
4831
4832
4833
4834 <hr>
4835 <h3><a name="123"></a>123. Should valarray helper arrays fill functions be const?</h3>
4836 <p><b>Section:</b> 26.5.5.3 [slice.arr.fill], 26.5.7.3 [gslice.array.fill], 26.5.8.3 [mask.array.fill], 26.5.9.3 [indirect.array.fill] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
4837  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4838 <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>
4839 <p><b>Discussion:</b></p>
4840 <p>One of the operator= in the valarray helper arrays is const and one
4841 is not. For example, look at slice_array. This operator= in Section
4842 26.5.5.1 [slice.arr.assign] is const: </p>
4843
4844 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const valarray&lt;T&gt;&amp;) const;</tt> </p>
4845
4846 <p>but this one in Section 26.5.5.3 [slice.arr.fill] is not: </p>
4847
4848 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const T&amp;); </tt></p>
4849
4850 <p>The description of the semantics for these two functions is similar. </p>
4851
4852
4853 <p><b>Proposed resolution:</b></p>
4854
4855 <p>26.5.5 [template.slice.array] Template class slice_array</p>
4856 <blockquote>
4857
4858    <p>In the class template definition for slice_array, replace the member
4859    function declaration</p>
4860     <pre>      void operator=(const T&amp;);
4861     </pre>
4862    <p>with</p>
4863     <pre>      void operator=(const T&amp;) const;
4864     </pre>
4865 </blockquote>
4866
4867 <p>26.5.5.3 [slice.arr.fill] slice_array fill function</p>
4868 <blockquote>
4869
4870    <p>Change the function declaration</p>
4871     <pre>      void operator=(const T&amp;);
4872     </pre>
4873    <p>to</p>
4874     <pre>      void operator=(const T&amp;) const;
4875     </pre>
4876 </blockquote>
4877
4878 <p>26.5.7 [template.gslice.array] Template class gslice_array</p>
4879 <blockquote>
4880
4881    <p>In the class template definition for gslice_array, replace the member
4882    function declaration</p>
4883     <pre>      void operator=(const T&amp;);
4884     </pre>
4885    <p>with</p>
4886     <pre>      void operator=(const T&amp;) const;
4887     </pre>
4888 </blockquote>
4889
4890 <p>26.5.7.3 [gslice.array.fill] gslice_array fill function</p>
4891 <blockquote>
4892
4893    <p>Change the function declaration</p>
4894     <pre>      void operator=(const T&amp;);
4895     </pre>
4896    <p>to</p>
4897     <pre>      void operator=(const T&amp;) const;
4898     </pre>
4899 </blockquote>
4900
4901 <p>26.5.8 [template.mask.array] Template class mask_array</p>
4902 <blockquote>
4903
4904    <p>In the class template definition for mask_array, replace the member
4905    function declaration</p>
4906     <pre>      void operator=(const T&amp;);
4907     </pre>
4908    <p>with</p>
4909     <pre>      void operator=(const T&amp;) const;
4910     </pre>
4911 </blockquote>
4912
4913 <p>26.5.8.3 [mask.array.fill] mask_array fill function</p>
4914 <blockquote>
4915
4916    <p>Change the function declaration</p>
4917     <pre>      void operator=(const T&amp;);
4918     </pre>
4919    <p>to</p>
4920     <pre>      void operator=(const T&amp;) const;
4921     </pre>
4922 </blockquote>
4923
4924 <p>26.5.9 [template.indirect.array] Template class indirect_array</p>
4925 <blockquote>
4926
4927    <p>In the class template definition for indirect_array, replace the member
4928    function declaration</p>
4929     <pre>      void operator=(const T&amp;);
4930     </pre>
4931    <p>with</p>
4932     <pre>      void operator=(const T&amp;) const;
4933     </pre>
4934 </blockquote>
4935
4936 <p>26.5.9.3 [indirect.array.fill] indirect_array fill function</p>
4937 <blockquote>
4938
4939    <p>Change the function declaration</p>
4940     <pre>      void operator=(const T&amp;);
4941     </pre>
4942    <p>to</p>
4943     <pre>      void operator=(const T&amp;) const;
4944     </pre>
4945 </blockquote>
4946
4947
4948 <p><i>[Redmond: Robert provided wording.]</i></p>
4949
4950
4951
4952
4953 <p><b>Rationale:</b></p>
4954 <p>There's no good reason for one version of operator= being const and
4955 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
4956 matters: these functions are now callable in more circumstances.  In
4957 many existing implementations, both versions are already const.</p>
4958
4959
4960
4961
4962
4963 <hr>
4964 <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>
4965 <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>
4966  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4967 <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>
4968 <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>
4969 <p><b>Discussion:</b></p>
4970 <p>In Section 22.2.1.2 [locale.ctype.byname]
4971 ctype_byname&lt;charT&gt;::do_scan_is() and do_scan_not() are declared
4972 to return a const char* not a const charT*. </p>
4973
4974
4975 <p><b>Proposed resolution:</b></p>
4976 <p>Change Section 22.2.1.2 [locale.ctype.byname] <tt>do_scan_is()</tt> and
4977 <tt>do_scan_not()</tt> to return a <tt> const
4978 charT*</tt>. </p>
4979
4980
4981
4982
4983
4984 <hr>
4985 <h3><a name="125"></a>125. valarray&lt;T&gt;::operator!() return type is inconsistent</h3>
4986 <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>
4987  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4988 <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>
4989 <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>
4990 <p><b>Discussion:</b></p>
4991 <p>In Section 26.5.2 [template.valarray] valarray&lt;T&gt;::operator!()
4992 is
4993 declared to return a valarray&lt;T&gt;, but in Section 26.5.2.5
4994 [valarray.unary] it is declared to return a valarray&lt;bool&gt;. The
4995 latter appears to be correct. </p>
4996
4997
4998 <p><b>Proposed resolution:</b></p>
4999 <p>Change in Section 26.5.2 [template.valarray] the declaration of
5000 <tt>operator!()</tt> so that the return type is
5001 <tt>valarray&lt;bool&gt;</tt>. </p>
5002
5003
5004
5005
5006 <hr>
5007 <h3><a name="126"></a>126. typos in Effects clause of ctype::do_narrow()</h3>
5008 <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>
5009  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
5010 <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>
5011 <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>
5012 <p><b>Discussion:</b></p><p>Typos in 22.2.1.1.2 need to be fixed.</p>
5013
5014 <p><b>Proposed resolution:</b></p>
5015 <p>In Section 22.2.1.1.2 [locale.ctype.virtuals] change: </p>
5016
5017 <pre>   do_widen(do_narrow(c),0) == c</pre>
5018
5019 <p>to:</p>
5020
5021 <pre>   do_widen(do_narrow(c,0)) == c</pre>
5022
5023 <p>and change:</p>
5024
5025 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
5026
5027 <p>to:</p>
5028
5029 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
5030
5031
5032
5033
5034
5035 <hr>
5036 <h3><a name="127"></a>127. auto_ptr&lt;&gt; conversion issues</h3>
5037 <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>
5038  <b>Submitter:</b> Greg Colvin <b>Date:</b> 1999-02-17</p>
5039 <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>
5040 <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>
5041 <p><b>Discussion:</b></p>
5042 <p>There are two problems with the current <tt>auto_ptr</tt> wording
5043 in the standard: </p>
5044
5045 <p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
5046 because <tt>auto_ptr&lt;Derived&gt;::auto_ptr_ref</tt> is unrelated to
5047 <tt>auto_ptr&lt;Base&gt;::auto_ptr_ref</tt>.  <i>Also submitted by
5048 Nathan Myers, with the same proposed resolution.</i></p>
5049
5050 <p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
5051 <tt>auto_ptr_ref</tt> argument. </p>
5052
5053 <p>I have discussed these problems with my proposal coauthor, Bill
5054 Gibbons, and with some compiler and library implementors, and we
5055 believe that these problems are not desired or desirable implications
5056 of the standard. </p>
5057
5058 <p>25 Aug 1999: The proposed resolution now reflects changes suggested
5059 by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
5060 "assignment operator" to "public assignment
5061 operator", 2) changed effects to specify use of release(), 3)
5062 made the conversion to auto_ptr_ref const. </p>
5063
5064 <p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
5065 states that the conversion from auto_ptr to auto_ptr_ref should
5066 be const.  This is not acceptable, because it would allow
5067 initialization and assignment from _any_ const auto_ptr!  It also
5068 introduces an implementation difficulty in writing this conversion
5069 function -- namely, somewhere along the line, a const_cast will be
5070 necessary to remove that const so that release() may be called.  This
5071 may result in undefined behavior [7.1.5.1/4]. The conversion
5072 operator does not have to be const, because a non-const implicit
5073 object parameter may be bound to an rvalue [13.3.3.1.4/3]
5074 [13.3.1/5]. </p>
5075
5076   <p>Tokyo: The LWG removed the following from the proposed resolution:</p>
5077
5078   <p>In 20.4.4 [meta.unary], paragraph 2, and 20.4.4.3 [meta.unary.prop],
5079   paragraph 2, make the conversion to auto_ptr_ref const:</p>
5080   <blockquote>
5081     <pre>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() const throw();</pre>
5082   </blockquote>
5083
5084
5085 <p><b>Proposed resolution:</b></p>
5086 <p>In 20.4.4 [meta.unary], paragraph 2, move
5087 the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
5088
5089 <p>In 20.4.4 [meta.unary], paragraph 2, add
5090 a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
5091
5092 <blockquote>
5093   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</pre>
5094 </blockquote>
5095
5096 <p>Also add the assignment operator to 20.4.4.3 [meta.unary.prop]: </p>
5097
5098 <blockquote>
5099   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw()</pre>
5100
5101   <p><b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
5102   p</tt> that <tt>r</tt> holds a reference to.<br>
5103   <b>Returns: </b><tt>*this</tt>.</p>
5104
5105 </blockquote>
5106
5107
5108
5109
5110
5111 <hr>
5112 <h3><a name="129"></a>129. Need error indication from seekp() and seekg()</h3>
5113 <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>
5114  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p>
5115 <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>
5116 <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>
5117 <p><b>Discussion:</b></p>
5118 <p>Currently, the standard does not specify how seekg() and seekp()
5119 indicate failure. They are not required to set failbit, and they can't
5120 return an error indication because they must return *this, i.e. the
5121 stream. Hence, it is undefined what happens if they fail. And they
5122 <i>can</i> fail, for instance, when a file stream is disconnected from the
5123 underlying file (is_open()==false) or when a wide character file
5124 stream must perform a state-dependent code conversion, etc. </p>
5125
5126 <p>The stream functions seekg() and seekp() should set failbit in the
5127 stream state in case of failure.</p>
5128
5129
5130 <p><b>Proposed resolution:</b></p>
5131 <p>Add to the Effects: clause of&nbsp; seekg() in
5132 27.6.1.3 [istream.unformatted] and to the Effects: clause of seekp() in
5133 27.6.2.5 [ostream.seeks]: </p>
5134
5135 <blockquote>
5136   <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
5137   </p>
5138 </blockquote>
5139
5140
5141 <p><b>Rationale:</b></p>
5142 <p>Setting failbit is the usual error reporting mechanism for streams</p>
5143
5144
5145
5146
5147 <hr>
5148 <h3><a name="130"></a>130. Return type of container::erase(iterator) differs for associative containers</h3>
5149 <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>
5150  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-03-02</p>
5151 <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>
5152 <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>
5153 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#451">451</a></p>
5154 <p><b>Discussion:</b></p>
5155 <p>Table 67 (23.1.1) says that container::erase(iterator) returns an
5156 iterator. Table 69 (23.1.2) says that in addition to this requirement,
5157 associative containers also say that container::erase(iterator)
5158 returns void.  That's not an addition; it's a change to the
5159 requirements, which has the effect of making associative containers
5160 fail to meet the requirements for containers.</p>
5161
5162
5163 <p><b>Proposed resolution:</b></p>
5164
5165 <p>
5166 In 23.1.2 [associative.reqmts], in Table 69 Associative container
5167 requirements, change the return type of <tt>a.erase(q)</tt> from
5168 <tt>void</tt> to <tt>iterator</tt>.  Change the
5169 assertion/not/pre/post-condition from "erases the element pointed to
5170 by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>.
5171 Returns an iterator pointing to the element immediately following q
5172 prior to the element being erased. If no such element exists, a.end()
5173 is returned."
5174 </p>
5175
5176 <p>
5177 In 23.1.2 [associative.reqmts], in Table 69 Associative container
5178 requirements, change the return type of <tt>a.erase(q1, q2)</tt>
5179 from <tt>void</tt> to <tt>iterator</tt>.  Change the
5180 assertion/not/pre/post-condition from "erases the elements in the
5181 range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1,
5182 q2)</tt>.  Returns q2."
5183 </p>
5184
5185 <p>
5186 In 23.3.1 [map], in the <tt>map</tt> class synopsis; and
5187 in 23.3.2 [multimap], in the <tt>multimap</tt> class synopsis; and
5188 in 23.3.3 [set], in the <tt>set</tt> class synopsis; and
5189 in 23.3.4 [multiset], in the <tt>multiset</tt> class synopsis:
5190 change the signature of the first <tt>erase</tt> overload to
5191 </p>
5192 <pre>   iterator erase(iterator position);
5193 </pre>
5194 <p>and change the signature of the third <tt>erase</tt> overload to</p>
5195 <pre>  iterator erase(iterator first, iterator last);
5196 </pre>
5197
5198
5199 <p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p>
5200
5201
5202 <p><i>[Post-Kona: the LWG agrees the return type should be
5203 <tt>iterator</tt>, not <tt>void</tt>.  (Alex Stepanov agrees too.)
5204 Matt provided wording.]</i></p>
5205
5206
5207 <p><i>[
5208  Sydney: the proposed wording went in the right direction, but it
5209  wasn't good enough. We want to return an iterator from the range form
5210  of erase as well as the single-iterator form. Also, the wording is
5211  slightly different from the wording we have for sequences; there's no
5212  good reason for having a difference.  Matt provided new wording,
5213 (reflected above) which we will review at the next meeting.
5214 ]</i></p>
5215
5216
5217 <p><i>[
5218 Redmond:  formally voted into WP.
5219 ]</i></p>
5220
5221
5222
5223
5224
5225
5226
5227 <hr>
5228 <h3><a name="132"></a>132. list::resize description uses random access iterators</h3>
5229 <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>
5230  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
5231 <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>
5232 <p><b>Discussion:</b></p>
5233 <p>The description reads:</p>
5234
5235 <p>-1- Effects:</p>
5236
5237 <pre>         if (sz &gt; size())
5238            insert(end(), sz-size(), c);
5239          else if (sz &lt; size())
5240            erase(begin()+sz, end());
5241          else
5242            ;                           //  do nothing</pre>
5243
5244 <p>Obviously list::resize should not be specified in terms of random access iterators.</p>
5245
5246
5247 <p><b>Proposed resolution:</b></p>
5248 <p>Change 23.2.3.2 [list.capacity] paragraph 1 to:</p>
5249
5250 <p>Effects:</p>
5251
5252 <pre>         if (sz &gt; size())
5253            insert(end(), sz-size(), c);
5254          else if (sz &lt; size())
5255          {
5256            iterator i = begin();
5257            advance(i, sz);
5258            erase(i, end());
5259          }</pre>
5260
5261 <p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
5262 with David Abrahams. They had a discussion and believe there is
5263 no issue of exception safety with the proposed resolution.]</i></p>
5264
5265
5266
5267
5268
5269
5270 <hr>
5271 <h3><a name="133"></a>133. map missing get_allocator()</h3>
5272 <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>
5273  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
5274 <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>
5275 <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>
5276 <p><b>Discussion:</b></p><p>The title says it all.</p>
5277
5278 <p><b>Proposed resolution:</b></p>
5279 <p>Insert in 23.3.1 [map], paragraph 2,
5280 after operator= in the map declaration:</p>
5281
5282 <pre>    allocator_type get_allocator() const;</pre>
5283
5284
5285
5286
5287 <hr>
5288 <h3><a name="134"></a>134. vector constructors over specified</h3>
5289 <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>
5290  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
5291 <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>
5292 <p><b>Discussion:</b></p>
5293 <p>The complexity description says: "It does at most 2N calls to the copy constructor
5294 of T and logN reallocations if they are just input iterators ...".</p>
5295
5296 <p>This appears to be overly restrictive, dictating the precise memory/performance
5297 tradeoff for the implementor.</p>
5298
5299
5300 <p><b>Proposed resolution:</b></p>
5301 <p>Change 23.2.5.1 [vector.cons], paragraph 1 to:</p>
5302
5303 <p>-1- Complexity: The constructor template &lt;class
5304 InputIterator&gt; vector(InputIterator first, InputIterator last)
5305 makes only N calls to the copy constructor of T (where N is the
5306 distance between first and last) and no reallocations if iterators
5307 first and last are of forward, bidirectional, or random access
5308 categories. It makes order N calls to the copy constructor of T and
5309 order logN reallocations if they are just input iterators.
5310 </p>
5311
5312
5313 <p><b>Rationale:</b></p>
5314 <p>"at most 2N calls" is correct only if the growth factor
5315 is greater than or equal to 2.
5316 </p>
5317
5318
5319
5320
5321 <hr>
5322 <h3><a name="136"></a>136. seekp, seekg setting wrong streams?</h3>
5323 <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>
5324  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
5325 <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>
5326 <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>
5327 <p><b>Discussion:</b></p>
5328 <p>I may be misunderstanding the intent, but should not seekg set only
5329 the input stream and seekp set only the output stream? The description
5330 seems to say that each should set both input and output streams. If
5331 that's really the intent, I withdraw this proposal.</p>
5332
5333
5334 <p><b>Proposed resolution:</b></p>
5335 <p>In section 27.6.1.3 change:</p>
5336
5337 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
5338 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
5339
5340 <p>To:</p>
5341
5342 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
5343 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::in). </pre>
5344
5345 <p>In section 27.6.1.3 change:</p>
5346
5347 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
5348 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
5349
5350 <p>To:</p>
5351
5352 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
5353 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::in). </pre>
5354
5355 <p>In section 27.6.2.4, paragraph 2 change:</p>
5356
5357 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
5358
5359 <p>To:</p>
5360
5361 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::out). </pre>
5362
5363 <p>In section 27.6.2.4, paragraph 4 change:</p>
5364
5365 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
5366
5367 <p>To:</p>
5368
5369 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::out). </pre>
5370
5371 <p><i>[Dublin: Dietmar Kühl thinks this is probably correct, but would
5372 like the opinion of more iostream experts before taking action.]</i></p>
5373
5374
5375 <p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
5376 incorrect, his implementation already implements the Proposed
5377 Resolution.]</i></p>
5378
5379
5380 <p><i>[Post-Tokyo: Matt Austern comments:<br>
5381 Is it a problem with basic_istream and basic_ostream, or is it a problem
5382 with basic_stringbuf?
5383 We could resolve the issue either by changing basic_istream and
5384 basic_ostream, or by changing basic_stringbuf. I prefer the latter
5385 change (or maybe both changes): I don't see any reason for the standard to
5386 require that std::stringbuf s(std::string("foo"), std::ios_base::in);
5387 s.pubseekoff(0, std::ios_base::beg); must fail.<br>
5388 This requirement is a bit weird. There's no similar requirement
5389 for basic_streambuf&lt;&gt;::seekpos, or for basic_filebuf&lt;&gt;::seekoff or
5390 basic_filebuf&lt;&gt;::seekpos.]</i></p>
5391
5392
5393
5394
5395
5396
5397 <hr>
5398 <h3><a name="137"></a>137. Do use_facet and has_facet look in the global locale?</h3>
5399 <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>
5400  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-03-17</p>
5401 <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>
5402 <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>
5403 <p><b>Discussion:</b></p>
5404 <p>Section 22.1.1 [locale] says:</p>
5405
5406 <p>-4- In the call to use_facet&lt;Facet&gt;(loc), the type argument
5407 chooses a facet, making available all members of the named type. If
5408 Facet is not present in a locale (or, failing that, in the global
5409 locale), it throws the standard exception bad_cast. A C++ program can
5410 check if a locale implements a particular facet with the template
5411 function has_facet&lt;Facet&gt;(). </p>
5412
5413 <p>This contradicts the specification given in section
5414 22.1.2 [locale.global.templates]:
5415 <br><br>
5416 template &lt;class&nbsp; Facet&gt; const&nbsp; Facet&amp; use_facet(const
5417 locale&amp;&nbsp; loc); <br>
5418 <br>
5419 -1- Get a reference to a facet of a locale. <br>
5420 -2- Returns: a reference to the corresponding facet of loc, if present. <br>
5421 -3- Throws: bad_cast if has_facet&lt;Facet&gt;(loc) is false. <br>
5422 -4- Notes: The reference returned remains valid at least as long as any copy of loc exists
5423 </p>
5424
5425
5426 <p><b>Proposed resolution:</b></p>
5427 <p>Remove the phrase "(or, failing that, in the global locale)"
5428 from section 22.1.1. </p>
5429
5430
5431 <p><b>Rationale:</b></p>
5432 <p>Needed for consistency with the way locales are handled elsewhere
5433 in the standard.</p>
5434
5435
5436
5437
5438 <hr>
5439 <h3><a name="139"></a>139. Optional sequence operation table description unclear</h3>
5440 <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>
5441  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-03-30</p>
5442 <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>
5443 <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>
5444 <p><b>Discussion:</b></p>
5445 <p>The sentence introducing the Optional sequence operation table
5446 (23.1.1 paragraph 12) has two problems:</p>
5447
5448 <p>A. It says ``The operations in table 68 are provided only for the containers for which
5449 they take constant time.''<br>
5450 <br>
5451 That could be interpreted in two ways, one of them being ``Even though table 68 shows
5452 particular operations as being provided, implementations are free to omit them if they
5453 cannot implement them in constant time.''<br>
5454 <br>
5455 B. That paragraph says nothing about amortized constant time, and it should.&nbsp;</p>
5456
5457
5458 <p><b>Proposed resolution:</b></p>
5459 <p>Replace the wording in 23.1.1 paragraph 12&nbsp; which begins ``The operations in table 68 are provided only..."
5460 with:</p>
5461
5462 <blockquote>
5463   <p>Table 68 lists sequence operations that are provided for some types of sequential
5464   containers but not others. An implementation shall provide these operations for all
5465   container types shown in the ``container'' column, and shall implement them so as to take
5466   amortized constant time.</p>
5467 </blockquote>
5468
5469
5470
5471
5472 <hr>
5473 <h3><a name="141"></a>141. basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3>
5474 <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>
5475  <b>Submitter:</b> Arch Robison <b>Date:</b> 1999-04-28</p>
5476 <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>
5477 <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>
5478 <p><b>Discussion:</b></p>
5479 <p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
5480 say:<br>
5481 <br>
5482 &#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();</tt></p>
5483
5484 <p>Surely the document meant to say ``<tt>xpos &lt; size()</tt>'' in both places.</p>
5485
5486 <p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
5487 proposed resolution.]</i></p>
5488
5489
5490
5491 <p><b>Proposed resolution:</b></p>
5492 <p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
5493 <br>
5494 &#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();<br>
5495 <br>
5496 </tt>to:<br>
5497 <tt><br>
5498 </tt>&#8212; <tt>xpos &lt;= pos</tt> and <tt>xpos &lt; size();</tt></p>
5499
5500
5501
5502
5503 <hr>
5504 <h3><a name="142"></a>142. lexicographical_compare complexity wrong</h3>
5505 <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>
5506  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-06-20</p>
5507 <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>
5508 <p><b>Discussion:</b></p>
5509 <p>The lexicographical_compare complexity is specified as:<br>
5510 <br>
5511 &nbsp;&nbsp;&nbsp;&nbsp; "At most min((last1 - first1), (last2 - first2))
5512 applications of the corresponding comparison."<br>
5513 <br>
5514 The best I can do is twice that expensive.</p>
5515
5516 <p>Nicolai Josuttis comments in lib-6862: You mean, to check for
5517 equality you have to check both &lt; and &gt;? Yes, IMO you are
5518 right! (and Matt states this complexity in his book)</p>
5519
5520
5521
5522 <p><b>Proposed resolution:</b></p>
5523 <p>Change 25.3.8 [alg.lex.comparison] complexity to:</p>
5524     <blockquote><p>
5525     At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
5526     applications of the corresponding comparison.
5527     </p></blockquote>
5528
5529 <p>Change the example at the end of paragraph 3 to read:</p>
5530     <blockquote><p>
5531     [Example:<br>
5532     <br>
5533     &nbsp;&nbsp;&nbsp; for ( ; first1 != last1 &amp;&amp; first2 != last2 ;
5534     ++first1, ++first2) {<br>
5535     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first1 &lt; *first2) return true;<br>
5536     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first2 &lt; *first1) return false;<br>
5537     &nbsp;&nbsp;&nbsp; }<br>
5538     &nbsp;&nbsp;&nbsp; return first1 == last1 &amp;&amp; first2 != last2;<br>
5539     &nbsp;&nbsp;&nbsp;<br>
5540     --end example]
5541     </p></blockquote>
5542
5543
5544
5545
5546 <hr>
5547 <h3><a name="144"></a>144. Deque constructor complexity wrong </h3>
5548 <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>
5549  <b>Submitter:</b> Herb Sutter <b>Date:</b> 1999-05-09</p>
5550 <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>
5551 <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>
5552 <p><b>Discussion:</b></p>
5553 <p>In 23.2.2.1 [deque.cons] paragraph 6, the deque ctor that takes an iterator range appears
5554 to have complexity requirements which are incorrect, and which contradict the
5555 complexity requirements for insert(). I suspect that the text in question,
5556 below, was taken from vector:</p>
5557 <blockquote>
5558   <p>Complexity: If the iterators first and last are forward iterators,
5559   bidirectional iterators, or random access iterators the constructor makes only
5560   N calls to the copy constructor, and performs no reallocations, where N is
5561   last - first.</p>
5562 </blockquote>
5563 <p>The word "reallocations" does not really apply to deque. Further,
5564 all of the following appears to be spurious:</p>
5565 <blockquote>
5566   <p>It makes at most 2N calls to the copy constructor of T and log N
5567   reallocations if they are input iterators.1)</p>
5568   <p>1) The complexity is greater in the case of input iterators because each
5569   element must be added individually: it is impossible to determine the distance
5570   between first abd last before doing the copying.</p>
5571 </blockquote>
5572 <p>This makes perfect sense for vector, but not for deque. Why should deque gain
5573 an efficiency advantage from knowing in advance the number of elements to
5574 insert?</p>
5575
5576
5577 <p><b>Proposed resolution:</b></p>
5578 <p>In 23.2.2.1 [deque.cons] paragraph 6, replace the Complexity description, including the
5579 footnote, with the following text (which also corrects the "abd"
5580 typo):</p>
5581 <blockquote>
5582   <p>Complexity: Makes last - first calls to the copy constructor of T.</p>
5583 </blockquote>
5584
5585
5586
5587
5588 <hr>
5589 <h3><a name="146"></a>146. complex&lt;T&gt; Inserter and Extractor need sentries</h3>
5590 <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>
5591  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-05-12</p>
5592 <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>
5593 <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>
5594 <p><b>Discussion:</b></p>
5595 <p>The extractor for complex numbers is specified as:&nbsp;</p>
5596
5597 <blockquote>
5598
5599 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
5600      basic_istream&lt;charT, traits&gt;&amp;&nbsp;<br>
5601      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;  is, complex&lt;T&gt;&amp;  x);<br>
5602 &nbsp;<br>
5603 Effects: Extracts a complex number x of the form: u, (u), or (u,v),
5604 where u is the real part and v is the imaginary part
5605 (lib.istream.formatted).&nbsp;<br>
5606 Requires: The input values be convertible to T. If bad input is
5607 encountered, calls is.setstate(ios::failbit) (which may throw
5608 ios::failure (lib.iostate.flags).&nbsp;<br>
5609 Returns: is .</p>
5610
5611 </blockquote>
5612 <p>Is it intended that the extractor for complex numbers does not skip
5613 whitespace, unlike all other extractors in the standard library do?
5614 Shouldn't a sentry be used?&nbsp;<br>
5615 <br>
5616 The inserter for complex numbers is specified as:</p>
5617
5618 <blockquote>
5619
5620 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
5621      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
5622      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;  o, const complex&lt;T&gt;&amp;  x);<br>
5623 <br>
5624 Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
5625 <br>
5626      template&lt;class T, class charT, class traits&gt;&nbsp;<br>
5627      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
5628      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; o, const complex&lt;T&gt;&amp; x)&nbsp;<br>
5629      {&nbsp;<br>
5630              basic_ostringstream&lt;charT, traits&gt; s;&nbsp;<br>
5631              s.flags(o.flags());&nbsp;<br>
5632              s.imbue(o.getloc());&nbsp;<br>
5633              s.precision(o.precision());&nbsp;<br>
5634              s &lt;&lt; '(' &lt;&lt; x.real() &lt;&lt; "," &lt;&lt; x.imag() &lt;&lt; ')';&nbsp;<br>
5635              return o &lt;&lt; s.str();&nbsp;<br>
5636      }</p>
5637
5638 </blockquote>
5639
5640 <p>Is it intended that the inserter for complex numbers ignores the
5641 field width and does not do any padding? If, with the suggested
5642 implementation above, the field width were set in the stream then the
5643 opening parentheses would be adjusted, but the rest not, because the
5644 field width is reset to zero after each insertion.</p>
5645
5646 <p>I think that both operations should use sentries, for sake of
5647 consistency with the other inserters and extractors in the
5648 library. Regarding the issue of padding in the inserter, I don't know
5649 what the intent was.&nbsp;</p>
5650
5651
5652 <p><b>Proposed resolution:</b></p>
5653 <p>After 26.3.6 [complex.ops] paragraph 14 (operator&gt;&gt;), add a
5654 Notes clause:</p>
5655
5656 <blockquote>
5657
5658 <p>Notes: This extraction is performed as a series of simpler
5659 extractions. Therefore, the skipping of whitespace is specified to be the
5660 same for each of the simpler extractions.</p>
5661
5662 </blockquote>
5663
5664
5665 <p><b>Rationale:</b></p>
5666 <p>For extractors, the note is added to make it clear that skipping whitespace
5667 follows an "all-or-none" rule.</p>
5668
5669 <p>For inserters, the LWG believes there is no defect; the standard is correct
5670 as written.</p>
5671
5672
5673
5674
5675 <hr>
5676 <h3><a name="147"></a>147. Library Intro refers to global functions that aren't global</h3>
5677 <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>
5678  <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 1999-06-04</p>
5679 <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>
5680 <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>
5681 <p><b>Discussion:</b></p>
5682 <p>The library had many global functions until 17.4.1.1 [lib.contents]
5683 paragraph 2 was added: </p>
5684
5685 <blockquote>
5686
5687 <p>All library entities except macros, operator new and operator
5688 delete are defined within the namespace std or namespaces nested
5689 within namespace std. </p>
5690
5691 </blockquote>
5692
5693 <p>It appears "global function" was never updated in the following: </p>
5694
5695 <blockquote>
5696
5697 <p>17.4.4.3 - Global functions [lib.global.functions]<br>
5698 <br>
5699 -1- It is unspecified whether any global functions in the C++ Standard
5700 Library are defined as inline (dcl.fct.spec).<br>
5701 <br>
5702 -2- A call to a global function signature described in Clauses
5703 lib.language.support through lib.input.output behaves the same as if
5704 the implementation declares no additional global function
5705 signatures.*<br>
5706 <br>
5707     [Footnote: A valid C++ program always calls the expected library
5708     global function. An implementation may also define additional
5709     global functions that would otherwise not be called by a valid C++
5710     program. --- end footnote]<br>
5711 <br>
5712 -3- A global function cannot be declared by the implementation as
5713 taking additional default arguments.&nbsp;<br>
5714 <br>
5715 17.4.4.4 - Member functions [lib.member.functions]<br>
5716 <br>
5717 -2- An implementation can declare additional non-virtual member
5718 function signatures within a class: </p>
5719
5720   <blockquote>
5721
5722 <p>-- by adding arguments with default values to a member function
5723 signature; The same latitude does not extend to the implementation of
5724 virtual or global functions, however. </p>
5725
5726   </blockquote>
5727 </blockquote>
5728
5729
5730 <p><b>Proposed resolution:</b></p>
5731 <p>     Change "global" to "global or non-member" in:</p>
5732 <blockquote>
5733   <p>17.4.4.3 [lib.global.functions] section title,<br>
5734   17.4.4.3 [lib.global.functions] para 1,<br>
5735   17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2
5736            places in the footnote,<br>
5737   17.4.4.3 [lib.global.functions] para 3,<br>
5738   17.4.4.4 [lib.member.functions] para 2</p>
5739 </blockquote>
5740
5741
5742 <p><b>Rationale:</b></p>
5743 <p>
5744 Because operator new and delete are global, the proposed resolution
5745 was changed from "non-member" to "global or non-member.
5746 </p>
5747
5748
5749
5750
5751 <hr>
5752 <h3><a name="148"></a>148. Functions in the example facet BoolNames should be const</h3>
5753 <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>
5754  <b>Submitter:</b> Jeremy Siek <b>Date:</b> 1999-06-03</p>
5755 <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>
5756 <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>
5757 <p><b>Discussion:</b></p>
5758 <p>In 22.2.8 [facets.examples] paragraph 13, the do_truename() and
5759 do_falsename() functions in the example facet BoolNames should be
5760 const. The functions they are overriding in
5761 numpunct_byname&lt;char&gt; are const. </p>
5762
5763
5764 <p><b>Proposed resolution:</b></p>
5765 <p>In 22.2.8 [facets.examples] paragraph 13, insert "const" in
5766 two places:</p>
5767 <blockquote>
5768   <p><tt>string do_truename() const { return "Oui Oui!"; }<br>
5769   string do_falsename() const { return "Mais Non!"; }</tt></p>
5770 </blockquote>
5771
5772
5773
5774
5775 <hr>
5776 <h3><a name="150"></a>150. Find_first_of says integer instead of iterator </h3>
5777 <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>
5778  <b>Submitter:</b> Matt McClure <b>Date:</b> 1999-06-30</p>
5779 <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>
5780 <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>
5781 <p><b>Discussion:</b></p>
5782
5783
5784 <p><b>Proposed resolution:</b></p>
5785 <p>Change 25.1.4 [alg.find.first.of] paragraph 2 from:</p>
5786
5787 <blockquote>
5788 <p>Returns: The first iterator i in the range [first1, last1) such
5789 that for some integer j in the range [first2, last2) ...</p>
5790 </blockquote>
5791
5792 <p>to:</p>
5793
5794 <blockquote>
5795 <p>Returns: The first iterator i in the range [first1, last1) such
5796 that for some iterator j in the range [first2, last2) ...</p>
5797 </blockquote>
5798
5799
5800
5801
5802 <hr>
5803 <h3><a name="151"></a>151. Can't currently clear() empty container</h3>
5804 <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>
5805  <b>Submitter:</b> Ed Brey <b>Date:</b> 1999-06-21</p>
5806 <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>
5807 <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>
5808 <p><b>Discussion:</b></p>
5809 <p>For both sequences and associative containers, a.clear() has the
5810 semantics of erase(a.begin(),a.end()), which is undefined for an empty
5811 container since erase(q1,q2) requires that q1 be dereferenceable
5812 (23.1.1,3 and 23.1.2,7).  When the container is empty, a.begin() is
5813 not dereferenceable.<br>
5814 <br>
5815 The requirement that q1 be unconditionally dereferenceable causes many
5816 operations to be intuitively undefined, of which clearing an empty
5817 container is probably the most dire.<br>
5818 <br>
5819 Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
5820 q2) is required to be a valid range, stating that q1 and q2 must be
5821 iterators or certain kinds of iterators is unnecessary.
5822 </p>
5823
5824
5825 <p><b>Proposed resolution:</b></p>
5826 <p>In 23.1.1, paragraph 3, change:</p>
5827 <blockquote>
5828   <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>
5829 </blockquote>
5830 <p>to:</p>
5831 <blockquote>
5832   <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range
5833   in a</p>
5834 </blockquote>
5835 <p>In 23.1.2, paragraph 7, change:</p>
5836 <blockquote>
5837   <p>p and q2 are valid iterators to a, q and q1 are valid dereferenceable
5838   iterators to a, [q1, q2) is a valid range</p>
5839 </blockquote>
5840 <p>to</p>
5841 <blockquote>
5842   <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
5843   into a</p>
5844 </blockquote>
5845
5846
5847
5848
5849 <hr>
5850 <h3><a name="152"></a>152. Typo in <tt>scan_is()</tt> semantics</h3>
5851 <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>
5852  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
5853 <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>
5854 <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>
5855 <p><b>Discussion:</b></p>
5856 <p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
5857 because there is no function <tt>is()</tt> which only takes a character as
5858 argument. Also, in the effects clause (paragraph 3), the semantic is also kept
5859 vague.</p>
5860
5861
5862 <p><b>Proposed resolution:</b></p>
5863 <p>In 22.2.1.1.2 [locale.ctype.virtuals] paragraphs 4 and 6, change the returns
5864 clause from:</p>
5865 <blockquote>
5866   <p>"... such that <tt>is(*p)</tt>
5867 would..."</p>
5868 </blockquote>
5869 <p>to:&nbsp; "... such that <tt>is(m, *p)</tt>
5870  would...."</p>
5871
5872
5873
5874
5875
5876 <hr>
5877 <h3><a name="153"></a>153. Typo in <tt>narrow()</tt> semantics</h3>
5878 <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>
5879  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
5880 <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>
5881 <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>
5882 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a></p>
5883 <p><b>Discussion:</b></p>
5884 <p>The description of the array version of <tt>narrow()</tt> (in
5885 paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
5886 takes only three arguments because in addition to the range a default
5887 character is needed.</p>
5888
5889 <p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
5890 two signatures followed by a <b>Returns</b> clause that only addresses
5891 one of them.</p>
5892
5893
5894
5895 <p><b>Proposed resolution:</b></p>
5896 <p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members]
5897 paragraph 10 from:</p>
5898 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
5899
5900 <p>to:</p>
5901 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to),
5902 respectively.</p>
5903
5904 <p>Change 22.2.1.3.2 [facet.ctype.char.members] paragraph 10 and 11 from:</p>
5905 <pre>        char        narrow(char c, char /*dfault*/) const;
5906         const char* narrow(const char* low, const char* high,
5907                            char /*dfault*/, char* to) const;</pre>
5908 <pre>        Returns: do_narrow(low, high, to).</pre>
5909 <p>to:</p>
5910 <pre>        char        narrow(char c, char dfault) const;
5911         const char* narrow(const char* low, const char* high,
5912                            char dfault, char* to) const;</pre>
5913 <pre>        Returns: do_narrow(c, dfault) or
5914                  do_narrow(low, high, dfault, to), respectively.</pre>
5915
5916 <p><i>[Kona: 1) the problem occurs in additional places, 2) a user
5917 defined version could be different.]</i></p>
5918
5919
5920 <p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
5921 the LWG. He could find no other places the problem occurred. He
5922 asks for clarification of the Kona "a user defined
5923 version..." comment above.  Perhaps it was a circuitous way of
5924 saying "dfault" needed to be uncommented?]</i></p>
5925
5926
5927 <p><i>[Post-Toronto: the issues list maintainer has merged in the
5928 proposed resolution from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a>, which addresses the
5929 same paragraphs.]</i></p>
5930
5931
5932
5933
5934
5935
5936 <hr>
5937 <h3><a name="154"></a>154. Missing <tt>double</tt> specifier for <tt>do_get()</tt></h3>
5938 <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>
5939  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
5940 <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>
5941 <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>
5942 <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>
5943 <p><b>Discussion:</b></p>
5944 <p>The table in paragraph 7 for the length modifier does not list the length
5945 modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
5946 standard asks the implementation to do undefined things when using <tt>scanf()</tt>
5947 (the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
5948 is actually a problem I found quite often in production code, too).</p>
5949
5950
5951 <p><b>Proposed resolution:</b></p>
5952 <p>In 22.2.2.1.2 [facet.num.get.virtuals], paragraph 7, add a row in the Length
5953 Modifier table to say that for <tt>double</tt> a length modifier
5954 <tt>l</tt> is to be used.</p>
5955
5956
5957 <p><b>Rationale:</b></p>
5958 <p>The standard makes an embarrassing beginner's mistake.</p>
5959
5960
5961
5962
5963 <hr>
5964 <h3><a name="155"></a>155. Typo in naming the class defining the class <tt>Init</tt></h3>
5965 <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>
5966  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
5967 <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>
5968 <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>
5969 <p><b>Discussion:</b></p>
5970 <p>There are conflicting statements about where the class
5971 <tt>Init</tt> is defined. According to 27.3 [iostream.objects] paragraph 2
5972 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>
5973
5974
5975 <p><b>Proposed resolution:</b></p>
5976 <p>Change 27.3 [iostream.objects] paragraph 2 from
5977 "<tt>basic_ios::Init"</tt> to
5978 "<tt>ios_base::Init"</tt>.</p>
5979
5980
5981 <p><b>Rationale:</b></p>
5982 <p>Although not strictly wrong, the standard was misleading enough to warrant
5983 the change.</p>
5984
5985
5986
5987
5988 <hr>
5989 <h3><a name="156"></a>156. Typo in <tt>imbue()</tt> description</h3>
5990 <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>
5991  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
5992 <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>
5993 <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>
5994 <p><b>Discussion:</b></p>
5995 <p>There is a small discrepancy between the declarations of
5996 <tt>imbue()</tt>: in 27.4.2 [ios.base] the argument is passed as
5997 <tt>locale const&amp;</tt> (correct), in 27.4.2.3 [ios.base.locales] it
5998 is passed as <tt>locale const</tt> (wrong).</p>
5999
6000
6001 <p><b>Proposed resolution:</b></p>
6002 <p>In 27.4.2.3 [ios.base.locales] change the <tt>imbue</tt> argument
6003 from "<tt>locale const" to "locale
6004 const&amp;".</tt></p>
6005
6006
6007
6008
6009 <hr>
6010 <h3><a name="158"></a>158. Underspecified semantics for <tt>setbuf()</tt></h3>
6011 <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>
6012  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6013 <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>
6014 <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>
6015 <p><b>Discussion:</b></p>
6016 <p>The default behavior of <tt>setbuf()</tt> is described only for the
6017 situation that <tt>gptr() != 0 &amp;&amp; gptr() != egptr()</tt>:
6018 namely to do nothing.  What has to be done in other situations&nbsp;
6019 is not described although there is actually only one reasonable
6020 approach, namely to do nothing, too.</p>
6021
6022 <p>Since changing the buffer would almost certainly mess up most
6023 buffer management of derived classes unless these classes do it
6024 themselves, the default behavior of <tt>setbuf()</tt> should always be
6025 to do nothing.</p>
6026
6027
6028 <p><b>Proposed resolution:</b></p>
6029 <p>Change 27.5.2.4.2 [streambuf.virt.buffer], paragraph 3, Default behavior,
6030 to: "Default behavior: Does nothing. Returns this."</p>
6031
6032
6033
6034
6035 <hr>
6036 <h3><a name="159"></a>159. Strange use of <tt>underflow()</tt></h3>
6037 <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>
6038  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6039 <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>
6040 <p><b>Discussion:</b></p>
6041 <p>The description of the meaning of the result of
6042 <tt>showmanyc()</tt> seems to be rather strange: It uses calls to
6043 <tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
6044 this function only reads the current character but does not extract
6045 it, <tt>uflow()</tt> would extract the current character. This should
6046 be fixed to use <tt>sbumpc()</tt> instead.</p>
6047
6048
6049 <p><b>Proposed resolution:</b></p>
6050 <p>Change 27.5.2.4.3 [streambuf.virt.get] paragraph 1,
6051 <tt>showmanyc()</tt>returns clause, by replacing the word
6052 "supplied" with the words "extracted from the
6053 stream".</p>
6054
6055
6056
6057
6058 <hr>
6059 <h3><a name="160"></a>160. Typo: Use of non-existing function <tt>exception()</tt></h3>
6060 <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>
6061  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6062 <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>
6063 <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>
6064 <p><b>Discussion:</b></p>
6065 <p>The paragraph 4 refers to the function <tt>exception()</tt> which
6066 is not defined. Probably, the referred function is
6067 <tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>
6068
6069
6070 <p><b>Proposed resolution:</b></p>
6071 <p>In 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted], paragraph 1,
6072 27.6.2.1 [ostream], paragraph 3, and 27.6.2.6.1 [ostream.formatted.reqmts],
6073 paragraph 1, change "<tt>exception()" to
6074 "exceptions()"</tt>.</p>
6075
6076 <p><i>[Note to Editor: "exceptions" with an "s"
6077 is the correct spelling.]</i></p>
6078
6079
6080
6081
6082
6083
6084 <hr>
6085 <h3><a name="161"></a>161. Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt></h3>
6086 <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>
6087  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6088 <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>
6089 <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>
6090 <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>
6091 <p><b>Discussion:</b></p>
6092 <p>The note in the second paragraph pretends that the first argument
6093 is an object of type <tt>istream_iterator</tt>. This is wrong: It is
6094 an object of type <tt>istreambuf_iterator</tt>.</p>
6095
6096
6097 <p><b>Proposed resolution:</b></p>
6098 <p>Change 27.6.1.2.2 [istream.formatted.arithmetic] from:</p>
6099 <blockquote>
6100   <p>The first argument provides an object of the istream_iterator class...</p>
6101 </blockquote>
6102 <p>to</p>
6103 <blockquote>
6104   <p>The first argument provides an object of the istreambuf_iterator class...</p>
6105 </blockquote>
6106
6107
6108
6109
6110
6111 <hr>
6112 <h3><a name="164"></a>164. do_put() has apparently unused fill argument</h3>
6113 <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>
6114  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-07-23</p>
6115 <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>
6116 <p><b>Discussion:</b></p>
6117 <p>In 22.2.5.3.2 [locale.time.put.virtuals] the do_put() function is specified
6118 as taking a fill character as an argument, but the description of the
6119 function does not say whether the character is used at all and, if so,
6120 in which way. The same holds for any format control parameters that
6121 are accessible through the ios_base&amp; argument, such as the
6122 adjustment or the field width. Is strftime() supposed to use the fill
6123 character in any way? In any case, the specification of
6124 time_put.do_put() looks inconsistent to me.<br> <br> Is the
6125 signature of do_put() wrong, or is the effects clause incomplete?</p>
6126
6127
6128 <p><b>Proposed resolution:</b></p>
6129 <p>Add the following note after 22.2.5.3.2 [locale.time.put.virtuals]
6130 paragraph 2:</p>
6131 <blockquote>
6132   <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
6133   for this argument. --end Note]</p>
6134 </blockquote>
6135
6136
6137 <p><b>Rationale:</b></p>
6138 <p>The LWG felt that while the normative text was correct,
6139 users need some guidance on what to pass for the <tt>fill</tt>
6140 argument since the standard doesn't say how it's used.</p>
6141
6142
6143
6144
6145 <hr>
6146 <h3><a name="165"></a>165. <tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3>
6147 <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>
6148  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6149 <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>
6150 <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>
6151 <p><b>Discussion:</b></p>
6152 <p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
6153 functions falling into one of the groups "formatted output functions"
6154 and "unformatted output functions" calls any stream buffer function
6155 which might call a virtual function other than <tt>overflow()</tt>. Basically
6156 this is fine but this implies that <tt>sputn()</tt> (this function would call
6157 the virtual function <tt>xsputn()</tt>) is never called by any of the standard
6158 output functions. Is this really intended? At minimum it would be convenient to
6159 call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
6160 is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
6161 with the definition of <tt>flush()</tt> which calls <tt>rdbuf()-&gt;pubsync()</tt>
6162 and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
6163 under "unformatted output functions").</p>
6164 <p>In addition, I guess that the sentence starting with "They may use other
6165 public members of <tt>basic_ostream</tt> ..." probably was intended to
6166 start with "They may use other public members of <tt>basic_streamuf</tt>..."
6167 although the problem with the virtual members exists in both cases.</p>
6168 <p>I see two obvious resolutions:</p>
6169 <ol>
6170   <li>state in a footnote that this means that <tt>xsputn()</tt> will never be
6171     called by any ostream member and that this is intended.</li>
6172   <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
6173     Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
6174 </ol>
6175
6176
6177 <p><b>Proposed resolution:</b></p>
6178 <p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
6179 <blockquote>
6180   <p>They may use other public members of basic_ostream except that they do not
6181   invoke any virtual members of rdbuf() except overflow().</p>
6182 </blockquote>
6183 <p>to:</p>
6184 <blockquote>
6185   <p>They may use other public members of basic_ostream except that they shall
6186   not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
6187   sync().</p>
6188 </blockquote>
6189
6190 <p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
6191 PJP why the standard is written this way.]</i></p>
6192
6193
6194 <p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
6195 LWG. He comments: The rules can be made a little bit more specific if
6196 necessary be explicitly spelling out what virtuals are allowed to be
6197 called from what functions and eg to state specifically that flush()
6198 is allowed to call sync() while other functions are not.]</i></p>
6199
6200
6201
6202
6203
6204
6205 <hr>
6206 <h3><a name="167"></a>167. Improper use of <tt>traits_type::length()</tt></h3>
6207 <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>
6208  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6209 <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>
6210 <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>
6211 <p><b>Discussion:</b></p>
6212 <p>Paragraph 4 states that the length is determined using
6213 <tt>traits::length(s)</tt>.  Unfortunately, this function is not
6214 defined for example if the character type is <tt>wchar_t</tt> and the
6215 type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
6216 the character type is <tt>char</tt> and the type of <tt>s</tt> is
6217 either <tt>signed char const*</tt> or <tt>unsigned char
6218 const*</tt>.</p>
6219
6220
6221 <p><b>Proposed resolution:</b></p>
6222 <p>Change 27.6.2.6.4 [ostream.inserters.character] paragraph 4 from:</p>
6223 <blockquote>
6224   <p>Effects: Behaves like an formatted inserter (as described in
6225   lib.ostream.formatted.reqmts) of out. After a sentry object is
6226   constructed it inserts characters. The number of characters starting
6227   at s to be inserted is traits::length(s). Padding is determined as
6228   described in lib.facet.num.put.virtuals. The traits::length(s)
6229   characters starting at s are widened using out.widen
6230   (lib.basic.ios.members). The widened characters and any required
6231   padding are inserted into out. Calls width(0).</p>
6232 </blockquote>
6233 <p>to:</p>
6234 <blockquote>
6235   <p>Effects: Behaves like a formatted inserter (as described in
6236   lib.ostream.formatted.reqmts) of out. After a sentry object is
6237   constructed it inserts <i>n</i> characters starting at <i>s</i>,
6238   where <i>n</i> is the number that would be computed as if by:</p>
6239   <ul>
6240   <li>traits::length(s) for the overload where the first argument is of
6241     type basic_ostream&lt;charT, traits&gt;&amp; and the second is
6242     of type const charT*, and also for the overload where the first
6243     argument is of type basic_ostream&lt;char, traits&gt;&amp; and
6244     the second is of type const char*.</li>
6245   <li>std::char_traits&lt;char&gt;::length(s)
6246     for the overload where the first argument is of type
6247     basic_ostream&lt;charT, traits&gt;&amp; and the second is of type
6248     const char*.</li>
6249   <li>traits::length(reinterpret_cast&lt;const char*&gt;(s))
6250     for the other two overloads.</li>
6251   </ul>
6252   <p>Padding is determined as described in
6253   lib.facet.num.put.virtuals. The <i>n</i> characters starting at
6254   <i>s</i> are widened using out.widen (lib.basic.ios.members).  The
6255   widened characters and any required padding are inserted into
6256   out. Calls width(0).</p>
6257 </blockquote>
6258
6259 <p><i>[Santa Cruz: Matt supplied new wording]</i></p>
6260
6261
6262 <p><i>[Kona: changed "where <i>n</i> is" to " where <i>n</i> is the
6263   number that would be computed as if by"]</i></p>
6264
6265
6266
6267
6268 <p><b>Rationale:</b></p>
6269 <p>We have five separate cases.  In two of them we can use the
6270 user-supplied traits class without any fuss.  In the other three we
6271 try to use something as close to that user-supplied class as possible.
6272 In two cases we've got a traits class that's appropriate for
6273 char and what we've got is a const signed char* or a const
6274 unsigned char*; that's close enough so we can just use a reinterpret
6275 cast, and continue to use the user-supplied traits class.  Finally,
6276 there's one case where we just have to give up: where we've got a
6277 traits class for some arbitrary charT type, and we somehow have to
6278 deal with a const char*.  There's nothing better to do but fall back
6279 to char_traits&lt;char&gt;</p>
6280
6281
6282
6283
6284
6285 <hr>
6286 <h3><a name="168"></a>168. Typo: formatted vs. unformatted</h3>
6287 <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>
6288  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6289 <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>
6290 <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>
6291 <p><b>Discussion:</b></p>
6292 <p>The first paragraph begins with a descriptions what has to be done
6293 in <i>formatted</i> output functions. Probably this is a typo and the
6294 paragraph really want to describe unformatted output functions...</p>
6295
6296
6297 <p><b>Proposed resolution:</b></p>
6298 <p>In 27.6.2.7 [ostream.unformatted] paragraph 1, the first and last
6299 sentences, change the word "formatted" to
6300 "unformatted":</p>
6301 <blockquote>
6302   <p>"Each <b>unformatted </b> output function begins ..."<br>
6303   "... value specified for the <b>unformatted </b>  output
6304   function."</p>
6305 </blockquote>
6306
6307
6308
6309
6310 <hr>
6311 <h3><a name="169"></a>169. Bad efficiency of <tt>overflow()</tt> mandated</h3>
6312 <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>
6313  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6314 <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>
6315 <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>
6316 <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>
6317 <p><b>Discussion:</b></p>
6318 <p>Paragraph 8, Notes, of this section seems to mandate an extremely
6319 inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
6320 especially in view of the restriction that <tt>basic_ostream</tt>
6321 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
6322 is to be created.</p>
6323 <p>Of course, the resolution below requires some handling of
6324 simultaneous input and output since it is no longer possible to update
6325 <tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
6326 solution is to handle this in <tt>underflow()</tt>.</p>
6327
6328
6329 <p><b>Proposed resolution:</b></p>
6330 <p>In 27.7.1.4 [stringbuf.virtuals] paragraph 8, Notes, insert the words
6331 "at least" as in the following:</p>
6332 <blockquote>
6333   <p>To make a write position available, the function reallocates (or initially
6334   allocates) an array object with a sufficient number of elements to hold the
6335   current array object (if any), plus <b>at least</b> one additional write
6336   position.</p>
6337 </blockquote>
6338
6339
6340
6341
6342 <hr>
6343 <h3><a name="170"></a>170. Inconsistent definition of <tt>traits_type</tt></h3>
6344 <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>
6345  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6346 <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>
6347 <p><b>Discussion:</b></p>
6348 <p>The classes <tt>basic_stringstream</tt> (27.7.4 [stringstream]),
6349 <tt>basic_istringstream</tt> (27.7.2 [istringstream]), and
6350 <tt>basic_ostringstream</tt> (27.7.3 [ostringstream]) are inconsistent
6351 in their definition of the type <tt>traits_type</tt>: For
6352 <tt>istringstream</tt>, this type is defined, for the other two it is
6353 not. This should be consistent.</p>
6354
6355
6356 <p><b>Proposed resolution:</b></p>
6357 <p><b>Proposed resolution:</b></p> <p>To the declarations of
6358 <tt>basic_ostringstream</tt> (27.7.3 [ostringstream]) and
6359 <tt>basic_stringstream</tt> (27.7.4 [stringstream]) add:</p>
6360 <blockquote>
6361 <pre>typedef traits traits_type;</pre>
6362 </blockquote>
6363
6364
6365
6366
6367 <hr>
6368 <h3><a name="171"></a>171. Strange <tt>seekpos()</tt> semantics due to joint position</h3>
6369 <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>
6370  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6371 <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>
6372 <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>
6373 <p><b>Discussion:</b></p>
6374 <p>Overridden virtual functions, seekpos()</p> <p>In 27.8.1.1 [filebuf] paragraph 3, it is stated that a joint input and
6375 output position is maintained by <tt>basic_filebuf</tt>. Still, the
6376 description of <tt>seekpos()</tt> seems to talk about different file
6377 positions. In particular, it is unclear (at least to me) what is
6378 supposed to happen to the output buffer (if there is one) if only the
6379 input position is changed. The standard seems to mandate that the
6380 output buffer is kept and processed as if there was no positioning of
6381 the output position (by changing the input position). Of course, this
6382 can be exactly what you want if the flag <tt>ios_base::ate</tt> is
6383 set. However, I think, the standard should say something like
6384 this:</p>
6385 <ul>
6386   <li>If <tt>(which &amp; mode) == 0</tt> neither read nor write position is
6387     changed and the call fails. Otherwise, the joint read and write position is
6388     altered to correspond to <tt>sp</tt>.</li>
6389   <li>If there is an output buffer, the output sequences is updated and any
6390     unshift sequence is written before the position is altered.</li>
6391   <li>If there is an input buffer, the input sequence is updated after the
6392     position is altered.</li>
6393 </ul>
6394 <p>Plus the appropriate error handling, that is...</p>
6395
6396
6397 <p><b>Proposed resolution:</b></p>
6398 <p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
6399 paragraph 14 from:</p>
6400 <blockquote>
6401   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
6402   ios_base::out);</p>
6403   <p>Alters the file position, if possible, to correspond to the position stored
6404   in sp (as described below).</p>
6405   <p>- if (which&amp;ios_base::in)!=0, set the file position to sp, then update
6406   the input sequence</p>
6407   <p>- if (which&amp;ios_base::out)!=0, then update the output sequence, write
6408   any unshift sequence, and set the file position to sp.</p>
6409 </blockquote>
6410 <p>to:</p>
6411 <blockquote>
6412   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
6413   ios_base::out);</p>
6414   <p>Alters the file position, if possible, to correspond to the position stored
6415   in sp (as described below). Altering the file position performs as follows:</p>
6416   <p>1. if (om &amp; ios_base::out)!=0, then update the output sequence and
6417   write any unshift sequence;</p>
6418   <p>2. set the file position to sp;</p>
6419   <p>3. if (om &amp; ios_base::in)!=0, then update the input sequence;</p>
6420   <p>where om is the open mode passed to the last call to open(). The operation
6421   fails if is_open() returns false.</p>
6422 </blockquote>
6423
6424 <p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
6425
6426 <p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
6427
6428
6429
6430
6431
6432
6433 <hr>
6434 <h3><a name="172"></a>172. Inconsistent types for <tt>basic_istream::ignore()</tt></h3>
6435 <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>
6436  <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 1999-07-23</p>
6437 <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>
6438 <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>
6439 <p><b>Discussion:</b></p>
6440 <p>In 27.6.1.1 [istream] the function
6441 <tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
6442 argument. However, in 27.6.1.3 [istream.unformatted]
6443 paragraph 23 the first argument is of type <tt>int.</tt></p>
6444
6445 <p>As far as I can see this is not really a contradiction because
6446 everything is consistent if <tt>streamsize</tt> is typedef to be
6447 <tt>int</tt>. However, this is almost certainly not what was
6448 intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
6449 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>.</p>
6450
6451 <p>Darin Adler also
6452 submitted this issue, commenting: Either 27.6.1.1 should be modified
6453 to show a first parameter of type int, or 27.6.1.3 should be modified
6454 to show a first parameter of type streamsize and use
6455 numeric_limits&lt;streamsize&gt;::max.</p>
6456
6457
6458 <p><b>Proposed resolution:</b></p>
6459 <p>In 27.6.1.3 [istream.unformatted] paragraph 23 and 24, change both uses
6460 of <tt>int</tt> in the description of <tt>ignore()</tt> to
6461 <tt>streamsize</tt>.</p>
6462
6463
6464
6465
6466 <hr>
6467 <h3><a name="173"></a>173. Inconsistent types for <tt>basic_filebuf::setbuf()</tt></h3>
6468 <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>
6469  <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 1999-07-23</p>
6470 <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>
6471 <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>
6472 <p><b>Discussion:</b></p>
6473
6474 <p>
6475 In 27.8.1.1 [filebuf] the function <tt>setbuf()</tt> gets an
6476 object of type <tt>streamsize</tt> as second argument. However, in
6477 27.8.1.5 [filebuf.virtuals] paragraph 9 the second argument is of type
6478 <tt>int</tt>.
6479 </p>
6480
6481 <p>
6482 As far as I can see this is not really a contradiction because
6483 everything is consistent if <tt>streamsize</tt> is typedef to be
6484 <tt>int</tt>. However, this is almost certainly not what was
6485 intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
6486 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>.
6487 </p>
6488
6489
6490
6491 <p><b>Proposed resolution:</b></p>
6492 <p>In 27.8.1.5 [filebuf.virtuals] paragraph 9, change all uses of
6493 <tt>int</tt> in the description of <tt>setbuf()</tt> to
6494 <tt>streamsize</tt>.</p>
6495
6496
6497
6498
6499 <hr>
6500 <h3><a name="174"></a>174. Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt></h3>
6501 <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>
6502  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-23</p>
6503 <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>
6504 <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>
6505 <p><b>Discussion:</b></p>
6506 <p>According to paragraph 1 of this section, <tt>streampos</tt> is the
6507 type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
6508 paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt></p>
6509
6510
6511 <p><b>Proposed resolution:</b></p>
6512 <p>Change D.6 [depr.ios.members] paragraph 1 from "<tt>typedef
6513 OFF_T streampos;</tt>" to "<tt>typedef POS_T
6514 streampos;</tt>"</p>
6515
6516
6517
6518
6519 <hr>
6520 <h3><a name="175"></a>175. Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3>
6521 <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>
6522  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-23</p>
6523 <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>
6524 <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>
6525 <p><b>Discussion:</b></p>
6526 <p>According to paragraph 8 of this section, the methods
6527 <tt>basic_streambuf::pubseekpos()</tt>,
6528 <tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
6529 "may" be overloaded by a version of this function taking the
6530 type <tt>ios_base::open_mode</tt> as last argument argument instead of
6531 <tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
6532 in this section to be an alias for one of the integral types). The
6533 clause specifies, that the last argument has a default argument in
6534 three cases.  However, this generates an ambiguity with the overloaded
6535 version because now the arguments are absolutely identical if the last
6536 argument is not specified.</p>
6537
6538
6539 <p><b>Proposed resolution:</b></p>
6540 <p>In D.6 [depr.ios.members] paragraph 8, remove the default arguments for
6541 <tt>basic_streambuf::pubseekpos()</tt>,
6542 <tt>basic_ifstream::open()</tt>, and
6543 <tt>basic_ofstream::open().</tt></p>
6544
6545
6546
6547
6548 <hr>
6549 <h3><a name="176"></a>176. <tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3>
6550 <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>
6551  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-23</p>
6552 <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>
6553 <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>
6554 <p><b>Discussion:</b></p>
6555 <p>The "overload" for the function <tt>exceptions()</tt> in
6556 paragraph 8 gives the impression that there is another function of
6557 this function defined in class <tt>ios_base</tt>. However, this is not
6558 the case. Thus, it is hard to tell how the semantics (paragraph 9) can
6559 be implemented: "Call the corresponding member function specified
6560 in clause 27 [input.output]."</p>
6561
6562
6563 <p><b>Proposed resolution:</b></p>
6564 <p>In D.6 [depr.ios.members] paragraph 8, move the declaration of the
6565 function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
6566
6567
6568
6569
6570 <hr>
6571 <h3><a name="179"></a>179. Comparison of const_iterators to iterators doesn't work</h3>
6572 <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>
6573  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-07-02</p>
6574 <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>
6575 <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>
6576 <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>
6577 <p><b>Discussion:</b></p>
6578 <p>Currently the following will not compile on two well-known standard
6579 library implementations:</p>
6580
6581 <blockquote>
6582   <pre>#include &lt;set&gt;
6583 using namespace std;
6584
6585 void f(const set&lt;int&gt; &amp;s)
6586 {
6587   set&lt;int&gt;::iterator i;
6588   if (i==s.end()); // s.end() returns a const_iterator
6589 }</pre>
6590 </blockquote>
6591
6592 <p>
6593 The reason this doesn't compile is because operator== was implemented
6594 as a member function of the nested classes set:iterator and
6595 set::const_iterator, and there is no conversion from const_iterator to
6596 iterator. Surprisingly, (s.end() == i) does work, though, because of
6597 the conversion from iterator to const_iterator.
6598 </p>
6599
6600 <p>
6601 I don't see a requirement anywhere in the standard that this must
6602 work. Should there be one?  If so, I think the requirement would need
6603 to be added to the tables in section 24.1.1. I'm not sure about the
6604 wording.  If this requirement existed in the standard, I would think
6605 that implementors would have to make the comparison operators
6606 non-member functions.</p>
6607
6608 <p>This issues was also raised on comp.std.c++ by Darin
6609 Adler.&nbsp; The example given was:</p>
6610
6611 <blockquote>
6612   <pre>bool check_equal(std::deque&lt;int&gt;::iterator i,
6613 std::deque&lt;int&gt;::const_iterator ci)
6614 {
6615 return i == ci;
6616 }</pre>
6617 </blockquote>
6618
6619 <p>Comment from John Potter:</p>
6620 <blockquote>
6621     <p>
6622     In case nobody has noticed, accepting it will break reverse_iterator.
6623     </p>
6624
6625     <p>
6626     The fix is to make the comparison operators templated on two types.
6627     </p>
6628
6629     <pre>    template &lt;class Iterator1, class Iterator2&gt;
6630     bool operator== (reverse_iterator&lt;Iterator1&gt; const&amp; x,
6631                      reverse_iterator&lt;Iterator2&gt; const&amp; y);
6632     </pre>
6633
6634     <p>
6635     Obviously:  return x.base() == y.base();
6636     </p>
6637
6638     <p>
6639     Currently, no reverse_iterator to const_reverse_iterator compares are
6640     valid.
6641     </p>
6642
6643     <p>
6644     BTW, I think the issue is in support of bad code.  Compares should be
6645     between two iterators of the same type.  All std::algorithms require
6646     the begin and end iterators to be of the same type.
6647     </p>
6648 </blockquote>
6649
6650
6651 <p><b>Proposed resolution:</b></p>
6652 <p>Insert this paragraph after 23.1 [container.requirements] paragraph 7:</p>
6653 <blockquote>
6654   <p>In the expressions</p>
6655   <pre>    i == j
6656     i != j
6657     i &lt; j
6658     i &lt;= j
6659     i &gt;= j
6660     i &gt; j
6661     i - j
6662   </pre>
6663   <p>Where i and j denote objects of a container's iterator type,
6664   either or both may be replaced by an object of the container's
6665   const_iterator type referring to the same element with no
6666   change in semantics.</p>
6667 </blockquote>
6668
6669 <p><i>[post-Toronto: Judy supplied a proposed resolution saying that
6670 <tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
6671 iterator comparison and difference operations.]</i></p>
6672
6673
6674 <p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
6675 explicitly listed expressions; there was concern that the previous
6676 proposed resolution was too informal.]</i></p>
6677
6678
6679
6680 <p><b>Rationale:</b></p>
6681 <p>
6682 The LWG believes it is clear that the above wording applies only to
6683 the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
6684 where <tt>X</tt> is a container.  There is no requirement that
6685 <tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
6686 can be mixed.  If mixing them is considered important, that's a
6687 separate issue.  (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>.)
6688 </p>
6689
6690
6691
6692
6693 <hr>
6694 <h3><a name="181"></a>181. make_pair() unintended behavior</h3>
6695 <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>
6696  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-03</p>
6697 <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>
6698 <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>
6699 <p><b>Discussion:</b></p>
6700 <p>The claim has surfaced in Usenet that expressions such as<br>
6701 <br>
6702 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>make_pair("abc", 3)</tt><br>
6703 <br>
6704 are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
6705 parameter to <tt> const char (&amp;)[4]</tt>, which type is uncopyable.<br>
6706 <br>
6707 I doubt anyone intended that behavior...
6708 </p>
6709
6710
6711 <p><b>Proposed resolution:</b></p>
6712 <p>In 20.2 [utility], paragraph 1 change the following
6713 declaration of make_pair():</p>
6714 <blockquote>
6715   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(const T1&amp;, const T2&amp;);</pre>
6716 </blockquote>
6717 <p>to:</p>
6718 <blockquote>
6719   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(T1, T2);</pre>
6720 </blockquote>
6721 <p>  In 20.2.3 [pairs] paragraph 7 and the line before, change:</p>
6722 <blockquote>
6723 <pre>template &lt;class T1, class T2&gt;
6724 pair&lt;T1, T2&gt; make_pair(const T1&amp; x, const T2&amp; y);</pre>
6725 </blockquote>
6726 <p>to:</p>
6727 <blockquote>
6728 <pre>template &lt;class T1, class T2&gt;
6729 pair&lt;T1, T2&gt; make_pair(T1 x, T2 y);</pre>
6730 </blockquote>
6731 <p>and add the following footnote to the effects clause:</p>
6732 <blockquote>
6733   <p> According to 12.8 [class.copy], an implementation is permitted
6734   to not perform a copy of an argument, thus avoiding unnecessary
6735   copies.</p>
6736 </blockquote>
6737
6738
6739 <p><b>Rationale:</b></p>
6740 <p>Two potential fixes were suggested by Matt Austern and Dietmar
6741 Kühl, respectively, 1) overloading with array arguments, and 2) use of
6742 a reference_traits class with a specialization for arrays.  Andy
6743 Koenig suggested changing to pass by value. In discussion, it appeared
6744 that this was a much smaller change to the standard that the other two
6745 suggestions, and any efficiency concerns were more than offset by the
6746 advantages of the solution. Two implementors reported that the
6747 proposed resolution passed their test suites.</p>
6748
6749
6750
6751
6752 <hr>
6753 <h3><a name="182"></a>182. Ambiguous references to size_t</h3>
6754 <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>
6755  <b>Submitter:</b> Al Stevens <b>Date:</b> 1999-08-15</p>
6756 <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>
6757 <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>
6758 <p><b>Discussion:</b></p>
6759 <p>Many references to <tt> size_t</tt> throughout the document
6760 omit the <tt> std::</tt> namespace qualification.</p> <p>For
6761 example, 17.4.3.4 [replacement.functions] paragraph 2:</p>
6762 <blockquote>
6763 <pre> operator new(size_t)
6764  operator new(size_t, const std::nothrow_t&amp;)
6765  operator new[](size_t)
6766  operator new[](size_t, const std::nothrow_t&amp;)</pre>
6767 </blockquote>
6768
6769
6770 <p><b>Proposed resolution:</b></p>
6771 <p>   In 17.4.3.4 [replacement.functions] paragraph 2: replace:</p>
6772 <blockquote>
6773 <p><tt>     - operator new(size_t)<br>
6774      - operator new(size_t, const std::nothrow_t&amp;)<br>
6775      - operator new[](size_t)<br>
6776      - operator new[](size_t, const std::nothrow_t&amp;)</tt></p>
6777 </blockquote>
6778 <p>    by:</p>
6779 <blockquote>
6780 <pre>- operator new(std::size_t)
6781 - operator new(std::size_t, const std::nothrow_t&amp;)
6782 - operator new[](std::size_t)
6783 - operator new[](std::size_t, const std::nothrow_t&amp;)</pre>
6784 </blockquote>
6785 <p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
6786 <blockquote>
6787   <p>The typedef members pointer, const_pointer, size_type, and difference_type
6788   are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
6789 </blockquote>
6790 <p>&nbsp;by:</p>
6791 <blockquote>
6792   <p>The typedef members pointer, const_pointer, size_type, and difference_type
6793   are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
6794   respectively.</p>
6795 </blockquote>
6796 <p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
6797 <blockquote>
6798   <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
6799   <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
6800   is unspecified when or how often this function is called. The use of hint is
6801   unspecified, but intended as an aid to locality if an implementation so
6802   desires.</p>
6803 </blockquote>
6804 <p>by:</p>
6805 <blockquote>
6806   <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
6807   <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
6808   it is unspecified when or how often this function is called. The use of hint
6809   is unspecified, but intended as an aid to locality if an implementation so
6810   desires.</p>
6811 </blockquote>
6812 <p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
6813 <blockquote>
6814   <p>In Table 37, X denotes a Traits class defining types and functions for the
6815   character container type CharT; c and d denote values of type CharT; p and q
6816   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
6817   j denote values of type size_t; e and f denote values of type X::int_type; pos
6818   denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
6819 </blockquote>
6820 <p>by:</p>
6821 <blockquote>
6822   <p>In Table 37, X denotes a Traits class defining types and functions for the
6823   character container type CharT; c and d denote values of type CharT; p and q
6824   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
6825   j denote values of type std::size_t; e and f denote values of type X::int_type;
6826   pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
6827 </blockquote>
6828 <p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
6829 X::length(p): "size_t" by "std::size_t".</p>
6830 <p>   In [lib.std.iterator.tags] 24.3.3, paragraph 2:    replace:<br>
6831 &nbsp;&nbsp;&nbsp; typedef ptrdiff_t difference_type;<br>
6832     by:<br>
6833 &nbsp;&nbsp;&nbsp; typedef std::ptrdiff_t difference_type;</p>
6834 <p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the
6835 declaration of template &lt;class charT&gt; class ctype.<br>
6836 <br>
6837    In [lib.iterator.traits] 24.3.1, paragraph 2    put namespace std { ...} around the declaration of:<br>
6838 <br>
6839 &nbsp;&nbsp;&nbsp; template&lt;class Iterator&gt; struct iterator_traits<br>
6840 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;T*&gt;<br>
6841 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;const T*&gt;</p>
6842
6843
6844 <p><b>Rationale:</b></p>
6845 <p>The LWG believes correcting names like <tt>size_t</tt> and
6846 <tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
6847 to be essentially editorial.  There there can't be another size_t or
6848 ptrdiff_t meant anyway because, according to 17.4.3.1.4 [extern.types],</p>
6849
6850 <blockquote><p>
6851 For each type T from the Standard C library, the types ::T and std::T
6852 are reserved to the implementation and, when defined, ::T shall be
6853 identical to std::T.
6854 </p></blockquote>
6855
6856 <p>The issue is treated as a Defect Report to make explicit the Project
6857 Editor's authority to make this change.</p>
6858
6859 <p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
6860 request of the LWG.]</i></p>
6861
6862
6863 <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
6864 address use of the name <tt>size_t</tt> in contexts outside of
6865 namespace std, such as in the description of <tt>::operator new</tt>.
6866 The proposed changes should be reviewed to make sure they are
6867 correct.]</i></p>
6868
6869
6870 <p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
6871 them to be correct.]</i></p>
6872
6873
6874
6875
6876
6877
6878
6879 <hr>
6880 <h3><a name="183"></a>183. I/O stream manipulators don't work for wide character streams</h3>
6881 <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>
6882  <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1999-07-07</p>
6883 <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>
6884 <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>
6885 <p><b>Discussion:</b></p>
6886 <p>27.6.3 [std.manip] paragraph 3 says (clause numbering added for
6887 exposition):</p>
6888 <blockquote>
6889 <p>Returns: An object s of unspecified type such that if [1] out is an (instance
6890 of) basic_ostream then the expression out&lt;&lt;s behaves as if f(s) were
6891 called, and if [2] in is an (instance of) basic_istream then the expression
6892 in&gt;&gt;s behaves as if f(s) were called. Where f can be defined as: ios_base&amp;
6893 f(ios_base&amp; str, ios_base::fmtflags mask) { // reset specified flags
6894 str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
6895 out&lt;&lt;s has type ostream&amp; and value out. [4] The expression in&gt;&gt;s
6896 has type istream&amp; and value in.</p>
6897 </blockquote>
6898 <p>Given the definitions [1] and [2] for out and in, surely [3] should read:
6899 "The expression out &lt;&lt; s has type basic_ostream&amp; ..." and
6900 [4] should read: "The expression in &gt;&gt; s has type basic_istream&amp;
6901 ..."</p>
6902 <p>If the wording in the standard is correct, I can see no way of implementing
6903 any of the manipulators so that they will work with wide character streams.</p>
6904 <p>e.g. wcout &lt;&lt; setbase( 16 );</p>
6905 <p>Must have value 'wcout' (which makes sense) and type 'ostream&amp;' (which
6906 doesn't).</p>
6907 <p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
6908 8. In addition, Para 6 [setfill] has a similar error, but relates only to
6909 ostreams.</p>
6910 <p>I'd be happier if there was a better way of saying this, to make it clear
6911 that the value of the expression is "the same specialization of
6912 basic_ostream as out"&amp;</p>
6913
6914
6915 <p><b>Proposed resolution:</b></p>
6916 <p>Replace section 27.6.3 [std.manip] except paragraph 1 with the
6917 following:</p>
6918 <blockquote>
6919 <p>2- The type designated smanip in each of the following function
6920 descriptions is implementation-specified and may be different for each
6921 function.<br>
6922 <br>
6923 <tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
6924 <br>
6925 -3- Returns: An object s of unspecified type such that if out is an
6926 instance of basic_ostream&lt;charT,traits&gt; then the expression
6927 out&lt;&lt;s behaves
6928 as if f(s, mask) were called, or if in is an instance of
6929 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
6930 behaves as if
6931 f(s, mask) were called. The function f can be defined as:*<br>
6932 <br>
6933 [Footnote: The expression cin &gt;&gt; resetiosflags(ios_base::skipws)
6934 clears ios_base::skipws in the format flags stored in the
6935 basic_istream&lt;charT,traits&gt; object cin (the same as cin &gt;&gt;
6936 noskipws), and the expression cout &lt;&lt;
6937 resetiosflags(ios_base::showbase) clears
6938 ios_base::showbase in the format flags stored in the
6939 basic_ostream&lt;charT,traits&gt; object cout (the same as cout
6940 &lt;&lt;
6941 noshowbase). --- end footnote]<br>
6942 <br>
6943 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
6944 &nbsp;&nbsp; {<br>
6945 &nbsp;&nbsp; //  reset specified flags<br>
6946 &nbsp;&nbsp; str.setf(ios_base::fmtflags(0), mask);<br>
6947 &nbsp;&nbsp; return str;<br>
6948 &nbsp;&nbsp; }<br>
6949 </tt><br>
6950 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
6951 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
6952 <br>
6953 &nbsp;<tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
6954 <br>
6955 -4- Returns: An object s of unspecified type such that if out is an
6956 instance of basic_ostream&lt;charT,traits&gt; then the expression
6957 out&lt;&lt;s behaves
6958 as if f(s, mask) were called, or if in is an instance of
6959 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
6960 behaves as if f(s,
6961 mask) were called. The function f can be defined as:<br>
6962 <br>
6963 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
6964 &nbsp;&nbsp; {<br>
6965 &nbsp;&nbsp; //  set specified flags<br>
6966 &nbsp;&nbsp; str.setf(mask);<br>
6967 &nbsp;&nbsp; return str;<br>
6968 &nbsp;&nbsp; }<br>
6969 </tt><br>
6970 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
6971 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
6972 <br>
6973 <tt>smanip setbase(int base);</tt><br>
6974 <br>
6975 -5- Returns: An object s of unspecified type such that if out is an
6976 instance of basic_ostream&lt;charT,traits&gt; then the expression
6977 out&lt;&lt;s behaves
6978 as if f(s, base) were called, or if in is an instance of
6979 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
6980 behaves as if f(s,
6981 base) were called. The function f can be defined as:<br>
6982 <br>
6983 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int base)<br>
6984 &nbsp;&nbsp; {<br>
6985 &nbsp;&nbsp; //  set  basefield<br>
6986 &nbsp;&nbsp; str.setf(base ==  8 ? ios_base::oct :<br>
6987 &nbsp;&nbsp; base == 10 ? ios_base::dec :<br>
6988 &nbsp;&nbsp; base == 16 ? ios_base::hex :<br>
6989 &nbsp;&nbsp; ios_base::fmtflags(0), ios_base::basefield);<br>
6990 &nbsp;&nbsp; return str;<br>
6991 &nbsp;&nbsp; }<br>
6992 </tt><br>
6993 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
6994 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
6995 <br>
6996 <tt>smanip setfill(char_type c);<br>
6997 </tt><br>
6998 -6- Returns: An object s of unspecified type such that if out is (or is
6999 derived from) basic_ostream&lt;charT,traits&gt; and c has type charT
7000 then the
7001 expression out&lt;&lt;s behaves as if f(s, c) were called. The function
7002 f can be
7003 defined as:<br>
7004 <br>
7005 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>template&lt;class charT, class traits&gt;<br>
7006 &nbsp;&nbsp; basic_ios&lt;charT,traits&gt;&amp; f(basic_ios&lt;charT,traits&gt;&amp; str, charT c)<br>
7007 &nbsp;&nbsp; {<br>
7008 &nbsp;&nbsp; //  set fill character<br>
7009 &nbsp;&nbsp; str.fill(c);<br>
7010 &nbsp;&nbsp; return str;<br>
7011 &nbsp;&nbsp; }<br>
7012 </tt><br>
7013 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.<br>
7014 <br>
7015 <tt>smanip setprecision(int n);</tt><br>
7016 <br>
7017 -7- Returns: An object s of unspecified type such that if out is an
7018 instance of basic_ostream&lt;charT,traits&gt; then the expression
7019 out&lt;&lt;s behaves
7020 as if f(s, n) were called, or if in is an instance of
7021 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
7022 behaves as if f(s, n)
7023 were called. The function f can be defined as:<br>
7024 <br>
7025 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
7026 &nbsp;&nbsp; {<br>
7027 &nbsp;&nbsp; //  set precision<br>
7028 &nbsp;&nbsp; str.precision(n);<br>
7029 &nbsp;&nbsp; return str;<br>
7030 &nbsp;&nbsp; }<br>
7031 </tt><br>
7032 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
7033 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in<br>
7034 .<br>
7035 <tt>smanip setw(int n);<br>
7036 </tt><br>
7037 -8- Returns: An object s of unspecified type such that if out is an
7038 instance of basic_ostream&lt;charT,traits&gt; then the expression
7039 out&lt;&lt;s behaves
7040 as if f(s, n) were called, or if in is an instance of
7041 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
7042 behaves as if f(s, n)
7043 were called. The function f can be defined as:<br>
7044 <br>
7045 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
7046 &nbsp;&nbsp; {<br>
7047 &nbsp;&nbsp; //  set width<br>
7048 &nbsp;&nbsp; str.width(n);<br>
7049 &nbsp;&nbsp; return str;<br>
7050 &nbsp;&nbsp; }<br>
7051 </tt><br>
7052 The expression out&lt;&lt;s has type
7053 basic_ostream&lt;charT,traits&gt;&amp; and value out.  The expression
7054 in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value
7055 in.
7056 </p>
7057 </blockquote>
7058
7059 <p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
7060 the proposed resolution.]</i></p>
7061
7062
7063 <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
7064 the same paragraphs.]</i></p>
7065
7066
7067 <p><i>[Post-Tokyo: The issues list maintainer combined the proposed
7068 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
7069 intertwined that dealing with them separately appear fraught with
7070 error.  The full text was supplied by Bill Plauger; it was cross
7071 checked against changes supplied by Andy Sawyer. It should be further
7072 checked by the LWG.]</i></p>
7073
7074
7075
7076
7077
7078
7079 <hr>
7080 <h3><a name="184"></a>184. numeric_limits&lt;bool&gt; wording problems</h3>
7081 <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>
7082  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 1999-07-21</p>
7083 <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>
7084 <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>
7085 <p><b>Discussion:</b></p>
7086 <p>bools are defined by the standard to be of integer types, as per
7087 3.9.1 [basic.fundamental] paragraph 7.  However "integer types"
7088 seems to have a special meaning for the author of 18.2. The net effect
7089 is an unclear and confusing specification for
7090 numeric_limits&lt;bool&gt; as evidenced below.</p>
7091
7092 <p>18.2.1.2/7 says numeric_limits&lt;&gt;::digits is, for built-in integer
7093 types, the number of non-sign bits in the representation.</p>
7094
7095 <p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
7096 arithmetical value converts to true.</p>
7097
7098 <p>I don't think it makes sense at all to require
7099 numeric_limits&lt;bool&gt;::digits and numeric_limits&lt;bool&gt;::digits10 to
7100 be meaningful.</p>
7101
7102 <p>The standard defines what constitutes a signed (resp. unsigned) integer
7103 types. It doesn't categorize bool as being signed or unsigned. And the set of
7104 values of bool type has only two elements.</p>
7105
7106 <p>I don't think it makes sense to require numeric_limits&lt;bool&gt;::is_signed
7107 to be meaningful.</p>
7108
7109 <p>18.2.1.2/18 for numeric_limits&lt;integer_type&gt;::radix&nbsp; says:</p>
7110 <blockquote>
7111   <p>For integer types, specifies the base of the representation.186)</p>
7112 </blockquote>
7113
7114 <p>This disposition is at best misleading and confusing for the standard
7115 requires a "pure binary numeration system" for integer types as per
7116 3.9.1/7</p>
7117
7118 <p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
7119 BCD)."&nbsp; This also erroneous as the standard never defines any integer
7120 types with base representation other than 2.</p>
7121
7122 <p>Furthermore, numeric_limits&lt;bool&gt;::is_modulo and
7123 numeric_limits&lt;bool&gt;::is_signed have similar problems.</p>
7124
7125
7126 <p><b>Proposed resolution:</b></p>
7127 <p>Append to the end of 18.2.1.5 [numeric.special]:</p>
7128 <blockquote>
7129   <p>The specialization for bool shall be provided as follows:</p>
7130   <pre>    namespace std {
7131        template&lt;&gt; class numeric_limits&lt;bool&gt; {
7132        public:
7133          static const bool is_specialized = true;
7134          static bool min() throw() { return false; }
7135          static bool max() throw() { return true; }
7136
7137          static const int  digits = 1;
7138          static const int  digits10 = 0;
7139          static const bool is_signed = false;
7140          static const bool is_integer = true;
7141          static const bool is_exact = true;
7142          static const int  radix = 2;
7143          static bool epsilon() throw() { return 0; }
7144          static bool round_error() throw() { return 0; }
7145
7146          static const int  min_exponent = 0;
7147          static const int  min_exponent10 = 0;
7148          static const int  max_exponent = 0;
7149          static const int  max_exponent10 = 0;
7150
7151          static const bool has_infinity = false;
7152          static const bool has_quiet_NaN = false;
7153          static const bool has_signaling_NaN = false;
7154          static const float_denorm_style has_denorm = denorm_absent;
7155          static const bool has_denorm_loss = false;
7156          static bool infinity() throw() { return 0; }
7157          static bool quiet_NaN() throw() { return 0; }
7158          static bool signaling_NaN() throw() { return 0; }
7159          static bool denorm_min() throw() { return 0; }
7160
7161          static const bool is_iec559 = false;
7162          static const bool is_bounded = true;
7163          static const bool is_modulo = false;
7164
7165          static const bool traps = false;
7166          static const bool tinyness_before = false;
7167          static const float_round_style round_style = round_toward_zero;
7168        };
7169      }</pre>
7170 </blockquote>
7171
7172 <p><i>[Tokyo:&nbsp; The LWG desires wording that specifies exact values
7173 rather than more general wording in the original proposed
7174 resolution.]</i></p>
7175
7176
7177 <p><i>[Post-Tokyo:&nbsp; At the request of the LWG in Tokyo, Nico
7178 Josuttis provided the above wording.]</i></p>
7179
7180
7181
7182
7183
7184
7185 <hr>
7186 <h3><a name="185"></a>185. Questionable use of term "inline"</h3>
7187 <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>
7188  <b>Submitter:</b> UK Panel <b>Date:</b> 1999-07-26</p>
7189 <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>
7190 <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>
7191 <p><b>Discussion:</b></p>
7192 <p>Paragraph 4 of 20.5 [function.objects] says:</p>
7193 <blockquote>
7194   <p>&nbsp;[Example: To negate every element of a: transform(a.begin(), a.end(),
7195   a.begin(), negate&lt;double&gt;()); The corresponding functions will inline
7196   the addition and the negation. end example]</p>
7197 </blockquote>
7198 <p>(Note: The "addition" referred to in the above is in para 3) we can
7199 find no other wording, except this (non-normative) example which suggests that
7200 any "inlining" will take place in this case.</p>
7201 <p>Indeed both:</p>
7202 <blockquote>
7203   <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
7204   unspecified whether any global functions in the C++ Standard Library
7205   are defined as inline (7.1.2).</p>
7206 </blockquote>
7207 <p>and</p>
7208 <blockquote>
7209   <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
7210   unspecified whether any member functions in the C++ Standard Library
7211   are defined as inline (7.1.2).</p>
7212 </blockquote>
7213 <p>take care to state that this may indeed NOT be the case.</p>
7214 <p>Thus the example "mandates" behavior that is explicitly
7215 not required elsewhere.</p>
7216
7217
7218 <p><b>Proposed resolution:</b></p>
7219 <p>In 20.5 [function.objects] paragraph 1, remove the sentence:</p>
7220 <blockquote>
7221 <p>They are important for the effective use of the library.</p>
7222 </blockquote>
7223 <p>Remove 20.5 [function.objects] paragraph 2, which reads:</p>
7224 <blockquote>
7225   <p> Using function objects together with function templates
7226   increases the expressive power of the library as well as making the
7227   resulting code much more efficient.</p>
7228 </blockquote>
7229 <p>In 20.5 [function.objects] paragraph 4, remove the sentence:</p>
7230 <blockquote>
7231   <p>The corresponding functions will inline the addition and the
7232   negation.</p>
7233 </blockquote>
7234
7235 <p><i>[Kona: The LWG agreed there was a defect.]</i></p>
7236
7237 <p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
7238
7239
7240
7241
7242
7243
7244 <hr>
7245 <h3><a name="186"></a>186. bitset::set() second parameter should be bool</h3>
7246 <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>
7247  <b>Submitter:</b> Darin Adler <b>Date:</b> 1999-08-13</p>
7248 <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>
7249 <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>
7250 <p><b>Discussion:</b></p>
7251 <p>In section 23.3.5.2 [bitset.members], paragraph 13 defines the
7252 bitset::set operation to take a second parameter of type int. The
7253 function tests whether this value is non-zero to determine whether to
7254 set the bit to true or false. The type of this second parameter should
7255 be bool. For one thing, the intent is to specify a Boolean value. For
7256 another, the result type from test() is bool. In addition, it's
7257 possible to slice an integer that's larger than an int. This can't
7258 happen with bool, since conversion to bool has the semantic of
7259 translating 0 to false and any non-zero value to true.</p>
7260
7261
7262 <p><b>Proposed resolution:</b></p>
7263 <p>In 23.3.5 [template.bitset] Para 1 Replace:</p>
7264 <blockquote>
7265 <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = true ); </pre>
7266 </blockquote>
7267 <p>With:</p>
7268 <blockquote>
7269   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
7270 </blockquote>
7271 <p>In 23.3.5.2 [bitset.members] Para 12(.5) Replace:</p>
7272 <blockquote>
7273   <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = 1 );</pre>
7274 </blockquote>
7275 <p>With:</p>
7276 <blockquote>
7277   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
7278 </blockquote>
7279
7280 <p><i>[Kona: The LWG agrees with the description.&nbsp; Andy Sawyer will work
7281 on better P/R wording.]</i></p>
7282
7283 <p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
7284
7285
7286
7287 <p><b>Rationale:</b></p>
7288 <p><tt>bool</tt> is a better choice.  It is believed that binary
7289 compatibility is not an issue, because this member function is
7290 usually implemented as <tt>inline</tt>, and because it is already
7291 the case that users cannot rely on the type of a pointer to a
7292 nonvirtual member of a standard library class.</p>
7293
7294
7295
7296
7297
7298 <hr>
7299 <h3><a name="187"></a>187. iter_swap underspecified</h3>
7300 <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>
7301  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-14</p>
7302 <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>
7303 <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>
7304 <p><b>Discussion:</b></p>
7305 <p>The description of iter_swap in 25.2.2 paragraph 7,says that it
7306 ``exchanges the values'' of the objects to which two iterators
7307 refer.<br> <br> What it doesn't say is whether it does so using swap
7308 or using the assignment operator and copy constructor.<br> <br> This
7309 question is an important one to answer, because swap is specialized to
7310 work efficiently for standard containers.<br> For example:</p>
7311 <blockquote>
7312 <pre>vector&lt;int&gt; v1, v2;
7313 iter_swap(&amp;v1, &amp;v2);</pre>
7314 </blockquote>
7315 <p>Is this call to iter_swap equivalent to calling swap(v1, v2)?&nbsp;
7316 Or is it equivalent to</p>
7317 <blockquote>
7318 <pre>{
7319 vector&lt;int&gt; temp = v1;
7320 v1 = v2;
7321 v2 = temp;
7322 }</pre>
7323 </blockquote>
7324 <p>The first alternative is O(1); the second is O(n).</p>
7325 <p>A LWG member, Dave Abrahams, comments:</p>
7326 <blockquote>
7327 <p>Not an objection necessarily, but I want to point out the cost of
7328 that requirement:</p>
7329   <blockquote>
7330 <p><tt>iter_swap(list&lt;T&gt;::iterator, list&lt;T&gt;::iterator)</tt></p>
7331   </blockquote>
7332 <p>can currently be specialized to be more efficient than
7333 iter_swap(T*,T*) for many T (by using splicing). Your proposal would
7334 make that optimization illegal.&nbsp;</p>
7335 </blockquote>
7336
7337 <p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
7338 which are no longer permitted.]</i></p>
7339
7340
7341
7342 <p><b>Proposed resolution:</b></p>
7343 <p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
7344 <blockquote>
7345 <p>Exchanges the values pointed to by the two iterators a and b.</p>
7346 </blockquote>
7347 <p>to</p>
7348 <blockquote>
7349 <p><tt>swap(*a, *b)</tt>.</p>
7350 </blockquote>
7351
7352
7353
7354 <p><b>Rationale:</b></p>
7355 <p>It's useful to say just what <tt>iter_swap</tt> does.  There may be
7356   some iterators for which we want to specialize <tt>iter_swap</tt>,
7357   but the fully general version should have a general specification.</p>
7358
7359 <p>Note that in the specific case of <tt>list&lt;T&gt;::iterator</tt>,
7360 iter_swap should not be specialized as suggested above.  That would do
7361 much more than exchanging the two iterators' values: it would change
7362 predecessor/successor relationships, possibly moving the iterator from
7363 one list to another.  That would surely be inappropriate.</p>
7364
7365
7366
7367
7368
7369 <hr>
7370 <h3><a name="189"></a>189. setprecision() not specified correctly</h3>
7371 <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>
7372  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-25</p>
7373 <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>
7374 <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>
7375 <p><b>Discussion:</b></p>
7376 <p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
7377 and includes a parenthetical note saying that it is the number of
7378 digits after the decimal point.<br>
7379 <br>
7380 This claim is not strictly correct.  For example, in the default
7381 floating-point output format, setprecision sets the number of
7382 significant digits printed, not the number of digits after the decimal
7383 point.<br>
7384 <br>
7385 I would like the committee to look at the definition carefully and
7386 correct the statement in 27.4.2.2</p>
7387
7388
7389 <p><b>Proposed resolution:</b></p>
7390 <p>Remove from 27.4.2.2 [fmtflags.state], paragraph 9, the text
7391 "(number of digits after the decimal point)".</p>
7392
7393
7394
7395
7396 <hr>
7397 <h3><a name="193"></a>193. Heap operations description incorrect</h3>
7398 <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>
7399  <b>Submitter:</b> Markus Mauhart <b>Date:</b> 1999-09-24</p>
7400 <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>
7401 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a></p>
7402 <p><b>Discussion:</b></p>
7403 <p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
7404 is<br>
7405 <br>
7406 &nbsp;&nbsp;&nbsp; `"(1) *a is the largest element"<br>
7407 <br>
7408 I think this is incorrect and should be changed to the wording in the proposed
7409 resolution.</p>
7410 <p>Actually there are two independent changes:</p>
7411 <blockquote>
7412   <p>A-"part of largest equivalence class" instead of "largest", cause 25.3
7413   [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
7414   <p>B-Take
7415 'an oldest' from that equivalence class, otherwise the heap functions
7416 could not be used for a priority queue as explained in 23.2.3.2.2
7417 [lib.priqueue.members] (where I assume that a "priority queue" respects
7418 priority AND time).</p>
7419 </blockquote>
7420
7421
7422 <p><b>Proposed resolution:</b></p>
7423 <p>Change 25.3.6 [alg.heap.operations] property (1) from:</p>
7424 <blockquote>
7425   <p>(1) *a is the largest element</p>
7426 </blockquote>
7427 <p>to:</p>
7428 <blockquote>
7429   <p>(1) There is no element greater than <tt>*a</tt></p>
7430 </blockquote>
7431
7432
7433
7434
7435
7436 <hr>
7437 <h3><a name="195"></a>195. Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3>
7438 <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>
7439  <b>Submitter:</b> Matt Austern <b>Date:</b> 1999-10-13</p>
7440 <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>
7441 <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>
7442 <p><b>Discussion:</b></p>
7443 <p>Suppose that <tt>is.flags() &amp; ios_base::skipws</tt> is nonzero.
7444 What should <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor do if it
7445 reaches eof while skipping whitespace?  27.6.1.1.2/5 suggests it
7446 should set failbit. Should it set eofbit as well?  The standard
7447 doesn't seem to answer that question.</p>
7448
7449 <p>On the one hand, nothing in 27.6.1.1.3 [istream::sentry] says that
7450 <tt>basic_istream&lt;&gt;::sentry</tt> should ever set eofbit.  On the
7451 other hand, 27.6.1.1 [istream] paragraph 4 says that if
7452 extraction from a <tt>streambuf</tt> "returns
7453 <tt>traits::eof()</tt>, then the input function, except as explicitly
7454 noted otherwise, completes its actions and does
7455 <tt>setstate(eofbit)"</tt>.  So the question comes down to
7456 whether <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor is an
7457 input function.</p>
7458
7459 <p>Comments from Jerry Schwarz:</p>
7460 <blockquote>
7461 <p>It was always my intention that eofbit should be set any time that a
7462 virtual returned something to indicate eof, no matter what reason
7463 iostream code had for calling the virtual.</p>
7464 <p>
7465 The motivation for this is that I did not want to require streambufs
7466 to behave consistently if their virtuals are called after they have
7467 signaled eof.</p>
7468 <p>
7469 The classic case is a streambuf reading from a UNIX file.  EOF isn't
7470 really a state for UNIX file descriptors.  The convention is that a
7471 read on UNIX returns 0 bytes to indicate "EOF", but the file
7472 descriptor isn't shut down in any way and future reads do not
7473 necessarily also return 0 bytes.  In particular, you can read from
7474 tty's on UNIX even after they have signaled "EOF".  (It
7475 isn't always understood that a ^D on UNIX is not an EOF indicator, but
7476 an EOL indicator.  By typing a "line" consisting solely of
7477 ^D you cause a read to return 0 bytes, and by convention this is
7478 interpreted as end of file.)</p>
7479 </blockquote>
7480
7481
7482 <p><b>Proposed resolution:</b></p>
7483 <p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
7484 <blockquote>
7485 <p>If <tt>is.rdbuf()-&gt;sbumpc()</tt> or <tt>is.rdbuf()-&gt;sgetc()</tt>
7486 returns <tt>traits::eof()</tt>, the function calls
7487 <tt>setstate(failbit | eofbit)</tt> (which may throw
7488 <tt>ios_base::failure</tt>).
7489 </p>
7490 </blockquote>
7491
7492
7493
7494
7495 <hr>
7496 <h3><a name="198"></a>198. Validity of pointers and references unspecified after iterator destruction</h3>
7497 <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>
7498  <b>Submitter:</b> Beman Dawes <b>Date:</b> 1999-11-03</p>
7499 <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>
7500 <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>
7501 <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>
7502 <p><b>Discussion:</b></p>
7503 <p>
7504 Is a pointer or reference obtained from an iterator still valid after
7505 destruction of the iterator?
7506 </p>
7507 <p>
7508 Is a pointer or reference obtained from an iterator still valid after the value
7509 of the iterator changes?
7510 </p>
7511 <blockquote>
7512 <pre>#include &lt;iostream&gt;
7513 #include &lt;vector&gt;
7514 #include &lt;iterator&gt;
7515
7516 int main()
7517 {
7518     typedef std::vector&lt;int&gt; vec_t;
7519     vec_t v;
7520     v.push_back( 1 );
7521
7522     // Is a pointer or reference obtained from an iterator still
7523     // valid after destruction of the iterator?
7524     int * p = &amp;*v.begin();
7525     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
7526
7527     // Is a pointer or reference obtained from an iterator still
7528     // valid after the value of the iterator changes?
7529     vec_t::iterator iter( v.begin() );
7530     p = &amp;*iter++;
7531     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
7532
7533     return 0;
7534 }
7535 </pre>
7536 </blockquote>
7537
7538 <p>The standard doesn't appear to directly address these
7539 questions. The standard needs to be clarified. At least two real-world
7540 cases have been reported where library implementors wasted
7541 considerable effort because of the lack of clarity in the
7542 standard. The question is important because requiring pointers and
7543 references to remain valid has the effect for practical purposes of
7544 prohibiting iterators from pointing to cached rather than actual
7545 elements of containers.</p>
7546
7547 <p>The standard itself assumes that pointers and references obtained
7548 from an iterator are still valid after iterator destruction or
7549 change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 [reverse.iter.conv], which returns a reference, defines
7550 effects:</p>
7551
7552 <blockquote>
7553   <pre>Iterator tmp = current;
7554 return *--tmp;</pre>
7555 </blockquote>
7556 <p>The definition of reverse_iterator::operator-&gt;(), 24.4.1.3.4
7557 [reverse.iter.op.star], which returns a pointer, defines effects:</p>
7558 <blockquote>
7559   <pre>return &amp;(operator*());</pre>
7560 </blockquote>
7561
7562 <p>Because the standard itself assumes pointers and references remain
7563 valid after iterator destruction or change, the standard should say so
7564 explicitly. This will also reduce the chance of user code breaking
7565 unexpectedly when porting to a different standard library
7566 implementation.</p>
7567
7568
7569 <p><b>Proposed resolution:</b></p>
7570 <p>Add a new paragraph to 24.1 [iterator.requirements]:</p>
7571 <blockquote><p>
7572 Destruction of an iterator may invalidate pointers and references
7573 previously obtained from that iterator.
7574 </p></blockquote>
7575
7576 <p>Replace paragraph 1 of 24.4.1.3.3 [reverse.iter.conv] with:</p>
7577
7578 <blockquote>
7579 <p><b>Effects:</b></p>
7580 <pre>  this-&gt;tmp = current;
7581   --this-&gt;tmp;
7582   return *this-&gt;tmp;
7583 </pre>
7584
7585 <p>
7586 [<i>Note:</i> This operation must use an auxiliary member variable,
7587 rather than a temporary variable, to avoid returning a reference that
7588 persists beyond the lifetime of its associated iterator.  (See
7589 24.1 [iterator.requirements].)  The name of this member variable is shown for
7590 exposition only.  <i>--end note</i>]
7591 </p>
7592 </blockquote>
7593
7594 <p><i>[Post-Tokyo: The issue has been reformulated purely
7595 in terms of iterators.]</i></p>
7596
7597
7598 <p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
7599 assumption by reverse_iterator. The issue and proposed resolution was
7600 reformulated yet again to reflect this reality.]</i></p>
7601
7602
7603 <p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
7604 assumes its underlying iterator has persistent pointers and
7605 references.  Andy Koenig pointed out that it is possible to rewrite
7606 reverse_iterator so that it no longer makes such an assupmption.
7607 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
7608 decide it is intentional that <tt>p[n]</tt> may return by value
7609 instead of reference when <tt>p</tt> is a Random Access Iterator,
7610 other changes in reverse_iterator will be necessary.]</i></p>
7611
7612
7613
7614 <p><b>Rationale:</b></p>
7615 <p>This issue has been discussed extensively.  Note that it is
7616 <i>not</i> an issue about the behavior of predefined iterators.  It is
7617 asking whether or not user-defined iterators are permitted to have
7618 transient pointers and references.  Several people presented examples
7619 of useful user-defined iterators that have such a property; examples
7620 include a B-tree iterator, and an "iota iterator" that doesn't point
7621 to memory.  Library implementors already seem to be able to cope with
7622 such iterators: they take pains to avoid forming references to memory
7623 that gets iterated past.  The only place where this is a problem is
7624 <tt>reverse_iterator</tt>, so this issue changes
7625 <tt>reverse_iterator</tt> to make it work.</p>
7626
7627 <p>This resolution does not weaken any guarantees provided by
7628 predefined iterators like <tt>list&lt;int&gt;::iterator</tt>.
7629 Clause 23 should be reviewed to make sure that guarantees for
7630 predefined iterators are as strong as users expect.</p>
7631
7632
7633
7634
7635
7636
7637 <hr>
7638 <h3><a name="199"></a>199. What does <tt>allocate(0)</tt> return?</h3>
7639 <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>
7640  <b>Submitter:</b> Matt Austern <b>Date:</b> 1999-11-19</p>
7641 <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>
7642 <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>
7643 <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>
7644 <p><b>Discussion:</b></p>
7645 <p>
7646 Suppose that <tt>A</tt> is a class that conforms to the
7647 Allocator requirements of Table 32, and <tt>a</tt> is an
7648 object of class <tt>A</tt>  What should be the return
7649 value of <tt>a.allocate(0)</tt>?  Three reasonable
7650 possibilities: forbid the argument <tt>0</tt>, return
7651 a null pointer, or require that the return value be a
7652 unique non-null pointer.
7653 </p>
7654
7655
7656 <p><b>Proposed resolution:</b></p>
7657 <p>
7658 Add a note to the <tt>allocate</tt> row of Table 32:
7659 "[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
7660
7661
7662 <p><b>Rationale:</b></p>
7663 <p>A key to understanding this issue is that the ultimate use of
7664 allocate() is to construct an iterator, and that iterator for zero
7665 length sequences must be the container's past-the-end
7666 representation.  Since this already implies special case code, it
7667 would be over-specification to mandate the return value.
7668 </p>
7669
7670
7671
7672
7673 <hr>
7674 <h3><a name="200"></a>200. Forward iterator requirements don't allow constant iterators</h3>
7675 <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>
7676  <b>Submitter:</b> Matt Austern <b>Date:</b> 1999-11-19</p>
7677 <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>
7678 <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>
7679 <p><b>Discussion:</b></p>
7680 <p>
7681 In table 74, the return type of the expression <tt>*a</tt> is given
7682 as <tt>T&amp;</tt>, where <tt>T</tt> is the iterator's value type.
7683 For constant iterators, however, this is wrong.  ("Value type"
7684 is never defined very precisely, but it is clear that the value type
7685 of, say, <tt>std::list&lt;int&gt;::const_iterator</tt> is supposed to be
7686 <tt>int</tt>, not <tt>const int</tt>.)
7687 </p>
7688
7689
7690 <p><b>Proposed resolution:</b></p>
7691 <p>
7692 In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
7693 return type from "<tt>T&amp;</tt>" to "<tt>T&amp;</tt>
7694 if <tt>X</tt> is mutable, otherwise <tt>const T&amp;</tt>".
7695 In the <tt>a-&gt;m</tt> row, change the return type from
7696 "<tt>U&amp;</tt>" to "<tt>U&amp;</tt> if <tt>X</tt> is mutable,
7697 otherwise <tt>const U&amp;</tt>".
7698 </p>
7699
7700 <p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
7701 there are multiple const problems with the STL portion of the library
7702 and that these should be addressed as a single package.&nbsp; Note
7703 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
7704 that very reason.]</i></p>
7705
7706
7707 <p><i>[Redmond: the LWG thinks this is separable from other constness
7708 issues.  This issue is just cleanup; it clarifies language that was
7709 written before we had iterator_traits.  Proposed resolution was
7710 modified: the original version only discussed *a.  It was pointed out
7711 that we also need to worry about *r++ and a-&gt;m.]</i></p>
7712
7713
7714
7715
7716
7717
7718
7719 <hr>
7720 <h3><a name="201"></a>201. Numeric limits terminology wrong</h3>
7721 <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>
7722  <b>Submitter:</b> Stephen Cleary <b>Date:</b> 1999-12-21</p>
7723 <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>
7724 <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>
7725 <p><b>Discussion:</b></p>
7726 <p>
7727 In some places in this section, the terms "fundamental types" and
7728 "scalar types" are used when the term "arithmetic types" is intended.
7729 The current usage is incorrect because void is a fundamental type and
7730 pointers are scalar types, neither of which should have
7731 specializations of numeric_limits.
7732 </p>
7733 <p><i>[Lillehammer: it remains true that numeric_limits is using
7734   imprecise language. However, none of the proposals for changed
7735   wording are clearer.  A redesign of numeric_limits is needed, but this
7736   is more a task than an open issue.]</i></p>
7737
7738
7739
7740 <p><b>Proposed resolution:</b></p>
7741
7742 <p>
7743 Change 18.2 [support.limits] to:
7744 </p>
7745
7746 <blockquote>
7747 <p>
7748 -1- The headers <tt>&lt;limits&gt;</tt>, <tt>&lt;climits&gt;</tt>,
7749 <tt>&lt;cfloat&gt;</tt>, and <tt>&lt;cinttypes&gt;</tt> supply
7750 characteristics of implementation-dependent <del>fundamental</del>
7751 <ins>arithmetic</ins> types (3.9.1).
7752 </p>
7753 </blockquote>
7754
7755 <p>
7756 Change 18.2.1 [limits] to:
7757 </p>
7758
7759 <blockquote>
7760 <p>
7761 -1- The <tt>numeric_limits</tt> component provides a C++ program with
7762 information about various properties of the implementation's
7763 representation of the <del>fundamental</del> <ins>arithmetic</ins>
7764 types.
7765 </p>
7766 <p>
7767 -2- Specializations shall be provided for each <del>fundamental</del>
7768 <ins>arithmetic</ins> type, both floating point and integer, including
7769 <tt>bool</tt>. The member <tt>is_specialized</tt> shall be <tt>true</tt>
7770 for all such specializations of <tt>numeric_limits</tt>.
7771 </p>
7772 <p>
7773 -4- Non-<del>fundamental</del><ins>arithmetic</ins> standard types, such
7774 as <tt>complex&lt;T&gt;</tt> (26.3.2), shall not have specializations.
7775 </p>
7776 </blockquote>
7777
7778 <p>
7779 Change 18.2.1.1 [numeric.limits] to:
7780 </p>
7781
7782 <blockquote>
7783 <p>
7784 <del>-1- The member <tt>is_specialized</tt> makes it possible to distinguish
7785 between fundamental types, which have specializations, and non-scalar types,
7786 which do not.</del>
7787 </p>
7788 </blockquote>
7789
7790
7791
7792
7793
7794
7795 <hr>
7796 <h3><a name="202"></a>202. unique() effects unclear when predicate not an equivalence relation</h3>
7797 <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>
7798  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-01-13</p>
7799 <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>
7800 <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>
7801 <p><b>Discussion:</b></p>
7802 <p>
7803 What should unique() do if you give it a predicate that is not an
7804 equivalence relation?  There are at least two plausible answers:
7805 </p>
7806
7807 <blockquote>
7808
7809 <p>
7810    1. You can't, because 25.2.8 says that it it "eliminates all but
7811    the first element from every consecutive group of equal
7812    elements..." and it wouldn't make sense to interpret "equal" as
7813    meaning anything but an equivalence relation.  [It also doesn't
7814    make sense to interpret "equal" as meaning ==, because then there
7815    would never be any sense in giving a predicate as an argument at
7816    all.]
7817 </p>
7818
7819 <p>
7820    2. The word "equal" should be interpreted to mean whatever the
7821    predicate says, even if it is not an equivalence relation
7822    (and in particular, even if it is not transitive).
7823 </p>
7824
7825 </blockquote>
7826
7827 <p>
7828 The example that raised this question is from Usenet:
7829 </p>
7830
7831 <blockquote>
7832
7833 <pre>int f[] = { 1, 3, 7, 1, 2 };
7834 int* z = unique(f, f+5, greater&lt;int&gt;());</pre>
7835
7836 </blockquote>
7837
7838 <p>
7839 If one blindly applies the definition using the predicate
7840 greater&lt;int&gt;, and ignore the word "equal", you get:
7841 </p>
7842
7843 <blockquote>
7844
7845 <p>
7846     Eliminates all but the first element from every consecutive group
7847     of elements referred to by the iterator i in the range [first, last)
7848     for which *i &gt; *(i - 1).
7849 </p>
7850
7851 </blockquote>
7852
7853 <p>
7854 The first surprise is the order of the comparison.  If we wanted to
7855 allow for the predicate not being an equivalence relation, then we
7856 should surely compare elements the other way: pred(*(i - 1), *i).  If
7857 we do that, then the description would seem to say: "Break the
7858 sequence into subsequences whose elements are in strictly increasing
7859 order, and keep only the first element of each subsequence".  So the
7860 result would be 1, 1, 2.  If we take the description at its word, it
7861 would seem to call for strictly DEcreasing order, in which case the
7862 result should be 1, 3, 7, 2.<br>
7863 <br>
7864 In fact, the SGI implementation of unique() does neither: It yields 1,
7865 3, 7.
7866 </p>
7867
7868
7869 <p><b>Proposed resolution:</b></p>
7870 <p>Change 25.2.9 [alg.unique] paragraph 1 to:</p>
7871 <blockquote><p>
7872 For a nonempty range, eliminates all but the first element from every
7873 consecutive group of equivalent elements referred to by the iterator
7874 <tt>i</tt> in the range [first+1, last) for which the following
7875 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
7876 false</tt>.
7877 </p></blockquote>
7878
7879 <p>
7880 Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
7881 comparison function must be an equivalence relation."
7882 </p>
7883
7884 <p><i>[Redmond: discussed arguments for and against requiring the
7885 comparison function to be an equivalence relation.  Straw poll:
7886 14-2-5.  First number is to require that it be an equivalence
7887 relation, second number is to explicitly not require that it be an
7888 equivalence relation, third number is people who believe they need
7889 more time to consider the issue.  A separate issue: Andy Sawyer
7890 pointed out that "i-1" is incorrect, since "i" can refer to the first
7891 iterator in the range.  Matt provided wording to address this
7892 problem.]</i></p>
7893
7894
7895 <p><i>[Curaçao: The LWG changed "... the range (first,
7896 last)..." to "...  the range [first+1, last)..." for
7897 clarity. They considered this change close enough to editorial to not
7898 require another round of review.]</i></p>
7899
7900
7901
7902
7903 <p><b>Rationale:</b></p>
7904 <p>The LWG also considered an alternative resolution: change
7905 25.2.9 [alg.unique] paragraph 1 to:</p>
7906
7907 <blockquote><p>
7908 For a nonempty range, eliminates all but the first element from every
7909 consecutive group of elements referred to by the iterator
7910 <tt>i</tt> in the range (first, last) for which the following
7911 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
7912 false</tt>.
7913 </p></blockquote>
7914
7915 <p>
7916 Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
7917 comparison function need not be an equivalence relation."
7918 </p>
7919
7920
7921 <p>Informally: the proposed resolution imposes an explicit requirement
7922 that the comparison function be an equivalence relation.  The
7923 alternative resolution does not, and it gives enough information so
7924 that the behavior of unique() for a non-equivalence relation is
7925 specified.  Both resolutions are consistent with the behavior of
7926 existing implementations.</p>
7927
7928
7929
7930
7931
7932 <hr>
7933 <h3><a name="206"></a>206. operator new(size_t, nothrow) may become unlinked to ordinary operator new if ordinary version replaced</h3>
7934 <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>
7935  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-08-29</p>
7936 <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>
7937 <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>
7938 <p><b>Discussion:</b></p>
7939 <p>As specified, the implementation of the nothrow version of operator
7940 new does not necessarily call the ordinary operator new, but may
7941 instead simply call the same underlying allocator and return a null
7942 pointer instead of throwing an exception in case of failure.</p>
7943
7944 <p>Such an implementation breaks code that replaces the ordinary
7945 version of new, but not the nothrow version. If the ordinary version
7946 of new/delete is replaced, and if the replaced delete is not
7947 compatible with pointers returned from the library versions of new,
7948 then when the replaced delete receives a pointer allocated by the
7949 library new(nothrow), crash follows.</p>
7950
7951 <p>The fix appears to be that the lib version of new(nothrow) must
7952 call the ordinary new. Thus when the ordinary new gets replaced, the
7953 lib version will call the replaced ordinary new and things will
7954 continue to work.</p>
7955
7956 <p>An alternative would be to have the ordinary new call
7957 new(nothrow). This seems sub-optimal to me as the ordinary version of
7958 new is the version most commonly replaced in practice. So one would
7959 still need to replace both ordinary and nothrow versions if one wanted
7960 to replace the ordinary version.</p>
7961
7962 <p>Another alternative is to put in clear text that if one version is
7963 replaced, then the other must also be replaced to maintain
7964 compatibility. Then the proposed resolution below would just be a
7965 quality of implementation issue. There is already such text in
7966 paragraph 7 (under the new(nothrow) version). But this nuance is
7967 easily missed if one reads only the paragraphs relating to the
7968 ordinary new.</p>
7969
7970 <p>
7971 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2158.html">N2158</a>
7972 has been written explaining the rationale for the proposed resolution below.
7973 </p>
7974
7975
7976
7977 <p><b>Proposed resolution:</b></p>
7978 <p>
7979 Change 18.5.1.1 [new.delete.single]:
7980 </p>
7981
7982 <blockquote>
7983 <pre>void* operator new(std::size_t <i>size</i>, const std::nothrow_t&amp;) throw();
7984 </pre>
7985 <blockquote>
7986 <p>
7987 -5- <i>Effects:</i> Same as above, except that it is called by a placement
7988 version of a <i>new-expression</i> when a C++ program prefers a null pointer result as
7989 an error indication, instead of a <tt>bad_alloc</tt> exception.
7990 </p>
7991
7992 <p>
7993 -6- <i>Replaceable:</i> a C++ program may define a function with this function
7994 signature that displaces the default version defined by the C++ Standard
7995 library.
7996 </p>
7997
7998 <p>
7999 -7- <i>Required behavior:</i> Return a non-null pointer to suitably aligned
8000 storage (3.7.4), or else return a null pointer. This nothrow version of operator
8001 new returns a pointer obtained as if acquired from the <ins>(possibly
8002 replaced)</ins> ordinary version. This requirement is binding on a replacement
8003 version of this function.
8004 </p>
8005
8006 <p>
8007 -8- <i>Default behavior:</i>
8008 </p>
8009 <ul>
8010 <li><ins>
8011 Calls <tt>operator new(<i>size</i>)</tt>.
8012 </ins></li>
8013 <li><ins>
8014 If the call to <tt>operator new(<i>size</i>)</tt> returns normally, returns
8015 the result of that call, else
8016 </ins></li>
8017 <li><ins>
8018 if the call to <tt>operator new(<i>size</i>)</tt> throws an exception, returns
8019 a null pointer.
8020 </ins></li>
8021 <li><del>
8022 Executes a loop: Within the loop, the function first attempts to allocate the
8023 requested storage. Whether the attempt involves a call to the Standard C library
8024 function <tt>malloc</tt> is unspecified.
8025 </del></li>
8026 <li><del>
8027 Returns a pointer to the allocated storage if the attempt is successful.
8028 Otherwise, if the last argument to <tt>set_new_handler()</tt> was a null
8029 pointer, return a null pointer.
8030 </del></li>
8031 <li><del>
8032 Otherwise, the function calls the current <i>new_handler</i> (18.5.2.2). If the
8033 called function returns, the loop repeats.
8034 </del></li>
8035 <li><del>
8036 The loop terminates when an attempt to allocate the requested storage is
8037 successful or when a called <i>new_handler</i> function does not return. If the
8038 called <i>new_handler</i> function terminates by throwing a <tt>bad_alloc
8039 exception</tt>, the function returns a null pointer.
8040 </del></li>
8041 </ul>
8042 <p>
8043 -9- [<i>Example:</i>
8044 </p>
8045 <blockquote><pre>T* p1 = new T;                 <i>// throws bad_alloc if it fails</i>
8046 T* p2 = new(nothrow) T;        <i>// returns 0 if it fails</i>
8047 </pre></blockquote>
8048 <p>
8049 --<i>end example</i>]
8050 </p>
8051 </blockquote>
8052
8053 <pre>void operator delete(void* <i>ptr</i>) throw();
8054 <del>void operator delete(void* <i>ptr</i>, const std::nothrow_t&amp;) throw();</del>
8055 </pre>
8056
8057 <blockquote>
8058 <p>
8059 -10- <i>Effects:</i> The <i>deallocation function</i> (3.7.4.2) called by a
8060 <i>delete-expression</i> to render the value of <tt><i>ptr</i></tt> invalid.
8061 </p>
8062 <p>
8063 -11- <i>Replaceable:</i> a C++ program may define a function with this function
8064 signature that displaces the default version defined by the C++ Standard
8065 library.
8066 </p>
8067 <p>
8068 -12- <i>Requires:</i> the value of <tt><i>ptr</i></tt> is null or the value
8069 returned by an earlier call to the <del>default</del> <ins>(possibly
8070 replaced)</ins> <tt>operator new(std::size_t)</tt> or <tt>operator
8071 new(std::size_t, const std::nothrow_t&amp;)</tt>.
8072 </p>
8073 <p>
8074 -13- <i>Default behavior:</i>
8075 </p>
8076 <ul>
8077 <li>
8078 For a null value of <tt><i>ptr</i></tt>, do nothing.
8079 </li>
8080 <li>
8081 Any other value of <tt><i>ptr</i></tt> shall be a value returned earlier by a
8082 call to the default <tt>operator new</tt>, which was not invalidated by an
8083 intervening call to <tt>operator delete(void*)</tt> (17.4.3.7). For such a
8084 non-null value of <tt><i>ptr</i></tt>, reclaims storage allocated by the earlier
8085 call to the default <tt>operator new</tt>.
8086 </li>
8087 </ul>
8088 <p>
8089 -14- <i>Remarks:</i>  It is unspecified under what conditions part or all of
8090 such reclaimed storage is allocated by a subsequent call to <tt>operator
8091 new</tt> or any of <tt>calloc</tt>, <tt>malloc</tt>, or <tt>realloc</tt>,
8092 declared in <tt>&lt;cstdlib&gt;</tt>.
8093 </p>
8094 </blockquote>
8095
8096 <pre><ins>void operator delete(void* <i>ptr</i>, const std::nothrow_t&amp;) throw();</ins>
8097 </pre>
8098
8099 <blockquote>
8100 <p><ins>
8101 -15- <i>Effects:</i> Same as above, except that it is called by the
8102 implementation when an exception propagates from a nothrow placement version
8103 of the <i>new-expression</i> (i.e. when the constructor throws an exception).
8104 </ins></p>
8105 <p><ins>
8106 -16- <i>Replaceable:</i> a C++ program may define a function with this function
8107 signature that displaces the default version defined by the C++ Standard
8108 library.
8109 </ins></p>
8110 <p><ins>
8111 -17- <i>Requires:</i> the value of <tt><i>ptr</i></tt> is null or the
8112 value returned by an earlier call to the (possibly replaced) <tt>operator
8113 new(std::size_t)</tt> or <tt>operator new(std::size_t, const
8114 std::nothrow_t&amp;)</tt>. </ins></p>
8115 <p><ins>
8116 -18- <i>Default behavior:</i> Calls <tt>operator delete(<i>ptr</i>)</tt>.
8117 </ins></p>
8118 </blockquote>
8119
8120 </blockquote>
8121
8122 <p>
8123 Change 18.5.1.2 [new.delete.array]
8124 </p>
8125
8126 <blockquote>
8127 <pre>void* operator new[](std::size_t <i>size</i>, const std::nothrow_t&amp;) throw();
8128 </pre>
8129
8130 <blockquote>
8131 <p>
8132 -5- <i>Effects:</i> Same as above, except that it is called by a placement
8133 version of a <i>new-expression</i> when a C++ program prefers a null pointer result as
8134 an error indication, instead of a <tt>bad_alloc</tt> exception.
8135 </p>
8136
8137 <p>
8138 -6- <i>Replaceable:</i>  a C++ program can define a function with this function
8139 signature that displaces the default version defined by the C++ Standard
8140 library.
8141 </p>
8142
8143 <p>
8144 -7- <i>Required behavior:</i> <del>Same as for operator <tt>new(std::size_t,
8145 const std::nothrow_t&amp;)</tt>. This nothrow version of operator <tt>new[]</tt>
8146 returns a pointer obtained as if acquired from the ordinary version.</del>
8147 <ins>Return a non-null pointer to suitably aligned storage (3.7.4), or else
8148 return a null pointer. This nothrow version of operator new returns a pointer
8149 obtained as if acquired from the (possibly replaced) <tt>operator
8150 new[](std::size_t <i>size</i>)</tt>. This requirement is binding on a
8151 replacement version of this function.</ins>
8152 </p>
8153
8154 <p>
8155 -8- <i>Default behavior:</i> <del>Returns <tt>operator new(<i>size</i>,
8156 nothrow)</tt>.</del>
8157 </p>
8158
8159 <ul>
8160 <li><ins>
8161 Calls <tt>operator new[](<i>size</i>)</tt>.
8162 </ins></li>
8163 <li><ins>
8164 If the call to <tt>operator new[](<i>size</i>)</tt> returns normally, returns
8165 the result of that call, else
8166 </ins></li>
8167 <li><ins>
8168 if the call to <tt>operator new[](<i>size</i>)</tt> throws an exception, returns
8169 a null pointer.
8170 </ins></li>
8171 </ul>
8172 </blockquote>
8173
8174 <pre>void operator delete[](void* <i>ptr</i>) throw();
8175 void operator delete[](void* <i>ptr</i>, const std::nothrow_t&amp;) throw();
8176 </pre>
8177
8178 <blockquote>
8179 <p>
8180 -9- <i>Effects:</i> The <i>deallocation function</i> (3.7.4.2) called by the
8181 array form of a <i>delete-expression</i> to render the value of
8182 <tt><i>ptr</i></tt> invalid.
8183 </p>
8184
8185 <p>
8186 -10- <i>Replaceable:</i> a C++ program can define a function with this function
8187 signature that displaces the default version defined by the C++ Standard
8188 library.
8189 </p>
8190
8191 <p>
8192 -11- <i>Requires:</i> the value of
8193 <tt><i>ptr</i></tt> is null or the value returned by an earlier call to
8194 <tt>operator new[](std::size_t)</tt> or <tt>operator new[](std::size_t, const
8195 std::nothrow_t&amp;)</tt>.
8196 </p>
8197
8198 <p>
8199 -12- <i>Default behavior:</i> Calls <tt>operator delete(<i>ptr</i>)</tt> or
8200 <tt>operator delete<ins>[]</ins>(<i>ptr</i><del>, std::nothrow</del>)</tt> respectively.
8201 </p>
8202 </blockquote>
8203
8204 </blockquote>
8205
8206
8207
8208 <p><b>Rationale:</b></p>
8209 <p>Yes, they may become unlinked, and that is by design. If a user
8210 replaces one, the user should also replace the other.</p>
8211
8212 <p><i>[
8213 Reopened due to a gcc conversation between Howard, Martin and Gaby.  Forwarding
8214 or not is visible behavior to the client and it would be useful for the client
8215 to know which behavior it could depend on.
8216 ]</i></p>
8217
8218
8219 <p><i>[
8220 Batavia: Robert voiced serious reservations about backwards compatibility for
8221 his customers.
8222 ]</i></p>
8223
8224
8225
8226
8227
8228
8229 <hr>
8230 <h3><a name="208"></a>208. Unnecessary restriction on past-the-end iterators</h3>
8231 <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>
8232  <b>Submitter:</b> Stephen Cleary <b>Date:</b> 2000-02-02</p>
8233 <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>
8234 <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>
8235 <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>
8236 <p><b>Discussion:</b></p>
8237 <p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
8238 past-the-end values are always non-singular."</p>
8239 <p>This places an unnecessary restriction on past-the-end iterators for
8240 containers with forward iterators (for example, a singly-linked list). If the
8241 past-the-end value on such a container was a well-known singular value, it would
8242 still satisfy all forward iterator requirements.</p>
8243 <p>Removing this restriction would allow, for example, a singly-linked list
8244 without a "footer" node.</p>
8245 <p>This would have an impact on existing code that expects past-the-end
8246 iterators obtained from different (generic) containers being not equal.</p>
8247
8248
8249 <p><b>Proposed resolution:</b></p>
8250 <p>Change 24.1 [iterator.requirements] paragraph 5, the last sentence, from:</p>
8251 <blockquote>
8252 <p>Dereferenceable and past-the-end values are always non-singular.</p>
8253 </blockquote>
8254 <p>to:</p>
8255 <blockquote>
8256 <p>Dereferenceable values are always non-singular.&nbsp;</p>
8257 </blockquote>
8258
8259
8260 <p><b>Rationale:</b></p>
8261 <p>For some kinds of containers, including singly linked lists and
8262 zero-length vectors, null pointers are perfectly reasonable past-the-end
8263 iterators.  Null pointers are singular.
8264 </p>
8265
8266
8267
8268
8269 <hr>
8270 <h3><a name="209"></a>209. basic_string declarations inconsistent</h3>
8271 <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>
8272  <b>Submitter:</b> Igor Stauder <b>Date:</b> 2000-02-11</p>
8273 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
8274 <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>
8275 <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>
8276 <p><b>Discussion:</b></p>
8277 <p>In Section 21.3 [basic.string] the basic_string member function
8278 declarations use a consistent style except for the following functions:</p>
8279 <blockquote>
8280   <pre>void push_back(const charT);
8281 basic_string&amp; assign(const basic_string&amp;);
8282 void swap(basic_string&lt;charT,traits,Allocator&gt;&amp;);</pre>
8283 </blockquote>
8284 <p>- push_back, assign, swap: missing argument name&nbsp;<br>
8285 - push_back: use of const with charT (i.e. POD type passed by value
8286 not by reference - should be charT or const charT&amp; )<br>
8287 - swap: redundant use of template parameters in argument
8288 basic_string&lt;charT,traits,Allocator&gt;&amp;</p>
8289
8290
8291 <p><b>Proposed resolution:</b></p>
8292 <p>In Section 21.3 [basic.string] change the basic_string member
8293 function declarations push_back, assign, and swap to:</p>
8294 <blockquote>
8295   <pre>void push_back(charT c);
8296
8297 basic_string&amp; assign(const basic_string&amp; str);
8298 void swap(basic_string&amp; str);</pre>
8299 </blockquote>
8300
8301
8302 <p><b>Rationale:</b></p>
8303 <p>Although the standard is in general not consistent in declaration
8304 style, the basic_string declarations are consistent other than the
8305 above.  The LWG felt that this was sufficient reason to merit the
8306 change.
8307 </p>
8308
8309
8310
8311
8312 <hr>
8313 <h3><a name="210"></a>210. distance first and last confused</h3>
8314 <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>
8315  <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 2000-02-15</p>
8316 <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>
8317 <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>
8318 <p><b>Discussion:</b></p>
8319 <p>In paragraph 9 of section 25 [algorithms], it is written:</p>
8320 <blockquote>
8321   <p>      In the description of the algorithms operators + and - are used
8322            for some of the iterator categories for which they do not have to
8323            be defined. In these cases the semantics of [...] a-b is the same
8324            as of<br>
8325   <br>
8326   &nbsp;&nbsp;&nbsp;&nbsp; <tt>return distance(a, b);</tt></p>
8327 </blockquote>
8328
8329
8330 <p><b>Proposed resolution:</b></p>
8331 <p>On the last line of paragraph 9 of section 25 [algorithms] change
8332 <tt>"a-b"</tt> to <tt>"b-a".</tt></p>
8333
8334
8335 <p><b>Rationale:</b></p>
8336 <p>There are two ways to fix the defect; change the description to b-a
8337 or change the return to distance(b,a).  The LWG preferred the
8338 former for consistency.</p>
8339
8340
8341
8342
8343 <hr>
8344 <h3><a name="211"></a>211. operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</h3>
8345 <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>
8346  <b>Submitter:</b> Scott Snyder <b>Date:</b> 2000-02-04</p>
8347 <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>
8348 <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>
8349 <p><b>Discussion:</b></p>
8350 <p>The description of the stream extraction operator for std::string (section
8351 21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
8352 the case that the operator fails to extract any characters from the input
8353 stream.</p>
8354 <p>This implies that the typical construction</p>
8355 <blockquote>
8356   <pre>std::istream is;
8357 std::string str;
8358 ...
8359 while (is &gt;&gt; str) ... ;</pre>
8360 </blockquote>
8361 <p>(which tests failbit) is not required to terminate at EOF.</p>
8362 <p>Furthermore, this is inconsistent with other extraction operators,
8363 which do include this requirement. (See sections 27.6.1.2 [istream.formatted] and 27.6.1.3 [istream.unformatted]), where this
8364 requirement is present, either explicitly or implicitly, for the
8365 extraction operators. It is also present explicitly in the description
8366 of getline (istream&amp;, string&amp;, charT) in section 21.3.8.9 [string.io] paragraph 8.)</p>
8367
8368
8369 <p><b>Proposed resolution:</b></p>
8370 <p>Insert new paragraph after paragraph 2 in section 21.3.8.9 [string.io]:</p>
8371 <blockquote>
8372
8373 <p>If the function extracts no characters, it calls
8374 is.setstate(ios::failbit) which may throw ios_base::failure
8375 (27.4.4.3).</p>
8376 </blockquote>
8377
8378
8379
8380
8381 <hr>
8382 <h3><a name="212"></a>212. Empty range behavior unclear for several algorithms</h3>
8383 <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>
8384  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 2000-02-26</p>
8385 <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>
8386 <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>
8387 <p><b>Discussion:</b></p>
8388 <p>The standard doesn't specify what min_element() and max_element() shall
8389 return if the range is empty (first equals last). The usual implementations
8390 return last. This problem seems also apply to partition(), stable_partition(),
8391 next_permutation(), and prev_permutation().</p>
8392
8393
8394 <p><b>Proposed resolution:</b></p>
8395 <p>In 25.3.7 [alg.min.max] - Minimum and maximum, paragraphs 7 and
8396 9, append: Returns last if first==last.</p>
8397
8398
8399 <p><b>Rationale:</b></p>
8400 <p>The LWG looked in some detail at all of the above mentioned
8401 algorithms, but believes that except for min_element() and
8402 max_element() it is already clear that last is returned if first ==
8403 last.</p>
8404
8405
8406
8407
8408 <hr>
8409 <h3><a name="214"></a>214. set::find() missing const overload</h3>
8410 <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>
8411  <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-02-28</p>
8412 <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>
8413 <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>
8414 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#450">450</a></p>
8415 <p><b>Discussion:</b></p>
8416 <p>The specification for the associative container requirements in
8417 Table 69 state that the find member function should "return
8418 iterator; const_iterator for constant a". The map and multimap
8419 container descriptions have two overloaded versions of find, but set
8420 and multiset do not, all they have is:</p>
8421 <blockquote>
8422   <pre>iterator find(const key_type &amp; x) const;</pre>
8423 </blockquote>
8424
8425
8426 <p><b>Proposed resolution:</b></p>
8427 <p>Change the prototypes for find(), lower_bound(), upper_bound(), and
8428 equal_range() in section 23.3.3 [set] and section 23.3.4 [multiset] to each have two overloads:</p>
8429 <blockquote>
8430   <pre>iterator find(const key_type &amp; x);
8431 const_iterator find(const key_type &amp; x) const;</pre>
8432   <pre>iterator lower_bound(const key_type &amp; x);
8433 const_iterator lower_bound(const key_type &amp; x) const;</pre>
8434   <pre>iterator upper_bound(const key_type &amp; x);
8435 const_iterator upper_bound(const key_type &amp; x) const;</pre>
8436   <pre>pair&lt;iterator, iterator&gt; equal_range(const key_type &amp; x);
8437 pair&lt;const_iterator, const_iterator&gt; equal_range(const key_type &amp; x) const;</pre>
8438 </blockquote>
8439
8440 <p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
8441 extending the proposed resolution to lower_bound, upper_bound, and
8442 equal_range.]</i></p>
8443
8444
8445
8446
8447
8448
8449 <hr>
8450 <h3><a name="217"></a>217. Facets example (Classifying Japanese characters) contains errors</h3>
8451 <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>
8452  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-02-29</p>
8453 <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>
8454 <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>
8455 <p><b>Discussion:</b></p>
8456 <p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
8457 <p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
8458 must be const in order for it to be callable on a const object (a reference to
8459 which which is what std::use_facet&lt;&gt;() returns).</p>
8460 <p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
8461 name of the namespace `My'.</p>
8462 <p>3) In the definition of `loc' and subsequently in the call to use_facet&lt;&gt;()
8463 in main(), the name of the facet is misspelled: it should read `My::JCtype'
8464 rather than `My::JCType'.</p>
8465
8466
8467 <p><b>Proposed resolution:</b></p>
8468 <p>Replace the "Classifying Japanese characters" example in 22.2.8,
8469 paragraph 11 with the following:</p>
8470 <pre>#include &lt;locale&gt;</pre>
8471 <pre>namespace My {
8472     using namespace std;
8473     class JCtype : public locale::facet {
8474     public:
8475         static locale::id id;     //  required for use as a new locale facet
8476         bool is_kanji (wchar_t c) const;
8477         JCtype() {}
8478     protected:
8479         ~JCtype() {}
8480     };
8481 }</pre>
8482 <pre>//  file:  filt.C
8483 #include &lt;iostream&gt;
8484 #include &lt;locale&gt;
8485 #include "jctype"                 //  above
8486 std::locale::id My::JCtype::id;   //  the static  JCtype  member
8487 declared above.</pre>
8488 <pre>int main()
8489 {
8490     using namespace std;
8491     typedef ctype&lt;wchar_t&gt; wctype;
8492     locale loc(locale(""),              //  the user's preferred locale...
8493                new My::JCtype);         //  and a new feature ...
8494     wchar_t c = use_facet&lt;wctype&gt;(loc).widen('!');
8495     if (!use_facet&lt;My::JCtype&gt;(loc).is_kanji(c))
8496         cout &lt;&lt; "no it isn't!" &lt;&lt; endl;
8497     return 0;
8498 }</pre>
8499
8500
8501
8502
8503 <hr>
8504 <h3><a name="220"></a>220. ~ios_base() usage valid?</h3>
8505 <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>
8506  <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Date:</b> 2000-03-13</p>
8507 <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>
8508 <p><b>Discussion:</b></p>
8509 <p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
8510 paragraph 2:</p>
8511 <blockquote>
8512   <p>Effects: Destroys an object of class ios_base. Calls each registered
8513   callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
8514   time that any ios_base member function called from within fn has well defined
8515   results.</p>
8516 </blockquote>
8517 <p>But what is not clear is: If no callback functions were ever registered, does
8518 it matter whether the ios_base members were ever initialized?</p>
8519 <p>For instance, does this program have defined behavior:</p>
8520 <blockquote>
8521   <pre>#include &lt;ios&gt;</pre>
8522   <pre>class D : public std::ios_base { };</pre>
8523   <pre>int main() { D d; }</pre>
8524 </blockquote>
8525 <p>It seems that registration of a callback function would surely affect the
8526 state of an ios_base. That is, when you register a callback function with an
8527 ios_base, the ios_base must record that fact somehow.</p>
8528 <p>But if after construction the ios_base is in an indeterminate state, and that
8529 state is not made determinate before the destructor is called, then how would
8530 the destructor know if any callbacks had indeed been registered? And if the
8531 number of callbacks that had been registered is indeterminate, then is not the
8532 behavior of the destructor undefined?</p>
8533 <p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
8534 it explicit that destruction before initialization results in undefined
8535 behavior.</p>
8536
8537
8538 <p><b>Proposed resolution:</b></p>
8539 <p>Modify 27.4.2.7 paragraph 1 from</p>
8540 <blockquote>
8541   <p>Effects: Each ios_base member has an indeterminate value after
8542   construction.</p>
8543 </blockquote>
8544 <p>to</p>
8545 <blockquote>
8546   <p>Effects: Each ios_base member has an indeterminate
8547 value after construction. These members must be initialized by calling
8548 basic_ios::init. If an ios_base object is destroyed before these
8549 initializations have taken place, the behavior is undefined.</p>
8550 </blockquote>
8551
8552
8553
8554
8555 <hr>
8556 <h3><a name="221"></a>221. num_get&lt;&gt;::do_get stage 2 processing broken</h3>
8557 <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>
8558  <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-03-14</p>
8559 <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>
8560 <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>
8561 <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>
8562 <p><b>Discussion:</b></p>
8563 <p>Stage 2 processing of numeric conversion is broken.</p>
8564
8565 <p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
8566 conversion specifier is %i. A %i specifier determines a number's base
8567 by its prefix (0 for octal, 0x for hex), so the intention is clearly
8568 that a 0x prefix is allowed.  Paragraph 8 in the same section,
8569 however, describes very precisely how characters are processed. (It
8570 must be done "as if" by a specified code fragment.) That
8571 description does not allow a 0x prefix to be recognized.</p>
8572
8573 <p>Very roughly, stage 2 processing reads a char_type ct. It converts
8574 ct to a char, not by using narrow but by looking it up in a
8575 translation table that was created by widening the string literal
8576 "0123456789abcdefABCDEF+-". The character "x" is
8577 not found in that table, so it can't be recognized by stage 2
8578 processing.</p>
8579
8580
8581 <p><b>Proposed resolution:</b></p>
8582 <p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
8583 <blockquote>
8584   <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
8585 </blockquote>
8586 <p>with the line:</p>
8587 <blockquote>
8588   <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
8589 </blockquote>
8590
8591
8592 <p><b>Rationale:</b></p>
8593 <p>If we're using the technique of widening a string literal, the
8594 string literal must contain every character we wish to recognize.
8595 This technique has the consequence that alternate representations
8596 of digits will not be recognized.  This design decision was made
8597 deliberately, with full knowledge of that limitation.</p>
8598
8599
8600
8601
8602
8603 <hr>
8604 <h3><a name="222"></a>222. Are throw clauses necessary if a throw is already implied by the effects clause?</h3>
8605 <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>
8606  <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-03-17</p>
8607 <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>
8608 <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>
8609 <p><b>Discussion:</b></p>
8610 <p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
8611 <blockquote>
8612   <pre>21.3.6.8 - basic_string::compare [lib.string::compare]
8613
8614 int compare(size_type pos1, size_type n1,
8615                 const basic_string&lt;charT,traits,Allocator&gt;&amp;  str ,
8616                 size_type  pos2 , size_type  n2 ) const;
8617
8618 -4- Returns:
8619
8620     basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
8621                  basic_string&lt;charT,traits,Allocator&gt;(str,pos2,n2)) .</pre>
8622 </blockquote>
8623 <p>and the constructor that's implicitly called by the above is
8624 defined to throw an out-of-range exception if pos &gt; str.size(). See
8625 section 21.3.1 [string.require] paragraph 4.</p>
8626
8627 <p>On the other hand, the compare function descriptions themselves don't have
8628 "Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
8629 that do not apply to a function are omitted.</p>
8630 <p>So it seems there is an inconsistency in the standard -- are the
8631 "Effects" clauses correct, or are the "Throws" clauses
8632 missing?</p>
8633
8634
8635 <p><b>Proposed resolution:</b></p>
8636 <p>In 17.3.1.3 [structure.specifications] paragraph 3, the footnote 148 attached to
8637 the sentence "Descriptions of function semantics contain the
8638 following elements (as appropriate):", insert the word
8639 "further" so that the foot note reads:</p>
8640 <blockquote>
8641   <p>To save space, items that do not apply to a function are
8642   omitted. For example, if a function does not specify any further
8643   preconditions, there will be no "Requires" paragraph.</p>
8644 </blockquote>
8645
8646
8647 <p><b>Rationale:</b></p>
8648 <p>The standard is somewhat inconsistent, but a failure to note a
8649 throw condition in a throws clause does not grant permission not to
8650 throw.  The inconsistent wording is in a footnote, and thus
8651 non-normative. The proposed resolution from the LWG clarifies the
8652 footnote.</p>
8653
8654
8655
8656
8657 <hr>
8658 <h3><a name="223"></a>223. reverse algorithm should use iter_swap rather than swap</h3>
8659 <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>
8660  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-03-21</p>
8661 <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>
8662 <p><b>Discussion:</b></p>
8663 <p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
8664
8665
8666 <p><b>Proposed resolution:</b></p>
8667 <p>In 25.2.10 [alg.reverse], replace:</p>
8668   <blockquote><p>
8669   Effects: For each non-negative integer i &lt;= (last - first)/2,
8670   applies swap to all pairs of iterators first + i, (last - i) - 1.
8671   </p></blockquote>
8672 <p>with:</p>
8673   <blockquote><p>
8674   Effects: For each non-negative integer i &lt;= (last - first)/2,
8675   applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
8676   </p></blockquote>
8677
8678
8679
8680
8681 <hr>
8682 <h3><a name="224"></a>224. clear() complexity for associative containers refers to undefined N</h3>
8683 <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>
8684  <b>Submitter:</b> Ed Brey <b>Date:</b> 2000-03-23</p>
8685 <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>
8686 <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>
8687 <p><b>Discussion:</b></p>
8688 <p>In the associative container requirements table in 23.1.2 paragraph 7,
8689 a.clear() has complexity "log(size()) + N". However, the meaning of N
8690 is not defined.</p>
8691
8692
8693 <p><b>Proposed resolution:</b></p>
8694 <p>In the associative container requirements table in 23.1.2 paragraph
8695 7, the complexity of a.clear(), change "log(size()) + N" to
8696 "linear in <tt>size()</tt>".</p>
8697
8698
8699 <p><b>Rationale:</b></p>
8700 <p>It's the "log(size())", not the "N", that is in
8701 error: there's no difference between <i>O(N)</i> and <i>O(N +
8702 log(N))</i>.  The text in the standard is probably an incorrect
8703 cut-and-paste from the range version of <tt>erase</tt>.</p>
8704
8705
8706
8707
8708 <hr>
8709 <h3><a name="225"></a>225. std:: algorithms use of other unqualified algorithms</h3>
8710 <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>
8711  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-01</p>
8712 <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>
8713 <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>
8714 <p><b>Discussion:</b></p>
8715 <p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
8716 user namespaces might be found through Koenig lookup?</p>
8717 <p>For example, a popular standard library implementation includes this
8718 implementation of std::unique:</p>
8719 <blockquote>
8720 <pre>namespace std {
8721     template &lt;class _ForwardIter&gt;
8722     _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
8723       __first = adjacent_find(__first, __last);
8724       return unique_copy(__first, __last, __first);
8725     }
8726     }</pre>
8727 </blockquote>
8728 <p>Imagine two users on opposite sides of town, each using unique on his own
8729 sequences bounded by my_iterators . User1 looks at his standard library
8730 implementation and says, "I know how to implement a more efficient
8731 unique_copy for my_iterators", and writes:</p>
8732 <blockquote>
8733 <pre>namespace user1 {
8734     class my_iterator;
8735     // faster version for my_iterator
8736     my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
8737     }</pre>
8738 </blockquote>
8739 <p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
8740 <p>User2 has other needs, and writes:</p>
8741 <blockquote>
8742 <pre>namespace user2 {
8743     class my_iterator;
8744     // Returns true iff *c is a unique copy of *a and *b.
8745     bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
8746     }</pre>
8747 </blockquote>
8748 <p>User2 is shocked to find later that his fully-qualified use of
8749 std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
8750 compile (if he's lucky). Looking in the standard, he sees the following Effects
8751 clause for unique():</p>
8752 <blockquote>
8753   <p>Effects: Eliminates all but the first element from every consecutive group
8754   of equal elements referred to by the iterator i in the range [first, last) for
8755   which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
8756   *(i - 1)) != false</p>
8757 </blockquote>
8758 <p>The standard gives user2 absolutely no reason to think he can interfere with
8759 std::unique by defining names in namespace user2. His standard library has been
8760 built with the template export feature, so he is unable to inspect the
8761 implementation. User1 eventually compiles his code with another compiler, and
8762 his version of unique_copy silently stops being called. Eventually, he realizes
8763 that he was depending on an implementation detail of his library and had no
8764 right to expect his unique_copy() to be called portably.</p>
8765 <p>On the face of it, and given above scenario, it may seem obvious that the
8766 implementation of unique() shown is non-conforming because it uses unique_copy()
8767 rather than ::std::unique_copy(). Most standard library implementations,
8768 however, seem to disagree with this notion.</p>
8769 <p> <i>[Tokyo:&nbsp; Steve Adamczyk from
8770 the core working group indicates that "std::" is sufficient;&nbsp;
8771 leading "::" qualification is not required because any namespace
8772 qualification is sufficient to suppress Koenig lookup.]</i></p>
8773
8774
8775 <p><b>Proposed resolution:</b></p>
8776 <p>Add a paragraph and a note at the end of
8777 17.4.4.3 [global.functions]:</p>
8778 <blockquote>
8779
8780 <p>Unless otherwise specified, no global or non-member function in the
8781 standard library shall use a function from another namespace which is
8782 found through <i>argument-dependent name lookup</i> (3.4.2 [basic.lookup.argdep]).</p>
8783
8784 <p>[Note: the phrase "unless otherwise specified" is intended to
8785 allow Koenig lookup in cases like that of ostream_iterators:<br>
8786
8787 <br>
8788   Effects:</p>
8789   <blockquote>
8790 <p>*out_stream &lt;&lt; value;<br>
8791       if(delim != 0) *out_stream &lt;&lt; delim;<br>
8792       return (*this);</p>
8793     <p>--end note]</p>
8794   </blockquote>
8795 </blockquote>
8796
8797 <p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
8798 is as yet unsure if the proposed resolution is the best
8799 solution. Furthermore, the LWG believes that the same problem of
8800 unqualified library names applies to wording in the standard itself,
8801 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
8802 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
8803 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>.]</i></p>
8804
8805
8806 <p><i>[Toronto: The LWG is not sure if this is a defect in the
8807 standard.  Most LWG members believe that an implementation of
8808 <tt>std::unique</tt> like the one quoted in this issue is already
8809 illegal, since, under certain circumstances, its semantics are not
8810 those specified in the standard.  The standard's description of
8811 <tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
8812 should have any effect.]</i></p>
8813
8814
8815 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
8816 225, 226, and 229.  Their conclusion was that the issues should be
8817 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
8818 EWG portion (Dave will write a proposal). The LWG and EWG had
8819 (separate) discussions of this plan the next day.  The proposed
8820 resolution for this issue is in accordance with Howard's paper.]</i></p>
8821
8822
8823
8824
8825 <p><b>Rationale:</b></p>
8826 <p>It could be argued that this proposed isn't strictly necessary,
8827   that the Standard doesn't grant implementors license to write a
8828   standard function that behaves differently than specified in the
8829   Standard just because of an unrelated user-defined name in some
8830   other namespace.  However, this is at worst a clarification.  It is
8831   surely right that algorithsm shouldn't pick up random names, that
8832   user-defined names should have no effect unless otherwise specified.
8833   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
8834   appropriate for the standard to explicitly specify otherwise.</p>
8835
8836
8837
8838
8839
8840 <hr>
8841 <h3><a name="226"></a>226. User supplied specializations or overloads of namespace std function templates</h3>
8842 <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>
8843  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-01</p>
8844 <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>
8845 <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>
8846 <p><b>Discussion:</b></p>
8847 <p>The issues are:&nbsp;</p>
8848 <p>1. How can a 3rd party library implementor (lib1) write a version of a standard
8849 algorithm which is specialized to work with his own class template?&nbsp;</p>
8850 <p>2. How can another library implementor (lib2) write a generic algorithm which
8851 will take advantage of the specialized algorithm in lib1?</p>
8852 <p>This appears to be the only viable answer under current language rules:</p>
8853 <blockquote>
8854   <pre>namespace lib1
8855 {
8856     // arbitrary-precision numbers using T as a basic unit
8857     template &lt;class T&gt;
8858     class big_num { //...
8859     };
8860     </pre>
8861   <pre>    // defining this in namespace std is illegal (it would be an
8862     // overload), so we hope users will rely on Koenig lookup
8863     template &lt;class T&gt;
8864     void swap(big_int&lt;T&gt;&amp;, big_int&lt;T&gt;&amp;);
8865 }</pre>
8866   <pre>#include &lt;algorithm&gt;
8867 namespace lib2
8868 {
8869     template &lt;class T&gt;
8870     void generic_sort(T* start, T* end)
8871     {
8872             ...
8873         // using-declaration required so we can work on built-in types
8874         using std::swap;
8875         // use Koenig lookup to find specialized algorithm if available
8876         swap(*x, *y);
8877     }
8878 }</pre>
8879 </blockquote>
8880 <p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
8881 and somewhat slippery. The implementor needs to remember to write the
8882 using-declaration, or generic_sort will fail to compile when T is a built-in
8883 type. The second drawback is that the use of this style in lib2 effectively
8884 "reserves" names in any namespace which defines types which may
8885 eventually be used with lib2. This may seem innocuous at first when applied to
8886 names like swap, but consider more ambiguous names like unique_copy() instead.
8887 It is easy to imagine the user wanting to define these names differently in his
8888 own namespace. A definition with semantics incompatible with the standard
8889 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>
8890 <p>Why, you may ask, can't we just partially specialize std::swap()? It's
8891 because the language doesn't allow for partial specialization of function
8892 templates. If you write:</p>
8893 <blockquote>
8894   <pre>namespace std
8895 {
8896     template &lt;class T&gt;
8897     void swap(lib1::big_int&lt;T&gt;&amp;, lib1::big_int&lt;T&gt;&amp;);
8898 }</pre>
8899 </blockquote>
8900 <p>You have just overloaded std::swap, which is illegal under the current
8901 language rules. On the other hand, the following full specialization is legal:</p>
8902 <blockquote>
8903   <pre>namespace std
8904 {
8905     template &lt;&gt;
8906     void swap(lib1::other_type&amp;, lib1::other_type&amp;);
8907 }</pre>
8908 </blockquote>
8909
8910 <p>This issue reflects concerns raised by the "Namespace issue
8911 with specialized swap" thread on comp.lang.c++.moderated. A
8912 similar set of concerns was earlier raised on the boost.org mailing
8913 list and the ACCU-general mailing list.  Also see library reflector
8914 message c++std-lib-7354.</p>
8915
8916 <p>
8917 J. C. van Winkel points out (in c++std-lib-9565) another unexpected
8918 fact: it's impossible to output a container of std::pair's using copy
8919 and an ostream_iterator, as long as both pair-members are built-in or
8920 std:: types.  That's because a user-defined operator&lt;&lt; for (for
8921 example) std::pair&lt;const std::string, int&gt; will not be found:
8922 lookup for operator&lt;&lt; will be performed only in namespace std.
8923 Opinions differed on whether or not this was a defect, and, if so,
8924 whether the defect is that something is wrong with user-defined
8925 functionality and std, or whether it's that the standard library does
8926 not provide an operator&lt;&lt; for std::pair&lt;&gt;.
8927 </p>
8928
8929
8930
8931 <p><b>Proposed resolution:</b></p>
8932
8933 <p>Adopt the wording proposed in Howard Hinnant's paper
8934   N1523=03-0106, "Proposed Resolution To LWG issues 225, 226, 229".</p>
8935
8936
8937 <p><i>[Tokyo: Summary, "There is no conforming way to extend
8938 std::swap for user defined templates."&nbsp; The LWG agrees that
8939 there is a problem.  Would like more information before
8940 proceeding. This may be a core issue.  Core issue 229 has been opened
8941 to discuss the core aspects of this problem. It was also noted that
8942 submissions regarding this issue have been received from several
8943 sources, but too late to be integrated into the issues list.
8944 ]</i></p>
8945
8946
8947 <p><i>[Post-Tokyo: A paper with several proposed resolutions,
8948 J16/00-0029==WG21/N1252, "Shades of namespace std functions
8949 " by Alan Griffiths, is in the Post-Tokyo mailing. It
8950 should be considered a part of this issue.]</i></p>
8951
8952
8953 <p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
8954 resolution that involves core changes: it would add partial
8955 specialization of function template.  The Core Working Group is
8956 reluctant to add partial specialization of function templates.  It is
8957 viewed as a large change, CWG believes that proposal presented leaves
8958 some syntactic issues unanswered; if the CWG does add partial
8959 specialization of function templates, it wishes to develop its own
8960 proposal.  The LWG continues to believe that there is a serious
8961 problem: there is no good way for users to force the library to use
8962 user specializations of generic standard library functions, and in
8963 certain cases (e.g. transcendental functions called by
8964 <tt>valarray</tt> and <tt>complex</tt>) this is important.  Koenig
8965 lookup isn't adequate, since names within the library must be
8966 qualified with <tt>std</tt> (see issue 225), specialization doesn't
8967 work (we don't have partial specialization of function templates), and
8968 users aren't permitted to add overloads within namespace std.
8969 ]</i></p>
8970
8971
8972 <p><i>[Copenhagen: Discussed at length, with no consensus.  Relevant
8973 papers in the pre-Copenhagen mailing: N1289, N1295, N1296.  Discussion
8974 focused on four options. (1) Relax restrictions on overloads within
8975 namespace std. (2) Mandate that the standard library use unqualified
8976 calls for <tt>swap</tt> and possibly other functions.  (3) Introduce
8977 helper class templates for <tt>swap</tt> and possibly other functions.
8978 (4) Introduce partial specialization of function templates.  Every
8979 option had both support and opposition.  Straw poll (first number is
8980 support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
8981 (4) 4, 4.]</i></p>
8982
8983
8984 <p><i>[Redmond: Discussed, again no consensus.  Herb presented an
8985 argument that a user who is defining a type <tt>T</tt> with an
8986 associated <tt>swap</tt> should not be expected to put that
8987 <tt>swap</tt> in namespace std, either by overloading or by partial
8988 specialization.  The argument is that <tt>swap</tt> is part of
8989 <tt>T</tt>'s interface, and thus should to in the same namespace as
8990 <tt>T</tt> and only in that namespace.  If we accept this argument,
8991 the consequence is that standard library functions should use
8992 unqualified call of <tt>swap</tt>.  (And which other functions? Any?)
8993 A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
8994 try to put together a proposal before the next meeting.]</i></p>
8995
8996
8997 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
8998 225, 226, and 229.  Their conclusion was that the issues should be
8999 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
9000 EWG portion (Dave will write a proposal). The LWG and EWG had
9001 (separate) discussions of this plan the next day.  The proposed
9002 resolution is the one proposed by Howard.]</i></p>
9003
9004
9005 <p><i>[Santa Cruz: the LWG agreed with the general direction of
9006   Howard's paper, N1387.  (Roughly: Koenig lookup is disabled unless
9007   we say otherwise; this issue is about when we do say otherwise.)
9008   However, there were concerns about wording.  Howard will provide new
9009   wording.  Bill and Jeremy will review it.]</i></p>
9010
9011
9012 <p><i>[Kona: Howard proposed the new wording.  The LWG accepted his
9013   proposed resolution.]</i></p>
9014
9015
9016
9017
9018 <p><b>Rationale:</b></p>
9019 <p>Informally: introduce a Swappable concept, and specify that the
9020   value types of the iterators passed to certain standard algorithms
9021   (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
9022   to that concept.  The Swappable concept will make it clear that
9023   these algorithms use unqualified lookup for the calls
9024   to <tt>swap</tt>.  Also, in 26.5.3.3 [valarray.transcend] paragraph 1,
9025   state that the valarray transcendentals use unqualified lookup.</p>
9026
9027
9028
9029
9030
9031 <hr>
9032 <h3><a name="227"></a>227. std::swap() should require CopyConstructible or DefaultConstructible arguments</h3>
9033 <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>
9034  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-09</p>
9035 <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>
9036 <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>
9037 <p><b>Discussion:</b></p>
9038 <p>25.2.2 reads:</p>
9039 <blockquote>
9040   <p><tt>  template&lt;class T&gt; void swap(T&amp; a, T&amp; b);</tt><br>
9041   <br>
9042   Requires:    Type T is Assignable (_lib.container.requirements_).<br>
9043   Effects:    Exchanges values stored in two locations.</p>
9044 </blockquote>
9045 <p>The only reasonable** generic implementation of swap requires construction of a
9046    new temporary copy of one of its arguments:</p>
9047 <blockquote>
9048 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
9049   {
9050       T tmp(a);
9051       a = b;
9052       b = tmp;
9053   }</pre>
9054 </blockquote>
9055 <p>But a type which is only Assignable cannot be swapped by this implementation.</p>
9056 <p>**Yes, there's also an unreasonable implementation which would require T to be
9057    DefaultConstructible instead of CopyConstructible. I don't think this is worthy
9058    of consideration:</p>
9059 <blockquote>
9060 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
9061 {
9062     T tmp;
9063     tmp = a;
9064     a = b;
9065     b = tmp;
9066 }</pre>
9067 </blockquote>
9068
9069
9070 <p><b>Proposed resolution:</b></p>
9071 <p>Change 25.2.2 paragraph 1 from:</p>
9072 <blockquote>
9073 <p>  Requires: Type T is Assignable (23.1).</p>
9074 </blockquote>
9075 <p>to:</p>
9076 <blockquote>
9077 <p>  Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
9078 </blockquote>
9079
9080
9081
9082
9083
9084 <hr>
9085 <h3><a name="228"></a>228. Incorrect specification of "..._byname" facets</h3>
9086 <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>
9087  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-20</p>
9088 <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>
9089 <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>
9090 <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>
9091 <p><b>Discussion:</b></p>
9092 <p>The sections 22.2.1.2 [locale.ctype.byname], 22.2.1.5
9093 [locale.codecvt.byname],
9094 sref ref="22.2.1.6", 22.2.3.2 [locale.numpunct.byname], 22.2.4.2
9095 [locale.collate.byname], 22.2.5.4 [locale.time.put.byname], 22.2.6.4
9096 [locale.moneypunct.byname], and 22.2.7.2 [locale.messages.byname]
9097 overspecify the
9098 definitions of the "..._byname" classes by listing a bunch
9099 of virtual functions. At the same time, no semantics of these
9100 functions are defined. Real implementations do not define these
9101 functions because the functional part of the facets is actually
9102 implemented in the corresponding base classes and the constructor of
9103 the "..._byname" version just provides suitable date used by
9104 these implementations. For example, the 'numpunct' methods just return
9105 values from a struct. The base class uses a statically initialized
9106 struct while the derived version reads the contents of this struct
9107 from a table. However, no virtual function is defined in
9108 'numpunct_byname'.</p>
9109
9110 <p>For most classes this does not impose a problem but specifically
9111 for 'ctype' it does: The specialization for 'ctype_byname&lt;char&gt;'
9112 is required because otherwise the semantics would change due to the
9113 virtual functions defined in the general version for 'ctype_byname':
9114 In 'ctype&lt;char&gt;' the method 'do_is()' is not virtual but it is
9115 made virtual in both 'ctype&lt;cT&gt;' and 'ctype_byname&lt;cT&gt;'.
9116 Thus, a class derived from 'ctype_byname&lt;char&gt;' can tell whether
9117 this class is specialized or not under the current specification:
9118 Without the specialization, 'do_is()' is virtual while with
9119 specialization it is not virtual.</p>
9120
9121
9122 <p><b>Proposed resolution:</b></p>
9123 <p>&nbsp; Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
9124 <pre>     namespace std {
9125        template &lt;class charT&gt;
9126        class ctype_byname : public ctype&lt;charT&gt; {
9127        public:
9128          typedef ctype&lt;charT&gt;::mask mask;
9129          explicit ctype_byname(const char*, size_t refs = 0);
9130        protected:
9131         ~ctype_byname();             //  virtual
9132        };
9133      }</pre>
9134 <p>&nbsp; Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
9135 <pre>    namespace std {
9136       template &lt;class internT, class externT, class stateT&gt;
9137       class codecvt_byname : public codecvt&lt;internT, externT, stateT&gt; {
9138       public:
9139        explicit codecvt_byname(const char*, size_t refs = 0);
9140       protected:
9141       ~codecvt_byname();             //  virtual
9142        };
9143      }
9144 </pre>
9145 <p>&nbsp; Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
9146 <pre>     namespace std {
9147        template &lt;class charT&gt;
9148        class numpunct_byname : public numpunct&lt;charT&gt; {
9149      //  this class is specialized for  char  and  wchar_t.
9150        public:
9151          typedef charT                char_type;
9152          typedef basic_string&lt;charT&gt;  string_type;
9153          explicit numpunct_byname(const char*, size_t refs = 0);
9154        protected:
9155         ~numpunct_byname();          //  virtual
9156        };
9157      }</pre>
9158 <p>&nbsp; Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
9159 <pre>     namespace std {
9160        template &lt;class charT&gt;
9161        class collate_byname : public collate&lt;charT&gt; {
9162        public:
9163          typedef basic_string&lt;charT&gt; string_type;
9164          explicit collate_byname(const char*, size_t refs = 0);
9165        protected:
9166         ~collate_byname();           //  virtual
9167        };
9168      }</pre>
9169 <p>&nbsp; Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
9170 <pre>     namespace std {
9171        template &lt;class charT, class InputIterator = istreambuf_iterator&lt;charT&gt; &gt;
9172        class time_get_byname : public time_get&lt;charT, InputIterator&gt; {
9173        public:
9174          typedef time_base::dateorder dateorder;
9175          typedef InputIterator        iter_type</pre>
9176 <pre>         explicit time_get_byname(const char*, size_t refs = 0);
9177        protected:
9178         ~time_get_byname();          //  virtual
9179        };
9180      }</pre>
9181 <p>&nbsp; Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
9182 <pre>     namespace std {
9183        template &lt;class charT, class OutputIterator = ostreambuf_iterator&lt;charT&gt; &gt;
9184        class time_put_byname : public time_put&lt;charT, OutputIterator&gt;
9185        {
9186        public:
9187          typedef charT          char_type;
9188          typedef OutputIterator iter_type;</pre>
9189 <pre>         explicit time_put_byname(const char*, size_t refs = 0);
9190        protected:
9191         ~time_put_byname();          //  virtual
9192        };
9193      }"</pre>
9194 <p>&nbsp; Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
9195 <pre>     namespace std {
9196        template &lt;class charT, bool Intl = false&gt;
9197        class moneypunct_byname : public moneypunct&lt;charT, Intl&gt; {
9198        public:
9199          typedef money_base::pattern pattern;
9200          typedef basic_string&lt;charT&gt; string_type;</pre>
9201 <pre>         explicit moneypunct_byname(const char*, size_t refs = 0);
9202        protected:
9203         ~moneypunct_byname();        //  virtual
9204        };
9205      }</pre>
9206 <p>&nbsp; Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
9207 <pre>     namespace std {
9208        template &lt;class charT&gt;
9209        class messages_byname : public messages&lt;charT&gt; {
9210        public:
9211          typedef messages_base::catalog catalog;
9212          typedef basic_string&lt;charT&gt;    string_type;</pre>
9213 <pre>         explicit messages_byname(const char*, size_t refs = 0);
9214        protected:
9215         ~messages_byname();          //  virtual
9216        };
9217      }</pre>
9218 <p>Remove section 22.2.1.4 [locale.codecvt] completely (because in
9219 this case only those members are defined to be virtual which are
9220 defined to be virtual in 'ctype&lt;cT&gt;'.)</p>
9221
9222 <p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of
9223 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>
9224
9225
9226 <p><i>[Copenhagen: proposed resolution was revised slightly, to remove
9227 three last virtual functions from <tt>messages_byname</tt>.]</i></p>
9228
9229
9230
9231
9232
9233
9234
9235 <hr>
9236 <h3><a name="229"></a>229. Unqualified references of other library entities</h3>
9237 <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>
9238  <b>Submitter:</b> Steve Clamage <b>Date:</b> 2000-04-19</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>Throughout the library chapters, the descriptions of library entities refer
9242 to other library entities without necessarily qualifying the names.</p>
9243
9244 <p>For example, section 25.2.2 "Swap" describes the effect of
9245 swap_ranges in terms of the unqualified name "swap". This section
9246 could reasonably be interpreted to mean that the library must be implemented so
9247 as to do a lookup of the unqualified name "swap", allowing users to
9248 override any ::std::swap function when Koenig lookup applies.</p>
9249
9250 <p>Although it would have been best to use explicit qualification with
9251 "::std::" throughout, too many lines in the standard would have to be
9252 adjusted to make that change in a Technical Corrigendum.</p>
9253
9254 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, which addresses qualification of
9255 <tt>size_t</tt>, is a special case of this.
9256 </p>
9257
9258
9259 <p><b>Proposed resolution:</b></p>
9260 <p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p>
9261 <blockquote>
9262   <p>Whenever a name x defined in the standard library is mentioned, the name x
9263   is assumed to be fully qualified as ::std::x, unless explicitly described
9264   otherwise. For example, if the Effects section for library function F is
9265   described as calling library function G, the function ::std::G is meant.</p>
9266 </blockquote>
9267
9268 <p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
9269 the LWG to solve a problem in the standard itself similar to the
9270 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
9271 coordinated with the resolution of this issue.]</i></p>
9272
9273
9274 <p><i>[post-Toronto: Howard is undecided about whether it is
9275 appropriate for all standard library function names referred to in
9276 other standard library functions to be explicitly qualified by
9277 <tt>std</tt>: it is common advice that users should define global
9278 functions that operate on their class in the same namespace as the
9279 class, and this requires argument-dependent lookup if those functions
9280 are intended to be called by library code.  Several LWG members are
9281 concerned that valarray appears to require argument-dependent lookup,
9282 but that the wording may not be clear enough to fall under
9283 "unless explicitly described otherwise".]</i></p>
9284
9285
9286 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
9287 225, 226, and 229.  Their conclusion was that the issues should be
9288 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
9289 EWG portion (Dave will write a proposal). The LWG and EWG had
9290 (separate) discussions of this plan the next day.  This paper resolves
9291 issues 225 and 226.  In light of that resolution, the proposed
9292 resolution for the current issue makes sense.]</i></p>
9293
9294
9295
9296
9297
9298
9299
9300 <hr>
9301 <h3><a name="230"></a>230. Assignable specified without also specifying CopyConstructible</h3>
9302 <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>
9303  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2000-04-26</p>
9304 <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>
9305 <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>
9306 <p><b>Discussion:</b></p>
9307 <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
9308 Assignable was specified without also specifying
9309 CopyConstructible. The LWG asked that the standard be searched to
9310 determine if the same defect existed elsewhere.</p>
9311
9312 <p>There are a number of places (see proposed resolution below) where
9313 Assignable is specified without also specifying
9314 CopyConstructible. There are also several cases where both are
9315 specified. For example, 26.4.1 [rand.req].</p>
9316
9317
9318 <p><b>Proposed resolution:</b></p>
9319 <p>In  23.1 [container.requirements] table 65 for value_type:
9320 change "T is Assignable" to "T is CopyConstructible and
9321 Assignable"
9322 </p>
9323
9324 <p>In 23.1.2 [associative.reqmts] table 69 X::key_type; change
9325 "Key is Assignable" to "Key is
9326 CopyConstructible and Assignable"<br>
9327 </p>
9328
9329 <p>In 24.1.2 [output.iterators] paragraph 1, change:
9330 </p>
9331 <blockquote>
9332 <p> A class or a built-in type X satisfies the requirements of an
9333 output iterator if X is an Assignable type (23.1) and also the
9334 following expressions are valid, as shown in Table 73:
9335 </p>
9336 </blockquote>
9337 <p>to:
9338 </p>
9339 <blockquote>
9340 <p> A class or a built-in type X satisfies the requirements of an
9341 output iterator if X is a CopyConstructible (20.1.3) and Assignable
9342 type (23.1) and also the following expressions are valid, as shown in
9343 Table 73:
9344 </p>
9345 </blockquote>
9346
9347 <p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
9348 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
9349 CopyConstructible is really a requirement and may be
9350 overspecification.]</i></p>
9351
9352
9353 <p><i>[Portions of the resolution for issue 230 have been superceded by
9354 the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.]</i></p>
9355
9356
9357
9358
9359 <p><b>Rationale:</b></p>
9360 <p>The original proposed resolution also included changes to input
9361 iterator, fill, and replace.  The LWG believes that those changes are
9362 not necessary.  The LWG considered some blanket statement, where an
9363 Assignable type was also required to be Copy Constructible, but
9364 decided against this because fill and replace really don't require the
9365 Copy Constructible property.</p>
9366
9367
9368
9369
9370 <hr>
9371 <h3><a name="231"></a>231. Precision in iostream?</h3>
9372 <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>
9373  <b>Submitter:</b> James Kanze, Stephen Clamage <b>Date:</b> 2000-04-25</p>
9374 <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>
9375 <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>
9376 <p><b>Discussion:</b></p>
9377 <p>What is the following program supposed to output?</p>
9378 <pre>#include &lt;iostream&gt;
9379
9380     int
9381     main()
9382     {
9383         std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
9384         std::cout.precision( 0 ) ;
9385         std::cout &lt;&lt; 1.00 &lt;&lt; '\n' ;
9386         return 0 ;
9387     }</pre>
9388 <p>From my C experience, I would expect "1e+00"; this is what
9389 <tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs
9390 "1.000000e+00".</p>
9391
9392 <p>The only indication I can find in the standard is 22.2.2.2.2/11,
9393 where it says "For conversion from a floating-point type, if
9394 (flags &amp; fixed) != 0 or if str.precision() &gt; 0, then
9395 str.precision() is specified in the conversion specification."
9396 This is an obvious error, however, fixed is not a mask for a field,
9397 but a value that a multi-bit field may take -- the results of and'ing
9398 fmtflags with ios::fixed are not defined, at least not if
9399 ios::scientific has been set. G++'s behavior corresponds to what might
9400 happen if you do use (flags &amp; fixed) != 0 with a typical
9401 implementation (floatfield == 3 &lt;&lt; something, fixed == 1
9402 &lt;&lt; something, and scientific == 2 &lt;&lt; something).</p>
9403
9404 <p>Presumably, the intent is either (flags &amp; floatfield) != 0, or
9405 (flags &amp; floatfield) == fixed; the first gives something more or
9406 less like the effect of precision in a printf floating point
9407 conversion. Only more or less, of course. In order to implement printf
9408 formatting correctly, you must know whether the precision was
9409 explicitly set or not. Say by initializing it to -1, instead of 6, and
9410 stating that for floating point conversions, if precision &lt; -1, 6
9411 will be used, for fixed point, if precision &lt; -1, 1 will be used,
9412 etc. Plus, of course, if precision == 0 and flags &amp; floatfield ==
9413 0, 1 should be = used. But it probably isn't necessary to emulate all
9414 of the anomalies of printf:-).</p>
9415
9416
9417 <p><b>Proposed resolution:</b></p>
9418 <p>
9419 Replace 22.2.2.2.2 [facet.num.put.virtuals], paragraph 11, with the following
9420 sentence:
9421 </p>
9422 <blockquote><p>
9423 For conversion from a floating-point type,
9424 <tt><i>str</i>.precision()</tt> is specified in the conversion
9425 specification.
9426 </p></blockquote>
9427
9428
9429 <p><b>Rationale:</b></p>
9430 <p>The floatfield determines whether numbers are formatted as if
9431 with %f, %e, or %g.  If the <tt>fixed</tt> bit is set, it's %f,
9432 if <tt>scientific</tt> it's %e, and if both bits are set, or
9433 neither, it's %g.</p>
9434 <p>Turning to the C standard, a precision of 0 is meaningful
9435 for %f and %e.  For %g, precision 0 is taken to be the same as
9436 precision 1.</p>
9437 <p>The proposed resolution has the effect that if neither
9438 <tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
9439 specifying a precision of 0, which will be internally
9440 turned into 1.  There's no need to call it out as a special
9441 case.</p>
9442 <p>The output of the above program will be "1e+00".</p>
9443
9444 <p><i>[Post-Curaçao: Howard provided improved wording covering the case
9445 where precision is 0 and mode is %g.]</i></p>
9446
9447
9448
9449
9450
9451
9452
9453 <hr>
9454 <h3><a name="232"></a>232. "depends" poorly defined in 17.4.3.1</h3>
9455 <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>
9456  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2000-04-18</p>
9457 <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>
9458 <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>
9459 <p><b>Discussion:</b></p>
9460 <p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
9461 specializations of standard templates to those that "depend on a
9462 user-defined name of external linkage."</p>
9463 <p>This term, however, is not adequately defined, making it possible to
9464 construct a specialization that is, I believe, technically legal according to
9465 17.4.3.1/1, but that specializes a standard template for a built-in type such as
9466 'int'.</p>
9467 <p>The following code demonstrates the problem:</p>
9468 <blockquote>
9469   <pre>#include &lt;algorithm&gt;</pre>
9470   <pre>template&lt;class T&gt; struct X
9471 {
9472  typedef T type;
9473 };</pre>
9474   <pre>namespace std
9475 {
9476  template&lt;&gt; void swap(::X&lt;int&gt;::type&amp; i, ::X&lt;int&gt;::type&amp; j);
9477 }</pre>
9478 </blockquote>
9479
9480
9481 <p><b>Proposed resolution:</b></p>
9482 <p>Change "user-defined name" to "user-defined
9483 type".</p>
9484
9485
9486 <p><b>Rationale:</b></p>
9487 <p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
9488 Programming Language</i>.  It disallows the example in the issue,
9489 since the underlying type itself is not user-defined.  The only
9490 possible problem I can see is for non-type templates, but there's no
9491 possible way for a user to come up with a specialization for bitset,
9492 for example, that might not have already been specialized by the
9493 implementor?</p>
9494
9495 <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>
9496
9497
9498 <p><i>[post-Toronto: Judy provided the above proposed resolution and
9499 rationale.]</i></p>
9500
9501
9502
9503
9504
9505
9506 <hr>
9507 <h3><a name="233"></a>233. Insertion hints in associative containers</h3>
9508 <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>
9509  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-04-30</p>
9510 <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>
9511 <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>
9512 <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>
9513 <p><b>Discussion:</b></p>
9514 <p>
9515 If <tt>mm</tt> is a multimap and <tt>p</tt> is an iterator
9516 into the multimap, then <tt>mm.insert(p, x)</tt> inserts
9517 <tt>x</tt> into <tt>mm</tt> with <tt>p</tt> as a hint as
9518 to where it should go.  Table 69 claims that the execution time is
9519 amortized constant if the insert winds up taking place adjacent to
9520 <tt>p</tt>, but does not say when, if ever, this is guaranteed to
9521 happen.  All it says it that <tt>p</tt> is a hint as to where to
9522 insert.
9523 </p>
9524 <p>
9525 The question is whether there is any guarantee about the relationship
9526 between <tt>p</tt> and the insertion point, and, if so, what it
9527 is.
9528 </p>
9529 <p>
9530 I believe the present state is that there is no guarantee: The user
9531 can supply <tt>p</tt>, and the implementation is allowed to
9532 disregard it entirely.
9533 </p>
9534
9535 <p><b>Additional comments from Nathan:</b><br>
9536
9537 The vote [in Redmond] was on whether to elaborately specify the use of
9538 the hint, or to require behavior only if the value could be inserted
9539 adjacent to the hint.  I would like to ensure that we have a chance to
9540 vote for a deterministic treatment: "before, if possible, otherwise
9541 after, otherwise anywhere appropriate", as an alternative to the
9542 proposed "before or after, if possible, otherwise [...]".
9543 </p>
9544
9545 <p><i>[Toronto: there was general agreement that this is a real defect:
9546 when inserting an element x into a multiset that already contains
9547 several copies of x, there is no way to know whether the hint will be
9548 used.  The proposed resolution was that the new element should always
9549 be inserted as close to the hint as possible.  So, for example, if
9550 there is a subsequence of equivalent values, then providing a.begin()
9551 as the hint means that the new element should be inserted before the
9552 subsequence even if a.begin() is far away.  JC van Winkel supplied
9553 precise wording for this proposed resolution, and also for an
9554 alternative resolution in which hints are only used when they are
9555 adjacent to the insertion point.]</i></p>
9556
9557
9558 <p><i>[Copenhagen: the LWG agreed to the original proposed resolution,
9559 in which an insertion hint would be used even when it is far from the
9560 insertion point.  This was contingent on seeing a reference
9561 implementation showing that it is possible to implement this
9562 requirement without loss of efficiency.  John Potter provided such a
9563 reference implementation.]</i></p>
9564
9565
9566 <p><i>[Redmond: The LWG was reluctant to adopt the proposal that
9567 emerged from Copenhagen: it seemed excessively complicated, and went
9568 beyond fixing the defect that we identified in Toronto.  PJP provided
9569 the new wording described in this issue.  Nathan agrees that we
9570 shouldn't adopt the more detailed semantics, and notes: "we know that
9571 you can do it efficiently enough with a red-black tree, but there are
9572 other (perhaps better) balanced tree techniques that might differ
9573 enough to make the detailed semantics hard to satisfy."]</i></p>
9574
9575
9576 <p><i>[Curaçao: Nathan should give us the alternative wording he
9577 suggests so the LWG can decide between the two options.]</i></p>
9578
9579
9580 <p><i>[Lillehammer: The LWG previously rejected the more detailed
9581   semantics, because it seemed more loike a new feature than like
9582   defect fixing.  We're now more sympathetic to it, but we (especially
9583   Bill) are still worried about performance.  N1780 describes a naive
9584   algorithm, but it's not clear whether there is a non-naive
9585   implementation. Is it possible to implement this as efficently as
9586   the current version of insert?]</i></p>
9587
9588
9589 <p><i>[Post Lillehammer:
9590 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">N1780</a>
9591 updated in post meeting mailing with
9592 feedback from Lillehammer with more information regarding performance.
9593 ]</i></p>
9594
9595
9596 <p><i>[
9597 Batavia:
9598 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>
9599 accepted with minor wording changes in the proposed wording (reflected in the
9600 proposed resolution below).  Concerns about the performance of the algorithm
9601 were satisfactorily met by
9602 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>.
9603 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a> already handles the stability of equal ranges
9604 and so that part of the resolution from
9605 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>
9606 is no longer needed (or reflected in the proposed wording below).
9607 ]</i></p>
9608
9609
9610
9611
9612 <p><b>Proposed resolution:</b></p>
9613
9614 <p>
9615 Change the indicated rows of the "Associative container requirements" Table in
9616 23.1.2 [associative.reqmts] to:
9617 </p>
9618
9619 <p></p><center>
9620 <table border="1">
9621 <caption>Associative container requirements</caption>
9622 <tbody><tr><th>expression</th> <th>return type</th>
9623 <th>assertion/note<br>pre/post-condition</th>
9624 <th>complexity</th></tr>
9625 <tr><td><tt>a_eq.insert(t)</tt></td>
9626 <td><tt>iterator</tt></td>
9627 <td>
9628 inserts <tt>t</tt> and returns the iterator pointing to the newly inserted
9629 element. <ins>If a range containing elements equivalent to <tt>t</tt> exists in
9630 <tt>a_eq</tt>, <tt>t</tt> is inserted at the end of that range.</ins>
9631 </td>
9632 <td>
9633 logarithmic
9634 </td></tr>
9635 <tr><td><tt>a.insert(p,t)</tt></td>
9636 <td><tt>iterator</tt></td>
9637 <td>
9638 inserts <tt>t</tt> if and only if there is no element with key equivalent to the
9639 key of <tt>t</tt> in containers with unique keys; always inserts <tt>t</tt> in containers
9640 with equivalent keys. always returns the iterator pointing to the element with key
9641 equivalent to the key of <tt>t</tt>. <del>iterator <tt>p</tt> is a hint pointing to where
9642 the insert should start to search.</del> <ins><tt>t</tt> is inserted as close as possible
9643 to the position just prior to <tt>p</tt>.</ins>
9644 </td>
9645 <td>
9646 logarithmic in general, but amortized constant if <tt>t</tt> is inserted right <del>after</del>
9647  <ins>before</ins> <tt>p</tt>.
9648 </td></tr>
9649 </tbody></table>
9650 </center>
9651
9652
9653
9654
9655
9656
9657 <hr>
9658 <h3><a name="234"></a>234. Typos in allocator definition</h3>
9659 <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>
9660  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p>
9661 <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>
9662 <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>
9663 <p><b>Discussion:</b></p>
9664 <p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
9665 <tt>destruct()</tt> are described as returns but the functions actually
9666 return <tt>void</tt>.</p>
9667
9668
9669 <p><b>Proposed resolution:</b></p>
9670 <p>Substitute "Returns" by "Effect".</p>
9671
9672
9673
9674
9675 <hr>
9676 <h3><a name="235"></a>235. No specification of default ctor for reverse_iterator</h3>
9677 <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>
9678  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p>
9679 <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>
9680 <p><b>Discussion:</b></p>
9681 <p>The declaration of <tt>reverse_iterator</tt> lists a default
9682 constructor.  However, no specification is given what this constructor
9683 should do.</p>
9684
9685
9686 <p><b>Proposed resolution:</b></p>
9687   <p>In section 24.4.1.3.1 [reverse.iter.cons] add the following
9688   paragraph:</p>
9689       <blockquote>
9690       <p><tt>reverse_iterator()</tt></p>
9691
9692       <p>Default initializes <tt>current</tt>. Iterator operations
9693       applied to the resulting iterator have defined behavior if and
9694       only if the corresponding operations are defined on a default
9695       constructed iterator of type <tt>Iterator</tt>.</p>
9696       </blockquote>
9697   <p><i>[pre-Copenhagen: Dietmar provide wording for proposed
9698   resolution.]</i></p>
9699
9700
9701
9702
9703
9704
9705 <hr>
9706 <h3><a name="237"></a>237. Undefined expression in complexity specification</h3>
9707 <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>
9708  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p>
9709 <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>
9710 <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>
9711 <p><b>Discussion:</b></p>
9712 <p>The complexity specification in paragraph 6 says that the complexity
9713 is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
9714 defined on iterators this term is in general undefined because it
9715 would have to be <tt>last - first</tt>.</p>
9716
9717
9718 <p><b>Proposed resolution:</b></p>
9719   <p>Change paragraph 6 from</p>
9720      <blockquote><p>Linear in <i>first - last</i>.</p></blockquote>
9721   <p>to become</p>
9722      <blockquote><p>Linear in <i>distance(first, last)</i>.</p></blockquote>
9723
9724
9725
9726
9727 <hr>
9728 <h3><a name="238"></a>238. Contradictory results of stringbuf initialization.</h3>
9729 <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>
9730  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-05-11</p>
9731 <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>
9732 <p><b>Discussion:</b></p>
9733 <p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
9734 'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
9735 that far but consider this code:</p>
9736
9737 <pre>  std::basic_stringbuf&lt;char&gt; sbuf("hello, world", std::ios_base::openmode(0));
9738   std::cout &lt;&lt; "'" &lt;&lt; sbuf.str() &lt;&lt; "'\n";
9739 </pre>
9740
9741 <p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
9742 the output sequence nor the input sequence is initialized and
9743 paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
9744 returns the input or the output sequence. None of them is initialized,
9745 ie. both are empty, in which case the return from <tt>str()</tt> is
9746 defined to be <tt>basic_string&lt;cT&gt;()</tt>.</p>
9747
9748 <p>However, probably only test cases in some testsuites will detect this
9749 "problem"...</p>
9750
9751
9752 <p><b>Proposed resolution:</b></p>
9753 <p>Remove 27.7.1.1 paragraph 4.</p>
9754
9755
9756 <p><b>Rationale:</b></p>
9757 <p>We could fix 27.7.1.1 paragraph 4, but there would be no point.  If
9758 we fixed it, it would say just the same thing as text that's already
9759 in the standard.</p>
9760
9761
9762
9763
9764 <hr>
9765 <h3><a name="239"></a>239. Complexity of unique() and/or unique_copy incorrect</h3>
9766 <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>
9767  <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
9768 <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>
9769 <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>
9770 <p><b>Discussion:</b></p>
9771 <p>The complexity of unique and unique_copy are inconsistent with each
9772 other and inconsistent with the implementations.&nbsp; The standard
9773 specifies:</p>
9774
9775 <p>for unique():</p>
9776
9777 <blockquote><p>-3- Complexity: If the range (last - first) is not empty, exactly
9778 (last - first) - 1 applications of the corresponding predicate, otherwise
9779 no applications of the predicate.</p></blockquote>
9780
9781 <p>for unique_copy():</p>
9782
9783 <blockquote><p>-7- Complexity: Exactly last - first applications of the corresponding
9784 predicate.</p></blockquote>
9785
9786 <p>
9787 The implementations do it the other way round: unique() applies the
9788 predicate last-first times and unique_copy() applies it last-first-1
9789 times.</p>
9790
9791 <p>As both algorithms use the predicate for pair-wise comparison of
9792 sequence elements I don't see a justification for unique_copy()
9793 applying the predicate last-first times, especially since it is not
9794 specified to which pair in the sequence the predicate is applied
9795 twice.</p>
9796
9797
9798 <p><b>Proposed resolution:</b></p>
9799 <p>Change both complexity sections in 25.2.9 [alg.unique] to:</p>
9800
9801 <blockquote><p>Complexity: For nonempty ranges, exactly last - first - 1
9802 applications of the corresponding predicate.</p></blockquote>
9803
9804
9805
9806
9807
9808
9809 <hr>
9810 <h3><a name="240"></a>240. Complexity of adjacent_find() is meaningless</h3>
9811 <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>
9812  <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
9813 <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>
9814 <p><b>Discussion:</b></p>
9815 <p>The complexity section of adjacent_find is defective:</p>
9816
9817 <blockquote>
9818 <pre>template &lt;class ForwardIterator&gt;
9819 ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
9820                               BinaryPredicate pred);
9821 </pre>
9822
9823 <p>-1- Returns: The first iterator i such that both i and i + 1 are in
9824 the range [first, last) for which the following corresponding
9825 conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
9826 last if no such iterator is found.</p>
9827
9828 <p>-2- Complexity: Exactly find(first, last, value) - first applications
9829 of the corresponding predicate.
9830 </p>
9831 </blockquote>
9832
9833 <p>In the Complexity section, it is not defined what "value"
9834 is supposed to mean. My best guess is that "value" means an
9835 object for which one of the conditions pred(*i,value) or
9836 pred(value,*i) is true, where i is the iterator defined in the Returns
9837 section. However, the value type of the input sequence need not be
9838 equality-comparable and for this reason the term find(first, last,
9839 value) - first is meaningless.</p>
9840
9841 <p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
9842 find_if(first, last, bind1st(pred,*i)) - first might come closer to
9843 the intended specification.  Binders can only be applied to function
9844 objects that have the function call operator declared const, which is
9845 not required of predicates because they can have non-const data
9846 members. For this reason, a specification using a binder could only be
9847 an "as-if" specification.</p>
9848
9849
9850 <p><b>Proposed resolution:</b></p>
9851 <p>Change the complexity section in 25.1.5 [alg.adjacent.find] to:</p>
9852 <blockquote><p>
9853 For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
9854 (<i>last</i> - <i>first</i>) - 1)</tt> applications of the
9855 corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
9856 return value.
9857 </p></blockquote>
9858
9859 <p><i>[Copenhagen: the original resolution specified an upper
9860 bound.  The LWG preferred an exact count.]</i></p>
9861
9862
9863
9864
9865
9866
9867
9868 <hr>
9869 <h3><a name="241"></a>241. Does unique_copy() require CopyConstructible and Assignable?</h3>
9870 <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>
9871  <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
9872 <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>
9873 <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>
9874 <p><b>Discussion:</b></p>
9875
9876 <p>Some popular implementations of unique_copy() create temporary
9877 copies of values in the input sequence, at least if the input iterator
9878 is a pointer.  Such an implementation is built on the assumption that
9879 the value type is CopyConstructible and Assignable.</p>
9880
9881 <p>It is common practice in the standard that algorithms explicitly
9882 specify any additional requirements that they impose on any of the
9883 types used by the algorithm. An example of an algorithm that creates
9884 temporary copies and correctly specifies the additional requirements
9885 is accumulate(), 26.4.1 [rand.req].</p>
9886
9887 <p>Since the specifications of unique() and unique_copy() do not
9888 require CopyConstructible and Assignable of the InputIterator's value
9889 type the above mentioned implementations are not standard-compliant. I
9890 cannot judge whether this is a defect in the standard or a defect in
9891 the implementations.</p>
9892
9893
9894 <p><b>Proposed resolution:</b></p>
9895 <p>In 25.2.8 change:</p>
9896
9897 <blockquote><p>
9898 -4- Requires: The ranges [first, last) and [result, result+(last-first))
9899 shall not overlap.
9900 </p></blockquote>
9901
9902 <p>to:</p>
9903
9904 <blockquote>
9905   <p>-4- Requires: The ranges [first, last) and [result,
9906   result+(last-first)) shall not overlap. The expression *result =
9907   *first must be valid. If neither InputIterator nor OutputIterator
9908   meets the requirements of forward iterator then the value type of
9909   InputIterator must be copy constructible. Otherwise copy
9910   constructible is not required. </p>
9911 </blockquote>
9912
9913 <p><i>[Redmond: the original proposed resolution didn't impose an
9914 explicit requirement that the iterator's value type must be copy
9915 constructible, on the grounds that an input iterator's value type must
9916 always be copy constructible.  Not everyone in the LWG thought that
9917 this requirement was clear from table 72.  It has been suggested that
9918 it might be possible to implement <tt>unique_copy</tt> without
9919 requiring assignability, although current implementations do impose
9920 that requirement.  Howard provided new wording.]</i></p>
9921
9922
9923 <p><i>[
9924 Curaçao: The LWG changed the PR editorially to specify
9925 "neither...nor...meet..." as clearer than
9926 "both...and...do not meet...". Change believed to be so
9927 minor as not to require re-review.
9928 ]</i></p>
9929
9930
9931
9932
9933
9934
9935
9936
9937 <hr>
9938 <h3><a name="242"></a>242. Side effects of function objects</h3>
9939 <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>
9940  <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
9941 <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>
9942 <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>
9943 <p><b>Discussion:</b></p>
9944 <p>The algorithms transform(), accumulate(), inner_product(),
9945 partial_sum(), and adjacent_difference() require that the function
9946 object supplied to them shall not have any side effects.</p>
9947
9948 <p>The standard defines a side effect in 1.9 [intro.execution] as:</p>
9949 <blockquote><p>-7- Accessing an object designated by a volatile lvalue (basic.lval),
9950 modifying an object, calling a library I/O function, or calling a function
9951 that does any of those operations are all side effects, which are changes
9952 in the state of the execution environment.</p></blockquote>
9953
9954 <p>As a consequence, the function call operator of a function object supplied
9955 to any of the algorithms listed above cannot modify data members, cannot
9956 invoke any function that has a side effect, and cannot even create and
9957 modify temporary objects.&nbsp; It is difficult to imagine a function object
9958 that is still useful under these severe limitations. For instance, any
9959 non-trivial transformator supplied to transform() might involve creation
9960 and modification of temporaries, which is prohibited according to the current
9961 wording of the standard.</p>
9962
9963 <p>On the other hand, popular implementations of these algorithms exhibit
9964 uniform and predictable behavior when invoked with a side-effect-producing
9965 function objects. It looks like the strong requirement is not needed for
9966 efficient implementation of these algorithms.</p>
9967
9968 <p>The requirement of&nbsp; side-effect-free function objects could be
9969 replaced by a more relaxed basic requirement (which would hold for all
9970 function objects supplied to any algorithm in the standard library):</p>
9971 <blockquote><p>A function objects supplied to an algorithm shall not invalidate
9972 any iterator or sequence that is used by the algorithm. Invalidation of
9973 the sequence includes destruction of the sorting order if the algorithm
9974 relies on the sorting order (see section 25.3 - Sorting and related operations
9975 [lib.alg.sorting]).</p></blockquote>
9976
9977 <p>I can't judge whether it is intended that the function objects supplied
9978 to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
9979 shall not modify sequence elements through dereferenced iterators.</p>
9980
9981 <p>It is debatable whether this issue is a defect or a change request.
9982 Since the consequences for user-supplied function objects are drastic and
9983 limit the usefulness of the algorithms significantly I would consider it
9984 a defect.</p>
9985
9986
9987 <p><b>Proposed resolution:</b></p>
9988
9989 <p><i>Things to notice about these changes:</i></p>
9990
9991 <ol>
9992 <li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
9993      are intentional. we want to prevent side-effects from
9994      invalidating the end iterators.</i></li>
9995
9996 <li> <i>That has the unintentional side-effect of prohibiting
9997      modification of the end element as a side-effect. This could
9998      conceivably be significant in some cases.</i></li>
9999
10000 <li> <i>The wording also prevents side-effects from modifying elements
10001      of the output sequence. I can't imagine why anyone would want
10002      to do this, but it is arguably a restriction that implementors
10003      don't need to place on users.</i></li>
10004
10005 <li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
10006      and simple, but would require more verbiage.</i></li>
10007 </ol>
10008
10009 <p>Change 25.2.3/2 from:</p>
10010
10011 <blockquote><p>
10012    -2- Requires: op and binary_op shall not have any side effects.
10013 </p></blockquote>
10014
10015 <p>to:</p>
10016
10017 <blockquote><p>
10018   -2- Requires: in the ranges [first1, last1], [first2, first2 +
10019   (last1 - first1)] and [result, result + (last1- first1)], op and
10020   binary_op shall neither modify elements nor invalidate iterators or
10021   subranges.
10022   [Footnote: The use of fully closed ranges is intentional --end footnote]
10023 </p></blockquote>
10024
10025
10026 <p>Change 25.2.3/2 from:</p>
10027
10028 <blockquote><p>
10029    -2- Requires: op and binary_op shall not have any side effects.
10030 </p></blockquote>
10031
10032 <p>to:</p>
10033
10034 <blockquote><p>
10035   -2- Requires: op and binary_op shall not invalidate iterators or
10036    subranges, or modify elements in the ranges [first1, last1],
10037    [first2, first2 + (last1 - first1)], and [result, result + (last1
10038    - first1)].
10039   [Footnote: The use of fully closed ranges is intentional --end footnote]
10040 </p></blockquote>
10041
10042
10043 <p>Change 26.4.1/2 from:</p>
10044
10045 <blockquote><p>
10046   -2- Requires: T must meet the requirements of CopyConstructible
10047    (lib.copyconstructible) and Assignable (lib.container.requirements)
10048    types. binary_op shall not cause side effects.
10049 </p></blockquote>
10050
10051 <p>to:</p>
10052
10053 <blockquote><p>
10054   -2- Requires: T must meet the requirements of CopyConstructible
10055    (lib.copyconstructible) and Assignable
10056    (lib.container.requirements) types. In the range [first, last],
10057    binary_op shall neither modify elements nor invalidate iterators
10058    or subranges.
10059   [Footnote: The use of a fully closed range is intentional --end footnote]
10060 </p></blockquote>
10061
10062 <p>Change 26.4.2/2 from:</p>
10063
10064 <blockquote><p>
10065   -2- Requires: T must meet the requirements of CopyConstructible
10066    (lib.copyconstructible) and Assignable (lib.container.requirements)
10067    types. binary_op1 and binary_op2 shall not cause side effects.
10068 </p></blockquote>
10069
10070 <p>to:</p>
10071
10072 <blockquote><p>
10073   -2- Requires: T must meet the requirements of CopyConstructible
10074    (lib.copyconstructible) and Assignable (lib.container.requirements)
10075    types. In the ranges [first, last] and [first2, first2 + (last -
10076    first)], binary_op1 and binary_op2 shall neither modify elements
10077    nor invalidate iterators or subranges.
10078   [Footnote: The use of fully closed ranges is intentional --end footnote]
10079 </p></blockquote>
10080
10081
10082 <p>Change 26.4.3/4 from:</p>
10083
10084 <blockquote><p>
10085   -4- Requires: binary_op is expected not to have any side effects.
10086 </p></blockquote>
10087
10088 <p>to:</p>
10089
10090 <blockquote><p>
10091   -4- Requires: In the ranges [first, last] and [result, result +
10092    (last - first)], binary_op shall neither modify elements nor
10093    invalidate iterators or subranges.
10094   [Footnote: The use of fully closed ranges is intentional --end footnote]
10095 </p></blockquote>
10096
10097 <p>Change 26.4.4/2 from:</p>
10098
10099 <blockquote><p>
10100   -2- Requires: binary_op shall not have any side effects.
10101 </p></blockquote>
10102
10103 <p>to:</p>
10104
10105 <blockquote><p>
10106   -2- Requires: In the ranges [first, last] and [result, result +
10107    (last - first)], binary_op shall neither modify elements nor
10108    invalidate iterators or subranges.
10109   [Footnote: The use of fully closed ranges is intentional --end footnote]
10110 </p></blockquote>
10111
10112 <p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
10113
10114
10115 <p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
10116 added footnotes pointing out that the use of closed ranges was
10117 intentional.]</i></p>
10118
10119
10120
10121
10122
10123
10124
10125 <hr>
10126 <h3><a name="243"></a>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3>
10127 <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>
10128  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-05-15</p>
10129 <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>
10130 <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>
10131 <p><b>Discussion:</b></p>
10132 <p>basic_istream&lt;&gt;::get(), and basic_istream&lt;&gt;::getline(),
10133 are unclear with respect to the behavior and side-effects of the named
10134 functions in case of an error.</p>
10135
10136 <p>27.6.1.3, p1 states that "... If the sentry object returns
10137 true, when converted to a value of type bool, the function endeavors
10138 to obtain the requested input..." It is not clear from this (or
10139 the rest of the paragraph) what precisely the behavior should be when
10140 the sentry ctor exits by throwing an exception or when the sentry
10141 object returns false.  In particular, what is the number of characters
10142 extracted that gcount() returns supposed to be?</p>
10143
10144 <p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
10145 "...  In any case, it then stores a null character (using
10146 charT()) into the next successive location of the array." Is not
10147 clear whether this sentence applies if either of the conditions above
10148 holds (i.e., when sentry fails).</p>
10149
10150
10151 <p><b>Proposed resolution:</b></p>
10152 <p>Add to 27.6.1.3, p1 after the sentence</p>
10153
10154 <blockquote><p>
10155 "... If the sentry object returns true, when converted to a value of
10156 type bool, the function endeavors to obtain the requested input."
10157 </p></blockquote>
10158
10159 <p>the following</p>
10160
10161
10162 <blockquote><p>
10163 "Otherwise, if the sentry constructor exits by throwing an exception or
10164 if the sentry object returns false, when converted to a value of type
10165 bool, the function returns without attempting to obtain any input. In
10166 either case the number of extracted characters is set to 0; unformatted
10167 input functions taking a character array of non-zero size as an argument
10168 shall also store a null character (using charT()) in the first location
10169 of the array."
10170 </p></blockquote>
10171
10172
10173 <p><b>Rationale:</b></p>
10174 <p>Although the general philosophy of the input functions is that the
10175 argument should not be modified upon failure, <tt>getline</tt>
10176 historically added a terminating null unconditionally.  Most
10177 implementations still do that.  Earlier versions of the draft standard
10178 had language that made this an unambiguous requirement; those words
10179 were moved to a place where their context made them less clear.  See
10180 Jerry Schwarz's message c++std-lib-7618.</p>
10181
10182
10183
10184
10185 <hr>
10186 <h3><a name="247"></a>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3>
10187 <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>
10188  <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 2000-06-06</p>
10189 <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>
10190 <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>
10191 <p><b>Discussion:</b></p>
10192 <p>Paragraph 2 of 23.2.5.4 [vector.modifiers] describes the complexity
10193 of <tt>vector::insert</tt>:</p>
10194
10195    <blockquote><p>
10196    Complexity: If first and last are forward iterators, bidirectional
10197    iterators, or random access iterators, the complexity is linear in
10198    the number of elements in the range [first, last) plus the distance
10199    to the end of the vector. If they are input iterators, the complexity
10200    is proportional to the number of elements in the range [first, last)
10201    times the distance to the end of the vector.
10202    </p></blockquote>
10203
10204 <p>First, this fails to address the non-iterator forms of
10205 <tt>insert</tt>.</p>
10206
10207 <p>Second, the complexity for input iterators misses an edge case --
10208 it requires that an arbitrary number of elements can be added at
10209 the end of a <tt>vector</tt> in constant time.</p>
10210
10211 <p>I looked to see if <tt>deque</tt> had a similar problem, and was
10212 surprised to find that <tt>deque</tt> places no requirement on the
10213 complexity of inserting multiple elements (23.2.2.3 [deque.modifiers],
10214 paragraph 3):</p>
10215
10216    <blockquote><p>
10217    Complexity: In the worst case, inserting a single element into a
10218    deque takes time linear in the minimum of the distance from the
10219    insertion point to the beginning of the deque and the distance
10220    from the insertion point to the end of the deque. Inserting a
10221    single element either at the beginning or end of a deque always
10222    takes constant time and causes a single call to the copy constructor
10223    of T.
10224    </p></blockquote>
10225
10226
10227 <p><b>Proposed resolution:</b></p>
10228
10229 <p>Change Paragraph 2 of 23.2.5.4 [vector.modifiers] to</p>
10230    <blockquote><p>
10231    Complexity: The complexity is linear in the number of elements
10232    inserted plus the distance to the end of the vector.
10233    </p></blockquote>
10234
10235    <p><i>[For input iterators, one may achieve this complexity by first
10236    inserting at the end of the <tt>vector</tt>, and then using
10237    <tt>rotate</tt>.]</i></p>
10238
10239
10240 <p>Change 23.2.2.3 [deque.modifiers], paragraph 3, to:</p>
10241
10242    <blockquote><p>
10243    Complexity: The complexity is linear in the number of elements
10244    inserted plus the shorter of the distances to the beginning and
10245    end of the deque.  Inserting a single element at either the
10246    beginning or the end of a deque causes a single call to the copy
10247    constructor of T.
10248    </p></blockquote>
10249
10250
10251
10252 <p><b>Rationale:</b></p>
10253 <p>This is a real defect, and proposed resolution fixes it: some
10254   complexities aren't specified that should be.  This proposed
10255   resolution does constrain deque implementations (it rules out the
10256   most naive possible implementations), but the LWG doesn't see a
10257   reason to permit that implementation.</p>
10258
10259
10260
10261
10262
10263 <hr>
10264 <h3><a name="248"></a>248. time_get fails to set eofbit</h3>
10265 <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>
10266  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-06-22</p>
10267 <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>
10268 <p><b>Discussion:</b></p>
10269 <p>There is no requirement that any of time_get member functions set
10270 ios::eofbit when they reach the end iterator while parsing their input.
10271 Since members of both the num_get and money_get facets are required to
10272 do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
10273 should follow the same requirement for consistency.</p>
10274
10275
10276 <p><b>Proposed resolution:</b></p>
10277 <p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
10278
10279 <blockquote><p>
10280 If the end iterator is reached during parsing by any of the get()
10281 member functions, the member sets ios_base::eofbit in err.
10282 </p></blockquote>
10283
10284
10285 <p><b>Rationale:</b></p>
10286 <p>Two alternative resolutions were proposed.  The LWG chose this one
10287 because it was more consistent with the way eof is described for other
10288 input facets.</p>
10289
10290
10291
10292
10293 <hr>
10294 <h3><a name="250"></a>250. splicing invalidates iterators</h3>
10295 <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>
10296  <b>Submitter:</b> Brian Parker  <b>Date:</b> 2000-07-14</p>
10297 <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>
10298 <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>
10299 <p><b>Discussion:</b></p>
10300 <p>
10301 Section 23.2.3.4 [list.ops] states that
10302 </p>
10303 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
10304 </pre>
10305 <p>
10306 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
10307 </p>
10308
10309 <p>
10310 This is unnecessary and defeats an important feature of splice. In
10311 fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
10312 after <tt>splice</tt>.
10313 </p>
10314
10315
10316 <p><b>Proposed resolution:</b></p>
10317
10318 <p>Add a footnote to 23.2.3.4 [list.ops], paragraph 1:</p>
10319 <blockquote><p>
10320 [<i>Footnote:</i> As specified in  [default.con.req], paragraphs
10321 4-5, the semantics described in this clause applies only to the case
10322 where allocators compare equal.  --end footnote]
10323 </p></blockquote>
10324
10325 <p>In 23.2.3.4 [list.ops], replace paragraph 4 with:</p>
10326 <blockquote><p>
10327 Effects: Inserts the contents of x before position and x becomes
10328 empty.  Pointers and references to the moved elements of x now refer to
10329 those same elements but as members of *this.  Iterators referring to the
10330 moved elements will continue to refer to their elements, but they now
10331 behave as iterators into *this, not into x.
10332 </p></blockquote>
10333
10334 <p>In 23.2.3.4 [list.ops], replace paragraph 7 with:</p>
10335 <blockquote><p>
10336 Effects: Inserts an element pointed to by i from list x before
10337 position and removes the element from x. The result is unchanged if
10338 position == i or position == ++i.  Pointers and references to *i continue
10339 to refer to this same element but as a member of *this.  Iterators to *i
10340 (including i itself) continue to refer to the same element, but now
10341 behave as iterators into *this, not into x.
10342 </p></blockquote>
10343
10344 <p>In 23.2.3.4 [list.ops], replace paragraph 12 with:</p>
10345 <blockquote><p>
10346 Requires: [first, last) is a valid range in x. The result is
10347 undefined if position is an iterator in the range [first, last).
10348 Pointers and references to the moved elements of x now refer to those
10349 same elements but as members of *this.  Iterators referring to the moved
10350 elements will continue to refer to their elements, but they now behave as
10351 iterators into *this, not into x.
10352 </p></blockquote>
10353
10354 <p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
10355
10356
10357
10358 <p><b>Rationale:</b></p>
10359 <p>The original proposed resolution said that iterators and references
10360 would remain "valid".  The new proposed resolution clarifies what that
10361 means.  Note that this only applies to the case of equal allocators.
10362 From  [default.con.req] paragraph 4, the behavior of list when
10363 allocators compare nonequal is outside the scope of the standard.</p>
10364
10365
10366
10367
10368 <hr>
10369 <h3><a name="251"></a>251. basic_stringbuf missing allocator_type</h3>
10370 <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>
10371  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-07-28</p>
10372 <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>
10373 <p><b>Discussion:</b></p>
10374 <p>The synopsis for the template class <tt>basic_stringbuf</tt>
10375 doesn't list a typedef for the template parameter
10376 <tt>Allocator</tt>. This makes it impossible to determine the type of
10377 the allocator at compile time. It's also inconsistent with all other
10378 template classes in the library that do provide a typedef for the
10379 <tt>Allocator</tt> parameter.</p>
10380
10381
10382 <p><b>Proposed resolution:</b></p>
10383 <p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
10384 basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and
10385 basic_stringstream (27.7.4) the typedef:</p>
10386 <pre>  typedef Allocator allocator_type;
10387 </pre>
10388
10389
10390
10391
10392 <hr>
10393 <h3><a name="252"></a>252. missing casts/C-style casts used in iostreams</h3>
10394 <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>
10395  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-07-28</p>
10396 <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>
10397 <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>
10398 <p><b>Discussion:</b></p>
10399 <p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
10400 const_cast&lt;&gt; in the Returns clause for basic_istringstream&lt;&gt;::rdbuf().
10401 The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
10402 D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
10403 the cast altogether.</p>
10404
10405 <p>C-style casts have not been deprecated, so the first part of this
10406 issue is stylistic rather than a matter of correctness.</p>
10407
10408
10409 <p><b>Proposed resolution:</b></p>
10410 <p>In 27.7.2.2, p1 replace </p>
10411 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
10412
10413 <p>with</p>
10414 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
10415
10416
10417 <p>In 27.7.3.2, p1 replace</p>
10418 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
10419
10420 <p>with</p>
10421 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
10422
10423 <p>In 27.7.6, p1, replace</p>
10424 <pre>  -1- Returns: &amp;sb</pre>
10425
10426 <p>with</p>
10427 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
10428
10429 <p>In D.7.2.2, p1 replace</p>
10430 <pre>  -2- Returns: &amp;sb. </pre>
10431
10432 <p>with</p>
10433 <pre>  -2- Returns: const_cast&lt;strstreambuf*&gt;(&amp;sb).</pre>
10434
10435
10436
10437
10438 <hr>
10439 <h3><a name="253"></a>253. valarray helper functions are almost entirely useless</h3>
10440 <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>
10441  <b>Submitter:</b> Robert Klarer <b>Date:</b> 2000-07-31</p>
10442 <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>
10443 <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>
10444 <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>
10445 <p><b>Discussion:</b></p>
10446 <p>This discussion is adapted from message c++std-lib-7056 posted
10447 November 11, 1999.  I don't think that anyone can reasonably claim
10448 that the problem described below is NAD.</p>
10449
10450 <p>These valarray constructors can never be called:</p>
10451
10452 <pre>   template &lt;class T&gt;
10453          valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
10454    template &lt;class T&gt;
10455          valarray&lt;T&gt;::valarray(const gslice_array&lt;T&gt; &amp;);
10456    template &lt;class T&gt;
10457          valarray&lt;T&gt;::valarray(const mask_array&lt;T&gt; &amp;);
10458    template &lt;class T&gt;
10459          valarray&lt;T&gt;::valarray(const indirect_array&lt;T&gt; &amp;);
10460 </pre>
10461
10462 <p>Similarly, these valarray assignment operators cannot be
10463 called:</p>
10464
10465 <pre>     template &lt;class T&gt;
10466      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const slice_array&lt;T&gt; &amp;);
10467      template &lt;class T&gt;
10468      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const gslice_array&lt;T&gt; &amp;);
10469      template &lt;class T&gt;
10470      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const mask_array&lt;T&gt; &amp;);
10471      template &lt;class T&gt;
10472      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const indirect_array&lt;T&gt; &amp;);
10473 </pre>
10474
10475 <p>Please consider the following example:</p>
10476
10477 <pre>   #include &lt;valarray&gt;
10478    using namespace std;
10479
10480    int main()
10481    {
10482        valarray&lt;double&gt; va1(12);
10483        valarray&lt;double&gt; va2(va1[slice(1,4,3)]); // line 1
10484    }
10485 </pre>
10486
10487
10488 <p>Since the valarray va1 is non-const, the result of the sub-expression
10489 va1[slice(1,4,3)] at line 1 is an rvalue of type const
10490 std::slice_array&lt;double&gt;.  This slice_array rvalue is then used to
10491 construct va2.  The constructor that is used to construct va2 is
10492 declared like this:</p>
10493
10494 <pre>     template &lt;class T&gt;
10495      valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
10496 </pre>
10497
10498 <p>Notice the constructor's const reference parameter.  When the
10499 constructor is called, a slice_array must be bound to this reference.
10500 The rules for binding an rvalue to a const reference are in 8.5.3,
10501 paragraph 5 (see also 13.3.3.1.4).  Specifically, paragraph 5
10502 indicates that a second slice_array rvalue is constructed (in this
10503 case copy-constructed) from the first one; it is this second rvalue
10504 that is bound to the reference parameter.  Paragraph 5 also requires
10505 that the constructor that is used for this purpose be callable,
10506 regardless of whether the second rvalue is elided.  The
10507 copy-constructor in this case is not callable, however, because it is
10508 private.  Therefore, the compiler should report an error.</p>
10509
10510 <p>Since slice_arrays are always rvalues, the valarray constructor that has a
10511 parameter of type const slice_array&lt;T&gt; &amp; can never be called.  The
10512 same reasoning applies to the three other constructors and the four
10513 assignment operators that are listed at the beginning of this post.
10514 Furthermore, since these functions cannot be called, the valarray helper
10515 classes are almost entirely useless.</p>
10516
10517
10518 <p><b>Proposed resolution:</b></p>
10519 <p>slice_array:</p>
10520 <ul>
10521 <li> Make the copy constructor and copy-assignment operator declarations
10522      public in the slice_array class template definition in 26.5.5 [template.slice.array] </li>
10523 <li> remove paragraph 3 of 26.5.5 [template.slice.array]</li>
10524 <li> remove the copy constructor declaration from  [cons.slice.arr]</li>
10525 <li> change paragraph 1 of  [cons.slice.arr] to read "This constructor is declared
10526     to be private.  This constructor need not be defined."</li>
10527 <li> remove the first sentence of paragraph 1 of 26.5.5.1 [slice.arr.assign]</li>
10528 <li> Change the first three words of the second sentence of paragraph 1 of
10529     26.5.5.1 [slice.arr.assign] to "These assignment operators have"</li>
10530 </ul>
10531
10532 <p>gslice_array:</p>
10533 <ul>
10534 <li> Make the copy constructor and copy-assignment operator declarations
10535     public in the gslice_array class template definition in 26.5.7 [template.gslice.array] </li>
10536 <li> remove the note in paragraph 3 of 26.5.7 [template.gslice.array]</li>
10537 <li> remove the copy constructor declaration from  [gslice.array.cons]</li>
10538 <li> change paragraph 1 of  [gslice.array.cons] to read "This constructor is declared
10539     to be private.  This constructor need not be defined."</li>
10540 <li> remove the first sentence of paragraph 1 of 26.5.7.1 [gslice.array.assign]</li>
10541 <li> Change the first three words of the second sentence of paragraph 1 of
10542     26.5.7.1 [gslice.array.assign] to "These assignment operators have"</li>
10543 </ul>
10544
10545 <p>mask_array:</p>
10546 <ul>
10547 <li> Make the copy constructor and copy-assignment operator declarations
10548     public in the mask_array class template definition in 26.5.8 [template.mask.array] </li>
10549 <li> remove the note in paragraph 2 of 26.5.8 [template.mask.array]</li>
10550 <li> remove the copy constructor declaration from  [mask.array.cons]</li>
10551 <li> change paragraph 1 of  [mask.array.cons] to read "This constructor is declared
10552     to be private.  This constructor need not be defined."</li>
10553 <li> remove the first sentence of paragraph 1 of 26.5.8.1 [mask.array.assign]</li>
10554 <li> Change the first three words of the second sentence of paragraph 1 of
10555     26.5.8.1 [mask.array.assign] to "These assignment operators have"</li>
10556 </ul>
10557
10558 <p>indirect_array:</p>
10559 <ul>
10560 <li>Make the copy constructor and copy-assignment operator declarations
10561     public in the indirect_array class definition in 26.5.9 [template.indirect.array]</li>
10562 <li> remove the note in paragraph 2 of 26.5.9 [template.indirect.array]</li>
10563 <li> remove the copy constructor declaration from  [indirect.array.cons]</li>
10564 <li> change the descriptive text in  [indirect.array.cons] to read "This constructor is
10565     declared to be private.  This constructor need not be defined."</li>
10566 <li> remove the first sentence of paragraph 1 of 26.5.9.1 [indirect.array.assign]</li>
10567 <li> Change the first three words of the second sentence of paragraph 1 of
10568     26.5.9.1 [indirect.array.assign] to "These assignment operators have"</li>
10569 </ul>
10570 <p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
10571 copy constructor and copy assignment operators public, instead of
10572 removing them.]</i></p>
10573
10574
10575
10576 <p><b>Rationale:</b></p>
10577 <p>Keeping the valarray constructors private is untenable.  Merely
10578 making valarray a friend of the helper classes isn't good enough,
10579 because access to the copy constructor is checked in the user's
10580 environment.</p>
10581
10582 <p>Making the assignment operator public is not strictly necessary to
10583 solve this problem.  A majority of the LWG <i>(straw poll: 13-4)</i>
10584 believed we should make the assignment operators public, in addition
10585 to the copy constructors, for reasons of symmetry and user
10586 expectation.</p>
10587
10588
10589
10590
10591
10592 <hr>
10593 <h3><a name="254"></a>254. Exception types in clause 19 are constructed from <tt>std::string</tt></h3>
10594 <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>
10595  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-08-01</p>
10596 <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>
10597 <p><b>Discussion:</b></p>
10598 <p>
10599 Many of the standard exception types which implementations are
10600 required to throw are constructed with a const std::string&amp;
10601 parameter. For example:
10602 </p>
10603
10604 <pre>     19.1.5  Class out_of_range                          [lib.out.of.range]
10605      namespace std {
10606        class out_of_range : public logic_error {
10607        public:
10608          explicit out_of_range(const string&amp; what_arg);
10609        };
10610      }
10611
10612    1 The class out_of_range defines the type of objects  thrown  as  excep-
10613      tions to report an argument value not in its expected range.
10614
10615      out_of_range(const string&amp; what_arg);
10616
10617      Effects:
10618        Constructs an object of class out_of_range.
10619      Postcondition:
10620        strcmp(what(), what_arg.c_str()) == 0.
10621 </pre>
10622
10623 <p>
10624 There are at least two problems with this:
10625 </p>
10626 <ol>
10627 <li>A program which is low on memory may end up throwing
10628 std::bad_alloc instead of out_of_range because memory runs out while
10629 constructing the exception object.</li>
10630 <li>An obvious implementation which stores a std::string data member
10631 may end up invoking terminate() during exception unwinding because the
10632 exception object allocates memory (or rather fails to) as it is being
10633 copied.</li>
10634 </ol>
10635
10636 <p>
10637 There may be no cure for (1) other than changing the interface to
10638 out_of_range, though one could reasonably argue that (1) is not a
10639 defect. Personally I don't care that much if out-of-memory is reported
10640 when I only have 20 bytes left, in the case when out_of_range would
10641 have been reported. People who use exception-specifications might care
10642 a lot, though.
10643 </p>
10644
10645 <p>
10646 There is a cure for (2), but it isn't completely obvious. I think a
10647 note for implementors should be made in the standard. Avoiding
10648 possible termination in this case shouldn't be left up to chance.  The
10649 cure is to use a reference-counted "string" implementation
10650 in the exception object. I am not necessarily referring to a
10651 std::string here; any simple reference-counting scheme for a NTBS
10652 would do.
10653 </p>
10654
10655 <p><b>Further discussion, in email:</b></p>
10656
10657 <p>
10658 ...I'm not so concerned about (1). After all, a library implementation
10659 can add const char* constructors as an extension, and users don't
10660 <i>need</i> to avail themselves of the standard exceptions, though this is
10661 a lame position to be forced into.  FWIW, std::exception and
10662 std::bad_alloc don't require a temporary basic_string.
10663 </p>
10664
10665 <p>
10666 ...I don't think the fixed-size buffer is a solution to the problem,
10667 strictly speaking, because you can't satisfy the postcondition
10668 <br>
10669     <tt>&nbsp;&nbsp;strcmp(what(), what_arg.c_str()) == 0</tt>
10670 <br>
10671 For all values of what_arg (i.e. very long values). That means that
10672 the only truly conforming solution requires a dynamic allocation.
10673 </p>
10674
10675 <p><b>Further discussion, from Redmond:</b></p>
10676
10677 <p>The most important progress we made at the Redmond meeting was
10678 realizing that there are two separable issues here: the const
10679 string&amp; constructor, and the copy constructor.  If a user writes
10680 something like <tt>throw std::out_of_range("foo")</tt>, the const
10681 string&amp; constructor is invoked before anything gets thrown.  The
10682 copy constructor is potentially invoked during stack unwinding.</p>
10683
10684 <p>The copy constructor is a more serious problem, becuase failure
10685 during stack unwinding invokes <tt>terminate</tt>.  The copy
10686 constructor must be nothrow. <i>Curaçao: Howard thinks this
10687 requirement may already be present.</i></p>
10688
10689 <p>The fundamental problem is that it's difficult to get the nothrow
10690 requirement to work well with the requirement that the exception
10691 objects store a string of unbounded size, particularly if you also try
10692 to make the const string&amp; constructor nothrow.  Options discussed
10693 include:</p>
10694
10695 <ul>
10696 <li>Limit the size of a string that exception objects are required to
10697 throw: change the postconditions of 19.1.2 [domain.error] paragraph 3
10698 and 19.1.6 [runtime.error] paragraph 3 to something like this:
10699 "strncmp(what(), what_arg._str(), N) == 0, where N is an
10700 implementation defined constant no smaller than 256".</li>
10701 <li>Allow the const string&amp; constructor to throw, but not the
10702 copy constructor.  It's the implementor's responsibility to get it
10703 right.  (An implementor might use a simple refcount class.)</li>
10704 <li>Compromise between the two: an implementation is not allowed to
10705 throw if the string's length is less than some N, but, if it doesn't
10706 throw, the string must compare equal to the argument.</li>
10707 <li>Add a new constructor that takes a const char*</li>
10708 </ul>
10709
10710 <p>(Not all of these options are mutually exclusive.)</p>
10711
10712
10713
10714 <p><b>Proposed resolution:</b></p>
10715
10716 <p>
10717 Change 19.1.1 [logic.error]
10718 </p>
10719
10720 <blockquote>
10721 <pre>namespace std {
10722   class logic_error : public exception {
10723   public:
10724     explicit logic_error(const string&amp; <i>what_arg</i>);
10725     <ins>explicit logic_error(const char* <i>what_arg</i>);</ins>
10726   };
10727 }
10728 </pre>
10729 <p>...</p>
10730 <p>
10731 <ins><tt>logic_error(const char* <i>what_arg</i>);</tt></ins>
10732 </p>
10733 <blockquote>
10734 <p><ins>
10735 -4- <i>Effects:</i> Constructs an object of class <tt>logic_error</tt>.
10736 </ins></p>
10737 <p><ins>
10738 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10739 </ins></p>
10740 </blockquote>
10741
10742 </blockquote>
10743
10744 <p>
10745 Change 19.1.2 [domain.error]
10746 </p>
10747
10748 <blockquote>
10749 <pre>namespace std {
10750   class domain_error : public logic_error {
10751   public:
10752     explicit domain_error(const string&amp; <i>what_arg</i>);
10753     <ins>explicit domain_error(const char* <i>what_arg</i>);</ins>
10754   };
10755 }
10756 </pre>
10757 <p>...</p>
10758 <p>
10759 <ins><tt>domain_error(const char* <i>what_arg</i>);</tt></ins>
10760 </p>
10761 <blockquote>
10762 <p><ins>
10763 -4- <i>Effects:</i> Constructs an object of class <tt>domain_error</tt>.
10764 </ins></p>
10765 <p><ins>
10766 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10767 </ins></p>
10768
10769 </blockquote>
10770 </blockquote>
10771
10772 <p>
10773 Change 19.1.3 [invalid.argument]
10774 </p>
10775
10776 <blockquote>
10777 <pre>namespace std {
10778   class invalid_argument : public logic_error {
10779   public:
10780     explicit invalid_argument(const string&amp; <i>what_arg</i>);
10781     <ins>explicit invalid_argument(const char* <i>what_arg</i>);</ins>
10782   };
10783 }
10784 </pre>
10785 <p>...</p>
10786 <p>
10787 <ins><tt>invalid_argument(const char* <i>what_arg</i>);</tt></ins>
10788 </p>
10789 <blockquote>
10790 <p><ins>
10791 -4- <i>Effects:</i> Constructs an object of class <tt>invalid_argument</tt>.
10792 </ins></p>
10793 <p><ins>
10794 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10795 </ins></p>
10796 </blockquote>
10797
10798 </blockquote>
10799
10800 <p>
10801 Change 19.1.4 [length.error]
10802 </p>
10803
10804 <blockquote>
10805 <pre>namespace std {
10806   class length_error : public logic_error {
10807   public:
10808     explicit length_error(const string&amp; <i>what_arg</i>);
10809     <ins>explicit length_error(const char* <i>what_arg</i>);</ins>
10810   };
10811 }
10812 </pre>
10813 <p>...</p>
10814 <p>
10815 <ins><tt>length_error(const char* <i>what_arg</i>);</tt></ins>
10816 </p>
10817 <blockquote>
10818 <p><ins>
10819 -4- <i>Effects:</i> Constructs an object of class <tt>length_error</tt>.
10820 </ins></p>
10821 <p><ins>
10822 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10823 </ins></p>
10824 </blockquote>
10825
10826 </blockquote>
10827
10828 <p>
10829 Change 19.1.5 [out.of.range]
10830 </p>
10831
10832 <blockquote>
10833 <pre>namespace std {
10834   class out_of_range : public logic_error {
10835   public:
10836     explicit out_of_range(const string&amp; <i>what_arg</i>);
10837     <ins>explicit out_of_range(const char* <i>what_arg</i>);</ins>
10838   };
10839 }
10840 </pre>
10841 <p>...</p>
10842 <p>
10843 <ins><tt>out_of_range(const char* <i>what_arg</i>);</tt></ins>
10844 </p>
10845 <blockquote>
10846 <p><ins>
10847 -4- <i>Effects:</i> Constructs an object of class <tt>out_of_range</tt>.
10848 </ins></p>
10849 <p><ins>
10850 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10851 </ins></p>
10852 </blockquote>
10853
10854 </blockquote>
10855
10856 <p>
10857 Change 19.1.6 [runtime.error]
10858 </p>
10859
10860 <blockquote>
10861 <pre>namespace std {
10862   class runtime_error : public exception {
10863   public:
10864     explicit runtime_error(const string&amp; <i>what_arg</i>);
10865     <ins>explicit runtime_error(const char* <i>what_arg</i>);</ins>
10866   };
10867 }
10868 </pre>
10869 <p>...</p>
10870 <p>
10871 <ins><tt>runtime_error(const char* <i>what_arg</i>);</tt></ins>
10872 </p>
10873 <blockquote>
10874 <p><ins>
10875 -4- <i>Effects:</i> Constructs an object of class <tt>runtime_error</tt>.
10876 </ins></p>
10877 <p><ins>
10878 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10879 </ins></p>
10880 </blockquote>
10881
10882 </blockquote>
10883
10884 <p>
10885 Change 19.1.7 [range.error]
10886 </p>
10887
10888 <blockquote>
10889 <pre>namespace std {
10890   class range_error : public runtime_error {
10891   public:
10892     explicit range_error(const string&amp; <i>what_arg</i>);
10893     <ins>explicit range_error(const char* <i>what_arg</i>);</ins>
10894   };
10895 }
10896 </pre>
10897 <p>...</p>
10898 <p>
10899 <ins><tt>range_error(const char* <i>what_arg</i>);</tt></ins>
10900 </p>
10901 <blockquote>
10902 <p><ins>
10903 -4- <i>Effects:</i> Constructs an object of class <tt>range_error</tt>.
10904 </ins></p>
10905 <p><ins>
10906 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10907 </ins></p>
10908 </blockquote>
10909
10910 </blockquote>
10911
10912 <p>
10913 Change 19.1.8 [overflow.error]
10914 </p>
10915
10916 <blockquote>
10917 <pre>namespace std {
10918   class overflow_error : public runtime_error {
10919   public:
10920     explicit overflow_error(const string&amp; <i>what_arg</i>);
10921     <ins>explicit overflow_error(const char* <i>what_arg</i>);</ins>
10922   };
10923 }
10924 </pre>
10925 <p>...</p>
10926 <p>
10927 <ins><tt>overflow_error(const char* <i>what_arg</i>);</tt></ins>
10928 </p>
10929 <blockquote>
10930 <p><ins>
10931 -4- <i>Effects:</i> Constructs an object of class <tt>overflow_error</tt>.
10932 </ins></p>
10933 <p><ins>
10934 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10935 </ins></p>
10936 </blockquote>
10937
10938 </blockquote>
10939
10940 <p>
10941 Change 19.1.9 [underflow.error]
10942 </p>
10943
10944 <blockquote>
10945 <pre>namespace std {
10946   class underflow_error : public runtime_error {
10947   public:
10948     explicit underflow_error(const string&amp; <i>what_arg</i>);
10949     <ins>explicit underflow_error(const char* <i>what_arg</i>);</ins>
10950   };
10951 }
10952 </pre>
10953 <p>...</p>
10954 <p>
10955 <ins><tt>underflow_error(const char* <i>what_arg</i>);</tt></ins>
10956 </p>
10957 <blockquote>
10958 <p><ins>
10959 -4- <i>Effects:</i> Constructs an object of class <tt>underflow_error</tt>.
10960 </ins></p>
10961 <p><ins>
10962 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10963 </ins></p>
10964 </blockquote>
10965
10966 </blockquote>
10967
10968 <p>
10969 Change 27.4.2.1.1 [ios::failure]
10970 </p>
10971
10972 <blockquote>
10973 <pre>namespace std {
10974   class ios_base::failure : public exception {
10975   public:
10976     explicit failure(const string&amp; <i>msg</i>);
10977     <ins>explicit failure(const char* <i>msg</i>);</ins>
10978     virtual const char* what() const throw();
10979 };
10980 }
10981 </pre>
10982 <p>...</p>
10983 <p>
10984 <ins><tt>failure(const char* <i>msg</i>);</tt></ins>
10985 </p>
10986 <blockquote>
10987 <p><ins>
10988 -4- <i>Effects:</i> Constructs an object of class <tt>failure</tt>.
10989 </ins></p>
10990 <p><ins>
10991 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>msg</i>) == 0</tt>.
10992 </ins></p>
10993 </blockquote>
10994
10995 </blockquote>
10996
10997
10998
10999 <p><b>Rationale:</b></p>
11000
11001 <p>Throwing a bad_alloc while trying to construct a message for another
11002 exception-derived class is not necessarily a bad thing.  And the
11003 bad_alloc constructor already has a no throw spec on it (18.4.2.1).</p>
11004
11005 <p><b>Future:</b></p>
11006
11007 <p>All involved would like to see const char* constructors added, but
11008 this should probably be done for C++0X as opposed to a DR.</p>
11009
11010 <p>I believe the no throw specs currently decorating these functions
11011 could be improved by some kind of static no throw spec checking
11012 mechanism (in a future C++ language).  As they stand, the copy
11013 constructors might fail via a call to unexpected.  I think what is
11014 intended here is that the copy constructors can't fail.</p>
11015
11016 <p><i>[Pre-Sydney: reopened at the request of Howard Hinnant.
11017   Post-Redmond: James Kanze noticed that the copy constructors of
11018   exception-derived classes do not have nothrow clauses.  Those
11019   classes have no copy constructors declared, meaning the
11020   compiler-generated implicit copy constructors are used, and those
11021   compiler-generated constructors might in principle throw anything.]</i></p>
11022
11023
11024 <p><i>[
11025 Batavia:  Merged copy constructor and assignment operator spec into <tt>exception</tt>
11026 and added <tt>ios::failure</tt> into the proposed resolution.
11027 ]</i></p>
11028
11029
11030 <p><i>[
11031 Oxford:  The proposed resolution simply addresses the issue of constructing
11032 the exception objects with <tt>const char*</tt> and string literals without
11033 the need to explicit include or construct a <tt>std::string</tt>.
11034 ]</i></p>
11035
11036
11037
11038
11039
11040
11041
11042 <hr>
11043 <h3><a name="256"></a>256. typo in 27.4.4.2, p17: copy_event does not exist</h3>
11044 <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>
11045  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-21</p>
11046 <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>
11047 <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>
11048 <p><b>Discussion:</b></p>
11049 <p>
11050 27.4.4.2, p17 says
11051 </p>
11052
11053 <blockquote><p>
11054 -17- Before copying any parts of rhs, calls each registered callback
11055 pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
11056 exceptions() have been replaced, calls each callback pair that was
11057 copied from rhs as (*fn)(copy_event,*this,index).
11058 </p></blockquote>
11059
11060 <p>
11061 The name copy_event isn't defined anywhere. The intended name was
11062 copyfmt_event.
11063 </p>
11064
11065
11066 <p><b>Proposed resolution:</b></p>
11067 <p>Replace copy_event with copyfmt_event in the named paragraph.</p>
11068
11069
11070
11071
11072 <hr>
11073 <h3><a name="258"></a>258. Missing allocator requirement</h3>
11074 <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>
11075  <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-08-22</p>
11076 <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>
11077 <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>
11078 <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>
11079 <p><b>Discussion:</b></p>
11080 <p>
11081 From lib-7752:
11082 </p>
11083
11084 <p>
11085 I've been assuming (and probably everyone else has been assuming) that
11086 allocator instances have a particular property, and I don't think that
11087 property can be deduced from anything in Table 32.
11088 </p>
11089
11090 <p>
11091 I think we have to assume that allocator type conversion is a
11092 homomorphism.  That is, if x1 and x2 are of type X, where
11093 X::value_type is T, and if type Y is X::template
11094 rebind&lt;U&gt;::other, then Y(x1) == Y(x2) if and only if x1 == x2.
11095 </p>
11096
11097 <p>
11098 Further discussion: Howard Hinnant writes, in lib-7757:
11099 </p>
11100
11101 <p>
11102 I think I can prove that this is not provable by Table 32.  And I agree
11103 it needs to be true except for the "and only if".  If x1 != x2, I see no
11104 reason why it can't be true that Y(x1) == Y(x2).  Admittedly I can't
11105 think of a practical instance where this would happen, or be valuable.
11106 But I also don't see a need to add that extra restriction.  I think we
11107 only need:
11108 </p>
11109
11110 <blockquote><p>
11111      if (x1 == x2) then Y(x1) == Y(x2)
11112 </p></blockquote>
11113
11114 <p>
11115 If we decide that == on allocators is transitive, then I think I can
11116 prove the above.  But I don't think == is necessarily transitive on
11117 allocators.  That is:
11118 </p>
11119
11120 <p>
11121 Given x1 == x2  and x2 == x3, this does not mean x1 == x3.
11122 </p>
11123
11124 <p>Example:</p>
11125
11126 <blockquote>
11127 <p>
11128 x1 can deallocate pointers from:  x1, x2, x3    <br>
11129 x2 can deallocate pointers from:  x1, x2, x4    <br>
11130 x3 can deallocate pointers from:  x1, x3        <br>
11131 x4 can deallocate pointers from:  x2, x4
11132 </p>
11133
11134 <p>
11135 x1 == x2, and x2 == x4, but x1 != x4
11136 </p>
11137 </blockquote>
11138 <p><i>[Toronto: LWG members offered multiple opinions.  One
11139 opinion is that it should not be required that <tt>x1 == x2</tt>
11140 implies <tt>Y(x1) == Y(x2)</tt>, and that it should not even be
11141 required that <tt>X(x1) == x1</tt>.  Another opinion is that
11142 the second line from the bottom in table 32 already implies the
11143 desired property.  This issue should be considered in light of
11144 other issues related to allocator instances.]</i></p>
11145
11146
11147
11148 <p><b>Proposed resolution:</b></p>
11149 <p>
11150 Accept proposed wording from
11151 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2436.pdf">N2436</a> part 3.
11152 </p>
11153
11154
11155 <p><i>[Lillehammer: Same conclusion as before: this should be
11156   considered as part of an allocator redesign, not solved on its own.]</i></p>
11157
11158
11159 <p><i>[
11160 Batavia:  An allocator redesign is not forthcoming and thus we fixed this one issue.
11161 ]</i></p>
11162
11163
11164 <p><i>[
11165 Toronto:  Reopened at the request of the project editor (Pete) because the proposed
11166 wording did not fit within the indicated table.  The intent of the resolution remains
11167 unchanged.  Pablo to work with Pete on improved wording.
11168 ]</i></p>
11169
11170
11171 <p><i>[
11172 Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
11173 was subsequently split out into a separate paper N2436 for the purposes of voting.
11174 The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
11175 issue to Ready status to be voted into the WP at Kona.
11176 ]</i></p>
11177
11178
11179
11180
11181
11182 <hr>
11183 <h3><a name="259"></a>259. <tt>basic_string::operator[]</tt> and const correctness</h3>
11184 <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>
11185  <b>Submitter:</b> Chris Newton  <b>Date:</b> 2000-08-27</p>
11186 <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>
11187 <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>
11188 <p><b>Discussion:</b></p>
11189 <p>
11190 <i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
11191 </p>
11192
11193 <p>
11194 The standard's description of <tt>basic_string&lt;&gt;::operator[]</tt>
11195 seems to violate const correctness.
11196 </p>
11197
11198 <p>
11199 The standard (21.3.4/1) says that "If <tt>pos &lt; size()</tt>,
11200 returns <tt>data()[pos]</tt>." The types don't work.  The
11201 return value of <tt>data()</tt> is <tt>const charT*</tt>, but
11202 <tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
11203 </p>
11204
11205
11206 <p><b>Proposed resolution:</b></p>
11207 <p>
11208 In section 21.3.4, paragraph 1, change
11209 "<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
11210 <i>pos</i>)</tt>".
11211 </p>
11212
11213
11214
11215
11216 <hr>
11217 <h3><a name="260"></a>260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt></h3>
11218 <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>
11219  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-27</p>
11220 <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>
11221 <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>
11222 <p><b>Discussion:</b></p>
11223 <p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
11224 it as returning the iterator by value. 24.5.1.2, p5 shows the same
11225 operator as returning the iterator by reference. That's incorrect
11226 given the Effects clause below (since a temporary is returned). The
11227 `&amp;' is probably just a typo.</p>
11228
11229
11230 <p><b>Proposed resolution:</b></p>
11231 <p>Change the declaration in 24.5.1.2, p5 from</p>
11232  <pre> istream_iterator&lt;T,charT,traits,Distance&gt;&amp; operator++(int);
11233  </pre>
11234 <p>to</p>
11235  <pre> istream_iterator&lt;T,charT,traits,Distance&gt; operator++(int);
11236  </pre>
11237 <p>(that is, remove the `&amp;').</p>
11238
11239
11240
11241
11242 <hr>
11243 <h3><a name="261"></a>261. Missing description of <tt>istream_iterator::operator!=</tt></h3>
11244 <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>
11245  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-27</p>
11246 <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>
11247 <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>
11248 <p><b>Discussion:</b></p>
11249 <p>
11250 24.5.1, p3 lists the synopsis for
11251 </p>
11252
11253 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
11254         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
11255                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
11256 </pre>
11257
11258 <p>
11259 but there is no description of what the operator does (i.e., no Effects
11260 or Returns clause) in 24.5.1.2.
11261 </p>
11262
11263
11264 <p><b>Proposed resolution:</b></p>
11265 <p>
11266 Add paragraph 7 to the end of section 24.5.1.2 with the following text:
11267 </p>
11268
11269 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
11270         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
11271                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
11272 </pre>
11273
11274 <p>-7- Returns: !(x == y).</p>
11275
11276
11277
11278
11279 <hr>
11280 <h3><a name="262"></a>262. Bitmask operator ~ specified incorrectly</h3>
11281 <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>
11282  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2000-09-03</p>
11283 <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>
11284 <p><b>Discussion:</b></p>
11285 <p>
11286 The ~ operation should be applied after the cast to int_type.
11287 </p>
11288
11289
11290 <p><b>Proposed resolution:</b></p>
11291 <p>
11292 Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
11293 </p>
11294
11295 <pre>   bitmask operator~ ( bitmask X )
11296      { return static_cast&lt; bitmask&gt;(static_cast&lt;int_type&gt;(~ X)); }
11297 </pre>
11298
11299 <p>
11300 to:
11301 </p>
11302
11303 <pre>   bitmask operator~ ( bitmask X )
11304      { return static_cast&lt; bitmask&gt;(~static_cast&lt;int_type&gt;(X)); }
11305 </pre>
11306
11307
11308
11309
11310 <hr>
11311 <h3><a name="263"></a>263. Severe restriction on <tt>basic_string</tt> reference counting</h3>
11312 <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>
11313  <b>Submitter:</b> Kevlin Henney <b>Date:</b> 2000-09-04</p>
11314 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
11315 <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>
11316 <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>
11317 <p><b>Discussion:</b></p>
11318 <p>
11319 The note in paragraph 6 suggests that the invalidation rules for
11320 references, pointers, and iterators in paragraph 5 permit a reference-
11321 counted implementation (actually, according to paragraph 6, they permit
11322 a "reference counted implementation", but this is a minor editorial fix).
11323 </p>
11324
11325 <p>
11326 However, the last sub-bullet is so worded as to make a reference-counted
11327 implementation unviable. In the following example none of the
11328 conditions for iterator invalidation are satisfied:
11329 </p>
11330
11331 <pre>    // first example: "*******************" should be printed twice
11332     string original = "some arbitrary text", copy = original;
11333     const string &amp; alias = original;
11334
11335     string::const_iterator i = alias.begin(), e = alias.end();
11336     for(string::iterator j = original.begin(); j != original.end(); ++j)
11337         *j = '*';
11338     while(i != e)
11339         cout &lt;&lt; *i++;
11340     cout &lt;&lt; endl;
11341     cout &lt;&lt; original &lt;&lt; endl;
11342 </pre>
11343
11344 <p>
11345 Similarly, in the following example:
11346 </p>
11347
11348 <pre>    // second example: "some arbitrary text" should be printed out
11349     string original = "some arbitrary text", copy = original;
11350     const string &amp; alias = original;
11351
11352     string::const_iterator i = alias.begin();
11353     original.begin();
11354     while(i != alias.end())
11355         cout &lt;&lt; *i++;
11356 </pre>
11357
11358 <p>
11359 I have tested this on three string implementations, two of which were
11360 reference counted. The reference-counted implementations gave
11361 "surprising behavior" because they invalidated iterators on
11362 the first call to non-const begin since construction. The current
11363 wording does not permit such invalidation because it does not take
11364 into account the first call since construction, only the first call
11365 since various member and non-member function calls.
11366 </p>
11367
11368
11369 <p><b>Proposed resolution:</b></p>
11370 <p>
11371 Change the following sentence in 21.3 paragraph 5 from
11372 </p>
11373
11374 <blockquote><p>
11375     Subsequent to any of the above uses except the forms of insert() and
11376     erase() which return iterators, the first call to non-const member
11377     functions operator[](), at(), begin(), rbegin(), end(), or rend().
11378 </p></blockquote>
11379
11380 <p>to</p>
11381
11382 <blockquote><p>
11383     Following construction or any of the above uses, except the forms of
11384     insert() and erase() that return iterators, the first call to non-
11385     const member functions operator[](), at(), begin(), rbegin(), end(),
11386     or rend().
11387 </p></blockquote>
11388
11389
11390
11391
11392 <hr>
11393 <h3><a name="264"></a>264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3>
11394 <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>
11395  <b>Submitter:</b> John Potter <b>Date:</b> 2000-09-07</p>
11396 <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>
11397 <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>
11398 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></p>
11399 <p><b>Discussion:</b></p>
11400 <p>
11401 Table 69 requires linear time if [i, j) is sorted.  Sorted is necessary but not sufficient.
11402 Consider inserting a sorted range of even integers into a set&lt;int&gt; containing the odd
11403 integers in the same range.
11404 </p>
11405
11406 <p><i>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></i></p>
11407
11408
11409 <p><b>Proposed resolution:</b></p>
11410 <p>
11411 In Table 69, in section 23.1.2, change the complexity clause for
11412 insertion of a range from "N log(size() + N) (N is the distance
11413 from i to j) in general; linear if [i, j) is sorted according to
11414 value_comp()" to "N log(size() + N), where N is the distance
11415 from i to j".
11416 </p>
11417
11418 <p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
11419 parens in the revised wording.]</i></p>
11420
11421
11422
11423
11424 <p><b>Rationale:</b></p>
11425 <p>
11426 Testing for valid insertions could be less efficient than simply
11427 inserting the elements when the range is not both sorted and between
11428 two adjacent existing elements; this could be a QOI issue.
11429 </p>
11430
11431 <p>
11432 The LWG considered two other options: (a) specifying that the
11433 complexity was linear if [i, j) is sorted according to value_comp()
11434 and between two adjacent existing elements; or (b) changing to
11435 Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
11436 number of elements which do not insert immediately after the previous
11437 element from [i, j) including the first).  The LWG felt that, since
11438 we can't guarantee linear time complexity whenever the range to be
11439 inserted is sorted, it's more trouble than it's worth to say that it's
11440 linear in some special cases.
11441 </p>
11442
11443
11444
11445
11446 <hr>
11447 <h3><a name="265"></a>265. std::pair::pair() effects overly restrictive</h3>
11448 <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>
11449  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-09-11</p>
11450 <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>
11451 <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>
11452 <p><b>Discussion:</b></p>
11453 <p>
11454 I don't see any requirements on the types of the elements of the
11455 std::pair container in 20.2.2. From the descriptions of the member
11456 functions it appears that they must at least satisfy the requirements of
11457 20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
11458 the case of the [in]equality operators also the requirements of 20.1.1
11459 [lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
11460 </p>
11461
11462 <p>
11463 I believe that the the CopyConstructible requirement is unnecessary in
11464 the case of 20.2.2, p2.
11465 </p>
11466
11467
11468 <p><b>Proposed resolution:</b></p>
11469 <p>Change the Effects clause in 20.2.2, p2 from</p>
11470
11471 <blockquote><p>
11472 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
11473 first(T1()), second(T2()) {} </tt>
11474 </p></blockquote>
11475
11476 <p>to</p>
11477
11478 <blockquote><p>
11479 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
11480 first(), second() {} </tt>
11481 </p></blockquote>
11482
11483
11484 <p><b>Rationale:</b></p>
11485 <p>The existing specification of pair's constructor appears to be a
11486 historical artifact: there was concern that pair's members be properly
11487 zero-initialized when they are built-in types.  At one time there was
11488 uncertainty about whether they would be zero-initialized if the
11489 default constructor was written the obvious way.  This has been
11490 clarified by core issue 178, and there is no longer any doubt that
11491 the straightforward implementation is correct.</p>
11492
11493
11494
11495
11496 <hr>
11497 <h3><a name="266"></a>266. bad_exception::~bad_exception() missing Effects clause</h3>
11498 <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>
11499  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-09-24</p>
11500 <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>
11501 <p><b>Discussion:</b></p>
11502 <p>
11503 The synopsis for std::bad_exception lists the function ~bad_exception()
11504 but there is no description of what the function does (the Effects
11505 clause is missing).
11506 </p>
11507
11508
11509 <p><b>Proposed resolution:</b></p>
11510 <p>
11511 Remove the destructor from the class synopses of
11512 <tt>bad_alloc</tt> (18.5.2.1 [bad.alloc]),
11513 <tt>bad_cast</tt> (18.6.2 [bad.cast]),
11514 <tt>bad_typeid</tt> (18.6.3 [bad.typeid]),
11515 and <tt>bad_exception</tt> (18.7.2.1 [bad.exception]).
11516 </p>
11517
11518
11519 <p><b>Rationale:</b></p>
11520 <p>
11521 This is a general problem with the exception classes in clause 18.
11522 The proposed resolution is to remove the destructors from the class
11523 synopses, rather than to document the destructors' behavior, because
11524 removing them is more consistent with how exception classes are
11525 described in clause 19.
11526 </p>
11527
11528
11529
11530
11531 <hr>
11532 <h3><a name="268"></a>268. Typo in locale synopsis</h3>
11533 <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>
11534  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-10-05</p>
11535 <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>
11536 <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>
11537 <p><b>Discussion:</b></p>
11538 <p>The synopsis of the class std::locale in 22.1.1 contains two typos:
11539 the semicolons after the declarations of the default ctor
11540 locale::locale() and the copy ctor locale::locale(const locale&amp;)
11541 are missing.</p>
11542
11543
11544 <p><b>Proposed resolution:</b></p>
11545 <p>Add the missing semicolons, i.e., change</p>
11546
11547 <pre>    //  construct/copy/destroy:
11548         locale() throw()
11549         locale(const locale&amp; other) throw()
11550 </pre>
11551
11552 <p>in the synopsis in 22.1.1 to</p>
11553
11554 <pre>    //  construct/copy/destroy:
11555         locale() throw();
11556         locale(const locale&amp; other) throw();
11557 </pre>
11558
11559
11560
11561
11562 <hr>
11563 <h3><a name="270"></a>270. Binary search requirements overly strict</h3>
11564 <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>
11565  <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-10-18</p>
11566 <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>
11567 <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>
11568 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#472">472</a></p>
11569 <p><b>Discussion:</b></p>
11570 <p>
11571 Each of the four binary search algorithms (lower_bound, upper_bound,
11572 equal_range, binary_search) has a form that allows the user to pass a
11573 comparison function object.  According to 25.3, paragraph 2, that
11574 comparison function object has to be a strict weak ordering.
11575 </p>
11576
11577 <p>
11578 This requirement is slightly too strict.  Suppose we are searching
11579 through a sequence containing objects of type X, where X is some
11580 large record with an integer key.  We might reasonably want to look
11581 up a record by key, in which case we would want to write something
11582 like this:
11583 </p>
11584 <pre>    struct key_comp {
11585       bool operator()(const X&amp; x, int n) const {
11586         return x.key() &lt; n;
11587       }
11588     }
11589
11590     std::lower_bound(first, last, 47, key_comp());
11591 </pre>
11592
11593 <p>
11594 key_comp is not a strict weak ordering, but there is no reason to
11595 prohibit its use in lower_bound.
11596 </p>
11597
11598 <p>
11599 There's no difficulty in implementing lower_bound so that it allows
11600 the use of something like key_comp.  (It will probably work unless an
11601 implementor takes special pains to forbid it.)  What's difficult is
11602 formulating language in the standard to specify what kind of
11603 comparison function is acceptable.  We need a notion that's slightly
11604 more general than that of a strict weak ordering, one that can encompass
11605 a comparison function that involves different types.  Expressing that
11606 notion may be complicated.
11607 </p>
11608
11609 <p><i>Additional questions raised at the Toronto meeting:</i></p>
11610 <ul>
11611 <li> Do we really want to specify what ordering the implementor must
11612      use when calling the function object?  The standard gives
11613      specific expressions when describing these algorithms, but it also
11614      says that other expressions (with different argument order) are
11615      equivalent.</li>
11616 <li> If we are specifying ordering, note that the standard uses both
11617      orderings when describing <tt>equal_range</tt>.</li>
11618 <li> Are we talking about requiring these algorithms to work properly
11619      when passed a binary function object whose two argument types
11620      are not the same, or are we talking about requirements when
11621      they are passed a binary function object with several overloaded
11622      versions of <tt>operator()</tt>?</li>
11623 <li> The definition of a strict weak ordering does not appear to give
11624      any guidance on issues of overloading; it only discusses expressions,
11625      and all of the values in these expressions are of the same type.
11626      Some clarification would seem to be in order.</li>
11627 </ul>
11628
11629 <p><i>Additional discussion from Copenhagen:</i></p>
11630 <ul>
11631 <li>It was generally agreed that there is a real defect here: if
11632 the predicate is merely required to be a Strict Weak Ordering, then
11633 it's possible to pass in a function object with an overloaded
11634 operator(), where the version that's actually called does something
11635 completely inappropriate.  (Such as returning a random value.)</li>
11636
11637 <li>An alternative formulation was presented in a paper distributed by
11638 David Abrahams at the meeting, "Binary Search with Heterogeneous
11639 Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
11640 predicate as a Strict Weak Ordering acting on a sorted sequence, view
11641 the predicate/value pair as something that partitions a sequence.
11642 This is almost equivalent to saying that we should view binary search
11643 as if we are given a unary predicate and a sequence, such that f(*p)
11644 is true for all p below a specific point and false for all p above it.
11645 The proposed resolution is based on that alternative formulation.</li>
11646 </ul>
11647
11648
11649 <p><b>Proposed resolution:</b></p>
11650
11651 <p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
11652
11653 <blockquote><p>
11654   3 For all algorithms that take Compare, there is a version that uses
11655   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i &lt;
11656   *j != false. For the algorithms to work correctly, comp has to
11657   induce a strict weak ordering on the values.
11658 </p></blockquote>
11659
11660 <p>to:</p>
11661
11662 <blockquote><p>
11663   3 For all algorithms that take Compare, there is a version that uses
11664   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i
11665   &lt; *j != false. For algorithms other than those described in
11666   lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
11667   a strict weak ordering on the values.
11668 </p></blockquote>
11669
11670 <p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
11671
11672 <blockquote><p>
11673   -6- A sequence [start, finish) is partitioned with respect to an
11674   expression f(e) if there exists an integer n such that
11675   for all 0 &lt;= i &lt; distance(start, finish), f(*(begin+i)) is true if
11676   and only if i &lt; n.
11677 </p></blockquote>
11678
11679 <p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
11680
11681 <blockquote><p>
11682   -1- All of the algorithms in this section are versions of binary
11683    search and assume that the sequence being searched is in order
11684    according to the implied or explicit comparison function. They work
11685    on non-random access iterators minimizing the number of
11686    comparisons, which will be logarithmic for all types of
11687    iterators. They are especially appropriate for random access
11688    iterators, because these algorithms do a logarithmic number of
11689    steps through the data structure. For non-random access iterators
11690    they execute a linear number of steps.
11691 </p></blockquote>
11692
11693 <p>to:</p>
11694
11695 <blockquote><p>
11696    -1- All of the algorithms in this section are versions of binary
11697     search and assume that the sequence being searched is partitioned
11698     with respect to an expression formed by binding the search key to
11699     an argument of the implied or explicit comparison function. They
11700     work on non-random access iterators minimizing the number of
11701     comparisons, which will be logarithmic for all types of
11702     iterators. They are especially appropriate for random access
11703     iterators, because these algorithms do a logarithmic number of
11704     steps through the data structure. For non-random access iterators
11705     they execute a linear number of steps.
11706 </p></blockquote>
11707
11708 <p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
11709
11710 <blockquote><p>
11711    -1- Requires: Type T is LessThanComparable
11712     (lib.lessthancomparable).
11713 </p></blockquote>
11714
11715 <p>to:</p>
11716
11717 <blockquote><p>
11718    -1- Requires: The elements e of [first, last) are partitioned with
11719    respect to the expression e &lt; value or comp(e, value)
11720 </p></blockquote>
11721
11722
11723 <p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
11724
11725 <blockquote><p>
11726    -2- Effects: Finds the first position into which value can be
11727     inserted without violating the ordering.
11728 </p></blockquote>
11729
11730 <p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
11731
11732 <blockquote><p>
11733   -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
11734 </p></blockquote>
11735
11736 <p>to:</p>
11737
11738 <blockquote><p>
11739    -1- Requires: The elements e of [first, last) are partitioned with
11740    respect to the expression !(value &lt; e) or !comp(value, e)
11741 </p></blockquote>
11742
11743 <p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
11744
11745 <blockquote><p>
11746    -2- Effects: Finds the furthermost position into which value can be
11747     inserted without violating the ordering.
11748 </p></blockquote>
11749
11750 <p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
11751
11752 <blockquote><p>
11753    -1- Requires: Type T is LessThanComparable
11754     (lib.lessthancomparable).
11755 </p></blockquote>
11756
11757 <p>to:</p>
11758
11759 <blockquote><p>
11760    -1- Requires: The elements e of [first, last) are partitioned with
11761    respect to the expressions e &lt; value and !(value &lt; e) or
11762    comp(e, value) and !comp(value, e).  Also, for all elements e of
11763    [first, last), e &lt; value implies !(value &lt; e) or comp(e,
11764    value) implies !comp(value, e)
11765 </p></blockquote>
11766
11767 <p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
11768
11769 <blockquote><p>
11770    -2- Effects: Finds the largest subrange [i, j) such that the value
11771     can be inserted at any iterator k in it without violating the
11772     ordering. k satisfies the corresponding conditions: !(*k &lt; value)
11773     &amp;&amp; !(value &lt; *k) or comp(*k, value) == false &amp;&amp; comp(value, *k) ==
11774     false.
11775 </p></blockquote>
11776
11777 <p>to:</p>
11778
11779 <pre>   -2- Returns:
11780          make_pair(lower_bound(first, last, value),
11781                    upper_bound(first, last, value))
11782        or
11783          make_pair(lower_bound(first, last, value, comp),
11784                    upper_bound(first, last, value, comp))
11785 </pre>
11786
11787 <p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
11788
11789 <blockquote><p>
11790    -1- Requires: Type T is LessThanComparable
11791     (lib.lessthancomparable).
11792 </p></blockquote>
11793
11794 <p>to:</p>
11795
11796 <blockquote><p>
11797    -1- Requires: The elements e of [first, last) are partitioned with
11798    respect to the expressions e &lt; value and !(value &lt; e) or comp(e,
11799    value) and !comp(value, e). Also, for all elements e of [first,
11800    last), e &lt; value implies !(value &lt; e) or comp(e, value) implies
11801    !comp(value, e)
11802 </p></blockquote>
11803
11804 <p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
11805
11806
11807 <p><i>[Redmond: Minor changes in wording.  (Removed "non-negative", and
11808 changed the "other than those described in" wording.) Also, the LWG
11809 decided to accept the "optional" part.]</i></p>
11810
11811
11812
11813
11814 <p><b>Rationale:</b></p>
11815 <p>The proposed resolution reinterprets binary search. Instead of
11816 thinking about searching for a value in a sorted range, we view that
11817 as an important special case of a more general algorithm: searching
11818 for the partition point in a partitioned range.</p>
11819
11820 <p>We also add a guarantee that the old wording did not: we ensure
11821 that the upper bound is no earlier than the lower bound, that
11822 the pair returned by equal_range is a valid range, and that the first
11823 part of that pair is the lower bound.</p>
11824
11825
11826
11827
11828
11829 <hr>
11830 <h3><a name="271"></a>271. basic_iostream missing typedefs</h3>
11831 <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>
11832  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
11833 <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>
11834 <p><b>Discussion:</b></p>
11835 <p>
11836 Class template basic_iostream has no typedefs.  The typedefs it
11837 inherits from its base classes can't be used, since (for example)
11838 basic_iostream&lt;T&gt;::traits_type is ambiguous.
11839 </p>
11840
11841
11842 <p><b>Proposed resolution:</b></p>
11843
11844 <p>Add the following to basic_iostream's class synopsis in
11845 27.6.1.5 [iostreamclass], immediately after <tt>public</tt>:</p>
11846
11847 <pre>  // types:
11848   typedef charT                     char_type;
11849   typedef typename traits::int_type int_type;
11850   typedef typename traits::pos_type pos_type;
11851   typedef typename traits::off_type off_type;
11852   typedef traits                    traits_type;
11853 </pre>
11854
11855
11856
11857
11858 <hr>
11859 <h3><a name="272"></a>272. Missing parentheses around subexpression</h3>
11860 <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>
11861  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
11862 <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>
11863 <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>
11864 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a></p>
11865 <p><b>Discussion:</b></p>
11866 <p>
11867 27.4.4.3, p4 says about the postcondition of the function: If
11868 rdbuf()!=0 then state == rdstate(); otherwise
11869 rdstate()==state|ios_base::badbit.
11870 </p>
11871
11872 <p>
11873 The expression on the right-hand-side of the operator==() needs to be
11874 parenthesized in order for the whole expression to ever evaluate to
11875 anything but non-zero.
11876 </p>
11877
11878
11879 <p><b>Proposed resolution:</b></p>
11880 <p>
11881 Add parentheses like so: rdstate()==(state|ios_base::badbit).
11882 </p>
11883
11884
11885
11886
11887 <hr>
11888 <h3><a name="273"></a>273. Missing ios_base qualification on members of a dependent class</h3>
11889 <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>
11890  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
11891 <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>
11892 <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>
11893 <p><b>Discussion:</b></p>
11894 <p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
11895 27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
11896 That's incorrect since the names are members of a dependent base
11897 class (14.6.2 [temp.dep]) and thus not visible.</p>
11898
11899
11900 <p><b>Proposed resolution:</b></p>
11901 <p>Qualify the names with the name of the class of which they are
11902 members, i.e., ios_base.</p>
11903
11904
11905
11906
11907 <hr>
11908 <h3><a name="274"></a>274. a missing/impossible allocator requirement</h3>
11909 <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>
11910  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
11911 <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>
11912 <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>
11913 <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>
11914 <p><b>Discussion:</b></p>
11915 <p>
11916 I see that table 31 in 20.1.5, p3 allows T in std::allocator&lt;T&gt; to be of
11917 any type. But the synopsis in 20.4.1 calls for allocator&lt;&gt;::address() to
11918 be overloaded on reference and const_reference, which is ill-formed for
11919 all T = const U. In other words, this won't work:
11920 </p>
11921
11922 <p>
11923 template class std::allocator&lt;const int&gt;;
11924 </p>
11925
11926 <p>
11927 The obvious solution is to disallow specializations of allocators on
11928 const types. However, while containers' elements are required to be
11929 assignable (which rules out specializations on const T's), I think that
11930 allocators might perhaps be potentially useful for const values in other
11931 contexts. So if allocators are to allow const types a partial
11932 specialization of std::allocator&lt;const T&gt; would probably have to be
11933 provided.
11934 </p>
11935
11936
11937 <p><b>Proposed resolution:</b></p>
11938 <p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
11939
11940     <blockquote><p>
11941     any type
11942     </p></blockquote>
11943
11944 <p>to</p>
11945     <blockquote><p>
11946     any non-const, non-reference type
11947     </p></blockquote>
11948
11949 <p><i>[Redmond: previous proposed resolution was "any non-const,
11950 non-volatile, non-reference type".  Got rid of the "non-volatile".]</i></p>
11951
11952
11953
11954
11955 <p><b>Rationale:</b></p>
11956 <p>
11957 Two resolutions were originally proposed: one that partially
11958 specialized std::allocator for const types, and one that said an
11959 allocator's value type may not be const.  The LWG chose the second.
11960 The first wouldn't be appropriate, because allocators are intended for
11961 use by containers, and const value types don't work in containers.
11962 Encouraging the use of allocators with const value types would only
11963 lead to unsafe code.
11964 </p>
11965 <p>
11966 The original text for proposed resolution 2 was modified so that it
11967 also forbids volatile types and reference types.
11968 </p>
11969
11970 <p><i>[Curaçao: LWG double checked and believes volatile is correctly
11971 excluded from the PR.]</i></p>
11972
11973
11974
11975
11976
11977
11978
11979 <hr>
11980 <h3><a name="275"></a>275. Wrong type in num_get::get() overloads</h3>
11981 <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>
11982  <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-11-02</p>
11983 <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>
11984 <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>
11985 <p><b>Discussion:</b></p>
11986 <p>
11987 In 22.2.2.1.1, we have a list of overloads for num_get&lt;&gt;::get().
11988 There are eight overloads, all of which are identical except for the
11989 last parameter.  The overloads are:
11990 </p>
11991 <ul>
11992 <li> long&amp; </li>
11993 <li> unsigned short&amp; </li>
11994 <li> unsigned int&amp; </li>
11995 <li> unsigned long&amp; </li>
11996 <li> short&amp; </li>
11997 <li> double&amp; </li>
11998 <li> long double&amp; </li>
11999 <li> void*&amp; </li>
12000 </ul>
12001
12002 <p>
12003 There is a similar list, in 22.2.2.1.2, of overloads for
12004 num_get&lt;&gt;::do_get().  In this list, the last parameter has
12005 the types:
12006 </p>
12007 <ul>
12008 <li> long&amp; </li>
12009 <li> unsigned short&amp; </li>
12010 <li> unsigned int&amp; </li>
12011 <li> unsigned long&amp; </li>
12012 <li> float&amp; </li>
12013 <li> double&amp; </li>
12014 <li> long double&amp; </li>
12015 <li> void*&amp; </li>
12016 </ul>
12017
12018 <p>
12019 These two lists are not identical.  They should be, since
12020 <tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
12021 the arguments it was given.
12022 </p>
12023
12024
12025 <p><b>Proposed resolution:</b></p>
12026 <p>In 22.2.2.1.1 [facet.num.get.members], change</p>
12027 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
12028                 ios_base::iostate&amp; err, short&amp; val) const;
12029 </pre>
12030 <p>to</p>
12031 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
12032                 ios_base::iostate&amp; err, float&amp; val) const;
12033 </pre>
12034
12035
12036
12037
12038 <hr>
12039 <h3><a name="276"></a>276. Assignable requirement for container value type overly strict</h3>
12040 <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>
12041  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2000-11-07</p>
12042 <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>
12043 <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>
12044 <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>
12045 <p><b>Discussion:</b></p>
12046 <p>
12047 23.1/3 states that the objects stored in a container must be
12048 Assignable.  23.3.1 [map], paragraph 2,
12049 states that map satisfies all requirements for a container, while in
12050 the same time defining value_type as pair&lt;const Key, T&gt; - a type
12051 that is not Assignable.
12052 </p>
12053
12054 <p>
12055 It should be noted that there exists a valid and non-contradictory
12056 interpretation of the current text. The wording in 23.1/3 avoids
12057 mentioning value_type, referring instead to "objects stored in a
12058 container." One might argue that map does not store objects of
12059 type map::value_type, but of map::mapped_type instead, and that the
12060 Assignable requirement applies to map::mapped_type, not
12061 map::value_type.
12062 </p>
12063
12064 <p>
12065 However, this makes map a special case (other containers store objects of
12066 type value_type) and the Assignable requirement is needlessly restrictive in
12067 general.
12068 </p>
12069
12070 <p>
12071 For example, the proposed resolution of active library issue
12072 <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
12073 means that no set operations can exploit the fact that the stored
12074 objects are Assignable.
12075 </p>
12076
12077 <p>
12078 This is related to, but slightly broader than, closed issue
12079 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>.
12080 </p>
12081
12082
12083 <p><b>Proposed resolution:</b></p>
12084 <p>23.1/3: Strike the trailing part of the sentence:</p>
12085     <blockquote><p>
12086     , and the additional requirements of Assignable types from 23.1/3
12087     </p></blockquote>
12088 <p>so that it reads:</p>
12089     <blockquote><p>
12090     -3- The type of objects stored in these components must meet the
12091     requirements of CopyConstructible types (lib.copyconstructible).
12092     </p></blockquote>
12093
12094 <p>23.1/4: Modify to make clear that this requirement is not for all
12095 containers.  Change to:</p>
12096
12097 <blockquote><p>
12098 -4- Table 64 defines the Assignable requirement.  Some containers
12099 require this property of the types to be stored in the container.  T is
12100 the type used to instantiate the container. t is a value of T, and u is
12101 a value of (possibly const) T.
12102 </p></blockquote>
12103
12104 <p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
12105 CopyConstructible".</p>
12106
12107 <p>23.2.1/2: Add sentence for Assignable requirement.  Change to:</p>
12108
12109 <blockquote><p>
12110 -2- A deque satisfies all of the requirements of a container and of a
12111 reversible container (given in tables in lib.container.requirements) and
12112 of a sequence, including the optional sequence requirements
12113 (lib.sequence.reqmts).  In addition to the requirements on the stored
12114 object described in 23.1[lib.container.requirements], the stored object
12115 must also meet the requirements of Assignable.  Descriptions are
12116 provided here only for operations on deque that are not described in one
12117 of these tables or for operations where there is additional semantic
12118 information.
12119 </p></blockquote>
12120
12121 <p>23.2.2/2:  Add Assignable requirement to specific methods of list.
12122 Change to:</p>
12123
12124 <blockquote>
12125 <p>-2- A list satisfies all of the requirements of a container and of a
12126 reversible container (given in two tables in lib.container.requirements)
12127 and of a sequence, including most of the the optional sequence
12128 requirements (lib.sequence.reqmts). The exceptions are the operator[]
12129 and at member functions, which are not provided.
12130
12131 [Footnote: These member functions are only provided by containers whose
12132 iterators are random access iterators. --- end foonote]
12133 </p>
12134
12135 <p>list does not require the stored type T to be Assignable unless the
12136 following methods are instantiated:
12137
12138 [Footnote: Implementors are permitted but not required to take advantage
12139 of T's Assignable properties for these methods. -- end foonote]
12140 </p>
12141 <pre>     list&lt;T,Allocator&gt;&amp; operator=(const list&lt;T,Allocator&gt;&amp;  x );
12142      template &lt;class InputIterator&gt;
12143        void assign(InputIterator first, InputIterator last);
12144      void assign(size_type n, const T&amp; t);
12145 </pre>
12146
12147
12148 <p>Descriptions are provided here only for operations on list that are not
12149 described in one of these tables or for operations where there is
12150 additional semantic information.</p>
12151 </blockquote>
12152
12153 <p>23.2.4/2:   Add sentence for Assignable requirement.  Change to:</p>
12154
12155 <blockquote><p>
12156 -2- A vector satisfies all of the requirements of a container and of a
12157 reversible container (given in two tables in lib.container.requirements)
12158 and of a sequence, including most of the optional sequence requirements
12159 (lib.sequence.reqmts). The exceptions are the push_front and pop_front
12160 member functions, which are not provided.  In addition to the
12161 requirements on the stored object described in
12162 23.1[lib.container.requirements], the stored object must also meet the
12163 requirements of Assignable.  Descriptions are provided here only for
12164 operations on vector that are not described in one of these tables or
12165 for operations where there is additional semantic information.
12166 </p></blockquote>
12167
12168
12169 <p><b>Rationale:</b></p>
12170 <p>list, set, multiset, map, multimap are able to store non-Assignables.
12171 However, there is some concern about <tt>list&lt;T&gt;</tt>:
12172 although in general there's no reason for T to be Assignable, some
12173 implementations of the member functions <tt>operator=</tt> and
12174 <tt>assign</tt> do rely on that requirement.  The LWG does not want
12175 to forbid such implementations.</p>
12176
12177 <p>Note that the type stored in a standard container must still satisfy
12178 the requirements of the container's allocator; this rules out, for
12179 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>
12180 for more details.
12181 </p>
12182
12183 <p>In principle we could also relax the "Assignable" requirement for
12184 individual <tt>vector</tt> member functions, such as
12185 <tt>push_back</tt>.  However, the LWG did not see great value in such
12186 selective relaxation.  Doing so would remove implementors' freedom to
12187 implement <tt>vector::push_back</tt> in terms of
12188 <tt>vector::insert</tt>.</p>
12189
12190
12191
12192
12193
12194 <hr>
12195 <h3><a name="278"></a>278. What does iterator validity mean?</h3>
12196 <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>
12197  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2000-11-27</p>
12198 <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>
12199 <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>
12200 <p><b>Discussion:</b></p>
12201 <p>
12202 Section 23.2.3.4 [list.ops] states that
12203 </p>
12204 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
12205 </pre>
12206 <p>
12207 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
12208 </p>
12209
12210 <p>
12211 But what does the C++ Standard mean by "invalidate"?  You
12212 can still dereference the iterator to a spliced list element, but
12213 you'd better not use it to delimit a range within the original
12214 list. For the latter operation, it has definitely lost some of its
12215 validity.
12216 </p>
12217
12218 <p>
12219 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>,
12220 then we'd better clarify that a "valid" iterator need no
12221 longer designate an element within the same container as it once did.
12222 We then have to clarify what we mean by invalidating a past-the-end
12223 iterator, as when a vector or string grows by reallocation. Clearly,
12224 such an iterator has a different kind of validity. Perhaps we should
12225 introduce separate terms for the two kinds of "validity."
12226 </p>
12227
12228
12229 <p><b>Proposed resolution:</b></p>
12230 <p>Add the following text to the end of section 24.1 [iterator.requirements],
12231 after paragraph 5:</p>
12232 <blockquote><p>
12233 An <i>invalid</i> iterator is an iterator that may be
12234 singular. [Footnote: This definition applies to pointers, since
12235 pointers are iterators. The effect of dereferencing an iterator that
12236 has been invalidated is undefined.]
12237 </p></blockquote>
12238
12239 <p><i>[post-Copenhagen: Matt provided wording.]</i></p>
12240
12241
12242 <p><i>[Redmond: General agreement with the intent, some objections to
12243 the wording.  Dave provided new wording.]</i></p>
12244
12245
12246
12247 <p><b>Rationale:</b></p>
12248 <p>This resolution simply defines a term that the Standard uses but
12249   never defines, "invalid", in terms of a term that is defined,
12250   "singular".</p>
12251
12252 <p>Why do we say "may be singular", instead of "is singular"?  That's
12253   becuase a valid iterator is one that is known to be nonsingular.
12254   Invalidating an iterator means changing it in such a way that it's
12255   no longer known to be nonsingular.  An example: inserting an
12256   element into the middle of a vector is correctly said to invalidate
12257   all iterators pointing into the vector.  That doesn't necessarily
12258   mean they all become singular.</p>
12259
12260
12261
12262
12263
12264 <hr>
12265 <h3><a name="280"></a>280. Comparison of reverse_iterator to const reverse_iterator</h3>
12266 <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>
12267  <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-11-27</p>
12268 <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>
12269 <p><b>Discussion:</b></p>
12270 <p>
12271 This came from an email from Steve Cleary to Fergus in reference to
12272 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
12273 this in Toronto and believed it should be a separate issue.  There was
12274 also some reservations about whether this was a worthwhile problem to
12275 fix.
12276 </p>
12277
12278 <p>
12279 Steve said: "Fixing reverse_iterator. std::reverse_iterator can
12280 (and should) be changed to preserve these additional
12281 requirements." He also said in email that it can be done without
12282 breaking user's code: "If you take a look at my suggested
12283 solution, reverse_iterator doesn't have to take two parameters; there
12284 is no danger of breaking existing code, except someone taking the
12285 address of one of the reverse_iterator global operator functions, and
12286 I have to doubt if anyone has ever done that. . .  <i>But</i>, just in
12287 case they have, you can leave the old global functions in as well --
12288 they won't interfere with the two-template-argument functions.  With
12289 that, I don't see how <i>any</i> user code could break."
12290 </p>
12291
12292
12293 <p><b>Proposed resolution:</b></p>
12294 <p>
12295 <b>Section:</b> 24.4.1.1 [reverse.iterator]
12296 add/change the following declarations:</p>
12297 <pre>  A) Add a templated assignment operator, after the same manner
12298         as the templated copy constructor, i.e.:
12299
12300   template &lt; class U &gt;
12301   reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
12302
12303   B) Make all global functions (except the operator+) have
12304   two template parameters instead of one, that is, for
12305   operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
12306
12307        template &lt; class Iterator &gt;
12308        typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
12309                  const reverse_iterator&lt; Iterator &gt;&amp; x,
12310                  const reverse_iterator&lt; Iterator &gt;&amp; y);
12311
12312   with:
12313
12314       template &lt; class Iterator1, class Iterator2 &gt;
12315       typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
12316                  const reverse_iterator &lt; Iterator1 &gt; &amp; x,
12317                  const reverse_iterator &lt; Iterator2 &gt; &amp; y);
12318 </pre>
12319 <p>
12320 Also make the addition/changes for these signatures in
12321 24.4.1.3 [reverse.iter.ops].
12322 </p>
12323
12324 <p><i>[
12325 Copenhagen: The LWG is concerned that the proposed resolution
12326 introduces new overloads.  Experience shows that introducing
12327 overloads is always risky, and that it would be inappropriate to
12328 make this change without implementation experience.  It may be
12329 desirable to provide this feature in a different way.
12330 ]</i></p>
12331
12332
12333 <p><i>[
12334 Lillehammer: We now have implementation experience, and agree that
12335 this solution is safe and correct.
12336 ]</i></p>
12337
12338
12339
12340
12341
12342
12343
12344 <hr>
12345 <h3><a name="281"></a>281. std::min() and max() requirements overly restrictive</h3>
12346 <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>
12347  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-02</p>
12348 <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>
12349 <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>
12350 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#486">486</a></p>
12351 <p><b>Discussion:</b></p>
12352 <p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
12353 requirements of <tt>LessThanComparable</tt> ( [lessthancomparable])
12354 and <tt>CopyConstructible</tt> (20.1.1 [utility.arg.requirements]).
12355 Since the functions take and return their arguments and result by
12356 const reference, I believe the <tt>CopyConstructible</tt> requirement
12357 is unnecessary.
12358 </p>
12359
12360
12361 <p><b>Proposed resolution:</b></p>
12362 <p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
12363 25.3.7, p1 with</p>
12364 <p><b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt>
12365 ( [lessthancomparable]).
12366 </p>
12367 <p>and replace 25.3.7, p4 with</p>
12368 <p><b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt>
12369 ( [lessthancomparable]).
12370 </p>
12371
12372
12373
12374
12375 <hr>
12376 <h3><a name="282"></a>282. What types does numpunct grouping refer to?</h3>
12377 <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>
12378  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2000-12-05</p>
12379 <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>
12380 <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>
12381 <p><b>Discussion:</b></p>
12382 <p>
12383 Paragraph 16 mistakenly singles out integral types for inserting
12384 thousands_sep() characters.  This conflicts with the syntax for floating
12385 point numbers described under 22.2.3.1/2.
12386 </p>
12387
12388
12389 <p><b>Proposed resolution:</b></p>
12390 <p>Change paragraph 16 from:</p>
12391
12392 <blockquote><p>
12393 For integral types, punct.thousands_sep() characters are inserted into
12394 the sequence as determined by the value returned by punct.do_grouping()
12395 using the method described in 22.2.3.1.2 [facet.numpunct.virtuals].
12396 </p></blockquote>
12397
12398 <p>To:</p>
12399
12400 <blockquote><p>
12401 For arithmetic types, punct.thousands_sep() characters are inserted into
12402 the sequence as determined by the value returned by punct.do_grouping()
12403 using the method described in 22.2.3.1.2 [facet.numpunct.virtuals].
12404 </p></blockquote>
12405
12406 <p><i>[
12407 Copenhagen: Opinions were divided about whether this is actually an
12408 inconsistency, but at best it seems to have been unintentional.  This
12409 is only an issue for floating-point output: The standard is
12410 unambiguous that implementations must parse thousands_sep characters
12411 when performing floating-point.  The standard is also unambiguous that
12412 this requirement does not apply to the "C" locale.
12413 ]</i></p>
12414
12415
12416 <p><i>[
12417 A survey of existing practice is needed; it is believed that some
12418 implementations do insert thousands_sep characters for floating-point
12419 output and others fail to insert thousands_sep characters for
12420 floating-point input even though this is unambiguously required by the
12421 standard.
12422 ]</i></p>
12423
12424
12425 <p><i>[Post-Curaçao: the above proposed resolution is the consensus of
12426 Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
12427
12428
12429
12430
12431
12432
12433 <hr>
12434 <h3><a name="283"></a>283. std::replace() requirement incorrect/insufficient</h3>
12435 <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>
12436  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-15</p>
12437 <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>
12438 <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>
12439 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#483">483</a></p>
12440 <p><b>Discussion:</b></p>
12441 <p>
12442 (revision of the further discussion)
12443 There are a number of problems with the requires clauses for the
12444 algorithms in 25.1 and 25.2. The requires clause of each algorithm
12445 should describe the necessary and sufficient requirements on the inputs
12446 to the algorithm such that the algorithm compiles and runs properly.
12447 Many of the requires clauses fail to do this. Here is a summary of the kinds
12448 of mistakes:
12449 </p>
12450
12451 <ol>
12452 <li>
12453 Use of EqualityComparable, which only puts requirements on a single
12454 type, when in fact an equality operator is required between two
12455 different types, typically either T and the iterator's value type
12456 or between the value types of two different iterators.
12457 </li>
12458 <li>
12459 Use of Assignable for T when in fact what was needed is Assignable
12460 for the value_type of the iterator, and convertability from T to the
12461 value_type of the iterator. Or for output iterators, the requirement
12462 should be that T is writable to the iterator (output iterators do
12463 not have value types).
12464 </li>
12465 </ol>
12466
12467 <p>
12468 Here is the list of algorithms that contain mistakes:
12469 </p>
12470
12471 <ul>
12472 <li>25.1.2 std::find</li>
12473 <li>25.1.6 std::count</li>
12474 <li>25.1.8 std::equal</li>
12475 <li>25.1.9 std::search, std::search_n</li>
12476 <li>25.2.4 std::replace, std::replace_copy</li>
12477 <li>25.2.5 std::fill</li>
12478 <li>25.2.7 std::remove, std::remove_copy</li>
12479 </ul>
12480
12481 <p>
12482 Also, in the requirements for EqualityComparable, the requirement that
12483 the operator be defined for const objects is lacking.
12484 </p>
12485
12486
12487
12488 <p><b>Proposed resolution:</b></p>
12489
12490 <p>20.1.1 Change p1 from</p>
12491
12492 <p>In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
12493 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
12494 values of type <tt>T</tt>.
12495 </p>
12496
12497 <p>to</p>
12498
12499 <p>
12500 In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
12501 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
12502 values of type <tt>const T</tt>.
12503 </p>
12504
12505 <p>25 Between p8 and p9</p>
12506
12507 <p>Add the following sentence:</p>
12508
12509 <p>When the description of an algorithm gives an expression such as
12510 <tt>*first == value</tt> for a condition, it is required that the expression
12511 evaluate to either true or false in boolean contexts.</p>
12512
12513 <p>25.1.2 Change p1 by deleting the requires clause.</p>
12514
12515 <p>25.1.6 Change p1 by deleting the requires clause.</p>
12516
12517 <p>25.1.9</p>
12518
12519 <p>Change p4 from</p>
12520
12521 <p>-4- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt>
12522 (20.1.1), type Size is convertible to integral type (4.7.12.3).
12523 </p>
12524
12525 <p>to</p>
12526
12527 <p>-4- Requires: The type <tt>Size</tt> is convertible to integral
12528 type (4.7.12.3).</p>
12529
12530 <p>25.2.4 Change p1 from</p>
12531
12532 <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>
12533
12534 <p>to</p>
12535
12536 <p>-1- Requires: The expression <tt>*first = new_value</tt> must be valid.</p>
12537
12538 <p>and change p4 from</p>
12539
12540 <p>-4- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1) (and,
12541 for <tt>replace_copy()</tt>, <tt>EqualityComparable</tt>
12542 (20.1.1)). The ranges <tt>[first, last)</tt> and <tt>[result, result +
12543 (last - first))</tt> shall not overlap.</p>
12544
12545 <p>to</p>
12546
12547 <p>-4- Requires: The results of the expressions <tt>*first</tt> and
12548 <tt>new_value</tt> must be writable to the result output iterator. The
12549 ranges <tt>[first, last)</tt> and <tt>[result, result + (last -
12550 first))</tt> shall not overlap.</p>
12551
12552
12553 <p>25.2.5 Change p1 from</p>
12554
12555 <p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1). The
12556 type <tt>Size</tt> is convertible to an integral type (4.7.12.3).</p>
12557
12558 <p>to</p>
12559
12560 <p>-1- Requires: The expression <tt>value</tt> must be is writable to
12561 the output iterator. The type <tt>Size</tt> is convertible to an
12562 integral type (4.7.12.3).</p>
12563
12564 <p>25.2.7 Change p1 from</p>
12565
12566 <p>-1- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> (20.1.1).</p>
12567
12568 <p>to</p>
12569
12570 <p>
12571 -1- Requires: The value type of the iterator must be
12572 <tt>Assignable</tt> (23.1).
12573 </p>
12574
12575
12576
12577 <p><b>Rationale:</b></p>
12578 <p>
12579 The general idea of the proposed solution is to remove the faulty
12580 requires clauses and let the returns and effects clauses speak for
12581 themselves. That is, the returns clauses contain expressions that must
12582 be valid, and therefore already imply the correct requirements. In
12583 addition, a sentence is added at the beginning of chapter 25 saying
12584 that expressions given as conditions must evaluate to true or false in
12585 a boolean context. An alternative would be to say that the type of
12586 these condition expressions must be literally bool, but that would be
12587 imposing a greater restriction that what the standard currently says
12588 (which is convertible to bool).
12589 </p>
12590
12591
12592
12593
12594
12595 <hr>
12596 <h3><a name="284"></a>284. unportable example in 20.3.7, p6</h3>
12597 <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>
12598  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-26</p>
12599 <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>
12600 <p><b>Discussion:</b></p>
12601 <p>The example in 20.5.7 [comparisons], p6 shows how to use the C
12602 library function <tt>strcmp()</tt> with the function pointer adapter
12603 <tt>ptr_fun()</tt>. But since it's unspecified whether the C library
12604 functions have <tt>extern "C"</tt> or <tt>extern
12605 "C++"</tt> linkage [17.4.2.2 [using.linkage]], and since
12606 function pointers with different the language linkage specifications
12607 (7.5 [dcl.link]) are incompatible, whether this example is
12608 well-formed is unspecified.
12609 </p>
12610
12611
12612 <p><b>Proposed resolution:</b></p>
12613 <p>Change 20.5.7 [comparisons] paragraph 6 from:</p>
12614 <blockquote>
12615   <p>[<i>Example:</i></p>
12616   <pre>    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
12617   </pre>
12618   <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
12619 </blockquote>
12620
12621
12622 <p>to:</p>
12623 <blockquote>
12624   <p>[<i>Example:</i></p>
12625   <pre>    int compare(const char*, const char*);
12626     replace_if(v.begin(), v.end(),
12627                not1(bind2nd(ptr_fun(compare), "abc")), "def");
12628   </pre>
12629   <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
12630 </blockquote>
12631
12632 <p>Also, remove footnote 215 in that same paragraph.</p>
12633
12634 <p><i>[Copenhagen: Minor change in the proposed resolution.  Since this
12635 issue deals in part with C and C++ linkage, it was believed to be too
12636 confusing for the strings in the example to be "C" and "C++".
12637 ]</i></p>
12638
12639
12640 <p><i>[Redmond: More minor changes.  Got rid of the footnote (which
12641 seems to make a sweeping normative requirement, even though footnotes
12642 aren't normative), and changed the sentence after the footnote so that
12643 it corresponds to the new code fragment.]</i></p>
12644
12645
12646
12647
12648
12649
12650 <hr>
12651 <h3><a name="285"></a>285. minor editorial errors in fstream ctors</h3>
12652 <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>
12653  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-31</p>
12654 <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>
12655 <p><b>Discussion:</b></p>
12656 <p>27.8.1.7 [ifstream.cons], p2, 27.8.1.11 [ofstream.cons], p2, and
12657 27.8.1.15 [fstream.cons], p2 say about the effects of each constructor:
12658 </p>
12659
12660 <p>... If that function returns a null pointer, calls
12661 <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
12662 </p>
12663
12664 <p>The parenthetical note doesn't apply since the ctors cannot throw an
12665 exception due to the requirement in 27.4.4.1 [basic.ios.cons], p3
12666 that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
12667 </p>
12668
12669
12670 <p><b>Proposed resolution:</b></p>
12671 <p>
12672 Strike the parenthetical note from the Effects clause in each of the
12673 paragraphs mentioned above.
12674 </p>
12675
12676
12677
12678
12679 <hr>
12680 <h3><a name="286"></a>286. &lt;cstdlib&gt; requirements missing size_t typedef</h3>
12681 <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>
12682  <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
12683 <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>
12684 <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>
12685 <p><b>Discussion:</b></p>
12686 <p>
12687 The &lt;cstdlib&gt; header file contains prototypes for bsearch and
12688 qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
12689 prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
12690 require the typedef size_t. Yet size_t is not listed in the
12691 &lt;cstdlib&gt; synopsis table 78 in section 25.4.
12692 </p>
12693
12694
12695 <p><b>Proposed resolution:</b></p>
12696 <p>
12697 Add the type size_t to Table 78 (section 25.4) and add
12698 the type size_t &lt;cstdlib&gt; to Table 97 (section C.2).
12699 </p>
12700
12701
12702 <p><b>Rationale:</b></p>
12703 <p>Since size_t is in &lt;stdlib.h&gt;, it must also be in &lt;cstdlib&gt;.</p>
12704
12705
12706
12707
12708
12709 <hr>
12710 <h3><a name="288"></a>288. &lt;cerrno&gt; requirements missing macro EILSEQ</h3>
12711 <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>
12712  <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
12713 <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>
12714 <p><b>Discussion:</b></p>
12715 <p>
12716 ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
12717 of macros defined in &lt;errno.h&gt; is adjusted to include a new
12718 macro, EILSEQ"
12719 </p>
12720
12721 <p>
12722 ISO/IEC 14882:1998(E) section 19.3 does not refer
12723 to the above amendment.
12724 </p>
12725
12726
12727
12728 <p><b>Proposed resolution:</b></p>
12729 <p>
12730 Update Table 26 (section 19.3) "Header  &lt;cerrno&gt; synopsis"
12731 and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
12732 </p>
12733
12734
12735
12736
12737
12738 <hr>
12739 <h3><a name="291"></a>291. Underspecification of set algorithms</h3>
12740 <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>
12741  <b>Submitter:</b> Matt Austern <b>Date:</b> 2001-01-03</p>
12742 <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>
12743 <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>
12744 <p><b>Discussion:</b></p>
12745 <p>
12746 The standard library contains four algorithms that compute set
12747 operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
12748 <tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>.  Each
12749 of these algorithms takes two sorted ranges as inputs, and writes the
12750 output of the appropriate set operation to an output range.  The elements
12751 in the output range are sorted.
12752 </p>
12753
12754 <p>
12755 The ordinary mathematical definitions are generalized so that they
12756 apply to ranges containing multiple copies of a given element.  Two
12757 elements are considered to be "the same" if, according to an
12758 ordering relation provided by the user, neither one is less than the
12759 other.  So, for example, if one input range contains five copies of an
12760 element and another contains three, the output range of <tt>set_union</tt>
12761 will contain five copies, the output range of
12762 <tt>set_intersection</tt> will contain three, the output range of
12763 <tt>set_difference</tt> will contain two, and the output range of
12764 <tt>set_symmetric_difference</tt> will contain two.
12765 </p>
12766
12767 <p>
12768 Because two elements can be "the same" for the purposes
12769 of these set algorithms, without being identical in other respects
12770 (consider, for example, strings under case-insensitive comparison),
12771 this raises a number of unanswered questions:
12772 </p>
12773
12774 <ul>
12775 <li>If we're copying an element that's present in both of the
12776 input ranges, which one do we copy it from?</li>
12777 <li>If there are <i>n</i> copies of an element in the relevant
12778 input range, and the output range will contain fewer copies (say
12779 <i>m</i>) which ones do we choose?  The first <i>m</i>, or the last
12780 <i>m</i>, or something else?</li>
12781 <li>Are these operations stable?  That is, does a run of equivalent
12782 elements appear in the output range in the same order as as it
12783 appeared in the input range(s)?</li>
12784 </ul>
12785
12786 <p>
12787 The standard should either answer these questions, or explicitly
12788 say that the answers are unspecified.  I prefer the former option,
12789 since, as far as I know, all existing implementations behave the
12790 same way.
12791 </p>
12792
12793
12794
12795 <p><b>Proposed resolution:</b></p>
12796
12797 <p>Add the following to the end of 25.3.5.2 [set.union] paragraph 5:</p>
12798 <blockquote><p>
12799 If [first1, last1) contains <i>m</i> elements that are equivalent to
12800 each other and [first2, last2) contains <i>n</i> elements that are
12801 equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
12802 will be copied to the output range: all <i>m</i> of these elements
12803 from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
12804 [first2, last2), in that order.
12805 </p></blockquote>
12806
12807 <p>Add the following to the end of 25.3.5.3 [set.intersection] paragraph 5:</p>
12808 <blockquote><p>
12809 If [first1, last1) contains <i>m</i> elements that are equivalent to each
12810 other and [first2, last2) contains <i>n</i> elements that are
12811 equivalent to them, the first min(<i>m</i>, <i>n</i>) of those
12812 elements from [first1, last1) are copied to the output range.
12813 </p></blockquote>
12814
12815 <p>Add a new paragraph, <b>Notes</b>, after 25.3.5.4 [set.difference]
12816 paragraph 4:</p>
12817 <blockquote><p>
12818 If [first1, last1) contains <i>m</i> elements that are equivalent to each
12819 other and [first2, last2) contains <i>n</i> elements that are
12820 equivalent to them, the last max(<i>m-n</i>, 0) elements from
12821 [first1, last1) are copied to the output range.
12822 </p></blockquote>
12823
12824 <p>Add a new paragraph, <b>Notes</b>, after 25.3.5.5 [set.symmetric.difference]
12825 paragraph 4:</p>
12826 <blockquote><p>
12827 If [first1, last1) contains <i>m</i> elements that are equivalent to
12828 each other and [first2, last2) contains <i>n</i> elements that are
12829 equivalent to them, then |<i>m - n</i>| of those elements will be
12830 copied to the output range: the last <i>m - n</i> of these elements
12831 from [first1, last1) if <i>m</i> &gt; <i>n</i>, and the last <i>n -
12832 m</i> of these elements from [first2, last2) if <i>m</i> &lt; <i>n</i>.
12833 </p></blockquote>
12834
12835 <p><i>[Santa Cruz: it's believed that this language is clearer than
12836   what's in the Standard.  However, it's also believed that the
12837   Standard may already make these guarantees (although not quite in
12838   these words).  Bill and Howard will check and see whether they think
12839   that some or all of these changes may be redundant.  If so, we may
12840   close this issue as NAD.]</i></p>
12841
12842
12843
12844
12845 <p><b>Rationale:</b></p>
12846 <p>For simple cases, these descriptions are equivalent to what's
12847   already in the Standard.  For more complicated cases, they describe
12848   the behavior of existing implementations.</p>
12849
12850
12851
12852
12853
12854 <hr>
12855 <h3><a name="292"></a>292. effects of a.copyfmt (a)</h3>
12856 <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>
12857  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-05</p>
12858 <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>
12859 <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>
12860 <p><b>Discussion:</b></p>
12861 <p>The Effects clause of the member function <tt>copyfmt()</tt> in
12862 27.4.4.2, p15 doesn't consider the case where the left-hand side
12863 argument is identical to the argument on the right-hand side, that is
12864 <tt>(this == &amp;rhs)</tt>.  If the two arguments are identical there
12865 is no need to copy any of the data members or call any callbacks
12866 registered with <tt>register_callback()</tt>.  Also, as Howard Hinnant
12867 points out in message c++std-lib-8149 it appears to be incorrect to
12868 allow the object to fire <tt>erase_event</tt> followed by
12869 <tt>copyfmt_event</tt> since the callback handling the latter event
12870 may inadvertently attempt to access memory freed by the former.
12871 </p>
12872
12873
12874 <p><b>Proposed resolution:</b></p>
12875 <p>Change the Effects clause in 27.4.4.2, p15 from</p>
12876
12877 <blockquote><p>
12878 <b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
12879 the corresponding member objects of <tt>rhs</tt>, except that...
12880 </p></blockquote>
12881
12882 <p>to</p>
12883
12884 <blockquote><p>
12885 <b>-15- Effects:</b>If <tt>(this == &amp;rhs)</tt> does nothing. Otherwise
12886 assigns to the member objects of <tt>*this</tt> the corresponding member
12887 objects of <tt>rhs</tt>, except that...
12888 </p></blockquote>
12889
12890
12891
12892
12893 <hr>
12894 <h3><a name="294"></a>294. User defined macros and standard headers</h3>
12895 <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>
12896  <b>Submitter:</b> James Kanze <b>Date:</b> 2001-01-11</p>
12897 <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>
12898 <p><b>Discussion:</b></p>
12899 <p>Paragraph 2 of 17.4.3.1.1 [macro.names] reads: "A
12900 translation unit that includes a header shall not contain any macros
12901 that define names declared in that header." As I read this, it
12902 would mean that the following program is legal:</p>
12903
12904 <pre>  #define npos 3.14
12905   #include &lt;sstream&gt;
12906 </pre>
12907
12908 <p>since npos is not defined in &lt;sstream&gt;.  It is, however, defined
12909 in &lt;string&gt;, and it is hard to imagine an implementation in
12910 which &lt;sstream&gt; didn't include &lt;string&gt;.</p>
12911
12912 <p>I think that this phrase was probably formulated before it was
12913 decided that a standard header may freely include other standard
12914 headers.  The phrase would be perfectly appropriate for C, for
12915 example.  In light of 17.4.4.1 [res.on.headers] paragraph 1, however,
12916 it isn't stringent enough.</p>
12917
12918
12919 <p><b>Proposed resolution:</b></p>
12920 <p>For 17.4.3.1.1 [macro.names], replace the current wording, which reads:</p>
12921 <blockquote>
12922      <p>Each name defined as a macro in a header is reserved to the
12923      implementation for any use if the translation unit includes
12924      the header.168)</p>
12925
12926      <p>A translation unit that includes a header shall not contain any
12927      macros that define names declared or defined in that header. Nor shall
12928      such a translation unit define macros for names lexically
12929      identical to keywords.</p>
12930
12931      <p>168) It is not permissible to remove a library macro definition by
12932      using the #undef directive.</p>
12933 </blockquote>
12934
12935 <p>with the wording:</p>
12936
12937 <blockquote>
12938      <p>A translation unit that includes a standard library header shall not
12939      #define or #undef names declared in any standard library header.</p>
12940
12941      <p>A translation unit shall not #define or #undef names lexically
12942      identical to keywords.</p>
12943 </blockquote>
12944
12945 <p><i>[Lillehammer: Beman provided new wording]</i></p>
12946
12947
12948
12949
12950
12951
12952 <hr>
12953 <h3><a name="295"></a>295. Is abs defined in &lt;cmath&gt;?</h3>
12954 <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>
12955  <b>Submitter:</b> Jens Maurer <b>Date:</b> 2001-01-12</p>
12956 <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>
12957 <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>
12958 <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>
12959 <p><b>Discussion:</b></p>
12960 <p>
12961 Table 80 lists the contents of the &lt;cmath&gt; header.  It does not
12962 list <tt>abs()</tt>.  However, 26.5, paragraph 6, which lists added
12963 signatures present in &lt;cmath&gt;, does say that several overloads
12964 of <tt>abs()</tt> should be defined in &lt;cmath&gt;.
12965 </p>
12966
12967
12968 <p><b>Proposed resolution:</b></p>
12969 <p>
12970 Add <tt>abs</tt> to Table 80.  Also, remove the parenthetical list
12971 of functions "(abs(), div(), rand(), srand())" from 26.5 [numarray],
12972 paragraph 1.
12973 </p>
12974
12975 <p><i>[Copenhagen: Modified proposed resolution so that it also gets
12976 rid of that vestigial list of functions in paragraph 1.]</i></p>
12977
12978
12979
12980
12981 <p><b>Rationale:</b></p>
12982 <p>All this DR does is fix a typo; it's uncontroversial.  A
12983 separate question is whether we're doing the right thing in
12984 putting some overloads in &lt;cmath&gt; that we aren't also
12985 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>
12986
12987
12988
12989
12990
12991 <hr>
12992 <h3><a name="297"></a>297. const_mem_fun_t&lt;&gt;::argument_type should be const T*</h3>
12993 <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>
12994  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-06</p>
12995 <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>
12996 <p><b>Discussion:</b></p>
12997 <p>The class templates <tt>const_mem_fun_t</tt> in 20.5.8, p8 and
12998 <tt>const_mem_fun1_t</tt>
12999 in 20.5.8, p9 derive from <tt>unary_function&lt;T*, S&gt;</tt>, and
13000 <tt>binary_function&lt;T*,
13001 A, S&gt;</tt>, respectively. Consequently, their <tt>argument_type</tt>, and
13002 <tt>first_argument_type</tt>
13003 members, respectively, are both defined to be <tt>T*</tt> (non-const).
13004 However, their function call member operator takes a <tt>const T*</tt>
13005 argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
13006 T*</tt> instead, so that one can easily refer to it in generic code. The
13007 example below derived from existing code fails to compile due to the
13008 discrepancy:
13009 </p>
13010
13011 <p><tt>template &lt;class T&gt;</tt>
13012 <br><tt>void foo (typename T::argument_type arg)&nbsp;&nbsp; // #1</tt>
13013 <br><tt>{</tt>
13014 <br><tt>&nbsp;&nbsp;&nbsp; typename T::result_type (T::*pf) (typename
13015 T::argument_type)
13016 const =&nbsp;&nbsp; // #2</tt>
13017 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;T::operator();</tt>
13018 <br><tt>}</tt>
13019 </p>
13020
13021 <p><tt>struct X { /* ... */ };</tt></p>
13022
13023 <p><tt>int main ()</tt>
13024 <br><tt>{</tt>
13025 <br><tt>&nbsp;&nbsp;&nbsp; const X x;</tt>
13026 <br><tt>&nbsp;&nbsp;&nbsp; foo&lt;std::const_mem_fun_t&lt;void, X&gt;
13027 &gt;(&amp;x);&nbsp;&nbsp;
13028 // #3</tt>
13029 <br><tt>}</tt>
13030 </p>
13031
13032 <p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
13033 <br>#2 the type of the pointer is incompatible with the type of the member
13034 function
13035 <br>#3 the address of a constant being passed to a function taking a non-const
13036 <tt>X*</tt>
13037 </p>
13038
13039
13040 <p><b>Proposed resolution:</b></p>
13041 <p>Replace the top portion of the definition of the class template
13042 const_mem_fun_t in 20.5.8, p8
13043 </p>
13044 <p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
13045 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
13046 unary_function&lt;T*, S&gt; {</tt>
13047 </p>
13048 <p>with</p>
13049 <p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
13050 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
13051 unary_function&lt;<b>const</b> T*, S&gt; {</tt>
13052 </p>
13053 <p>Also replace the top portion of the definition of the class template
13054 const_mem_fun1_t in 20.5.8, p9</p>
13055 <p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
13056 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
13057 binary_function&lt;T*, A, S&gt; {</tt>
13058 </p>
13059 <p>with</p>
13060 <p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
13061 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
13062 binary_function&lt;<b>const</b> T*, A, S&gt; {</tt>
13063 </p>
13064
13065
13066 <p><b>Rationale:</b></p>
13067 <p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
13068 and the argument type itself, are not the same.</p>
13069
13070
13071
13072
13073
13074 <hr>
13075 <h3><a name="298"></a>298. ::operator delete[] requirement incorrect/insufficient</h3>
13076 <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>
13077  <b>Submitter:</b> John A. Pedretti <b>Date:</b> 2001-01-10</p>
13078 <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>
13079 <p><b>Discussion:</b></p>
13080 <p>
13081 The default behavior of <tt>operator delete[]</tt> described in 18.5.1.2, p12 -
13082 namely that for non-null value of <i>ptr</i>, the operator reclaims storage
13083 allocated by the earlier call to the default <tt>operator new[]</tt> - is not
13084 correct in all cases. Since the specified <tt>operator new[]</tt> default
13085 behavior is to call <tt>operator new</tt> (18.5.1.2, p4, p8), which can be
13086 replaced, along with <tt>operator delete</tt>, by the user, to implement their
13087 own memory management, the specified default behavior of<tt> operator
13088 delete[]</tt> must be to call <tt>operator delete</tt>.
13089 </p>
13090
13091
13092 <p><b>Proposed resolution:</b></p>
13093 <p>Change 18.5.1.2, p12 from</p>
13094 <blockquote><p>
13095 <b>-12-</b> <b>Default behavior:</b></p>
13096 <ul>
13097 <li>
13098 For a null value of <i><tt>ptr</tt></i> , does nothing.
13099 </li>
13100 <li>
13101 Any other value of <i><tt>ptr</tt></i> shall be a value returned
13102 earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
13103 [Footnote: The value must not have been invalidated by an intervening
13104 call to <tt>operator delete[](void*)</tt> (17.4.3.7 [res.on.arguments]).
13105 --- end footnote]
13106 For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
13107 allocated by the earlier call to the default <tt>operator new[]</tt>.
13108 </li>
13109 </ul>
13110 </blockquote>
13111
13112 <p>to</p>
13113
13114 <blockquote><p>
13115 <b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
13116 delete(</tt><i>ptr</i>)
13117 or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
13118 </p></blockquote>
13119 <p>and expunge paragraph 13.</p>
13120
13121
13122
13123
13124 <hr>
13125 <h3><a name="300"></a>300. list::merge() specification incomplete</h3>
13126 <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>
13127  <b>Submitter:</b> John Pedretti <b>Date:</b> 2001-01-23</p>
13128 <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>
13129 <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>
13130 <p><b>Discussion:</b></p>
13131 <p>
13132 The "Effects" clause for list::merge() (23.2.3.4 [list.ops], p23)
13133 appears to be incomplete: it doesn't cover the case where the argument
13134 list is identical to *this (i.e., this == &amp;x). The requirement in the
13135 note in p24 (below) is that x be empty after the merge which is surely
13136 unintended in this case.
13137 </p>
13138
13139
13140 <p><b>Proposed resolution:</b></p>
13141 <p>In 23.2.3.4 [list.ops], replace paragraps 23-25 with:</p>
13142 <blockquote>
13143 <p>
13144 23 Effects: if (&amp;x == this) does nothing; otherwise, merges the two
13145 sorted ranges [begin(), end()) and [x.begin(), x.end()).  The result
13146 is a range in which the elements will be sorted in non-decreasing
13147 order according to the ordering defined by comp; that is, for every
13148 iterator i in the range other than the first, the condition comp(*i,
13149 *(i - 1)) will be false.
13150 </p>
13151
13152 <p>
13153 24 Notes: Stable: if (&amp;x != this), then for equivalent elements in the
13154 two original ranges, the elements from the original range [begin(),
13155 end()) always precede the elements from the original range [x.begin(),
13156 x.end()).  If (&amp;x != this) the range [x.begin(), x.end()) is empty
13157 after the merge.
13158 </p>
13159
13160 <p>
13161 25 Complexity: At most size() + x.size() - 1 applications of comp if
13162 (&amp;x !  = this); otherwise, no applications of comp are performed.  If
13163 an exception is thrown other than by a comparison there are no
13164 effects.
13165 </p>
13166
13167 </blockquote>
13168
13169 <p><i>[Copenhagen: The original proposed resolution did not fix all of
13170 the problems in 23.2.3.4 [list.ops], p22-25.  Three different
13171 paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
13172 Changing p23, without changing the other two, appears to introduce
13173 contradictions.  Additionally, "merges the argument list into the
13174 list" is excessively vague.]</i></p>
13175
13176
13177 <p><i>[Post-Curaçao: Robert Klarer provided new wording.]</i></p>
13178
13179
13180
13181
13182
13183
13184
13185 <hr>
13186 <h3><a name="301"></a>301. basic_string template ctor effects clause omits allocator argument</h3>
13187 <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>
13188  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-27</p>
13189 <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>
13190 <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>
13191 <p><b>Discussion:</b></p>
13192 <p>
13193 The effects clause for the basic_string template ctor in 21.3.1, p15
13194 leaves out the third argument of type Allocator. I believe this to be
13195 a mistake.
13196 </p>
13197
13198
13199 <p><b>Proposed resolution:</b></p>
13200 <p>Replace</p>
13201
13202 <blockquote>
13203     <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
13204     type, equivalent to</p>
13205
13206     <blockquote><p><tt>basic_string(static_cast&lt;size_type&gt;(begin),
13207     static_cast&lt;value_type&gt;(end))</tt></p></blockquote>
13208 </blockquote>
13209
13210 <p>with</p>
13211
13212 <blockquote>
13213     <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
13214     type, equivalent to</p>
13215
13216     <blockquote><p><tt>basic_string(static_cast&lt;size_type&gt;(begin),
13217     static_cast&lt;value_type&gt;(end), <b>a</b>)</tt></p></blockquote>
13218 </blockquote>
13219
13220
13221
13222
13223 <hr>
13224 <h3><a name="303"></a>303. Bitset input operator underspecified</h3>
13225 <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>
13226  <b>Submitter:</b> Matt Austern <b>Date:</b> 2001-02-05</p>
13227 <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>
13228 <p><b>Discussion:</b></p>
13229 <p>
13230 In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
13231 "Extracts up to <i>N</i> (single-byte) characters from
13232 <i>is</i>.", where <i>is</i> is a stream of type
13233 <tt>basic_istream&lt;charT, traits&gt;</tt>.
13234 </p>
13235
13236 <p>
13237 The standard does not say what it means to extract single byte
13238 characters from a stream whose character type, <tt>charT</tt>, is in
13239 general not a single-byte character type.  Existing implementations
13240 differ.
13241 </p>
13242
13243 <p>
13244 A reasonable solution will probably involve <tt>widen()</tt> and/or
13245 <tt>narrow()</tt>, since they are the supplied mechanism for
13246 converting a single character between <tt>char</tt> and
13247 arbitrary <tt>charT</tt>.
13248 </p>
13249
13250 <p>Narrowing the input characters is not the same as widening the
13251 literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
13252 locales in which more than one wide character maps to the narrow
13253 character <tt>'0'</tt>.  Narrowing means that alternate
13254 representations may be used for bitset input, widening means that
13255 they may not be.</p>
13256
13257 <p>Note that for numeric input, <tt>num_get&lt;&gt;</tt>
13258 (22.2.2.1.2/8) compares input characters to widened version of narrow
13259 character literals.</p>
13260
13261 <p>From Pete Becker, in c++std-lib-8224:</p>
13262 <blockquote>
13263 <p>
13264 Different writing systems can have different representations for the
13265 digits that represent 0 and 1. For example, in the Unicode representation
13266 of the Devanagari script (used in many of the Indic languages) the digit 0
13267 is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
13268 into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
13269 0x0031 for for the Latin representations of '0' and '1', as well as code
13270 points for the same numeric values in several other scripts (Tamil has no
13271 character for 0, but does have the digits 1-9), and any of these values
13272 would also be narrowed to '0' and '1'.
13273 </p>
13274
13275 <p>...</p>
13276
13277 <p>
13278 It's fairly common to intermix both native and Latin
13279 representations of numbers in a document. So I think the rule has to be
13280 that if a wide character represents a digit whose value is 0 then the bit
13281 should be cleared; if it represents a digit whose value is 1 then the bit
13282 should be set; otherwise throw an exception. So in a Devanagari locale,
13283 both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
13284 would set it. Widen can't do that. It would pick one of those two values,
13285 and exclude the other one.
13286 </p>
13287
13288 </blockquote>
13289
13290 <p>From Jens Maurer, in c++std-lib-8233:</p>
13291
13292 <blockquote>
13293 <p>
13294 Whatever we decide, I would find it most surprising if
13295 bitset conversion worked differently from int conversion
13296 with regard to alternate local representations of
13297 numbers.
13298 </p>
13299
13300 <p>Thus, I think the options are:</p>
13301 <ul>
13302  <li> Have a new defect issue for 22.2.2.1.2/8 so that it will
13303 require the use of narrow().</li>
13304
13305  <li> Have a defect issue for bitset() which describes clearly
13306 that widen() is to be used.</li>
13307 </ul>
13308 </blockquote>
13309
13310
13311
13312 <p><b>Proposed resolution:</b></p>
13313
13314     <p>Replace the first two sentences of paragraph 5 with:</p>
13315
13316     <blockquote><p>
13317     Extracts up to <i>N</i> characters from <i>is</i>. Stores these
13318     characters in a temporary object <i>str</i> of type
13319     <tt>basic_string&lt;charT, traits&gt;</tt>, then evaluates the
13320     expression <tt><i>x</i> = bitset&lt;N&gt;(<i>str</i>)</tt>.
13321     </p></blockquote>
13322
13323     <p>Replace the third bullet item in paragraph 5 with:</p>
13324     <ul><li>
13325     the next input character is neither <tt><i>is</i>.widen(0)</tt>
13326     nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
13327     is not extracted).
13328     </li></ul>
13329
13330
13331
13332 <p><b>Rationale:</b></p>
13333 <p>Input for <tt>bitset</tt> should work the same way as numeric
13334 input.  Using <tt>widen</tt> does mean that alternative digit
13335 representations will not be recognized, but this was a known
13336 consequence of the design choice.</p>
13337
13338
13339
13340
13341
13342 <hr>
13343 <h3><a name="305"></a>305. Default behavior of codecvt&lt;wchar_t, char, mbstate_t&gt;::length()</h3>
13344 <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>
13345  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-01-24</p>
13346 <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>
13347 <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>
13348 <p><b>Discussion:</b></p>
13349 <p>22.2.1.5/3 introduces codecvt in part with:</p>
13350
13351 <blockquote><p>
13352   codecvt&lt;wchar_t,char,mbstate_t&gt; converts between the native
13353   character sets for tiny and wide characters. Instantiations on
13354   mbstate_t perform conversion between encodings known to the library
13355   implementor.
13356 </p></blockquote>
13357
13358 <p>But 22.2.1.5.2/10 describes do_length in part with:</p>
13359
13360 <blockquote><p>
13361   ... codecvt&lt;wchar_t, char, mbstate_t&gt; ... return(s) the lesser of max and
13362   (from_end-from).
13363 </p></blockquote>
13364
13365 <p>
13366 The semantics of do_in and do_length are linked.  What one does must
13367 be consistent with what the other does.  22.2.1.5/3 leads me to
13368 believe that the vendor is allowed to choose the algorithm that
13369 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in performs so that it makes
13370 his customers happy on a given platform.  But 22.2.1.5.2/10 explicitly
13371 says what codecvt&lt;wchar_t,char,mbstate_t&gt;::do_length must
13372 return.  And thus indirectly specifies the algorithm that
13373 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in must perform.  I believe
13374 that this is not what was intended and is a defect.
13375 </p>
13376
13377 <p>Discussion from the -lib reflector:
13378
13379 <br>This proposal would have the effect of making the semantics of
13380 all of the virtual functions in <tt>codecvt&lt;wchar_t, char,
13381 mbstate_t&gt;</tt> implementation specified.  Is that what we want, or
13382 do we want to mandate specific behavior for the base class virtuals
13383 and leave the implementation specified behavior for the codecvt_byname
13384 derived class?  The tradeoff is that former allows implementors to
13385 write a base class that actually does something useful, while the
13386 latter gives users a way to get known and specified---albeit
13387 useless---behavior, and is consistent with the way the standard
13388 handles other facets.  It is not clear what the original intention
13389 was.</p>
13390
13391 <p>
13392 Nathan has suggest a compromise: a character that is a widened version
13393 of the characters in the basic execution character set must be
13394 converted to a one-byte sequence, but there is no such requirement
13395 for characters that are not part of the basic execution character set.
13396 </p>
13397
13398
13399 <p><b>Proposed resolution:</b></p>
13400 <p>
13401 Change 22.2.1.5.2/5 from:
13402 </p>
13403 <p>
13404 The instantiations required in Table 51 (lib.locale.category), namely
13405 codecvt&lt;wchar_t,char,mbstate_t&gt; and
13406 codecvt&lt;char,char,mbstate_t&gt;, store no characters. Stores no more
13407 than (to_limit-to) destination elements. It always leaves the to_next
13408 pointer pointing one beyond the last element successfully stored.
13409 </p>
13410 <p>
13411 to:
13412 </p>
13413 <p>
13414 Stores no more than (to_limit-to) destination elements, and leaves the
13415 to_next pointer pointing one beyond the last element successfully
13416 stored.  codecvt&lt;char,char,mbstate_t&gt; stores no characters.
13417 </p>
13418
13419 <p>Change 22.2.1.5.2/10 from:</p>
13420
13421 <blockquote><p>
13422 -10- Returns: (from_next-from) where from_next is the largest value in
13423 the range [from,from_end] such that the sequence of values in the
13424 range [from,from_next) represents max or fewer valid complete
13425 characters of type internT. The instantiations required in Table 51
13426 (21.1.1.1.1), namely codecvt&lt;wchar_t, char, mbstate_t&gt; and
13427 codecvt&lt;char, char, mbstate_t&gt;, return the lesser of max and
13428 (from_end-from).
13429 </p></blockquote>
13430
13431 <p>to:</p>
13432
13433 <blockquote><p>
13434 -10- Returns: (from_next-from) where from_next is the largest value in
13435 the range [from,from_end] such that the sequence of values in the range
13436 [from,from_next) represents max or fewer valid complete characters of
13437 type internT. The instantiation codecvt&lt;char, char, mbstate_t&gt; returns
13438 the lesser of max and (from_end-from).
13439 </p></blockquote>
13440
13441 <p><i>[Redmond: Nathan suggested an alternative resolution: same as
13442 above, but require that, in the default encoding, a character from the
13443 basic execution character set would map to a single external
13444 character.  The straw poll was 8-1 in favor of the proposed
13445 resolution.]</i></p>
13446
13447
13448
13449
13450 <p><b>Rationale:</b></p>
13451 <p>The default encoding should be whatever users of a given platform
13452 would expect to be the most natural.  This varies from platform to
13453 platform.  In many cases there is a preexisting C library, and users
13454 would expect the default encoding to be whatever C uses in the default
13455 "C" locale.  We could impose a guarantee like the one Nathan suggested
13456 (a character from the basic execution character set must map to a
13457 single external character), but this would rule out important
13458 encodings that are in common use: it would rule out JIS, for
13459 example, and it would rule out a fixed-width encoding of UCS-4.</p>
13460
13461 <p><i>[Curaçao: fixed rationale typo at the request of Ichiro Koshida;
13462 "shift-JIS" changed to "JIS".]</i></p>
13463
13464
13465
13466
13467
13468
13469
13470 <hr>
13471 <h3><a name="306"></a>306. offsetof macro and non-POD types</h3>
13472 <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>
13473  <b>Submitter:</b> Steve Clamage <b>Date:</b> 2001-02-21</p>
13474 <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>
13475 <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>
13476 <p><b>Discussion:</b></p>
13477 <p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
13478
13479 <p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
13480 accepts a restricted set of <i>type</i> arguments in this
13481 International Standard. <i>type</i> shall be a POD structure or a POD
13482 union (clause 9). The result of applying the offsetof macro to a field
13483 that is a static data member or a function member is
13484 undefined."</p>
13485
13486 <p>For the POD requirement, it doesn't say "no diagnostic
13487 required" or "undefined behavior". I read 1.4 [intro.compliance], paragraph 1, to mean that a diagnostic is required.
13488 It's not clear whether this requirement was intended.  While it's
13489 possible to provide such a diagnostic, the extra complication doesn't
13490 seem to add any value.
13491 </p>
13492
13493
13494 <p><b>Proposed resolution:</b></p>
13495 <p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
13496 structure or a POD union the results are undefined."</p>
13497
13498 <p><i>[Copenhagen: straw poll was 7-4 in favor.  It was generally
13499 agreed that requiring a diagnostic was inadvertent, but some LWG
13500 members thought that diagnostics should be required whenever
13501 possible.]</i></p>
13502
13503
13504
13505
13506
13507
13508 <hr>
13509 <h3><a name="307"></a>307. Lack of reference typedefs in container adaptors</h3>
13510 <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>
13511  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-03-13</p>
13512 <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>
13513 <p><b>Discussion:</b></p>
13514
13515 <p>From reflector message c++std-lib-8330.  See also lib-8317.</p>
13516
13517 <p>
13518 The standard is currently inconsistent in 23.2.3.2 [list.capacity]
13519 paragraph 1 and 23.2.3.3 [list.modifiers] paragraph 1.
13520 23.2.3.3/1, for example, says:
13521 </p>
13522
13523 <blockquote><p>
13524 -1- Any sequence supporting operations back(), push_back() and pop_back()
13525 can be used to instantiate stack. In particular, vector (lib.vector), list
13526 (lib.list) and deque (lib.deque) can be used.
13527 </p></blockquote>
13528
13529 <p>But this is false: vector&lt;bool&gt; can not be used, because the
13530 container adaptors return a T&amp; rather than using the underlying
13531 container's reference type.</p>
13532
13533 <p>This is a contradiction that can be fixed by:</p>
13534
13535 <ol>
13536 <li>Modifying these paragraphs to say that vector&lt;bool&gt;
13537     is an exception.</li>
13538 <li>Removing the vector&lt;bool&gt; specialization.</li>
13539 <li>Changing the return types of stack and priority_queue to use
13540     reference typedef's.</li>
13541 </ol>
13542
13543 <p>
13544 I propose 3.  This does not preclude option 2 if we choose to do it
13545 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
13546 3 offers a small step towards support for proxied containers.  This
13547 small step fixes a current contradiction, is easy for vendors to
13548 implement, is already implemented in at least one popular lib, and
13549 does not break any code.
13550 </p>
13551
13552
13553
13554 <p><b>Proposed resolution:</b></p>
13555 <p>Summary: Add reference and const_reference typedefs to queue,
13556 priority_queue and stack.  Change return types of "value_type&amp;" to
13557 "reference".  Change return types of "const value_type&amp;" to
13558 "const_reference".  Details:</p>
13559
13560 <p>Change 23.2.3.1/1 from:</p>
13561
13562 <pre>  namespace std {
13563     template &lt;class T, class Container = deque&lt;T&gt; &gt;
13564     class queue {
13565     public:
13566       typedef typename Container::value_type            value_type;
13567       typedef typename Container::size_type             size_type;
13568       typedef          Container                        container_type;
13569     protected:
13570       Container c;
13571
13572     public:
13573       explicit queue(const Container&amp; = Container());
13574
13575       bool      empty() const             { return c.empty(); }
13576       size_type size()  const             { return c.size(); }
13577       value_type&amp;       front()           { return c.front(); }
13578       const value_type&amp; front() const     { return c.front(); }
13579       value_type&amp;       back()            { return c.back(); }
13580       const value_type&amp; back() const      { return c.back(); }
13581       void push(const value_type&amp; x)      { c.push_back(x); }
13582       void pop()                          { c.pop_front(); }
13583     };
13584 </pre>
13585
13586 <p>to:</p>
13587
13588 <pre>  namespace std {
13589     template &lt;class T, class Container = deque&lt;T&gt; &gt;
13590     class queue {
13591     public:
13592       typedef typename Container::value_type            value_type;
13593       typedef typename Container::reference             reference;
13594       typedef typename Container::const_reference       const_reference;
13595       typedef typename Container::value_type            value_type;
13596       typedef typename Container::size_type             size_type;
13597       typedef          Container                        container_type;
13598     protected:
13599       Container c;
13600
13601     public:
13602       explicit queue(const Container&amp; = Container());
13603
13604       bool      empty() const             { return c.empty(); }
13605       size_type size()  const             { return c.size(); }
13606       reference         front()           { return c.front(); }
13607       const_reference   front() const     { return c.front(); }
13608       reference         back()            { return c.back(); }
13609       const_reference   back() const      { return c.back(); }
13610       void push(const value_type&amp; x)      { c.push_back(x); }
13611       void pop()                          { c.pop_front(); }
13612     };
13613 </pre>
13614
13615 <p>Change 23.2.3.2/1 from:</p>
13616
13617 <pre>  namespace std {
13618     template &lt;class T, class Container = vector&lt;T&gt;,
13619               class Compare = less&lt;typename Container::value_type&gt; &gt;
13620     class priority_queue {
13621     public:
13622       typedef typename Container::value_type            value_type;
13623       typedef typename Container::size_type             size_type;
13624       typedef          Container                        container_type;
13625     protected:
13626       Container c;
13627       Compare comp;
13628
13629     public:
13630       explicit priority_queue(const Compare&amp; x = Compare(),
13631                               const Container&amp; = Container());
13632       template &lt;class InputIterator&gt;
13633         priority_queue(InputIterator first, InputIterator last,
13634                        const Compare&amp; x = Compare(),
13635                        const Container&amp; = Container());
13636
13637       bool      empty() const       { return c.empty(); }
13638       size_type size()  const       { return c.size(); }
13639       const value_type&amp; top() const { return c.front(); }
13640       void push(const value_type&amp; x);
13641       void pop();
13642     };
13643                                   //  no equality is provided
13644   }
13645 </pre>
13646
13647 <p>to:</p>
13648
13649 <pre>  namespace std {
13650     template &lt;class T, class Container = vector&lt;T&gt;,
13651               class Compare = less&lt;typename Container::value_type&gt; &gt;
13652     class priority_queue {
13653     public:
13654       typedef typename Container::value_type            value_type;
13655       typedef typename Container::reference             reference;
13656       typedef typename Container::const_reference       const_reference;
13657       typedef typename Container::size_type             size_type;
13658       typedef          Container                        container_type;
13659     protected:
13660       Container c;
13661       Compare comp;
13662
13663     public:
13664       explicit priority_queue(const Compare&amp; x = Compare(),
13665                               const Container&amp; = Container());
13666       template &lt;class InputIterator&gt;
13667         priority_queue(InputIterator first, InputIterator last,
13668                        const Compare&amp; x = Compare(),
13669                        const Container&amp; = Container());
13670
13671       bool      empty() const       { return c.empty(); }
13672       size_type size()  const       { return c.size(); }
13673       const_reference   top() const { return c.front(); }
13674       void push(const value_type&amp; x);
13675       void pop();
13676     };
13677                                   //  no equality is provided
13678   }
13679 </pre>
13680
13681 <p>And change 23.2.3.3/1 from:</p>
13682
13683 <pre>  namespace std {
13684     template &lt;class T, class Container = deque&lt;T&gt; &gt;
13685     class stack {
13686     public:
13687       typedef typename Container::value_type            value_type;
13688       typedef typename Container::size_type             size_type;
13689       typedef          Container                        container_type;
13690     protected:
13691       Container c;
13692
13693     public:
13694       explicit stack(const Container&amp; = Container());
13695
13696       bool      empty() const             { return c.empty(); }
13697       size_type size()  const             { return c.size(); }
13698       value_type&amp;       top()             { return c.back(); }
13699       const value_type&amp; top() const       { return c.back(); }
13700       void push(const value_type&amp; x)      { c.push_back(x); }
13701       void pop()                          { c.pop_back(); }
13702     };
13703
13704     template &lt;class T, class Container&gt;
13705       bool operator==(const stack&lt;T, Container&gt;&amp; x,
13706                       const stack&lt;T, Container&gt;&amp; y);
13707     template &lt;class T, class Container&gt;
13708       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
13709                       const stack&lt;T, Container&gt;&amp; y);
13710     template &lt;class T, class Container&gt;
13711       bool operator!=(const stack&lt;T, Container&gt;&amp; x,
13712                       const stack&lt;T, Container&gt;&amp; y);
13713     template &lt;class T, class Container&gt;
13714       bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
13715                       const stack&lt;T, Container&gt;&amp; y);
13716     template &lt;class T, class Container&gt;
13717       bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
13718                       const stack&lt;T, Container&gt;&amp; y);
13719     template &lt;class T, class Container&gt;
13720       bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
13721                       const stack&lt;T, Container&gt;&amp; y);
13722   }
13723 </pre>
13724
13725 <p>to:</p>
13726
13727 <pre>  namespace std {
13728     template &lt;class T, class Container = deque&lt;T&gt; &gt;
13729     class stack {
13730     public:
13731       typedef typename Container::value_type            value_type;
13732       typedef typename Container::reference             reference;
13733       typedef typename Container::const_reference       const_reference;
13734       typedef typename Container::size_type             size_type;
13735       typedef          Container                        container_type;
13736     protected:
13737       Container c;
13738
13739     public:
13740       explicit stack(const Container&amp; = Container());
13741
13742       bool      empty() const             { return c.empty(); }
13743       size_type size()  const             { return c.size(); }
13744       reference         top()             { return c.back(); }
13745       const_reference   top() const       { return c.back(); }
13746       void push(const value_type&amp; x)      { c.push_back(x); }
13747       void pop()                          { c.pop_back(); }
13748     };
13749
13750     template &lt;class T, class Container&gt;
13751       bool operator==(const stack&lt;T, Container&gt;&amp; x,
13752                       const stack&lt;T, Container&gt;&amp; y);
13753     template &lt;class T, class Container&gt;
13754       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
13755                       const stack&lt;T, Container&gt;&amp; y);
13756     template &lt;class T, class Container&gt;
13757       bool operator!=(const stack&lt;T, Container&gt;&amp; x,
13758                       const stack&lt;T, Container&gt;&amp; y);
13759     template &lt;class T, class Container&gt;
13760       bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
13761                       const stack&lt;T, Container&gt;&amp; y);
13762     template &lt;class T, class Container&gt;
13763       bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
13764                       const stack&lt;T, Container&gt;&amp; y);
13765     template &lt;class T, class Container&gt;
13766       bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
13767                       const stack&lt;T, Container&gt;&amp; y);
13768   }
13769 </pre>
13770
13771 <p><i>[Copenhagen: This change was discussed before the IS was released
13772 and it was deliberately not adopted.  Nevertheless, the LWG believes
13773 (straw poll: 10-2) that it is a genuine defect.]</i></p>
13774
13775
13776
13777
13778
13779
13780 <hr>
13781 <h3><a name="308"></a>308. Table 82 mentions unrelated headers</h3>
13782 <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>
13783  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-15</p>
13784 <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>
13785 <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>
13786 <p><b>Discussion:</b></p>
13787 <p>
13788 Table 82 in section 27 mentions the header &lt;cstdlib&gt; for String
13789 streams (27.7 [string.streams]) and the headers &lt;cstdio&gt; and
13790 &lt;cwchar&gt; for File streams (27.8 [file.streams]). It's not clear
13791 why these headers are mentioned in this context since they do not
13792 define any of the library entities described by the
13793 subclauses. According to 17.4.1.1 [contents], only such headers
13794 are to be listed in the summary.
13795 </p>
13796
13797
13798 <p><b>Proposed resolution:</b></p>
13799 <p>Remove &lt;cstdlib&gt; and &lt;cwchar&gt; from
13800 Table 82.</p>
13801
13802 <p><i>[Copenhagen: changed the proposed resolution slightly.  The
13803 original proposed resolution also said to remove &lt;cstdio&gt; from
13804 Table 82.  However, &lt;cstdio&gt; is mentioned several times within
13805 section 27.8 [file.streams], including 27.8.2 [c.files].]</i></p>
13806
13807
13808
13809
13810
13811
13812 <hr>
13813 <h3><a name="310"></a>310. Is errno a macro?</h3>
13814 <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>
13815  <b>Submitter:</b> Steve Clamage <b>Date:</b> 2001-03-21</p>
13816 <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>
13817 <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>
13818 <p><b>Discussion:</b></p>
13819   <p>
13820   Exactly how should errno be declared in a conforming C++ header?
13821   </p>
13822
13823   <p>
13824   The C standard says in 7.1.4 that it is unspecified whether errno is a
13825   macro or an identifier with external linkage.  In some implementations
13826   it can be either, depending on compile-time options.  (E.g., on
13827   Solaris in multi-threading mode, errno is a macro that expands to a
13828   function call, but is an extern int otherwise.  "Unspecified" allows
13829   such variability.)
13830   </p>
13831
13832   <p>The C++ standard:</p>
13833   <ul>
13834   <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
13835   <li>17.4.3.1.3 footnote 166 says errno is reserved as an external
13836       name (true), and implies that it is an identifier.</li>
13837   <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
13838       on to say that the contents of of C++ &lt;errno.h&gt; are the
13839       same as in C, begging the question.</li>
13840   <li>C.2, table 95 lists errno as a macro, without comment.</li>
13841   </ul>
13842
13843   <p>I find no other references to errno.</p>
13844
13845   <p>We should either explicitly say that errno must be a macro, even
13846   though it need not be a macro in C, or else explicitly leave it
13847   unspecified.  We also need to say something about namespace std.
13848   A user who includes &lt;cerrno&gt; needs to know whether to write
13849   <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
13850   else &lt;cerrno&gt; is useless.</p>
13851
13852   <p>Two acceptable fixes:</p>
13853   <ul>
13854     <li><p>errno must be a macro. This is trivially satisfied by adding<br>
13855         &nbsp;&nbsp;#define errno (::std::errno)<br>
13856         to the headers if errno is not already a macro. You then always
13857         write errno without any scope qualification, and it always expands
13858         to a correct reference. Since it is always a macro, you know to
13859         avoid using errno as a local identifer.</p></li>
13860     <li><p>errno is in the global namespace. This fix is inferior, because
13861         ::errno is not guaranteed to be well-formed.</p></li>
13862   </ul>
13863
13864   <p><i>[
13865     This issue was first raised in 1999, but it slipped through
13866     the cracks.
13867   ]</i></p>
13868
13869
13870
13871 <p><b>Proposed resolution:</b></p>
13872   <p>Change the Note in section 17.4.1.2p5 from</p>
13873
13874     <blockquote><p>
13875     Note: the names defined as macros in C include the following:
13876     assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
13877     </p></blockquote>
13878
13879   <p>to</p>
13880
13881     <blockquote><p>
13882     Note: the names defined as macros in C include the following:
13883     assert, offsetof, setjmp, va_arg, va_end, and va_start.
13884     </p></blockquote>
13885
13886   <p>In section 19.3, change paragraph 2 from</p>
13887
13888     <blockquote><p>
13889     The contents are the same as the Standard C library header
13890     &lt;errno.h&gt;.
13891     </p></blockquote>
13892
13893   <p>to</p>
13894
13895     <blockquote><p>
13896     The contents are the same as the Standard C library header
13897     &lt;errno.h&gt;, except that errno shall be defined as a macro.
13898     </p></blockquote>
13899
13900
13901 <p><b>Rationale:</b></p>
13902 <p>C++ must not leave it up to the implementation to decide whether or
13903 not a name is a macro; it must explicitly specify exactly which names
13904 are required to be macros.  The only one that really works is for it
13905 to be a macro.</p>
13906
13907 <p><i>[Curaçao: additional rationale added.]</i></p>
13908
13909
13910
13911
13912
13913
13914
13915 <hr>
13916 <h3><a name="311"></a>311. Incorrect wording in basic_ostream class synopsis</h3>
13917 <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>
13918  <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-03-21</p>
13919 <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>
13920 <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>
13921 <p><b>Discussion:</b></p>
13922
13923 <p>In 27.6.2.1 [ostream], the synopsis of class basic_ostream says:</p>
13924
13925 <pre>  // partial specializationss
13926   template&lt;class traits&gt;
13927     basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;( basic_ostream&lt;char,traits&gt;&amp;,
13928                                             const char * );
13929 </pre>
13930
13931 <p>Problems:</p>
13932 <ul>
13933 <li>Too many 's's at the end of "specializationss" </li>
13934 <li>This is an overload, not a partial specialization</li>
13935 </ul>
13936
13937
13938
13939 <p><b>Proposed resolution:</b></p>
13940 <p>In the synopsis in 27.6.2.1 [ostream], remove the
13941 <i>// partial specializationss</i> comment.  Also remove the same
13942 comment (correctly spelled, but still incorrect) from the synopsis in
13943 27.6.2.6.4 [ostream.inserters.character].
13944 </p>
13945
13946 <p><i>[
13947 Pre-Redmond: added 27.6.2.6.4 [ostream.inserters.character] because of Martin's
13948 comment in c++std-lib-8939.
13949 ]</i></p>
13950
13951
13952
13953
13954
13955
13956
13957 <hr>
13958 <h3><a name="312"></a>312. Table 27 is missing headers</h3>
13959 <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>
13960  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-29</p>
13961 <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>
13962 <p><b>Discussion:</b></p>
13963 <p>Table 27 in section 20 lists the header &lt;memory&gt; (only) for
13964 Memory (lib.memory) but neglects to mention the headers
13965 &lt;cstdlib&gt; and &lt;cstring&gt; that are discussed in 20.4.5 [meta.rel].</p>
13966
13967
13968 <p><b>Proposed resolution:</b></p>
13969 <p>Add &lt;cstdlib&gt; and &lt;cstring&gt; to Table 27, in the same row
13970 as &lt;memory&gt;.</p>
13971
13972
13973
13974
13975
13976 <hr>
13977 <h3><a name="315"></a>315. Bad "range" in list::unique complexity</h3>
13978 <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>
13979  <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-05-01</p>
13980 <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>
13981 <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>
13982 <p><b>Discussion:</b></p>
13983 <p>
13984 23.2.3.4 [list.ops], Para 21 describes the complexity of
13985 list::unique as: "If the range (last - first) is not empty, exactly
13986 (last - first) -1 applications of the corresponding predicate,
13987 otherwise no applications of the predicate)".
13988 </p>
13989
13990 <p>
13991 "(last - first)" is not a range.
13992 </p>
13993
13994
13995 <p><b>Proposed resolution:</b></p>
13996 <p>
13997 Change the "range" from (last - first) to [first, last).
13998 </p>
13999
14000
14001
14002
14003 <hr>
14004 <h3><a name="316"></a>316. Vague text in Table 69</h3>
14005 <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>
14006  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-04</p>
14007 <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>
14008 <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>
14009 <p><b>Discussion:</b></p>
14010 <p>Table 69 says this about a_uniq.insert(t):</p>
14011
14012 <blockquote><p>
14013 inserts t if and only if there is no element in the container with key
14014 equivalent to the key of t. The bool component of the returned pair
14015 indicates whether the insertion takes place and the iterator component of the
14016 pair points to the element with key equivalent to the key of t.
14017 </p></blockquote>
14018
14019 <p>The description should be more specific about exactly how the bool component
14020 indicates whether the insertion takes place.</p>
14021
14022
14023 <p><b>Proposed resolution:</b></p>
14024 <p>Change the text in question to</p>
14025
14026 <blockquote><p>
14027 ...The bool component of the returned pair is true if and only if the insertion
14028 takes place...
14029 </p></blockquote>
14030
14031
14032
14033
14034
14035 <hr>
14036 <h3><a name="317"></a>317. Instantiation vs. specialization of facets</h3>
14037 <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>
14038  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-04</p>
14039 <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>
14040 <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>
14041 <p><b>Discussion:</b></p>
14042 <p>
14043 The localization section of the standard refers to specializations of
14044 the facet templates as instantiations even though the required facets
14045 are typically specialized rather than explicitly (or implicitly)
14046 instantiated. In the case of ctype&lt;char&gt; and
14047 ctype_byname&lt;char&gt; (and the wchar_t versions), these facets are
14048 actually required to be specialized. The terminology should be
14049 corrected to make it clear that the standard doesn't mandate explicit
14050 instantiation (the term specialization encompasses both explicit
14051 instantiations and specializations).
14052 </p>
14053
14054
14055 <p><b>Proposed resolution:</b></p>
14056 <p>
14057 In the following paragraphs, replace all occurrences of the word
14058 instantiation or instantiations with specialization or specializations,
14059 respectively:
14060 </p>
14061
14062 <blockquote><p>
14063 22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
14064 22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3,
14065 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
14066 Footnote 242.
14067 </p></blockquote>
14068
14069 <p>And change the text in 22.1.1.1.1, p4 from</p>
14070
14071 <blockquote><p>
14072     An implementation is required to provide those instantiations
14073     for facet templates identified as members of a category, and
14074     for those shown in Table 52:
14075 </p></blockquote>
14076
14077 <p>to</p>
14078
14079 <blockquote><p>
14080     An implementation is required to provide those specializations...
14081 </p></blockquote>
14082
14083 <p><i>[Nathan will review these changes, and will look for places where
14084 explicit specialization is necessary.]</i></p>
14085
14086
14087
14088
14089 <p><b>Rationale:</b></p>
14090 <p>This is a simple matter of outdated language.  The language to
14091 describe templates was clarified during the standardization process,
14092 but the wording in clause 22 was never updated to reflect that
14093 change.</p>
14094
14095
14096
14097
14098
14099
14100
14101 <hr>
14102 <h3><a name="318"></a>318. Misleading comment in definition of numpunct_byname</h3>
14103 <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>
14104  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-12</p>
14105 <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>
14106 <p><b>Discussion:</b></p>
14107 <p>The definition of the numpunct_byname template contains the following
14108 comment:</p>
14109
14110 <pre>    namespace std {
14111         template &lt;class charT&gt;
14112         class numpunct_byname : public numpunct&lt;charT&gt; {
14113     // this class is specialized for char and wchar_t.
14114         ...
14115 </pre>
14116
14117 <p>There is no documentation of the specializations and it seems
14118 conceivable that an implementation will not explicitly specialize the
14119 template at all, but simply provide the primary template.</p>
14120
14121
14122 <p><b>Proposed resolution:</b></p>
14123 <p>Remove the comment from the text in 22.2.3.2 and from the proposed
14124 resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
14125
14126
14127
14128
14129 <hr>
14130 <h3><a name="319"></a>319. Storage allocation wording confuses "Required behavior", "Requires"</h3>
14131 <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>
14132  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2001-05-15</p>
14133 <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>
14134 <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>
14135 <p><b>Discussion:</b></p>
14136 <p>The standard specifies 17.3.1.3 [structure.specifications] that "Required
14137 behavior" elements describe "the semantics of a function definition
14138 provided by either the implementation or a C++ program."</p>
14139
14140 <p>The standard specifies 17.3.1.3 [structure.specifications] that "Requires"
14141 elements describe "the preconditions for calling the function."</p>
14142
14143 <p>In the sections noted below, the current wording specifies
14144 "Required Behavior" for what are actually preconditions, and thus
14145 should be specified as "Requires".</p>
14146
14147
14148
14149 <p><b>Proposed resolution:</b></p>
14150
14151 <p>In 18.5.1.1 [new.delete.single] Para 12 Change:</p>
14152 <blockquote>
14153   <p>Required behavior: accept a value of ptr that is null or that was
14154   returned by an earlier call ...</p>
14155 </blockquote>
14156 <p>to:</p>
14157 <blockquote>
14158   <p>Requires: the value of ptr is null or the value returned by an
14159   earlier call ...</p>
14160 </blockquote>
14161
14162 <p>In 18.5.1.2 [new.delete.array] Para 11 Change:</p>
14163 <blockquote>
14164   <p>Required behavior: accept a value of ptr that is null or that was
14165   returned by an earlier call ...</p>
14166 </blockquote>
14167 <p>to:</p>
14168 <blockquote>
14169   <p>Requires: the value of ptr is null or the value returned by an
14170   earlier call ...</p>
14171 </blockquote>
14172
14173
14174
14175
14176
14177 <hr>
14178 <h3><a name="320"></a>320. list::assign overspecified</h3>
14179 <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>
14180  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-05-17</p>
14181 <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>
14182 <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>
14183 <p><b>Discussion:</b></p>
14184 <p>
14185 Section 23.2.3.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have
14186 the "effects" of a call to erase followed by a call to insert.
14187 </p>
14188
14189 <p>
14190 I would like to document that implementers have the freedom to implement
14191 assign by other methods, as long as the end result is the same and the
14192 exception guarantee is as good or better than the basic guarantee.
14193 </p>
14194
14195 <p>
14196 The motivation for this is to use T's assignment operator to recycle
14197 existing nodes in the list instead of erasing them and reallocating
14198 them with new values.  It is also worth noting that, with careful
14199 coding, most common cases of assign (everything but assignment with
14200 true input iterators) can elevate the exception safety to strong if
14201 T's assignment has a nothrow guarantee (with no extra memory cost).
14202 Metrowerks does this.  However I do not propose that this subtlety be
14203 standardized.  It is a QoI issue.  </p>
14204
14205 <p>Existing practise:
14206 Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
14207 </p>
14208
14209
14210 <p><b>Proposed resolution:</b></p>
14211 <p>Change 23.2.3.1 [list.cons]/7 from:</p>
14212
14213 <blockquote>
14214 <p>Effects:</p>
14215
14216 <pre>   erase(begin(), end());
14217    insert(begin(), first, last);
14218 </pre>
14219 </blockquote>
14220
14221 <p>to:</p>
14222
14223 <blockquote>
14224 <p>Effects: Replaces the contents of the list with the range [first, last).</p>
14225 </blockquote>
14226
14227 <p>In 23.1.1 [sequence.reqmts], in Table 67 (sequence requirements),
14228 add two new rows:</p>
14229 <pre>      a.assign(i,j)     void      pre: i,j are not iterators into a.
14230                                   Replaces elements in a with a copy
14231                                   of [i, j).
14232
14233       a.assign(n,t)     void      pre: t is not a reference into a.
14234                                   Replaces elements in a with n copies
14235                                   of t.
14236 </pre>
14237
14238 <p>Change 23.2.3.1 [list.cons]/8 from:</p>
14239
14240 <blockquote>
14241 <p>Effects:</p>
14242 <pre>   erase(begin(), end());
14243    insert(begin(), n, t);
14244 </pre>
14245 </blockquote>
14246 <p>to:</p>
14247
14248 <blockquote>
14249 <p>Effects: Replaces the contents of the list with n copies of t.</p>
14250 </blockquote>
14251
14252 <p><i>[Redmond: Proposed resolution was changed slightly.  Previous
14253 version made explicit statement about exception safety, which wasn't
14254 consistent with the way exception safety is expressed elsewhere.
14255 Also, the change in the sequence requirements is new.  Without that
14256 change, the proposed resolution would have required that assignment of
14257 a subrange would have to work.  That too would have been
14258 overspecification; it would effectively mandate that assignment use a
14259 temporary.  Howard provided wording.
14260 ]</i></p>
14261
14262
14263 <p><i>[Curaçao: Made editorial improvement in wording; changed
14264 "Replaces elements in a with copies of elements in [i, j)."
14265 with "Replaces the elements of a with a copy of [i, j)."
14266 Changes not deemed serious enough to requre rereview.]</i></p>
14267
14268
14269
14270
14271
14272
14273
14274 <hr>
14275 <h3><a name="321"></a>321. Typo in num_get</h3>
14276 <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>
14277  <b>Submitter:</b> Kevin Djang <b>Date:</b> 2001-05-17</p>
14278 <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>
14279 <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>
14280 <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>
14281 <p><b>Discussion:</b></p>
14282 <p>
14283 Section 22.2.2.1.2 at p7 states that "A length specifier is added to
14284 the conversion function, if needed, as indicated in Table 56."
14285 However, Table 56 uses the term "length modifier", not "length
14286 specifier".
14287 </p>
14288
14289
14290 <p><b>Proposed resolution:</b></p>
14291 <p>
14292 In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
14293 to be "A length modifier is added ..."
14294 </p>
14295
14296
14297 <p><b>Rationale:</b></p>
14298 <p>C uses the term "length modifier".  We should be consistent.</p>
14299
14300
14301
14302
14303
14304
14305 <hr>
14306 <h3><a name="322"></a>322. iterator and const_iterator should have the same value type</h3>
14307 <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>
14308  <b>Submitter:</b> Matt Austern <b>Date:</b> 2001-05-17</p>
14309 <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>
14310 <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>
14311 <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>
14312 <p><b>Discussion:</b></p>
14313 <p>
14314 It's widely assumed that, if X is a container,
14315 iterator_traits&lt;X::iterator&gt;::value_type and
14316 iterator_traits&lt;X::const_iterator&gt;::value_type should both be
14317 X::value_type.  However, this is nowhere stated.  The language in
14318 Table 65 is not precise about the iterators' value types (it predates
14319 iterator_traits), and could even be interpreted as saying that
14320 iterator_traits&lt;X::const_iterator&gt;::value_type should be "const
14321 X::value_type".
14322 </p>
14323
14324 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a>.</p>
14325
14326
14327 <p><b>Proposed resolution:</b></p>
14328 <p>In Table 65 ("Container Requirements"), change the return type for
14329 X::iterator to "iterator type whose value type is T".  Change the
14330 return type for X::const_iterator to "constant iterator type whose
14331 value type is T".</p>
14332
14333
14334 <p><b>Rationale:</b></p>
14335 <p>
14336 This belongs as a container requirement, rather than an iterator
14337 requirement, because the whole notion of iterator/const_iterator
14338 pairs is specific to containers' iterator.
14339 </p>
14340 <p>
14341 It is existing practice that (for example)
14342 iterator_traits&lt;list&lt;int&gt;::const_iterator&gt;::value_type
14343 is "int", rather than "const int".  This is consistent with
14344 the way that const pointers are handled: the standard already
14345 requires that iterator_traits&lt;const int*&gt;::value_type is int.
14346 </p>
14347
14348
14349
14350
14351
14352 <hr>
14353 <h3><a name="324"></a>324. Do output iterators have value types?</h3>
14354 <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>
14355  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-06-07</p>
14356 <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>
14357 <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>
14358 <p><b>Discussion:</b></p>
14359
14360 <p>Table 73 suggests that output iterators have value types.  It
14361 requires the expression "*a = t".  Additionally, although Table 73
14362 never lists "a = t" or "X(a) = t" in the "expressions" column, it
14363 contains a note saying that "a = t" and "X(a) = t" have equivalent
14364 (but nowhere specified!) semantics.</p>
14365
14366 <p>According to 24.1/9, t is supposed to be "a value of value type
14367 T":</p>
14368
14369     <blockquote><p>
14370     In the following sections, a and b denote values of X, n denotes a
14371     value of the difference type Distance, u, tmp, and m denote
14372     identifiers, r denotes a value of X&amp;, t denotes a value of
14373     value type T.
14374     </p></blockquote>
14375
14376 <p>Two other parts of the standard that are relevant to whether
14377 output iterators have value types:</p>
14378
14379 <ul>
14380     <li>24.1/1 says "All iterators i support the expression *i,
14381     resulting in a value of some class, enumeration, or built-in type
14382     T, called the value type of the iterator".</li>
14383
14384     <li>
14385     24.3.1/1, which says "In the case of an output iterator, the types
14386     iterator_traits&lt;Iterator&gt;::difference_type
14387     iterator_traits&lt;Iterator&gt;::value_type are both defined as void."
14388     </li>
14389 </ul>
14390
14391 <p>The first of these passages suggests that "*i" is supposed to
14392 return a useful value, which contradicts the note in 24.1.2/2 saying
14393 that the only valid use of "*i" for output iterators is in an
14394 expression of the form "*i = t".  The second of these passages appears
14395 to contradict Table 73, because it suggests that "*i"'s return value
14396 should be void.  The second passage is also broken in the case of a an
14397 iterator type, like non-const pointers, that satisfies both the output
14398 iterator requirements and the forward iterator requirements.</p>
14399
14400 <p>What should the standard say about <tt>*i</tt>'s return value when
14401 i is an output iterator, and what should it say about that t is in the
14402 expression "*i = t"?  Finally, should the standard say anything about
14403 output iterators' pointer and reference types?</p>
14404
14405
14406
14407 <p><b>Proposed resolution:</b></p>
14408 <p>24.1 p1, change</p>
14409
14410 <blockquote>
14411 <p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
14412 in a value of some class, enumeration, or built-in type <tt>T</tt>,
14413 called the value type of the iterator.</p>
14414 </blockquote>
14415
14416 <p>to</p>
14417
14418 <blockquote>
14419 <p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
14420 resulting in a value of some class, enumeration, or built-in type
14421 <tt>T</tt>, called the value type of the iterator. All output
14422 iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
14423 value of some type that is in the set of types that are <i>writable</i> to
14424 the particular iterator type of <tt>i</tt>.
14425 </p>
14426 </blockquote>
14427
14428 <p>24.1 p9, add</p>
14429
14430 <blockquote>
14431 <p><tt>o</tt> denotes a value of some type that is writable to the
14432 output iterator.
14433 </p>
14434 </blockquote>
14435
14436 <p>Table 73, change</p>
14437
14438 <blockquote>
14439 <pre>*a = t
14440 </pre>
14441 </blockquote>
14442
14443 <p>to</p>
14444
14445 <blockquote>
14446 <pre>*r = o
14447 </pre>
14448 </blockquote>
14449
14450 <p>and change</p>
14451
14452 <blockquote>
14453 <pre>*r++ = t
14454 </pre>
14455 </blockquote>
14456
14457 <p>to</p>
14458
14459 <blockquote>
14460 <pre>*r++ = o
14461 </pre>
14462 </blockquote>
14463
14464 <p><i>[post-Redmond: Jeremy provided wording]</i></p>
14465
14466
14467
14468
14469 <p><b>Rationale:</b></p>
14470 <p>The LWG considered two options: change all of the language that
14471 seems to imply that output iterators have value types, thus making it
14472 clear that output iterators have no value types, or else define value
14473 types for output iterator consistently.  The LWG chose the former
14474 option, because it seems clear that output iterators were never
14475 intended to have value types.  This was a deliberate design decision,
14476 and any language suggesting otherwise is simply a mistake.</p>
14477
14478 <p>A future revision of the standard may wish to revisit this design
14479 decision.</p>
14480
14481
14482
14483
14484
14485 <hr>
14486 <h3><a name="325"></a>325. Misleading text in moneypunct&lt;&gt;::do_grouping</h3>
14487 <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>
14488  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-02</p>
14489 <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>
14490 <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>
14491 <p><b>Discussion:</b></p>
14492 <p>The Returns clause in 22.2.6.3.2, p3 says about
14493 moneypunct&lt;charT&gt;::do_grouping()
14494 </p>
14495
14496 <blockquote><p>
14497     Returns: A pattern defined identically as the result of
14498     numpunct&lt;charT&gt;::do_grouping().241)
14499 </p></blockquote>
14500
14501 <p>Footnote 241 then reads</p>
14502
14503 <blockquote><p>
14504     This is most commonly the value "\003" (not "3").
14505 </p></blockquote>
14506
14507 <p>
14508 The returns clause seems to imply that the two member functions must
14509 return an identical value which in reality may or may not be true,
14510 since the facets are usually implemented in terms of struct std::lconv
14511 and return the value of the grouping and mon_grouping, respectively.
14512 The footnote also implies that the member function of the moneypunct
14513 facet (rather than the overridden virtual functions in moneypunct_byname)
14514 most commonly return "\003", which contradicts the C standard which
14515 specifies the value of "" for the (most common) C locale.
14516 </p>
14517
14518
14519
14520 <p><b>Proposed resolution:</b></p>
14521 <p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>
14522
14523 <blockquote><p>
14524     Returns: A pattern defined identically as, but not necessarily
14525     equal to, the result of numpunct&lt;charT&gt;::do_grouping().241)
14526 </p></blockquote>
14527
14528 <p>and replace the text in Footnote 241 with the following:</p>
14529
14530 <blockquote><p>
14531     To specify grouping by 3s the value is "\003", not "3".
14532 </p></blockquote>
14533
14534
14535 <p><b>Rationale:</b></p>
14536 <p>
14537 The fundamental problem is that the description of the locale facet
14538 virtuals serves two purposes: describing the behavior of the base
14539 class, and describing the meaning of and constraints on the behavior
14540 in arbitrary derived classes.  The new wording makes that separation a
14541 little bit clearer.  The footnote (which is nonnormative) is not
14542 supposed to say what the grouping is in the "C" locale or in any other
14543 locale. It is just a reminder that the values are interpreted as small
14544 integers, not ASCII characters.
14545 </p>
14546
14547
14548
14549
14550 <hr>
14551 <h3><a name="327"></a>327. Typo in time_get facet in table 52</h3>
14552 <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>
14553  <b>Submitter:</b> Tiki Wan <b>Date:</b> 2001-07-06</p>
14554 <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>
14555 <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>
14556 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#447">447</a></p>
14557 <p><b>Discussion:</b></p>
14558 <p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
14559 <tt>time_get_byname</tt> are listed incorrectly in table 52,
14560 required instantiations.  In both cases the second template
14561 parameter is given as OutputIterator.  It should instead be
14562 InputIterator, since these are input facets.</p>
14563
14564
14565 <p><b>Proposed resolution:</b></p>
14566 <p>
14567 In table 52, required instantiations, in
14568 22.1.1.1.1 [locale.category], change</p>
14569 <pre>    time_get&lt;wchar_t, OutputIterator&gt;
14570     time_get_byname&lt;wchar_t, OutputIterator&gt;
14571 </pre>
14572 <p>to</p>
14573 <pre>    time_get&lt;wchar_t, InputIterator&gt;
14574     time_get_byname&lt;wchar_t, InputIterator&gt;
14575 </pre>
14576
14577 <p><i>[Redmond: Very minor change in proposed resolution.  Original had
14578 a typo, wchart instead of wchar_t.]</i></p>
14579
14580
14581
14582
14583
14584
14585 <hr>
14586 <h3><a name="328"></a>328. Bad sprintf format modifier in money_put&lt;&gt;::do_put()</h3>
14587 <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>
14588  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-07</p>
14589 <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>
14590 <p><b>Discussion:</b></p>
14591 <p>The sprintf format string , "%.01f" (that's the digit one), in the
14592 description of the do_put() member functions of the money_put facet in
14593 22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
14594 for values of type long double, and second, the precision of 01
14595 doesn't seem to make sense. What was most likely intended was
14596 "%.0Lf"., that is a precision of zero followed by the L length
14597 modifier.</p>
14598
14599
14600 <p><b>Proposed resolution:</b></p>
14601 <p>Change the format string to "%.0Lf".</p>
14602
14603
14604 <p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
14605
14606
14607
14608
14609 <hr>
14610 <h3><a name="329"></a>329. vector capacity, reserve and reallocation</h3>
14611 <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>
14612  <b>Submitter:</b> Anthony Williams <b>Date:</b> 2001-07-13</p>
14613 <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>
14614 <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>
14615 <p><b>Discussion:</b></p>
14616 <p>
14617 There is an apparent contradiction about which circumstances can cause
14618 a reallocation of a vector in Section 23.2.5.2 [vector.capacity] and
14619 section 23.2.5.4 [vector.modifiers].
14620 </p>
14621
14622 <p>23.2.5.2 [vector.capacity],p5 says:</p>
14623 <blockquote><p>
14624 Notes: Reallocation invalidates all the references, pointers, and iterators
14625 referring to the elements in the sequence. It is guaranteed that no
14626 reallocation takes place during insertions that happen after a call to
14627 reserve() until the time when an insertion would make the size of the vector
14628 greater than the size specified in the most recent call to reserve().
14629 </p></blockquote>
14630
14631 <p>Which implies if I do</p>
14632
14633 <pre>  std::vector&lt;int&gt; vec;
14634   vec.reserve(23);
14635   vec.reserve(0);
14636   vec.insert(vec.end(),1);
14637 </pre>
14638
14639 <p>then the implementation may reallocate the vector for the insert,
14640 as the size specified in the previous call to reserve was zero.</p>
14641
14642 <p>However, the previous paragraphs (23.2.5.2 [vector.capacity], p1-2) state:</p>
14643 <blockquote>
14644 <p>
14645 (capacity) Returns: The total number of elements the vector
14646 can hold without requiring reallocation
14647 </p>
14648 <p>
14649 ...After reserve(), capacity() is greater or equal to the
14650 argument of reserve if reallocation happens; and equal to the previous value
14651 of capacity() otherwise...
14652 </p>
14653 </blockquote>
14654
14655 <p>
14656 This implies that vec.capacity() is still 23, and so the insert()
14657 should not require a reallocation, as vec.size() is 0. This is backed
14658 up by 23.2.5.4 [vector.modifiers], p1:
14659 </p>
14660 <blockquote><p>
14661 (insert) Notes: Causes reallocation if the new size is greater than the old
14662 capacity.
14663 </p></blockquote>
14664
14665 <p>
14666 Though this doesn't rule out reallocation if the new size is less
14667 than the old capacity, I think the intent is clear.
14668 </p>
14669
14670
14671
14672 <p><b>Proposed resolution:</b></p>
14673 <p>Change the wording of 23.2.5.2 [vector.capacity] paragraph 5 to:</p>
14674
14675 <blockquote><p>
14676 Notes: Reallocation invalidates all the references, pointers, and
14677 iterators referring to the elements in the sequence. It is guaranteed
14678 that no reallocation takes place during insertions that happen after a
14679 call to reserve() until the time when an insertion would make the size
14680 of the vector greater than the value of capacity().
14681 </p></blockquote>
14682
14683 <p><i>[Redmond: original proposed resolution was modified slightly.  In
14684 the original, the guarantee was that there would be no reallocation
14685 until the size would be greater than the value of capacity() after the
14686 most recent call to reserve().  The LWG did not believe that the
14687 "after the most recent call to reserve()" added any useful
14688 information.]</i></p>
14689
14690
14691
14692
14693 <p><b>Rationale:</b></p>
14694 <p>There was general agreement that, when reserve() is called twice in
14695 succession and the argument to the second invocation is smaller than
14696 the argument to the first, the intent was for the second invocation to
14697 have no effect.  Wording implying that such cases have an effect on
14698 reallocation guarantees was inadvertant.</p>
14699
14700
14701
14702
14703
14704 <hr>
14705 <h3><a name="331"></a>331. bad declaration of destructor for ios_base::failure</h3>
14706 <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>
14707  <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-23</p>
14708 <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>
14709 <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>
14710 <p><b>Discussion:</b></p>
14711 <p>
14712 With the change in 17.4.4.8 [res.on.exception.handling] to state
14713    "An implementation may strengthen the exception-specification for a
14714     non-virtual function by removing listed exceptions."
14715 (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>)
14716 and the following declaration of ~failure() in ios_base::failure
14717 </p>
14718 <pre>    namespace std {
14719        class ios_base::failure : public exception {
14720        public:
14721            ...
14722            virtual ~failure();
14723            ...
14724        };
14725      }
14726 </pre>
14727 <p>the class failure cannot be implemented since in 18.6.1 [type.info] the destructor of class exception has an empty
14728 exception specification:</p>
14729 <pre>    namespace std {
14730        class exception {
14731        public:
14732          ...
14733          virtual ~exception() throw();
14734          ...
14735        };
14736      }
14737 </pre>
14738
14739
14740 <p><b>Proposed resolution:</b></p>
14741 <p>Remove the declaration of ~failure().</p>
14742
14743
14744 <p><b>Rationale:</b></p>
14745 <p>The proposed resolution is consistent with the way that destructors
14746 of other classes derived from <tt>exception</tt> are handled.</p>
14747
14748
14749
14750
14751
14752
14753
14754 <hr>
14755 <h3><a name="333"></a>333. does endl imply synchronization with the device?</h3>
14756 <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>
14757  <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-27</p>
14758 <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>
14759 <p><b>Discussion:</b></p>
14760 <p>A footnote in 27.6.2.8 [ostream.manip] states:</p>
14761 <blockquote><p>
14762     [Footnote: The effect of executing cout &lt;&lt; endl is to insert a
14763      newline character in the output sequence controlled by cout, then
14764      synchronize it with any external file with which it might be
14765      associated. --- end foonote]
14766 </p></blockquote>
14767
14768 <p>
14769 Does the term "file" here refer to the external device?
14770 This leads to some implementation ambiguity on systems with fully
14771 buffered files where a newline does not cause a flush to the device.
14772 </p>
14773
14774 <p>
14775 Choosing to sync with the device leads to significant performance
14776 penalties for each call to endl, while not sync-ing leads to
14777 errors under special circumstances.
14778 </p>
14779
14780 <p>
14781 I could not find any other statement that explicitly defined
14782 the behavior one way or the other.
14783 </p>
14784
14785
14786 <p><b>Proposed resolution:</b></p>
14787 <p>Remove footnote 300 from section 27.6.2.8 [ostream.manip].</p>
14788
14789
14790 <p><b>Rationale:</b></p>
14791 <p>We already have normative text saying what <tt>endl</tt> does: it
14792 inserts a newline character and calls <tt>flush</tt>.  This footnote
14793 is at best redundant, at worst (as this issue says) misleading,
14794 because it appears to make promises about what <tt>flush</tt>
14795 does.</p>
14796
14797
14798
14799
14800
14801
14802
14803 <hr>
14804 <h3><a name="334"></a>334. map::operator[] specification forces inefficient implementation</h3>
14805 <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>
14806  <b>Submitter:</b> Andrea Griffini <b>Date:</b> 2001-09-02</p>
14807 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p>
14808 <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>
14809 <p><b>Discussion:</b></p>
14810 <p>
14811 The current standard describes map::operator[] using a
14812 code example. That code example is however quite
14813 inefficient because it requires several useless copies
14814 of both the passed key_type value and of default
14815 constructed mapped_type instances.
14816 My opinion is that was not meant by the comitee to
14817 require all those temporary copies.
14818 </p>
14819
14820 <p>Currently map::operator[] behaviour is specified as: </p>
14821 <pre>  Returns:
14822     (*((insert(make_pair(x, T()))).first)).second.
14823 </pre>
14824
14825 <p>
14826 This specification however uses make_pair that is a
14827 template function of which parameters in this case
14828 will be deduced being of type const key_type&amp; and
14829 const T&amp;. This will create a pair&lt;key_type,T&gt; that
14830 isn't the correct type expected by map::insert so
14831 another copy will be required using the template
14832 conversion constructor available in pair to build
14833 the required pair&lt;const key_type,T&gt; instance.
14834 </p>
14835
14836 <p>If we consider calling of key_type copy constructor
14837 and mapped_type default constructor and copy
14838 constructor as observable behaviour (as I think we
14839 should) then the standard is in this place requiring
14840 two copies of a key_type element plus a default
14841 construction and two copy construction of a mapped_type
14842 (supposing the addressed element is already present
14843 in the map; otherwise at least another copy
14844 construction for each type).
14845 </p>
14846
14847 <p>A simple (half) solution would be replacing the description with:</p>
14848 <pre>  Returns:
14849     (*((insert(value_type(x, T()))).first)).second.
14850 </pre>
14851
14852 <p>This will remove the wrong typed pair construction that
14853 requires one extra copy of both key and value.</p>
14854
14855 <p>However still the using of map::insert requires temporary
14856 objects while the operation, from a logical point of view,
14857 doesn't require any. </p>
14858
14859 <p>I think that a better solution would be leaving free an
14860 implementer to use a different approach than map::insert
14861 that, because of its interface, forces default constructed
14862 temporaries and copies in this case.
14863 The best solution in my opinion would be just requiring
14864 map::operator[] to return a reference to the mapped_type
14865 part of the contained element creating a default element
14866 with the specified key if no such an element is already
14867 present in the container. Also a logarithmic complexity
14868 requirement should be specified for the operation.
14869 </p>
14870
14871 <p>
14872 This would allow library implementers to write alternative
14873 implementations not using map::insert and reaching optimal
14874 performance in both cases of the addressed element being
14875 present or absent from the map (no temporaries at all and
14876 just the creation of a new pair inside the container if
14877 the element isn't present).
14878 Some implementer has already taken this option but I think
14879 that the current wording of the standard rules that as
14880 non-conforming.
14881 </p>
14882
14883
14884
14885 <p><b>Proposed resolution:</b></p>
14886
14887 <p>
14888 Replace 23.3.1.2 [map.access] paragraph 1 with
14889 </p>
14890 <blockquote>
14891 <p>
14892 -1- Effects:  If there is no key equivalent to x in the map, inserts
14893 value_type(x, T()) into the map.
14894 </p>
14895 <p>
14896 -2- Returns: A reference to the mapped_type corresponding to x in *this.
14897 </p>
14898 <p>
14899 -3- Complexity: logarithmic.
14900 </p>
14901 </blockquote>
14902
14903 <p><i>[This is the second option mentioned above.  Howard provided
14904 wording.  We may also wish to have a blanket statement somewhere in
14905 clause 17 saying that we do not intend the semantics of sample code
14906 fragments to be interpreted as specifing exactly how many copies are
14907 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>
14908
14909
14910
14911
14912 <p><b>Rationale:</b></p>
14913 <p>
14914 This is the second solution described above; as noted, it is
14915 consistent with existing practice.
14916 </p>
14917
14918 <p>Note that we now need to specify the complexity explicitly, because
14919 we are no longer defining <tt>operator[]</tt> in terms of
14920 <tt>insert</tt>.</p>
14921
14922
14923
14924
14925
14926 <hr>
14927 <h3><a name="335"></a>335. minor issue with char_traits, table 37</h3>
14928 <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>
14929  <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-09-06</p>
14930 <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>
14931 <p><b>Discussion:</b></p>
14932 <p>
14933 Table 37, in 21.1.1 [char.traits.require], descibes char_traits::assign
14934 as:
14935 </p>
14936 <pre>  X::assign(c,d)   assigns c = d.
14937 </pre>
14938
14939 <p>And para 1 says:</p>
14940
14941 <blockquote><p>
14942  [...] c and d denote values of type CharT [...]
14943 </p></blockquote>
14944
14945 <p>
14946 Naturally, if c and d are <i>values</i>, then the assignment is
14947 (effectively) meaningless. It's clearly intended that (in the case of
14948 assign, at least), 'c' is intended to be a reference type.
14949 </p>
14950
14951 <p>I did a quick survey of the four implementations I happened to have
14952 lying around, and sure enough they all have signatures:</p>
14953 <pre>    assign( charT&amp;, const charT&amp; );
14954 </pre>
14955
14956 <p>(or the equivalent). It's also described this way in Nico's book.
14957 (Not to mention the synopses of char_traits&lt;char&gt; in 21.1.3.1
14958 and char_traits&lt;wchar_t&gt; in 21.1.3.2...)
14959 </p>
14960
14961
14962 <p><b>Proposed resolution:</b></p>
14963 <p>Add the following to 21.1.1 para 1:</p>
14964 <blockquote><p>
14965  r denotes an lvalue of CharT
14966 </p></blockquote>
14967
14968 <p>and change the description of assign in the table to:</p>
14969 <pre>  X::assign(r,d)   assigns r = d
14970 </pre>
14971
14972
14973
14974
14975
14976 <hr>
14977 <h3><a name="336"></a>336. Clause 17 lack of references to deprecated headers</h3>
14978 <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>
14979  <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-09-05</p>
14980 <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>
14981 <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>
14982 <p><b>Discussion:</b></p>
14983 <p>From c++std-edit-873:</p>
14984
14985 <p>17.4.1.2 [headers], Table 11.  In this table, the header
14986 &lt;strstream&gt; is missing.</p>
14987
14988 <p>This shows a general problem: The whole clause 17 refers quite
14989 often to clauses 18 through 27, but D.7 is also a part of the standard
14990 library (though a deprecated one).</p>
14991
14992
14993
14994 <p><b>Proposed resolution:</b></p>
14995
14996 <p>To 17.4.1.2 [headers] Table 11, C++ Library Headers, add
14997 "&lt;strstream&gt;".</p>
14998
14999 <p>In the following places, change "clauses 17 through 27" to "clauses
15000 17 through 27 and Annex D":</p>
15001
15002 <ul>
15003 <li>1.2 [intro.refs] Normative references/1/footnote 1</li>
15004 <li>1.3 [intro.defs] Definitions/1</li>
15005 <li>7 [dcl.dcl] Library introduction/9</li>
15006 <li>17.3 [description] Method of description (Informative)/1</li>
15007 <li>17.3.2.1.3 [character.seq] Character sequences/1/bullet 2</li>
15008 <li>17.3.2.2 [functions.within.classes] Functions within classes/1</li>
15009 <li>17.3.2.3 [objects.within.classes] Private members/1/(2 places)</li>
15010 <li>17.4 [requirements] Library-wide requirements/1</li>
15011 <li>17.4.1.2 [headers] Headers/4</li>
15012 <li>17.4.3.4 [replacement.functions] Replacement functions/1</li>
15013 <li>17.4.4.3 [global.functions] Global or non-member functions/2</li>
15014 <li>17.4.4.6 [protection.within.classes] Protection within classes/1</li>
15015 </ul>
15016
15017
15018
15019
15020
15021
15022
15023 <hr>
15024 <h3><a name="337"></a>337. replace_copy_if's template parameter should be InputIterator</h3>
15025 <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>
15026  <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-09-07</p>
15027 <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>
15028 <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>
15029 <p><b>Discussion:</b></p>
15030 <p>From c++std-edit-876:</p>
15031
15032 <p>
15033 In section 25.2.5 [alg.replace] before p4: The name of the first
15034 parameter of template replace_copy_if should be "InputIterator"
15035 instead of "Iterator".  According to 17.3.2.1 [type.descriptions] p1 the
15036 parameter name conveys real normative meaning.
15037 </p>
15038
15039
15040 <p><b>Proposed resolution:</b></p>
15041 <p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
15042
15043
15044
15045
15046
15047 <hr>
15048 <h3><a name="338"></a>338.  is whitespace allowed between `-' and a digit?</h3>
15049 <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>
15050  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-09-17</p>
15051 <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>
15052 <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>
15053 <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>
15054 <p><b>Discussion:</b></p>
15055 <p>
15056 From Stage 2 processing in 22.2.2.1.2 [facet.num.get.virtuals], p8 and 9 (the
15057 original text or the text corrected by the proposed resolution of
15058 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
15059 within a number, but 22.2.3.1 [locale.numpunct], p2, which gives the
15060 format for integer and floating point values, says that whitespace is
15061 optional between a plusminus and a sign.
15062 </p>
15063
15064 <p>
15065 The text needs to be clarified to either consistently allow or
15066 disallow whitespace between a plusminus and a sign. It might be
15067 worthwhile to consider the fact that the C library stdio facility does
15068 not permit whitespace embedded in numbers and neither does the C or
15069 C++ core language (the syntax of integer-literals is given in 2.13.1
15070 [lex.icon], that of floating-point-literals in 2.13.3 [lex.fcon] of the
15071 C++ standard).
15072 </p>
15073
15074
15075 <p><b>Proposed resolution:</b></p>
15076 <p>Change the first part of 22.2.3.1 [locale.numpunct] paragraph 2 from:</p>
15077 <blockquote>
15078 <p>
15079 The syntax for number formats is as follows, where <tt>digit</tt>
15080 represents the radix set specified by the <tt>fmtflags</tt> argument
15081 value, <tt>whitespace</tt> is as determined by the facet
15082 <tt>ctype&lt;charT&gt;</tt> (22.2.1.1), and <tt>thousands-sep</tt> and
15083 <tt>decimal-point</tt> are the results of corresponding
15084 <tt>numpunct&lt;charT&gt;</tt> members.  Integer values have the
15085 format:
15086 </p>
15087 <pre>  integer   ::= [sign] units
15088   sign      ::= plusminus [whitespace]
15089   plusminus ::= '+' | '-'
15090   units     ::= digits [thousands-sep units]
15091   digits    ::= digit [digits]
15092 </pre>
15093 </blockquote>
15094 <p>to:</p>
15095 <blockquote>
15096 <p>
15097 The syntax for number formats is as follows, where <tt>digit</tt>
15098 represents the radix set specified by the <tt>fmtflags</tt> argument
15099 value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
15100 results of corresponding <tt>numpunct&lt;charT&gt;</tt> members.
15101 Integer values have the format:
15102 </p>
15103 <pre>  integer   ::= [sign] units
15104   sign      ::= plusminus
15105   plusminus ::= '+' | '-'
15106   units     ::= digits [thousands-sep units]
15107   digits    ::= digit [digits]
15108 </pre>
15109 </blockquote>
15110
15111
15112 <p><b>Rationale:</b></p>
15113 <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
15114 standard says how, or whether, it's used.  However, there's no reason
15115 for it to differ gratuitously from the very specific description of
15116 numeric processing in 22.2.2.1.2 [facet.num.get.virtuals].  The proposed
15117 resolution removes all mention of "whitespace" from that format.</p>
15118
15119
15120
15121
15122
15123 <hr>
15124 <h3><a name="339"></a>339. definition of bitmask type restricted to clause 27</h3>
15125 <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>
15126  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-09-17</p>
15127 <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>
15128 <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>
15129 <p><b>Discussion:</b></p>
15130 <p>The ctype_category::mask type is declared to be an enum in 22.2.1
15131 [category.ctype] with p1 then stating that it is a bitmask type, most
15132 likely referring to the definition of bitmask type in 17.3.2.1.2
15133 [bitmask.types], p1. However, the said definition only applies to
15134 clause 27, making the reference in 22.2.1 somewhat dubious.
15135 </p>
15136
15137
15138 <p><b>Proposed resolution:</b></p>
15139 <p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
15140     <blockquote><p>
15141     Several types defined in clause 27 are bitmask types. Each bitmask type
15142     can be implemented as an enumerated type that overloads certain operators,
15143     as an integer type, or as a bitset (23.3.5 [template.bitset]).
15144     </p></blockquote>
15145 <p>to read</p>
15146     <blockquote><p>
15147     Several types defined in clauses lib.language.support through
15148     lib.input.output and Annex D are bitmask types. Each bitmask type can
15149     be implemented as an enumerated type that overloads certain operators,
15150     as an integer  type, or as a bitset (lib.template.bitset).
15151     </p></blockquote>
15152
15153 <p>
15154 Additionally, change the definition in 22.2.1 to adopt the same
15155 convention as in clause 27 by replacing the existing text with the
15156 following (note, in particluar, the cross-reference to 17.3.2.1.2 in
15157 22.2.1, p1):
15158 </p>
15159
15160 <blockquote>
15161 <p>22.2.1 The ctype category [lib.category.ctype]</p>
15162 <pre>namespace std {
15163     class ctype_base {
15164     public:
15165         typedef <b><i>T</i></b> mask;
15166
15167         // numeric values are for exposition only.
15168         static const mask space = 1 &lt;&lt; 0;
15169         static const mask print = 1 &lt;&lt; 1;
15170         static const mask cntrl = 1 &lt;&lt; 2;
15171         static const mask upper = 1 &lt;&lt; 3;
15172         static const mask lower = 1 &lt;&lt; 4;
15173         static const mask alpha = 1 &lt;&lt; 5;
15174         static const mask digit = 1 &lt;&lt; 6;
15175         static const mask punct = 1 &lt;&lt; 7;
15176         static const mask xdigit = 1 &lt;&lt; 8;
15177         static const mask alnum = alpha | digit;
15178         static const mask graph = alnum | punct;
15179     };
15180 }
15181 </pre>
15182
15183 <p>The type <tt>mask</tt> is a bitmask type (17.3.2.1.2 [bitmask.types]).</p>
15184 </blockquote>
15185
15186 <p><i>[Curaçao: The LWG notes that T above should be bold-italics to be
15187 consistent with the rest of the standard.]</i></p>
15188
15189
15190
15191
15192
15193
15194
15195
15196
15197 <hr>
15198 <h3><a name="340"></a>340. interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt></h3>
15199 <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>
15200  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-09-18</p>
15201 <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>
15202 <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>
15203 <p><b>Discussion:</b></p>
15204 <p>
15205 It's unclear whether 22.1.1.1.1, p3 says that
15206 <tt>has_facet&lt;Facet&gt;(loc)</tt> returns true for any <tt>Facet</tt>
15207 from Table 51 or whether it includes Table 52 as well:
15208 </p>
15209
15210 <blockquote><p>
15211 For any locale <tt>loc</tt> either constructed, or returned by
15212 locale::classic(), and any facet <tt>Facet</tt> that is a member of a
15213 standard category, <tt>has_facet&lt;Facet&gt;(loc)</tt> is true. Each
15214 locale member function which takes a <tt>locale::category</tt>
15215 argument operates on the corresponding set of facets.
15216 </p></blockquote>
15217
15218 <p>
15219 It seems that it comes down to which facets are considered to be members of a
15220 standard category. Intuitively, I would classify all the facets in Table 52 as
15221 members of their respective standard categories, but there are an unbounded set
15222 of them...
15223 </p>
15224
15225 <p>
15226 The paragraph implies that, for instance, <tt>has_facet&lt;num_put&lt;C,
15227 OutputIterator&gt; &gt;(loc)</tt> must always return true. I don't think that's
15228 possible. If it were, then <tt>use_facet&lt;num_put&lt;C, OutputIterator&gt;
15229 &gt;(loc)</tt> would have to return a reference to a distinct object for each
15230 valid specialization of <tt>num_put&lt;C, OutputIteratory&gt;</tt>, which is
15231 clearly impossible.
15232 </p>
15233
15234 <p>
15235 On the other hand, if none of the facets in Table 52 is a member of a standard
15236 category then none of the locale member functions that operate on entire
15237 categories of facets will work properly.
15238 </p>
15239
15240 <p>
15241 It seems that what p3 should mention that it's required (permitted?)
15242 to hold only for specializations of <tt>Facet</tt> from Table 52 on
15243 <tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
15244 <tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
15245 {
15246 {i,o}<tt>streambuf_iterator</tt>&lt;{<tt>char</tt>,<tt>wchar_t</tt>}<tt>&gt;</tt>
15247 }.
15248 </p>
15249
15250
15251 <p><b>Proposed resolution:</b></p>
15252 <p>In 22.1.1.1.1 [locale.category], paragraph 3, change
15253 "that is a member of a standard category" to "shown in Table 51".</p>
15254
15255
15256 <p><b>Rationale:</b></p>
15257 <p>The facets in Table 52 are an unbounded set.  Locales should not be
15258 required to contain an infinite number of facets.</p>
15259
15260 <p>It's not necessary to talk about which values of InputIterator and
15261 OutputIterator must be supported.  Table 51 already contains a
15262 complete list of the ones we need.</p>
15263
15264
15265
15266
15267
15268
15269 <hr>
15270 <h3><a name="341"></a>341. Vector reallocation and swap</h3>
15271 <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>
15272  <b>Submitter:</b> Anthony Williams <b>Date:</b> 2001-09-27</p>
15273 <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>
15274 <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>
15275 <p><b>Discussion:</b></p>
15276 <p>It is a common idiom to reduce the capacity of a vector by swapping it with
15277 an empty one:</p>
15278 <pre>  std::vector&lt;SomeType&gt; vec;
15279   // fill vec with data
15280   std::vector&lt;SomeType&gt;().swap(vec);
15281   // vec is now empty, with minimal capacity
15282 </pre>
15283
15284 <p>However, the wording of 23.2.5.2 [vector.capacity]paragraph 5 prevents
15285 the capacity of a vector being reduced, following a call to
15286 reserve(). This invalidates the idiom, as swap() is thus prevented
15287 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
15288 requires the temporary to be expanded to cater for the contents of
15289 vec, and the contents be copied across. This is a linear-time
15290 operation.</p>
15291
15292 <p>However, the container requirements state that swap must have constant
15293 complexity (23.1 [container.requirements] note to table 65).</p>
15294
15295 <p>This is an important issue, as reallocation affects the validity of
15296 references and iterators.</p>
15297
15298 <p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
15299 references and iterators remain valid after a call to swap, if they refer to
15300 an element before the new end() of the vector into which they originally
15301 pointed, in which case they refer to the element at the same index position.
15302 Iterators and references that referred to an element whose index position
15303 was beyond the new end of the vector are invalidated.</p>
15304
15305 <p>If the note to table 65 is taken as the desired intent, then there are two
15306 possibilities with regard to iterators and references:</p>
15307
15308 <ol>
15309 <li>All Iterators and references into both vectors are invalidated.</li>
15310 <li>Iterators and references into either vector remain valid, and remain
15311 pointing to the same element. Consequently iterators and references that
15312 referred to one vector now refer to the other, and vice-versa.</li>
15313 </ol>
15314
15315
15316 <p><b>Proposed resolution:</b></p>
15317 <p>Add a new paragraph after 23.2.5.2 [vector.capacity] paragraph 5:</p>
15318 <blockquote>
15319 <pre>  void swap(vector&lt;T,Allocator&gt;&amp; x);
15320 </pre>
15321 <p><b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
15322 with that of <tt>x</tt>.</p>
15323 <p><b>Complexity:</b> Constant time.</p>
15324 </blockquote>
15325
15326 <p><i>[This solves the problem reported for this issue.  We may also
15327 have a problem with a circular definition of swap() for other
15328 containers.]</i></p>
15329
15330
15331
15332
15333 <p><b>Rationale:</b></p>
15334 <p>
15335 swap should be constant time.  The clear intent is that it should just
15336 do pointer twiddling, and that it should exchange all properties of
15337 the two vectors, including their reallocation guarantees.
15338 </p>
15339
15340
15341
15342
15343
15344 <hr>
15345 <h3><a name="345"></a>345. type tm in &lt;cwchar&gt;</h3>
15346 <p><b>Section:</b> 21.5 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15347  <b>Submitter:</b> Clark Nelson <b>Date:</b> 2001-10-19</p>
15348 <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>
15349 <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>
15350 <p><b>Discussion:</b></p>
15351 <p>C99, and presumably amendment 1 to C90, specify that &lt;wchar.h&gt;
15352 declares struct tm as an incomplete type. However, table 48 in 21.5
15353 [c.strings] does not mention the type tm as being declared in
15354 &lt;cwchar&gt;. Is this omission intentional or accidental?
15355 </p>
15356
15357
15358 <p><b>Proposed resolution:</b></p>
15359 <p>In section 21.5 [c.strings], add "tm" to table 48.</p>
15360
15361
15362
15363
15364
15365 <hr>
15366 <h3><a name="346"></a>346. Some iterator member functions should be const</h3>
15367 <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>
15368  <b>Submitter:</b> Jeremy Siek <b>Date:</b> 2001-10-20</p>
15369 <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>
15370 <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>
15371 <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>
15372 <p><b>Discussion:</b></p>
15373 <p>Iterator member functions and operators that do not change the state
15374 of the iterator should be defined as const member functions or as
15375 functions that take iterators either by const reference or by
15376 value. The standard does not explicitly state which functions should
15377 be const.  Since this a fairly common mistake, the following changes
15378 are suggested to make this explicit.</p>
15379
15380 <p>The tables almost indicate constness properly through naming: r
15381 for non-const and a,b for const iterators. The following changes
15382 make this more explicit and also fix a couple problems.</p>
15383
15384
15385 <p><b>Proposed resolution:</b></p>
15386 <p>In 24.1 [iterator.requirements] Change the first section of p9 from
15387 "In the following sections, a and b denote values of X..." to
15388 "In the following sections, a and b denote values of type const X...".</p>
15389
15390 <p>In Table 73, change</p>
15391 <pre>    a-&gt;m   U&amp;         ...
15392 </pre>
15393
15394 <p>to</p>
15395
15396 <pre>    a-&gt;m   const U&amp;   ...
15397     r-&gt;m   U&amp;         ...
15398 </pre>
15399
15400 <p>In Table 73 expression column, change</p>
15401
15402 <pre>    *a = t
15403 </pre>
15404
15405 <p>to</p>
15406
15407 <pre>    *r = t
15408 </pre>
15409
15410 <p><i>[Redmond: The container requirements should be reviewed to see if
15411 the same problem appears there.]</i></p>
15412
15413
15414
15415
15416
15417
15418
15419 <hr>
15420 <h3><a name="347"></a>347. locale::category and bitmask requirements</h3>
15421 <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>
15422  <b>Submitter:</b> P.J. Plauger, Nathan Myers <b>Date:</b> 2001-10-23</p>
15423 <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>
15424 <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>
15425 <p><b>Discussion:</b></p>
15426 <p>
15427 In 22.1.1.1.1 [locale.category] paragraph 1, the category members
15428 are described as bitmask elements.  In fact, the bitmask requirements
15429 in 17.3.2.1.2 [bitmask.types] don't seem quite right: <tt>none</tt>
15430 and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
15431
15432 <p>In particular, the requirements for <tt>none</tt> interact poorly
15433 with the requirement that the LC_* constants from the C library must
15434 be recognizable as C++ locale category constants.  LC_* values should
15435 not be mixed with these values to make category values.</p>
15436
15437 <p>We have two options for the proposed resolution.  Informally:
15438 option 1 removes the requirement that LC_* values be recognized as
15439 category arguments.  Option 2 changes the category type so that this
15440 requirement is implementable, by allowing <tt>none</tt> to be some
15441 value such as 0x1000 instead of 0.</p>
15442
15443 <p>Nathan writes: "I believe my proposed resolution [Option 2] merely
15444 re-expresses the status quo more clearly, without introducing any
15445 changes beyond resolving the DR.</p>
15446
15447
15448
15449 <p><b>Proposed resolution:</b></p>
15450 <p>Replace the first two paragraphs of 22.1.1.1 [locale.types] with:</p>
15451 <blockquote>
15452 <pre>    typedef int category;
15453 </pre>
15454
15455 <p>Valid category values include the <tt>locale</tt> member bitmask
15456 elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
15457 <tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
15458 represents a single locale category. In addition, <tt>locale</tt> member
15459 bitmask constant <tt>none</tt> is defined as zero and represents no
15460 category. And locale member bitmask constant <tt>all</tt> is defined such that
15461 the expression</p>
15462 <pre>    (collate | ctype | monetary | numeric | time | messages | all) == all
15463 </pre>
15464 <p>
15465 is <tt>true</tt>, and represents the union of all categories.  Further
15466 the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
15467 represent a single category, represents the union of the two
15468 categories.
15469 </p>
15470
15471 <p>
15472 <tt>locale</tt> member functions expecting a <tt>category</tt>
15473 argument require one of the <tt>category</tt> values defined above, or
15474 the union of two or more such values. Such a <tt>category</tt>
15475 argument identifies a set of locale categories. Each locale category,
15476 in turn, identifies a set of locale facets, including at least those
15477 shown in Table 51:
15478 </p>
15479 </blockquote>
15480 <p><i>[Curaçao: need input from locale experts.]</i></p>
15481
15482
15483
15484
15485 <p><b>Rationale:</b></p>
15486
15487 <p>The LWG considered, and rejected, an alternate proposal (described
15488   as "Option 2" in the discussion).  The main reason for rejecting it
15489   was that library implementors were concerened about implementation
15490   difficult, given that getting a C++ library to work smoothly with a
15491   separately written C library is already a delicate business.  Some
15492   library implementers were also concerned about the issue of adding
15493   extra locale categories.</p>
15494
15495 <blockquote>
15496 <p><b>Option 2:</b> <br>
15497 Replace the first paragraph of 22.1.1.1 [locale.types] with:</p>
15498 <blockquote>
15499 <p>
15500 Valid category values include the enumerated values.  In addition, the
15501 result of applying commutative operators | and &amp; to any two valid
15502 values is valid, and results in the setwise union and intersection,
15503 respectively, of the argument categories.  The values <tt>all</tt> and
15504 <tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
15505 expressions <tt>(cat | all == all)</tt>, <tt>(cat &amp; all == cat)</tt>,
15506 <tt>(cat | none == cat)</tt> and <tt>(cat &amp; none == none)</tt> are
15507 true.  For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
15508 remaining enumerated values, <tt>(cat1 &amp; cat2 == none)</tt> is true.
15509 For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
15510 of <tt>(cat1 &amp; ~cat2)</tt> is valid, and equals the setwise union of
15511 those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
15512 [Footnote: it is not required that <tt>all</tt> equal the setwise union
15513 of the other enumerated values; implementations may add extra categories.]
15514 </p>
15515 </blockquote>
15516 </blockquote>
15517
15518
15519
15520
15521
15522 <hr>
15523 <h3><a name="349"></a>349. Minor typographical error in ostream_iterator</h3>
15524 <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>
15525  <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-10-24</p>
15526 <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>
15527 <p><b>Discussion:</b></p>
15528 <p>24.5.2 [lib.ostream.iterator] states:</p>
15529 <pre>    [...]
15530
15531     private:
15532     // basic_ostream&lt;charT,traits&gt;* out_stream; exposition only
15533     // const char* delim; exposition only
15534 </pre>
15535
15536 <p>Whilst it's clearly marked "exposition only", I suspect 'delim'
15537 should be of type 'const charT*'.</p>
15538
15539
15540 <p><b>Proposed resolution:</b></p>
15541 <p>
15542 In 24.5.2 [ostream.iterator], replace <tt>const char* delim</tt> with
15543 <tt>const charT* delim</tt>.
15544 </p>
15545
15546
15547
15548
15549
15550 <hr>
15551 <h3><a name="352"></a>352. missing fpos requirements</h3>
15552 <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>
15553  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-12-02</p>
15554 <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>
15555 <p><b>Discussion:</b></p>
15556 <p>
15557 <i>(1)</i>
15558 There are no requirements on the <tt>stateT</tt> template parameter of
15559 <tt>fpos</tt> listed in 27.4.3. The interface appears to require that
15560 the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
15561 and I think also DefaultConstructible (to implement the operations in
15562 Table 88).
15563 </p>
15564 <p>
15565 21.1.2, p3, however, only requires that
15566 <tt>char_traits&lt;charT&gt;::state_type</tt> meet the requirements of
15567 CopyConstructible types.
15568 </p>
15569 <p>
15570 <i>(2)</i>
15571 Additionally, the <tt>stateT</tt> template argument has no
15572 corresponding typedef in fpos which might make it difficult to use in
15573 generic code.
15574 </p>
15575
15576
15577 <p><b>Proposed resolution:</b></p>
15578 <p>
15579 Modify 21.1.2, p4 from
15580 </p>
15581 <p>
15582     Requires: <tt>state_type</tt> shall meet the requirements of
15583               CopyConstructible types (20.1.3).
15584 </p>
15585 <p>
15586     Requires: state_type shall meet the requirements of Assignable
15587               (23.1, p4), CopyConstructible (20.1.3), and
15588               DefaultConstructible  (20.1.4) types.
15589 </p>
15590
15591
15592
15593 <p><b>Rationale:</b></p>
15594 <p>The LWG feels this is two issues, as indicated above. The first is
15595 a defect---std::basic_fstream is unimplementable without these
15596 additional requirements---and the proposed resolution fixes it.  The
15597 second is questionable; who would use that typedef?  The class
15598 template fpos is used only in a very few places, all of which know the
15599 state type already.  Unless motivation is provided, the second should
15600 be considered NAD.</p>
15601
15602
15603
15604
15605
15606 <hr>
15607 <h3><a name="354"></a>354. Associative container lower/upper bound requirements</h3>
15608 <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>
15609  <b>Submitter:</b> Hans Aberg <b>Date:</b> 2001-12-17</p>
15610 <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>
15611 <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>
15612 <p><b>Discussion:</b></p>
15613 <p>
15614 Discussions in the thread "Associative container lower/upper bound
15615 requirements" on comp.std.c++ suggests that there is a defect in the
15616 C++ standard, Table 69 of section 23.1.2, "Associative containers",
15617 [lib.associative.reqmts].  It currently says:</p>
15618
15619 <blockquote>
15620 <p>
15621 a.find(k): returns an iterator pointing to an element with the key equivalent to
15622 k, or a.end() if such an element is not found.
15623 </p>
15624
15625 <p>
15626 a.lower_bound(k): returns an iterator pointing to the first element with
15627 key not less than k.
15628 </p>
15629
15630 <p>
15631 a.upper_bound(k): returns an iterator pointing to the first element with
15632 key greater than k.
15633 </p>
15634 </blockquote>
15635
15636 <p>
15637 We have "or a.end() if such an element is not found" for
15638 <tt>find</tt>, but not for <tt>upper_bound</tt> or
15639 <tt>lower_bound</tt>.  As the text stands, one would be forced to
15640 insert a new element into the container and return an iterator to that
15641 in case the sought iterator does not exist, which does not seem to be
15642 the intention (and not possible with the "const" versions).
15643 </p>
15644
15645
15646 <p><b>Proposed resolution:</b></p>
15647
15648 <p>Change Table 69 of section 23.1.2 [associative.reqmts] indicated entries
15649 to:</p>
15650
15651 <blockquote>
15652 <p>
15653 a.lower_bound(k): returns an iterator pointing to the first element with
15654 key not less than k, or a.end() if such an element is not found.
15655 </p>
15656
15657 <p>
15658 a.upper_bound(k): returns an iterator pointing to the first element with
15659 key greater than k, or a.end() if such an element is not found.
15660 </p>
15661 </blockquote>
15662
15663 <p><i>[Curaçao: LWG reviewed PR.]</i></p>
15664
15665
15666
15667
15668
15669
15670
15671
15672 <hr>
15673 <h3><a name="355"></a>355. Operational semantics for a.back()</h3>
15674 <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>
15675  <b>Submitter:</b> Yaroslav Mironov <b>Date:</b> 2002-01-23</p>
15676 <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>
15677 <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>
15678 <p><b>Discussion:</b></p>
15679
15680 <p>Table 68 "Optional Sequence Operations" in 23.1.1/12
15681 specifies operational semantics for "a.back()" as
15682 "*--a.end()", which may be ill-formed <i>[because calling
15683 operator-- on a temporary (the return) of a built-in type is
15684 ill-formed]</i>, provided a.end() returns a simple pointer rvalue
15685 (this is almost always the case for std::vector::end(), for
15686 example). Thus, the specification is not only incorrect, it
15687 demonstrates a dangerous construct: "--a.end()" may
15688 successfully compile and run as intended, but after changing the type
15689 of the container or the mode of compilation it may produce
15690 compile-time error. </p>
15691
15692
15693
15694 <p><b>Proposed resolution:</b></p>
15695 <p>Change the specification in table 68 "Optional Sequence
15696 Operations" in 23.1.1/12 for "a.back()" from</p>
15697
15698
15699 <blockquote><pre>*--a.end()
15700 </pre></blockquote>
15701
15702 <p>to</p>
15703
15704 <blockquote><pre>  { iterator tmp = a.end(); --tmp; return *tmp; }
15705 </pre></blockquote>
15706
15707 <p>and the specification for "a.pop_back()" from</p>
15708
15709 <blockquote><pre>a.erase(--a.end())
15710 </pre></blockquote>
15711
15712 <p>to</p>
15713
15714 <blockquote><pre>  { iterator tmp = a.end(); --tmp; a.erase(tmp); }
15715 </pre></blockquote>
15716
15717 <p><i>[Curaçao: LWG changed PR from "{ X::iterator tmp =
15718 a.end(); return *--tmp; }" to "*a.rbegin()", and from
15719 "{ X::iterator tmp = a.end(); a.erase(--tmp); }" to
15720 "a.erase(rbegin())".]</i></p>
15721
15722
15723 <p><i>[There is a second possible defect; table 68 "Optional
15724 Sequence Operations" in the "Operational Semantics"
15725 column uses operations present only in the "Reversible
15726 Container" requirements, yet there is no stated dependency
15727 between these separate requirements tables. Ask in Santa Cruz if the
15728 LWG would like a new issue opened.]</i></p>
15729
15730
15731 <p><i>[Santa Cruz: the proposed resolution is even worse than what's in
15732   the current standard: erase is undefined for reverse iterator.  If
15733   we're going to make the change, we need to define a temporary and
15734   use operator--.  Additionally, we don't know how prevalent this is:
15735   do we need to make this change in more than one place?  Martin has
15736   volunteered to review the standard and see if this problem occurs
15737   elsewhere.]</i></p>
15738
15739
15740 <p><i>[Oxford: Matt provided new wording to address the concerns raised
15741   in Santa Cruz.  It does not appear that this problem appears
15742   anywhere else in clauses 23 or 24.]</i></p>
15743
15744
15745 <p><i>[Kona: In definition of operational semantics of back(), change
15746 "*tmp" to "return *tmp;"]</i></p>
15747
15748
15749
15750
15751
15752
15753
15754 <hr>
15755 <h3><a name="358"></a>358. interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt></h3>
15756 <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>
15757  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
15758 <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>
15759 <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>
15760 <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>
15761 <p><b>Discussion:</b></p>
15762 <p>
15763 I don't think <tt>thousands_sep</tt> is being treated correctly after
15764 decimal_point has been seen. Since grouping applies only to the
15765 integral part of the number, the first such occurrence should, IMO,
15766 terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
15767 and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
15768 interpreted in the fractional part of a number.)
15769 </p>
15770
15771 <p>
15772 The easiest change I can think of that resolves this issue would be
15773 something like below.
15774 </p>
15775
15776
15777 <p><b>Proposed resolution:</b></p>
15778 <p>
15779 Change the first sentence of 22.2.2.1.2, p9 from
15780 </p>
15781
15782 <blockquote><p>
15783     If discard is true then the position of the character is
15784     remembered, but the character is otherwise ignored. If it is not
15785     discarded, then a check is made to determine if c is allowed as
15786     the next character of an input field of the conversion specifier
15787     returned by stage 1. If so it is accumulated.
15788 </p></blockquote>
15789
15790 <p>to</p>
15791
15792 <blockquote><p>
15793     If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
15794     accumulated, then the position of the character is remembered, but
15795     the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
15796     already been accumulated, the character is discarded and Stage 2
15797      terminates. ...
15798 </p></blockquote>
15799
15800
15801
15802 <p><b>Rationale:</b></p>
15803 <p>We believe this reflects the intent of the Standard.  Thousands sep
15804   characters after the decimal point are not useful in any locale.
15805   Some formatting conventions do group digits that follow the decimal
15806   point, but they usually introduce a different grouping character
15807   instead of reusing the thousand sep character.  If we want to add
15808   support for such conventions, we need to do so explicitly.</p>
15809
15810
15811
15812
15813
15814
15815 <hr>
15816 <h3><a name="359"></a>359. num_put&lt;&gt;::do_put (..., bool) undocumented</h3>
15817 <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>
15818  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
15819 <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>
15820 <p><b>Discussion:</b></p>
15821 <p>22.2.2.2.1, p1:</p>
15822
15823     <pre>    iter_type put (iter_type out, ios_base&amp; str, char_type fill,
15824                    bool val) const;
15825     ...
15826
15827     1   Returns: do_put (out, str, fill, val).
15828     </pre>
15829
15830 <p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
15831 however, 22.2.2.2.2, p23:</p>
15832
15833 <blockquote>
15834 <pre>iter_type put (iter_type out, ios_base&amp; str, char_type fill,
15835                bool val) const;
15836 </pre>
15837
15838
15839         <p>Effects: If (str.flags() &amp; ios_base::boolalpha) == 0 then do
15840              out = do_put(out, str, fill, (int)val)
15841            Otherwise do</p>
15842 <pre>             string_type s =
15843                  val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
15844                      : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
15845 </pre>
15846            <p>and then insert the characters of s into out. <i>out</i>.</p>
15847 </blockquote>
15848
15849 <p>
15850 This means that the bool overload of <tt>do_put()</tt> will never be called,
15851 which contradicts the first paragraph. Perhaps the declaration
15852 should read <tt>do_put()</tt>, and not <tt>put()</tt>?
15853 </p>
15854
15855 <p>
15856 Note also that there is no <b>Returns</b> clause for this function, which
15857 should probably be corrected, just as should the second occurrence
15858 of <i>"out."</i> in the text.
15859 </p>
15860
15861 <p>
15862 I think the least invasive change to fix it would be something like
15863 the following:
15864 </p>
15865
15866
15867 <p><b>Proposed resolution:</b></p>
15868 <p>In 22.2.2.2.2 [facet.num.put.virtuals], just above paragraph 1, remove
15869   the <tt>bool</tt> overload.</p>
15870
15871 <p>
15872 In 22.2.2.2.2 [facet.num.put.virtuals], p23, make the following changes
15873 </p>
15874
15875 <blockquote><p>
15876      Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
15877      of the member function.
15878 </p></blockquote>
15879
15880 <blockquote><p>
15881     Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
15882     avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
15883     do_put (..., bool))</tt>
15884     like so:
15885 </p></blockquote>
15886
15887 <blockquote><p>
15888     23   <b>Returns</b>: If <tt>(str.flags() &amp;
15889          ios_base::boolalpha) == 0</tt> then
15890          <tt>do_put (out, str, fill, (long)val)</tt>
15891          Otherwise the function obtains a string <tt>s</tt> as if by</p>
15892 <pre>             string_type s =
15893                 val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
15894                     : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
15895 </pre>
15896          <p>and then inserts each character <tt>c</tt> of s into out via
15897            <tt>*out++ = c</tt>
15898          and returns <tt>out</tt>.</p>
15899 </blockquote>
15900
15901
15902
15903 <p><b>Rationale:</b></p><p>
15904 This fixes a couple of obvious typos, and also fixes what appears to
15905 be a requirement of gratuitous inefficiency.
15906 </p>
15907
15908
15909
15910
15911 <hr>
15912 <h3><a name="360"></a>360. locale mandates inefficient implementation</h3>
15913 <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>
15914  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
15915 <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>
15916 <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>
15917 <p><b>Discussion:</b></p>
15918 <p>
15919 22.1.1, p7 (copied below) allows iostream formatters and extractors
15920 to make assumptions about the values returned from facet members.
15921 However, such assumptions are apparently not guaranteed to hold
15922 in other cases (e.g., when the facet members are being called directly
15923 rather than as a result of iostream calls, or between successive
15924 calls to the same iostream functions with no interevening calls to
15925 <tt>imbue()</tt>, or even when the facet member functions are called
15926 from other member functions of other facets). This restriction
15927 prevents locale from being implemented efficiently.
15928 </p>
15929
15930
15931 <p><b>Proposed resolution:</b></p>
15932 <p>Change the first sentence in 22.1.1, p7 from</p>
15933 <blockquote><p>
15934     In successive calls to a locale facet member function during
15935     a call to an iostream inserter or extractor or a streambuf member
15936     function, the returned result shall be identical. [Note: This
15937     implies that such results may safely be reused without calling
15938     the locale facet member function again, and that member functions
15939     of iostream classes cannot safely call <tt>imbue()</tt>
15940     themselves, except as specified elsewhere. --end note]
15941 </p></blockquote>
15942
15943 <p>to</p>
15944
15945 <blockquote><p>
15946     In successive calls to a locale facet member function on a facet
15947     object installed in the same locale, the returned result shall be
15948     identical. ...
15949 </p></blockquote>
15950
15951
15952
15953 <p><b>Rationale:</b></p>
15954 <p>This change is reasonable becuase it clarifies the intent of this
15955   part of the standard.</p>
15956
15957
15958
15959
15960
15961 <hr>
15962 <h3><a name="362"></a>362. bind1st/bind2nd type safety</h3>
15963 <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>
15964  <b>Submitter:</b> Andrew Demkin <b>Date:</b> 2002-04-26</p>
15965 <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>
15966 <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>
15967 <p><b>Discussion:</b></p>
15968 <p>
15969 The definition of bind1st() (D.8 [depr.lib.binders]) can result in
15970 the construction of an unsafe binding between incompatible pointer
15971 types. For example, given a function whose first parameter type is
15972 'pointer to T', it's possible without error to bind an argument of
15973 type 'pointer to U' when U does not derive from T:
15974 </p>
15975 <pre>   foo(T*, int);
15976
15977    struct T {};
15978    struct U {};
15979
15980    U u;
15981
15982    int* p;
15983    int* q;
15984
15985    for_each(p, q, bind1st(ptr_fun(foo), &amp;u));    // unsafe binding
15986 </pre>
15987
15988 <p>
15989 The definition of bind1st() includes a functional-style conversion to
15990 map its argument to the expected argument type of the bound function
15991 (see below):
15992 </p>
15993 <pre>  typename Operation::first_argument_type(x)
15994 </pre>
15995
15996 <p>A functional-style conversion (D.8 [depr.lib.binders]) is defined to
15997 be
15998 semantically equivalent to an explicit cast expression (D.8
15999 [depr.lib.binders]), which may (according to 5.4, paragraph 5) be
16000 interpreted
16001 as a reinterpret_cast, thus masking the error.
16002 </p>
16003
16004 <p>The problem and proposed change also apply to D.8 [depr.lib.binders].</p>
16005
16006
16007 <p><b>Proposed resolution:</b></p>
16008 <p>Add this sentence to the end of D.8 [depr.lib.binders]/1:
16009   "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in
16010   favor of <tt>std::tr1::bind</tt>."</p>
16011
16012 <p>(Notes to editor: (1) when and if tr1::bind is incorporated into
16013   the standard, "std::tr1::bind" should be changed to "std::bind". (2)
16014   20.5.6 should probably be moved to Annex D.</p>
16015
16016
16017 <p><b>Rationale:</b></p>
16018 <p>There is no point in fixing bind1st and bind2nd.  tr1::bind is a
16019   superior solution.  It solves this problem and others.</p>
16020
16021
16022
16023
16024
16025 <hr>
16026 <h3><a name="363"></a>363. Missing exception specification in 27.4.2.1.1</h3>
16027 <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>
16028  <b>Submitter:</b> Walter Brown and Marc Paterno <b>Date:</b> 2002-05-20</p>
16029 <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>
16030 <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>
16031 <p><b>Discussion:</b></p>
16032 <p>
16033 The destructor of ios_base::failure should have an empty throw
16034 specification, because the destructor of its base class, exception, is
16035 declared in this way.
16036 </p>
16037
16038
16039 <p><b>Proposed resolution:</b></p>
16040 <p>Change the destructor to</p>
16041 <pre>  virtual ~failure() throw();
16042 </pre>
16043
16044
16045 <p><b>Rationale:</b></p>
16046 <p>Fixes an obvious glitch.  This is almost editorial.</p>
16047
16048
16049
16050
16051
16052 <hr>
16053 <h3><a name="364"></a>364. Inconsistent wording in 27.5.2.4.2</h3>
16054 <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>
16055  <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 2002-05-10</p>
16056 <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>
16057 <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>
16058 <p><b>Discussion:</b></p>
16059 <p>
16060 27.5.2.4.2 [streambuf.virt.buffer] paragraph 1 is inconsistent with the Effects
16061 clause for seekoff.
16062 </p>
16063
16064
16065 <p><b>Proposed resolution:</b></p>
16066 <p>
16067 Make this paragraph, the Effects clause for setbuf, consistent in wording
16068 with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
16069 to indicate the purpose of setbuf:
16070 </p>
16071
16072 <p>Original text:</p>
16073
16074 <blockquote><p>
16075 1 Effects: Performs an operation that is defined separately for each
16076 class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
16077 </p></blockquote>
16078
16079 <p>Proposed text:</p>
16080
16081 <blockquote><p>
16082 1 Effects: Influences stream buffering in a way that is defined separately
16083 for each class derived from basic_streambuf in this clause
16084 (27.7.1.3, 27.8.1.4).
16085 </p></blockquote>
16086
16087
16088
16089 <p><b>Rationale:</b></p>
16090 <p>The LWG doesn't believe there is any normative difference between
16091   the existing wording and what's in the proposed resolution, but the
16092   change may make the intent clearer.</p>
16093
16094
16095
16096
16097
16098 <hr>
16099 <h3><a name="365"></a>365. Lack of const-qualification in clause 27</h3>
16100 <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>
16101  <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 2002-05-10</p>
16102 <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>
16103 <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>
16104 <p><b>Discussion:</b></p>
16105 <p>
16106 Some stream and streambuf member functions are declared non-const,
16107 even thought they appear only to report information rather than to
16108 change an object's logical state.  They should be declared const.  See
16109 document N1360 for details and rationale.
16110 </p>
16111
16112 <p>The list of member functions under discussion: <tt>in_avail</tt>,
16113 <tt>showmanyc</tt>, <tt>tellg</tt>, <tt>tellp</tt>, <tt>is_open</tt>.</p>
16114
16115 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a></p>
16116
16117
16118
16119 <p><b>Proposed resolution:</b></p>
16120 <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>
16121 <p>Replace</p>
16122 <pre>  bool is_open();
16123 </pre>
16124 <p>with</p>
16125 <pre>  bool is_open() const;
16126 </pre>
16127
16128
16129 <p><b>Rationale:</b></p>
16130 <p>Of the changes proposed in N1360, the only one that is safe is
16131 changing the filestreams' is_open to const.  The LWG believed that
16132 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
16133 member function, after all,is already const.</p>
16134
16135 <p>The other proposed changes are less safe, because some streambuf
16136 functions that appear merely to report a value do actually perform
16137 mutating operations.  It's not even clear that they should be
16138 considered "logically const", because streambuf has two interfaces, a
16139 public one and a protected one.  These functions may, and often do,
16140 change the state as exposed by the protected interface, even if the
16141 state exposed by the public interface is unchanged.</p>
16142
16143 <p>Note that implementers can make this change in a binary compatible
16144 way by providing both overloads; this would be a conforming extension.</p>
16145
16146
16147
16148
16149
16150
16151 <hr>
16152 <h3><a name="369"></a>369. io stream objects and static ctors</h3>
16153 <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>
16154  <b>Submitter:</b> Ruslan Abdikeev <b>Date:</b> 2002-07-08</p>
16155 <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>
16156 <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>
16157 <p><b>Discussion:</b></p>
16158 <p>
16159 Is it safe to use standard iostream objects from constructors of
16160 static objects?  Are standard iostream objects constructed and are
16161 their associations established at that time?
16162 </p>
16163
16164 <p>Surpisingly enough, Standard does NOT require that.</p>
16165
16166 <p>
16167 27.3/2 [lib.iostream.objects] guarantees that standard iostream
16168 objects are constructed and their associations are established before
16169 the body of main() begins execution.  It also refers to ios_base::Init
16170 class as the panacea for constructors of static objects.
16171 </p>
16172
16173 <p>
16174 However, there's nothing in 27.3 [lib.iostream.objects],
16175 in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
16176 that would require implementations to allow access to standard
16177 iostream objects from constructors of static objects.
16178 </p>
16179
16180 <p>Details:</p>
16181
16182 <p>Core text refers to some magic object ios_base::Init, which will
16183 be discussed below:</p>
16184
16185 <blockquote><p>
16186     "The [standard iostream] objects are constructed, and their
16187     associations are established at some time prior to or during
16188     first time an object of class basic_ios&lt;charT,traits&gt;::Init
16189     is constructed, and in any case before the body of main
16190     begins execution." (27.3/2 [lib.iostream.objects])
16191 </p></blockquote>
16192
16193 <p>
16194 The first <i>non-normative</i> footnote encourages implementations
16195 to initialize standard iostream objects earlier than required.
16196 </p>
16197
16198 <p>However, the second <i>non-normative</i> footnote makes an explicit
16199 and unsupported claim:</p>
16200
16201 <blockquote><p>
16202   "Constructors and destructors for static objects can access these
16203   [standard iostream] objects to read input from stdin or write output
16204   to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects])
16205 </p></blockquote>
16206
16207 <p>
16208 The only bit of magic is related to that ios_base::Init class.  AFAIK,
16209 the rationale behind ios_base::Init was to bring an instance of this
16210 class to each translation unit which #included &lt;iostream&gt; or
16211 related header.  Such an inclusion would support the claim of footnote
16212 quoted above, because in order to use some standard iostream object it
16213 is necessary to #include &lt;iostream&gt;.
16214 </p>
16215
16216 <p>
16217 However, while Standard explicitly describes ios_base::Init as
16218 an appropriate class for doing the trick, I failed to found a
16219 mention of an _instance_ of ios_base::Init in Standard.
16220 </p>
16221
16222
16223 <p><b>Proposed resolution:</b></p>
16224
16225 <p>Add to 27.3 [iostream.objects], p2, immediately before the last sentence
16226 of the paragraph, the following two sentences:</p>
16227
16228 <blockquote><p>
16229 If a translation unit includes &lt;iostream&gt;, or explicitly
16230 constructs an ios_base::Init object, these stream objects shall
16231 be constructed before dynamic initialization of non-local
16232 objects defined later in that translation unit, and these stream
16233 objects shall be destroyed after the destruction of dynamically
16234 initialized non-local objects defined later in that translation unit.
16235 </p></blockquote>
16236
16237 <p><i>[Lillehammer: Matt provided wording.]</i></p>
16238
16239 <p><i>[Mont Tremblant: Matt provided revised wording.]</i></p>
16240
16241
16242
16243 <p><b>Rationale:</b></p>
16244 <p>
16245 The original proposed resolution unconditionally required
16246 implementations to define an ios_base::Init object of some
16247 implementation-defined name in the header &lt;iostream&gt;. That's an
16248 overspecification. First, defining the object may be unnecessary
16249 and even detrimental to performance if an implementation can
16250 guarantee that the 8 standard iostream objects will be initialized
16251 before any other user-defined object in a program. Second, there
16252 is no need to require implementations to document the name of the
16253 object.</p>
16254
16255 <p>
16256 The new proposed resolution gives users guidance on what they need to
16257 do to ensure that stream objects are constructed during startup.</p>
16258
16259
16260
16261
16262
16263 <hr>
16264 <h3><a name="370"></a>370. Minor error in basic_istream::get</h3>
16265 <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>
16266  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-07-15</p>
16267 <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>
16268 <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>
16269 <p><b>Discussion:</b></p>
16270 <p>Defect report for description of basic_istream::get (section
16271 27.6.1.3 [istream.unformatted]), paragraph 15. The description for the
16272 get function
16273 with the following signature:</p>
16274
16275 <pre>  basic_istream&lt;charT,traits&gt;&amp; get(basic_streambuf&lt;char_type,traits&gt;&amp;
16276   sb);
16277 </pre>
16278
16279 <p>is incorrect. It reads</p>
16280
16281 <blockquote><p>
16282   Effects: Calls get(s,n,widen('\n'))
16283 </p></blockquote>
16284
16285 <p>which I believe should be:</p>
16286
16287 <blockquote><p>
16288   Effects: Calls get(sb,widen('\n'))
16289 </p></blockquote>
16290
16291
16292 <p><b>Proposed resolution:</b></p>
16293 <p>Change the <b>Effects</b> paragraph to:</p>
16294 <blockquote><p>
16295   Effects: Calls get(sb,this-&gt;widen('\n'))
16296 </p></blockquote>
16297
16298 <p><i>[Pre-Oxford: Minor correction from Howard: replaced 'widen'
16299       with 'this-&gt;widen'.]</i></p>
16300
16301
16302
16303
16304 <p><b>Rationale:</b></p><p>Fixes an obvious typo.</p>
16305
16306
16307
16308
16309 <hr>
16310 <h3><a name="371"></a>371. Stability of multiset and multimap member functions</h3>
16311 <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>
16312  <b>Submitter:</b> Frank Compagner <b>Date:</b> 2002-07-20</p>
16313 <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>
16314 <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>
16315 <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>
16316 <p><b>Discussion:</b></p>
16317 <p>
16318 The requirements for multiset and multimap containers (23.1
16319 [lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
16320 23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
16321 the stability of the required (mutating) member functions. It appears
16322 the standard allows these functions to reorder equivalent elements of
16323 the container at will, yet the pervasive red-black tree implementation
16324 appears to provide stable behaviour.
16325 </p>
16326
16327 <p>This is of most concern when considering the behaviour of erase().
16328 A stability requirement would guarantee the correct working of the
16329 following 'idiom' that removes elements based on a certain predicate
16330 function.
16331 </p>
16332
16333 <pre>  multimap&lt;int, int&gt; m;
16334   multimap&lt;int, int&gt;::iterator i = m.begin();
16335   while (i != m.end()) {
16336       if (pred(i))
16337           m.erase (i++);
16338       else
16339           ++i;
16340   }
16341 </pre>
16342
16343 <p>
16344 Although clause 23.1.2/8 guarantees that i remains a valid iterator
16345 througout this loop, absence of the stability requirement could
16346 potentially result in elements being skipped. This would make
16347 this code incorrect, and, furthermore, means that there is no way
16348 of erasing these elements without iterating first over the entire
16349 container, and second over the elements to be erased. This would
16350 be unfortunate, and have a negative impact on both performance and
16351 code simplicity.
16352 </p>
16353
16354 <p>
16355 If the stability requirement is intended, it should be made explicit
16356 (probably through an extra paragraph in clause 23.1.2).
16357 </p>
16358 <p>
16359 If it turns out stability cannot be guaranteed, i'd argue that a
16360 remark or footnote is called for (also somewhere in clause 23.1.2) to
16361 warn against relying on stable behaviour (as demonstrated by the code
16362 above).  If most implementations will display stable behaviour, any
16363 problems emerging on an implementation without stable behaviour will
16364 be hard to track down by users. This would also make the need for an
16365 erase_if() member function that much greater.
16366 </p>
16367
16368 <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>
16369
16370
16371
16372 <p><b>Proposed resolution:</b></p>
16373
16374 <p>Add the following to the end of 23.1.2 [associative.reqmts] paragraph 4:
16375 "For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt>
16376   are <i>stable</i>: they preserve the relative ordering of equivalent
16377   elements.</p>
16378
16379 <p><i>[Lillehammer: Matt provided wording]</i></p>
16380
16381 <p><i>[Joe Gottman points out that the provided wording does not address
16382 multimap and multiset.  N1780 also addresses this issue and suggests
16383 wording.]</i></p>
16384
16385
16386 <p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p>
16387
16388
16389
16390
16391 <p><b>Rationale:</b></p>
16392 <p>The LWG agrees that this guarantee is necessary for common user
16393   idioms to work, and that all existing implementations provide this
16394   property.  Note that this resolution guarantees stability for
16395   multimap and multiset, not for all associative containers in
16396   general.</p>
16397
16398
16399
16400
16401
16402
16403 <hr>
16404 <h3><a name="373"></a>373. Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</h3>
16405 <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>
16406  <b>Submitter:</b> Keith Baker <b>Date:</b> 2002-07-23</p>
16407 <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>
16408 <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>
16409 <p><b>Discussion:</b></p>
16410
16411 <p>
16412 In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmts]
16413 (exception()&amp;badbit) != 0 is used in testing for rethrow, yet
16414 exception() is the constructor to class std::exception in 18.6.1 [type.info] that has no return type. Should member function
16415 exceptions() found in 27.4.4 [ios] be used instead?
16416 </p>
16417
16418
16419
16420 <p><b>Proposed resolution:</b></p>
16421 <p>
16422 In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmts], change
16423 "(exception()&amp;badbit) != 0" to "(exceptions()&amp;badbit) != 0".
16424 </p>
16425
16426
16427 <p><b>Rationale:</b></p>
16428 <p>Fixes an obvious typo.</p>
16429
16430
16431
16432
16433
16434 <hr>
16435 <h3><a name="375"></a>375. basic_ios should be ios_base in 27.7.1.3</h3>
16436 <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>
16437  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-14</p>
16438 <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>
16439 <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>
16440 <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>
16441 <p><b>Discussion:</b></p>
16442 <p>
16443 In Section 27.7.1.4 [stringbuf.virtuals]: Table 90, Table 91, and paragraph
16444 14 all contain references to "basic_ios::" which should be
16445 "ios_base::".
16446 </p>
16447
16448
16449 <p><b>Proposed resolution:</b></p>
16450 <p>
16451 Change all references to "basic_ios" in Table 90, Table 91, and
16452 paragraph 14 to "ios_base".
16453 </p>
16454
16455
16456 <p><b>Rationale:</b></p><p>Fixes an obvious typo.</p>
16457
16458
16459
16460
16461 <hr>
16462 <h3><a name="376"></a>376. basic_streambuf semantics</h3>
16463 <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>
16464  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-14</p>
16465 <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>
16466 <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>
16467 <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>
16468 <p><b>Discussion:</b></p>
16469 <p>
16470 In Section 27.7.1.4 [stringbuf.virtuals], Table 90, the implication is that
16471 the four conditions should be mutually exclusive, but they are not.
16472 The first two cases, as written, are subcases of the third.</p>
16473
16474 <p>
16475 As written, it is unclear what should be the result if cases 1 and 2
16476 are both true, but case 3 is false.
16477 </p>
16478
16479
16480
16481 <p><b>Proposed resolution:</b></p>
16482
16483 <p>Rewrite these conditions as:</p>
16484 <blockquote>
16485 <p>
16486   (which &amp; (ios_base::in|ios_base::out)) == ios_base::in
16487 </p>
16488
16489 <p>
16490   (which &amp; (ios_base::in|ios_base::out)) == ios_base::out
16491 </p>
16492
16493 <p>
16494   (which &amp; (ios_base::in|ios_base::out)) ==
16495 (ios_base::in|ios_base::out)
16496    and way == either ios_base::beg or ios_base::end
16497 </p>
16498
16499 <p>Otherwise</p>
16500 </blockquote>
16501
16502
16503
16504 <p><b>Rationale:</b></p>
16505 <p>It's clear what we wanted to say, we just failed to say it.  This
16506   fixes it.</p>
16507
16508
16509
16510
16511
16512 <hr>
16513 <h3><a name="379"></a>379. nonsensical ctype::do_widen() requirement</h3>
16514 <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>
16515  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p>
16516 <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>
16517 <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>
16518 <p><b>Discussion:</b></p>
16519 <p>
16520 The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
16521 </p>
16522 <pre>  charT do_widen (char c) const;
16523
16524   -11- Effects: Applies the simplest reasonable transformation from
16525        a char value or sequence of char values to the corresponding
16526        charT value or values. The only characters for which unique
16527        transformations are required are those in the basic source
16528        character set (2.2). For any named ctype category with a
16529        ctype&lt;charT&gt; facet ctw and valid ctype_base::mask value
16530        M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
16531 </pre>
16532 <p>
16533 Shouldn't the last sentence instead read
16534 </p>
16535 <pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
16536        and valid ctype_base::mask value M
16537        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
16538 </pre>
16539 <p>
16540 I.e., if the narrow character c is not a member of a class of
16541 characters then neither is the widened form of c. (To paraphrase
16542 footnote 224.)
16543 </p>
16544
16545
16546 <p><b>Proposed resolution:</b></p>
16547 <p>
16548 Replace the last sentence of 22.2.1.1.2 [locale.ctype.virtuals], p11 with the
16549 following text:
16550 </p>
16551 <pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
16552        and valid ctype_base::mask value M,
16553        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
16554 </pre>
16555
16556 <p><i>[Kona: Minor edit. Added a comma after the <i>M</i> for clarity.]</i></p>
16557
16558
16559
16560
16561 <p><b>Rationale:</b></p>
16562 <p>The LWG believes this is just a typo, and that this is the correct fix.</p>
16563
16564
16565
16566
16567
16568 <hr>
16569 <h3><a name="380"></a>380. typos in codecvt tables 53 and 54</h3>
16570 <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>
16571  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p>
16572 <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>
16573 <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>
16574 <p><b>Discussion:</b></p>
16575 <p>
16576 Tables 53 and 54 in 22.2.1.5 [locale.codecvt.byname] are both titled "convert
16577 result values," when surely "do_in/do_out result values" must have
16578 been intended for Table 53 and "do_unshift result values" for Table
16579 54.
16580 </p>
16581 <p>
16582 Table 54, row 3 says that the meaning of partial is "more characters
16583 needed to be supplied to complete termination." The function is not
16584 supplied any characters, it is given a buffer which it fills with
16585 characters or, more precisely, destination elements (i.e., an escape
16586 sequence). So partial means that space for more than (to_limit - to)
16587 destination elements was needed to terminate a sequence given the
16588 value of state.
16589 </p>
16590
16591
16592 <p><b>Proposed resolution:</b></p>
16593 <p>
16594 Change the title of Table 53 to "do_in/do_out result values" and
16595 the title of Table 54 to "do_unshift result values."
16596 </p>
16597 <p>
16598 Change the text in Table 54, row 3 (the <b>partial</b> row), under the
16599 heading Meaning, to "space for more than (to_limit - to) destination
16600 elements was needed to terminate a sequence given the value of state."
16601 </p>
16602
16603
16604
16605
16606 <hr>
16607 <h3><a name="381"></a>381. detection of invalid mbstate_t in codecvt</h3>
16608 <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>
16609  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p>
16610 <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>
16611 <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>
16612 <p><b>Discussion:</b></p>
16613 <p>
16614 All but one codecvt member functions that take a state_type argument
16615 list as one of their preconditions that the state_type argument have
16616 a valid value. However, according to 22.2.1.5.2, p6,
16617 codecvt::do_unshift() is the only codecvt member that is supposed to
16618 return error if the state_type object is invalid.
16619 </p>
16620
16621 <p>
16622 It seems to me that the treatment of state_type by all codecvt member
16623 functions should be the same and the current requirements should be
16624 changed. Since the detection of invalid state_type values may be
16625 difficult in general or computationally expensive in some specific
16626 cases, I propose the following:
16627 </p>
16628
16629
16630 <p><b>Proposed resolution:</b></p>
16631 <p>
16632 Add a new paragraph before 22.2.1.5.2, p5, and after the function
16633 declaration below
16634 </p>
16635 <pre>    result do_unshift(stateT&amp; state,
16636     externT* to, externT* to_limit, externT*&amp; to_next) const;
16637 </pre>
16638 <p>
16639 as follows:
16640 </p>
16641 <pre>    Requires: (to &lt;= to_end) well defined and true; state initialized,
16642     if at the beginning of a sequence, or else equal to the result of
16643     converting the preceding characters in the sequence.
16644 </pre>
16645 <p>
16646 and change the text in Table 54, row 4, the <b>error</b> row, under
16647 the heading Meaning, from
16648 </p>
16649 <pre>    state has invalid value
16650 </pre>
16651 <p>
16652 to
16653 </p>
16654 <pre>    an unspecified error has occurred
16655 </pre>
16656
16657
16658 <p><b>Rationale:</b></p>
16659 <p>The intent is that implementations should not be required to detect
16660 invalid state values; such a requirement appears nowhere else.  An
16661 invalid state value is a precondition violation, <i>i.e.</i> undefined
16662 behavior.  Implementations that do choose to detect invalid state
16663 values, or that choose to detect any other kind of error, may return
16664 <b>error</b> as an indication.</p>
16665
16666
16667
16668
16669
16670 <hr>
16671 <h3><a name="383"></a>383. Bidirectional iterator assertion typo</h3>
16672 <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>
16673  <b>Submitter:</b> ysapir (submitted via comp.std.c++) <b>Date:</b> 2002-10-17</p>
16674 <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>
16675 <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>
16676 <p><b>Discussion:</b></p>
16677 <p>
16678 Following a discussion on the boost list regarding end iterators and
16679 the possibility of performing operator--() on them, it seems to me
16680 that there is a typo in the standard.  This typo has nothing to do
16681 with that discussion.
16682 </p>
16683
16684 <p>
16685 I have checked this newsgroup, as well as attempted a search of the
16686 Active/Defect/Closed Issues List on the site for the words "s is
16687 derefer" so I believe this has not been proposed before.  Furthermore,
16688 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
16689 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.
16690 </p>
16691
16692 <p>
16693 The standard makes the following assertion on bidirectional iterators,
16694 in section 24.1.4 [lib.bidirectional.iterators], Table 75:
16695 </p>
16696
16697 <pre>                         operational  assertion/note
16698 expression  return type   semantics    pre/post-condition
16699
16700 --r          X&amp;                        pre: there exists s such
16701                                        that r == ++s.
16702                                        post: s is dereferenceable.
16703                                        --(++r) == r.
16704                                        --r == --s implies r == s.
16705                                        &amp;r == &amp;--r.
16706 </pre>
16707
16708 <p>
16709 (See <a href="http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763">http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763</a>.)
16710 </p>
16711
16712 <p>
16713 In particular, "s is dereferenceable" seems to be in error.  It seems
16714 that the intention was to say "r is dereferenceable".
16715 </p>
16716
16717 <p>
16718 If it were to say "r is dereferenceable" it would
16719 make perfect sense.  Since s must be dereferenceable prior to
16720 operator++, then the natural result of operator-- (to undo operator++)
16721 would be to make r dereferenceable.  Furthermore, without other
16722 assertions, and basing only on precondition and postconditions, we
16723 could not otherwise know this.  So it is also interesting information.
16724 </p>
16725
16726
16727
16728 <p><b>Proposed resolution:</b></p>
16729 <p>
16730 Change the guarantee to "postcondition: r is dereferenceable."
16731 </p>
16732
16733
16734 <p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
16735
16736
16737
16738
16739 <hr>
16740 <h3><a name="384"></a>384. equal_range has unimplementable runtime complexity</h3>
16741 <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>
16742  <b>Submitter:</b> Hans Bos <b>Date:</b> 2002-10-18</p>
16743 <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>
16744 <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>
16745 <p><b>Discussion:</b></p>
16746 <p>
16747 Section 25.3.3.3 [equal.range]
16748 states that at most 2 * log(last - first) + 1
16749 comparisons are allowed for equal_range.
16750 </p>
16751
16752 <p>It is not possible to implement equal_range with these constraints.</p>
16753
16754 <p>In a range of one element as in:</p>
16755 <pre>    int x = 1;
16756     equal_range(&amp;x, &amp;x + 1, 1)
16757 </pre>
16758
16759 <p>it is easy to see that at least 2 comparison operations are needed.</p>
16760
16761 <p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p>
16762
16763 <p>I have checked a few libraries and they all use the same (nonconforming)
16764 algorithm for equal_range that has a complexity of</p>
16765 <pre>     2* log(distance(first, last)) + 2.
16766 </pre>
16767 <p>I guess this is the algorithm that the standard assumes for equal_range.</p>
16768
16769 <p>
16770 It is easy to see that 2 * log(distance) + 2 comparisons are enough
16771 since equal range can be implemented with lower_bound and upper_bound
16772 (both log(distance) + 1).
16773 </p>
16774
16775 <p>
16776 I think it is better to require something like 2log(distance) + O(1)  (or
16777 even logarithmic as multiset::equal_range).
16778 Then an implementation has more room to optimize for certain cases (e.g.
16779 have log(distance) characteristics when at most match is found in the range
16780 but 2log(distance) + 4 for the worst case).
16781 </p>
16782
16783
16784
16785 <p><b>Proposed resolution:</b></p>
16786 <p>In 25.3.3.1 [lower.bound]/4, change <tt>log(last - first) + 1</tt>
16787 to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
16788
16789 <p>In 25.3.3.2 [upper.bound]/4, change <tt>log(last - first) + 1</tt>
16790 to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
16791
16792 <p>In 25.3.3.3 [equal.range]/4, change <tt>2*log(last - first) + 1</tt>
16793 to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
16794
16795 <p><i>[Matt provided wording]</i></p>
16796
16797
16798
16799 <p><b>Rationale:</b></p>
16800 <p>The LWG considered just saying <i>O</i>(log n) for all three, but
16801   decided that threw away too much valuable information.  The fact
16802   that lower_bound is twice as fast as equal_range is important.
16803   However, it's better to allow an arbitrary additive constant than to
16804   specify an exact count.  An exact count would have to
16805   involve <tt>floor</tt> or <tt>ceil</tt>.  It would be too easy to
16806   get this wrong, and don't provide any substantial value for users.</p>
16807
16808
16809
16810
16811 <hr>
16812 <h3><a name="386"></a>386. Reverse iterator's operator[] has impossible return type</h3>
16813 <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>
16814  <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-10-23</p>
16815 <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>
16816 <p><b>Discussion:</b></p>
16817 <p>In 24.4.1.3.11 [reverse.iter.op-=], <tt>reverse_iterator&lt;&gt;::operator[]</tt>
16818 is specified as having a return type of <tt>reverse_iterator::reference</tt>,
16819 which is the same as <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.
16820 (Where <tt>Iterator</tt> is the underlying iterator type.)</p>
16821
16822 <p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't
16823   necessarily have a return type
16824   of <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.   Its
16825   return type is merely required to be convertible
16826   to <tt>Iterator</tt>'s value type.  The return type specified for
16827   reverse_iterator's operator[] would thus appear to be impossible.</p>
16828
16829 <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
16830   <tt>a[n]</tt> will continue to be required (for random access
16831   iterators) to be convertible to the value type, and also <tt>a[n] =
16832   t</tt> will be a valid expression.  Implementations of
16833   <tt>reverse_iterator</tt> will likely need to return a proxy from
16834   <tt>operator[]</tt> to meet these requirements. As mentioned in the
16835   comment from Dave Abrahams, the simplest way to specify that
16836   <tt>reverse_iterator</tt> meet this requirement to just mandate
16837   it and leave the return type of <tt>operator[]</tt> unspecified.</p>
16838
16839
16840
16841 <p><b>Proposed resolution:</b></p>
16842
16843 <p>In 24.4.1.2 [reverse.iter.requirements] change:</p>
16844
16845 <blockquote>
16846 <pre>reference operator[](difference_type n) const;
16847 </pre>
16848 </blockquote>
16849
16850 <p>to:</p>
16851
16852 <blockquote>
16853 <pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see 24.1.5 [random.access.iterators]
16854 </pre>
16855 </blockquote>
16856
16857
16858
16859
16860 <p><i>[
16861 Comments from Dave Abrahams: IMO we should resolve 386 by just saying
16862     that the return type of reverse_iterator's operator[] is
16863     unspecified, allowing the random access iterator requirements to
16864     impose an appropriate return type.  If we accept 299's proposed
16865     resolution (and I think we should), the return type will be
16866     readable and writable, which is about as good as we can do.
16867 ]</i></p>
16868
16869
16870
16871
16872
16873
16874 <hr>
16875 <h3><a name="389"></a>389. Const overload of valarray::operator[] returns by value</h3>
16876 <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>
16877  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
16878 <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>
16879 <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>
16880 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a></p>
16881 <p><b>Discussion:</b></p>
16882 <p>Consider the following program:</p>
16883 <pre>    #include &lt;iostream&gt;
16884     #include &lt;ostream&gt;
16885     #include &lt;vector&gt;
16886     #include &lt;valarray&gt;
16887     #include &lt;algorithm&gt;
16888     #include &lt;iterator&gt;
16889     template&lt;typename Array&gt;
16890     void print(const Array&amp; a)
16891     {
16892     using namespace std;
16893     typedef typename Array::value_type T;
16894     copy(&amp;a[0], &amp;a[0] + a.size(),
16895     ostream_iterator&lt;T&gt;(std::cout, " "));
16896     }
16897     template&lt;typename T, unsigned N&gt;
16898     unsigned size(T(&amp;)[N]) { return N; }
16899     int main()
16900     {
16901     double array[] = { 0.89, 9.3, 7, 6.23 };
16902     std::vector&lt;double&gt; v(array, array + size(array));
16903     std::valarray&lt;double&gt; w(array, size(array));
16904     print(v); // #1
16905     std::cout &lt;&lt; std::endl;
16906     print(w); // #2
16907     std::cout &lt;&lt; std::endl;
16908     }
16909 </pre>
16910
16911 <p>While the call numbered #1 succeeds, the call numbered #2 fails
16912 because the const version of the member function
16913 valarray&lt;T&gt;::operator[](size_t) returns a value instead of a
16914 const-reference. That seems to be so for no apparent reason, no
16915 benefit. Not only does that defeats users' expectation but it also
16916 does hinder existing software (written either in C or Fortran)
16917 integration within programs written in C++.  There is no reason why
16918 subscripting an expression of type valarray&lt;T&gt; that is const-qualified
16919 should not return a const T&amp;.</p>
16920
16921
16922 <p><b>Proposed resolution:</b></p>
16923 <p>In the class synopsis in 26.5.2 [template.valarray], and in
16924 26.5.2.3 [valarray.access] just above paragraph 1, change</p>
16925 <pre>  T operator[](size_t const);
16926 </pre>
16927 <p>to</p>
16928 <pre>  const T&amp; operator[](size_t const);
16929 </pre>
16930
16931 <p><i>[Kona: fixed a minor typo: put semicolon at the end of the line
16932   wehre it belongs.]</i></p>
16933
16934
16935
16936
16937 <p><b>Rationale:</b></p>
16938 <p>Return by value seems to serve no purpose.  Valaray was explicitly
16939 designed to have a specified layout so that it could easily be
16940 integrated with libraries in other languages, and return by value
16941 defeats that purpose.  It is believed that this change will have no
16942 impact on allowable optimizations.</p>
16943
16944
16945
16946
16947
16948 <hr>
16949 <h3><a name="391"></a>391. non-member functions specified as const</h3>
16950 <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>
16951  <b>Submitter:</b> James Kanze <b>Date:</b> 2002-12-10</p>
16952 <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>
16953 <p><b>Discussion:</b></p>
16954 <p>
16955 The specifications of toupper and tolower both specify the functions as
16956 const, althought they are not member functions, and are not specified as
16957 const in the header file synopsis in section 22.1 [locales].
16958 </p>
16959
16960
16961 <p><b>Proposed resolution:</b></p>
16962 <p>In 22.1.3.2 [conversions], remove <tt>const</tt> from the function
16963   declarations of std::toupper and std::tolower</p>
16964
16965
16966 <p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
16967
16968
16969
16970
16971 <hr>
16972 <h3><a name="395"></a>395. inconsistencies in the definitions of rand() and random_shuffle()</h3>
16973 <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>
16974  <b>Submitter:</b> James Kanze <b>Date:</b> 2003-01-03</p>
16975 <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>
16976 <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>
16977 <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>
16978 <p><b>Discussion:</b></p>
16979 <p>
16980 In 26.7 [c.math], the C++ standard refers to the C standard for the
16981 definition of rand(); in the C standard, it is written that "The
16982 implementation shall behave as if no library function calls the rand
16983 function."
16984 </p>
16985
16986 <p>
16987 In 25.2.12 [alg.random.shuffle], there is no specification as to
16988 how the two parameter version of the function generates its random
16989 value.  I believe that all current implementations in fact call rand()
16990 (in contradiction with the requirement avove); if an implementation does
16991 not call rand(), there is the question of how whatever random generator
16992 it does use is seeded.  Something is missing.
16993 </p>
16994
16995
16996
16997 <p><b>Proposed resolution:</b></p>
16998 <p>
16999 In [lib.c.math], add a paragraph specifying that the C definition of
17000 rand shal be modified to say that "Unless otherwise specified, the
17001 implementation shall behave as if no library function calls the rand
17002 function."
17003 </p>
17004
17005 <p>
17006 In [lib.alg.random.shuffle], add a sentence to the effect that "In
17007 the two argument form of the function, the underlying source of
17008 random numbers is implementation defined. [Note: in particular, an
17009 implementation is permitted to use <tt>rand</tt>.]
17010 </p>
17011
17012
17013 <p><b>Rationale:</b></p>
17014 <p>The original proposed resolution proposed requiring the
17015   two-argument from of <tt>random_shuffle</tt> to
17016   use <tt>rand</tt>. We don't want to do that, because some existing
17017   implementations already use something else: gcc
17018   uses <tt>lrand48</tt>, for example.  Using <tt>rand</tt> presents a
17019   problem if the number of elements in the sequence is greater than
17020   RAND_MAX.</p>
17021
17022
17023
17024
17025
17026 <hr>
17027 <h3><a name="400"></a>400. redundant type cast in lib.allocator.members</h3>
17028 <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>
17029  <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
17030 <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>
17031 <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>
17032 <p><b>Discussion:</b></p>
17033 <p>
17034 20.6.1.1 [allocator.members] allocator members, contains
17035 the following 3 lines:
17036 </p>
17037
17038 <pre>  12 Returns: new((void *) p) T( val)
17039      void destroy(pointer p);
17040   13 Returns: ((T*) p)-&gt;~T()
17041 </pre>
17042
17043 <p>
17044 The type cast "(T*) p" in the last line is redundant cause
17045 we know that std::allocator&lt;T&gt;::pointer is a typedef for T*.
17046 </p>
17047
17048
17049 <p><b>Proposed resolution:</b></p>
17050 <p>
17051 Replace "((T*) p)" with "p".
17052 </p>
17053
17054
17055 <p><b>Rationale:</b></p><p>Just a typo, this is really editorial.</p>
17056
17057
17058
17059
17060 <hr>
17061 <h3><a name="401"></a>401.  incorrect type casts in table 32 in lib.allocator.requirements</h3>
17062 <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>
17063  <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
17064 <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>
17065 <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>
17066 <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>
17067 <p><b>Discussion:</b></p>
17068 <p>
17069 I think that in par2 of  [default.con.req] the last two
17070 lines of table 32 contain two incorrect type casts. The lines are ...
17071 </p>
17072
17073 <pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
17074   a.destroy(p)       Effect: ((T*)p)?-&gt;~T()
17075 </pre>
17076
17077 <p>
17078 .... with the prerequisits coming from the preceding two paragraphs, especially
17079 from table 31:
17080 </p>
17081
17082 <pre>  alloc&lt;T&gt;             a     ;// an allocator for T
17083   alloc&lt;T&gt;::pointer    p     ;// random access iterator
17084                               // (may be different from T*)
17085   alloc&lt;T&gt;::reference  r = *p;// T&amp;
17086   T const&amp;             t     ;
17087 </pre>
17088
17089 <p>
17090 For that two type casts ("(void*)p" and "(T*)p") to be well-formed
17091 this would require then conversions to T* and void* for all
17092 alloc&lt;T&gt;::pointer, so it would implicitely introduce extra
17093 requirements for alloc&lt;T&gt;::pointer, additionally to the only
17094 current requirement (being a random access iterator).
17095 </p>
17096
17097
17098 <p><b>Proposed resolution:</b></p>
17099
17100 <p>
17101 Accept proposed wording from
17102 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2436.pdf">N2436</a> part 1.
17103 </p>
17104
17105 <p>
17106 Note: Actually I would prefer to replace "((T*)p)?-&gt;dtor_name" with
17107 "p?-&gt;dtor_name", but AFAICS this is not possible cause of an omission
17108 in 13.5.6 [over.ref] (for which I have filed another DR on 29.11.2002).
17109 </p>
17110
17111 <p><i>[Kona: The LWG thinks this is somewhere on the border between
17112   Open and NAD.  The intend is clear: <tt>construct</tt> constructs an
17113   object at the location <i>p</i>.  It's reading too much into the
17114   description to think that literally calling <tt>new</tt> is
17115   required.  Tweaking this description is low priority until we can do
17116   a thorough review of allocators, and, in particular, allocators with
17117   non-default pointer types.]</i></p>
17118
17119
17120 <p><i>[
17121 Batavia:  Proposed resolution changed to less code and more description.
17122 ]</i></p>
17123
17124
17125 <p><i>[
17126 post Oxford:  This would be rendered NAD Editorial by acceptance of
17127 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
17128 ]</i></p>
17129
17130
17131 <p><i>[
17132 Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
17133 was subsequently split out into a separate paper N2436 for the purposes of voting.
17134 The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
17135 issue to Ready status to be voted into the WP at Kona.
17136 ]</i></p>
17137
17138
17139
17140
17141
17142
17143
17144 <hr>
17145 <h3><a name="402"></a>402. wrong new expression in [some_]allocator::construct</h3>
17146 <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>
17147  <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
17148 <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>
17149 <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>
17150 <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>
17151 <p><b>Discussion:</b></p>
17152 <p>
17153 This applies to the new expression that is contained in both par12 of
17154 20.6.1.1 [allocator.members] and in par2 (table 32) of  [default.con.req].
17155 I think this new expression is wrong, involving unintended side
17156 effects.
17157 </p>
17158
17159
17160 <p>20.6.1.1 [allocator.members]  contains the following 3 lines:</p>
17161
17162 <pre>  11 Returns: the largest value N for which the call allocate(N,0) might succeed.
17163      void construct(pointer p, const_reference val);
17164   12 Returns: new((void *) p) T( val)
17165 </pre>
17166
17167
17168 <p> [default.con.req] in table 32 has the following line:</p>
17169 <pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
17170 </pre>
17171
17172 <p>
17173 .... with the prerequisits coming from the preceding two paragraphs,
17174 especially from table 31:
17175 </p>
17176
17177 <pre>  alloc&lt;T&gt;             a     ;// an allocator for T
17178   alloc&lt;T&gt;::pointer    p     ;// random access iterator
17179                               // (may be different from T*)
17180   alloc&lt;T&gt;::reference  r = *p;// T&amp;
17181   T const&amp;             t     ;
17182 </pre>
17183
17184 <p>
17185 Cause of using "new" but not "::new", any existing "T::operator new"
17186 function will hide the global placement new function. When there is no
17187 "T::operator new" with adequate signature,
17188 every_alloc&lt;T&gt;::construct(..) is ill-formed, and most
17189 std::container&lt;T,every_alloc&lt;T&gt;&gt; use it; a workaround
17190 would be adding placement new and delete functions with adequate
17191 signature and semantic to class T, but class T might come from another
17192 party. Maybe even worse is the case when T has placement new and
17193 delete functions with adequate signature but with "unknown" semantic:
17194 I dont like to speculate about it, but whoever implements
17195 any_container&lt;T,any_alloc&gt; and wants to use construct(..)
17196 probably must think about it.
17197 </p>
17198
17199
17200 <p><b>Proposed resolution:</b></p>
17201 <p>
17202 Replace "new" with "::new" in both cases.
17203 </p>
17204
17205
17206
17207
17208
17209
17210
17211 <hr>
17212 <h3><a name="403"></a>403. basic_string::swap should not throw exceptions</h3>
17213 <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>
17214  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2003-03-25</p>
17215 <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>
17216 <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>
17217 <p><b>Discussion:</b></p>
17218
17219 <p>
17220 std::basic_string, 21.3 [basic.string] paragraph 2 says that
17221 basic_string "conforms to the requirements of a Sequence, as specified
17222 in (23.1.1)." The sequence requirements specified in (23.1.1) to not
17223 include any prohibition on swap members throwing exceptions.
17224 </p>
17225
17226 <p>
17227 Section 23.1 [container.requirements] paragraph 10 does limit conditions under
17228 which exceptions may be thrown, but applies only to "all container
17229 types defined in this clause" and so excludes basic_string::swap
17230 because it is defined elsewhere.
17231 </p>
17232
17233 <p>
17234 Eric Niebler points out that 21.3 [basic.string] paragraph 5 explicitly
17235 permits basic_string::swap to invalidates iterators, which is
17236 disallowed by 23.1 [container.requirements] paragraph 10. Thus the standard would
17237 be contradictory if it were read or extended to read as having
17238 basic_string meet 23.1 [container.requirements] paragraph 10 requirements.
17239 </p>
17240
17241 <p>
17242 Yet several LWG members have expressed the belief that the original
17243 intent was that basic_string::swap should not throw exceptions as
17244 specified by 23.1 [container.requirements] paragraph 10, and that the standard is
17245 unclear on this issue. The complexity of basic_string::swap is
17246 specified as "constant time", indicating the intent was to avoid
17247 copying (which could cause a bad_alloc or other exception). An
17248 important use of swap is to ensure that exceptions are not thrown in
17249 exception-safe code.
17250 </p>
17251
17252 <p>
17253 Note: There remains long standing concern over whether or not it is
17254 possible to reasonably meet the 23.1 [container.requirements] paragraph 10 swap
17255 requirements when allocators are unequal. The specification of
17256 basic_string::swap exception requirements is in no way intended to
17257 address, prejudice, or otherwise impact that concern.
17258 </p>
17259
17260
17261
17262
17263
17264
17265
17266 <p><b>Proposed resolution:</b></p>
17267 <p>
17268 In 21.3.6.8 [string::swap], add a throws clause:
17269 </p>
17270
17271 <p>
17272 Throws: Shall not throw exceptions.
17273 </p>
17274
17275
17276
17277
17278
17279 <hr>
17280 <h3><a name="404"></a>404. May a replacement allocation function be declared inline?</h3>
17281 <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>
17282  <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-04-24</p>
17283 <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>
17284 <p><b>Discussion:</b></p>
17285 <p>
17286 The eight basic dynamic memory allocation functions (single-object
17287 and array versions of ::operator new and ::operator delete, in the
17288 ordinary and nothrow forms) are replaceable.  A C++ program may
17289 provide an alternative definition for any of them, which will be used
17290 in preference to the implementation's definition.
17291 </p>
17292
17293 <p>
17294 Three different parts of the standard mention requirements on
17295 replacement functions: 17.4.3.4 [replacement.functions], 18.5.1.1 [new.delete.single]
17296 and 18.5.1.2 [new.delete.array], and 3.7.2 [basic.stc.auto].
17297 </p>
17298
17299 <p>None of these three places say whether a replacement function may
17300   be declared inline.  18.5.1.1 [new.delete.single] paragraph 2 specifies a
17301   signature for the replacement function, but that's not enough:
17302   the <tt>inline</tt> specifier is not part of a function's signature.
17303   One might also reason from 7.1.2 [dcl.fct.spec] paragraph 2, which
17304   requires that "an inline function shall be defined in every
17305   translation unit in which it is used," but this may not be quite
17306   specific enough either.  We should either explicitly allow or
17307   explicitly forbid inline replacement memory allocation
17308   functions.</p>
17309
17310
17311 <p><b>Proposed resolution:</b></p>
17312 <p>
17313 Add a new sentence to the end of 17.4.3.4 [replacement.functions] paragraph 3:
17314 "The program's definitions shall not be specified as <tt>inline</tt>.
17315 No diagnostic is required."
17316 </p>
17317
17318 <p><i>[Kona: added "no diagnostic is required"]</i></p>
17319
17320
17321
17322
17323 <p><b>Rationale:</b></p>
17324 <p>
17325 The fact that <tt>inline</tt> isn't mentioned appears to have been
17326 nothing more than an oversight.  Existing implementations do not
17327 permit inline functions as replacement memory allocation functions.
17328 Providing this functionality would be difficult in some cases, and is
17329 believed to be of limited value.
17330 </p>
17331
17332
17333
17334
17335
17336 <hr>
17337 <h3><a name="405"></a>405. qsort and POD</h3>
17338 <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>
17339  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2003-04-08</p>
17340 <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>
17341 <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>
17342 <p><b>Discussion:</b></p>
17343 <p>
17344 Section 25.4 [alg.c.library] describes bsearch and qsort, from the C
17345 standard library. Paragraph 4 does not list any restrictions on qsort,
17346 but it should limit the base parameter to point to POD.  Presumably,
17347 qsort sorts the array by copying bytes, which requires POD.
17348 </p>
17349
17350
17351 <p><b>Proposed resolution:</b></p>
17352 <p>
17353 In 25.4 [alg.c.library] paragraph 4, just after the declarations and
17354 before the nonnormative note, add these words: "both of which have the
17355 same behavior as the original declaration.  The behavior is undefined
17356 unless the objects in the array pointed to by <i>base</i> are of POD
17357 type."
17358 </p>
17359
17360 <p><i>[Something along these lines is clearly necessary.  Matt
17361   provided wording.]</i></p>
17362
17363
17364
17365
17366
17367
17368 <hr>
17369 <h3><a name="406"></a>406. vector::insert(s) exception safety</h3>
17370 <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>
17371  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2003-04-27</p>
17372 <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>
17373 <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>
17374 <p><b>Discussion:</b></p>
17375 <p>
17376 There is a possible defect in the standard: the standard text was
17377 never intended to prevent arbitrary ForwardIterators, whose operations
17378 may throw exceptions, from being passed, and it also wasn't intended
17379 to require a temporary buffer in the case where ForwardIterators were
17380 passed (and I think most implementations don't use one).  As is, the
17381 standard appears to impose requirements that aren't met by any
17382 existing implementation.
17383 </p>
17384
17385
17386 <p><b>Proposed resolution:</b></p>
17387 <p>Replace 23.2.5.4 [vector.modifiers] paragraph 1 with:</p>
17388 <blockquote><p>
17389   1- Notes: Causes reallocation if the new size is greater than the
17390   old capacity. If no reallocation happens, all the iterators and
17391   references before the insertion point remain valid. If an exception
17392   is thrown other than by the copy constructor or assignment operator
17393   of T or by any InputIterator operation there are no effects.
17394 </p></blockquote>
17395
17396 <p><i>[We probably need to say something similar for deque.]</i></p>
17397
17398
17399
17400
17401
17402
17403
17404 <hr>
17405 <h3><a name="407"></a>407. Can singular iterators be destroyed?</h3>
17406 <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>
17407  <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
17408 <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>
17409 <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>
17410 <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>
17411 <p><b>Discussion:</b></p>
17412 <p>
17413 Clause 24.1 [iterator.requirements], paragraph 5, says that the only expression
17414 that is defined for a singular iterator is "an assignment of a
17415 non-singular value to an iterator that holds a singular value".  This
17416 means that destroying a singular iterator (e.g. letting an automatic
17417 variable go out of scope) is technically undefined behavior.  This
17418 seems overly strict, and probably unintentional.
17419 </p>
17420
17421
17422 <p><b>Proposed resolution:</b></p>
17423 <p>
17424 Change the sentence in question to "... the only exceptions are
17425 destroying an iterator that holds a singular value, or the assignment
17426 of a non-singular value to an iterator that holds a singular value."
17427 </p>
17428
17429
17430
17431
17432
17433 <hr>
17434 <h3><a name="409"></a>409. Closing an fstream should clear error state</h3>
17435 <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>
17436  <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
17437 <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>
17438 <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>
17439 <p><b>Discussion:</b></p>
17440 <p>
17441 A strict reading of 27.8.1 [fstreams] shows that opening or
17442 closing a basic_[io]fstream does not affect the error bits.  This
17443 means, for example, that if you read through a file up to EOF, and
17444 then close the stream and reopen it at the beginning of the file,
17445 the EOF bit in the stream's error state is still set.  This is
17446 counterintuitive.
17447 </p>
17448 <p>
17449 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>,
17450 and put in a footnote to clarify that the strict reading was indeed
17451 correct.  We did that because we believed the standard was
17452 unambiguous and consistent, and that we should not make architectural
17453 changes in a TC.  Now that we're working on a new revision of the
17454 language, those considerations no longer apply.
17455 </p>
17456
17457
17458 <p><b>Proposed resolution:</b></p>
17459
17460 <p>Change 27.8.1.9 [ifstream.members], para. 3 from:</p>
17461
17462 <blockquote><p>
17463 Calls rdbuf()-&gt;open(s,mode|in). If that function returns a null
17464 pointer, calls setstate(failbit) (which may throw ios_base::failure
17465 [Footnote: (lib.iostate.flags)].
17466 </p></blockquote>
17467
17468 <p>to:</p>
17469
17470 <blockquote><p>Calls rdbuf()-&gt;open(s,mode|in). If that function
17471 returns a null pointer, calls setstate(failbit) (which may throw
17472 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
17473 </p></blockquote>
17474
17475 <p>Change 27.8.1.13 [ofstream.members], para. 3 from:</p>
17476
17477 <blockquote><p>Calls rdbuf()-&gt;open(s,mode|out). If that function
17478 returns a null pointer, calls setstate(failbit) (which may throw
17479 ios_base::failure [Footnote: (lib.iostate.flags)).
17480 </p></blockquote>
17481
17482 <p>to:</p>
17483
17484 <blockquote><p>Calls rdbuf()-&gt;open(s,mode|out). If that function
17485 returns a null pointer, calls setstate(failbit) (which may throw
17486 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
17487 </p></blockquote>
17488
17489 <p>Change 27.8.1.17 [fstream.members], para. 3 from:</p>
17490
17491 <blockquote><p>Calls rdbuf()-&gt;open(s,mode), If that function returns
17492 a null pointer, calls setstate(failbit), (which may throw
17493 ios_base::failure). (lib.iostate.flags) )
17494 </p></blockquote>
17495
17496 <p>to:</p>
17497
17498 <blockquote><p>Calls rdbuf()-&gt;open(s,mode), If that function returns
17499 a null pointer, calls setstate(failbit), (which may throw
17500 ios_base::failure). (lib.iostate.flags) ), else calls clear().
17501 </p></blockquote>
17502
17503
17504
17505 <p><i>[Kona: the LWG agrees this is a good idea.  Post-Kona: Bill
17506 provided wording.  He suggests having open, not close, clear the error
17507 flags.]</i></p>
17508
17509
17510 <p><i>[Post-Sydney: Howard provided a new proposed resolution.  The
17511   old one didn't make sense because it proposed to fix this at the
17512   level of basic_filebuf, which doesn't have access to the stream's
17513   error state.  Howard's proposed resolution fixes this at the level
17514   of the three fstream class template instead.]</i></p>
17515
17516
17517
17518
17519
17520
17521
17522
17523 <hr>
17524 <h3><a name="410"></a>410. Missing semantics for stack and queue comparison operators</h3>
17525 <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>
17526  <b>Submitter:</b> Hans Bos <b>Date:</b> 2003-06-07</p>
17527 <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>
17528 <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>
17529 <p><b>Discussion:</b></p>
17530 <p>
17531 Sections 23.2.3.1 [list.cons] and 23.2.3.3 [list.modifiers] list
17532 comparison operators (==, !=, &lt;, &lt;=, &gt;, =&gt;) for queue and
17533 stack.  Only the semantics for queue::operator== (23.2.3.1 [list.cons] par2) and queue::operator&lt; (23.2.3.1 [list.cons]
17534 par3) are defined.
17535 </p>
17536
17537
17538 <p><b>Proposed resolution:</b></p>
17539
17540 <p>Add the following new paragraphs after 23.2.3.1 [list.cons]
17541   paragraph 3:</p>
17542
17543 <blockquote>
17544
17545 <pre>  operator!=
17546 </pre>
17547 <p>Returns: <tt>x.c != y.c</tt></p>
17548
17549 <pre>  operator&gt;
17550 </pre>
17551 <p>Returns: <tt>x.c &gt; y.c</tt></p>
17552
17553 <pre>  operator&lt;=
17554 </pre>
17555 <p>Returns: <tt>x.c &lt;= y.c</tt></p>
17556
17557 <pre>  operator&gt;=
17558 </pre>
17559 <p>Returns: <tt>x.c &gt;= y.c</tt></p>
17560
17561 </blockquote>
17562
17563 <p>Add the following paragraphs at the end of 23.2.3.3 [list.modifiers]:</p>
17564
17565 <blockquote>
17566
17567 <pre>  operator==
17568 </pre>
17569 <p>Returns: <tt>x.c == y.c</tt></p>
17570
17571 <pre>  operator&lt;
17572 </pre>
17573 <p>Returns: <tt>x.c &lt; y.c</tt></p>
17574
17575 <pre>  operator!=
17576 </pre>
17577 <p>Returns: <tt>x.c != y.c</tt></p>
17578
17579 <pre>  operator&gt;
17580 </pre>
17581 <p>Returns: <tt>x.c &gt; y.c</tt></p>
17582
17583 <pre>  operator&lt;=
17584 </pre>
17585 <p>Returns: <tt>x.c &lt;= y.c</tt></p>
17586
17587 <pre>  operator&gt;=
17588 </pre>
17589 <p>Returns: <tt>x.c &gt;= y.c</tt></p>
17590
17591 </blockquote>
17592
17593
17594 <p><i>[Kona: Matt provided wording.]</i></p>
17595
17596
17597
17598
17599 <p><b>Rationale:</b></p>
17600 <p>There isn't any real doubt about what these operators are
17601 supposed to do, but we ought to spell it out.</p>
17602
17603
17604
17605
17606
17607 <hr>
17608 <h3><a name="411"></a>411. Wrong names of set member functions</h3>
17609 <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>
17610  <b>Submitter:</b> Daniel Frey <b>Date:</b> 2003-07-09</p>
17611 <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>
17612 <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>
17613 <p><b>Discussion:</b></p>
17614 <p>
17615 25.3.5 [alg.set.operations] paragraph 1 reads:
17616 "The semantics of the set operations are generalized to multisets in a
17617 standard way by defining union() to contain the maximum number of
17618 occurrences of every element, intersection() to contain the minimum, and
17619 so on."
17620 </p>
17621
17622 <p>
17623 This is wrong.  The name of the functions are set_union() and
17624 set_intersection(), not union() and intersection().
17625 </p>
17626
17627
17628 <p><b>Proposed resolution:</b></p>
17629 <p>Change that sentence to use the correct names.</p>
17630
17631
17632
17633
17634
17635 <hr>
17636 <h3><a name="412"></a>412. Typo in 27.4.4.3</h3>
17637 <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>
17638  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-07-10</p>
17639 <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>
17640 <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>
17641 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#429">429</a></p>
17642 <p><b>Discussion:</b></p>
17643 <p>
17644 The Effects clause in 27.4.4.3 [iostate.flags] paragraph 5 says that the
17645 function only throws if the respective bits are already set prior to
17646 the function call. That's obviously not the intent. The typo ought to
17647 be corrected and the text reworded as: "If (<i>state</i> &amp;
17648 exceptions()) == 0, returns. ..."
17649 </p>
17650
17651
17652 <p><b>Proposed resolution:</b></p>
17653 <p>
17654 In 27.4.4.3 [iostate.flags] paragraph 5, replace "If (rdstate() &amp;
17655 exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
17656 &amp; exceptions()) == 0".
17657 </p>
17658
17659 <p><i>[Kona: the original proposed resolution wasn't quite right.  We
17660   really do mean rdstate(); the ambiguity is that the wording in the
17661   standard doesn't make it clear whether we mean rdstate() before
17662   setting the new state, or rdsate() after setting it.  We intend the
17663   latter, of course. Post-Kona: Martin provided wording.]</i></p>
17664
17665
17666
17667
17668
17669
17670
17671 <hr>
17672 <h3><a name="413"></a>413. Proposed resolution to LDR#64 still wrong</h3>
17673 <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>
17674  <b>Submitter:</b> Bo Persson <b>Date:</b> 2003-07-13</p>
17675 <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>
17676 <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>
17677 <p><b>Discussion:</b></p>
17678 <p>
17679 The second sentence of the proposed resolution says:
17680 </p>
17681
17682 <p>
17683 "If it inserted no characters because it caught an exception thrown
17684 while extracting characters from sb and ..."
17685 </p>
17686
17687 <p>
17688 However, we are not extracting from sb, but extracting from the
17689 basic_istream (*this) and inserting into sb. I can't really tell if
17690 "extracting" or "sb" is a typo.
17691 </p>
17692
17693 <p><i>[
17694 Sydney: Definitely a real issue. We are, indeed, extracting characters
17695 from an istream and not from sb. The problem was there in the FDIS and
17696 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
17697 to have *this instead of sb. We're talking about the exception flag
17698 state of a basic_istream object, and there's only one basic_istream
17699 object in this discussion, so that would be a consistent
17700 interpretation.  (But we need to be careful: the exception policy of
17701 this member function must be consistent with that of other
17702 extractors.)  PJP will provide wording.
17703 ]</i></p>
17704
17705
17706
17707
17708 <p><b>Proposed resolution:</b></p>
17709 <p>Change the sentence from:</p>
17710
17711 <blockquote><p>
17712 If it inserted no characters because it caught an exception thrown
17713 while extracting characters from sb and failbit is on in exceptions(),
17714 then the caught exception is rethrown.
17715 </p></blockquote>
17716
17717 <p>to:</p>
17718
17719 <blockquote><p>
17720 If it inserted no characters because it caught an exception thrown
17721 while extracting characters from *this and failbit is on in exceptions(),
17722 then the caught exception is rethrown.
17723 </p></blockquote>
17724
17725
17726
17727
17728
17729 <hr>
17730 <h3><a name="414"></a>414. Which iterators are invalidated by v.erase()?</h3>
17731 <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>
17732  <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-08-19</p>
17733 <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>
17734 <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>
17735 <p><b>Discussion:</b></p>
17736 <p>
17737 Consider the following code fragment:
17738 </p>
17739 <blockquote>
17740 <pre>int A[8] = { 1,3,5,7,9,8,4,2 };
17741 std::vector&lt;int&gt; v(A, A+8);
17742
17743 std::vector&lt;int&gt;::iterator i1 = v.begin() + 3;
17744 std::vector&lt;int&gt;::iterator i2 = v.begin() + 4;
17745 v.erase(i1);
17746 </pre>
17747 </blockquote>
17748
17749 <p>
17750 Which iterators are invalidated by <tt>v.erase(i1)</tt>: i1, i2,
17751 both, or neither?
17752 </p>
17753
17754 <p>
17755 On all existing implementations that I know of, the status of i1 and
17756 i2 is the same: both of them will be iterators that point to some
17757 elements of the vector (albeit not the same elements they did
17758 before).  You won't get a crash if you use them.  Depending on
17759 exactly what you mean by "invalidate", you might say that neither one
17760 has been invalidated because they still point to <i>something</i>,
17761 or you might say that both have been invalidated because in both
17762 cases the elements they point to have been changed out from under the
17763 iterator.
17764 </p>
17765
17766 <p>
17767 The standard doesn't say either of those things.  It says that erase
17768 invalidates all iterators and references "after the point of the
17769 erase".  This doesn't include i1, since it's at the point of the
17770 erase instead of after it.  I can't think of any sensible definition
17771 of invalidation by which one can say that i2 is invalidated but i1
17772 isn't.
17773 </p>
17774
17775 <p>
17776 (This issue is important if you try to reason about iterator validity
17777 based only on the guarantees in the standard, rather than reasoning
17778 from typical implementation techniques.  Strict debugging modes,
17779 which some programmers find useful, do not use typical implementation
17780 techniques.)
17781 </p>
17782
17783
17784 <p><b>Proposed resolution:</b></p>
17785 <p>
17786 In 23.2.5.4 [vector.modifiers] paragraph 3, change "Invalidates all the
17787 iterators and references after the point of the erase" to
17788 "Invalidates iterators and references at or after the point of the
17789 erase".
17790 </p>
17791
17792
17793 <p><b>Rationale:</b></p>
17794 <p>I believe this was essentially a typographical error, and that it
17795   was taken for granted that erasing an element invalidates iterators
17796   that point to it.  The effects clause in question treats iterators
17797   and references in parallel, and it would seem counterintuitive to
17798   say that a reference to an erased value remains valid.</p>
17799
17800
17801
17802
17803
17804 <hr>
17805 <h3><a name="415"></a>415. behavior of std::ws</h3>
17806 <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>
17807  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
17808 <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>
17809 <p><b>Discussion:</b></p>
17810 <p>
17811 According to 27.6.1.4, the ws() manipulator is not required to construct
17812 the sentry object. The manipulator is also not a member function so the
17813 text in 27.6.1, p1 through 4 that describes the exception policy for
17814 istream member functions does not apply. That seems inconsistent with
17815 the rest of extractors and all the other input functions (i.e., ws will
17816 not cause a tied stream to be flushed before extraction, it doesn't check
17817 the stream's exceptions or catch exceptions thrown during input, and it
17818 doesn't affect the stream's gcount).
17819 </p>
17820
17821
17822 <p><b>Proposed resolution:</b></p>
17823 <p>
17824 Add to 27.6.1.4 [istream.manip], immediately before the first sentence
17825 of paragraph 1, the following text:
17826 </p>
17827
17828     <blockquote><p>
17829     Behaves as an unformatted input function (as described in
17830     27.6.1.3, paragraph 1), except that it does not count the number
17831     of characters extracted and does not affect the value returned by
17832     subsequent calls to is.gcount(). After constructing a sentry
17833     object...
17834     </p></blockquote>
17835
17836 <p><i>[Post-Kona: Martin provided wording]</i></p>
17837
17838
17839
17840
17841
17842
17843 <hr>
17844 <h3><a name="416"></a>416. definitions of XXX_MIN and XXX_MAX macros in climits</h3>
17845 <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>
17846  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
17847 <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>
17848 <p><b>Discussion:</b></p>
17849         <p>
17850
17851 Given two overloads of the function foo(), one taking an argument of type
17852 int and the other taking a long, which one will the call foo(LONG_MAX)
17853 resolve to? The expected answer should be foo(long), but whether that
17854 is true depends on the #defintion of the LONG_MAX macro, specifically
17855 its type. This issue is about the fact that the type of these macros
17856 is not actually required to be the same as the the type each respective
17857 limit.
17858 <br>
17859
17860 Section 18.2.2 of the C++ Standard does not specify the exact types of
17861 the XXX_MIN and XXX_MAX macros #defined in the &lt;climits&gt; and &lt;limits.h&gt;
17862 headers such as INT_MAX and LONG_MAX and instead defers to the C standard.
17863 <br>
17864
17865 Section 5.2.4.2.1, p1 of the C standard specifies that "The values [of
17866 these constants] shall be replaced by constant expressions suitable for use
17867 in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX,
17868 the following shall be replaced by expressions that have the same type as
17869 would an expression that is an object of the corresponding type converted
17870 according to the integer promotions."
17871 <br>
17872
17873 The "corresponding type converted according to the integer promotions" for
17874 LONG_MAX is, according to 6.4.4.1, p5 of the C standard, the type of long
17875 converted to the first of the following set of types that can represent it:
17876 int, long int, long long int. So on an implementation where (sizeof(long)
17877 == sizeof(int)) this type is actually int, while on an implementation where
17878 (sizeof(long) &gt; sizeof(int)) holds this type will be long.
17879 <br>
17880
17881 This is not an issue in C since the type of the macro cannot be detected
17882 by any conforming C program, but it presents a portability problem in C++
17883 where the actual type is easily detectable by overload resolution.
17884
17885         </p>
17886 <p><i>[Kona: the LWG does not believe this is a defect.  The C macro
17887   definitions are what they are; we've got a better
17888   mechanism, <tt>std::numeric_limits</tt>, that is specified more
17889   precisely than the C limit macros.  At most we should add a
17890   nonnormative note recommending that users who care about the exact
17891   types of limit quantities should use &lt;limits&gt; instead of
17892   &lt;climits&gt;.]</i></p>
17893
17894
17895
17896
17897 <p><b>Proposed resolution:</b></p>
17898
17899 <p>
17900 Change 18.2.2 [c.limits], paragraph 2:
17901 </p>
17902
17903 <blockquote><p>
17904 -2- The contents are the same as the Standard C library header <tt>&lt;limits.h&gt;</tt>.
17905 <ins>[<i>Note:</i> The types of the macros in <tt>&lt;climits&gt;</tt> are not guaranteed
17906 to match the type to which they refer.<i>--end note</i>]</ins>
17907 </p></blockquote>
17908
17909
17910
17911
17912
17913 <hr>
17914 <h3><a name="420"></a>420. is std::FILE a complete type?</h3>
17915 <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>
17916  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
17917 <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>
17918 <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>
17919 <p><b>Discussion:</b></p>
17920 <p>
17921 7.19.1, p2, of C99 requires that the FILE type only be declared in
17922 &lt;stdio.h&gt;.  None of the (implementation-defined) members of the
17923 struct is mentioned anywhere for obvious reasons.
17924 </p>
17925
17926 <p>
17927 C++ says in 27.8.1, p2 that FILE is a type that's defined in &lt;cstdio&gt;. Is
17928 it really the intent that FILE be a complete type or is an implementation
17929 allowed to just declare it without providing a full definition?
17930 </p>
17931
17932
17933 <p><b>Proposed resolution:</b></p>
17934 <p>In the first sentence of 27.8.1 [fstreams] paragraph 2, change
17935   "defined" to "declared".</p>
17936
17937
17938 <p><b>Rationale:</b></p>
17939 <p>We don't want to impose any restrictions beyond what the C standard
17940   already says. We don't want to make anything implementation defined,
17941   because that imposes new requirements in implementations.</p>
17942
17943
17944
17945
17946
17947 <hr>
17948 <h3><a name="422"></a>422. explicit specializations of member functions of class templates</h3>
17949 <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>
17950  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
17951 <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>
17952 <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>
17953 <p><b>Discussion:</b></p>
17954 <p>
17955 It has been suggested that 17.4.3.1, p1 may or may not allow programs to
17956 explicitly specialize members of standard templates on user-defined types.
17957 The answer to the question might have an impact where library requirements
17958 are given using the "as if" rule. I.e., if programs are allowed to specialize
17959 member functions they will be able to detect an implementation's strict
17960 conformance to Effects clauses that describe the behavior of the function
17961 in terms of the other member function (the one explicitly specialized by
17962 the program) by relying on the "as if" rule.
17963 </p>
17964
17965
17966 <p><b>Proposed resolution:</b></p>
17967
17968 <p>
17969   Add the following sentence to 17.4.3.1 [reserved.names], p1:
17970 </p>
17971
17972 <blockquote><p>
17973 It is undefined for a C++ program to add declarations or definitions to
17974 namespace std or namespaces within namespace <tt>std</tt> unless otherwise specified. A
17975 program may add template specializations for any standard library template to
17976 namespace <tt>std</tt>. Such a specialization (complete or partial) of a standard library
17977 template results in undefined behavior unless the declaration depends on a
17978 user-defined type of external linkage and unless the specialization meets the
17979 standard library requirements for the original template.<sup>168)</sup>
17980 <ins>A program has undefined behavior if it declares</ins>
17981 </p>
17982 <ul>
17983 <li><ins>an explicit specialization of any member function of a standard
17984             library class template, or</ins></li>
17985 <li><ins>an explicit specialization of any member function template of a
17986             standard library class or class template, or</ins></li>
17987 <li><ins>an explicit or partial specialization of any member class
17988             template of a standard library class or class template.</ins></li>
17989 </ul>
17990 <p>
17991 A program may explicitly instantiate any templates in the standard library only
17992 if the declaration depends on the name of a user-defined type of external
17993 linkage and the instantiation meets the standard library requirements for the
17994 original template.
17995 </p></blockquote>
17996
17997 <p><i>[Kona: straw poll was 6-1 that user programs should not be
17998   allowed to specialize individual member functions of standard
17999   library class templates, and that doing so invokes undefined
18000   behavior. Post-Kona: Martin provided wording.]</i></p>
18001
18002
18003 <p><i>[Sydney: The LWG agrees that the standard shouldn't permit users
18004 to specialize individual member functions unless they specialize the
18005 whole class, but we're not sure these words say what we want them to;
18006 they could be read as prohibiting the specialization of any standard
18007 library class templates. We need to consult with CWG to make sure we
18008 use the right wording.]</i></p>
18009
18010
18011
18012
18013
18014
18015 <hr>
18016 <h3><a name="425"></a>425. return value of std::get_temporary_buffer</h3>
18017 <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>
18018  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
18019 <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>
18020 <p><b>Discussion:</b></p>
18021 <p>
18022 The standard is not clear about the requirements on the value returned from
18023 a call to get_temporary_buffer(0). In particular, it fails to specify whether
18024 the call should return a distinct pointer each time it is called (like
18025 operator new), or whether the value is unspecified (as if returned by
18026 malloc). The standard also fails to mention what the required behavior
18027 is when the argument is less than 0.
18028 </p>
18029
18030
18031 <p><b>Proposed resolution:</b></p>
18032 <p>Change 20.4.3 [meta.help] paragraph 2 from "...or a pair of 0
18033 values if no storage can be obtained" to "...or a pair of 0 values if
18034 no storage can be obtained or if <i>n</i> &lt;= 0."</p>
18035 <p><i>[Kona: Matt provided wording]</i></p>
18036
18037
18038
18039
18040
18041 <hr>
18042 <h3><a name="426"></a>426. search_n(), fill_n(), and generate_n() with negative n</h3>
18043 <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>
18044  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
18045 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.search">issues</a> in [alg.search].</p>
18046 <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>
18047 <p><b>Discussion:</b></p>
18048 <p>
18049 The complexity requirements for these function templates are incorrect
18050 (or don't even make sense) for negative n:</p>
18051
18052 <p>25.1.9, p7 (search_n):
18053 <br>
18054 Complexity: At most (last1 - first1) * count applications
18055 of the corresponding predicate.</p>
18056
18057 <p>25.2.5, p3 (fill_n):
18058 <br>
18059 Complexity: Exactly last - first (or n) assignments.</p>
18060
18061 <p>25.2.6, p3 (generate_n):
18062 <br>
18063 Complexity: Exactly last - first (or n) assignments.</p>
18064
18065 <p>
18066 In addition, the Requirements or the Effects clauses for the latter two
18067 templates don't say anything about the behavior when n is negative.
18068 </p>
18069
18070
18071 <p><b>Proposed resolution:</b></p>
18072 <p>Change 25.1.9, p7 to</p>
18073
18074 <blockquote><p>
18075 Complexity: At most (last1 - first1) * count applications
18076 of the corresponding predicate if count is positive,
18077 or 0 otherwise.
18078 </p></blockquote>
18079
18080 <p>Change 25.2.5, p2 to</p>
18081 <blockquote><p>
18082 Effects: Assigns value through all the iterators in the range [first,
18083 last), or [first, first + n) if n is positive, none otherwise.
18084 </p></blockquote>
18085
18086 <p>Change 25.2.5, p3 to:</p>
18087 <blockquote><p>
18088 Complexity: Exactly last - first (or n if n is positive,
18089 or 0 otherwise) assignments.
18090 </p></blockquote>
18091
18092 <p>
18093 Change 25.2.6, p1
18094 to (notice the correction for the misspelled "through"):
18095 </p>
18096 <blockquote><p>
18097 Effects: Invokes the function object genand assigns the return
18098 value of gen through all the iterators in the range [first, last),
18099 or [first, first + n) if n is positive, or [first, first)
18100 otherwise.
18101 </p></blockquote>
18102
18103 <p>Change 25.2.6, p3 to:</p>
18104 <blockquote><p>
18105 Complexity: Exactly last - first (or n if n is positive,
18106 or 0 otherwise) assignments.
18107 </p></blockquote>
18108
18109
18110 <p><b>Rationale:</b></p>
18111 <p>Informally, we want to say that whenever we see a negative number
18112   we treat it the same as if it were zero.  We believe the above
18113   changes do that (although they may not be the minimal way of saying
18114   so).  The LWG considered and rejected the alternative of saying that
18115   negative numbers are undefined behavior.</p>
18116
18117
18118
18119
18120
18121 <hr>
18122 <h3><a name="428"></a>428. string::erase(iterator) validity</h3>
18123 <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>
18124  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
18125 <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>
18126 <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>
18127 <p><b>Discussion:</b></p>
18128 <p>
18129 23.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q)
18130 that q must be a valid dereferenceable iterator into the sequence a.
18131 </p>
18132
18133 <p>
18134 However, 21.3.5.5, p5 describing string::erase(p) only requires that
18135 p be a valid iterator.
18136 </p>
18137
18138 <p>
18139 This may be interepreted as a relaxation of the general requirement,
18140 which is most likely not the intent.
18141 </p>
18142
18143
18144 <p><b>Proposed resolution:</b></p>
18145 <p>Remove 21.3.6.5 [string::erase] paragraph 5.</p>
18146
18147
18148 <p><b>Rationale:</b></p>
18149 <p>The LWG considered two options: changing the string requirements to
18150   match the general container requirements, or just removing the
18151   erroneous string requirements altogether.  The LWG chose the latter
18152   option, on the grounds that duplicating text always risks the
18153   possibility that it might be duplicated incorrectly.</p>
18154
18155
18156
18157
18158
18159 <hr>
18160 <h3><a name="432"></a>432. stringbuf::overflow() makes only one write position available</h3>
18161 <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>
18162  <b>Submitter:</b> Christian W Brock <b>Date:</b> 2003-09-24</p>
18163 <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>
18164 <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>
18165 <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>
18166 <p><b>Discussion:</b></p>
18167 <p>27.7.1.3 par 8 says:</p>
18168 <blockquote><p>
18169 Notes: The function can make a write position available only if
18170     ( mode &amp; ios_base::out) != 0. To make a write position
18171     available, the function reallocates (or initially allocates) an
18172     array object with a sufficient number of elements to hold the
18173     current array object (if any), plus one additional write position.
18174     If ( mode &amp; ios_base::in) != 0, the function alters the read end
18175     pointer egptr() to point just past the new write position (as
18176     does the write end pointer epptr()).
18177 </p></blockquote>
18178
18179 <p>
18180 The sentences "plus one additional write position." and especially
18181     "(as does the write end pointer epptr())" COULD by interpreted
18182     (and is interpreted by at least my library vendor) as:
18183 </p>
18184
18185 <blockquote><p>
18186     post-condition: epptr() == pptr()+1
18187 </p></blockquote>
18188
18189 <p>
18190 This WOULD force sputc() to call the virtual overflow() each time.
18191 </p>
18192
18193 <p>The proposed change also affects Defect Report 169.</p>
18194
18195
18196
18197 <p><b>Proposed resolution:</b></p>
18198 <p>27.7.1.1/2 Change:</p>
18199
18200 <blockquote><p>
18201 2- Notes: The function allocates no array object.
18202 </p></blockquote>
18203
18204 <p>
18205 to:
18206 </p>
18207
18208 <blockquote><p>
18209 2- Postcondition: str() == "".
18210 </p></blockquote>
18211
18212 <p>
18213 27.7.1.1/3 Change:
18214 </p>
18215
18216 <blockquote>
18217 <p>
18218 -3- Effects: Constructs an object of class basic_stringbuf,
18219 initializing the base class with basic_streambuf()
18220 (lib.streambuf.cons), and initializing mode with which . Then copies
18221 the content of str into the basic_stringbuf underlying character
18222 sequence and initializes the input and output sequences according to
18223 which. If which &amp; ios_base::out is true, initializes the output
18224 sequence with the underlying sequence. If which &amp; ios_base::in is
18225 true, initializes the input sequence with the underlying sequence.
18226 </p>
18227 </blockquote>
18228
18229 <p>to:</p>
18230
18231 <blockquote>
18232 <p>
18233 -3- Effects: Constructs an object of class basic_stringbuf,
18234 initializing the base class with basic_streambuf()
18235 (lib.streambuf.cons), and initializing mode with which. Then copies
18236 the content of str into the basic_stringbuf underlying character
18237 sequence. If which &amp; ios_base::out is true, initializes the output
18238 sequence such that pbase() points to the first underlying character,
18239 epptr() points one past the last underlying character, and if (which &amp;
18240 ios_base::ate) is true, pptr() is set equal to
18241 epptr() else pptr() is set equal to pbase(). If which &amp; ios_base::in
18242 is true, initializes the input sequence such that eback() and gptr()
18243 point to the first underlying character and egptr() points one past
18244 the last underlying character.
18245 </p>
18246 </blockquote>
18247
18248 <p>27.7.1.2/1 Change:</p>
18249
18250 <blockquote>
18251 <p>
18252 -1- Returns: A basic_string object whose content is equal to the
18253 basic_stringbuf underlying character sequence. If the buffer is only
18254 created in input mode, the underlying character sequence is equal to
18255 the input sequence; otherwise, it is equal to the output sequence. In
18256 case of an empty underlying character sequence, the function returns
18257 basic_string&lt;charT,traits,Allocator&gt;().
18258 </p>
18259 </blockquote>
18260
18261 <p>to:</p>
18262
18263 <blockquote>
18264 <p>
18265 -1- Returns: A basic_string object whose content is equal to the
18266 basic_stringbuf underlying character sequence. If the basic_stringbuf
18267 was created only in input mode, the resultant basic_string contains
18268 the character sequence in the range [eback(), egptr()).  If the
18269 basic_stringbuf was created with (which &amp; ios_base::out) being true
18270 then the resultant basic_string contains the character sequence in the
18271 range [pbase(), high_mark) where high_mark represents the position one
18272 past the highest initialized character in the buffer.  Characters can
18273 be initialized either through writing to the stream, or by
18274 constructing the basic_stringbuf with a basic_string, or by calling
18275 the str(basic_string) member function.  In the case of calling the
18276 str(basic_string) member function, all characters initialized prior to
18277 the call are now considered uninitialized (except for those
18278 characters re-initialized by the new basic_string).  Otherwise the
18279 basic_stringbuf has been created in neither input nor output mode and
18280 a zero length basic_string is returned.
18281 </p>
18282 </blockquote>
18283
18284 <p>
18285 27.7.1.2/2 Change:
18286 </p>
18287
18288 <blockquote>
18289 <p>
18290 -2- Effects: If the basic_stringbuf's underlying character sequence is
18291 not empty, deallocates it. Then copies the content of s into the
18292 basic_stringbuf underlying character sequence and initializes the
18293 input and output sequences according to the mode stored when creating
18294 the basic_stringbuf object. If (mode&amp;ios_base::out) is true, then
18295 initializes the output sequence with the underlying sequence. If
18296 (mode&amp;ios_base::in) is true, then initializes the input sequence with
18297 the underlying sequence.
18298 </p>
18299 </blockquote>
18300
18301 <p>to:</p>
18302
18303 <blockquote>
18304 <p>
18305 -2- Effects: Copies the content of s into the basic_stringbuf
18306 underlying character sequence. If mode &amp; ios_base::out is true,
18307 initializes the output sequence such that pbase() points to the first
18308 underlying character, epptr() points one past the last underlying
18309 character, and if (mode &amp; ios_base::ate) is true,
18310 pptr() is set equal to epptr() else pptr() is set equal to pbase(). If
18311 mode &amp; ios_base::in is true, initializes the input sequence such that
18312 eback() and gptr() point to the first underlying character and egptr()
18313 points one past the last underlying character.
18314 </p>
18315 </blockquote>
18316
18317 <p>Remove 27.2.1.2/3.  (Same rationale as issue 238: incorrect and unnecessary.)</p>
18318
18319 <p>27.7.1.3/1 Change:</p>
18320
18321 <blockquote>
18322 <p>
18323 1- Returns: If the input sequence has a read position available,
18324 returns traits::to_int_type(*gptr()).  Otherwise, returns
18325 traits::eof().
18326 </p>
18327 </blockquote>
18328
18329 <p>to:</p>
18330
18331 <blockquote>
18332 <p>
18333 1- Returns: If the input sequence has a read position available,
18334 returns traits::to_int_type(*gptr()).  Otherwise, returns
18335 traits::eof().  Any character in the underlying buffer which has been
18336 initialized is considered to be part of the input sequence.
18337 </p>
18338 </blockquote>
18339
18340 <p>27.7.1.3/9 Change:</p>
18341
18342 <blockquote>
18343 <p>
18344 -9- Notes: The function can make a write position available only if (
18345 mode &amp; ios_base::out) != 0. To make a write position available, the
18346 function reallocates (or initially allocates) an array object with a
18347 sufficient number of elements to hold the current array object (if
18348 any), plus one additional write position. If ( mode &amp; ios_base::in) !=
18349 0, the function alters the read end pointer egptr() to point just past
18350 the new write position (as does the write end pointer epptr()).
18351 </p>
18352 </blockquote>
18353
18354 <p>to:</p>
18355
18356 <blockquote>
18357 <p>
18358 -9- The function can make a write position available only if ( mode &amp;
18359 ios_base::out) != 0. To make a write position available, the function
18360 reallocates (or initially allocates) an array object with a sufficient
18361 number of elements to hold the current array object (if any), plus one
18362 additional write position. If ( mode &amp; ios_base::in) != 0, the
18363 function alters the read end pointer egptr() to point just past the
18364 new write position.
18365 </p>
18366 </blockquote>
18367
18368 <p>27.7.1.3/12 Change:</p>
18369
18370 <blockquote>
18371 <p>
18372 -12- _ If (newoff + off) &lt; 0, or (xend - xbeg) &lt; (newoff + off), the
18373 positioning operation fails. Otherwise, the function assigns xbeg +
18374 newoff + off to the next pointer xnext .
18375 </p>
18376 </blockquote>
18377
18378 <p>to:</p>
18379
18380 <blockquote>
18381 <p>
18382 -12- _ If (newoff + off) &lt; 0, or if (newoff + off) refers to an
18383 uninitialized character (as defined in 27.7.1.3 [stringbuf.members]
18384 paragraph 1), the positioning operation fails. Otherwise, the function
18385 assigns xbeg + newoff + off to the next pointer xnext .
18386 </p>
18387 </blockquote>
18388
18389 <p><i>[post-Kona: Howard provided wording.  At Kona the LWG agreed that
18390   something along these lines was a good idea, but the original
18391   proposed resolution didn't say enough about the effect of various
18392   member functions on the underlying character sequences.]</i></p>
18393
18394
18395
18396
18397 <p><b>Rationale:</b></p>
18398 <p>The current basic_stringbuf description is over-constrained in such
18399 a way as to prohibit vendors from making this the high-performance
18400 in-memory stream it was meant to be.  The fundamental problem is that
18401 the pointers: eback(), gptr(), egptr(), pbase(), pptr(), epptr() are
18402 observable from a derived client, and the current description
18403 restricts the range [pbase(), epptr()) from being grown geometrically.
18404 This change allows, but does not require, geometric growth of this
18405 range.</p>
18406
18407 <p>Backwards compatibility issues: These changes will break code that
18408 derives from basic_stringbuf, observes epptr(), and depends upon
18409 [pbase(), epptr()) growing by one character on each call to overflow()
18410 (i.e. test suites).  Otherwise there are no backwards compatibility
18411 issues.</p>
18412
18413 <p>27.7.1.1/2: The non-normative note is non-binding, and if it were
18414 binding, would be over specification.  The recommended change focuses
18415 on the important observable fact.</p>
18416
18417 <p>27.7.1.1/3: This change does two things: 1.  It describes exactly
18418 what must happen in terms of the sequences.  The terms "input
18419 sequence" and "output sequence" are not well defined.  2.  It
18420 introduces a common extension: open with app or ate mode.  I concur
18421 with issue 238 that paragraph 4 is both wrong and unnecessary.</p>
18422
18423 <p>27.7.1.2/1: This change is the crux of the efficiency issue.  The
18424 resultant basic_string is not dependent upon epptr(), and thus
18425 implementors are free to grow the underlying buffer geometrically
18426 during overflow() *and* place epptr() at the end of that buffer.</p>
18427
18428 <p>27.7.1.2/2:  Made consistent with the proposed 27.7.1.1/3.</p>
18429
18430 <p>27.7.1.3/1: Clarifies that characters written to the stream beyond
18431 the initially specified string are available for reading in an i/o
18432 basic_streambuf.</p>
18433
18434 <p>27.7.1.3/9: Made normative by removing "Notes:", and removed the
18435 trailing parenthetical comment concerning epptr().</p>
18436
18437 <p>27.7.1.3/12: Restricting the positioning to [xbeg, xend) is no
18438 longer allowable since [pbase(), epptr()) may now contain
18439 uninitialized characters.  Positioning is only allowable over the
18440 initialized range.</p>
18441
18442
18443
18444
18445
18446 <hr>
18447 <h3><a name="434"></a>434. bitset::to_string() hard to use</h3>
18448 <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>
18449  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-10-15</p>
18450 <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>
18451 <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>
18452 <p><b>Discussion:</b></p>
18453 <p>
18454 It has been pointed out a number of times that the bitset to_string() member
18455 function template is tedious to use since callers must explicitly specify the
18456 entire template argument list (3 arguments). At least two implementations
18457 provide a number of overloads of this template to make it easier to use.
18458 </p>
18459
18460
18461
18462 <p><b>Proposed resolution:</b></p>
18463 <p>In order to allow callers to specify no template arguments at all, just the
18464 first one (charT), or the first 2 (charT and traits), in addition to all
18465 three template arguments, add the following three overloads to both the
18466 interface (declarations only) of the class template bitset as well as to
18467 section 23.3.5.2, immediately after p34, the Returns clause of the existing
18468 to_string() member function template:</p>
18469
18470 <pre>    template &lt;class charT, class traits&gt;
18471     basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
18472     to_string () const;
18473
18474     -34.1- Returns: to_string&lt;charT, traits, allocator&lt;charT&gt; &gt;().
18475
18476     template &lt;class charT&gt;
18477     basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
18478     to_string () const;
18479
18480     -34.2- Returns: to_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;().
18481
18482     basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
18483     to_string () const;
18484
18485     -34.3- Returns: to_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;().
18486 </pre>
18487
18488 <p><i>[Kona: the LWG agrees that this is an improvement over the
18489   status quo.  Dietmar thought about an alternative using a proxy
18490   object but now believes that the proposed resolution above is the
18491   right choice.
18492 ]</i></p>
18493
18494
18495
18496
18497
18498
18499
18500
18501 <hr>
18502 <h3><a name="435"></a>435. bug in DR 25</h3>
18503 <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>
18504  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-10-15</p>
18505 <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>
18506 <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>
18507 <p><b>Discussion:</b></p>
18508
18509 <p>
18510 It has been pointed out that the proposed resolution in DR 25 may not be
18511 quite up to snuff: <br>
18512 http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html
18513 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#25<br>
18514 </p>
18515
18516 <p>
18517 It looks like Petur is right. The complete corrected text is copied below.
18518 I think we may have have been confused by the reference to 22.2.2.2.2 and
18519 the subsequent description of `n' which actually talks about the second
18520 argument to sputn(), not about the number of fill characters to pad with.
18521 </p>
18522
18523 <p>
18524 So the question is: was the original text correct? If the intent was to
18525 follow classic iostreams then it most likely wasn't, since setting width()
18526 to less than the length of the string doesn't truncate it on output. This
18527 is also the behavior of most implementations (except for SGI's standard
18528 iostreams where the operator does truncate).
18529 </p>
18530
18531
18532
18533 <p><b>Proposed resolution:</b></p>
18534 <p>Change the text in 21.3.7.9, p4 from</p>
18535     <blockquote><p>
18536     If bool(k) is true, inserts characters as if by calling
18537     os.rdbuf()-&gt;sputn(str.data(), n), padding as described in stage 3
18538     of lib.facet.num.put.virtuals, where n is the larger of os.width()
18539     and str.size();
18540     </p></blockquote>
18541 <p>to</p>
18542     <blockquote><p>
18543     If bool(k) is true, determines padding as described in
18544     lib.facet.num.put.virtuals, and then inserts the resulting
18545     sequence of characters <tt>seq</tt> as if by calling
18546     <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where <tt>n</tt> is the larger of
18547     <tt>os.width()</tt> and <tt>str.size()</tt>;
18548      </p></blockquote>
18549
18550 <p><i>[Kona: it appears that neither the original wording, DR25, nor the
18551   proposed resolution, is quite what we want.  We want to say that
18552   the string will be output, padded to os.width() if necessary.  We
18553   don't want to duplicate the padding rules in clause 22, because
18554   they're complicated, but we need to be careful because they weren't
18555   quite written with quite this case in mind.  We need to say what
18556   the character sequence is, and then defer to clause 22.  Post-Kona:
18557   Benjamin provided wording.]</i></p>
18558
18559
18560
18561
18562
18563
18564
18565 <hr>
18566 <h3><a name="436"></a>436. are cv-qualified facet types valid facets?</h3>
18567 <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>
18568  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-10-15</p>
18569 <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>
18570 <p><b>Discussion:</b></p>
18571 <p>
18572 Is "const std::ctype&lt;char&gt;" a valid template argument to has_facet, use_facet,
18573 and the locale template ctor? And if so, does it designate the same Facet as
18574 the non-const "std::ctype&lt;char&gt;?" What about "volatile std::ctype&lt;char&gt;?"
18575 Different implementations behave differently: some fail to compile, others
18576 accept such types but behave inconsistently.
18577 </p>
18578
18579
18580 <p><b>Proposed resolution:</b></p>
18581 <p>Change 22.1.1.1.2, p1 to read:</p>
18582
18583 <p>Template parameters in this clause which are required to be facets
18584 are those named Facet in declarations. A program that passes a type
18585 that is not a facet, or a type that refers to volatile-qualified
18586 facet, as an (explicit or deduced) template parameter to a locale
18587 function expecting a facet, is ill-formed.  A const-qualified facet is
18588 a valid template argument to any locale function that expects a Facet
18589 template parameter.</p>
18590
18591 <p><i>[Kona: changed the last sentence from a footnote to normative
18592 text.]</i></p>
18593
18594
18595
18596
18597
18598
18599 <hr>
18600 <h3><a name="438"></a>438. Ambiguity in the "do the right thing" clause</h3>
18601 <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>
18602  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2003-10-20</p>
18603 <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>
18604 <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>
18605 <p><b>Discussion:</b></p>
18606
18607 <p>Section 23.1.1 [sequence.reqmts], paragraphs 9-11, fixed up the problem
18608 noticed with statements like:</p>
18609 <pre>vector&lt;int&gt; v(10, 1);
18610 </pre>
18611
18612 <p>The intent of the above statement was to construct with:</p>
18613 <pre>vector(size_type, const value_type&amp;);
18614 </pre>
18615
18616 <p>but early implementations failed to compile as they bound to:</p>
18617 <pre>template &lt;class InputIterator&gt;
18618 vector(InputIterator f, InputIterator l);
18619 </pre>
18620 <p>instead.</p>
18621
18622 <p>Paragraphs 9-11 say that if InputIterator is an integral type, then the
18623 member template constructor will have the same effect as:</p>
18624 <pre>vector&lt;static_cast&lt;size_type&gt;(f), static_cast&lt;value_type&gt;(l));
18625 </pre>
18626 <p>(and similarly for the other member template functions of sequences).</p>
18627
18628 <p>There is also a note that describes one implementation technique:</p>
18629 <blockquote><p>
18630    One way that sequence implementors can satisfy this requirement is to
18631    specialize the member template for every integral type.
18632 </p></blockquote>
18633
18634 <p>This might look something like:</p>
18635 <blockquote>
18636 <pre>template &lt;class T&gt;
18637 struct vector
18638 {
18639      typedef unsigned size_type;
18640
18641      explicit vector(size_type) {}
18642      vector(size_type, const T&amp;) {}
18643
18644      template &lt;class I&gt;
18645      vector(I, I);
18646
18647      // ...
18648 };
18649
18650 template &lt;class T&gt;
18651 template &lt;class I&gt;
18652 vector&lt;T&gt;::vector(I, I) { ... }
18653
18654 template &lt;&gt;
18655 template &lt;&gt;
18656 vector&lt;int&gt;::vector(int, int) { ... }
18657
18658 template &lt;&gt;
18659 template &lt;&gt;
18660 vector&lt;int&gt;::vector(unsigned, unsigned) { ... }
18661
18662 //  ...
18663 </pre>
18664 </blockquote>
18665
18666 <p>Label this solution 'A'.</p>
18667
18668 <p>The standard also says:</p>
18669 <blockquote><p>
18670  Less cumbersome implementation techniques also exist.
18671 </p></blockquote>
18672 <p>
18673 A popular technique is to not specialize as above, but instead catch
18674 every call with the member template, detect the type of InputIterator,
18675 and then redirect to the correct logic.  Something like:
18676 </p>
18677 <blockquote>
18678 <pre>template &lt;class T&gt;
18679 template &lt;class I&gt;
18680 vector&lt;T&gt;::vector(I f, I l)
18681 {
18682      choose_init(f, l, int2type&lt;is_integral&lt;I&gt;::value&gt;());
18683 }
18684
18685 template &lt;class T&gt;
18686 template &lt;class I&gt;
18687 vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;false&gt;)
18688 {
18689     // construct with iterators
18690 }
18691
18692 template &lt;class T&gt;
18693 template &lt;class I&gt;
18694 vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;true&gt;)
18695 {
18696     size_type sz = static_cast&lt;size_type&gt;(f);
18697     value_type v = static_cast&lt;value_type&gt;(l);
18698     // construct with sz,v
18699 }
18700 </pre>
18701 </blockquote>
18702
18703 <p>Label this solution 'B'.</p>
18704
18705 <p>Both of these solutions solve the case the standard specifically
18706 mentions:</p>
18707 <pre>vector&lt;int&gt; v(10, 1);  // ok, vector size 10, initialized to 1
18708 </pre>
18709
18710 <p>
18711 However, (and here is the problem), the two solutions have different
18712 behavior in some cases where the value_type of the sequence is not an
18713 integral type.  For example consider:
18714 </p>
18715 <blockquote><pre>     pair&lt;char, char&gt;                     p('a', 'b');
18716      vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
18717 </pre></blockquote>
18718 <p>
18719 The second line of this snippet is likely an error.  Solution A catches
18720 the error and refuses to compile.  The reason is that there is no
18721 specialization of the member template constructor that looks like:
18722 </p>
18723 <pre>template &lt;&gt;
18724 template &lt;&gt;
18725 vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;::vector(char, char) { ... }
18726 </pre>
18727
18728 <p>
18729 So the expression binds to the unspecialized member template
18730 constructor, and then fails (compile time) because char is not an
18731 InputIterator.
18732 </p>
18733
18734 <p>
18735 Solution B compiles the above example though.  'a' is casted to an
18736 unsigned integral type and used to size the outer vector.  'b' is
18737 static casted to the inner vector using it's explicit constructor:
18738 </p>
18739
18740 <pre>explicit vector(size_type n);
18741 </pre>
18742
18743 <p>
18744 and so you end up with a static_cast&lt;size_type&gt;('a') by
18745 static_cast&lt;size_type&gt;('b') matrix.
18746 </p>
18747
18748 <p>
18749 It is certainly possible that this is what the coder intended.  But the
18750 explicit qualifier on the inner vector has been thwarted at any rate.
18751 </p>
18752
18753 <p>
18754 The standard is not clear whether the expression:
18755 </p>
18756
18757 <pre>     vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
18758 </pre>
18759
18760 <p>
18761 (and similar expressions) are:
18762 </p>
18763
18764 <ol>
18765 <li>  undefined behavior.</li>
18766 <li>  illegal and must be rejected.</li>
18767 <li>  legal and must be accepted.</li>
18768 </ol>
18769
18770 <p>My preference is listed in the order presented.</p>
18771
18772 <p>There are still other techniques for implementing the requirements of
18773 paragraphs 9-11, namely the "restricted template technique" (e.g.
18774 enable_if).  This technique is the most compact and easy way of coding
18775 the requirements, and has the behavior of #2 (rejects the above
18776 expression).
18777 </p>
18778
18779 <p>
18780 Choosing 1 would allow all implementation techniques I'm aware of.
18781 Choosing 2 would allow only solution 'A' and the enable_if technique.
18782 Choosing 3 would allow only solution 'B'.
18783 </p>
18784
18785 <p>
18786 Possible wording for a future standard if we wanted to actively reject
18787 the expression above would be to change "static_cast" in paragraphs
18788 9-11 to "implicit_cast" where that is defined by:
18789 </p>
18790
18791 <blockquote>
18792 <pre>template &lt;class T, class U&gt;
18793 inline
18794 T implicit_cast(const U&amp; u)
18795 {
18796      return u;
18797 }
18798 </pre>
18799 </blockquote>
18800
18801
18802
18803 <p><b>Proposed resolution:</b></p>
18804
18805 <p>Replace 23.1.1 [sequence.reqmts] paragraphs 9 - 11 with:</p>
18806
18807 <p>For every sequence defined in this clause and in clause lib.strings:</p>
18808
18809 <ul>
18810   <li>
18811     <p>If the constructor</p>
18812        <pre>       template &lt;class InputIterator&gt;
18813        X(InputIterator f, InputIterator l,
18814          const allocator_type&amp; a = allocator_type())
18815        </pre>
18816     <p>is called with a type InputIterator that does not qualify as
18817     an input iterator, then the constructor will behave as if the
18818     overloaded constructor:</p>
18819        <pre>       X(size_type, const value_type&amp; = value_type(),
18820          const allocator_type&amp; = allocator_type())
18821        </pre>
18822     <p>were called instead, with the arguments static_cast&lt;size_type&gt;(f), l and a, respectively.</p>
18823   </li>
18824
18825   <li>
18826     <p>If the member functions of the forms:</p>
18827        <pre>       template &lt;class InputIterator&gt;          //  such as  insert()
18828        rt fx1(iterator p, InputIterator f, InputIterator l);
18829
18830        template &lt;class InputIterator&gt;          //  such as  append(), assign()
18831        rt fx2(InputIterator f, InputIterator l);
18832
18833        template &lt;class InputIterator&gt;          //  such as  replace()
18834        rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l);
18835        </pre>
18836     <p>are called with a type InputIterator that does not qualify as
18837     an input iterator, then these functions will behave as if the
18838     overloaded member functions:</p>
18839        <pre>       rt fx1(iterator, size_type, const value_type&amp;);
18840
18841        rt fx2(size_type, const value_type&amp;);
18842
18843        rt fx3(iterator, iterator, size_type, const value_type&amp;);
18844        </pre>
18845     <p>were called instead, with the same arguments.</p>
18846   </li>
18847 </ul>
18848
18849 <p>In the previous paragraph the alternative binding will fail if f
18850 is not implicitly convertible to X::size_type or if l is not implicitly
18851 convertible to X::value_type.</p>
18852
18853 <p>
18854 The extent to which an implementation determines that a type cannot be
18855 an input iterator is unspecified, except that as a minimum integral
18856 types shall not qualify as input iterators.
18857 </p>
18858
18859
18860
18861 <p><i>[
18862 Kona: agreed that the current standard requires <tt>v('a', 'b')</tt>
18863 to be accepted, and also agreed that this is surprising behavior.  The
18864 LWG considered several options, including something like
18865 implicit_cast, which doesn't appear to be quite what we want.  We
18866 considered Howards three options: allow acceptance or rejection,
18867 require rejection as a compile time error, and require acceptance.  By
18868 straw poll (1-6-1), we chose to require a compile time error.
18869 Post-Kona: Howard provided wording.
18870 ]</i></p>
18871
18872
18873 <p><i>[
18874 Sydney: The LWG agreed with this general direction, but there was some
18875 discomfort with the wording in the original proposed resolution.
18876 Howard submitted new wording, and we will review this again in
18877 Redmond.
18878 ]</i></p>
18879
18880
18881 <p><i>[Redmond: one very small change in wording: the first argument
18882   is cast to size_t.  This fixes the problem of something like
18883   <tt>vector&lt;vector&lt;int&gt; &gt;(5, 5)</tt>, where int is not
18884   implicitly convertible to the value type.]</i></p>
18885
18886
18887
18888
18889 <p><b>Rationale:</b></p>
18890 <p>The proposed resolution fixes:</p>
18891
18892 <pre>  vector&lt;int&gt; v(10, 1);
18893 </pre>
18894
18895 <p>
18896 since as integral types 10 and 1 must be disqualified as input
18897 iterators and therefore the (size,value) constructor is called (as
18898 if).</p>
18899
18900 <p>The proposed resolution breaks:</p>
18901
18902 <pre>  vector&lt;vector&lt;T&gt; &gt; v(10, 1);
18903 </pre>
18904
18905 <p>
18906 because the integral type 1 is not *implicitly* convertible to
18907 vector&lt;T&gt;.  The wording above requires a diagnostic.</p>
18908
18909 <p>
18910 The proposed resolution leaves the behavior of the following code
18911 unspecified.
18912 </p>
18913
18914 <pre>  struct A
18915   {
18916     operator int () const {return 10;}
18917   };
18918
18919   struct B
18920   {
18921     B(A) {}
18922   };
18923
18924   vector&lt;B&gt; v(A(), A());
18925 </pre>
18926
18927 <p>
18928 The implementation may or may not detect that A is not an input
18929 iterator and employee the (size,value) constructor.  Note though that
18930 in the above example if the B(A) constructor is qualified explicit,
18931 then the implementation must reject the constructor as A is no longer
18932 implicitly convertible to B.
18933 </p>
18934
18935
18936
18937
18938
18939 <hr>
18940 <h3><a name="441"></a>441. Is fpos::state const?</h3>
18941 <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>
18942  <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-17</p>
18943 <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>
18944 <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>
18945 <p><b>Discussion:</b></p>
18946 <p>
18947 In section 27.4.3.1 [fpos.members] fpos&lt;stateT&gt;::state() is declared
18948 non const, but in section 27.4.3 [fpos] it is declared const.
18949 </p>
18950
18951
18952 <p><b>Proposed resolution:</b></p>
18953 <p>
18954 In section 27.4.3.1 [fpos.members], change the declaration of
18955 <tt>fpos&lt;stateT&gt;::state()</tt> to const.
18956 </p>
18957
18958
18959
18960
18961
18962 <hr>
18963 <h3><a name="442"></a>442. sentry::operator bool() inconsistent signature</h3>
18964 <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>
18965  <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-18</p>
18966 <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>
18967 <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>
18968 <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>
18969 <p><b>Discussion:</b></p>
18970 <p>
18971 In section 27.6.2.4 [ostream::sentry] paragraph 4, in description part
18972 basic_ostream&lt;charT, traits&gt;::sentry::operator bool() is declared
18973 as non const, but in section 27.6.2.3, in synopsis it is declared
18974 const.
18975 </p>
18976
18977
18978 <p><b>Proposed resolution:</b></p>
18979 <p>
18980 In section 27.6.2.4 [ostream::sentry] paragraph 4, change the declaration
18981 of <tt>sentry::operator bool()</tt> to const.
18982 </p>
18983
18984
18985
18986
18987
18988 <hr>
18989 <h3><a name="443"></a>443. filebuf::close() inconsistent use of EOF</h3>
18990 <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>
18991  <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-20</p>
18992 <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>
18993 <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>
18994 <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>
18995 <p><b>Discussion:</b></p>
18996 <p>
18997 In section 27.8.1.4 [filebuf.members] par6, in effects description of
18998 basic_filebuf&lt;charT, traits&gt;::close(), overflow(EOF) is used twice;
18999 should be overflow(traits::eof()).
19000 </p>
19001
19002
19003 <p><b>Proposed resolution:</b></p>
19004 <p>
19005 Change overflow(EOF) to overflow(traits::eof()).
19006 </p>
19007
19008
19009
19010
19011
19012 <hr>
19013 <h3><a name="444"></a>444. Bad use of casts in fstream</h3>
19014 <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>
19015  <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-20</p>
19016 <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>
19017 <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>
19018 <p><b>Discussion:</b></p>
19019 <p>27.8.1.9 [ifstream.members] p1, 27.8.1.13 [ofstream.members] p1,
19020 27.8.1.17 [fstream.members] p1 seems have same problem as exposed in
19021 LWG issue
19022 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>.
19023 </p>
19024
19025
19026 <p><b>Proposed resolution:</b></p>
19027
19028 <p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away
19029  constness. The other two places are stylistic: we could change the
19030  C-style casts to const_cast. Post-Sydney: Howard provided wording.
19031 ]</i></p>
19032
19033
19034 <p>Change 27.8.1.7/1 from:</p>
19035 <blockquote><p>
19036   Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
19037 </p></blockquote>
19038
19039 <p>to:</p>
19040 <blockquote><p>
19041   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
19042 </p></blockquote>
19043
19044 <p>Change 27.8.1.10/1 from:</p>
19045 <blockquote><p>
19046   Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
19047 </p></blockquote>
19048
19049 <p>to:</p>
19050 <blockquote><p>
19051   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
19052 </p></blockquote>
19053
19054 <p>Change 27.8.1.13/1 from:</p>
19055 <blockquote><p>
19056   Returns: &amp;sb.
19057 </p></blockquote>
19058
19059 <p>to:</p>
19060 <blockquote><p>
19061   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
19062 </p></blockquote>
19063
19064
19065
19066
19067
19068
19069
19070
19071 <hr>
19072 <h3><a name="445"></a>445. iterator_traits::reference unspecified for some iterator categories</h3>
19073 <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>
19074  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2003-12-09</p>
19075 <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>
19076 <p><b>Discussion:</b></p>
19077 <p>
19078 The standard places no restrictions at all on the reference type
19079 of input, output, or forward iterators (for forward iterators it
19080 only specifies that *x must be value_type&amp; and doesn't mention
19081 the reference type).  Bidirectional iterators' reference type is
19082 restricted only by implication, since the base iterator's
19083 reference type is used as the return type of reverse_iterator's
19084 operator*, which must be T&amp; in order to be a conforming forward
19085 iterator.
19086 </p>
19087
19088 <p>
19089 Here's what I think we ought to be able to expect from an input
19090 or forward iterator's reference type R, where a is an iterator
19091 and V is its value_type
19092 </p>
19093
19094 <ul>
19095   <li>
19096       *a is convertible to R
19097   </li>
19098
19099   <li>
19100       R is convertible to V
19101   </li>
19102
19103   <li>
19104       static_cast&lt;V&gt;(static_cast&lt;R&gt;(*a)) is equivalent to
19105       static_cast&lt;V&gt;(*a)
19106   </li>
19107 </ul>
19108
19109 <p>A mutable forward iterator ought to satisfy, for x of type V:</p>
19110   <pre>      { R r = *a; r = x; } is equivalent to *a = x;
19111   </pre>
19112
19113 <p>
19114 I think these requirements capture existing container iterators
19115 (including vector&lt;bool&gt;'s), but render istream_iterator invalid;
19116 its reference type would have to be changed to a constant
19117 reference.
19118 </p>
19119
19120
19121 <p>
19122 (Jeremy Siek) During the discussion in Sydney, it was felt that a
19123 simpler long term solution for this was needed. The solution proposed
19124 was to require <tt>reference</tt> to be the same type as <tt>*a</tt>
19125 and <tt>pointer</tt> to be the same type as <tt>a-&gt;</tt>.  Most
19126 iterators in the Standard Library already meet this requirement. Some
19127 iterators are output iterators, and do not need to meet the
19128 requirement, and others are only specified through the general
19129 iterator requirements (which will change with this resolution). The
19130 sole case where there is an explicit definition of the reference type
19131 that will need to change is <tt>istreambuf_iterator</tt> which returns
19132 <tt>charT</tt> from <tt>operator*</tt> but has a reference type of
19133 <tt>charT&amp;</tt>. We propose changing the reference type of
19134 <tt>istreambuf_iterator</tt> to <tt>charT</tt>.
19135 </p>
19136
19137 <p>The other option for resolving the issue with <tt>pointer</tt>,
19138   mentioned in the note below, is to remove <tt>pointer</tt>
19139   altogether. I prefer placing requirements on <tt>pointer</tt> to
19140   removing it for two reasons. First, <tt>pointer</tt> will become
19141   useful for implementing iterator adaptors and in particular,
19142   <tt>reverse_iterator</tt> will become more well defined. Second,
19143   removing <tt>pointer</tt> is a rather drastic and publicly-visible
19144   action to take.</p>
19145
19146 <p>The proposed resolution technically enlarges the requirements for
19147 iterators, which means there are existing iterators (such as
19148 <tt>istreambuf_iterator</tt>, and potentially some programmer-defined
19149 iterators) that will no longer meet the requirements. Will this break
19150 existing code? The scenario in which it would is if an algorithm
19151 implementation (say in the Standard Library) is changed to rely on
19152 <tt>iterator_traits::reference</tt>, and then is used with one of the
19153 iterators that do not have an appropriately defined
19154 <tt>iterator_traits::reference</tt>.
19155 </p>
19156
19157
19158 <p>The proposed resolution makes one other subtle change. Previously,
19159 it was required that output iterators have a <tt>difference_type</tt>
19160 and <tt>value_type</tt> of <tt>void</tt>, which means that a forward
19161 iterator could not be an output iterator. This is clearly a mistake,
19162 so I've changed the wording to say that those types may be
19163 <tt>void</tt>.
19164 </p>
19165
19166
19167
19168 <p><b>Proposed resolution:</b></p>
19169
19170 <p>In 24.3.1 [iterator.traits], after:</p>
19171
19172 <blockquote><p>
19173 be defined as the iterator's difference type, value type and iterator
19174 category, respectively.
19175 </p></blockquote>
19176
19177 <p>add</p>
19178
19179 <blockquote><p>
19180 In addition, the types</p>
19181 <pre>iterator_traits&lt;Iterator&gt;::reference
19182 iterator_traits&lt;Iterator&gt;::pointer
19183 </pre>
19184 <p>must be defined as the iterator's reference and pointer types, that
19185 is, the same type as the type of <tt>*a</tt> and <tt>a-&gt;</tt>,
19186 respectively.</p>
19187 </blockquote>
19188
19189 <p>In 24.3.1 [iterator.traits], change:</p>
19190
19191 <blockquote><p>
19192 In the case of an output iterator, the types</p>
19193 <pre>iterator_traits&lt;Iterator&gt;::difference_type
19194 iterator_traits&lt;Iterator&gt;::value_type
19195 </pre>
19196 <p>are both defined as <tt>void</tt>.</p>
19197 </blockquote>
19198
19199 <p>to:</p>
19200 <blockquote><p>
19201 In the case of an output iterator, the types</p>
19202 <pre>iterator_traits&lt;Iterator&gt;::difference_type
19203 iterator_traits&lt;Iterator&gt;::value_type
19204 iterator_traits&lt;Iterator&gt;::reference
19205 iterator_traits&lt;Iterator&gt;::pointer
19206 </pre>
19207 <p>may be defined as <tt>void</tt>.</p>
19208 </blockquote>
19209
19210 <p>In 24.5.3 [istreambuf.iterator], change:</p>
19211 <blockquote>
19212 <pre>typename traits::off_type, charT*, charT&amp;&gt;
19213 </pre>
19214 </blockquote>
19215 <p>to:</p>
19216 <blockquote>
19217 <pre>typename traits::off_type, charT*, charT&gt;
19218 </pre>
19219 </blockquote>
19220
19221 <p><i>[
19222 Redmond: there was concern in Sydney that this might not be the only place
19223 where things were underspecified and needed to be changed.  Jeremy
19224 reviewed iterators in the standard and confirmed that nothing else
19225 needed to be changed.
19226 ]</i></p>
19227
19228
19229
19230
19231
19232
19233
19234
19235
19236 <hr>
19237 <h3><a name="448"></a>448. Random Access Iterators over abstract classes</h3>
19238 <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>
19239  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-01-07</p>
19240 <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>
19241 <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>
19242 <p><b>Discussion:</b></p>
19243 <p>
19244 Table 76, the random access iterator requirement table, says that the
19245 return type of a[n] must be "convertible to T".  When an iterator's
19246 value_type T is an abstract class, nothing is convertible to T.
19247 Surely this isn't an intended restriction?
19248 </p>
19249
19250
19251 <p><b>Proposed resolution:</b></p>
19252 <p>
19253 Change the return type to "convertible to T const&amp;".
19254 </p>
19255
19256
19257
19258
19259
19260 <hr>
19261 <h3><a name="449"></a>449. Library Issue 306 Goes Too Far</h3>
19262 <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>
19263  <b>Submitter:</b> Pete Becker <b>Date:</b> 2004-01-15</p>
19264 <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>
19265 <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>
19266 <p><b>Discussion:</b></p>
19267 <p>Original text:</p>
19268 <blockquote><p>
19269 The macro offsetof accepts a restricted set of type arguments in this
19270 International Standard. type shall be a POD structure or a POD union
19271 (clause 9). The result of applying the offsetof macro to a field that
19272 is a static data member or a function member is undefined."
19273 </p></blockquote>
19274
19275 <p>Revised text:</p>
19276 <blockquote><p>
19277 "If type is not a POD structure or a POD union the results are undefined."
19278 </p></blockquote>
19279
19280 <p>
19281 Looks to me like the revised text should have replaced only the second
19282 sentence. It doesn't make sense standing alone.
19283 </p>
19284
19285
19286
19287 <p><b>Proposed resolution:</b></p>
19288 <p>Change 18.1, paragraph 5, to:</p>
19289
19290 <blockquote><p>
19291 The macro offsetof accepts a restricted set of type arguments in this
19292 International Standard.  If type is not a POD structure or a POD union
19293 the results are undefined.  The result of applying the offsetof macro
19294 to a field that is a static data member or a function member is
19295 undefined."
19296 </p></blockquote>
19297
19298
19299
19300
19301
19302 <hr>
19303 <h3><a name="453"></a>453. basic_stringbuf::seekoff need not always fail for an empty stream</h3>
19304 <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>
19305  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
19306 <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>
19307 <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>
19308 <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>
19309 <p><b>Discussion:</b></p>
19310 <pre>  pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
19311                                     ios_base::openmode);
19312 </pre>
19313 <p>
19314 is obliged to fail if nothing has been inserted into the stream. This
19315 is unnecessary and undesirable. It should be permissible to seek to
19316 an effective offset of zero.</p>
19317
19318 <p><i>[
19319  Sydney: Agreed that this is an annoying problem: seeking to zero should be
19320  legal. Bill will provide wording.
19321 ]</i></p>
19322
19323
19324
19325
19326 <p><b>Proposed resolution:</b></p>
19327 <p>Change the sentence from:</p>
19328 <blockquote><p>
19329 For a sequence to be positioned, if its next pointer (either
19330 gptr() or pptr()) is a null pointer, the positioning operation
19331 fails.
19332 </p></blockquote>
19333
19334 <p>to:</p>
19335
19336 <blockquote><p>
19337 For a sequence to be positioned, if its next pointer (either
19338 gptr() or pptr()) is a null pointer and the new offset newoff
19339 is nonzero, the positioning operation fails.
19340 </p></blockquote>
19341
19342
19343
19344
19345
19346 <hr>
19347 <h3><a name="455"></a>455. cerr::tie() and wcerr::tie() are overspecified</h3>
19348 <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>
19349  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
19350 <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>
19351 <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>
19352 <p><b>Discussion:</b></p>
19353 <p>
19354 Both cerr::tie() and wcerr::tie() are obliged to be null at program
19355 startup. This is overspecification and overkill. It is both traditional
19356 and useful to tie cerr to cout, to ensure that standard output is drained
19357 whenever an error message is written. This behavior should at least be
19358 permitted if not required. Same for wcerr::tie().
19359 </p>
19360
19361
19362 <p><b>Proposed resolution:</b></p>
19363
19364 <p>Add to the description of cerr:</p>
19365 <blockquote><p>
19366 After the object cerr is initialized, cerr.tie() returns &amp;cout.
19367 Its state is otherwise the same as required for basic_ios&lt;char&gt;::init
19368 (lib.basic.ios.cons).
19369 </p></blockquote>
19370
19371 <p>Add to the description of wcerr:</p>
19372
19373 <blockquote><p>
19374 After the object wcerr is initialized, wcerr.tie() returns &amp;wcout.
19375 Its state is otherwise the same as required for basic_ios&lt;wchar_t&gt;::init
19376 (lib.basic.ios.cons).
19377 </p></blockquote>
19378
19379 <p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just
19380   permit, cout and cerr to be tied on startup.  Pre-Redmond: Bill will
19381   provide wording.]</i></p>
19382
19383
19384
19385
19386
19387
19388 <hr>
19389 <h3><a name="456"></a>456. Traditional C header files are overspecified</h3>
19390 <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>
19391  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
19392 <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>
19393 <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>
19394 <p><b>Discussion:</b></p>
19395
19396 <p>The C++ Standard effectively requires that the traditional C headers
19397 (of the form &lt;xxx.h&gt;) be defined in terms of the newer C++
19398 headers (of the form &lt;cxxx&gt;). Clauses 17.4.1.2/4 and D.5 combine
19399 to require that:</p>
19400
19401 <ul>
19402  <li>Including the header &lt;cxxx&gt; declares a C name in namespace std.</li>
19403
19404  <li> Including the header &lt;xxx.h&gt; declares a C name in namespace std
19405     (effectively by including &lt;cxxx&gt;), then imports it into the global
19406     namespace with an individual using declaration.</li>
19407 </ul>
19408
19409 <p>
19410 The rules were left in this form despited repeated and heated objections
19411 from several compiler vendors. The C headers are often beyond the direct
19412 control of C++ implementors. In some organizations, it's all they can do
19413 to get a few #ifdef __cplusplus tests added. Third-party library vendors
19414 can perhaps wrap the C headers. But neither of these approaches supports
19415 the drastic restructuring required by the C++ Standard. As a result, it is
19416 still widespread practice to ignore this conformance requirement, nearly
19417 seven years after the committee last debated this topic. Instead, what is
19418 often implemented is:
19419 </p>
19420
19421 <ul>
19422  <li> Including the header &lt;xxx.h&gt; declares a C name in the
19423  global namespace.</li>
19424
19425  <li> Including the header &lt;cxxx&gt; declares a C name in the
19426  global namespace (effectively by including &lt;xxx.h&gt;), then
19427  imports it into namespace std with an individual using declaration.</li>
19428 </ul>
19429
19430 <p>
19431 The practical benefit for implementors with the second approach is that
19432 they can use existing C library headers, as they are pretty much obliged
19433 to do. The practical cost for programmers facing a mix of implementations
19434 is that they have to assume weaker rules:</p>
19435
19436 <ul>
19437   <li> If you want to assuredly declare a C name in the global
19438   namespace, include &lt;xxx.h&gt;. You may or may not also get the
19439   declaration in namespace std.</li>
19440
19441   <li> If you want to assuredly declare a C name in namespace std,
19442   include &lt;cxxx&gt;. You may or may not also get the declaration in
19443   the global namespace.</li>
19444 </ul>
19445
19446 <p>
19447 There also exists the <i>possibility</i> of subtle differences due to
19448 Koenig lookup, but there are so few non-builtin types defined in the C
19449 headers that I've yet to see an example of any real problems in this
19450 area.
19451 </p>
19452
19453 <p>
19454 It is worth observing that the rate at which programmers fall afoul of
19455 these differences has remained small, at least as measured by newsgroup
19456 postings and our own bug reports. (By an overwhelming margin, the
19457 commonest problem is still that programmers include &lt;string&gt; and can't
19458 understand why the typename string isn't defined -- this a decade after
19459 the committee invented namespace std, nominally for the benefit of all
19460 programmers.)
19461 </p>
19462
19463 <p>
19464 We should accept the fact that we made a serious mistake and rectify it,
19465 however belatedly, by explicitly allowing either of the two schemes for
19466 declaring C names in headers.
19467 </p>
19468
19469 <p><i>[Sydney: This issue has been debated many times, and will
19470   certainly have to be discussed in full committee before any action
19471   can be taken.  However, the preliminary sentiment of the LWG was in
19472   favor of the change.  (6 yes, 0 no, 2 abstain) Robert Klarer
19473   suggests that we might also want to undeprecate the
19474   C-style <tt>.h</tt> headers.]</i></p>
19475
19476
19477
19478
19479 <p><b>Proposed resolution:</b></p>
19480 <p>
19481 Add to 17.4.1.2 [headers], para. 4:
19482 </p>
19483
19484 <blockquote><p>
19485 Except as noted in clauses 18 through 27 and Annex D, the contents of each
19486 header <i>cname</i> shall be the same as that of the corresponding header
19487 <i>name.h</i>, as specified in ISO/IEC 9899:1990 Programming Languages C (Clause
19488 7), or ISO/IEC:1990 Programming Languages-C AMENDMENT 1: C Integrity, (Clause
19489 7), as appropriate, as if by inclusion. In the C++ Standard Library, however,
19490 the declarations <del>and definitions</del> (except for names which are defined
19491 as macros in C) are within namespace scope (3.3.5) of the namespace std.
19492 <ins>It is unspecified whether these names are first declared within the global
19493 namespace scope and are then injected into namespace std by explicit
19494 using-declarations (7.3.3 [namespace.udecl]).</ins>
19495 </p></blockquote>
19496
19497 <p>
19498 Change D.5 [depr.c.headers], para. 2-3:
19499 </p>
19500
19501 <blockquote>
19502 <p>
19503 -2- Every C header, each of which has a name of the form <i>name.h</i>, behaves
19504 as if each name placed in the Standard library namespace by the corresponding
19505 <i>cname</i> header is <del>also</del> placed within the <ins>global</ins>
19506 namespace scope<ins>.</ins> <del>of the namespace <tt>std</tt> and is followed
19507 by an explicit <i>using-declaration</i> (7.3.3 [namespace.udecl]).</del>
19508 <ins>It is unspecified whether these names are first declared or defined within
19509 namespace scope (3.3.5 [basic.scope.namespace]) of the namespace
19510 <tt>std</tt> and are then injected into the global namespace scope by explicit
19511 using-declarations (7.3.3 [namespace.udecl]).</ins>
19512 </p>
19513 <p>
19514 -3- [<i>Example:</i> The header <tt>&lt;cstdlib&gt;</tt> <ins>assuredly</ins>
19515 provides its declarations and definitions within the namespace <tt>std</tt>.
19516 <ins>It may also provide these names within the global namespace.</ins> The
19517 header <tt>&lt;stdlib.h&gt;</tt> <del>makes these available also in</del>
19518 <ins>assuredly provides the same declarations and definitions within</ins> the
19519 global namespace, much as in the C Standard. <ins>It may also provide these
19520 names within the namespace <tt>std</tt>.</ins> <i>-- end example</i>]
19521 </p>
19522 </blockquote>
19523
19524
19525
19526
19527
19528 <hr>
19529 <h3><a name="457"></a>457. bitset constructor: incorrect number of initialized bits</h3>
19530 <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>
19531  <b>Submitter:</b> Dag Henriksson <b>Date:</b> 2004-01-30</p>
19532 <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>
19533 <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>
19534 <p><b>Discussion:</b></p>
19535 <p>
19536 The constructor from unsigned long says it initializes "the first M
19537 bit positions to the corresponding bit values in val. M is the smaller
19538 of N and the value CHAR_BIT * sizeof(unsigned long)."
19539 </p>
19540
19541 <p>
19542 Object-representation vs. value-representation strikes again. CHAR_BIT *
19543 sizeof (unsigned long) does not give us the number of bits an unsigned long
19544 uses to hold the value. Thus, the first M bit position above is not
19545 guaranteed to have any corresponding bit values in val.
19546 </p>
19547
19548
19549 <p><b>Proposed resolution:</b></p>
19550 <p>In 23.3.5.1 [bitset.cons] paragraph 2, change "M is the smaller of
19551   N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
19552   "<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in
19553   the value representation (section 3.9 [basic.types]) of <tt>unsigned
19554   long</tt>."
19555 </p>
19556
19557
19558
19559
19560
19561 <hr>
19562 <h3><a name="460"></a>460. Default modes missing from basic_fstream member specifications</h3>
19563 <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>
19564  <b>Submitter:</b> Ben Hutchings <b>Date:</b> 2004-04-01</p>
19565 <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>
19566 <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>
19567 <p><b>Discussion:</b></p>
19568 <p>
19569 The second parameters of the non-default constructor and of the open
19570 member function for basic_fstream, named "mode", are optional
19571 according to the class declaration in 27.8.1.11 [lib.fstream].  The
19572 specifications of these members in 27.8.1.12 [lib.fstream.cons] and
19573 27.8.1.13 lib.fstream.members] disagree with this, though the
19574 constructor declaration has the "explicit" function-specifier implying
19575 that it is intended to be callable with one argument.
19576 </p>
19577
19578
19579 <p><b>Proposed resolution:</b></p>
19580 <p>In 27.8.1.15 [fstream.cons], change</p>
19581 <pre>  explicit basic_fstream(const char* s, ios_base::openmode mode);
19582 </pre>
19583 <p>to</p>
19584 <pre>  explicit basic_fstream(const char* s,
19585                          ios_base::openmode mode = ios_base::in|ios_base::out);
19586 </pre>
19587 <p>In 27.8.1.17 [fstream.members], change</p>
19588 <pre>  void open(const char*s, ios_base::openmode mode);
19589 </pre>
19590 <p>to</p>
19591 <pre>  void open(const char*s,
19592             ios_base::openmode mode = ios_base::in|ios_base::out);
19593 </pre>
19594
19595
19596
19597
19598
19599 <hr>
19600 <h3><a name="461"></a>461. time_get hard or impossible to implement</h3>
19601 <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>
19602  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-03-23</p>
19603 <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>
19604 <p><b>Discussion:</b></p>
19605 <p>
19606 Template time_get currently contains difficult, if not impossible,
19607 requirements for do_date_order, do_get_time, and do_get_date. All require
19608 the implementation to scan a field generated by the %x or %X conversion
19609 specifier in strftime. Yes, do_date_order can always return no_order, but
19610 that doesn't help the other functions. The problem is that %x can be
19611 nearly anything, and it can vary widely with locales. It's horribly
19612 onerous to have to parse "third sunday after Michaelmas in the year of
19613 our Lord two thousand and three," but that's what we currently ask of
19614 do_get_date. More practically, it leads some people to think that if
19615 %x produces 10.2.04, we should know to look for dots as separators. Still
19616 not easy.
19617 </p>
19618
19619 <p>
19620 Note that this is the <i>opposite</i> effect from the intent stated in the
19621 footnote earlier in this subclause:
19622 </p>
19623
19624 <blockquote><p>
19625 "In other words, user confirmation is required for reliable parsing of
19626 user-entered dates and times, but machine-generated formats can be
19627 parsed reliably. This allows parsers to be aggressive about interpreting
19628 user variations on standard formats."
19629 </p></blockquote>
19630
19631 <p>
19632 We should give both implementers and users an easier and more reliable
19633 alternative: provide a (short) list of alternative delimiters and say
19634 what the default date order is for no_order. For backward compatibility,
19635 and maximum latitude, we can permit an implementation to parse whatever
19636 %x or %X generates, but we shouldn't require it.
19637 </p>
19638
19639
19640 <p><b>Proposed resolution:</b></p>
19641
19642 <p><b>In the description:</b></p>
19643 <pre>iter_type do_get_time(iter_type s, iter_type end, ios_base&amp; str,
19644         ios_base::iostate&amp; err, tm* t) const;
19645 </pre>
19646
19647 <p>
19648 2 Effects: Reads characters starting at suntil it has extracted those
19649 struct tm members, and remaining format characters, used by
19650 time_put&lt;&gt;::put to produce the format specified by 'X', or until it
19651 encounters an error or end of sequence.
19652 </p>
19653
19654 <p><b>change:</b> 'X'</p>
19655
19656 <p><b>to:</b> "%H:%M:%S"</p>
19657
19658
19659 <p>Change</p>
19660 <pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
19661         ios_base::iostate&amp; err, tm* t) const;
19662
19663 4 Effects: Reads characters starting at s until it has extracted those
19664 struct tm members, and remaining format characters, used by
19665 time_put&lt;&gt;::put to produce the format specified by 'x', or until it
19666 encounters an error.
19667 </pre>
19668
19669 <p>to</p>
19670 <pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
19671         ios_base::iostate&amp; err, tm* t) const;
19672 </pre>
19673
19674 <p>
19675 4 Effects: Reads characters starting at s until it has extracted those
19676 struct tm members, and remaining format characters, used by
19677 time_put&lt;&gt;::put to produce one of the following formats, or until it
19678 encounters an error. The format depends on the value returned by
19679 date_order() as follows:
19680 </p>
19681
19682 <pre>        date_order()  format
19683
19684         no_order      "%m/%d/%y"
19685         dmy           "%d/%m/%y"
19686         mdy           "%m/%d/%y"
19687         ymd           "%y/%m/%d"
19688         ydm           "%y/%d/%m"
19689 </pre>
19690 <p>
19691 An implementation may also accept additional implementation-defined formats.
19692 </p>
19693
19694 <p><i>[Redmond: agreed that this is a real problem.  The solution is
19695   probably to match C99's parsing rules.  Bill provided wording.
19696 ]</i></p>
19697
19698
19699
19700
19701
19702
19703
19704 <hr>
19705 <h3><a name="464"></a>464. Suggestion for new member functions in standard containers</h3>
19706 <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>
19707  <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2004-05-12</p>
19708 <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>
19709 <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>
19710 <p><b>Discussion:</b></p>
19711
19712 <p>To add slightly more convenience to vector&lt;T&gt; and map&lt;Key,T&gt; we should consider to add</p>
19713 <ol>
19714 <li> add vector&lt;T&gt;::data() member (const and non-const version)
19715 semantics: if( empty() ) return 0; else return buffer_;</li>
19716 <li> add map&lt;Key,T&gt;::at( const Key&amp; k ) member (const and non-const version)
19717 <i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
19718 </ol>
19719
19720 <p>Rationale:</p>
19721
19722 <ul>
19723 <li>To obtain a pointer to the vector's buffer, one must use either
19724 operator[]() (which can give undefined behavior for empty vectors) or
19725 at() (which will then throw if the vector is empty). </li>
19726 <li>tr1::array&lt;T,sz&gt; already has a data() member</li>
19727 <li>e cannot use operator[]() when T is not DefaultDonstructible</li>
19728 <li>Neither when the map is const.</li>
19729 <li>when we want to make sure we don't add an element accidently</li>
19730 <li>when it should be considered an error if a key is not in the map</li>
19731 </ul>
19732
19733
19734
19735 <p><b>Proposed resolution:</b></p>
19736 <p>In 23.2.5 [vector], add the following to the <tt>vector</tt>
19737   synopsis after "element access" and before "modifiers":</p>
19738 <pre>  // <i>[lib.vector.data] data access</i>
19739   pointer       data();
19740   const_pointer data() const;
19741 </pre>
19742
19743 <p>Add a new subsection of 23.2.5 [vector]:</p>
19744 <blockquote>
19745 <p>23.2.4.x <tt>vector</tt> data access</p>
19746 <pre>   pointer       data();
19747    const_pointer data() const;
19748 </pre>
19749 <p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
19750    range.  For a non-empty vector, data() == &amp;front().</p>
19751 <p><b>Complexity:</b> Constant time.</p>
19752 <p><b>Throws:</b> Nothing.</p>
19753 </blockquote>
19754
19755 <p>In 23.3.1 [map], add the following to the <tt>map</tt>
19756 synopsis immediately after the line for operator[]:</p>
19757 <pre>  T&amp;       at(const key_type&amp; x);
19758   const T&amp; at(const key_type&amp; x) const;
19759 </pre>
19760
19761 <p>Add the following to 23.3.1.2 [map.access]:</p>
19762 <blockquote>
19763 <pre>  T&amp;       at(const key_type&amp; x);
19764   const T&amp; at(const key_type&amp; x) const;
19765 </pre>
19766
19767 <p><b>Returns:</b> A reference to the element whose key is equivalent
19768   to x, if such an element is present in the map.</p>
19769 <p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
19770
19771 </blockquote>
19772
19773
19774
19775 <p><b>Rationale:</b></p>
19776 <p>Neither of these additions provides any new functionality but the
19777   LWG agreed that they are convenient, especially for novices.  The
19778   exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
19779   was chosen to match <tt>vector::at</tt>.</p>
19780
19781
19782
19783
19784
19785 <hr>
19786 <h3><a name="465"></a>465. Contents of &lt;ciso646&gt;</h3>
19787 <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>
19788  <b>Submitter:</b> Steve Clamage <b>Date:</b> 2004-06-03</p>
19789 <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>
19790 <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>
19791 <p><b>Discussion:</b></p>
19792 <p>C header &lt;iso646.h&gt; defines macros for some operators, such as
19793 not_eq for !=.</p>
19794
19795 <p>Section 17.4.1.2 [headers] "Headers" says that except as noted in
19796 clauses 18 through 27, the &lt;cname&gt; C++ header contents are the same
19797 as the C header &lt;name.h&gt;. In particular, table 12 lists
19798 &lt;ciso646&gt; as a C++ header.</p>
19799
19800 <p>I don't find any other mention of &lt;ciso646&gt;, or any mention of
19801 &lt;iso646.h&gt;, in clauses 17 thorough 27. That implies that the
19802 contents of &lt;ciso646&gt; are the same as C header &lt;iso646.h&gt;.</p>
19803
19804 <p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
19805 "Header &lt;iso646.h&gt;" says that the alternative tokens are not
19806 defined as macros in &lt;ciso646&gt;, but does not mention the contents
19807 of &lt;iso646.h&gt;.</p>
19808
19809 <p>I don't find any normative text to support C.2.2.2.</p>
19810
19811
19812
19813 <p><b>Proposed resolution:</b></p>
19814 <p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
19815   paragraph 6 (the one about functions must be functions):</p>
19816
19817 <blockquote>
19818 <p>Identifiers that are keywords or operators in C++ shall not be defined
19819 as macros in C++ standard library headers.
19820 [Footnote:In particular, including the standard header &lt;iso646.h&gt;
19821 or &lt;ciso646&gt; has no effect. </p>
19822 </blockquote>
19823
19824 <p><i>[post-Redmond: Steve provided wording.]</i></p>
19825
19826
19827
19828
19829
19830
19831
19832 <hr>
19833 <h3><a name="467"></a>467. char_traits::lt(), compare(), and memcmp()</h3>
19834 <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>
19835  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
19836 <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>
19837 <p><b>Discussion:</b></p>
19838
19839 <p>
19840 Table 37 describes the requirements on Traits::compare() in terms of
19841 those on Traits::lt(). 21.1.3.1, p6 requires char_traits&lt;char&gt;::lt()
19842 to yield the same result as operator&lt;(char, char).
19843 </p>
19844
19845 <p>
19846 Most, if not all, implementations of char_traits&lt;char&gt;::compare()
19847 call memcmp() for efficiency. However, the C standard requires both
19848 memcmp() and strcmp() to interpret characters under comparison as
19849 unsigned, regardless of the signedness of char. As a result, all
19850 these char_traits implementations fail to meet the requirement
19851 imposed by Table 37 on compare() when char is signed.
19852 </p>
19853
19854
19855 <p>Read email thread starting with c++std-lib-13499 for more. </p>
19856
19857
19858 <p><b>Proposed resolution:</b></p>
19859
19860
19861 <p>Change 21.1.3.1, p6 from</p>
19862 <blockquote><p>
19863     The two-argument members assign, eq, and lt are defined identically
19864     to the built-in operators =, ==, and &lt; respectively.
19865 </p></blockquote>
19866 <p>to</p>
19867 <blockquote><p>
19868   The two-argument member assign is defined identically to
19869   the built-in operator =. The two
19870   argument members eq and lt are defined identically to
19871   the built-in operators == and &lt; for type unsigned char.
19872 </p></blockquote>
19873
19874 <p><i>[Redmond: The LWG agreed with this general direction, but we
19875   also need to change <tt>eq</tt> to be consistent with this change.
19876   Post-Redmond: Martin provided wording.]</i></p>
19877
19878
19879
19880
19881
19882
19883 <hr>
19884 <h3><a name="468"></a>468. unexpected consequences of ios_base::operator void*()</h3>
19885 <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>
19886  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
19887 <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>
19888 <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>
19889 <p><b>Discussion:</b></p>
19890
19891 <p>The program below is required to compile but when run it typically
19892 produces unexpected results due to the user-defined conversion from
19893 std::cout or any object derived from basic_ios to void*.
19894 </p>
19895
19896 <pre>    #include &lt;cassert&gt;
19897     #include &lt;iostream&gt;
19898
19899     int main ()
19900     {
19901         assert (std::cin.tie () == std::cout);
19902         // calls std::cout.ios::operator void*()
19903     }
19904 </pre>
19905
19906
19907 <p><b>Proposed resolution:</b></p>
19908
19909 <p>
19910 Replace std::basic_ios&lt;charT, traits&gt;::operator void*() with another
19911 conversion operator to some unspecified type that is guaranteed not
19912 to be convertible to any other type except for bool (a pointer-to-member
19913 might be one such suitable type). In addition, make it clear that the
19914 pointer type need not be a pointer to a complete type and when non-null,
19915 the value need not be valid.
19916 </p>
19917
19918 <p>Specifically, change in [lib.ios] the signature of</p>
19919 <pre>    operator void*() const;
19920 </pre>
19921 <p>to</p>
19922 <pre>    operator unspecified-bool-type() const;
19923 </pre>
19924 <p>and change [lib.iostate.flags], p1 from</p>
19925 <pre>    operator void*() const;
19926 </pre>
19927 <p>to</p>
19928 <pre>operator unspecified-bool-type() const;
19929
19930      -1- Returns: if fail() then a value that will evaluate false in a
19931       boolean context; otherwise a value that will evaluate true in a
19932       boolean context. The value type returned shall not be
19933       convertible to int.
19934
19935      -2- [Note: This conversion can be used in contexts where a bool
19936       is expected (e.g., an if condition); however, implicit
19937       conversions (e.g., to int) that can occur with bool are not
19938       allowed, eliminating some sources of user error. One possible
19939       implementation choice for this type is pointer-to-member.  - end
19940       note]
19941 </pre>
19942
19943 <p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
19944
19945 <p><i>[Lillehammer: Doug provided revised wording for
19946   "unspecified-bool-type".]</i></p>
19947
19948
19949
19950
19951
19952
19953
19954
19955 <hr>
19956 <h3><a name="469"></a>469. vector&lt;bool&gt; ill-formed relational operators</h3>
19957 <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>
19958  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
19959 <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>
19960 <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>
19961 <p><b>Discussion:</b></p>
19962
19963 <p>
19964 The overloads of relational operators for vector&lt;bool&gt; specified
19965 in [lib.vector.bool] are redundant (they are semantically identical
19966 to those provided for the vector primary template) and may even be
19967 diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation
19968 in c++std-lib-13647).
19969 </p>
19970
19971
19972
19973 <p><b>Proposed resolution:</b></p>
19974 <p>
19975 Remove all overloads of overloads of relational operators for
19976 vector&lt;bool&gt; from [lib.vector.bool].
19977 </p>
19978
19979
19980
19981
19982 <hr>
19983 <h3><a name="474"></a>474. confusing Footnote 297</h3>
19984 <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>
19985  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-07-01</p>
19986 <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>
19987 <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>
19988 <p><b>Discussion:</b></p>
19989
19990 <p>
19991 I think Footnote 297 is confused. The paragraph it applies to seems
19992 quite clear in that widen() is only called if the object is not a char
19993 stream (i.e., not basic_ostream&lt;char&gt;), so it's irrelevant what the
19994 value of widen(c) is otherwise.
19995 </p>
19996
19997
19998 <p><b>Proposed resolution:</b></p>
19999 <p>
20000 I propose to strike the Footnote.
20001 </p>
20002
20003
20004
20005
20006 <hr>
20007 <h3><a name="475"></a>475. May the function object passed to for_each modify the elements of the iterated sequence?</h3>
20008 <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>
20009  <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Date:</b> 2004-07-09</p>
20010 <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>
20011 <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>
20012 <p><b>Discussion:</b></p>
20013 <p>
20014 It is not clear whether the function object passed to for_each is allowed to
20015 modify the elements of the sequence being iterated over.
20016 </p>
20017
20018 <p>
20019 for_each is classified without explanation in [lib.alg.nonmodifying], "25.1
20020 Non-modifying sequence operations". 'Non-modifying sequence operation' is
20021 never defined.
20022 </p>
20023
20024 <p>
20025 25(5) says: "If an algorithm's Effects section says that a value pointed to
20026 by any iterator passed as an argument is modified, then that algorithm has
20027 an additional type requirement: The type of that argument shall satisfy the
20028 requirements of a mutable iterator (24.1)."
20029 </p>
20030
20031 <p>for_each's Effects section does not mention whether arguments can be
20032 modified:</p>
20033
20034 <blockquote><p>
20035   "Effects: Applies f to the result of dereferencing every iterator in the
20036    range [first, last), starting from first and proceeding to last - 1."
20037 </p></blockquote>
20038
20039 <p>
20040 Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in
20041 the sense that neither the algorithms themselves nor the function objects
20042 passed to the algorithms may modify the sequences or elements in any way.
20043 This DR affects only for_each.
20044 </p>
20045
20046 <p>
20047 We suspect that for_each's classification in "non-modifying sequence
20048 operations" means that the algorithm itself does not inherently modify the
20049 sequence or the elements in the sequence, but that the function object
20050 passed to it may modify the elements it operates on.
20051 </p>
20052
20053 <p>
20054 The original STL document by Stepanov and Lee explicitly prohibited the
20055 function object from modifying its argument.
20056 The "obvious" implementation of for_each found in several standard library
20057 implementations, however, does not impose this restriction.
20058 As a result, we suspect that the use of for_each with function objects that modify
20059 their arguments is wide-spread.
20060 If the restriction was reinstated, all such code would become non-conforming.
20061 Further, none of the other algorithms in the Standard
20062 could serve the purpose of for_each (transform does not guarantee the order in
20063 which its function object is called).
20064 </p>
20065
20066 <p>
20067 We suggest that the standard be clarified to explicitly allow the function object
20068 passed to for_each modify its argument.</p>
20069
20070
20071
20072 <p><b>Proposed resolution:</b></p>
20073 <p>Add a nonnormative note to the Effects in 25.1.1 [alg.foreach]: If
20074 the type of 'first' satisfies the requirements of a mutable iterator,
20075 'f' may apply nonconstant functions through the dereferenced iterators
20076 passed to it.
20077 </p>
20078
20079
20080
20081 <p><b>Rationale:</b></p>
20082 <p>The LWG believes that nothing in the standard prohibits function
20083   objects that modify the sequence elements. The problem is that
20084   for_each is in a secion entitled "nonmutating algorithms", and the
20085   title may be confusing.  A nonnormative note should clarify that.</p>
20086
20087
20088
20089
20090
20091 <hr>
20092 <h3><a name="478"></a>478. Should forward iterator requirements table have a line for r-&gt;m?</h3>
20093 <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>
20094  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-07-11</p>
20095 <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>
20096 <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>
20097 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
20098 <p><b>Discussion:</b></p>
20099 <p>
20100 The Forward Iterator requirements table contains the following:
20101 </p>
20102 <pre> expression  return type         operational  precondition
20103                                   semantics
20104   ==========  ==================  ===========  ==========================
20105   a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
20106               otherwise const U&amp;
20107
20108   r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
20109 </pre>
20110
20111 <p>The second line may be unnecessary.  Paragraph 11 of
20112   [lib.iterator.requirements] says:
20113 </p>
20114
20115 <blockquote><p>
20116    In the following sections, a and b denote values of type const X, n
20117    denotes a value of the difference type Distance, u, tmp, and m
20118    denote identifiers, r denotes a value of X&amp;, t denotes a value of
20119    value type T, o denotes a value of some type that is writable to
20120    the output iterator.
20121 </p></blockquote>
20122
20123 <p>
20124 Because operators can be overloaded on an iterator's const-ness, the
20125 current requirements allow iterators to make many of the operations
20126 specified using the identifiers a and b invalid for non-const
20127 iterators.</p>
20128
20129 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
20130
20131
20132 <p><b>Proposed resolution:</b></p>
20133
20134 <p>Remove the "r-&gt;m" line from the Forward Iterator requirements
20135 table. Change</p>
20136 <blockquote><p>
20137     "const X"
20138 </p></blockquote>
20139
20140 <p> to </p>
20141
20142 <blockquote><p>
20143     "X or const X"
20144 </p></blockquote>
20145
20146 <p>in paragraph 11 of [lib.iterator.requirements].</p>
20147
20148
20149
20150
20151 <p><b>Rationale:</b></p>
20152 <p>
20153 This is a defect because it constrains an lvalue to returning a modifiable lvalue.
20154 </p>
20155
20156
20157
20158
20159
20160 <hr>
20161 <h3><a name="488"></a>488. rotate throws away useful information</h3>
20162 <p><b>Section:</b> 25.2.11 [alg.rotate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20163  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2004-11-22</p>
20164 <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>
20165 <p><b>Discussion:</b></p>
20166 <p>
20167 rotate takes 3 iterators:  first, middle and last which point into a
20168 sequence, and rearranges the sequence such that the subrange [middle,
20169 last) is now at the beginning of the sequence and the subrange [first,
20170 middle) follows.  The return type is void.
20171 </p>
20172
20173 <p>
20174 In many use cases of rotate, the client needs to know where the
20175 subrange [first, middle) starts after the rotate is performed.  This
20176 might look like:
20177 </p>
20178 <pre>  rotate(first, middle, last);
20179   Iterator i = advance(first, distance(middle, last));
20180 </pre>
20181
20182 <p>
20183 Unless the iterators are random access, the computation to find the
20184 start of the subrange [first, middle) has linear complexity.  However,
20185 it is not difficult for rotate to return this information with
20186 negligible additional computation expense.  So the client could code:
20187 </p>
20188 <pre>  Iterator i = rotate(first, middle, last);
20189 </pre>
20190
20191 <p>
20192 and the resulting program becomes significantly more efficient.
20193 </p>
20194
20195 <p>
20196 While the backwards compatibility hit with this change is not zero, it
20197 is very small (similar to that of lwg <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>), and there is
20198 a significant benefit to the change.
20199 </p>
20200
20201
20202
20203 <p><b>Proposed resolution:</b></p>
20204 <p>In 25 [algorithms] p2, change:</p>
20205
20206 <blockquote><pre>  template&lt;class ForwardIterator&gt;
20207     <del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle,
20208                 ForwardIterator last);
20209 </pre></blockquote>
20210
20211 <p>In 25.2.11 [alg.rotate], change:</p>
20212
20213 <blockquote><pre>  template&lt;class ForwardIterator&gt;
20214     <del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle,
20215                 ForwardIterator last);
20216 </pre></blockquote>
20217
20218 <p>In 25.2.11 [alg.rotate] insert a new paragraph after p1:</p>
20219
20220 <blockquote>
20221 <p><b>Returns</b>: <tt>first + (last - middle)</tt>.</p>
20222 </blockquote>
20223
20224 <p><i>[
20225 The LWG agrees with this idea, but has one quibble: we want to make
20226 sure not to give the impression that the function "advance" is
20227 actually called, just that the nth iterator is returned.  (Calling
20228 advance is observable behavior, since users can specialize it for
20229 their own iterators.)  Howard will provide wording.
20230 ]</i></p>
20231
20232
20233 <p><i>[Howard provided wording for mid-meeting-mailing Jun. 2005.]</i></p>
20234
20235
20236 <p><i>[
20237 Toronto: moved to Ready.
20238 ]</i></p>
20239
20240
20241
20242
20243
20244
20245
20246 <hr>
20247 <h3><a name="495"></a>495. Clause 22 template parameter requirements</h3>
20248 <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>
20249  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2005-01-10</p>
20250 <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>
20251 <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>
20252 <p><b>Discussion:</b></p>
20253 <p>It appears that there are no requirements specified for many of the
20254 template parameters in clause 22. It looks like this issue has never
20255 come up, except perhaps for Facet.</p>
20256
20257 <p>Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions],
20258 either, which is the wording that allows requirements on template
20259 parameters to be identified by name.</p>
20260
20261 <p>So one issue is that 17.3.2.1 [lib.type.descriptions] Should be
20262 changed to cover clause 22. A better change, which will cover us in
20263 the future, would be to say that it applies to all the library
20264 clauses. Then if a template gets added to any library clause we are
20265 covered.</p>
20266
20267 <p>charT, InputIterator, and other names with requirements defined
20268 elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix.
20269 But there are a few template arguments names which I don't think have
20270 requirements given elsewhere:</p>
20271
20272 <ul>
20273 <li>internT and externT.  The fix is to add wording saying that internT
20274 and externT must meet the same requirements as template arguments
20275 named charT.</li>
20276
20277 <li>stateT.  I'm not sure about this one. There already is some wording,
20278 but it seems a bit vague.</li>
20279
20280 <li>Intl.  [lib.locale.moneypunct.byname] The fix for this one is to
20281 rename "Intl" to "International". The name is important because other
20282 text identifies the requirements for the name International but not
20283 for Intl.</li>
20284 </ul>
20285
20286 <p><b>Proposed resolution:</b></p>
20287 <p>Change 17.3.2.1 [type.descriptions], paragraph 1, from:</p>
20288 <blockquote><p>
20289 The Requirements subclauses may describe names that are used to
20290 specify constraints on template arguments.153) These names are used in
20291 clauses 20, 23, 25, and 26 to describe the types that may be supplied
20292 as arguments by a C++ program when instantiating template components
20293 from the library.
20294 </p></blockquote>
20295 <p>to:</p>
20296 <blockquote><p>
20297 The Requirements subclauses may describe names that are used to
20298 specify constraints on template arguments.153) These names are used in
20299 library clauses to describe the types that may be supplied as
20300 arguments by a C++ program when instantiating template components from
20301 the library.
20302 </p></blockquote>
20303
20304 <p>In the front matter of class 22, locales, add:</p>
20305 <blockquote><p>
20306 Template parameter types internT and externT shall meet the
20307 requirements of charT (described in 21 [strings]).
20308 </p></blockquote>
20309
20310
20311 <p><b>Rationale:</b></p>
20312 <p>
20313  Again, a blanket clause isn't blanket enough. Also, we've got a
20314  couple of names that we don't have blanket requirement statements
20315  for. The only issue is what to do about stateT. This wording is
20316  thin, but probably adequate.</p>
20317
20318
20319
20320
20321
20322 <hr>
20323 <h3><a name="496"></a>496. Illegal use of "T" in vector&lt;bool&gt;</h3>
20324 <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>
20325  <b>Submitter:</b> richard@ex-parrot.com <b>Date:</b> 2005-02-10</p>
20326 <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>
20327 <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>
20328 <p><b>Discussion:</b></p>
20329 <p>
20330 In the synopsis of the std::vector&lt;bool&gt; specialisation in 23.2.5 [vector],
20331 the non-template assign() function has the signature</p>
20332
20333 <pre>  void assign( size_type n, const T&amp; t );
20334 </pre>
20335
20336 <p>The type, T, is not defined in this context.</p>
20337
20338
20339 <p><b>Proposed resolution:</b></p>
20340 <p>Replace "T" with "value_type".</p>
20341
20342
20343
20344
20345
20346 <hr>
20347 <h3><a name="497"></a>497. meaning of numeric_limits::traps for floating point types</h3>
20348 <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>
20349  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-03-02</p>
20350 <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>
20351 <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>
20352 <p><b>Discussion:</b></p>
20353
20354 <p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p>
20355
20356 <blockquote>
20357 <p>static const bool traps;<br>
20358 -59- true if trapping is implemented for the type.204)
20359 <br>
20360 Footnote 204: Required by LIA-1.
20361 </p>
20362 </blockquote>
20363
20364 <p>It's not clear what is meant by "is implemented" here.</p>
20365
20366 <p>
20367 In the context of floating point numbers it seems reasonable to expect
20368 to be able to use traps to determine whether a program can "safely" use
20369 infinity(), quiet_NaN(), etc., in arithmetic expressions, that is
20370 without causing a trap (i.e., on UNIX without having to worry about
20371 getting a signal). When traps is true, I would expect any of the
20372 operations in section 7 of IEEE 754 to cause a trap (and my program
20373 to get a SIGFPE). So, for example, on Alpha, I would expect traps
20374 to be true by default (unless I compiled my program with the -ieee
20375 option), false by default on most other popular architectures,
20376 including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require
20377 traps to be explicitly enabled by the program.
20378 </p>
20379
20380 <p>
20381 Another possible interpretation of p59 is that traps should be true
20382 on any implementation that supports traps regardless of whether they
20383 are enabled by default or not. I don't think such an interpretation
20384 makes the traps member very useful, even though that is how traps is
20385 implemented on several platforms. It is also the only way to implement
20386 traps on platforms that allow programs to enable and disable trapping
20387 at runtime.
20388 </p>
20389
20390
20391 <p><b>Proposed resolution:</b></p>
20392 <p>Change p59 to read:</p>
20393 <blockquote><p>True if, at program startup, there exists a value of the type that
20394   would cause an arithmetic operation using that value to trap.</p></blockquote>
20395
20396
20397 <p><b>Rationale:</b></p>
20398 <p>
20399  Real issue, since trapping can be turned on and off. Unclear what a
20400  static query can say about a dynamic issue. The real advice we should
20401  give users is to use cfenv for these sorts of queries. But this new
20402  proposed resolution is at least consistent and slightly better than
20403  nothing.</p>
20404
20405
20406
20407
20408
20409 <hr>
20410 <h3><a name="505"></a>505. Result_type in random distribution requirements</h3>
20411 <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>
20412  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
20413 <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>
20414 <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>
20415 <p><b>Discussion:</b></p>
20416 <p>
20417 Table 17: Random distribution requirements
20418 </p>
20419 <p>
20420 Row 1 requires that each random distribution provide a nested type "input_type";
20421 this type denotes the type of the values that the distribution consumes.
20422 </p>
20423 <p>
20424 Inspection of all distributions in [tr.rand.dist] reveals that each distribution
20425 provides a second typedef ("result_type") that denotes the type of the values the
20426 distribution produces when called.
20427 </p>
20428
20429
20430 <p><b>Proposed resolution:</b></p>
20431 <p>
20432 It seems to me that this is also a requirement
20433 for all distributions and should therefore be  indicated as such via a new second
20434 row to this table 17:
20435 </p>
20436 <table border="1" cellpadding="5">
20437 <tbody><tr><td>X::result_type</td><td>T</td><td>---</td><td>compile-time</td></tr>
20438 </tbody></table>
20439
20440 <p><i>[
20441 Berlin:  Voted to WP.  N1932 adopts the proposed resolution:  see Table 5 row 1.
20442 ]</i></p>
20443
20444
20445
20446
20447
20448
20449
20450 <hr>
20451 <h3><a name="507"></a>507. Missing requirement for variate_generator::operator()</h3>
20452 <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>
20453  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
20454 <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>
20455 <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>
20456 <p><b>Discussion:</b></p>
20457 <p>
20458 Paragraph 11 of [tr.rand.var] equires that the member template
20459 </p>
20460 <blockquote><pre>template&lt;class T&gt; result_type operator() (T value);
20461 </pre></blockquote>
20462 <p>
20463 return
20464 </p>
20465 <blockquote><pre>distribution()(e, value)
20466 </pre></blockquote>
20467 <p>
20468 However, not all distributions have an operator() with a corresponding signature.
20469 </p>
20470
20471 <p><i>[
20472 Berlin:  As a working group we voted in favor of N1932 which makes this moot:
20473 variate_generator has been eliminated.  Then in full committee we voted to give
20474 this issue WP status (mistakenly).
20475 ]</i></p>
20476
20477
20478
20479
20480 <p><b>Proposed resolution:</b></p>
20481 <p>
20482 We therefore  recommend that we insert the following precondition before paragraph 11:
20483 </p>
20484 <blockquote><p>
20485 Precondition:  <tt>distribution().operator()(e,value)</tt> is well-formed.
20486 </p></blockquote>
20487
20488
20489
20490
20491
20492 <hr>
20493 <h3><a name="508"></a>508. Bad parameters for ranlux64_base_01</h3>
20494 <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>
20495  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
20496 <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>
20497 <p><b>Discussion:</b></p>
20498 <p>
20499 The fifth of these engines with predefined parameters, ranlux64_base_01,
20500 appears to have an unintentional error for which there is a simple correction.
20501 The two pre-defined  subtract_with_carry_01 engines are given as:
20502 </p>
20503 <blockquote><pre>typedef subtract_with_carry_01&lt;float,  24, 10, 24&gt; ranlux_base_01;
20504 typedef subtract_with_carry_01&lt;double, 48, 10, 24&gt; ranlux64_base_01;
20505 </pre></blockquote>
20506 <p>
20507 We demonstrate below that ranlux64_base_01 fails to meet the intent of the
20508 random number generation proposal, but that the simple correction to
20509 </p>
20510 <blockquote><pre>typedef subtract_with_carry_01&lt;double, 48,  5, 12&gt; ranlux64_base_01;
20511 </pre></blockquote>
20512 <p>
20513 does meet the intent of defining well-known good parameterizations.
20514 </p>
20515 <p>
20516 The ranlux64_base_01 engine as presented fails to meet the intent for
20517 predefined engines, stated in proposal N1398 (section E):
20518 </p>
20519 <blockquote><p>
20520 In order to make good random numbers available to a large number of library
20521 users, this proposal not only defines generic random-number engines, but also
20522 provides a number of predefined well-known good parameterizations for those.
20523 </p></blockquote>
20524 <p>
20525 The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very
20526 long period and so meets this criterion.  This property makes it suitable for
20527 use in the excellent discard_block  engines defined subsequently.  The proof
20528 of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s)
20529 + 1 is prime (w, r, and s are template parameters to subtract_with_carry_01,
20530 as defined in [tr.rand.eng.sub1]).
20531 </p>
20532 <p>
20533 The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10.
20534 For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though
20535 explicit factorization  would be a challenge).  In consequence, while it is
20536 certainly possible for some seeding states that this engine would have a very
20537 long period, it is not at all "well-known" that this is the case. The intent
20538 in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy
20539 use in the physics community.  This is isomorphic to the predefined ranlux_base_01,
20540 but exploits the ability of double variables to hold (at least) 48 bits of mantissa,
20541 to deliver 48 random bits at a time rather than 24.
20542 </p>
20543
20544
20545 <p><b>Proposed resolution:</b></p>
20546 <p>
20547 To achieve this intended behavior, the correct template parameteriztion  would be:
20548 </p>
20549 <blockquote><pre>typedef subtract_with_carry_01&lt;double, 48, 5, 12&gt; ranlux64_base_01;
20550 </pre></blockquote>
20551 <p>
20552 The sequence of mantissa bits delivered by this is isomorphic (treating each
20553 double as having the  bits of two floats) to that delivered by ranlux_base_01.
20554 </p>
20555 <p>
20556 <b>References:</b>
20557 </p>
20558 <ol>
20559 <li>F. James, Comput. Phys. Commun. 60(1990) 329</li>
20560 <li>G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462</li>
20561 <li>M. Luscher, Comput. Phys. Commun. 79(1994) 100-110</li>
20562 </ol>
20563
20564 <p><i>[
20565 Berlin: Voted to WP.  N1932 adopts the proposed resolution in 26.3.5,
20566 just above paragraph 5.
20567 ]</i></p>
20568
20569
20570
20571
20572
20573
20574
20575 <hr>
20576 <h3><a name="519"></a>519. Data() undocumented</h3>
20577 <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>
20578  <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
20579 <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>
20580 <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>
20581 <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>
20582 <p><b>Discussion:</b></p>
20583 <p>
20584 <tt>array&lt;&gt;::data()</tt> is present in the class synopsis, but not documented.
20585 </p>
20586
20587
20588 <p><b>Proposed resolution:</b></p>
20589 <p>
20590 Add a new section, after 6.2.2.3:
20591 </p>
20592 <blockquote><pre>T*       data()
20593 const T* data() const;
20594 </pre></blockquote>
20595 <p>
20596 <b>Returns:</b> <tt>elems</tt>.
20597 </p>
20598 <p>
20599 Change 6.2.2.4/2 to:
20600 </p>
20601 <blockquote><p>
20602 In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value
20603 of <tt>data()</tt> is unspecified.
20604 </p></blockquote>
20605
20606
20607
20608
20609
20610 <hr>
20611 <h3><a name="520"></a>520. Result_of and pointers to data members</h3>
20612 <p><b>Section:</b> 20.5.11.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>
20613  <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
20614 <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>
20615 <p><b>Discussion:</b></p>
20616 <p>
20617 In the original proposal for binders, the return type of bind() when
20618 called with a pointer to member data as it's callable object was
20619 defined to be mem_fn(ptr); when Peter Dimov and I  unified the
20620 descriptions of the TR1 function objects we hoisted the descriptions
20621 of return types into the INVOKE pseudo-function and into result_of.
20622 Unfortunately, we left pointer to member data out of result_of, so
20623 bind doesn't have any specified behavior when called with a pointer
20624 to  member data.
20625 </p>
20626
20627
20628 <p><b>Proposed resolution:</b></p>
20629 <p><i>[
20630 Pete and Peter will provide wording.
20631 ]</i></p>
20632
20633
20634 <p>
20635 In 20.5.4 [lib.func.ret] ([tr.func.ret]) p3 add the following bullet after bullet 2:
20636 </p>
20637 <ol start="3">
20638 <li>If <tt>F</tt> is a member data pointer type <tt>R T::*</tt>, <tt>type</tt>
20639 shall be <tt><i>cv</i> R&amp;</tt> when <tt>T1</tt> is <tt><i>cv</i> U1&amp;</tt>,
20640 <tt>R</tt> otherwise.</li>
20641 </ol>
20642
20643 <p><i>[
20644 Peter provided wording.
20645 ]</i></p>
20646
20647
20648
20649
20650
20651
20652
20653 <hr>
20654 <h3><a name="521"></a>521. Garbled requirements for argument_type in reference_wrapper</h3>
20655 <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>
20656  <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
20657 <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>
20658 <p><b>Discussion:</b></p>
20659 <p>
20660 2.1.2/3, second bullet item currently says that reference_wrapper&lt;T&gt; is
20661 derived from unary_function&lt;T, R&gt; if T is:
20662 </p>
20663 <blockquote><p>
20664 a pointer to member function type with cv-qualifier cv and no arguments;
20665 the type T1 is cv T* and R is the return type of the pointer to member function;
20666 </p></blockquote>
20667 <p>
20668 The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member
20669 function. It should be a pointer to the class that T is a pointer to member of.
20670 Like this:
20671 </p>
20672 <blockquote><p>
20673 a pointer to a member function R T0::f() cv (where cv represents the member
20674 function's cv-qualifiers); the type T1 is cv T0*
20675 </p></blockquote>
20676 <p>
20677 Similarly, bullet item 2 in 2.1.2/4 should be:
20678 </p>
20679 <blockquote><p>
20680 a pointer to a member function R T0::f(T2) cv (where cv represents the member
20681 function's cv-qualifiers); the type T1 is cv T0*
20682 </p></blockquote>
20683
20684
20685 <p><b>Proposed resolution:</b></p>
20686
20687 <p>
20688 Change bullet item 2 in 2.1.2/3:
20689 </p>
20690
20691 <blockquote>
20692 <ul>
20693 <li>
20694 a pointer to member function <del>type with cv-qualifier <tt><i>cv</i></tt> and no arguments;
20695 the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and <tt>R</tt> is the return
20696 type of the pointer to member function</del> <ins><tt>R T0::f() <i>cv</i></tt>
20697 (where <tt><i>cv</i></tt> represents the member function's cv-qualifiers);
20698 the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
20699 </li>
20700 </ul>
20701 </blockquote>
20702
20703 <p>
20704 Change bullet item 2 in 2.1.2/4:
20705 </p>
20706
20707 <blockquote>
20708 <ul>
20709 <li>
20710 a pointer to member function <del>with cv-qualifier <tt><i>cv</i></tt> and taking one argument
20711 of type <tt>T2</tt>; the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and
20712 <tt>R</tt> is the return type of the pointer to member function</del>
20713 <ins><tt>R T0::f(T2) <i>cv</i></tt> (where <tt><i>cv</i></tt> represents the member
20714 function's cv-qualifiers); the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
20715 </li>
20716 </ul>
20717 </blockquote>
20718
20719
20720
20721
20722
20723
20724 <hr>
20725 <h3><a name="524"></a>524. regex named character classes and case-insensitivity don't mix</h3>
20726 <p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20727  <b>Submitter:</b> Eric Niebler <b>Date:</b> 2005-07-01</p>
20728 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re">issues</a> in [re].</p>
20729 <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>
20730 <p><b>Discussion:</b></p>
20731 <p>
20732 This defect is also being discussed on the Boost developers list. The
20733 full discussion can be found here:
20734 http://lists.boost.org/boost/2005/07/29546.php
20735 </p>
20736 <p>
20737 -- Begin original message --
20738 </p>
20739 <p>
20740 Also, I may have found another issue, closely related to the one under
20741 discussion. It regards case-insensitive matching of named character
20742 classes. The regex_traits&lt;&gt; provides two functions for working with
20743 named char classes: lookup_classname and isctype. To match a char class
20744 such as [[:alpha:]], you pass "alpha" to lookup_classname and get a
20745 bitmask. Later, you pass a char and the bitmask to isctype and get a
20746 bool yes/no answer.
20747 </p>
20748 <p>
20749 But how does case-insensitivity work in this scenario? Suppose we're
20750 doing a case-insensitive match on [[:lower:]]. It should behave as if it
20751 were [[:lower:][:upper:]], right? But there doesn't seem to be enough
20752 smarts in the regex_traits interface to do this.
20753 </p>
20754 <p>
20755 Imagine I write a traits class which recognizes [[:fubar:]], and the
20756 "fubar" char class happens to be case-sensitive. How is the regex engine
20757 to know that? And how should it do a case-insensitive match of a
20758 character against the [[:fubar:]] char class? John, can you confirm this
20759 is a legitimate problem?
20760 </p>
20761 <p>
20762 I see two options:
20763 </p>
20764 <p>
20765 1) Add a bool icase parameter to lookup_classname. Then,
20766 lookup_classname( "upper", true ) will know to return lower|upper
20767 instead of just upper.
20768 </p>
20769 <p>
20770 2) Add a isctype_nocase function
20771 </p>
20772 <p>
20773 I prefer (1) because the extra computation happens at the time the
20774 pattern is compiled rather than when it is executed.
20775 </p>
20776 <p>
20777 -- End original message --
20778 </p>
20779
20780 <p>
20781 For what it's worth, John has also expressed his preference for option
20782 (1) above.
20783 </p>
20784
20785
20786 <p><b>Proposed resolution:</b></p>
20787 <p>
20788 Adopt the proposed resolution in
20789 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
20790 </p>
20791
20792
20793 <p><i>[
20794 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
20795 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
20796 ]</i></p>
20797
20798
20799
20800
20801
20802 <hr>
20803 <h3><a name="530"></a>530. Must elements of a string be contiguous?</h3>
20804 <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>
20805  <b>Submitter:</b> Matt Austern <b>Date:</b> 2005-11-15</p>
20806 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
20807 <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>
20808 <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>
20809 <p><b>Discussion:</b></p>
20810 <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
20811    that the elements of a vector must be stored in contiguous memory.
20812    Should the same also apply to <tt>basic_string</tt>?</p>
20813
20814 <p>We almost require contiguity already. Clause 23.3.4 [multiset]
20815   defines <tt>operator[]</tt> as <tt>data()[pos]</tt>. What's missing
20816   is a similar guarantee if we access the string's elements via the
20817   iterator interface.</p>
20818
20819 <p>Given the existence of <tt>data()</tt>, and the definition of
20820   <tt>operator[]</tt> and <tt>at</tt> in terms of <tt>data</tt>,
20821   I don't believe it's possible to write a useful and standard-
20822   conforming <tt>basic_string</tt> that isn't contiguous. I'm not
20823   aware of any non-contiguous implementation. We should just require
20824   it.
20825 </p>
20826
20827
20828 <p><b>Proposed resolution:</b></p>
20829 <p>Add the following text to the end of 21.3 [basic.string],
20830 paragraph 2. </p>
20831
20832 <blockquote>
20833   <p>The characters in a string are stored contiguously, meaning that if
20834   <tt>s</tt> is a <tt>basic_string&lt;charT, Allocator&gt;</tt>, then
20835   it obeys the identity
20836   <tt>&amp;*(s.begin() + n) == &amp;*s.begin() + n</tt>
20837   for all <tt>0 &lt;= n &lt; s.size()</tt>.
20838   </p>
20839 </blockquote>
20840
20841
20842 <p><b>Rationale:</b></p>
20843 <p>
20844 Not standardizing this existing practice does not give implementors more
20845 freedom.  We thought it might a decade ago.  But the vendors have spoken
20846 both with their implementations, and with their voice at the LWG
20847 meetings.  The implementations are going to be contiguous no matter what
20848 the standard says.  So the standard might as well give string clients
20849 more design choices.
20850 </p>
20851
20852
20853
20854
20855
20856 <hr>
20857 <h3><a name="531"></a>531. array forms of unformatted input functions</h3>
20858 <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>
20859  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-11-23</p>
20860 <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>
20861 <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>
20862 <p><b>Discussion:</b></p>
20863 <p>
20864 The array forms of unformatted input functions don't seem to have well-defined
20865 semantics for zero-element arrays in a couple of cases. The affected ones
20866 (<tt>istream::get()</tt> and <tt>istream::getline()</tt>) are supposed to
20867 terminate when <tt>(n - 1)</tt> characters are stored, which obviously can
20868 never be true when <tt>(n == 0)</tt> holds to start with. See
20869 c++std-lib-16071.
20870 </p>
20871
20872
20873 <p><b>Proposed resolution:</b></p>
20874 <p>
20875 I suggest changing 27.6.1.3, p7 (<tt>istream::get()</tt>), bullet 1 to read:
20876 </p>
20877             <ul>
20878                 <li>
20879                     <tt>(n &lt; 1)</tt> is true or <tt>(n - 1)</tt> characters
20880                     are stored;
20881                 </li>
20882             </ul>
20883 <p>
20884 Change 27.6.1.3, p9:
20885 </p>
20886
20887 <blockquote><p>
20888 If the function stores no characters, it calls <tt>setstate(failbit)</tt> (which
20889 may throw <tt>ios_base::failure</tt> (27.4.4.3)).  In any case, <ins>if <tt>(n
20890 &gt; 0)</tt> is true</ins> it then stores a null character into the next
20891 successive location of the array.
20892 </p></blockquote>
20893
20894         <p>
20895
20896 and similarly p17 (<tt>istream::getline()</tt>), bullet 3 to:
20897
20898         </p>
20899             <ul>
20900                 <li>
20901                     <tt>(n &lt; 1)</tt> is true or <tt>(n - 1)</tt> characters
20902                     are stored (in which case the function calls
20903                     <tt>setstate(failbit)</tt>).
20904                 </li>
20905             </ul>
20906
20907         <p>
20908
20909 In addition, to clarify that <tt>istream::getline()</tt> must not store the
20910 terminating NUL character unless the the array has non-zero size, Robert
20911 Klarer suggests in c++std-lib-16082 to change 27.6.1.3, p20 to read:
20912
20913         </p>
20914             <blockquote><p>
20915
20916 In any case, provided <tt>(n &gt; 0)</tt> is true, it then stores a null character
20917 (using charT()) into the next successive location of the array.
20918
20919             </p></blockquote>
20920
20921 <p><i>[
20922 post-Redmond:  Pete noticed that the current resolution for <tt>get</tt> requires
20923 writing to out of bounds memory when <tt>n == 0</tt>.  Martin provided fix.
20924 ]</i></p>
20925
20926
20927
20928
20929
20930
20931
20932 <hr>
20933 <h3><a name="533"></a>533. typo in 2.2.3.10/1</h3>
20934 <p><b>Section:</b> 20.6.6.2.11 [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>
20935  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2005-11-09</p>
20936 <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>
20937 <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>
20938 <p><b>Discussion:</b></p>
20939 <p>
20940 I'm seeing something that looks like a typo. The Return of <tt>get_deleter</tt>
20941 says:
20942 </p>
20943 <blockquote><p>
20944 If <tt>*this</tt> <i>owns</i> a deleter <tt>d</tt>...
20945 </p></blockquote>
20946 <p>
20947 but <tt>get_deleter</tt> is a free function!
20948 </p>
20949
20950
20951 <p><b>Proposed resolution:</b></p>
20952 <p>
20953 Therefore, I think should be:
20954 </p>
20955 <blockquote><p>
20956 If <tt><del>*this</del> <ins>p</ins></tt> <i>owns</i> a deleter <tt>d</tt>...
20957 </p></blockquote>
20958
20959
20960
20961
20962
20963 <hr>
20964 <h3><a name="534"></a>534. Missing basic_string members</h3>
20965 <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>
20966  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2005-11-16</p>
20967 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
20968 <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>
20969 <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>
20970 <p><b>Discussion:</b></p>
20971 <p>
20972 OK, we all know std::basic_string is bloated and already has way too
20973 many members.  However, I propose it is missing 3 useful members that
20974 are often expected by users believing it is a close approximation of the
20975 container concept.  All 3 are listed in table 71 as 'optional'
20976 </p>
20977
20978 <p>
20979 i/  pop_back.
20980 </p>
20981
20982 <p>
20983 This is the one I feel most strongly about, as I only just discovered it
20984 was missing as we are switching to a more conforming standard library
20985 &lt;g&gt;
20986 </p>
20987
20988 <p>
20989 I find it particularly inconsistent to support push_back, but not
20990 pop_back.
20991 </p>
20992
20993 <p>
20994 ii/ back.
20995 </p>
20996
20997 <p>
20998 There are certainly cases where I want to examine the last character of
20999 a string before deciding to append, or to trim trailing path separators
21000 from directory names etc.  *rbegin() somehow feels inelegant.
21001 </p>
21002
21003 <p>
21004 iii/ front
21005 </p>
21006
21007 <p>
21008 This one I don't feel strongly about, but if I can get the first two,
21009 this one feels that it should be added as a 'me too' for consistency.
21010 </p>
21011
21012 <p>
21013 I believe this would be similarly useful to the data() member recently
21014 added to vector, or at() member added to the maps.
21015 </p>
21016
21017
21018 <p><b>Proposed resolution:</b></p>
21019 <p>
21020 Add the following members to definition of class template basic_string, 21.3p7
21021 </p>
21022 <blockquote><pre>void pop_back ()
21023
21024 const charT &amp; front() const
21025 charT &amp; front()
21026
21027 const charT &amp; back() const
21028 charT &amp; back()
21029 </pre></blockquote>
21030 <p>
21031 Add the following paragraphs to basic_string description
21032 </p>
21033
21034 <p>
21035 21.3.4p5
21036 </p>
21037 <blockquote>
21038 <pre>const charT &amp; front() const
21039 charT &amp; front()
21040 </pre>
21041 <p>
21042 <i>Precondition:</i> <tt>!empty()</tt>
21043 </p>
21044 <p>
21045 <i>Effects:</i> Equivalent to <tt>operator[](0)</tt>.
21046 </p>
21047 </blockquote>
21048
21049 <p>
21050 21.3.4p6
21051 </p>
21052 <blockquote>
21053 <pre>const charT &amp; back() const
21054 charT &amp; back()
21055 </pre>
21056 <p>
21057 <i>Precondition:</i> <tt>!empty()</tt>
21058 </p>
21059 <p>
21060 <i>Effects:</i> Equivalent to <tt>operator[]( size() - 1)</tt>.
21061 </p>
21062 </blockquote>
21063
21064 <p>
21065 21.3.5.5p10
21066 </p>
21067 <blockquote>
21068 <pre>void pop_back ()
21069 </pre>
21070 <p>
21071 <i>Precondition:</i> <tt>!empty()</tt>
21072 </p>
21073 <p>
21074 <i>Effects:</i> Equivalent to <tt>erase( size() - 1, 1 )</tt>.
21075 </p>
21076 </blockquote>
21077
21078 <p>
21079 Update Table 71: (optional sequence operations)
21080 Add basic_string to the list of containers for the following operations.
21081 </p>
21082 <blockquote><pre>a.front()
21083 a.back()
21084 a.push_back()
21085 a.pop_back()
21086 a[n]
21087 </pre></blockquote>
21088
21089 <p><i>[
21090 Berlin: Has support.  Alisdair provided wording.
21091 ]</i></p>
21092
21093
21094
21095
21096
21097
21098 <hr>
21099 <h3><a name="535"></a>535. std::string::swap specification poorly worded</h3>
21100 <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>
21101  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2005-12-14</p>
21102 <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>
21103 <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>
21104 <p><b>Discussion:</b></p>
21105 <p>
21106 std::string::swap currently says for effects and postcondition:
21107 </p>
21108
21109 <blockquote>
21110 <p>
21111 <i>Effects:</i> Swaps the contents of the two strings.
21112 </p>
21113
21114 <p>
21115 <i>Postcondition:</i> <tt>*this</tt> contains the characters that were in <tt><i>s</i></tt>,
21116 <tt><i>s</i></tt> contains the characters that were in <tt>*this</tt>.
21117 </p>
21118 </blockquote>
21119
21120 <p>
21121 Specifying both Effects and Postcondition seems redundant, and the postcondition
21122 needs to be made stronger. Users would be unhappy if the characters were not in
21123 the same order after the swap.
21124 </p>
21125
21126
21127 <p><b>Proposed resolution:</b></p>
21128 <blockquote>
21129 <p>
21130 <del><i>Effects:</i> Swaps the contents of the two strings.</del>
21131 </p>
21132
21133 <p>
21134 <i>Postcondition:</i> <tt>*this</tt> contains the <ins>same sequence of</ins>
21135 characters that <del>were</del> <ins>was</ins> in <tt><i>s</i></tt>,
21136 <tt><i>s</i></tt> contains the <ins>same sequence of</ins> characters that
21137 <del>were</del> <ins>was</ins> in <tt>*this</tt>.
21138 </p>
21139 </blockquote>
21140
21141
21142
21143
21144
21145 <hr>
21146 <h3><a name="537"></a>537. Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</h3>
21147 <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>
21148  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-12</p>
21149 <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>
21150 <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>
21151 <p><b>Discussion:</b></p>
21152 <p>
21153 In the most recent working draft, I'm still seeing:
21154 </p>
21155
21156 <blockquote><pre>seekg(off_type&amp; off, ios_base::seekdir dir)
21157 </pre></blockquote>
21158
21159 <p>
21160 and
21161 </p>
21162
21163 <blockquote><pre>seekp(pos_type&amp; pos)
21164
21165 seekp(off_type&amp; off, ios_base::seekdir dir)
21166 </pre></blockquote>
21167
21168 <p>
21169 that is, by reference off and pos arguments.
21170 </p>
21171
21172
21173 <p><b>Proposed resolution:</b></p>
21174 <p>
21175 After 27.6.1.3p42 change:
21176 </p>
21177
21178 <blockquote><pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
21179 </pre></blockquote>
21180
21181 <p>
21182 After 27.6.2.4p1 change:
21183 </p>
21184
21185 <blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(pos_type<del>&amp;</del> <i>pos</i>);
21186 </pre></blockquote>
21187
21188 <p>
21189 After 27.6.2.4p3 change:
21190 </p>
21191
21192 <blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
21193 </pre></blockquote>
21194
21195
21196
21197
21198
21199 <hr>
21200 <h3><a name="538"></a>538. 241 again: Does unique_copy() require CopyConstructible and Assignable?</h3>
21201 <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>
21202  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-02-09</p>
21203 <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>
21204 <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>
21205 <p><b>Discussion:</b></p>
21206 <p>
21207 I believe I botched the resolution of
21208 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">
21209 241 "Does unique_copy() require CopyConstructible and Assignable?"</a> which now
21210 has WP status.
21211 </p>
21212
21213 <p>
21214 This talks about <tt>unique_copy</tt> requirements and currently reads:
21215 </p>
21216
21217 <blockquote><p>
21218 -5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
21219 <tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
21220 shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt> shall
21221 be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
21222 requirements of forward iterator then the value type of <tt>InputIterator</tt>
21223 must be CopyConstructible (20.1.3). Otherwise CopyConstructible is not required.
21224 </p></blockquote>
21225
21226 <p>
21227 The problem (which Paolo discovered) is that when the iterators are at their
21228 most restrictive (<tt>InputIterator</tt>, <tt>OutputIterator</tt>), then we want
21229 <tt>InputIterator::value_type</tt> to be both <tt>CopyConstructible</tt> and
21230 <tt>CopyAssignable</tt> (for the most efficient implementation).  However this
21231 proposed resolution only makes it clear that it is <tt>CopyConstructible</tt>,
21232 and that one can assign from <tt>*<i>first</i></tt> to <tt>*<i>result</i></tt>.
21233 This latter requirement does not necessarily imply that you can:
21234 </p>
21235
21236 <blockquote><pre>*<i>first</i> = *<i>first</i>;
21237 </pre></blockquote>
21238
21239
21240 <p><b>Proposed resolution:</b></p>
21241 <blockquote><p>
21242 -5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
21243 <tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
21244 shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt>
21245 shall
21246 be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
21247 requirements of forward iterator then the <del>value type</del>
21248 <ins><tt>value_type</tt></ins> of <tt>InputIterator</tt>
21249 must be CopyConstructible (20.1.3) <ins>and Assignable</ins>.
21250 Otherwise CopyConstructible is not required.
21251 </p></blockquote>
21252
21253
21254
21255
21256
21257 <hr>
21258 <h3><a name="540"></a>540. shared_ptr&lt;void&gt;::operator*()</h3>
21259 <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>
21260  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-15</p>
21261 <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>
21262 <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>
21263 <p><b>Discussion:</b></p>
21264 <p>
21265 I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6
21266 that talks about the operator*() member function of shared_ptr:
21267 </p>
21268
21269 <blockquote><p>
21270   Notes: When T is void, attempting to instantiate this member function
21271   renders the program ill-formed. [Note: Instantiating shared_ptr&lt;void&gt;
21272   does not necessarily result in instantiating this member function.
21273   --end note]
21274 </p></blockquote>
21275
21276 <p>
21277 with the requirement in temp.inst, p1:
21278 </p>
21279
21280 <blockquote><p>
21281   The implicit instantiation of a class template specialization causes
21282   the implicit instantiation of the declarations, but not of the
21283   definitions...
21284 </p></blockquote>
21285
21286 <p>
21287 I assume that what the note is really trying to say is that
21288 "instantiating shared_ptr&lt;void&gt; *must not* result in instantiating
21289 this member function." That is, that this function must not be
21290 declared a member of shared_ptr&lt;void&gt;. Is my interpretation
21291 correct?
21292 </p>
21293
21294
21295 <p><b>Proposed resolution:</b></p>
21296 <p>
21297 Change 2.2.3.5p6
21298 </p>
21299
21300 <blockquote><p>
21301 -6- <del><i>Notes:</i></del> When <tt>T</tt> is <tt>void</tt>, <del>attempting to instantiate
21302 this member function renders the program ill-formed. [<i>Note:</i>
21303 Instantiating <tt>shared_ptr&lt;void&gt;</tt> does not necessarily result in
21304 instantiating this member function. <i>--end note</i>]</del> <ins>it is
21305 unspecified whether this member function is declared or not, and if so, what its
21306 return type is, except that the declaration (although not necessarily the
21307 definition) of the function shall be well-formed.</ins>
21308 </p></blockquote>
21309
21310
21311
21312
21313
21314
21315 <hr>
21316 <h3><a name="541"></a>541. shared_ptr template assignment and void</h3>
21317 <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>
21318  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-16</p>
21319 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
21320 <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>
21321 <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>
21322 <p><b>Discussion:</b></p>
21323 <p>
21324 Is the void specialization of the template assignment operator taking
21325 a shared_ptr&lt;void&gt; as an argument supposed be well-formed?
21326 </p>
21327 <p>
21328 I.e., is this snippet well-formed:
21329 </p>
21330 <blockquote><pre>shared_ptr&lt;void&gt; p;
21331 p.operator=&lt;void&gt;(p);
21332 </pre></blockquote>
21333
21334 <p>
21335 Gcc complains about auto_ptr&lt;void&gt;::operator*() returning a reference
21336 to void. I suspect it's because shared_ptr has two template assignment
21337 operators, one of which takes auto_ptr, and the auto_ptr template gets
21338 implicitly instantiated in the process of overload resolution.
21339 </p>
21340
21341 <p>
21342 The only way I see around it is to do the same trick with auto_ptr&lt;void&gt;
21343 operator*() as with the same operator in shared_ptr&lt;void&gt;.
21344 </p>
21345
21346 <p>
21347 PS Strangely enough, the EDG front end doesn't mind the code, even
21348 though in a small test case (below) I can reproduce the error with
21349 it as well.
21350 </p>
21351
21352 <blockquote><pre>template &lt;class T&gt;
21353 struct A { T&amp; operator*() { return *(T*)0; } };
21354
21355 template &lt;class T&gt;
21356 struct B {
21357     void operator= (const B&amp;) { }
21358     template &lt;class U&gt;
21359     void operator= (const B&lt;U&gt;&amp;) { }
21360     template &lt;class U&gt;
21361     void operator= (const A&lt;U&gt;&amp;) { }
21362 };
21363
21364 int main ()
21365 {
21366     B&lt;void&gt; b;
21367     b.operator=&lt;void&gt;(b);
21368 }
21369 </pre></blockquote>
21370
21371
21372 <p><b>Proposed resolution:</b></p>
21373 <p>
21374 In [lib.memory] change:
21375 </p>
21376 <blockquote><pre>template&lt;class X&gt; class auto_ptr;
21377 <ins>template&lt;&gt; class auto_ptr&lt;void&gt;;</ins>
21378 </pre></blockquote>
21379
21380 <p>
21381 In [lib.auto.ptr]/2 add the following before the last closing brace:
21382 </p>
21383
21384 <blockquote><pre>template&lt;&gt; class auto_ptr&lt;void&gt;
21385 {
21386 public:
21387     typedef void element_type;
21388 };
21389 </pre></blockquote>
21390
21391
21392
21393
21394
21395
21396 <hr>
21397 <h3><a name="542"></a>542. shared_ptr observers</h3>
21398 <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>
21399  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-18</p>
21400 <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>
21401 <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>
21402 <p><b>Discussion:</b></p>
21403 <p>
21404 Peter Dimov wrote:
21405 To: C++ libraries mailing list
21406 Message c++std-lib-15614
21407 [...]
21408 The intent is for both use_count() and unique() to work in a threaded environment.
21409 They are intrinsically prone to race conditions, but they never return garbage.
21410 </p>
21411
21412 <p>
21413 This is a crucial piece of information that I really wish were
21414 captured in the text. Having this in a non-normative note would
21415 have made everything crystal clear to me and probably stopped
21416 me from ever starting this discussion :) Instead, the sentence
21417 in p12 "use only for debugging and testing purposes, not for
21418 production code" very strongly suggests that implementations
21419 can and even are encouraged to return garbage (when threads
21420 are involved) for performance reasons.
21421 </p>
21422 <p>
21423 How about adding an informative note along these lines:
21424 </p>
21425 <blockquote><p>
21426   Note: Implementations are encouraged to provide well-defined
21427   behavior for use_count() and unique() even in the presence of
21428   multiple threads.
21429 </p></blockquote>
21430 <p>
21431 I don't necessarily insist on the exact wording, just that we
21432 capture the intent.
21433 </p>
21434
21435
21436 <p><b>Proposed resolution:</b></p>
21437 <p>
21438 Change 20.6.6.2.5 [util.smartptr.shared.obs] p12:
21439 </p>
21440 <blockquote><p>
21441 [<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
21442 debugging and testing purposes, not for production code.</del> --<i>end note</i>]
21443 </p></blockquote>
21444
21445 <p>
21446 Change 20.6.6.3.5 [util.smartptr.weak.obs] p3:
21447 </p>
21448 <blockquote><p>
21449 [<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
21450 debugging and testing purposes, not for production code.</del> --<i>end note</i>]
21451 </p></blockquote>
21452
21453
21454
21455
21456
21457 <hr>
21458 <h3><a name="543"></a>543. valarray slice default constructor</h3>
21459 <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>
21460  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2005-11-03</p>
21461 <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>
21462 <p><b>Discussion:</b></p>
21463 <p>
21464 If one explicitly constructs a slice or glice with the default
21465 constructor, does the standard require this slice to have any usable
21466 state?  It says "creates a slice which specifies no elements", which
21467 could be interpreted two ways:
21468 </p>
21469 <ol>
21470 <li>There are no elements to which the slice refers (i.e. undefined).</li>
21471 <li>The slice specifies an array with no elements in it (i.e. defined).</li>
21472 </ol>
21473 <p>
21474 Here is a bit of code to illustrate:
21475 </p>
21476 <blockquote><pre>#include &lt;iostream&gt;
21477 #include &lt;valarray&gt;
21478
21479 int main()
21480 {
21481     std::valarray&lt;int&gt; v(10);
21482     std::valarray&lt;int&gt; v2 = v[std::slice()];
21483     std::cout &lt;&lt; "v[slice()].size() = " &lt;&lt; v2.size() &lt;&lt; '\n';
21484 }
21485 </pre></blockquote>
21486
21487 <p>
21488 Is the behavior undefined?  Or should the output be:
21489 </p>
21490
21491 <blockquote><pre>v[slice()].size() = 0
21492 </pre></blockquote>
21493
21494 <p>
21495 There is a similar question and wording for gslice at 26.3.6.1p1.
21496 </p>
21497
21498
21499 <p><b>Proposed resolution:</b></p>
21500
21501 <p><i>[Martin suggests removing the second sentence in 26.5.4.1 [cons.slice] as well.]</i></p>
21502
21503
21504 <p>
21505 Change 26.5.4.1 [cons.slice]:
21506 </p>
21507
21508 <blockquote><p>
21509 1 - <del>The default constructor for <tt>slice</tt> creates a <tt>slice</tt>
21510 which specifies no elements.</del> <ins>The default constructor is equivalent to
21511 <tt>slice(0, 0, 0)</tt>.</ins> A default constructor is provided only to permit
21512 the declaration of arrays of slices. The constructor with arguments for a slice
21513 takes a start, length, and stride parameter.
21514 </p></blockquote>
21515
21516 <p>
21517 Change 26.5.6.1 [gslice.cons]:
21518 </p>
21519
21520 <blockquote><p>
21521 1 - <del>The default constructor creates a <tt>gslice</tt> which specifies no
21522 elements.</del> <ins>The default constructor is equivalent to <tt>gslice(0,
21523 valarray&lt;size_t&gt;(), valarray&lt;size_t&gt;())</tt>.</ins> The constructor
21524 with arguments builds a <tt>gslice</tt> based on a specification of start,
21525 lengths, and strides, as explained in the previous section.
21526 </p></blockquote>
21527
21528
21529
21530
21531
21532
21533 <hr>
21534 <h3><a name="545"></a>545. When is a deleter deleted?</h3>
21535 <p><b>Section:</b> 20.6.6.2.11 [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>
21536  <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
21537 <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>
21538 <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>
21539 <p><b>Discussion:</b></p>
21540 <p>
21541 The description of ~shared_ptr doesn't say when the shared_ptr's deleter, if
21542 any, is destroyed. In principle there are two possibilities: it is destroyed
21543 unconditionally whenever ~shared_ptr is executed (which, from an implementation
21544 standpoint, means that the deleter is copied whenever the shared_ptr is copied),
21545 or it is destroyed immediately after the owned pointer is destroyed (which, from
21546 an implementation standpoint, means that the deleter object is shared between
21547 instances). We should say which it is.
21548 </p>
21549
21550
21551 <p><b>Proposed resolution:</b></p>
21552 <p>
21553 Add after the first sentence of 20.6.6.2.11 [util.smartptr.getdeleter]/1:
21554 </p>
21555 <blockquote>
21556 <p>
21557 The returned pointer remains valid as long as there exists a <tt>shared_ptr</tt> instance
21558 that owns <tt><i>d</i></tt>.
21559 </p>
21560 <p>
21561 [<i>Note:</i> it is unspecified whether the pointer remains valid longer than that.
21562 This can happen if the implementation doesn't destroy the deleter until all
21563 <tt>weak_ptr</tt> instances in the ownership group are destroyed. <i>-- end note</i>]
21564 </p>
21565 </blockquote>
21566
21567
21568
21569
21570
21571 <hr>
21572 <h3><a name="551"></a>551. &lt;ccomplex&gt;</h3>
21573 <p><b>Section:</b> 26.3.11 [cmplxh], TR1 8.3 [tr.c99.cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21574  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-23</p>
21575 <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>
21576 <p><b>Discussion:</b></p>
21577 <p>
21578 Previously xxx.h was parsable by C++.  But in the case of C99's &lt;complex.h&gt;
21579 it isn't.  Otherwise we could model it just like &lt;string.h&gt;, &lt;cstring&gt;, &lt;string&gt;:
21580 </p>
21581
21582 <ul>
21583 <li>&lt;string&gt;   : C++ API in namespace std</li>
21584 <li>&lt;cstring&gt;  : C API in namespace std</li>
21585 <li>&lt;string.h&gt; : C API in global namespace</li>
21586 </ul>
21587
21588 <p>
21589 In the case of C's complex, the C API won't compile in C++.  So we have:
21590 </p>
21591
21592 <ul>
21593 <li>&lt;complex&gt;   : C++ API in namespace std</li>
21594 <li>&lt;ccomplex&gt;  : ?</li>
21595 <li>&lt;complex.h&gt; : ?</li>
21596 </ul>
21597
21598 <p>
21599 The ? can't refer to the C API.  TR1 currently says:
21600 </p>
21601
21602 <ul>
21603 <li>&lt;complex&gt;   : C++ API in namespace std</li>
21604 <li>&lt;ccomplex&gt;  : C++ API in namespace std</li>
21605 <li>&lt;complex.h&gt; : C++ API in global namespace</li>
21606 </ul>
21607
21608
21609
21610 <p><b>Proposed resolution:</b></p>
21611 <p>
21612 Change 26.3.11 [cmplxh]:
21613 </p>
21614
21615 <blockquote>
21616 <p>
21617 The header behaves as if it includes the header
21618 <tt>&lt;ccomplex&gt;</tt><ins>.</ins><del>, and provides sufficient using
21619 declarations to declare in the global namespace all function and type names
21620 declared or defined in the neader <tt>&lt;complex&gt;</tt>.</del>
21621 <ins>[<i>Note:</i> <tt>&lt;complex.h&gt;</tt> does not promote any interface
21622 into the global namespace as there is no C interface to promote. <i>--end
21623 note</i>]</ins>
21624 </p>
21625 </blockquote>
21626
21627
21628
21629
21630
21631
21632 <hr>
21633 <h3><a name="552"></a>552. random_shuffle and its generator</h3>
21634 <p><b>Section:</b> 25.2.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21635  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-01-25</p>
21636 <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>
21637 <p><b>Discussion:</b></p>
21638 <p>
21639 ...is specified to shuffle its range by calling swap but not how
21640 (or even that) it's supposed to use the RandomNumberGenerator
21641 argument passed to it.
21642 </p>
21643 <p>
21644 Shouldn't we require that the generator object actually be used
21645 by the algorithm to obtain a series of random numbers and specify
21646 how many times its operator() should be invoked by the algorithm?
21647 </p>
21648
21649 <p>
21650 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
21651 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
21652 for some further discussion.
21653 </p>
21654
21655
21656
21657 <p><b>Proposed resolution:</b></p>
21658 <p>
21659 Adopt the proposed resolution in
21660 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
21661 </p>
21662
21663
21664 <p><i>[
21665 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
21666 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
21667 ]</i></p>
21668
21669
21670
21671
21672
21673 <hr>
21674 <h3><a name="559"></a>559. numeric_limits&lt;const T&gt;</h3>
21675 <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>
21676  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-19</p>
21677 <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>
21678 <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>
21679 <p><b>Discussion:</b></p>
21680         <p>
21681
21682 18.2.1 [limits], p2 requires implementations  to provide specializations of the
21683 <code>numeric_limits</code> template for  each scalar type. While this
21684 could be interepreted to include cv-qualified forms of such types such
21685 an  interepretation   is  not  reflected   in  the  synopsis   of  the
21686 <code>&lt;limits&gt;</code> header.
21687
21688         </p>
21689         <p>
21690
21691 The absence  of specializations of the template  on cv-qualified forms
21692 of  fundamental types  makes <code>numeric_limits</code>  difficult to
21693 use in generic  code where the constness (or volatility)  of a type is
21694 not  always  immediately  apparent.  In  such  contexts,  the  primary
21695 template  ends   up  being   instantiated  instead  of   the  provided
21696 specialization, typically yielding unexpected behavior.
21697
21698         </p>
21699         <p>
21700
21701 Require   that  specializations   of   <code>numeric_limits</code>  on
21702 cv-qualified fundamental types have the same semantics as those on the
21703 unqualifed forms of the same types.
21704
21705         </p>
21706
21707
21708 <p><b>Proposed resolution:</b></p>
21709         <p>
21710
21711 Add  to  the   synopsis  of  the  <code>&lt;limits&gt;</code>  header,
21712 immediately  below  the  declaration  of  the  primary  template,  the
21713 following:
21714 </p>
21715
21716 <pre>
21717 template &lt;class T&gt; class numeric_limits&lt;const T&gt;;
21718 template &lt;class T&gt; class numeric_limits&lt;volatile T&gt;;
21719 template &lt;class T&gt; class numeric_limits&lt;const volatile T&gt;;
21720
21721 </pre>
21722
21723         <p>
21724
21725 Add  a new paragraph  to the  end of  18.2.1.1 [numeric.limits], with  the following
21726 text:
21727
21728         </p>
21729         <p>
21730
21731 -new-para- The  value of each member  of a <code>numeric_limits</code>
21732 specialization on a  cv-qualified T is equal to the  value of the same
21733 member of <code>numeric_limits&lt;T&gt;</code>.
21734
21735         </p>
21736
21737 <p><i>[
21738 Portland: Martin will clarify that user-defined types get cv-specializations
21739 automatically.
21740 ]</i></p>
21741
21742
21743
21744
21745
21746
21747
21748 <hr>
21749 <h3><a name="566"></a>566. array forms of unformatted input function undefined for zero-element arrays</h3>
21750 <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>
21751  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
21752 <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>
21753 <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>
21754 <p><b>Discussion:</b></p>
21755         <p>
21756
21757 The array forms of unformatted input functions don't have well-defined
21758 semantics for zero-element  arrays in a couple of  cases. The affected
21759 ones (<tt>istream::get()</tt> and  <tt>getline()</tt>) are supposed to
21760 terminate when <tt>(n - 1)</tt> characters are stored, which obviously
21761 can never be true when <tt>(n == 0)</tt> to start with.
21762
21763         </p>
21764
21765
21766 <p><b>Proposed resolution:</b></p>
21767         <p>
21768
21769 I  propose  the following  changes  (references  are  relative to  the
21770 Working Draft (document N1804).
21771
21772         </p>
21773         <p>
21774
21775 Change 27.6.1.3, p8 (<tt>istream::get()</tt>), bullet 1 as follows:
21776
21777         </p>
21778         <blockquote>
21779             <p>
21780
21781 <ins>if  <tt>(n  &lt; 1)</tt>  is  true  or  </ins> <tt>(n  -  1)</tt>
21782 characters are stored;
21783
21784             </p>
21785         </blockquote>
21786         <p>
21787
21788 Similarly, change  27.6.1.3, p18 (<tt>istream::getline()</tt>), bullet
21789 3 as follows:
21790
21791         </p>
21792         <blockquote>
21793             <p>
21794
21795 <ins><tt>(n &lt; 1)</tt> is  true or </ins><tt>(n - 1)</tt> characters
21796 are     stored     (in    which     case     the    function     calls
21797 <tt>setstate(failbit)</tt>).
21798
21799             </p>
21800         </blockquote>
21801         <p>
21802
21803 Finally, change p21 as follows:
21804
21805         </p>
21806         <blockquote>
21807             <p>
21808
21809 In any  case, <ins>provided  <tt>(n &gt; 0)</tt>  is true,  </ins>it then
21810 stores  a null  character  (using charT())  into  the next  successive
21811 location of the array.
21812
21813             </p>
21814         </blockquote>
21815
21816
21817
21818
21819
21820 <hr>
21821 <h3><a name="575"></a>575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions</h3>
21822 <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>
21823  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-04-23</p>
21824 <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>
21825 <p><b>Discussion:</b></p>
21826 <p>
21827 [tr.util.smartptr.shared.dest] says in its second bullet:
21828 </p>
21829
21830 <p>
21831 "If *this shares ownership with another shared_ptr instance (use_count() &gt; 1),
21832 decrements that instance's use count."
21833 </p>
21834
21835 <p>
21836 The problem with this formulation is that it presupposes the existence of an
21837 "use count" variable that can be decremented and that is part of the state of a
21838 shared_ptr instance (because of the "that instance's use count".)
21839 </p>
21840
21841 <p>
21842 This is contrary to the spirit of the rest of the specification that carefully
21843 avoids to require an use count variable. Instead, use_count() is specified to
21844 return a value, a number of instances.
21845 </p>
21846
21847 <p>
21848 In multithreaded code, the usual implicit assumption is that a shared variable
21849 should not be accessed by more than one thread without explicit synchronization,
21850 and by introducing the concept of an "use count" variable, the current wording
21851 implies that two shared_ptr instances that share ownership cannot be destroyed
21852 simultaneously.
21853 </p>
21854
21855 <p>
21856 In addition, if we allow the interpretation that an use count variable is part
21857 of shared_ptr's state, this would lead to other undesirable consequences WRT
21858 multiple threads. For example,
21859 </p>
21860
21861 <blockquote><pre>p1 = p2;
21862 </pre></blockquote>
21863
21864 <p>
21865 would now visibly modify the state of p2, a "write" operation, requiring a lock.
21866 </p>
21867
21868
21869 <p><b>Proposed resolution:</b></p>
21870 <p>
21871 Change the first two bullets of [lib.util.smartptr.shared.dest]/1 to:
21872 </p>
21873
21874 <blockquote>
21875 <ul>
21876 <li>If <tt>*this</tt> is <i>empty</i> <ins>or shares ownership with another
21877 <tt>shared_ptr</tt> instance (<tt>use_count() &gt; 1</tt>)</ins>, there are no side effects.</li>
21878 <li><del>If <tt>*this</tt> <i>shares ownership</i> with another <tt>shared_ptr</tt> instance
21879 (<tt>use_count() &gt; 1</tt>), decrements that instance's use count.</del></li>
21880 </ul>
21881 </blockquote>
21882
21883 <p>
21884 Add the following paragraph after [lib.util.smartptr.shared.dest]/1:
21885 </p>
21886
21887 <blockquote><p>
21888 [<i>Note:</i> since the destruction of <tt>*this</tt> decreases the number of instances in
21889 <tt>*this</tt>'s ownership group by one, all <tt>shared_ptr</tt> instances that share ownership
21890 with <tt>*this</tt> will report an <tt>use_count()</tt> that is one lower than its previous value
21891 after <tt>*this</tt> is destroyed. <i>--end note</i>]
21892 </p></blockquote>
21893
21894
21895
21896
21897
21898 <hr>
21899 <h3><a name="576"></a>576. find_first_of is overconstrained</h3>
21900 <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>
21901  <b>Submitter:</b> Doug Gregor <b>Date:</b> 2006-04-25</p>
21902 <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>
21903 <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>
21904 <p><b>Discussion:</b></p>
21905 <p>
21906 In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to
21907 find_first_of are specified to require Forward Iterators, as follows:
21908 </p>
21909
21910 <blockquote><pre>template&lt;class ForwardIterator1, class ForwardIterator2&gt;
21911   ForwardIterator1
21912   find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
21913                         ForwardIterator2 first2, ForwardIterator2 last2);
21914 template&lt;class ForwardIterator1, class ForwardIterator2,
21915                   class BinaryPredicate&gt;
21916 ForwardIterator1
21917   find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
21918                          ForwardIterator2 first2, ForwardIterator2 last2,
21919                         BinaryPredicate pred);
21920 </pre></blockquote>
21921
21922 <p>
21923 However, ForwardIterator1 need not actually be a Forward Iterator; an Input
21924 Iterator suffices, because we do not need the multi-pass property of the Forward
21925 Iterator or a true reference.
21926 </p>
21927
21928
21929 <p><b>Proposed resolution:</b></p>
21930 <p>
21931 Change the declarations of <tt>find_first_of</tt> to:
21932 </p>
21933
21934 <blockquote><pre>template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2&gt;
21935   <del>ForwardIterator1</del><ins>InputIterator1</ins>
21936   find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
21937                         ForwardIterator2 first2, ForwardIterator2 last2);
21938 template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2,
21939                   class BinaryPredicate&gt;
21940 <del>ForwardIterator1</del><ins>InputIterator1</ins>
21941   find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
21942                          ForwardIterator2 first2, ForwardIterator2 last2,
21943                         BinaryPredicate pred);
21944 </pre></blockquote>
21945
21946
21947
21948
21949
21950
21951 <hr>
21952 <h3><a name="577"></a>577. upper_bound(first, last, ...) cannot return last</h3>
21953 <p><b>Section:</b> 25.3.3.2 [upper.bound] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21954  <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 2006-05-03</p>
21955 <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>
21956 <p><b>Discussion:</b></p>
21957 <p>
21958 ISO/IEC 14882:2003 says:
21959 </p>
21960
21961 <blockquote>
21962 <p>
21963 25.3.3.2 upper_bound
21964 </p>
21965 <p>
21966 <i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
21967 <tt>[<i>first</i>, <i>last</i>)</tt> such that
21968 for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
21969 conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
21970 </p>
21971 </blockquote>
21972
21973 <p>
21974 From the description above, upper_bound cannot return last, since it's
21975 not in the interval [first, last). This seems to be a typo, because if
21976 value is greater than or equal to any other values in the range, or if
21977 the range is empty, returning last seems to be the intended behaviour.
21978 The corresponding interval for lower_bound is also [first, last].
21979 </p>
21980
21981
21982 <p><b>Proposed resolution:</b></p>
21983 <p>
21984 Change [lib.upper.bound]:
21985 </p>
21986
21987 <blockquote>
21988 <p>
21989 <i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
21990 <tt>[<i>first</i>, <i>last</i><del>)</del><ins>]</ins></tt> such that
21991 for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
21992 conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
21993 </p>
21994 </blockquote>
21995
21996
21997
21998
21999
22000
22001 <hr>
22002 <h3><a name="578"></a>578. purpose of hint to allocator::allocate()</h3>
22003 <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>
22004  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-17</p>
22005 <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>
22006 <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>
22007 <p><b>Discussion:</b></p>
22008         <p>
22009
22010 The     description    of     the     allocator    member     function
22011 <code>allocate()</code>  requires  that  the <i>hint</i>  argument  be
22012 either 0 or a  value previously returned from <code>allocate()</code>.
22013 Footnote 227 further suggests that  containers may pass the address of
22014 an adjacent element as this argument.
22015
22016         </p>
22017         <p>
22018
22019 I  believe  that  either  the  footnote  is  wrong  or  the  normative
22020 requirement that  the argument be  a value previously returned  from a
22021 call to  <code>allocate()</code> is wrong. The latter  is supported by
22022 the resolution  to issue 20-004 proposed in  c++std-lib-3736 by Nathan
22023 Myers. In addition,  the <i>hint</i> is an ordinary  void* and not the
22024 <code>pointer</code>  type returned  by  <code>allocate()</code>, with
22025 the  two  types potentially  being  incompatible  and the  requirement
22026 impossible to satisfy.
22027
22028         </p>
22029         <p>
22030
22031 See also c++std-lib-14323 for some  more context on where this came up
22032 (again).
22033
22034         </p>
22035
22036
22037     <p><b>Proposed resolution:</b></p>
22038         <p>
22039
22040 Remove  the requirement  in  20.6.1.1, p4  that  the hint  be a  value
22041 previously returned from <code>allocate()</code>. Specifically, change
22042 the paragraph as follows:
22043
22044         </p>
22045 <p>
22046 <del><i>Requires</i>: <i>hint</i> either 0 or previously obtained  from  member
22047 <code>allocate</code>  and  not  yet passed  to member  <code>deallocate</code>.
22048 The value hint may be used by an implementation to help improve performance
22049 <sup>223)</sup>.</del> <ins>[<i>Note:</i> The value <i>hint</i> may be used by an
22050 implementation to help improve performance. -- <i>end note</i>]</ins>
22051 </p>
22052 <blockquote><p>
22053 <del>[Footnote: <sup>223)</sup>In a container member function, the address of an
22054 adjacent element is often a good choice to pass for this argument.</del>
22055 </p></blockquote>
22056
22057
22058
22059
22060 <hr>
22061 <h3><a name="586"></a>586. string inserter not a formatted function</h3>
22062 <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>
22063  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-22</p>
22064 <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>
22065 <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>
22066 <p><b>Discussion:</b></p>
22067         <p>
22068
22069 Section  and paragraph  numbers  in  this paper  are  relative to  the
22070 working draft document number N2009 from 4/21/2006.
22071
22072         </p>
22073
22074         <p>
22075
22076 The  <code>basic_string</code> extractor  in 21.3.7.9,  p1  is clearly
22077 required  to  behave  as  a   formatted  input  function,  as  is  the
22078 <code>std::getline()</code> overload for string described in p7.
22079
22080         </p>
22081         <p>
22082
22083 However, the <code>basic_string</code> inserter described in p5 of the
22084 same section has no such requirement. This has implications on how the
22085 operator  responds  to  exceptions thrown  from  <code>xsputn()</code>
22086 (formatted  output functions are  required to  set <code>badbit</code>
22087 and swallow  the exception unless  <code>badbit</code> is also  set in
22088 <code>exceptions()</code>; the  string inserter doesn't  have any such
22089 requirement).
22090
22091         </p>
22092         <p>
22093
22094 I don't  see anything in the  spec for the string  inserter that would
22095 justify requiring  it to treat  exceptions differently from  all other
22096 similar operators. (If it did, I think it should be made this explicit
22097 by saying  that the  operator "does not  behave as a  formatted output
22098 function" as has been made customary by the adoption of the resolution
22099 of issue 60).
22100
22101         </p>
22102
22103
22104     <p><b>Proposed resolution:</b></p>
22105         <p>
22106
22107 I propose to change the Effects clause in 21.3.7.9, p5, as follows:
22108
22109         </p>
22110             <blockquote>
22111         <p>
22112
22113 <i>Effects</i>: <del>Begins by constructing a  sentry object k as if k
22114 were    constructed    by    typename    <code>basic_ostream&lt;charT,
22115 traits&gt;::sentry   k   (os)</code>.    If  <code>bool(k)</code>   is
22116 <code>true</code>, </del><ins>Behaves  as a formatted  output function
22117 (27.6.2.5.1).   After constructing  a  <code>sentry</code> object,  if
22118 this  object returns <code>true</code>  when converted  to a  value of
22119 type   <code>bool</code>,   determines   padding   as   described   in
22120 22.2.2.2.2</ins>,  then inserts the  resulting sequence  of characters
22121 <code><i>seq</i></code> as if by calling <code>os.rdbuf()-&gt;sputn(seq ,
22122 n)</code>,    where   <code><i>n</i></code>    is   the    larger   of
22123 <code>os.width()</code>   and   <code>str.size()</code>;  then   calls
22124 <code>os.width(0)</code>.  <del>If  the  call  to sputn  fails,  calls
22125 <code>os.setstate(ios_base::failbit)</code>.</del>
22126
22127         </p>
22128             </blockquote>
22129         <p>
22130
22131 This proposed  resilution assumes the  resolution of issue  394 (i.e.,
22132 that   all   formatted   output   functions  are   required   to   set
22133 <code>ios_base::badbit</code>  in response  to any  kind  of streambuf
22134 failure),   and   implicitly   assumes   that  a   return   value   of
22135 <code>sputn(seq,  <i>n</i>)</code>  other  than  <code><i>n</i></code>
22136 indicates a failure.
22137
22138         </p>
22139
22140
22141
22142
22143 <hr>
22144 <h3><a name="589"></a>589. Requirements on iterators of member template functions of containers</h3>
22145 <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>
22146  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-08-02</p>
22147 <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>
22148 <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>
22149 <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>
22150 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a></p>
22151 <p><b>Discussion:</b></p>
22152 <p>
22153 There appears to be no requirements on the InputIterators used in sequences in 23.1.1 in
22154 terms of their value_type, and the requirements in 23.1.2 appear to be overly strict
22155 (requires InputIterator::value_type be the same type as the container's value_type).
22156 </p>
22157
22158
22159 <p><b>Proposed resolution:</b></p>
22160 <p>
22161 Change 23.1.1 p3:
22162 </p>
22163
22164 <blockquote><p>
22165 In Tables 82 and 83, <tt>X</tt> denotes a sequence class, <tt>a</tt> denotes a
22166 value of <tt>X</tt>, <tt>i</tt> and <tt>j</tt> denote iterators satisfying input
22167 iterator requirements <ins>and refer to elements <ins>implicitly
22168 convertible to</ins> <tt>value_type</tt></ins>, <tt>[i, j)</tt> denotes a valid
22169 range, <tt>n</tt> denotes a value of <tt>X::size_type</tt>, <tt>p</tt> denotes a
22170 valid iterator to <tt>a</tt>, <tt>q</tt> denotes a valid dereferenceable
22171 iterator to <tt>a</tt>, <tt>[q1, q2)</tt> denotes a valid range in <tt>a</tt>,
22172 and <tt>t</tt> denotes a value of <tt>X::value_type</tt>.
22173 </p></blockquote>
22174
22175 <p>
22176 Change 23.1.2 p7:
22177 </p>
22178
22179 <blockquote><p>
22180 In Table 84, <tt>X</tt> is an associative container class, <tt>a</tt> is a value
22181 of <tt>X</tt>, <tt>a_uniq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
22182 unique keys, and <tt>a_eq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
22183 multiple keys, <tt>i</tt> and <tt>j</tt> satisfy input iterator requirements and
22184 refer to elements <del>of</del> <ins>implicitly convertible to</ins>
22185 <tt>value_type</tt>, <tt>[i, j)</tt> is a valid range, <tt>p</tt> is a valid
22186 iterator to <tt>a</tt>, <tt>q</tt> is a valid dereferenceable iterator to
22187 <tt>a</tt>, <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <tt>t</tt> is a
22188 value of <tt>X::value_type</tt>, <tt>k</tt> is a value of <tt>X::key_type</tt>
22189 and <tt>c</tt> is a value of type <tt>X::key_compare</tt>.
22190 </p></blockquote>
22191
22192
22193
22194 <p><b>Rationale:</b></p>
22195 <p>
22196 Concepts will probably come in and rewrite this section anyway.  But just in case it is
22197 easy to fix this up as a safety net and as a clear statement of intent.
22198 </p>
22199
22200
22201
22202
22203
22204 <hr>
22205 <h3><a name="593"></a>593. __STDC_CONSTANT_MACROS</h3>
22206 <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>
22207  <b>Submitter:</b> Walter Brown <b>Date:</b> 2006-08-28</p>
22208 <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>
22209 <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>
22210 <p><b>Discussion:</b></p>
22211 <p>
22212 Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers
22213 &lt;cstdint&gt; and &lt;stdint.h&gt;.  These are of course based on the C99 header
22214 &lt;stdint.h&gt;, and were part of TR1.
22215 </p>
22216
22217 <p>
22218 Per 18.3.1/1, these headers define a number of macros and function macros.
22219 While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99
22220 footnotes do mention __STDC_CONSTANT_MACROS.  Further, 18.3.1/2 states that "The
22221 header defines all ... macros the same as C99 subclause 7.18."
22222 </p>
22223
22224 <p>
22225 Therefore, if I wish to have the above-referenced macros and function macros
22226 defined, must I #define __STDC_CONSTANT_MACROS before I #include &lt;cstdint&gt;, or
22227 does the C++ header define these macros/function macros unconditionally?
22228 </p>
22229
22230
22231 <p><b>Proposed resolution:</b></p>
22232 <p>
22233 To put this issue to rest for C++0X, I propose the following addition to
22234 18.3.1/2 of the Working Paper N2009:
22235 </p>
22236
22237 <blockquote><p>
22238 [Note: The macros defined by &lt;cstdint&gt; are provided unconditionally: in
22239 particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
22240 (mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note]
22241 </p></blockquote>
22242
22243
22244
22245
22246
22247 <hr>
22248 <h3><a name="598"></a>598. Decimal: Conversion to integral should truncate, not round.</h3>
22249 <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>
22250  <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
22251 <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>
22252 <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>
22253 <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>
22254 <p><b>Discussion:</b></p>
22255
22256 <p>
22257 In a private email, Daniel writes:
22258 </p>
22259 <blockquote>
22260 <p>
22261 I would like to
22262 ask, what where the reason for the decision to
22263 define the semantics of the integral conversion of the decimal types, namely
22264 </p>
22265 <pre>"operator long long() const;
22266
22267      Returns: Returns the result of the
22268 conversion of *this to the type long long, as if
22269 performed by the expression llrounddXX(*this)."
22270 </pre>
22271 <p>
22272 where XX stands for either 32, 64, or 128,
22273 corresponding to the proper decimal type. The
22274 exact meaning of llrounddXX is not given in that
22275 paper, so I compared it to the corresponding
22276 definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2:
22277 </p>
22278 <p>
22279 "The lround and llround functions round their
22280 argument to the nearest integer value,
22281 rounding halfway cases away from zero, regardless
22282 of the current rounding direction. [..]"
22283 </p>
22284 <p>
22285 Now considering the fact that integral conversion
22286 of the usual floating-point types ("4.9
22287 Floating-integral conversions") has truncation
22288 semantic I wonder why this conversion behaviour
22289 has not been transferred for the decimal types.
22290 </p>
22291 </blockquote>
22292 <p>
22293 Robert comments:
22294 </p>
22295 <p>
22296 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>.
22297 </p>
22298
22299
22300
22301 <p><b>Proposed resolution:</b></p>
22302 <p>
22303 Change the <b>Returns:</b> clause in 3.2.2.4 to:
22304 </p>
22305 <blockquote><p>
22306 <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>.
22307 </p></blockquote>
22308 <p>
22309 Change the <b>Returns:</b> clause in 3.2.3.4 to:
22310 </p>
22311 <blockquote><p>
22312 <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> is in effect</ins>.
22313 </p></blockquote>
22314 <p>
22315 Change the <b>Returns:</b> clause in 3.2.4.4 to:
22316 </p>
22317 <blockquote><p>
22318 <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 <del><code>llroundd64(*this)</code></del> <ins><code>llroundd128(*this)</code> while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
22319 </p></blockquote>
22320
22321
22322
22323
22324
22325
22326 <hr>
22327 <h3><a name="599"></a>599. Decimal: Say "octets" instead of "bytes."</h3>
22328 <p><b>Section:</b> TRDecimal 3.1 [trdec.types.encodings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
22329  <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
22330 <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>
22331 <p><b>Discussion:</b></p>
22332 <p>
22333 Daniel writes in a private email:
22334 </p>
22335
22336 <blockquote>
22337 <p>
22338 - 3.1 'Decimal type encodings' says in its note:
22339 </p>
22340 <pre>"this implies that
22341 sizeof(std::decimal::decimal32) == 4,
22342 sizeof(std::decimal::decimal64) == 8, and
22343 sizeof(std::decimal::decimal128) == 16."
22344 </pre>
22345 <p>
22346 This is a wrong assertion, because the definition
22347 of 'byte' in 1.7 'The C+ + memory model' of ISO
22348 14882 (2nd edition) does not specify that a byte
22349 must be necessarily 8 bits large, which would be
22350 necessary to compare with the specified bit sizes
22351 of the types decimal32, decimal64, and decimal128.
22352 </p>
22353 </blockquote>
22354
22355
22356 <p><b>Proposed resolution:</b></p>
22357 <p>
22358 Change 3.1 as follows:
22359 </p>
22360 <blockquote>
22361 <p>
22362 The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows:
22363 </p>
22364 <ul>
22365 <li>
22366 decimal32 is a <em>decimal32</em> number, which is encoded in four consecutive <del>bytes</del> <ins>octets</ins> (32 bits)
22367 </li>
22368 <li>
22369 decimal64 is a <em>decimal64</em> number, which is encoded in eight consecutive <del>bytes</del> <ins>octets</ins> (64 bits)
22370
22371 </li>
22372 <li>
22373 decimal128 is a <em>decimal128</em> number, which is encoded in 16 consecutive <del>bytes</del> <ins>octets</ins> (128 bits)
22374 </li>
22375 </ul>
22376 <p>
22377 <del>[<i>Note:</i> this implies that <code>sizeof(std::decimal::decimal32) == 4</code>, <code>sizeof(std::decimal::decimal64) == 8</code>, and <code>sizeof(std::decimal::decimal128) == 16</code>.  <i>--end note</i>]</del>
22378 </p>
22379 </blockquote>
22380
22381
22382
22383
22384 <hr>
22385 <h3><a name="600"></a>600. Decimal: Wrong parameters for wcstod* functions</h3>
22386 <p><b>Section:</b> TRDecimal 3.9 [trdec.types.cwchar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
22387  <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
22388 <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>
22389 <p><b>Discussion:</b></p>
22390 <p>
22391 Daniel writes:
22392 </p>
22393 <blockquote><p>
22394 - 3.9.1 'Additions to &lt;cwchar&gt;' provides wrong
22395 signatures to the wcstod32, wcstod64, and
22396 wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t).
22397 </p></blockquote>
22398
22399
22400 <p><b>Proposed resolution:</b></p>
22401 <p>
22402 Change "3.9.1 Additions to <code>&lt;cwchar&gt;</code> synopsis" to:
22403 </p>
22404 <pre>       namespace std {
22405        namespace decimal {
22406          // 3.9.2 wcstod functions:
22407          decimal32  wcstod32  (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
22408          decimal64  wcstod64  (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
22409          decimal128 wcstod128 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
22410        }
22411        }
22412 </pre>
22413
22414
22415
22416
22417 <hr>
22418 <h3><a name="601"></a>601. Decimal: numeric_limits typos</h3>
22419 <p><b>Section:</b> TRDecimal 3.3 [trdec.types.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
22420  <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
22421 <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>
22422 <p><b>Discussion:</b></p>
22423 <p>
22424 Daniel writes in a private email:
22425 </p>
22426
22427 <blockquote>
22428 <p>
22429 - 3.3 'Additions to header &lt;limits&gt;' contains two
22430 errors in the specialisation of numeric_limits&lt;decimal::decimal128&gt;:
22431 </p>
22432 <ol>
22433 <li>The static member max() returns DEC128_MIN, this should be DEC128_MAX.</li>
22434 <li>The static member digits is assigned to 384,
22435 this should be 34 (Probably mixed up with the
22436 max. exponent for decimal::decimal64).</li>
22437 </ol>
22438 </blockquote>
22439
22440
22441 <p><b>Proposed resolution:</b></p>
22442 <p>
22443 In "3.3 Additions to header <code>&lt;limits&gt;</code>" change numeric_limits&lt;decimal::decimal128&gt; as follows:
22444 </p>
22445 <pre>        template&lt;&gt; class numeric_limits&lt;decimal::decimal128&gt; {
22446           public:
22447             static const bool is_specialized = true;
22448
22449             static decimal::decimal128 min() throw() { return DEC128_MIN; }
22450             static decimal::decimal128 max() throw() { return <del>DEC128_MIN;</del> <ins>DEC128_MAX;</ins> }
22451
22452             static const int digits       = <del>384</del> <ins>34</ins>;
22453             /* ... */
22454 </pre>
22455
22456
22457
22458
22459 <hr>
22460 <h3><a name="602"></a>602. Decimal: "generic floating type" not defined.</h3>
22461 <p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
22462  <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
22463 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
22464 <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>
22465 <p><b>Discussion:</b></p>
22466 <p>
22467 The document uses the term "generic floating types," but defines it nowhere.
22468 </p>
22469
22470
22471 <p><b>Proposed resolution:</b></p>
22472 <p>
22473 Change the first paragraph of "3 Decimal floating-point types" as follows:
22474 </p>
22475 <blockquote><p>
22476 This Technical Report introduces three decimal floating-point types, named
22477 decimal32, decimal64, and decimal128. The set of values of type decimal32 is a
22478 subset of the set of values of type decimal64; the set of values of the type
22479 decimal64 is a subset of the set of values of the type decimal128. Support for
22480 decimal128 is optional.  <ins>These types supplement the Standard C++ types
22481 <code>float</code>, <code>double</code>, and <code>long double</code>, which are
22482 collectively described as the <i>basic floating types</i></ins>.
22483 </p></blockquote>
22484
22485
22486
22487
22488 <hr>
22489 <h3><a name="603"></a>603. Decimal: Trivially simplifying decimal classes.</h3>
22490 <p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
22491  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-28</p>
22492 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
22493 <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>
22494 <p><b>Discussion:</b></p>
22495 <p>In c++std-lib-17198, Martin writes:</p>
22496
22497 <blockquote><p>
22498 Each of the three classes proposed in the paper (decimal32, decimal64,
22499 and decimal128) explicitly declares and specifies the semantics of its
22500 copy constructor, copy assignment operator, and destructor. Since the
22501 semantics of all three functions are identical to the trivial versions
22502 implicitly generated by the compiler in the absence of any declarations
22503 it is safe to drop them from the spec. This change would make the
22504 proposed classes consistent with other similar classes already in the
22505 standard (e.g., std::complex).
22506 </p></blockquote>
22507
22508
22509 <p><b>Proposed resolution:</b></p>
22510 <p>
22511 Change "3.2.2 Class <code>decimal32</code>" as follows:
22512 </p>
22513 <pre>      namespace std {
22514       namespace decimal {
22515         class decimal32 {
22516           public:
22517             // 3.2.2.1 construct/copy/destroy:
22518             decimal32();
22519             <del>decimal32(const decimal32 &amp; d32);</del>
22520             <del>decimal32 &amp; operator=(const decimal32 &amp; d32);</del>
22521             <del>~decimal32();</del>
22522             /* ... */
22523 </pre>
22524 <p>
22525 Change "3.2.2.1 construct/copy/destroy" as follows:
22526 </p>
22527 <pre>        decimal32();
22528
22529     Effects: Constructs an object of type decimal32 with the value 0;
22530
22531         <del>decimal32(const decimal32 &amp; d32);</del>
22532         <del>decimal32 &amp; operator=(const decimal32 &amp; d32);</del>
22533
22534     <del>Effects: Copies an object of type decimal32.</del>
22535
22536         <del>~decimal32();</del>
22537
22538     <del>Effects: Destroys an object of type decimal32.</del>
22539
22540 </pre>
22541 <p>
22542 Change "3.2.3 Class <code>decimal64</code>" as follows:
22543 </p>
22544 <pre>      namespace std {
22545       namespace decimal {
22546         class decimal64 {
22547           public:
22548             // 3.2.3.1 construct/copy/destroy:
22549             decimal64();
22550             <del>decimal64(const decimal64 &amp; d64);</del>
22551             <del>decimal64 &amp; operator=(const decimal64 &amp; d64);</del>
22552             <del>~decimal64();</del>
22553             /* ... */
22554 </pre>
22555 <p>
22556 Change "3.2.3.1 construct/copy/destroy" as follows:
22557 </p>
22558 <pre>        decimal64();
22559
22560     Effects: Constructs an object of type decimal64 with the value 0;
22561
22562         <del>decimal64(const decimal64 &amp; d64);</del>
22563         <del>decimal64 &amp; operator=(const decimal64 &amp; d64);</del>
22564
22565     <del>Effects: Copies an object of type decimal64.</del>
22566
22567         <del>~decimal64();</del>
22568
22569     <del>Effects: Destroys an object of type decimal64.</del>
22570
22571 </pre>
22572 <p>
22573 Change "3.2.4 Class <code>decimal128</code>" as follows:
22574 </p>
22575 <pre>      namespace std {
22576       namespace decimal {
22577         class decimal128 {
22578           public:
22579             // 3.2.4.1 construct/copy/destroy:
22580             decimal128();
22581             <del>decimal128(const decimal128 &amp; d128);</del>
22582             <del>decimal128 &amp; operator=(const decimal128 &amp; d128);</del>
22583             <del>~decimal128();</del>
22584             /* ... */
22585 </pre>
22586 <p>
22587 Change "3.2.4.1 construct/copy/destroy" as follows:
22588 </p>
22589 <pre>        decimal128();
22590
22591     Effects: Constructs an object of type decimal128 with the value 0;
22592
22593         <del>decimal128(const decimal128 &amp; d128);</del>
22594         <del>decimal128 &amp; operator=(const decimal128 &amp; d128);</del>
22595
22596     <del>Effects: Copies an object of type decimal128.</del>
22597
22598         <del>~decimal128();</del>
22599
22600     <del>Effects: Destroys an object of type decimal128.</del>
22601
22602 </pre>
22603
22604
22605
22606
22607 <hr>
22608 <h3><a name="604"></a>604. Decimal: Storing a reference to a facet unsafe.</h3>
22609 <p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
22610  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-28</p>
22611 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
22612 <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>
22613 <p><b>Discussion:</b></p>
22614 <p>
22615 In c++std-lib-17197, Martin writes:
22616 </p>
22617 <blockquote><p>
22618 The extended_num_get and extended_num_put facets are designed
22619 to store a reference to a num_get or num_put facet which the
22620 extended facets delegate the parsing and formatting of types
22621 other than decimal. One form of the extended facet's ctor (the
22622 default ctor and the size_t overload) obtains the reference
22623 from the global C++ locale while the other form takes this
22624 reference as an argument.
22625 </p></blockquote>
22626 <blockquote><p>
22627 The problem with storing a reference to a facet in another
22628 object (as opposed to storing the locale object in which the
22629 facet is installed) is that doing so bypasses the reference
22630 counting mechanism designed to prevent a facet that is still
22631 being referenced (i.e., one that is still installed in some
22632 locale) from being destroyed when another locale that contains
22633 it is destroyed. Separating a facet reference from the locale
22634 it comes from van make it cumbersome (and in some cases might
22635 even make it impossible) for programs to prevent invalidating
22636 the reference. (The danger of this design is highlighted in
22637 the paper.)
22638 </p></blockquote>
22639 <blockquote><p>
22640 This problem could be easily avoided by having the extended
22641 facets store a copy of the locale from which they would extract
22642 the base facet either at construction time or when needed. To
22643 make it possible, the forms of ctors of the extended facets that
22644 take a reference to the base facet would need to be changed to
22645 take a locale argument instead.
22646 </p></blockquote>
22647
22648
22649 <p><b>Proposed resolution:</b></p>
22650 <p>
22651 1. Change the <code>extended_num_get</code> synopsis in 3.10.2 as follows:
22652 </p>
22653 <pre>            extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
22654
22655             /* ... */
22656
22657             <del>// <i>const std::num_get&lt;charT, InputIterator&gt; &amp; <b>base</b></i>;        <i><b>exposition only</b></i></del>
22658             <ins>// <i>std::locale <b>baseloc</b></i>;                                    <i><b>exposition only</b></i></ins>
22659 </pre>
22660 <p>
22661 2. Change the description of the above constructor in 3.10.2.1:
22662 </p>
22663 <pre>            extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
22664
22665 </pre>
22666 <blockquote>
22667 <p>
22668 <b>Effects:</b> Constructs an <code>extended_num_get</code> facet as if by:
22669 </p>
22670 <pre>       extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
22671                 : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
22672                 { /* ... */ }
22673
22674 </pre>
22675 <p>
22676 <del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_get</code> facet.</del>
22677 </p>
22678 </blockquote>
22679 <p>
22680 3. Change the <b>Returns:</b> clause for <code>do_get(iter_type, iter_type, ios_base &amp;, ios_base::iostate &amp;, bool &amp;) const</code>, <i>et al</i> to
22681 </p>
22682 <blockquote><p>
22683 <b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_get&lt;charT, InputIterator&gt; &gt;(<i>baseloc</i>)</ins>.get(<i>in</i>, <i>end</i>, <i>str</i>, <i>err</i>, <i>val</i>)</code>.
22684 </p></blockquote>
22685 <p>
22686 4. Change the <code>extended_num_put</code> synopsis in 3.10.3 as follows:
22687 </p>
22688 <pre>            extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
22689
22690             /* ... */
22691
22692             <del>// <i>const std::num_put&lt;charT, OutputIterator&gt; &amp; <b>base</b></i>;       <i><b>exposition only</b></i></del>
22693             <ins>// <i>std::locale <b>baseloc</b></i>;                                    <i><b>exposition only</b></i></ins>
22694 </pre>
22695 <p>
22696 5. Change the description of the above constructor in 3.10.3.1:
22697 </p>
22698 <pre>            extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
22699 </pre>
22700 <blockquote>
22701 <p>
22702 <b>Effects:</b> Constructs an <code>extended_num_put</code> facet as if by:
22703 </p>
22704 <pre>       extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
22705                 : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
22706                 { /* ... */ }
22707
22708 </pre>
22709 <p>
22710 <del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_put</code> facet.</del>
22711 </p>
22712 </blockquote>
22713 <p>
22714 6. Change the <b>Returns:</b> clause for <code>do_put(iter_type, ios_base &amp;, char_type, bool &amp;) const</code>, <i>et al</i> to
22715 </p>
22716 <blockquote><p>
22717 <b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_put&lt;charT, OutputIterator&gt; &gt;(<i>baseloc</i>)</ins>.put(<i>s</i>, <i>f</i>, <i>fill</i>, <i>val</i>)</code>.
22718 </p></blockquote>
22719
22720 <p><i>[
22721 Redmond:  We would prefer to rename "extended" to "decimal".
22722 ]</i></p>
22723
22724
22725
22726
22727
22728
22729 <hr>
22730 <h3><a name="605"></a>605. Decimal: &lt;decfloat.h&gt; doesn't live here anymore.</h3>
22731 <p><b>Section:</b> TRDecimal 3.4 [trdec.types.cdecfloat] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
22732  <b>Submitter:</b> Robert Klarer <b>Date:</b> 2006-10-17</p>
22733 <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>
22734 <p><b>Discussion:</b></p>
22735 <p>
22736 In Berlin, WG14 decided to drop the &lt;decfloat.h&gt; header. The
22737 contents of that header have been moved into &lt;float.h&gt;. For the
22738 sake of C compatibility, we should make corresponding changes.
22739 </p>
22740
22741
22742 <p><b>Proposed resolution:</b></p>
22743 <p>
22744 1. Change the heading of subclause 3.4, "Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code>" to "Additions to headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code>."
22745 </p>
22746 <p>
22747 2. Change the text of subclause 3.4 as follows:
22748 </p>
22749 <blockquote>
22750 <p>
22751 <del>The standard C++ headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code> define characteristics of the floating-point types <code>float</code>, <code>double</code>, and <code>long double</code>.  Their contents remain unchanged by this Technical Report.</del>
22752 </p>
22753 <p>
22754 <del>Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>.  As well, <code>&lt;decfloat.h&gt;</code> defines the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del>
22755 </p>
22756 <p>
22757 <ins>The header <code>&lt;cfloat&gt;</code> is described in [tr.c99.cfloat].  The header <code>&lt;float.h&gt;</code>
22758 is described in [tr.c99.floath]. These headers are extended by this
22759 Technical Report to define characteristics of the decimal
22760 floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>.  As well, <code>&lt;float.h&gt;</code> is extended to define the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code> for compatibility with the C programming language.</ins>
22761 </p>
22762 </blockquote>
22763 <p>
22764 3. Change the heading of subclause 3.4.1, "Header <code>&lt;cdecfloat&gt;</code> synopsis"  to "Additions to header <code>&lt;cfloat&gt;</code> synopsis."
22765 </p>
22766 <p>
22767 4. Change the heading of subclause 3.4.2, "Header <code>&lt;decfloat.h&gt;</code> synopsis" to "Additions to header <code>&lt;float.h&gt;</code> synopsis."
22768 </p>
22769 <p>
22770 5. Change the contents of 3.4.2 as follows:
22771 </p>
22772 <pre>      <del>#include &lt;cdecfloat&gt;</del>
22773
22774       // <i>C-compatibility convenience typedefs:</i>
22775
22776       typedef std::decimal::decimal32  _Decimal32;
22777       typedef std::decimal::decimal64  _Decimal64;
22778       typedef std::decimal::decimal128 _Decimal128;
22779 </pre>
22780
22781
22782
22783
22784
22785 <hr>
22786 <h3><a name="607"></a>607. Concern about short seed vectors</h3>
22787 <p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
22788  <b>Submitter:</b> Charles Karney <b>Date:</b> 2006-10-26</p>
22789 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
22790 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p>
22791 <p><b>Discussion:</b></p>
22792 <p>
22793 Short seed vectors of 32-bit quantities all result in different states. However
22794 this is not true of seed vectors of 16-bit (or smaller) quantities.  For example
22795 these two seeds
22796 </p>
22797
22798 <blockquote><pre>unsigned short seed = {1, 2, 3};
22799 unsigned short seed = {1, 2, 3, 0};
22800 </pre></blockquote>
22801
22802 <p>
22803 both pack to
22804 </p>
22805
22806 <blockquote><pre>unsigned seed = {0x20001, 0x3};
22807 </pre></blockquote>
22808
22809 <p>
22810 yielding the same state.
22811 </p>
22812
22813 <p>
22814 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
22815 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
22816 for some further discussion.
22817 </p>
22818
22819
22820 <p><b>Proposed resolution:</b></p>
22821 <p>
22822 Adopt the proposed resolution in
22823 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
22824 </p>
22825
22826
22827 <p><i>[
22828 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
22829 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
22830 ]</i></p>
22831
22832
22833
22834
22835
22836 <hr>
22837 <h3><a name="608"></a>608. Unclear seed_seq construction details</h3>
22838 <p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
22839  <b>Submitter:</b> Charles Karney <b>Date:</b> 2006-10-26</p>
22840 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
22841 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p>
22842 <p><b>Discussion:</b></p>
22843 <p>
22844 In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
22845 treatment of signed quantities is unclear. Better to spell it out.
22846 </p>
22847
22848 <p>
22849 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
22850 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
22851 for some further discussion.
22852 </p>
22853
22854
22855 <p><b>Proposed resolution:</b></p>
22856 <p>
22857 Adopt the proposed resolution in
22858 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
22859 </p>
22860
22861
22862 <p><i>[
22863 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
22864 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
22865 ]</i></p>
22866
22867
22868
22869
22870
22871 <hr>
22872 <h3><a name="609"></a>609. missing static const</h3>
22873 <p><b>Section:</b> 26.4.4.2 [rand.adapt.ibits], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22874  <b>Submitter:</b> Walter E. Brown <b>Date:</b> 2006-11-02</p>
22875 <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>
22876 <p><b>Discussion:</b></p>
22877 <p>
22878 In preparing N2111, an error on my part resulted in the omission of the
22879 following line from the template synopsis in the cited section:
22880 </p>
22881
22882 <blockquote><pre>static const size_t word_size = w;
22883 </pre></blockquote>
22884
22885 <p>
22886 (This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].)
22887 </p>
22888
22889
22890 <p><b>Proposed resolution:</b></p>
22891 <p>
22892 Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4:
22893 </p>
22894
22895 <blockquote><pre>// engine characteristics
22896 <ins>static const size_t word_size = w;</ins>
22897 </pre></blockquote>
22898
22899 <p>
22900 and accept my apologies for the oversight.
22901 </p>
22902
22903
22904
22905
22906
22907 <hr>
22908 <h3><a name="610"></a>610. Suggested non-normative note for C++0x</h3>
22909 <p><b>Section:</b> 20.5.15.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22910  <b>Submitter:</b> Scott Meyers <b>Date:</b> 2006-11-02</p>
22911 <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>
22912 <p><b>Discussion:</b></p>
22913 <p>
22914 My suggestion is that implementers of both tr1::function and its
22915 official C++0x successor be explicitly encouraged (but not required) to
22916 optimize for the cases mentioned above, i.e., function pointers and
22917 small function objects.  They could do this by using a small internal
22918 buffer akin to the buffer used by implementations of the small string
22919 optimization.  (That would make this the small functor optimization --
22920 SFO :-})  The form of this encouragement could be a note in the standard
22921 akin to footnote 214 of the current standard.
22922 </p>
22923
22924 <p>
22925 Dave Abrahams notes:
22926 </p>
22927
22928 <p>
22929 "shall not throw exceptions" should really be "nothing," both to be more
22930 grammatical and to be consistent with existing wording in the standard.
22931 </p>
22932
22933 <p>
22934 Doug Gregor comments: I think this is a good idea. Currently, implementations of
22935 tr1::function are required to have non-throwing constructors and assignment
22936 operators when the target function object is a function pointer or a
22937 reference_wrapper. The common case, however, is for a tr1::function to store
22938 either an empty function object or a member pointer + an object pointer.
22939 </p>
22940 <p>
22941 The function implementation in the upcoming Boost 1.34.0 uses the
22942 "SFO", so that the function objects for typical bind expressions like
22943 </p>
22944 <blockquote><pre>bind(&amp;X::f, this, _1, _2, _3)
22945 </pre></blockquote>
22946
22947 <p>
22948 do not require heap allocation when stored in a boost::function. I
22949 believe Dinkumware's implementation also performs this optimization.
22950 </p>
22951
22952
22953
22954 <p><b>Proposed resolution:</b></p>
22955 <p>
22956 Revise 20.5.14.2.1 p6 [func.wrap.func.con] to add a note as follows:
22957 </p>
22958
22959 <blockquote>
22960 <p>
22961 <i>Throws:</i> shall not throw exceptions if <tt>f</tt>'s target is a function
22962 pointer or a function object passed via <tt>reference_wrapper</tt>. Otherwise,
22963 may throw <tt>bad_alloc</tt> or any exception thrown by the copy constructor of
22964 the stored function object.
22965 </p>
22966 <p>
22967 <ins><i>Note:</i> Implementations are encouraged to avoid the use of dynamically
22968 allocated memory for "small" function objects, e.g., where <tt>f</tt>'s target
22969 is an object holding only a pointer or reference to an object and a member
22970 function pointer (a "bound member function").</ins>
22971 </p>
22972 </blockquote>
22973
22974
22975
22976
22977
22978 <hr>
22979 <h3><a name="611"></a>611. Standard library templates and incomplete types</h3>
22980 <p><b>Section:</b> 17.4.3.6 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22981  <b>Submitter:</b> Nicola Musatti <b>Date:</b> 2006-11-13</p>
22982 <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>
22983 <p><b>Discussion:</b></p>
22984 <p>
22985 In the latest available draft standard
22986 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
22987 § 17.4.3.6 [res.on.functions] states:
22988 </p>
22989
22990 <blockquote>
22991 <p>
22992 -1- In certain cases (replacement functions, handler functions, operations on
22993 types used to instantiate standard library template components), the C++
22994 Standard Library depends on components supplied by a C++ program. If these
22995 components do not meet their requirements, the Standard places no requirements
22996 on the implementation.
22997 </p>
22998
22999 <p>
23000 -2- In particular, the effects are undefined in the following cases:
23001 </p>
23002 <p>
23003 [...]
23004 </p>
23005 <ul>
23006 <li>if an incomplete type (3.9) is used as a template argument when
23007 instantiating a template component. </li>
23008 </ul>
23009 </blockquote>
23010
23011 <p>
23012 This is contradicted by § 20.6.6.2/2 [util.smartptr.shared] which
23013 states:
23014 </p>
23015
23016 <blockquote>
23017 <p>
23018 [...]
23019 </p>
23020
23021 <p>
23022 The template parameter <tt>T</tt> of <tt>shared_ptr</tt> may be an incomplete type.
23023 </p>
23024 </blockquote>
23025
23026
23027 <p><b>Proposed resolution:</b></p>
23028 <p>
23029 Modify the last bullet of § 17.4.3.6/2 [res.on.functions] to allow for
23030 exceptions:
23031 </p>
23032
23033 <blockquote>
23034 <ul>
23035 <li>if an incomplete type (3.9) is used as a template argument when
23036 instantiating a template component<ins>, unless specifically allowed for the
23037 component</ins>. </li>
23038 </ul>
23039 </blockquote>
23040
23041
23042
23043
23044
23045
23046 <hr>
23047 <h3><a name="613"></a>613. max_digits10 missing from numeric_limits</h3>
23048 <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>
23049  <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-11-20</p>
23050 <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>
23051 <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>
23052 <p><b>Discussion:</b></p>
23053 <p>
23054 Section 18.2.1.5 [numeric.special] starts out by saying that "All members shall be provided
23055 for all specializations."
23056 </p>
23057 <p>
23058 Then it goes on to show specializations for float and bool, where one member
23059 is missing (max_digits10).
23060 </p>
23061
23062 <p>
23063 Maarten Kronenburg adds:
23064 </p>
23065
23066 <p>
23067 I agree, just adding the comment that the exact number of decimal digits
23068 is digits * ln(radix) / ln(10), where probably this real number is
23069 rounded downward for digits10, and rounded upward for max_digits10
23070 (when radix=10, then digits10=max_digits10).
23071 Why not add this exact definition also to the standard, so the user
23072 knows what these numbers exactly mean.
23073 </p>
23074
23075 <p>
23076 Howard adds:
23077 </p>
23078
23079 <p>
23080 For reference, here are the correct formulas from
23081 <a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1822.pdf">N1822</a>:
23082 </p>
23083
23084 <blockquote><pre>digits10 = floor((digits-1) * log10(2))
23085 max_digits10 = ceil((1 + digits) * log10(2))
23086 </pre></blockquote>
23087
23088 <p>
23089 We are also missing a statement regarding for what specializations this member has meaning.
23090 </p>
23091
23092
23093
23094 <p><b>Proposed resolution:</b></p>
23095 <p>
23096 Change and add after 18.2.1.2 [numeric.limits.members], p11:
23097 </p>
23098
23099 <blockquote>
23100 <pre>static const int max_digits10;</pre>
23101 <blockquote>
23102 <p>
23103 -11- Number of base 10 digits required to ensure that values which
23104 differ <del>by only one epsilon</del> are always differentiated.
23105 </p>
23106 <p><ins>
23107 -12- Meaningful for all floating point types.
23108 </ins></p>
23109 </blockquote>
23110 </blockquote>
23111
23112 <p>
23113 Change 18.2.1.5 [numeric.special], p2:
23114 </p>
23115
23116 <blockquote><pre>template&lt;&gt; class numeric_limits&lt;float&gt; {
23117 public:
23118   static const bool is_specialized = true;
23119   ...
23120   static const int digits10 = 6;
23121   <ins>static const int max_digits10 = 9</ins>;
23122   ...
23123 </pre></blockquote>
23124
23125 <p>
23126 Change 18.2.1.5 [numeric.special], p3:
23127 </p>
23128
23129 <blockquote><pre>template&lt;&gt; class numeric_limits&lt;bool&gt; {
23130 public:
23131   static const bool is_specialized = true;
23132   ...
23133   static const int digits10 = 0;
23134   <ins>static const int max_digits10 = 0</ins>;
23135   ...
23136 </pre></blockquote>
23137
23138
23139
23140
23141
23142
23143
23144 <hr>
23145 <h3><a name="616"></a>616. missing 'typename' in ctype_byname</h3>
23146 <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#WP">WP</a>
23147  <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-16</p>
23148 <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>
23149 <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>
23150 <p><b>Discussion:</b></p>
23151 <p>
23152 Section 22.2.1.2 defines the ctype_byname class template. It contains the
23153 line
23154 </p>
23155
23156 <blockquote><pre>typedef ctype&lt;charT&gt;::mask   mask;
23157 </pre></blockquote>
23158
23159
23160
23161 <p><b>Proposed resolution:</b></p>
23162 <p>
23163 as this is a dependent type, it should obviously be
23164 </p>
23165
23166 <blockquote><pre>typedef <ins>typename</ins> ctype&lt;charT&gt;::mask   mask;
23167 </pre></blockquote>
23168
23169
23170
23171
23172
23173 <hr>
23174 <h3><a name="619"></a>619. Longjmp wording problem</h3>
23175 <p><b>Section:</b> 18.8 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
23176  <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2007-01-12</p>
23177 <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>
23178 <p><b>Discussion:</b></p>
23179 <p>
23180 The wording for <tt>longjmp</tt> is confusing.
23181 </p>
23182 <p>
23183 18.8 [support.runtime] -4- Other runtime support
23184 </p>
23185 <blockquote><p>
23186 The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more restricted
23187 behavior in this International Standard.  If any automatic objects would
23188 be destroyed by a thrown exception transferring control to another
23189 (destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt> that
23190 the throw point that transfers control to the same (destination) point has
23191 undefined behavior.
23192 </p></blockquote>
23193 <p>
23194 Someone at Google thinks that should say "then a call to <tt>longjmp(jbuf, val)</tt>
23195 *at* the throw point that transfers control".
23196 </p>
23197 <p>
23198 Bill Gibbons thinks it should say something like "If any automatic objects
23199 would be destroyed by an exception thrown at the point of the longjmp and
23200 caught only at the point of the setjmp, the behavior is undefined."
23201 </p>
23202
23203
23204 <p><b>Proposed resolution:</b></p>
23205 <p>
23206 In general, accept Bill Gibbons' recommendation,
23207 but add "call" to indicate that the undefined behavior
23208 comes from the dynamic call, not from its presence in the code.
23209 In 18.8 [support.runtime] paragraph 4, change
23210 </p>
23211
23212 <blockquote><p>
23213 The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more
23214 restricted behavior in this International Standard.  <del>If any automatic
23215 objects would be destroyed by a thrown exception transferring control to another
23216 (destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt>
23217 that the throw point that transfers control to the same (destination) point has
23218 undefined behavior.</del> <ins>A <tt>setjmp</tt>/<tt>longjmp</tt> call pair has
23219 undefined behavior if replacing the <tt>setjmp</tt> and <tt>longjmp</tt> by
23220 <tt>catch</tt> and <tt>throw</tt> would destroy any automatic objects.</ins>
23221 </p></blockquote>
23222
23223
23224
23225
23226
23227 <hr>
23228 <h3><a name="628"></a>628. Inconsistent definition of basic_regex constructor</h3>
23229 <p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
23230  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-01-23</p>
23231 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex">issues</a> in [re.regex].</p>
23232 <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>
23233 <p><b>Discussion:</b></p>
23234 <p>
23235 Section 28.8 [re.regex] lists a constructor
23236 </p>
23237
23238 <blockquote><pre>template&lt;class InputIterator&gt;
23239 basic_regex(InputIterator first, InputIterator last,
23240                        flag_type f = regex_constants::ECMAScript);
23241 </pre></blockquote>
23242
23243 <p>
23244 However, in section 28.8.2 [re.regex.construct], this constructor takes a
23245 pair of <tt>ForwardIterator</tt>.
23246 </p>
23247
23248
23249 <p><b>Proposed resolution:</b></p>
23250 <p>
23251 Change 28.8.2 [re.regex.construct]:
23252 </p>
23253
23254 <blockquote><pre>template &lt;class <del>ForwardIterator</del> <ins>InputIterator</ins>&gt;
23255   basic_regex(<del>ForwardIterator</del> <ins>InputIterator</ins> first, <del>ForwardIterator</del> <ins>InputIterator</ins> last,
23256               flag_type f = regex_constants::ECMAScript);
23257 </pre></blockquote>
23258
23259
23260
23261
23262
23263
23264 <hr>
23265 <h3><a name="634"></a>634. <tt>allocator.address()</tt> doesn't work for types overloading <tt>operator&amp;</tt></h3>
23266 <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>
23267  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-02-07</p>
23268 <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>
23269 <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>
23270 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a></p>
23271 <p><b>Discussion:</b></p>
23272
23273 <p>
23274 20.6.1.1 [allocator.members] says:
23275 </p>
23276 <blockquote>
23277 <pre>pointer address(reference <i>x</i>) const;</pre>
23278 <blockquote>
23279 <p>
23280 -1- <i>Returns:</i> <tt>&amp;<i>x</i></tt>.
23281 </p>
23282 </blockquote>
23283 </blockquote>
23284
23285 <p>
23286 20.6.1.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not
23287 only defines the semantics of copy construction, but also restricts what an overloaded
23288 <tt>operator&amp;</tt> may do.  I believe proposals are in the works (such as concepts
23289 and rvalue reference) to decouple these two requirements.  Indeed it is not evident
23290 that we should disallow overloading <tt>operator&amp;</tt> to return something other
23291 than the address of <tt>*this</tt>.
23292 </p>
23293
23294 <p>
23295 An example of when you want to overload <tt>operator&amp;</tt> to return something
23296 other than the object's address is proxy references such as <tt>vector&lt;bool&gt;</tt>
23297 (or its replacement, currently code-named <tt>bit_vector</tt>).  Taking the address of
23298 such a proxy reference should logically yield a proxy pointer, which when dereferenced,
23299 yields a copy of the original proxy reference again.
23300 </p>
23301
23302 <p>
23303 On the other hand, some code truly needs the address of an object, and not a proxy
23304 (typically for determining the identity of an object compared to a reference object).
23305 <a href="http://www.boost.org/">boost</a> has long recognized this dilemma and solved it with
23306 <a href="http://www.boost.org/libs/utility/utility.htm#addressof"><tt>boost::addressof</tt></a>.
23307 It appears to me that this would be useful functionality for the default allocator.  Adopting
23308 this definition for <tt>allocator::address</tt> would free the standard of requiring
23309 anything special from types which overload <tt>operator&amp;</tt>.  Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>
23310 is expected to make use of <tt>allocator::address</tt> mandatory for containers.
23311 </p>
23312
23313
23314
23315 <p><b>Proposed resolution:</b></p>
23316 <p>
23317 Change 20.6.1.1 [allocator.members]:
23318 </p>
23319
23320 <blockquote>
23321 <pre>pointer address(reference <i>x</i>) const;</pre>
23322 <blockquote>
23323 <p>
23324 -1- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
23325 even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
23326 </p>
23327 </blockquote>
23328
23329 <pre>const_pointer address(address(const_reference <i>x</i>) const;</pre>
23330 <blockquote>
23331 <p>
23332 -2- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
23333 even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
23334 </p>
23335 </blockquote>
23336 </blockquote>
23337
23338 <p><i>[
23339 post Oxford:  This would be rendered NAD Editorial by acceptance of
23340 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
23341 ]</i></p>
23342
23343
23344 <p><i>[
23345 Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
23346 was subsequently split out into a separate paper N2436 for the purposes of voting.
23347 The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
23348 issue to Ready status to be voted into the WP at Kona.
23349 ]</i></p>
23350
23351
23352
23353
23354
23355
23356
23357 <hr>
23358 <h3><a name="640"></a>640. 27.6.2.5.2 does not handle (unsigned) long long</h3>
23359 <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>
23360  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-17</p>
23361 <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>
23362 <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>
23363 <p><b>Discussion:</b></p>
23364 <p>
23365 The arithmetic inserters are described in 27.6.2.6.2 [ostream.inserters.arithmetic].
23366 Although the section starts with a listing of the inserters including
23367 the new ones:
23368 </p>
23369
23370 <blockquote><pre>operator&lt;&lt;(long long val );
23371 operator&lt;&lt;(unsigned long long val );
23372 </pre></blockquote>
23373
23374 <p>
23375 the text in paragraph 1, which describes the corresponding effects
23376 of the inserters, depending on the actual type of val, does not
23377 handle the types <tt>long long</tt> and <tt>unsigned long long</tt>.
23378 </p>
23379
23380 <p><i>[
23381 Alisdair: In addition to the (unsigned) long long problem, that whole paragraph
23382 misses any reference to extended integral types supplied by the
23383 implementation - one of the additions by core a couple of working papers
23384 back.
23385 ]</i></p>
23386
23387
23388
23389
23390 <p><b>Proposed resolution:</b></p>
23391 <p>
23392 In 27.6.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
23393 </p>
23394
23395 <blockquote>
23396 When val is of type <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
23397 long</tt>, <ins>long long, unsigned long long,</ins> <tt>double</tt>,
23398 <tt>long double</tt>, or <tt>const void*</tt>, the formatting conversion
23399 occurs as if it performed the following code fragment:
23400 </blockquote>
23401
23402
23403
23404
23405
23406 <hr>
23407 <h3><a name="643"></a>643. Impossible "as if" clauses</h3>
23408 <p><b>Section:</b> 27.8.1.1 [filebuf], 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>
23409  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-20</p>
23410 <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>
23411 <p><b>Discussion:</b></p>
23412 <p>
23413 The current standard 14882:2003(E) as well as N2134 have the
23414 following
23415 defects:
23416 </p>
23417
23418 <p>
23419 27.8.1.1 [filebuf]/5 says:
23420 </p>
23421
23422 <blockquote>
23423 <p>
23424 In order to support file I/O and multibyte/wide character conversion, conversions are performed using members of a
23425 facet, referred to as <tt><i>a_codecvt</i></tt> in following sections, obtained "as if" by
23426 </p>
23427 <blockquote><pre>codecvt&lt;charT,char,typename traits::state_type&gt; <i>a_codecvt</i> =
23428   use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
23429 </pre></blockquote>
23430 </blockquote>
23431
23432 <p>
23433 <tt>use_facet</tt> returns a <tt>const facet</tt> reference and no facet is
23434 copyconstructible, so the codecvt construction should fail to compile.
23435 </p>
23436
23437 <p>
23438 A similar issue arises in 22.2.2.2.2 [facet.num.put.virtuals]/15 for <tt>num_punct</tt>.
23439 </p>
23440
23441
23442 <p><b>Proposed resolution:</b></p>
23443 <p>
23444 In 27.8.1.1 [filebuf]/5 change the "as if" code
23445 </p>
23446
23447 <blockquote><pre><ins>const </ins>codecvt&lt;charT,char,typename traits::state_type&gt;<ins>&amp;</ins> <i>a_codecvt</i> =
23448   use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
23449 </pre></blockquote>
23450
23451 <p>
23452 In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
23453 </p>
23454
23455 <blockquote>
23456 <p>
23457 A local variable <tt><i>punct</i></tt> is initialized via
23458 </p>
23459 <blockquote><pre><ins>const </ins>numpunct&lt;charT&gt;<ins>&amp;</ins> <i>punct</i> = use_facet&lt; numpunct&lt;charT&gt; &gt;(<i>str</i>.getloc() )<ins>;</ins>
23460 </pre></blockquote>
23461 </blockquote>
23462
23463 <p>
23464 (Please note also the additional provided trailing semicolon)
23465 </p>
23466
23467
23468
23469
23470
23471
23472 <hr>
23473 <h3><a name="644"></a>644. Possible typos in 'function' description</h3>
23474 <p><b>Section:</b> X [func.wrap.func.undef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
23475  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-25</p>
23476 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p>
23477 <p><b>Discussion:</b></p>
23478 <p>
23479 X [func.wrap.func.undef]
23480 </p>
23481 <p>
23482 The note in paragraph 2 refers to 'undefined void operators', while the
23483 section declares a pair of operators returning bool.
23484 </p>
23485
23486
23487 <p><b>Proposed resolution:</b></p>
23488 <p>
23489 Change 20.5.15.2 [func.wrap.func]
23490 </p>
23491
23492 <blockquote><pre>...
23493 private:
23494    // X [func.wrap.func.undef], undefined operators:
23495    template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
23496    template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
23497 };
23498 </pre></blockquote>
23499
23500 <p>
23501 Change X [func.wrap.func.undef]
23502 </p>
23503
23504 <blockquote><pre>template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
23505 template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
23506 </pre></blockquote>
23507
23508
23509
23510
23511
23512 <hr>
23513 <h3><a name="646"></a>646. const incorrect match_result members</h3>
23514 <p><b>Section:</b> 28.10.4 [re.results.form] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
23515  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p>
23516 <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>
23517 <p><b>Discussion:</b></p>
23518 <p>
23519 28.10.4 [re.results.form] (root and para 3) in N2134 defines the two function template
23520 members format as non-const functions, although they are declared
23521 as const in 28.10 [re.results]/3.
23522 </p>
23523
23524
23525 <p><b>Proposed resolution:</b></p>
23526 <p>
23527 Add the missing <tt>const</tt> specifier to both <tt>format</tt> overloads described
23528 in section 28.10.4 [re.results.form].
23529 </p>
23530
23531
23532
23533
23534
23535 <hr>
23536 <h3><a name="650"></a>650. regex_token_iterator and const correctness</h3>
23537 <p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
23538  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p>
23539 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter">issues</a> in [re.tokiter].</p>
23540 <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>
23541 <p><b>Discussion:</b></p>
23542 <p>
23543 Both the class definition of regex_token_iterator (28.12.2
23544 [re.tokiter]/6) and the latter member specifications (28.12.2.2
23545 [re.tokiter.comp]/1+2) declare both comparison operators as
23546 non-const functions. Furtheron, both dereference operators are
23547 unexpectedly also declared as non-const in 28.12.2 [re.tokiter]/6
23548 as well as in (28.12.2.3 [re.tokiter.deref]/1+2).
23549 </p>
23550
23551
23552 <p><b>Proposed resolution:</b></p>
23553 <p>
23554 1) In (28.12.2 [re.tokiter]/6) change the current declarations
23555 </p>
23556
23557 <blockquote><pre>bool operator==(const regex_token_iterator&amp;) <ins>const</ins>;
23558 bool operator!=(const regex_token_iterator&amp;) <ins>const</ins>;
23559 const value_type&amp; operator*() <ins>const</ins>;
23560 const value_type* operator-&gt;() <ins>const</ins>;
23561 </pre></blockquote>
23562
23563 <p>
23564 2) In 28.12.2.2 [re.tokiter.comp] change the following declarations
23565 </p>
23566
23567 <blockquote><pre>bool operator==(const regex_token_iterator&amp; right) <ins>const</ins>;
23568 bool operator!=(const regex_token_iterator&amp; right) <ins>const</ins>;
23569 </pre></blockquote>
23570
23571 <p>
23572 3) In 28.12.2.3 [re.tokiter.deref] change the following declarations
23573 </p>
23574
23575 <blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
23576 const value_type* operator-&gt;() <ins>const</ins>;
23577 </pre></blockquote>
23578
23579
23580 <p><i>[
23581 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
23582 is to adopt the proposed wording in this issue).
23583 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
23584 ]</i></p>
23585
23586
23587
23588
23589
23590 <hr>
23591 <h3><a name="651"></a>651. Missing preconditions for regex_token_iterator c'tors</h3>
23592 <p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
23593  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p>
23594 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter.cnstr">issues</a> in [re.tokiter.cnstr].</p>
23595 <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>
23596 <p><b>Discussion:</b></p>
23597 <p>
23598 The text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes
23599 the effects of the three non-default constructors of class
23600 template regex_token_iterator but is does not clarify which values
23601 are legal values for submatch/submatches. This becomes
23602 an issue, if one takes 28.12.2 [re.tokiter]/9 into account, which explains
23603 the notion of a "current match" by saying:
23604 </p>
23605
23606 <blockquote><p>
23607 The <i>current match</i> is <tt>(*position).prefix()</tt> if <tt>subs[N]
23608 == -1</tt>, or <tt>(*position)[subs[N]]</tt> for any other value of
23609 <tt>subs[N]</tt>.
23610 </p></blockquote>
23611
23612 <p>
23613 It's not clear to me, whether other negative values except -1
23614 are legal arguments or not - it seems they are not.
23615 </p>
23616
23617
23618 <p><b>Proposed resolution:</b></p>
23619 <p>
23620 Add the following precondition paragraph just before the current
23621 28.12.2.1 [re.tokiter.cnstr]/2:
23622 </p>
23623
23624 <blockquote><p>
23625 <i>Requires:</i> Each of the initialization values of <tt>subs</tt> must be <tt>&gt;= -1</tt>.
23626 </p></blockquote>
23627
23628
23629 <p><i>[
23630 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
23631 is to adopt the proposed wording in this issue).
23632 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
23633 ]</i></p>
23634
23635
23636
23637
23638
23639 <hr>
23640 <h3><a name="652"></a>652. regex_iterator and const correctness</h3>
23641 <p><b>Section:</b> 28.12.1 [re.regiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
23642  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p>
23643 <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>
23644 <p><b>Discussion:</b></p>
23645 <p>Both the class definition of regex_iterator (28.12.1 [re.regiter]/1)
23646 and the latter member specification (28.12.1.2 [re.regiter.comp]/1+2)
23647 declare both comparison operators as
23648 non-const functions. Furtheron, both dereference operators are
23649 unexpectedly also declared as non-const in 28.12.1 [re.regiter]/1
23650 as well as in (28.12.1.3 [re.regiter.deref]/1+2).
23651 </p>
23652
23653
23654 <p><b>Proposed resolution:</b></p>
23655 <p>
23656 1) In (28.12.1 [re.regiter]/1) change the current declarations
23657 </p>
23658
23659 <blockquote><pre>bool operator==(const regex_iterator&amp;) <ins>const</ins>;
23660 bool operator!=(const regex_iterator&amp;) <ins>const</ins>;
23661 const value_type&amp; operator*() <ins>const</ins>;
23662 const value_type* operator-&gt;() <ins>const</ins>;
23663 </pre></blockquote>
23664
23665 <p>
23666 2) In 28.12.1.3 [re.regiter.deref] change the following declarations
23667 </p>
23668
23669 <blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
23670 const value_type* operator-&gt;() <ins>const</ins>;
23671 </pre></blockquote>
23672
23673 <p>
23674 3) In 28.12.1.2 [re.regiter.comp] change the following declarations
23675 </p>
23676
23677 <blockquote><pre>bool operator==(const regex_iterator&amp; right) <ins>const</ins>;
23678 bool operator!=(const regex_iterator&amp; right) <ins>const</ins>;
23679 </pre></blockquote>
23680
23681
23682 <p><i>[
23683 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
23684 is to adopt the proposed wording in this issue).
23685 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
23686 ]</i></p>
23687
23688
23689
23690
23691
23692 <hr>
23693 <h3><a name="654"></a>654. Missing IO roundtrip for random number engines</h3>
23694 <p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
23695  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
23696 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
23697 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p>
23698 <p><b>Discussion:</b></p>
23699 <p>
23700 Table 98 and para 5 in 26.4.1.3 [rand.req.eng] specify
23701 the IO insertion and extraction semantic of random
23702 number engines. It can be shown, v.i., that the specification
23703 of the extractor cannot guarantee to fulfill the requirement
23704 from para 5:
23705 </p>
23706
23707 <blockquote><p>
23708 If a textual representation written via os &lt;&lt; x was
23709 subsequently read via is &gt;&gt; v, then x == v provided that
23710 there have been no intervening invocations of x or of v.
23711 </p></blockquote>
23712
23713 <p>
23714 The problem is, that the extraction process described in
23715 table 98 misses to specify that it will initially set the
23716 if.fmtflags to ios_base::dec, see table 104:
23717 </p>
23718
23719 <blockquote><p>
23720 dec: converts integer input or generates integer output
23721 in decimal base
23722 </p></blockquote>
23723
23724 <p>
23725 Proof: The following small program demonstrates the violation
23726 of requirements (exception safety not fulfilled):
23727 </p>
23728
23729 <blockquote><pre>#include &lt;cassert&gt;
23730 #include &lt;ostream&gt;
23731 #include &lt;iostream&gt;
23732 #include &lt;iomanip&gt;
23733 #include &lt;sstream&gt;
23734
23735 class RanNumEngine {
23736   int state;
23737 public:
23738   RanNumEngine() : state(42) {}
23739
23740   bool operator==(RanNumEngine other) const {
23741           return state == other.state;
23742   }
23743
23744   template &lt;typename Ch, typename Tr&gt;
23745   friend std::basic_ostream&lt;Ch, Tr&gt;&amp; operator&lt;&lt;(std::basic_ostream&lt;Ch, Tr&gt;&amp; os, RanNumEngine engine) {
23746         Ch old = os.fill(os.widen(' ')); // Sets space character
23747         std::ios_base::fmtflags f = os.flags();
23748         os &lt;&lt; std::dec &lt;&lt; std::left &lt;&lt; engine.state; // Adds ios_base::dec|ios_base::left
23749         os.fill(old); // Undo
23750         os.flags(f);
23751         return os;
23752   }
23753
23754   template &lt;typename Ch, typename Tr&gt;
23755   friend std::basic_istream&lt;Ch, Tr&gt;&amp; operator&gt;&gt;(std::basic_istream&lt;Ch, Tr&gt;&amp; is, RanNumEngine&amp; engine) {
23756        // Uncomment only for the fix.
23757
23758         //std::ios_base::fmtflags f = is.flags();
23759         //is &gt;&gt; std::dec;
23760         is &gt;&gt; engine.state;
23761         //is.flags(f);
23762         return is;
23763   }
23764 };
23765
23766 int main() {
23767         std::stringstream s;
23768         s &lt;&lt; std::setfill('#'); // No problem
23769         s &lt;&lt; std::oct; // Yikes!
23770         // Here starts para 5 requirements:
23771         RanNumEngine x;
23772         s &lt;&lt; x;
23773         RanNumEngine v;
23774         s &gt;&gt; v;
23775         assert(x == v); // Fails: 42 == 34
23776 }
23777 </pre></blockquote>
23778
23779 <p>
23780 A second, minor issue seems to be, that the insertion
23781 description from table 98 unnecessarily requires the
23782 addition of ios_base::fixed (which only influences floating-point
23783 numbers). Its not entirely clear to me whether the proposed
23784 standard does require that the state of random number engines
23785 is stored in integral types or not, but I have the impression
23786 that this is the indent, see e.g. p. 3
23787 </p>
23788
23789 <blockquote><p>
23790 The specification of each random number engine defines the
23791 size of its state in multiples of the size of its result_type.
23792 </p></blockquote>
23793
23794 <p>
23795 If other types than integrals are supported, then I wonder why
23796 no requirements are specified for the precision of the stream.
23797 </p>
23798
23799 <p>
23800 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
23801 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
23802 for some further discussion.
23803 </p>
23804
23805
23806 <p><b>Proposed resolution:</b></p>
23807 <p>
23808 Adopt the proposed resolution in
23809 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
23810 </p>
23811
23812
23813 <p><i>[
23814 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
23815 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
23816 ]</i></p>
23817
23818
23819
23820
23821
23822 <hr>
23823 <h3><a name="655"></a>655. Signature of generate_canonical not useful</h3>
23824 <p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
23825  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
23826 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.canonical">issues</a> in [rand.util.canonical].</p>
23827 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p>
23828 <p><b>Discussion:</b></p>
23829 <p>
23830 In 26.4.2 [rand.synopsis] we have the declaration
23831 </p>
23832
23833 <blockquote><pre>template&lt;class RealType, class UniformRandomNumberGenerator,
23834   size_t bits&gt;
23835 result_type generate_canonical(UniformRandomNumberGenerator&amp; g);
23836 </pre></blockquote>
23837
23838 <p>
23839 Besides the "result_type" issue (already recognized by Bo Persson
23840 at Sun, 11 Feb 2007 05:26:47 GMT in this group) it's clear, that
23841 the template parameter order is not reasonably choosen: Obviously
23842 one always needs to specify all three parameters, although usually
23843 only two are required, namely the result type RealType and the
23844 wanted bits, because UniformRandomNumberGenerator can usually
23845 be deduced.
23846 </p>
23847
23848 <p>
23849 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
23850 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
23851 for some further discussion.
23852 </p>
23853
23854
23855 <p><b>Proposed resolution:</b></p>
23856 <p>
23857 Adopt the proposed resolution in
23858 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
23859 </p>
23860
23861
23862 <p><i>[
23863 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
23864 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
23865 ]</i></p>
23866
23867
23868
23869
23870
23871 <hr>
23872 <h3><a name="660"></a>660. Missing Bitwise Operations</h3>
23873 <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>
23874  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-04-02</p>
23875 <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>
23876 <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>
23877 <p><b>Discussion:</b></p>
23878 <p>Section 20.5 [function.objects] provides <span id="st" name="st" class="st">function</span>
23879 <span id="st" name="st" class="st">objects</span> for some unary and binary
23880 operations, but others are missing. In a LWG reflector discussion, beginning
23881 with c++std-lib-18078, pros and cons of adding some of the missing operations
23882 were discussed. Bjarne Stroustrup commented "Why standardize what isn't used?
23883 Yes, I see the chicken and egg problems here, but it would be nice to see a
23884 couple of genuine uses before making additions."</p>
23885 <p>A number of libraries, including Rogue Wave, GNU, Adobe ASL, and Boost, have
23886 already added these functions, either publicly or for internal use. For example,
23887 Doug Gregor commented: "Boost will also add ... (|, &amp;, ^) in 1.35.0, because we
23888 need those <span id="st" name="st" class="st">function</span>
23889 <span id="st" name="st" class="st">objects</span> to represent various parallel
23890 collective operations (reductions, prefix reductions, etc.) in the new Message
23891 Passing Interface (MPI) library."</p>
23892 <p>Because the bitwise operators have the strongest use cases, the proposed
23893 resolution is limited to them.</p>
23894
23895
23896 <p><b>Proposed resolution:</b></p>
23897 <p>To 20.5 [function.objects], Function objects, paragraph 2, add to the header
23898 &lt;functional&gt; synopsis:</p>
23899 <blockquote>
23900   <pre>template &lt;class T&gt; struct bit_and;
23901 template &lt;class T&gt; struct bit_or;
23902 template &lt;class T&gt; struct bit_xor;</pre>
23903 </blockquote>
23904 <p>At a location in clause 20 to be determined by the Project Editor, add:</p>
23905 <blockquote>
23906   <p>The library provides basic function object classes for all of the bitwise
23907   operators in the language ([expr.bit.and], [expr.or], [exp.xor]).</p>
23908   <pre>template &lt;class T&gt; struct bit_and : binary_function&lt;T,T,T&gt; {
23909   T operator()(const T&amp; x , const T&amp; y ) const;
23910 };</pre>
23911   <blockquote>
23912     <p><code>operator()</code> returns<code> x &amp; y</code> .</p>
23913   </blockquote>
23914   <pre>template &lt;class T&gt; struct bit_or : binary_function&lt;T,T,T&gt; {
23915   T operator()(const T&amp; x , const T&amp; y ) const;
23916 };</pre>
23917   <blockquote>
23918     <p><code>operator()</code> returns <code>x | y</code> .</p>
23919   </blockquote>
23920   <pre>template &lt;class T&gt; struct bit_xor : binary_function&lt;T,T,T&gt; {
23921   T operator()(const T&amp; x , const T&amp; y ) const;
23922 };</pre>
23923   <blockquote>
23924     <p><code>operator()</code> returns <code>x ^ y</code> .</p>
23925   </blockquote>
23926 </blockquote>
23927
23928
23929
23930
23931
23932 <hr>
23933 <h3><a name="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</h3>
23934 <p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
23935  <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
23936 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
23937 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p>
23938 <p><b>Discussion:</b></p>
23939 <p>
23940 <tt>seed_seq::randomize</tt> provides a mechanism for initializing random number
23941 engines which ideally would yield "distant" states when given "close"
23942 seeds.  The algorithm for <tt>seed_seq::randomize</tt> given in the current
23943 Working Draft for C++,
23944 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
23945 (2007-05-08), has 3 weaknesses
23946 </p>
23947
23948 <ol>
23949 <li>
23950 <p> Collisions in state.  Because of the way the state is initialized,
23951     seeds of different lengths may result in the same state.  The
23952     current version of seed_seq has the following properties:</p>
23953 <ul>
23954 <li>  For a given <tt>s &lt;= n</tt>, each of the 2^(32s) seed vectors results in a
23955       distinct state.</li>
23956 </ul>
23957 <p>
23958     The proposed algorithm (below) has the considerably stronger
23959     properties:</p>
23960 <ul>
23961 <li>   All of the <tt>(2^(32n)-1)/(2^32-1)</tt> seed vectors of lengths <tt>s &lt; n</tt>
23962       result in distinct states.
23963 </li>
23964 <li>  All of the <tt>2^(32n)</tt> seed vectors of length <tt>s == n</tt> result in
23965       distinct states.
23966 </li>
23967 </ul>
23968 </li>
23969 <li>
23970 <p> Poor mixing of <tt>v'</tt>s entropy into the state.  Consider <tt>v.size() == n</tt>
23971     and hold <tt>v[n/2]</tt> thru <tt>v[n-1]</tt> fixed while varying <tt>v[0]</tt> thru <tt>v[n/2-1]</tt>,
23972     a total of <tt>2^(16n)</tt> possibilities.  Because of the simple recursion
23973     used in <tt>seed_seq</tt>, <tt>begin[n/2]</tt> thru <tt>begin[n-1]</tt> can take on only 2^64
23974     possible states.</p>
23975
23976 <p> The proposed algorithm uses a more complex recursion which results
23977     in much better mixing.</p>
23978 </li>
23979 <li> <tt>seed_seq::randomize</tt> is undefined for <tt>v.size() == 0</tt>.  The proposed
23980     algorithm remedies this.
23981 </li>
23982 </ol>
23983 <p>
23984 The current algorithm for <tt>seed_seq::randomize</tt> is adapted by me from the
23985 initialization procedure for the Mersenne Twister by Makoto Matsumoto
23986 and Takuji Nishimura.  The weakness (2) given above was communicated to
23987 me by Matsumoto last year.
23988 </p>
23989 <p>
23990 The proposed replacement for <tt>seed_seq::randomize</tt> is due to Mutsuo Saito,
23991 a student of Matsumoto, and is given in the implementation of the
23992 SIMD-oriented Fast Mersenne Twister random number generator SFMT.
23993 <a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/index.html">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html</a>
23994 <a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/SFMT-src-1.2.tar.gz">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz</a>
23995 </p>
23996 <p>
23997 See
23998 Mutsuo Saito,
23999 An Application of Finite Field: Design and Implementation of 128-bit
24000 Instruction-Based Fast Pseudorandom Number Generator,
24001 Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
24002 <a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/M062821.pdf">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf</a>
24003 </p>
24004 <p>
24005 One change has been made here, namely to treat the case of small <tt>n</tt>
24006 (setting <tt>t = (n-1)/2</tt> for <tt>n &lt; 7</tt>).
24007 </p>
24008 <p>
24009 Since <tt>seed_seq</tt> was introduced relatively recently there is little cost
24010 in making this incompatible improvement to it.
24011 </p>
24012
24013 <p>
24014 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
24015 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
24016 for some further discussion.
24017 </p>
24018
24019
24020 <p><b>Proposed resolution:</b></p>
24021 <p>
24022 Adopt the proposed resolution in
24023 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
24024 </p>
24025
24026
24027 <p><i>[
24028 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
24029 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
24030 ]</i></p>
24031
24032
24033
24034
24035
24036 <hr>
24037 <h3><a name="678"></a>678. Changes for [rand.req.eng]</h3>
24038 <p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24039  <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
24040 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
24041 <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>
24042 <p><b>Discussion:</b></p>
24043 <p>
24044 Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
24045 </p>
24046
24047 <p>
24048 This change follows naturally from the proposed change to
24049 <tt>seed_seq::randomize</tt> in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>.
24050 </p>
24051
24052 <p>
24053 In table 104 the description of <tt>X(q)</tt> contains a special treatment of
24054 the case <tt>q.size() == 0</tt>.  This is undesirable for 4 reasons:
24055 </p>
24056
24057 <ol>
24058 <li>It replicates the functionality provided by <tt>X()</tt>.</li>
24059 <li>It leads to the possibility of a collision in the state provided
24060     by some other <tt>X(q)</tt> with <tt>q.size() &gt; 0</tt>.</li>
24061 <li>It is inconsistent with the description of the <tt>X(q)</tt> in
24062 paragraphs 26.4.3.1 [rand.eng.lcong] p5, 26.4.3.2 [rand.eng.mers] p8, and 26.4.3.3 [rand.eng.sub] p10 where
24063 there is no special treatment of <tt>q.size() == 0</tt>.</li>
24064 <li>The proposed replacement for <tt>seed_seq::randomize</tt> given above
24065     allows for the case <tt>q.size() == 0</tt>.</li>
24066 </ol>
24067
24068 <p>
24069 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
24070 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
24071 for some further discussion.
24072 </p>
24073
24074
24075 <p><b>Proposed resolution:</b></p>
24076 <p>
24077 Adopt the proposed resolution in
24078 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
24079 </p>
24080
24081
24082 <p><i>[
24083 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
24084 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
24085 ]</i></p>
24086
24087
24088
24089
24090
24091 <hr>
24092 <h3><a name="681"></a>681. Operator functions impossible to compare are defined in [re.submatch.op]</h3>
24093 <p><b>Section:</b> 28.9.2 [re.submatch.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24094  <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p>
24095 <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>
24096 <p><b>Discussion:</b></p>
24097 <p>
24098 In 28.9.2 [re.submatch.op] of N2284,
24099 operator functions numbered 31-42 seem impossible to compare. &nbsp;E.g.:
24100 </p>
24101
24102 <blockquote>
24103 <pre>
24104 template &lt;class BiIter&gt;
24105 &nbsp; &nbsp; bool operator==(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
24106 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; const sub_match&lt;BiIter&gt;&amp; rhs);
24107 </pre>
24108 <blockquote>
24109 <p>
24110 -31- <i>Returns:</i> <tt>lhs == rhs.str()</tt>.
24111 </p>
24112 </blockquote>
24113 </blockquote>
24114
24115 <p>
24116 When <tt>char*</tt> is used as <tt>BiIter</tt>, <tt>iterator_traits&lt;BiIter&gt;::value_type</tt> would be
24117 <tt>char</tt>, so that <tt>lhs == rhs.str()</tt> ends up comparing a <tt>char</tt> value and an object
24118 of <tt>std::basic_string&lt;char&gt;</tt>. &nbsp;However, the behaviour of comparison between
24119 these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
24120 &nbsp;This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>.
24121 </p>
24122
24123
24124 <p><b>Proposed resolution:</b></p>
24125 <p>
24126 Adopt the proposed resolution in
24127 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
24128 </p>
24129
24130
24131 <p><i>[
24132 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
24133 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
24134 ]</i></p>
24135
24136
24137
24138
24139
24140 <hr>
24141 <h3><a name="682"></a>682. basic_regex ctor takes InputIterator or ForwardIterator?</h3>
24142 <p><b>Section:</b> 28.8.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
24143  <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-03</p>
24144 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p>
24145 <p><b>Discussion:</b></p>
24146 <p>
24147 Looking at N2284, 28.8 [re.regex], p3 <tt>basic_regex</tt> class template synopsis shows this
24148 constructor:
24149 </p>
24150 <blockquote><pre>template &lt;class InputIterator&gt;
24151 &nbsp; &nbsp; &nbsp;basic_regex(InputIterator first, InputIterator last,
24152 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;flag_type f = regex_constants::ECMAScript);
24153 </pre></blockquote>
24154
24155 <p>
24156 In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature:
24157 </p>
24158
24159 <blockquote><pre>template &lt;class ForwardIterator&gt;
24160 &nbsp; &nbsp; &nbsp;basic_regex(ForwardIterator first, ForwardIterator last,
24161 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;flag_type f = regex_constants::ECMAScript);
24162 </pre></blockquote>
24163
24164 <p>
24165 <tt>ForwardIterator</tt> is probably correct, so the synopsis is wrong.
24166 </p>
24167
24168 <p><i>[
24169 John adds:
24170 ]</i></p>
24171
24172
24173 <blockquote>
24174 <p>
24175 I think either could be implemented? &nbsp;Although an input iterator would
24176 probably require an internal copy of the string being made.
24177 </p>
24178 <p>
24179 I have no strong feelings either way, although I think my original intent
24180 was <tt>InputIterator</tt>.
24181 </p>
24182 </blockquote>
24183
24184
24185 <p><b>Proposed resolution:</b></p>
24186 <p>
24187 Adopt the proposed resolution in
24188 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
24189 </p>
24190
24191
24192 <p><i>[
24193 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
24194 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
24195 ]</i></p>
24196
24197
24198
24199
24200
24201 <hr>
24202 <h3><a name="699"></a>699. N2111 changes min/max</h3>
24203 <p><b>Section:</b> 26.4 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24204  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</p>
24205 <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>
24206 <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>
24207 <p><b>Discussion:</b></p>
24208 <p>
24209 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
24210 changes <tt>min/max</tt> in several places in random from member
24211 functions to static data members. I believe this introduces
24212 a needless backward compatibility problem between C++0X and
24213 TR1. I'd like us to find new names for the static data members,
24214 or perhaps change <tt>min/max</tt> to <tt>constexpr</tt>s in C++0X.
24215 </p>
24216
24217 <p>
24218 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
24219 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
24220 for some further discussion.
24221 </p>
24222
24223
24224 <p><b>Proposed resolution:</b></p>
24225 <p>
24226 Adopt the proposed resolution in
24227 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
24228 </p>
24229
24230
24231 <p><i>[
24232 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
24233 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
24234 ]</i></p>
24235
24236
24237
24238
24239
24240 <hr>
24241 <h3><a name="712"></a>712. <tt>seed_seq::size</tt> no longer useful</h3>
24242 <p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24243  <b>Submitter:</b> Marc Paterno <b>Date:</b> 2007-08-25</p>
24244 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
24245 <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>
24246 <p><b>Discussion:</b></p>
24247 <p>
24248 One of the motivations for incorporating <tt>seed_seq::size()</tt>
24249 was to simplify the wording
24250 in other parts of 26.4 [rand].
24251 As a side effect of resolving related issues,
24252 all such references
24253 to <tt>seed_seq::size()</tt> will have been excised.
24254 More importantly,
24255 the present specification is contradictory,
24256 as "The number of 32-bit units the object can deliver"
24257 is not the same as "the result of <tt>v.size()</tt>."
24258 </p>
24259
24260 <p>
24261 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
24262 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
24263 for some further discussion.
24264 </p>
24265
24266
24267 <p><b>Proposed resolution:</b></p>
24268 <p>
24269 Adopt the proposed resolution in
24270 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
24271 </p>
24272
24273
24274 <p><i>[
24275 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
24276 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
24277 ]</i></p>
24278
24279
24280
24281
24282
24283
24284 </body></html>