libstdc++-v3/docs/html/ext/lwg-closed.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 Closed Issues 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">N2458=07-0328</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 Closed Issues 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-defects.html">Library Defect Reports List</a></li>
  40     </ul>
  41
  42   <p>This document contains only library issues which have been closed
  43   by the Library Working Group as duplicates or not defects. That is,
  44   issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> or
  45   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> active issues and more
  46   information. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered
  47   defects.  The introductory material in that document also applies to
  48   this 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>Closed Issues</h2>
 523 <hr>
 524 <h3><a name="2"></a>2. Auto_ptr conversions effects incorrect</h3>
 525 <p><b>Section:</b> D.9.1.3 [auto.ptr.conv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 526  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1997-12-04</p>
 527 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 528 <p><b>Discussion:</b></p>
 529 <p>Paragraph 1 in "Effects", says "Calls
 530 p-&gt;release()" where it clearly must be "Calls
 531 p.release()". (As it is, it seems to require using
 532 auto_ptr&lt;&gt;::operator-&gt; to refer to X::release, assuming that
 533 exists.)</p>
 534
 535
 536 <p><b>Proposed resolution:</b></p>
 537 <p>Change 20.4.4.3 [meta.unary.prop] paragraph 1 Effects from
 538 "Calls p-&gt;release()" to "Calls p.release()".</p>
 539
 540
 541 <p><b>Rationale:</b></p>
 542 <p>Not a defect: the proposed change is already found in the standard.
 543 [Originally classified as a defect, later reclassified.]</p>
 544
 545
 546
 547
 548
 549 <hr>
 550 <h3><a name="4"></a>4. Basic_string size_type and difference_type should be implementation defined</h3>
 551 <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#NAD">NAD</a>
 552  <b>Submitter:</b> Beman Dawes <b>Date:</b> 1997-11-16</p>
 553 <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>
 554 <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>
 555 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 556 <p><b>Discussion:</b></p>
 557 <p>In Morristown we changed the size_type and difference_type typedefs
 558 for all the other containers to implementation defined with a
 559 reference to 23.1 [container.requirements].  This should probably also have been
 560 done for strings. </p>
 561
 562
 563 <p><b>Rationale:</b></p>
 564 <p>Not a defect.  [Originally classified as a defect, later
 565 reclassified.]  basic_string, unlike the other standard library
 566 template containers, is severely constrained by its use of
 567 char_traits. Those types are dictated by the traits class, and are far
 568 from implementation defined.</p>
 569
 570
 571
 572
 573
 574 <hr>
 575 <h3><a name="6"></a>6. File position not an offset unimplementable</h3>
 576 <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#NAD">NAD</a>
 577  <b>Submitter:</b> Matt Austern <b>Date:</b> 1997-12-15</p>
 578 <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>
 579 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 580 <p><b>Discussion:</b></p>
 581 <p>Table 88, in I/O, is too strict; it's unimplementable on systems
 582 where a file position isn't just an offset. It also never says just
 583 what fpos&lt;&gt; is really supposed to be.  [Here's my summary, which
 584 Jerry agrees is more or less accurate. "I think I now know what
 585 the class really is, at this point: it's a magic cookie that
 586 encapsulates an mbstate_t and a file position (possibly represented as
 587 an fpos_t), it has syntactic support for pointer-like arithmetic, and
 588 implementors are required to have real, not just syntactic, support
 589 for arithmetic." This isn't standardese, of course.] </p>
 590
 591
 592 <p><b>Rationale:</b></p>
 593 <p>Not a defect. The LWG believes that the Standard is already clear,
 594 and that the above summary is what the Standard in effect says.</p>
 595
 596
 597
 598
 599
 600 <hr>
 601 <h3><a name="10"></a>10. Codecvt&lt;&gt;::do unclear</h3>
 602 <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#Dup">Dup</a>
 603  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-14</p>
 604 <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>
 605 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
 606 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a></p>
 607 <p><b>Discussion:</b></p>
 608 <p>Section 22.2.1.5.2 says that codecvt&lt;&gt;::do_in and do_out
 609 should return the value noconv if "no conversion was
 610 needed". However, I don't see anything anywhere that defines what
 611 it means for a conversion to be needed or not needed. I can think of
 612 several circumstances where one might plausibly think that a
 613 conversion is not "needed", but I don't know which one is
 614 intended here. </p>
 615
 616
 617 <p><b>Rationale:</b></p>
 618
 619
 620
 621
 622
 623
 624 <hr>
 625 <h3><a name="12"></a>12. Way objects hold allocators unclear</h3>
 626 <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#NAD">NAD</a>
 627  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1998-02-23</p>
 628 <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>
 629 <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>
 630 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 631 <p><b>Discussion:</b></p>
 632 <p>I couldn't find a statement in the standard saying whether the allocator object held by
 633 a container is held as a copy of the constructor argument or whether a pointer of
 634 reference is maintained internal. There is an according statement for compare objects and
 635 how they are maintained by the associative containers, but I couldn't find anything
 636 regarding allocators. </p>
 637
 638 <p>Did I overlook it? Is it an open issue or known defect? Or is it deliberately left
 639 unspecified? </p>
 640
 641
 642 <p><b>Rationale:</b></p>
 643 <p>Not a defect. The LWG believes that the Standard is already
 644 clear.&nbsp; See 23.1 [container.requirements], paragraph 8.</p>
 645
 646
 647
 648
 649
 650 <hr>
 651 <h3><a name="43"></a>43. Locale table correction</h3>
 652 <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#Dup">Dup</a>
 653  <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1998-06-01</p>
 654 <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>
 655 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
 656 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a></p>
 657 <p><b>Discussion:</b></p>
 658
 659
 660 <p><b>Rationale:</b></p>
 661
 662
 663
 664
 665
 666
 667 <hr>
 668 <h3><a name="45"></a>45. Stringstreams read/write pointers initial position unclear</h3>
 669 <p><b>Section:</b> 27.7.3 [ostringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 670  <b>Submitter:</b> Matthias Mueller <b>Date:</b> 1998-05-27</p>
 671 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 672 <p><b>Discussion:</b></p>
 673 <p>In a comp.lang.c++.moderated Matthias Mueller wrote:</p>
 674
 675 <p>"We are not sure how to interpret the CD2 (see 27.2
 676 [iostream.forward], 27.7.3.1 [ostringstream.cons], 27.7.1.1
 677 [stringbuf.cons])
 678 with respect to the question as to what the correct initial positions
 679 of the write and&nbsp; read pointers of a stringstream should
 680 be."</p>
 681
 682 <p>"Is it the same to output two strings or to initialize the stringstream with the
 683 first and to output the second?"</p>
 684
 685 <p><i>[PJ Plauger, Bjarne Stroustrup, Randy Smithey, Sean Corfield, and
 686 Jerry Schwarz have all offered opinions; see reflector messages
 687 lib-6518, 6519, 6520, 6521, 6523, 6524.]</i></p>
 688
 689
 690
 691
 692 <p><b>Rationale:</b></p>
 693 <p>The LWG believes the Standard is correct as written. The behavior
 694 of stringstreams is consistent with fstreams, and there is a
 695 constructor which can be used to obtain the desired effect. This
 696 behavior is known to be different from strstreams.</p>
 697
 698
 699
 700
 701
 702 <hr>
 703 <h3><a name="58"></a>58. Extracting a char from a wide-oriented stream</h3>
 704 <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#NAD">NAD</a>
 705  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-07-01</p>
 706 <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>
 707 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 708 <p><b>Discussion:</b></p>
 709 <p>27.6.1.2.3 has member functions for extraction of signed char and
 710 unsigned char, both singly and as strings. However, it doesn't say
 711 what it means to extract a <tt>char</tt> from a
 712 <tt>basic_streambuf&lt;charT, Traits&gt;</tt>. </p>
 713
 714 <p>basic_streambuf, after all, has no members to extract a char, so
 715 basic_istream must somehow convert from charT to signed char or
 716 unsigned char. The standard doesn't say how it is to perform that
 717 conversion. </p>
 718
 719
 720 <p><b>Rationale:</b></p>
 721 <p>The Standard is correct as written.  There is no such extractor and
 722 this is the intent of the LWG.</p>
 723
 724
 725
 726
 727 <hr>
 728 <h3><a name="65"></a>65. Underspecification of strstreambuf::seekoff</h3>
 729 <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#NAD">NAD</a>
 730  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-18</p>
 731 <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>
 732 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 733 <p><b>Discussion:</b></p>
 734 <p>The standard says how this member function affects the current
 735 stream position. (<tt>gptr</tt> or <tt>pptr</tt>) However, it does not
 736 say how this member function affects the beginning and end of the
 737 get/put area. </p>
 738
 739 <p>This is an issue when seekoff is used to position the get pointer
 740 beyond the end of the current read area. (Which is legal. This is
 741 implicit in the definition of <i>seekhigh</i> in D.7.1, paragraph 4.)
 742 </p>
 743
 744
 745 <p><b>Rationale:</b></p>
 746 <p>The LWG agrees that seekoff() is underspecified, but does not wish
 747 to invest effort in this deprecated feature.</p>
 748
 749
 750
 751
 752
 753 <hr>
 754 <h3><a name="67"></a>67. Setw useless for strings</h3>
 755 <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#Dup">Dup</a>
 756  <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-07-09</p>
 757 <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>
 758 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
 759 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a></p>
 760 <p><b>Discussion:</b></p>
 761 <p>In a comp.std.c++ posting Michel Michaud wrote: What
 762 should be output by: </p>
 763
 764 <pre>   string text("Hello");
 765    cout &lt;&lt; '[' &lt;&lt; setw(10) &lt;&lt; right &lt;&lt; text &lt;&lt; ']';
 766 </pre>
 767
 768 <p>Shouldn't it be:</p>
 769
 770 <pre>   [     Hello]</pre>
 771
 772 <p>Another person replied: Actually, according to the FDIS, the width
 773 of the field should be the minimum of width and the length of the
 774 string, so the output shouldn't have any padding. I think that this is
 775 a typo, however, and that what is wanted is the maximum of the
 776 two. (As written, setw is useless for strings. If that had been the
 777 intent, one wouldn't expect them to have mentioned using its value.)
 778 </p>
 779
 780 <p>It's worth pointing out that this is a recent correction anyway;
 781 IIRC, earlier versions of the draft forgot to mention formatting
 782 parameters whatsoever.</p>
 783
 784
 785 <p><b>Rationale:</b></p>
 786
 787
 788
 789
 790
 791
 792 <hr>
 793 <h3><a name="72"></a>72. Do_convert phantom member function</h3>
 794 <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#Dup">Dup</a>
 795  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-24</p>
 796 <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>
 797 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
 798 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a></p>
 799 <p><b>Discussion:</b></p>
 800 <p>In 22.2.1.4 [locale.codecvt] par 3, and in 22.2.1.4.2 [locale.codecvt.virtuals] par 8, a nonexistent member function
 801 "do_convert" is mentioned. This member was replaced with
 802 "do_in" and "do_out", the proper referents in the
 803 contexts above.</p>
 804
 805
 806 <p><b>Rationale:</b></p>
 807
 808
 809
 810
 811
 812 <hr>
 813 <h3><a name="73"></a>73. <tt>is_open</tt> should be const</h3>
 814 <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#NAD">NAD</a>
 815  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-27</p>
 816 <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>
 817 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 818 <p><b>Discussion:</b></p>
 819 <p>Classes <tt>basic_ifstream</tt>, <tt>basic_ofstream</tt>, and
 820 <tt>basic_fstream</tt> all have a member function <tt>is_open</tt>. It
 821 should be a <tt>const</tt> member function, since it does nothing but
 822 call one of <tt>basic_filebuf</tt>'s const member functions. </p>
 823
 824
 825 <p><b>Rationale:</b></p>
 826 <p>Not a defect. This is a deliberate feature; const streams would be
 827 meaningless.</p>
 828
 829
 830
 831
 832 <hr>
 833 <h3><a name="77"></a>77. Valarray operator[] const returning value</h3>
 834 <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#Dup">Dup</a>
 835  <b>Submitter:</b> Levente Farkas <b>Date:</b> 1998-09-09</p>
 836 <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>
 837 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
 838 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a></p>
 839 <p><b>Discussion:</b></p>
 840 <p>valarray:<br>
 841 <br>
 842 &nbsp;&nbsp;&nbsp; <tt>T operator[] (size_t) const;</tt><br>
 843 <br>
 844 why not <br>
 845 <br>
 846 &nbsp;&nbsp;&nbsp; <tt>const T&amp; operator[] (size_t) const;</tt><br>
 847 <br>
 848 as in vector ???<br>
 849 <br>
 850 One can't copy even from a const valarray eg:<br>
 851 <br>
 852 &nbsp;&nbsp;&nbsp; <tt>memcpy(ptr, &amp;v[0], v.size() * sizeof(double));<br>
 853 </tt><br>
 854 [I] find this bug in valarray is very difficult.</p>
 855
 856
 857 <p><b>Rationale:</b></p>
 858 <p>The LWG believes that the interface was deliberately designed that
 859 way. That is what valarray was designed to do; that's where the
 860 "value array" name comes from. LWG members further comment
 861 that "we don't want valarray to be a full STL container."
 862 26.5.2.3 [valarray.access] specifies properties that indicate "an
 863 absence of aliasing" for non-constant arrays; this allows
 864 optimizations, including special hardware optimizations, that are not
 865 otherwise possible. </p>
 866
 867
 868
 869
 870
 871 <hr>
 872 <h3><a name="81"></a>81. Wrong declaration of slice operations</h3>
 873 <p><b>Section:</b> 26.5.5 [template.slice.array], 26.5.7 [template.gslice.array], 26.5.8 [template.mask.array], 26.5.9 [template.indirect.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 874  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
 875 <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>
 876 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 877 <p><b>Discussion:</b></p>
 878 <p>Isn't the definition of copy constructor and assignment operators wrong?
 879 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Instead of</p>
 880
 881 <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; slice_array(const slice_array&amp;);
 882 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; slice_array&amp; operator=(const slice_array&amp;);</pre>
 883
 884 <p>IMHO they have to be</p>
 885
 886 <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;slice_array(const slice_array&lt;T&gt;&amp;);
 887 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;slice_array&amp; operator=(const slice_array&lt;T&gt;&amp;);</pre>
 888
 889 <p>Same for gslice_array. </p>
 890
 891
 892 <p><b>Rationale:</b></p>
 893 <p>Not a defect. The Standard is correct as written. </p>
 894
 895
 896
 897
 898 <hr>
 899 <h3><a name="82"></a>82. Missing constant for set elements</h3>
 900 <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#NAD">NAD</a>
 901  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
 902 <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>
 903 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 904 <p><b>Discussion:</b></p>
 905 <p>Paragraph 5 specifies:</p>
 906
 907 <blockquote><p>
 908 For set and multiset the value type is the same as the key type. For
 909 map and multimap it is equal to pair&lt;const Key, T&gt;.
 910 </p></blockquote>
 911
 912 <p>Strictly speaking, this is not correct because for set and multiset
 913 the value type is the same as the <b>constant</b> key type.</p>
 914
 915
 916 <p><b>Rationale:</b></p>
 917 <p>Not a defect. The Standard is correct as written; it uses a
 918 different mechanism (const &amp;) for <tt>set</tt> and
 919 <tt>multiset</tt>. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for a related
 920 issue.</p>
 921
 922
 923
 924
 925 <hr>
 926 <h3><a name="84"></a>84. Ambiguity with string::insert()</h3>
 927 <p><b>Section:</b> 21.3.5 [string.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 928  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
 929 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 930 <p><b>Discussion:</b></p>
 931 <p>If I try</p>
 932 <pre>    s.insert(0,1,' ');</pre>
 933
 934 <p>&nbsp; I get an nasty ambiguity. It might be</p>
 935 <pre>    s.insert((size_type)0,(size_type)1,(charT)' ');</pre>
 936
 937 <p>which inserts 1 space character at position 0, or</p>
 938 <pre>    s.insert((char*)0,(size_type)1,(charT)' ')</pre>
 939
 940 <p>which inserts 1 space character at iterator/address 0 (bingo!), or</p>
 941 <pre>    s.insert((char*)0, (InputIterator)1, (InputIterator)' ')</pre>
 942
 943 <p>which normally inserts characters from iterator 1 to iterator '
 944 '. But according to 23.1.1.9 (the "do the right thing" fix)
 945 it is equivalent to the second. However, it is still ambiguous,
 946 because of course I mean the first!</p>
 947
 948
 949 <p><b>Rationale:</b></p>
 950 <p>Not a defect. The LWG believes this is a "genetic
 951 misfortune" inherent in the design of string and thus not a
 952 defect in the Standard as such .</p>
 953
 954
 955
 956
 957 <hr>
 958 <h3><a name="85"></a>85. String char types</h3>
 959 <p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 960  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
 961 <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>
 962 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 963 <p><b>Discussion:</b></p>
 964 <p>The standard seems not to require that charT is equivalent to
 965 traits::char_type. So, what happens if charT is not equivalent to
 966 traits::char_type?</p>
 967
 968
 969 <p><b>Rationale:</b></p>
 970 <p>There is already wording in 21.1 [char.traits] paragraph 3 that
 971 requires them to be the same.</p>
 972
 973
 974
 975
 976 <hr>
 977 <h3><a name="87"></a>87. Error in description of string::compare()</h3>
 978 <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#Dup">Dup</a>
 979  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
 980 <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>
 981 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
 982 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5">5</a></p>
 983 <p><b>Discussion:</b></p>
 984 <p>The following compare() description is obviously a bug:</p>
 985
 986 <pre>int compare(size_type pos, size_type n1,
 987             charT *s, size_type n2 = npos) const;
 988 </pre>
 989
 990 <p>because without passing n2 it should compare up to the end of the
 991 string instead of comparing npos characters (which throws an
 992 exception) </p>
 993
 994
 995 <p><b>Rationale:</b></p>
 996
 997
 998
 999
1000
1001 <hr>
1002 <h3><a name="88"></a>88. Inconsistency between string::insert() and string::append()</h3>
1003 <p><b>Section:</b> 21.3.6.4 [string::insert], 21.3.6.2 [string::append] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1004  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
1005 <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>
1006 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1007 <p><b>Discussion:</b></p>
1008 <p>Why does </p>
1009 <pre>  template&lt;class InputIterator&gt;
1010        basic_string&amp; append(InputIterator first, InputIterator last);</pre>
1011
1012 <p>return a string, while</p>
1013 <pre>  template&lt;class InputIterator&gt;
1014        void insert(iterator p, InputIterator first, InputIterator last);</pre>
1015
1016 <p>returns nothing ?</p>
1017
1018
1019 <p><b>Rationale:</b></p>
1020 <p>The LWG believes this stylistic inconsistency is not sufficiently
1021 serious to constitute a defect.</p>
1022
1023
1024
1025
1026 <hr>
1027 <h3><a name="89"></a>89. Missing throw specification for string::insert() and string::replace()</h3>
1028 <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#Dup">Dup</a>
1029  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
1030 <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>
1031 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1032 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a></p>
1033 <p><b>Discussion:</b></p>
1034 <p>All insert() and replace() members for strings with an iterator as
1035 first argument lack a throw specification. The throw
1036 specification should probably be: length_error if size exceeds
1037 maximum. </p>
1038
1039
1040 <p><b>Rationale:</b></p>
1041 <p>Considered a duplicate because it will be solved by the resolution
1042 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
1043
1044
1045
1046
1047
1048 <hr>
1049 <h3><a name="93"></a>93. Incomplete Valarray Subset Definitions</h3>
1050 <p><b>Section:</b> 26.5 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1051  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
1052 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numarray">issues</a> in [numarray].</p>
1053 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1054 <p><b>Discussion:</b></p>
1055 <p>You can easily create subsets, but you can't easily combine them
1056 with other subsets.  Unfortunately, you almost always needs an
1057 explicit type conversion to valarray. This is because the standard
1058 does not specify that valarray subsets provide the same operations as
1059 valarrays. </p>
1060
1061 <p>For example, to multiply two subsets and assign the result to a third subset, you can't
1062 write the following:</p>
1063
1064 <pre>va[slice(0,4,3)] = va[slice(1,4,3)] * va[slice(2,4,3)];</pre>
1065
1066 <p>Instead, you have to code as follows:</p>
1067
1068 <pre>va[slice(0,4,3)] = static_cast&lt;valarray&lt;double&gt; &gt;(va[slice(1,4,3)]) *
1069                    static_cast&lt;valarray&lt;double&gt; &gt;(va[slice(2,4,3)]);</pre>
1070
1071 <p>This is tedious and error-prone. Even worse, it costs performance because each cast
1072 creates a temporary objects, which could be avoided without the cast. </p>
1073
1074
1075 <p><b>Proposed resolution:</b></p>
1076 <p>Extend all valarray subset types so that they offer all valarray operations.</p>
1077
1078
1079 <p><b>Rationale:</b></p>
1080 <p>This is not a defect in the Standard; it is a request for an extension.</p>
1081
1082
1083
1084
1085 <hr>
1086 <h3><a name="94"></a>94. May library implementors add template parameters to Standard Library classes?</h3>
1087 <p><b>Section:</b> 17.4.4 [conforming] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1088  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-22</p>
1089 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1090 <p><b>Discussion:</b></p>
1091 <p>Is it a permitted extension for library implementors to add template parameters to
1092 standard library classes, provided that those extra parameters have defaults? For example,
1093 instead of defining <tt>template &lt;class T, class Alloc = allocator&lt;T&gt; &gt; class
1094 vector;</tt> defining it as <tt>template &lt;class T, class Alloc = allocator&lt;T&gt;,
1095 int N = 1&gt; class vector;</tt> </p>
1096
1097 <p>The standard may well already allow this (I can't think of any way that this extension
1098 could break a conforming program, considering that users are not permitted to
1099 forward-declare standard library components), but it ought to be explicitly permitted or
1100 forbidden. </p>
1101
1102 <p>comment from Steve Cleary via comp.std.c++:</p>
1103 <blockquote>
1104 <p>I disagree [with the proposed resolution] for the following reason:
1105 consider user library code with template template parameters. For
1106 example, a user library object may be templated on the type of
1107 underlying sequence storage to use (deque/list/vector), since these
1108 classes all take the same number and type of template parameters; this
1109 would allow the user to determine the performance tradeoffs of the
1110 user library object. A similar example is a user library object
1111 templated on the type of underlying set storage (set/multiset) or map
1112 storage (map/multimap), which would allow users to change (within
1113 reason) the semantic meanings of operations on that object.</p>
1114 <p>I think that additional template parameters should be forbidden in
1115 the Standard classes. Library writers don't lose any expressive power,
1116 and can still offer extensions because additional template parameters
1117 may be provided by a non-Standard implementation class:</p>
1118 <pre>
1119    template &lt;class T, class Allocator = allocator&lt;T&gt;, int N = 1&gt;
1120    class __vector
1121    { ... };
1122    template &lt;class T, class Allocator = allocator&lt;T&gt; &gt;
1123    class vector: public __vector&lt;T, Allocator&gt;
1124    { ... };
1125 </pre>
1126
1127 </blockquote>
1128
1129
1130
1131 <p><b>Proposed resolution:</b></p>
1132 <p>Add a new subclause [presumably 17.4.4.9] following 17.4.4.8 [res.on.exception.handling]:</p>
1133
1134 <blockquote>
1135   <p>17.4.4.9 Template Parameters</p> <p>A specialization of a
1136   template class described in the C++ Standard Library behaves the
1137   same as if the implementation declares no additional template
1138   parameters.</p> <p>Footnote: Additional template parameters with
1139   default values are thus permitted.</p>
1140 </blockquote>
1141
1142 <p>Add "template parameters" to the list of subclauses at
1143 the end of 17.4.4 [conforming] paragraph 1.</p>
1144
1145 <p><i>[Kona: The LWG agreed the standard needs clarification. After
1146 discussion with John Spicer, it seems added template parameters can be
1147 detected by a program using template-template parameters. A straw vote
1148 - "should implementors be allowed to add template
1149 parameters?" found no consensus ; 5 - yes, 7 - no.]</i></p>
1150
1151
1152
1153
1154 <p><b>Rationale:</b></p>
1155 <p>
1156 There is no ambiguity; the standard is clear as written.  Library
1157 implementors are not permitted to add template parameters to standard
1158 library classes.  This does not fall under the "as if" rule,
1159 so it would be permitted only if the standard gave explicit license
1160 for implementors to do this.  This would require a change in the
1161 standard.
1162 </p>
1163
1164 <p>
1165 The LWG decided against making this change, because it would break
1166 user code involving template template parameters or specializations
1167 of standard library class templates.
1168 </p>
1169
1170
1171
1172
1173
1174 <hr>
1175 <h3><a name="95"></a>95. Members added by the implementation</h3>
1176 <p><b>Section:</b> 17.4.4.4 [member.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1177  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1178 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1179 <p><b>Discussion:</b></p>
1180 <p>In 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual
1181 members a base class and break user derived classes.</p>
1182
1183 <p>Example: </p>
1184
1185 <blockquote>
1186   <pre>// implementation code:
1187 struct _Base { // _Base is in the implementer namespace
1188         virtual void foo ();
1189 };
1190 class vector : _Base // deriving from a class is allowed
1191 { ... };
1192
1193 // user code:
1194 class vector_checking : public vector
1195 {
1196         void foo (); // don't want to override _Base::foo () as the
1197                      // user doesn't know about _Base::foo ()
1198 };</pre>
1199 </blockquote>
1200
1201
1202 <p><b>Proposed resolution:</b></p>
1203 <p>Clarify the wording to make the example illegal.</p>
1204
1205
1206 <p><b>Rationale:</b></p>
1207 <p>This is not a defect in the Standard.&nbsp; The example is already
1208 illegal.&nbsp; See 17.4.4.4 [member.functions] paragraph 2.</p>
1209
1210
1211
1212
1213 <hr>
1214 <h3><a name="97"></a>97. Insert inconsistent definition</h3>
1215 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1216  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1217 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
1218 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1219 <p><b>Discussion:</b></p>
1220 <p><tt>insert(iterator, const value_type&amp;)</tt> is defined both on
1221 sequences and on set, with unrelated semantics: insert here (in
1222 sequences), and insert with hint (in associative containers). They
1223 should have different names (B.S. says: do not abuse overloading).</p>
1224
1225
1226 <p><b>Rationale:</b></p>
1227 <p>This is not a defect in the Standard. It is a genetic misfortune of
1228 the design, for better or for worse.</p>
1229
1230
1231
1232
1233 <hr>
1234 <h3><a name="99"></a>99. Reverse_iterator comparisons completely wrong</h3>
1235 <p><b>Section:</b> 24.4.1.3.13 [reverse.iter.op==] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1236  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1237 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1238 <p><b>Discussion:</b></p>
1239 <p>The &lt;, &gt;, &lt;=, &gt;= comparison operator are wrong: they
1240 return the opposite of what they should.</p>
1241
1242 <p>Note: same problem in CD2, these were not even defined in CD1.  SGI
1243 STL code is correct; this problem is known since the Morristown
1244 meeting but there it was too late</p>
1245
1246
1247 <p><b>Rationale:</b></p>
1248 <p>This is not a defect in the Standard. A careful reading shows the Standard is correct
1249 as written. A review of several implementations show that they implement
1250 exactly what the Standard says.</p>
1251
1252
1253
1254
1255 <hr>
1256 <h3><a name="100"></a>100. Insert iterators/ostream_iterators overconstrained</h3>
1257 <p><b>Section:</b> 24.4.2 [insert.iterators], 24.5.4 [ostreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1258  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1259 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1260 <p><b>Discussion:</b></p>
1261 <p>Overspecified For an insert iterator it, the expression *it is
1262 required to return a reference to it. This is a simple possible
1263 implementation, but as the SGI STL documentation says, not the only
1264 one, and the user should not assume that this is the case.</p>
1265
1266
1267 <p><b>Rationale:</b></p>
1268 <p>The LWG believes this causes no harm and is not a defect in the
1269 standard. The only example anyone could come up with caused some
1270 incorrect code to work, rather than the other way around.</p>
1271
1272
1273
1274
1275
1276 <hr>
1277 <h3><a name="101"></a>101. No way to free storage for vector and deque</h3>
1278 <p><b>Section:</b> 23.2.5 [vector], 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1279  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1280 <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>
1281 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1282 <p><b>Discussion:</b></p>
1283 <p>Reserve can not free storage, unlike string::reserve</p>
1284
1285
1286 <p><b>Rationale:</b></p>
1287 <p>This is not a defect in the Standard. The LWG has considered this
1288 issue in the past and sees no need to change the Standard. Deque has
1289 no reserve() member function. For vector, shrink-to-fit can be
1290 expressed in a single line of code (where <tt>v</tt> is
1291 <tt>vector&lt;T&gt;</tt>):
1292 </p>
1293
1294 <blockquote>
1295   <p><tt>vector&lt;T&gt;(v).swap(v);&nbsp; // shrink-to-fit v</tt></p>
1296 </blockquote>
1297
1298
1299
1300
1301
1302 <hr>
1303 <h3><a name="102"></a>102. Bug in insert range in associative containers</h3>
1304 <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#Dup">Dup</a>
1305  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1306 <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>
1307 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1308 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a></p>
1309 <p><b>Discussion:</b></p>
1310 <p>Table 69 of Containers say that a.insert(i,j) is linear if [i, j) is ordered. It seems
1311 impossible to implement, as it means that if [i, j) = [x], insert in an associative
1312 container is O(1)!</p>
1313
1314
1315 <p><b>Proposed resolution:</b></p>
1316 <p>N+log (size()) if [i,j) is sorted according to value_comp()</p>
1317
1318
1319 <p><b>Rationale:</b></p>
1320 <p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>.</p>
1321
1322
1323
1324
1325
1326 <hr>
1327 <h3><a name="104"></a>104. Description of basic_string::operator[] is unclear</h3>
1328 <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#NAD">NAD</a>
1329  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1330 <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>
1331 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1332 <p><b>Discussion:</b></p>
1333 <p>It is not clear that undefined behavior applies when pos == size ()
1334 for the non const version.</p>
1335
1336
1337 <p><b>Proposed resolution:</b></p>
1338 <p>Rewrite as: Otherwise, if pos &gt; size () or pos == size () and
1339 the non-const version is used, then the behavior is undefined.</p>
1340
1341
1342 <p><b>Rationale:</b></p>
1343 <p>The Standard is correct. The proposed resolution already appears in
1344 the Standard.</p>
1345
1346
1347
1348
1349 <hr>
1350 <h3><a name="105"></a>105. fstream ctors argument types desired</h3>
1351 <p><b>Section:</b> 27.8 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
1352  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1353 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
1354 <p><b>Discussion:</b></p>
1355 <p>fstream ctors take a const char* instead of string.<br>
1356 fstream ctors can't take wchar_t</p>
1357
1358 <p>An extension to add a const wchar_t* to fstream would make the
1359 implementation non conforming.</p>
1360
1361
1362 <p><b>Rationale:</b></p>
1363 <p>This is not a defect in the Standard. It might be an
1364 interesting extension for the next Standard. </p>
1365
1366
1367
1368
1369 <hr>
1370 <h3><a name="107"></a>107. Valarray constructor is strange</h3>
1371 <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#NAD">NAD</a>
1372  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1373 <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>
1374 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1375 <p><b>Discussion:</b></p>
1376 <p>The order of the arguments is (elem, size) instead of the normal
1377 (size, elem) in the rest of the library. Since elem often has an
1378 integral or floating point type, both types are convertible to each
1379 other and reversing them leads to a well formed program.</p>
1380
1381
1382 <p><b>Proposed resolution:</b></p>
1383 <p>Inverting the arguments could silently break programs. Introduce
1384 the two signatures (const T&amp;, size_t) and (size_t, const T&amp;),
1385 but make the one we do not want private so errors result in a
1386 diagnosed access violation. This technique can also be applied to STL
1387 containers.</p>
1388
1389
1390 <p><b>Rationale:</b></p>
1391 <p>The LWG believes that while the order of arguments is unfortunate,
1392 it does not constitute a defect in the standard. The LWG believes that
1393 the proposed solution will not work for valarray&lt;size_t&gt; and
1394 perhaps other cases.</p>
1395
1396
1397
1398
1399 <hr>
1400 <h3><a name="111"></a>111. istreambuf_iterator::equal overspecified, inefficient</h3>
1401 <p><b>Section:</b> 24.5.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
1402  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-10-15</p>
1403 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
1404 <p><b>Discussion:</b></p>
1405 <p>The member istreambuf_iterator&lt;&gt;::equal is specified to be
1406 unnecessarily inefficient. While this does not affect the efficiency
1407 of conforming implementations of iostreams, because they can
1408 "reach into" the iterators and bypass this function, it does
1409 affect users who use istreambuf_iterators. </p>
1410
1411 <p>The inefficiency results from a too-scrupulous definition, which
1412 requires a "true" result if neither iterator is at eof. In
1413 practice these iterators can only usefully be compared with the
1414 "eof" value, so the extra test implied provides no benefit,
1415 but slows down users' code. </p>
1416
1417 <p>The solution is to weaken the requirement on the function to return
1418 true only if both iterators are at eof. </p>
1419
1420
1421 <p><b>Proposed resolution:</b></p>
1422 <p>Replace 24.5.3.5 [istreambuf.iterator::equal],
1423 paragraph 1, </p>
1424
1425 <blockquote>
1426   <p>-1- Returns: true if and only if both iterators are at end-of-stream, or neither is at
1427   end-of-stream, regardless of what streambuf object they use. </p>
1428 </blockquote>
1429
1430 <p>with</p>
1431
1432 <blockquote>
1433   <p>-1- Returns: true if and only if both iterators are at
1434   end-of-stream, regardless of what streambuf object they use. </p>
1435 </blockquote>
1436
1437
1438
1439 <p><b>Rationale:</b></p>
1440 <p>It is not clear that this is a genuine defect.  Additionally, the
1441 LWG was reluctant to make a change that would result in
1442 operator== not being a equivalence relation.  One consequence of
1443 this change is that an algorithm that's passed the range [i, i)
1444 would no longer treat it as an empty range.</p>
1445
1446
1447
1448
1449
1450 <hr>
1451 <h3><a name="113"></a>113. Missing/extra iostream sync semantics</h3>
1452 <p><b>Section:</b> 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1453  <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-10-13</p>
1454 <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>
1455 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1456 <p><b>Discussion:</b></p>
1457 <p>In 27.6.1.1, class basic_istream has a member function sync, described in 27.6.1.3,
1458 paragraph 36. </p>
1459
1460 <p>Following the chain of definitions, I find that the various sync functions have defined
1461 semantics for output streams, but no semantics for input streams. On the other hand,
1462 basic_ostream has no sync function. </p>
1463
1464 <p>The sync function should at minimum be added to basic_ostream, for internal
1465 consistency. </p>
1466
1467 <p>A larger question is whether sync should have assigned semantics for input streams. </p>
1468
1469 <p>Classic iostreams said streambuf::sync flushes pending output and attempts to return
1470 unread input characters to the source. It is a protected member function. The filebuf
1471 version (which is public) has that behavior (it backs up the read pointer). Class
1472 strstreambuf does not override streambuf::sync, and so sync can't be called on a
1473 strstream. </p>
1474
1475 <p>If we can add corresponding semantics to the various sync functions, we should. If not,
1476 we should remove sync from basic_istream.</p>
1477
1478
1479 <p><b>Rationale:</b></p>
1480 <p>A sync function is not needed in basic_ostream because the flush function provides the
1481 desired functionality.</p>
1482
1483 <p>As for the other points, the LWG finds the standard correct as written.</p>
1484
1485
1486
1487
1488
1489 <hr>
1490 <h3><a name="116"></a>116. bitset cannot be constructed with a const char*</h3>
1491 <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#NAD%20Future">NAD Future</a>
1492  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-11-06</p>
1493 <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>
1494 <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>
1495 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
1496 <p><b>Discussion:</b></p>
1497 <p>The following code does not compile with the EDG compiler:</p>
1498
1499 <blockquote>
1500   <pre>#include &lt;bitset&gt;
1501 using namespace std;
1502 bitset&lt;32&gt; b("111111111");</pre>
1503 </blockquote>
1504
1505 <p>If you cast the ctor argument to a string, i.e.:</p>
1506
1507 <blockquote>
1508   <pre>bitset&lt;32&gt; b(string("111111111"));</pre>
1509 </blockquote>
1510
1511 <p>then it will compile. The reason is that bitset has the following templatized
1512 constructor:</p>
1513
1514 <blockquote>
1515   <pre>template &lt;class charT, class traits, class Allocator&gt;
1516 explicit bitset (const basic_string&lt;charT, traits, Allocator&gt;&amp; str, ...);</pre>
1517 </blockquote>
1518
1519 <p>According to the compiler vendor, Steve Adamcyk at EDG, the user
1520 cannot pass this template constructor a <tt>const char*</tt> and
1521 expect a conversion to <tt>basic_string</tt>.  The reason is
1522 "When you have a template constructor, it can get used in
1523 contexts where type deduction can be done. Type deduction basically
1524 comes up with exact matches, not ones involving conversions."
1525 </p>
1526
1527 <p>I don't think the intention when this constructor became
1528 templatized was for construction from a <tt>const char*</tt> to no
1529 longer work.</p>
1530
1531
1532 <p><b>Proposed resolution:</b></p>
1533 <p>Add to 23.3.5 [template.bitset] a bitset constructor declaration</p>
1534
1535 <blockquote>
1536   <pre>explicit bitset(const char*);</pre>
1537 </blockquote>
1538
1539 <p>and in Section 23.3.5.1 [bitset.cons] add:</p>
1540
1541 <blockquote>
1542   <pre>explicit bitset(const char* str);</pre>
1543   <p>Effects: <br>
1544   &nbsp;&nbsp;&nbsp; Calls <tt>bitset((string) str, 0, string::npos);</tt></p>
1545 </blockquote>
1546
1547
1548 <p><b>Rationale:</b></p>
1549 <p>Although the problem is real, the standard is designed that way so
1550 it is not a defect.  Education is the immediate workaround. A future
1551 standard may wish to consider the Proposed Resolution as an
1552 extension.</p>
1553
1554
1555
1556
1557
1558 <hr>
1559 <h3><a name="121"></a>121. Detailed definition for ctype&lt;wchar_t&gt; specialization</h3>
1560 <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#NAD">NAD</a>
1561  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
1562 <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>
1563 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1564 <p><b>Discussion:</b></p>
1565 <p>Section 22.1.1.1.1 has the following listed in Table 51: ctype&lt;char&gt; ,
1566 ctype&lt;wchar_t&gt;. </p>
1567
1568 <p>Also Section 22.2.1.1 [locale.ctype] says: </p>
1569
1570 <blockquote>
1571   <p>The instantiations required in Table 51 (22.1.1.1.1) namely ctype&lt;char&gt; and
1572   ctype&lt;wchar_t&gt; , implement character classing appropriate to the implementation's
1573   native character set. </p>
1574 </blockquote>
1575
1576 <p>However, Section 22.2.1.3 [facet.ctype.special]
1577 only has a detailed description of the ctype&lt;char&gt; specialization, not the
1578 ctype&lt;wchar_t&gt; specialization. </p>
1579
1580
1581 <p><b>Proposed resolution:</b></p>
1582 <p>Add the ctype&lt;wchar_t&gt; detailed class description to Section
1583 22.2.1.3 [facet.ctype.special]. </p>
1584
1585
1586 <p><b>Rationale:</b></p>
1587 <p>Specialization for wchar_t is not needed since the default is acceptable.</p>
1588
1589
1590
1591
1592
1593 <hr>
1594 <h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string&nbsp; buffers</h3>
1595 <p><b>Section:</b> 27.7 [string.streams], 27.8 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
1596  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p>
1597 <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>
1598 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
1599 <p><b>Discussion:</b></p>
1600 <p>The following question came from Thorsten Herlemann:</p>
1601
1602 <blockquote>
1603   <p>You can set a mode when constructing or opening a file-stream or
1604   filebuf, e.g.  ios::in, ios::out, ios::binary, ... But how can I get
1605   that mode later on, e.g. in my own operator &lt;&lt; or operator
1606   &gt;&gt; or when I want to check whether a file-stream or
1607   file-buffer object passed as parameter is opened for input or output
1608   or binary? Is there no possibility? Is this a design-error in the
1609   standard C++ library? </p>
1610 </blockquote>
1611
1612 <p>It is indeed impossible to find out what a stream's or stream
1613 buffer's open mode is, and without that knowledge you don't know
1614 how certain operations behave. Just think of the append mode. </p>
1615
1616 <p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the
1617 current open mode setting. </p>
1618
1619
1620 <p><b>Proposed resolution:</b></p>
1621 <p>For stream buffers, add a function to the base class as a non-virtual function
1622 qualified as const to 27.5.2 [streambuf]:</p>
1623
1624 <p>&nbsp;&nbsp;&nbsp;&nbsp;<tt>openmode mode() const</tt>;</p>
1625
1626 <p><b>&nbsp;&nbsp;&nbsp; Returns</b> the current open mode.</p>
1627
1628 <p>With streams, I'm not sure what to suggest. In principle, the mode
1629 could already be returned by <tt>ios_base</tt>, but the mode is only
1630 initialized for file and string stream objects, unless I'm overlooking
1631 anything. For this reason it should be added to the most derived
1632 stream classes. Alternatively, it could be added to <tt>basic_ios</tt>
1633 and would be default initialized in <tt>basic_ios&lt;&gt;::init()</tt>.</p>
1634
1635
1636 <p><b>Rationale:</b></p>
1637 <p>This might be an interesting extension for some future, but it is
1638 not a defect in the current standard. The Proposed Resolution is
1639 retained for future reference.</p>
1640
1641
1642
1643
1644
1645 <hr>
1646 <h3><a name="131"></a>131. list::splice throws nothing</h3>
1647 <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#NAD">NAD</a>
1648  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
1649 <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>
1650 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1651 <p><b>Discussion:</b></p>
1652 <p>What happens if a splice operation causes the size() of a list to grow
1653 beyond max_size()?</p>
1654
1655
1656 <p><b>Rationale:</b></p>
1657 <p>Size() cannot grow beyond max_size().&nbsp; </p>
1658
1659
1660
1661
1662
1663 <hr>
1664 <h3><a name="135"></a>135. basic_iostream doubly initialized</h3>
1665 <p><b>Section:</b> 27.6.1.5.1 [iostream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1666  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
1667 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1668 <p><b>Discussion:</b></p>
1669 <p>-1- Effects Constructs an object of class basic_iostream, assigning
1670 initial values to the base classes by calling
1671 basic_istream&lt;charT,traits&gt;(sb) (lib.istream) and
1672 basic_ostream&lt;charT,traits&gt;(sb) (lib.ostream)</p>
1673
1674 <p>The called for basic_istream and basic_ostream constructors call
1675 init(sb). This means that the basic_iostream's virtual base class is
1676 initialized twice.</p>
1677
1678
1679 <p><b>Proposed resolution:</b></p>
1680 <p>Change 27.6.1.5.1, paragraph 1 to:</p>
1681
1682 <p>-1- Effects Constructs an object of class basic_iostream, assigning
1683 initial values to the base classes by calling
1684 basic_istream&lt;charT,traits&gt;(sb) (lib.istream).</p>
1685
1686
1687 <p><b>Rationale:</b></p>
1688 <p>The LWG agreed that the <tt> init()</tt> function is called
1689 twice, but said that this is harmless and so not a defect in the
1690 standard.</p>
1691
1692
1693
1694
1695 <hr>
1696 <h3><a name="138"></a>138. Class ctype_byname&lt;char&gt; redundant and misleading</h3>
1697 <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#NAD%20Future">NAD Future</a>
1698  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-03-18</p>
1699 <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>
1700 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
1701 <p><b>Discussion:</b></p>
1702 <p>Section 22.2.1.4 [locale.codecvt] specifies that
1703 ctype_byname&lt;char&gt; must be a specialization of the ctype_byname
1704 template.</p>
1705
1706 <p>It is common practice in the standard that specializations of class templates are only
1707 mentioned where the interface of the specialization deviates from the interface of the
1708 template that it is a specialization of. Otherwise, the fact whether or not a required
1709 instantiation is an actual instantiation or a specialization is left open as an
1710 implementation detail. </p>
1711
1712 <p>Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The
1713 fact, that ctype_byname&lt;char&gt; is specified as a specialization suggests that there
1714 must be something "special" about it, but it has the exact same interface as the
1715 ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best
1716 redundant, at worst misleading - unless I am missing anything. </p>
1717
1718 <p>Naturally, an implementation will most likely implement ctype_byname&lt;char&gt; as a
1719 specialization, because the base class ctype&lt;char&gt; is a specialization with an
1720 interface different from the ctype template, but that's an implementation detail and need
1721 not be mentioned in the standard. </p>
1722
1723
1724 <p><b>Rationale:</b></p>
1725 <p> The standard as written is mildly misleading, but the correct fix
1726 is to deal with the underlying problem in the ctype_byname base class,
1727 not in the specialization. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
1728
1729
1730
1731
1732 <hr>
1733 <h3><a name="140"></a>140. map&lt;Key, T&gt;::value_type does not satisfy the assignable requirement</h3>
1734 <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#NAD%20Future">NAD Future</a>
1735  <b>Submitter:</b> Mark Mitchell <b>Date:</b> 1999-04-14</p>
1736 <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>
1737 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
1738 <p><b>Discussion:</b></p>
1739 <blockquote>
1740   <p>23.1 [container.requirements]<br>
1741   <br>
1742   expression&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return type
1743   &nbsp;&nbsp;&nbsp;&nbsp; pre/post-condition<br>
1744   -------------&nbsp;&nbsp;&nbsp;&nbsp; ----------- &nbsp;&nbsp;&nbsp;&nbsp;
1745   -------------------<br>
1746   X::value_type&nbsp;&nbsp;&nbsp; T
1747   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1748   T is assignable<br>
1749   <br>
1750   23.3.1 [map]<br>
1751   <br>
1752   A map satisfies all the requirements of a container.<br>
1753   <br>
1754   For a map&lt;Key, T&gt; ... the value_type is pair&lt;const Key, T&gt;.</p>
1755 </blockquote>
1756
1757 <p>There's a contradiction here. In particular, `pair&lt;const Key,
1758 T&gt;' is not assignable; the `const Key' cannot be assigned
1759 to. So,&nbsp; map&lt;Key, T&gt;::value_type does not satisfy the
1760 assignable requirement imposed by a container.</p>
1761
1762 <p><i>[See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for the slightly related issue of
1763 modification of set keys.]</i></p>
1764
1765
1766
1767 <p><b>Rationale:</b></p>
1768 <p>The LWG believes that the standard is inconsistent, but that this
1769 is a design problem rather than a strict defect. May wish to
1770 reconsider for the next standard.</p>
1771
1772
1773
1774
1775 <hr>
1776 <h3><a name="143"></a>143. C .h header wording unclear</h3>
1777 <p><b>Section:</b> D.5 [depr.c.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1778  <b>Submitter:</b> Christophe de Dinechin <b>Date:</b> 1999-05-04</p>
1779 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1780 <p><b>Discussion:</b></p>
1781 <p>[depr.c.headers] paragraph 2 reads:</p>
1782
1783 <blockquote>
1784
1785 <p>Each C header, whose name has the form name.h, behaves as if each
1786 name placed in the Standard library namespace by the corresponding
1787 cname header is also placed within the namespace scope of the
1788 namespace std and is followed by an explicit using-declaration
1789 (_namespace.udecl_)</p>
1790
1791 </blockquote>
1792
1793 <p>I think it should mention the global name space somewhere...&nbsp;
1794 Currently, it indicates that name placed in std is also placed in
1795 std...</p>
1796
1797 <p>I don't know what is the correct wording. For instance, if struct
1798 tm is defined in time.h, ctime declares std::tm. However, the current
1799 wording seems ambiguous regarding which of the following would occur
1800 for use of both ctime and time.h:</p>
1801
1802 <blockquote>
1803   <pre>// version 1:
1804 namespace std {
1805         struct tm { ... };
1806 }
1807 using std::tm;
1808
1809 // version 2:
1810 struct tm { ... };
1811 namespace std {
1812         using ::tm;
1813 }
1814
1815 // version 3:
1816 struct tm { ... };
1817 namespace std {
1818         struct tm { ... };
1819 }</pre>
1820 </blockquote>
1821
1822 <p>I think version 1 is intended.</p>
1823
1824 <p><i>[Kona: The LWG agreed that the wording is not clear. It also
1825 agreed that version 1 is intended, version 2 is not equivalent to
1826 version 1, and version 3 is clearly not intended. The example below
1827 was constructed by Nathan Myers to illustrate why version 2 is not
1828 equivalent to version 1.</i></p>
1829
1830 <p><i>Although not equivalent, the LWG is unsure if (2) is enough of
1831 a problem to be prohibited. Points discussed in favor of allowing
1832 (2):</i></p>
1833
1834 <blockquote>
1835   <ul>
1836     <li><i>It may be a convenience to implementors.</i></li>
1837     <li><i>The only cases that fail are structs, of which the C library
1838       contains only a few.</i></li>
1839   </ul>
1840 </blockquote>
1841
1842 <p><i>]</i></p>
1843
1844 <p><b>Example:</b></p>
1845
1846 <blockquote>
1847
1848 <pre>#include &lt;time.h&gt;
1849 #include &lt;utility&gt;
1850
1851 int main() {
1852     std::tm * t;
1853     make_pair( t, t ); // okay with version 1 due to Koenig lookup
1854                        // fails with version 2; make_pair not found
1855     return 0;
1856 }</pre>
1857
1858 </blockquote>
1859
1860
1861 <p><b>Proposed resolution:</b></p>
1862
1863 <p>Replace D.5 [depr.c.headers] paragraph 2 with:</p>
1864
1865 <blockquote>
1866
1867 <p> Each C header, whose name has the form name.h, behaves as if each
1868 name placed in the Standard library namespace by the corresponding
1869 cname header is also placed within the namespace scope of the
1870 namespace std by name.h and is followed by an explicit
1871 using-declaration (_namespace.udecl_) in global scope.</p>
1872
1873 </blockquote>
1874
1875
1876
1877 <p><b>Rationale:</b></p>
1878 <p> The current wording in the standard is the result of a difficult
1879 compromise that averted delay of the standard. Based on discussions
1880 in Tokyo it is clear that there is no still no consensus on stricter
1881 wording, so the issue has been closed. It is suggested that users not
1882 write code that depends on Koenig lookup of C library functions.</p>
1883
1884
1885
1886
1887 <hr>
1888 <h3><a name="145"></a>145. adjustfield lacks default value</h3>
1889 <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#NAD">NAD</a>
1890  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-05-12</p>
1891 <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>
1892 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1893 <p><b>Discussion:</b></p>
1894 <p>There is no initial value for the adjustfield defined, although
1895 many people believe that the default adjustment were right. This is a
1896 common misunderstanding. The standard only defines that, if no
1897 adjustment is specified, all the predefined inserters must add fill
1898 characters before the actual value, which is "as if" the
1899 right flag were set. The flag itself need not be set.</p>
1900
1901 <p>When you implement a user-defined inserter you cannot rely on right
1902 being the default setting for the adjustfield. Instead, you must be
1903 prepared to find none of the flags set and must keep in mind that in
1904 this case you should make your inserter behave "as if" the
1905 right flag were set. This is surprising to many people and complicates
1906 matters more than necessary.</p>
1907
1908 <p>Unless there is a good reason why the adjustfield should not be
1909 initialized I would suggest to give it the default value that
1910 everybody expects anyway.</p>
1911
1912
1913
1914 <p><b>Rationale:</b></p>
1915 <p>This is not a defect. It is deliberate that the default is no bits
1916 set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.</p>
1917
1918
1919
1920
1921 <hr>
1922 <h3><a name="149"></a>149. Insert should return iterator to first element inserted</h3>
1923 <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#NAD%20Future">NAD Future</a>
1924  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-06-28</p>
1925 <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>
1926 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
1927 <p><b>Discussion:</b></p>
1928 <p>Suppose that c and c1 are sequential containers and i is an
1929 iterator that refers to an element of c.  Then I can insert a copy of
1930 c1's elements into c ahead of element i by executing </p>
1931
1932 <blockquote>
1933
1934 <pre>c.insert(i, c1.begin(), c1.end());</pre>
1935
1936 </blockquote>
1937
1938 <p>If c is a vector, it is fairly easy for me to find out where the
1939 newly inserted elements are, even though i is now invalid: </p>
1940
1941 <blockquote>
1942
1943 <pre>size_t i_loc = i - c.begin();
1944 c.insert(i, c1.begin(), c1.end());</pre>
1945
1946 </blockquote>
1947
1948 <p>and now the first inserted element is at c.begin()+i_loc and one
1949 past the last is at c.begin()+i_loc+c1.size().<br>
1950 <br>
1951 But what if c is a list? I can still find the location of one past the
1952 last inserted element, because i is still valid. To find the location
1953 of the first inserted element, though, I must execute something like </p>
1954
1955 <blockquote>
1956
1957 <pre>for (size_t n = c1.size(); n; --n)
1958    --i;</pre>
1959
1960 </blockquote>
1961
1962 <p>because i is now no longer a random-access iterator.<br>
1963 <br>
1964 Alternatively, I might write something like </p>
1965
1966 <blockquote>
1967
1968 <pre>bool first = i == c.begin();
1969 list&lt;T&gt;::iterator j = i;
1970 if (!first) --j;
1971 c.insert(i, c1.begin(), c1.end());
1972 if (first)
1973    j = c.begin();
1974 else
1975    ++j;</pre>
1976
1977 </blockquote>
1978
1979 <p>which, although wretched, requires less overhead.<br>
1980 <br>
1981 But I think the right solution is to change the definition of insert
1982 so that instead of returning void, it returns an iterator that refers
1983 to the first element inserted, if any, and otherwise is a copy of its
1984 first argument.&nbsp; </p>
1985
1986
1987 <p><b>Rationale:</b></p>
1988 <p>The LWG believes this was an intentional design decision and so is
1989 not a defect. It may be worth revisiting for the next standard.</p>
1990
1991
1992
1993
1994 <hr>
1995 <h3><a name="157"></a>157. Meaningless error handling for <tt>pword()</tt> and <tt>iword()</tt></h3>
1996 <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#Dup">Dup</a>
1997  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
1998 <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>
1999 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2000 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a></p>
2001 <p><b>Discussion:</b></p>
2002 <p>According to paragraphs 2 and 4 of 27.4.2.5 [ios.base.storage], the
2003 functions <tt>iword()</tt> and <tt>pword()</tt> "set the
2004 <tt>badbit</tt> (which might throw an exception)" on
2005 failure. ... but what does it mean for <tt>ios_base</tt> to set the
2006 <tt>badbit</tt>? The state facilities of the IOStream library are
2007 defined in <tt>basic_ios</tt>, a derived class! It would be possible
2008 to attempt a down cast but then it would be necessary to know the
2009 character type used...</p>
2010
2011
2012 <p><b>Rationale:</b></p>
2013
2014
2015
2016
2017
2018 <hr>
2019 <h3><a name="162"></a>162. Really "formatted input functions"?</h3>
2020 <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#Dup">Dup</a>
2021  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
2022 <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>
2023 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2024 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
2025 <p><b>Discussion:</b></p>
2026 <p>It appears to be somewhat nonsensical to consider the functions
2027 defined in the paragraphs 1 to 5 to be "Formatted input
2028 function" but since these functions are defined in a section
2029 labeled "Formatted input functions" it is unclear to me
2030 whether these operators are considered formatted input functions which
2031 have to conform to the "common requirements" from 27.6.1.2.1
2032 [istream.formatted.reqmts]: If this is the case, all manipulators, not
2033 just
2034 <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is set
2035 (... but setting <tt>noskipws</tt> using the manipulator syntax would
2036 also skip whitespace :-)</p>
2037
2038 <p>See also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#166">166</a> for the same problem in formatted
2039 output</p>
2040
2041
2042 <p><b>Rationale:</b></p>
2043
2044
2045
2046
2047
2048 <hr>
2049 <h3><a name="163"></a>163. Return of <tt>gcount()</tt> after a call to <tt>gcount</tt></h3>
2050 <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#Dup">Dup</a>
2051  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
2052 <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>
2053 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2054 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
2055 <p><b>Discussion:</b></p>
2056 <p>It is not clear which functions are to be considered unformatted
2057 input functions. As written, it seems that all functions in 27.6.1.3
2058 [istream.unformatted] are unformatted input functions. However, it does
2059 not
2060 really make much sense to construct a sentry object for
2061 <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is unclear what
2062 happens to the <tt>gcount()</tt> if eg. <tt>gcount()</tt>,
2063 <tt>putback()</tt>, <tt>unget()</tt>, or <tt>sync()</tt> is called:
2064 These functions don't extract characters, some of them even
2065 "unextract" a character. Should this still be reflected in
2066 <tt>gcount()</tt>? Of course, it could be read as if after a call to
2067 <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt> (the last
2068 unformatted input function, <tt>gcount()</tt>, didn't extract any
2069 character) and after a call to <tt>putback()</tt> <tt>gcount()</tt>
2070 returns <tt>-1</tt> (the last unformatted input function
2071 <tt>putback()</tt> did "extract" back into the
2072 stream). Correspondingly for <tt>unget()</tt>. Is this what is
2073 intended?  If so, this should be clarified. Otherwise, a corresponding
2074 clarification should be used.</p>
2075
2076
2077 <p><b>Rationale:</b></p>
2078
2079
2080
2081
2082
2083 <hr>
2084 <h3><a name="166"></a>166. Really "formatted output functions"?</h3>
2085 <p><b>Section:</b> 27.6.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2086  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
2087 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2088 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
2089 <p><b>Discussion:</b></p>
2090 <p>From 27.6.2.6.1 [ostream.formatted.reqmts] it appears that all the functions
2091 defined in 27.6.2.6.3 [ostream.inserters] have to construct a
2092 <tt>sentry</tt> object. Is this really intended?</p>
2093
2094 <p>This is basically the same problem as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a> but
2095 for output instead of input.</p>
2096
2097
2098 <p><b>Rationale:</b></p>
2099
2100
2101
2102
2103
2104 <hr>
2105 <h3><a name="177"></a>177. Complex operators cannot be explicitly instantiated</h3>
2106 <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#NAD">NAD</a>
2107  <b>Submitter:</b> Judy Ward <b>Date:</b> 1999-07-02</p>
2108 <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>
2109 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2110 <p><b>Discussion:</b></p>
2111 <p>A user who tries to explicitly instantiate a complex non-member operator will
2112 get compilation errors. Below is a simplified example of the reason why. The
2113 problem is that iterator_traits cannot be instantiated on a non-pointer type
2114 like float, yet when the compiler is trying to decide which operator+ needs to
2115 be instantiated it must instantiate the declaration to figure out the first
2116 argument type of a reverse_iterator operator.</p>
2117 <pre>namespace std {
2118 template &lt;class Iterator&gt;
2119 struct iterator_traits
2120 {
2121     typedef typename Iterator::value_type value_type;
2122 };
2123
2124 template &lt;class T&gt; class reverse_iterator;
2125
2126 // reverse_iterator operator+
2127 template &lt;class T&gt;
2128 reverse_iterator&lt;T&gt; operator+
2129 (typename iterator_traits&lt;T&gt;::difference_type, const reverse_iterator&lt;T&gt;&amp;);
2130
2131 template &lt;class T&gt; struct complex {};
2132
2133 // complex operator +
2134 template &lt;class T&gt;
2135 complex&lt;T&gt; operator+ (const T&amp; lhs, const complex&lt;T&gt;&amp; rhs)
2136 { return complex&lt;T&gt;();}
2137 }
2138
2139 // request for explicit instantiation
2140 template std::complex&lt;float&gt; std::operator+&lt;float&gt;(const float&amp;,
2141      const std::complex&lt;float&gt;&amp;);</pre>
2142 <p>See also c++-stdlib reflector messages: lib-6814, 6815, 6816.</p>
2143
2144
2145 <p><b>Rationale:</b></p>
2146 <p>Implementors can make minor changes and the example will
2147 work. Users are not affected in any case.</p> <p>According to John
2148 Spicer, It is possible to explicitly instantiate these operators using
2149 different syntax: change "std::operator+&lt;float&gt;" to
2150 "std::operator+".</p>
2151
2152 <p>The proposed resolution of issue 120 is that users will not be able
2153 to explicitly instantiate standard library templates. If that
2154 resolution is accepted then library implementors will be the only ones
2155 that will be affected by this problem, and they must use the indicated
2156 syntax.</p>
2157
2158
2159
2160
2161 <hr>
2162 <h3><a name="178"></a>178. Should clog and cerr initially be tied to cout?</h3>
2163 <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#NAD">NAD</a>
2164  <b>Submitter:</b> Judy Ward <b>Date:</b> 1999-07-02</p>
2165 <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>
2166 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2167 <p><b>Discussion:</b></p>
2168 <p>
2169 Section 27.3.1 says "After the object cerr is initialized,
2170 cerr.flags() &amp; unitbuf is nonzero. Its state is otherwise the same as
2171 required for ios_base::init (lib.basic.ios.cons).  It doesn't say
2172 anything about the the state of clog.  So this means that calling
2173 cerr.tie() and clog.tie() should return 0 (see Table 89 for
2174 ios_base::init effects).
2175 </p>
2176 <p>
2177 Neither of the popular standard library implementations
2178 that I tried does this, they both tie cerr and clog
2179 to &amp;cout. I would think that would be what users expect.
2180 </p>
2181
2182
2183 <p><b>Rationale:</b></p>
2184 <p>The standard is clear as written.</p>
2185 <p>27.3.1/5 says that "After the object cerr is initialized, cerr.flags()
2186 &amp; unitbuf is nonzero. Its state is otherwise the same as required for
2187 ios_base::init (27.4.4.1)." Table 89 in 27.4.4.1, which gives the
2188 postconditions of basic_ios::init(), says that tie() is 0. (Other issues correct
2189 ios_base::init to basic_ios::init().)</p>
2190
2191
2192
2193
2194 <hr>
2195 <h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</h3>
2196 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
2197  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 1999-07-01</p>
2198 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
2199 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
2200 <p><b>Discussion:</b></p>
2201 <p>It is the constness of the container which should control whether
2202 it can be modified through a member function such as erase(), not the
2203 constness of the iterators. The iterators only serve to give
2204 positioning information.</p>
2205
2206 <p>Here's a simple and typical example problem which is currently very
2207 difficult or impossible to solve without the change proposed
2208 below.</p>
2209
2210 <p>Wrap a standard container C in a class W which allows clients to
2211 find and read (but not modify) a subrange of (C.begin(), C.end()]. The
2212 only modification clients are allowed to make to elements in this
2213 subrange is to erase them from C through the use of a member function
2214 of W.</p>
2215
2216
2217 <p><b>Proposed resolution:</b></p>
2218 <p>Change all non-const iterator parameters of standard library
2219 container member functions to accept const_iterator parameters.
2220 Note that this change applies to all library clauses, including
2221 strings.</p>
2222
2223 <p>For example, in   21.3.5.5  change:<br>
2224 <br>
2225 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>iterator erase(iterator p);</tt><br>
2226 <br>
2227 to:<br>
2228 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>iterator erase(const_iterator p);</tt>
2229 </p>
2230
2231
2232 <p><b>Rationale:</b></p>
2233 <p>The issue was discussed at length. It was generally agreed that 1)
2234 There is no major technical argument against the change (although
2235 there is a minor argument that some obscure programs may break), and
2236 2) Such a change would not break const correctness. The concerns about
2237 making the change were 1) it is user detectable (although only in
2238 boundary cases), 2) it changes a large number of signatures, and 3) it
2239 seems more of a design issue that an out-and-out defect.</p>
2240
2241 <p>The LWG believes that this issue should be considered as part of a
2242 general review of const issues for the next revision of the
2243 standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p>
2244
2245
2246
2247
2248 <hr>
2249 <h3><a name="188"></a>188. valarray helpers missing augmented assignment operators</h3>
2250 <p><b>Section:</b> 26.5.2.6 [valarray.cassign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
2251  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 1999-08-15</p>
2252 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
2253 <p><b>Discussion:</b></p>
2254 <p>26.5.2.6 defines augmented assignment operators
2255 valarray&lt;T&gt;::op=(const T&amp;), but fails to provide
2256 corresponding versions for the helper classes. Thus making the
2257 following illegal:</p>
2258 <blockquote>
2259 <pre>#include &lt;valarray&gt;
2260
2261 int main()
2262 {
2263 std::valarray&lt;double&gt; v(3.14, 1999);
2264
2265 v[99] *= 2.0; // Ok
2266
2267 std::slice s(0, 50, 2);
2268
2269 v[s] *= 2.0; // ERROR
2270 }</pre>
2271 </blockquote>
2272 <p>I can't understand the intent of that omission.  It makes the
2273 valarray library less intuitive and less useful.</p>
2274
2275
2276 <p><b>Rationale:</b></p>
2277 <p>Although perhaps an unfortunate
2278 design decision, the omission is not a defect in the current
2279 standard.&nbsp; A future standard may wish to add the missing
2280 operators.</p>
2281
2282
2283
2284
2285 <hr>
2286 <h3><a name="190"></a>190. min() and max() functions should be std::binary_functions</h3>
2287 <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#NAD%20Future">NAD Future</a>
2288  <b>Submitter:</b> Mark Rintoul <b>Date:</b> 1999-08-26</p>
2289 <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>
2290 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
2291 <p><b>Discussion:</b></p>
2292 <p>Both std::min and std::max are defined as template functions.  This
2293 is very different than the definition of std::plus (and similar
2294 structs) which are defined as function objects which inherit
2295 std::binary_function.<br>
2296 <br>
2297         This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
2298 a function object that inherits std::binary_function.</p>
2299
2300
2301 <p><b>Rationale:</b></p>
2302 <p>Although perhaps an unfortunate design decision, the omission is not a defect
2303 in the current standard.&nbsp; A future standard may wish to consider additional
2304 function objects.</p>
2305
2306
2307
2308
2309 <hr>
2310 <h3><a name="191"></a>191. Unclear complexity for algorithms such as binary search</h3>
2311 <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#NAD">NAD</a>
2312  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1999-10-10</p>
2313 <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>
2314 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2315 <p><b>Discussion:</b></p>
2316 <p>The complexity of binary_search() is stated as "At most
2317 log(last-first) + 2 comparisons", which seems to say that the
2318 algorithm has logarithmic complexity. However, this algorithms is
2319 defined for forward iterators. And for forward iterators, the need to
2320 step element-by-element results into linear complexity. But such a
2321 statement is missing in the standard. The same applies to
2322 lower_bound(), upper_bound(), and equal_range().&nbsp;<br>
2323 <br>
2324 However, strictly speaking the standard contains no bug here. So this
2325 might considered to be a clarification or improvement.
2326 </p>
2327
2328
2329 <p><b>Rationale:</b></p>
2330 <p>The complexity is expressed in terms of comparisons, and that
2331 complexity can be met even if the number of iterators accessed is
2332 linear. Paragraph 1 already says exactly what happens to
2333 iterators.</p>
2334
2335
2336
2337
2338 <hr>
2339 <h3><a name="192"></a>192. a.insert(p,t) is inefficient and overconstrained</h3>
2340 <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#NAD">NAD</a>
2341  <b>Submitter:</b> Ed Brey <b>Date:</b> 1999-06-06</p>
2342 <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>
2343 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2344 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p>
2345 <p><b>Discussion:</b></p>
2346 <p>As defined in 23.1.2, paragraph 7 (table 69), a.insert(p,t) suffers from
2347 several problems:</p>
2348 <table border="1" cellpadding="5">
2349   <tbody><tr>
2350     <td><b>expression</b></td>
2351     <td><b>return type</b></td>
2352     <td><b>pre/post-condition</b></td>
2353     <td><b>complexity</b></td>
2354   </tr>
2355   <tr>
2356     <td><tt>a.insert(p,t)</tt></td>
2357     <td><tt>iterator</tt></td>
2358     <td>inserts t if and only if there is no element with key equivalent to the key of
2359        t in containers with unique keys; always inserts t in containers with equivalent
2360        keys. always returns the iterator pointing to the element with key equivalent to
2361        the key of t . iterator p is a hint pointing to where the insert should start to search.</td>
2362     <td>logarithmic in general, but amortized constant if t is inserted right after p .</td>
2363   </tr>
2364 </tbody></table>
2365 <p>1. For a container with unique keys, only logarithmic complexity is
2366 guaranteed if no element is inserted, even though constant complexity is always
2367 possible if p points to an element equivalent to t.</p>
2368 <p>2. For a container with equivalent keys, the amortized constant complexity
2369 guarantee is only useful if no key equivalent to t exists in the container.
2370 Otherwise, the insertion could occur in one of multiple locations, at least one
2371 of which would not be right after p.</p>
2372 <p>3. By guaranteeing amortized constant complexity only when t is inserted
2373 after p, it is impossible to guarantee constant complexity if t is inserted at
2374 the beginning of the container. Such a problem would not exist if amortized
2375 constant complexity was guaranteed if t is inserted before p, since there is
2376 always some p immediately before which an insert can take place.</p>
2377 <p>4. For a container with equivalent keys, p does not allow specification of
2378 where to insert the element, but rather only acts as a hint for improving
2379 performance. This negates the added functionality that p would provide if it
2380 specified where within a sequence of equivalent keys the insertion should occur.
2381 Specifying the insert location provides more control to the user, while
2382 providing no disadvantage to the container implementation.</p>
2383
2384
2385 <p><b>Proposed resolution:</b></p>
2386 <p>In 23.1.2 [associative.reqmts] paragraph 7, replace the row in table 69
2387 for a.insert(p,t) with the following two rows:</p>
2388 <table border="1" cellpadding="5">
2389   <tbody><tr>
2390     <td><b>expression</b></td>
2391     <td><b>return type</b></td>
2392     <td><b>pre/post-condition</b></td>
2393     <td><b>complexity</b></td>
2394   </tr>
2395   <tr>
2396     <td><tt>a_uniq.insert(p,t)</tt></td>
2397     <td><tt>iterator</tt></td>
2398     <td>inserts t if and only if there is no element with key equivalent to the
2399       key of t. returns the iterator pointing to the element with key equivalent
2400       to the key of t.</td>
2401     <td>logarithmic in general, but amortized constant if t is inserted right
2402       before p or p points to an element with key equivalent to t.</td>
2403   </tr>
2404   <tr>
2405     <td><tt>a_eq.insert(p,t)</tt></td>
2406     <td><tt>iterator</tt></td>
2407     <td>inserts t and returns the iterator pointing to the newly inserted
2408       element. t is inserted right before p if doing so preserves the container
2409       ordering.</td>
2410     <td>logarithmic in general, but amortized constant if t is inserted right
2411       before p.</td>
2412   </tr>
2413 </tbody></table>
2414
2415
2416
2417 <p><b>Rationale:</b></p>
2418 <p>Too big a change.&nbsp; Furthermore, implementors report checking
2419 both before p and after p, and don't want to change this behavior.</p>
2420
2421
2422
2423
2424
2425 <hr>
2426 <h3><a name="194"></a>194. rdbuf() functions poorly specified</h3>
2427 <p><b>Section:</b> 27.4.4 [ios] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2428  <b>Submitter:</b> Steve Clamage <b>Date:</b> 1999-09-07</p>
2429 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2430 <p><b>Discussion:</b></p>
2431 <p>In classic iostreams, base class ios had an rdbuf function that returned a
2432 pointer to the associated streambuf. Each derived class had its own rdbuf
2433 function that returned a pointer of a type reflecting the actual type derived
2434 from streambuf. Because in ARM C++, virtual function overrides had to have the
2435 same return type, rdbuf could not be virtual.</p>
2436 <p>In standard iostreams, we retain the non-virtual rdbuf function design, and
2437 in addition have an overloaded rdbuf function that sets the buffer pointer.
2438 There is no need for the second function to be virtual nor to be implemented in
2439 derived classes.</p>
2440 <p>Minor question: Was there a specific reason not to make the original rdbuf
2441 function virtual?</p>
2442 <p>Major problem: Friendly compilers warn about functions in derived classes
2443 that hide base-class overloads. Any standard implementation of iostreams will
2444 result in such a warning on each of the iostream classes, because of the
2445 ill-considered decision to overload rdbuf only in a base class.</p>
2446 <p>In addition, users of the second rdbuf function must use explicit
2447 qualification or a cast to call it from derived classes. An explicit
2448 qualification or cast to basic_ios would prevent access to any later overriding
2449 version if there was one.</p>
2450 <p>What I'd like to do in an implementation is add a using- declaration for the
2451 second rdbuf function in each derived class. It would eliminate warnings about
2452 hiding functions, and would enable access without using explicit qualification.
2453 Such a change I don't think would change the behavior of any valid program, but
2454 would allow invalid programs to compile:</p>
2455 <blockquote>
2456   <pre> filebuf mybuf;
2457  fstream f;
2458  f.rdbuf(mybuf); // should be an error, no visible rdbuf</pre>
2459 </blockquote>
2460 <p>I'd like to suggest this problem as a defect, with the proposed resolution to
2461 require the equivalent of a using-declaration for the rdbuf function that is not
2462 replaced in a later derived class. We could discuss whether replacing the
2463 function should be allowed.</p>
2464
2465
2466 <p><b>Rationale:</b></p>
2467 <p>For historical reasons, the standard is correct as written. There is a subtle difference between the base
2468 class <tt> rdbuf()</tt> and derived class <tt>rdbuf()</tt>. The derived
2469 class <tt> rdbuf()</tt> always returns the original streambuf, whereas the base class
2470 <tt> rdbuf()</tt> will return the "current streambuf" if that has been changed by the variant you mention.</p>
2471
2472 <p>Permission is not required to add such an extension.  See
2473 17.4.4.4 [member.functions].</p>
2474
2475
2476
2477
2478 <hr>
2479 <h3><a name="196"></a>196. Placement new example has alignment problems</h3>
2480 <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#Dup">Dup</a>
2481  <b>Submitter:</b> Herb Sutter <b>Date:</b> 1998-12-15</p>
2482 <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>
2483 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2484 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a></p>
2485 <p><b>Discussion:</b></p>
2486 <p>The example in 18.5.1.3 [new.delete.placement] paragraph 4 reads: </p>
2487
2488 <blockquote>
2489
2490 <p>[Example: This can be useful for constructing an object at a known address:<br>
2491 <br>
2492 <tt>&nbsp;&nbsp; char place[sizeof(Something)];<br>
2493 &nbsp;&nbsp; Something* p = new (place) Something();<br>
2494 <br>
2495 </tt>end example] </p>
2496
2497 </blockquote>
2498
2499 <p>This example has potential alignment problems. </p>
2500
2501
2502 <p><b>Rationale:</b></p>
2503
2504
2505
2506
2507
2508 <hr>
2509 <h3><a name="197"></a>197. max_size() underspecified</h3>
2510 <p><b>Section:</b> 20.1.2 [allocator.requirements], 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2511  <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1999-10-21</p>
2512 <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>
2513 <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>
2514 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2515 <p><b>Discussion:</b></p>
2516 <p>Must the value returned by max_size() be unchanged from call to call? </p>
2517
2518 <p>Must the value returned from max_size() be meaningful? </p>
2519
2520 <p>Possible meanings identified in lib-6827: </p>
2521
2522 <p>1) The largest container the implementation can support given "best
2523 case" conditions - i.e. assume the run-time platform is "configured to
2524 the max", and no overhead from the program itself. This may possibly
2525 be determined at the point the library is written, but certainly no
2526 later than compile time.<br>
2527 <br>
2528 2) The largest container the program could create, given "best case"
2529 conditions - i.e. same platform assumptions as (1), but take into
2530 account any overhead for executing the program itself. (or, roughly
2531 "storage=storage-sizeof(program)"). This does NOT include any resource
2532 allocated by the program. This may (or may not) be determinable at
2533 compile time.<br>
2534 <br>
2535 3) The largest container the current execution of the program could
2536 create, given knowledge of the actual run-time platform, but again,
2537 not taking into account any currently allocated resource. This is
2538 probably best determined at program start-up.<br>
2539 <br>
2540 4) The largest container the current execution program could create at
2541 the point max_size() is called (or more correctly at the point
2542 max_size() returns :-), given it's current environment (i.e. taking
2543 into account the actual currently available resources). This,
2544 obviously, has to be determined dynamically each time max_size() is
2545 called. </p>
2546
2547
2548 <p><b>Proposed resolution:</b></p>
2549
2550
2551 <p><b>Rationale:</b></p>
2552 <p>max_size() isn't useful for very many things, and the existing
2553   wording is sufficiently clear for the few cases that max_size() can
2554   be used for.  None of the attempts to change the existing wording
2555   were an improvement.</p>
2556
2557 <p>It is clear to the LWG that the value returned by max_size() can't
2558   change from call to call.</p>
2559
2560
2561
2562
2563
2564
2565 <hr>
2566 <h3><a name="203"></a>203. basic_istream::sentry::sentry() is uninstantiable with ctype&lt;user-defined type&gt;</h3>
2567 <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#NAD">NAD</a>
2568  <b>Submitter:</b> Matt McClure and Dietmar Kühl <b>Date:</b> 2000-01-01</p>
2569 <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>
2570 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2571 <p><b>Discussion:</b></p>
2572 <p>27.6.1.1.2 Paragraph 4 states:</p>
2573 <blockquote>
2574   <p>To decide if the character c is a whitespace character, the constructor
2575      performs ''as if'' it executes the following code fragment:&nbsp;</p>
2576   <pre>const ctype&lt;charT&gt;&amp; ctype = use_facet&lt;ctype&lt;charT&gt; &gt;(is.getloc());
2577 if (ctype.is(ctype.space,c)!=0)
2578 // c is a whitespace character.</pre>
2579 </blockquote>
2580
2581 <p> But Table 51 in 22.1.1.1.1 only requires an implementation to
2582 provide specializations for ctype&lt;char&gt; and
2583 ctype&lt;wchar_t&gt;.  If sentry's constructor is implemented using
2584 ctype, it will be uninstantiable for a user-defined character type
2585 charT, unless the implementation has provided non-working (since it
2586 would be impossible to define a correct ctype&lt;charT&gt; specialization
2587 for an arbitrary charT) definitions of ctype's virtual member
2588 functions.</p>
2589
2590 <p>
2591 It seems the intent the standard is that sentry should behave, in
2592 every respect, not just during execution, as if it were implemented
2593 using ctype, with the burden of providing a ctype specialization
2594 falling on the user.  But as it is written, nothing requires the
2595 translation of sentry's constructor to behave as if it used the above
2596 code, and it would seem therefore, that sentry's constructor should be
2597 instantiable for all character types.
2598 </p>
2599
2600 <p>
2601 Note: If I have misinterpreted the intent of the standard with
2602 respect to sentry's constructor's instantiability, then a note should
2603 be added to the following effect:
2604 </p>
2605
2606 <blockquote><p>
2607 An implementation is forbidden from using the above code if it renders
2608 the constructor uninstantiable for an otherwise valid character
2609 type.
2610 </p></blockquote>
2611
2612 <p>In any event, some clarification is needed.</p>
2613
2614
2615
2616 <p><b>Rationale:</b></p>
2617 <p>It is possible but not easy to instantiate on types other than char
2618 or wchar_t; many things have to be done first. That is by intention
2619 and is not a defect.</p>
2620
2621
2622
2623
2624 <hr>
2625 <h3><a name="204"></a>204. distance(first, last) when "last" is before "first"</h3>
2626 <p><b>Section:</b> 24.3.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2627  <b>Submitter:</b> Rintala Matti <b>Date:</b> 2000-01-28</p>
2628 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2629 <p><b>Discussion:</b></p>
2630 <p>Section 24.3.4 describes the function distance(first, last) (where first and
2631 last are iterators) which calculates "the number of increments or
2632 decrements needed to get from 'first' to 'last'".</p>
2633 <p>The function should work for forward, bidirectional and random access
2634 iterators, and there is a requirement 24.3.4.5 which states that "'last'
2635 must be reachable from 'first'".</p>
2636 <p>With random access iterators the function is easy to implement as "last
2637 - first".</p>
2638 <p>With forward iterators it's clear that 'first' must point to a place before
2639 'last', because otherwise 'last' would not be reachable from 'first'.</p>
2640 <p>But what about bidirectional iterators? There 'last' is reachable from
2641 'first' with the -- operator even if 'last' points to an earlier position than
2642 'first'. However, I cannot see how the distance() function could be implemented
2643 if the implementation does not know which of the iterators points to an earlier
2644 position (you cannot use ++ or -- on either iterator if you don't know which
2645 direction is the "safe way to travel").</p>
2646 <p>The paragraph 24.3.4.1 states that "for ... bidirectional iterators they
2647 use ++ to provide linear time implementations". However, the ++ operator is
2648 not mentioned in the reachability requirement. Furthermore 24.3.4.4 explicitly
2649 mentions that distance() returns the number of increments _or decrements_,
2650 suggesting that it could return a negative number also for bidirectional
2651 iterators when 'last' points to a position before 'first'.</p>
2652 <p>Is a further requirement is needed to state that for forward and
2653 bidirectional iterators "'last' must be reachable from 'first' using the ++
2654 operator". Maybe this requirement might also apply to random access
2655 iterators so that distance() would work the same way for every iterator
2656 category?</p>
2657
2658
2659 <p><b>Rationale:</b></p>
2660 <p>"Reachable" is defined in the standard in 24.1 [iterator.requirements] paragraph 6.
2661 The definition is only in terms of operator++(). The LWG sees no defect in
2662 the standard.</p>
2663
2664
2665
2666
2667 <hr>
2668 <h3><a name="205"></a>205.  numeric_limits unclear on how to determine floating point types</h3>
2669 <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#NAD">NAD</a>
2670  <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-01-28</p>
2671 <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>
2672 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2673 <p><b>Discussion:</b></p>
2674 <p>In several places in 18.2.1.2 [numeric.limits.members], a member is
2675 described as "Meaningful for all floating point types."
2676 However, no clear method of determining a floating point type is
2677 provided.</p>
2678
2679 <p>In 18.2.1.5 [numeric.special], paragraph 1 states ". . . (for
2680 example, epsilon() is only meaningful if is_integer is
2681 false). . ." which suggests that a type is a floating point type
2682 if is_specialized is true and is_integer is false; however, this is
2683 unclear.</p>
2684
2685 <p>When clarifying this, please keep in mind this need of users: what
2686 exactly is the definition of floating point? Would a fixed point or
2687 rational representation be considered one? I guess my statement here
2688 is that there could also be types that are neither integer or
2689 (strictly) floating point.</p>
2690
2691
2692 <p><b>Rationale:</b></p>
2693 <p>It is up to the implementor of a user define type to decide if it is a
2694 floating point type.</p>
2695
2696
2697
2698
2699 <hr>
2700 <h3><a name="207"></a>207. ctype&lt;char&gt; members return clause incomplete</h3>
2701 <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#Dup">Dup</a>
2702  <b>Submitter:</b> Robert Klarer <b>Date:</b> 1999-11-02</p>
2703 <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>
2704 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2705 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a></p>
2706 <p><b>Discussion:</b></p>
2707 <p>
2708 The <tt>widen</tt> and <tt>narrow</tt> member functions are described
2709 in 22.2.1.3.2, paragraphs 9-11.  In each case we have two overloaded
2710 signatures followed by a <b>Returns</b> clause.  The <b>Returns</b>
2711 clause only describes one of the overloads.
2712 </p>
2713
2714
2715 <p><b>Proposed resolution:</b></p>
2716 <p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members]
2717 paragraph 10 from:</p>
2718 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
2719
2720 <p>to:</p>
2721 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to),
2722 respectively.</p>
2723
2724 <p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members] paragraph 11
2725 from:</p>
2726 <p>&nbsp;&nbsp;&nbsp; Returns: do_narrow(low, high, to).</p>
2727
2728 <p>to:</p>
2729 <p>&nbsp;&nbsp;&nbsp; Returns: do_narrow(c) or do_narrow(low, high, to),
2730 respectively.</p>
2731
2732
2733 <p><b>Rationale:</b></p>
2734 <p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>, which addresses the same
2735 paragraphs.</p>
2736
2737
2738
2739
2740
2741
2742 <hr>
2743 <h3><a name="213"></a>213. Math function overloads ambiguous</h3>
2744 <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#NAD">NAD</a>
2745  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 2000-02-26</p>
2746 <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>
2747 <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>
2748 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2749 <p><b>Discussion:</b></p>
2750 <p>Due to the additional overloaded versions of numeric functions for
2751 float and long double according to Section 26.5, calls such as int x;
2752 std::pow (x, 4) are ambiguous now in a standard conforming
2753 implementation. Current implementations solve this problem very
2754 different (overload for all types, don't overload for float and long
2755 double, use preprocessor, follow the standard and get
2756 ambiguities).</p> <p>This behavior should be standardized or at least
2757 identified as implementation defined.</p>
2758
2759
2760 <p><b>Rationale:</b></p>
2761 <p>These math issues are an
2762 understood and accepted consequence of the design. They have
2763 been discussed several times in the past. Users must write casts
2764 or write floating point expressions as arguments.</p>
2765
2766
2767
2768
2769 <hr>
2770 <h3><a name="215"></a>215. Can a map's key_type be const?</h3>
2771 <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#NAD">NAD</a>
2772  <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-02-29</p>
2773 <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>
2774 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2775 <p><b>Discussion:</b></p>
2776 <p>A user noticed that this doesn't compile with the Rogue Wave library because
2777 the rb_tree class declares a key_allocator, and allocator&lt;const int&gt; is
2778 not legal, I think:</p>
2779 <blockquote>
2780   <pre>map &lt; const int, ... &gt; // legal?</pre>
2781 </blockquote>
2782 <p>which made me wonder whether it is legal for a map's key_type to be const. In
2783 email from Matt Austern he said:</p>
2784 <blockquote>
2785 <p>I'm not sure whether it's legal to declare a map with a const key type. I
2786 hadn't thought about that question until a couple weeks ago. My intuitive
2787 feeling is that it ought not to be allowed, and that the standard ought to say
2788 so. It does turn out to work in SGI's library, though, and someone in the
2789 compiler group even used it. Perhaps this deserves to be written up as an issue
2790 too.</p>
2791 </blockquote>
2792
2793
2794 <p><b>Rationale:</b></p>
2795 <p>The "key is assignable" requirement from table 69 in
2796 23.1.2 [associative.reqmts] already implies the key cannot be const.</p>
2797
2798
2799
2800
2801 <hr>
2802 <h3><a name="216"></a>216. setbase manipulator description flawed</h3>
2803 <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#Dup">Dup</a>
2804  <b>Submitter:</b> Hyman Rosen <b>Date:</b> 2000-02-29</p>
2805 <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>
2806 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2807 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a></p>
2808 <p><b>Discussion:</b></p>
2809 <p>27.6.3 [std.manip] paragraph 5 says:</p>
2810 <blockquote>
2811 <pre>smanip setbase(int base);</pre>
2812 <p> Returns: An object s of unspecified type such that if out is an
2813 (instance of) basic_ostream then the expression out&lt;&lt;s behaves
2814 as if f(s) were called, in is an (instance of) basic_istream then the
2815 expression in&gt;&gt;s behaves as if f(s) were called. Where f can be
2816 defined as:</p>
2817 <pre>ios_base&amp; f(ios_base&amp; str, int base)
2818 {
2819   // set basefield
2820   str.setf(n == 8 ? ios_base::oct :
2821                 n == 10 ? ios_base::dec :
2822                 n == 16 ? ios_base::hex :
2823                   ios_base::fmtflags(0), ios_base::basefield);
2824   return str;
2825 }</pre>
2826 </blockquote>
2827 <p>There are two problems here. First, f takes two parameters, so the
2828 description needs to say that out&lt;&lt;s and in&gt;&gt;s behave as if f(s,base)
2829 had been called. Second, f is has a parameter named base, but is written as if
2830 the parameter was named n.</p>
2831 <p>Actually, there's a third problem. The paragraph has grammatical errors.
2832 There needs to be an "and" after the first comma, and the "Where
2833 f" sentence fragment needs to be merged into its preceding sentence. You
2834 may also want to format the function a little better. The formatting above is
2835 more-or-less what the Standard contains.</p>
2836
2837
2838 <p><b>Rationale:</b></p>
2839 <p>The resolution of this defect is subsumed by the proposed resolution for
2840 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>.</p>
2841
2842 <p><i>[Tokyo: The LWG agrees that this is a defect and notes that it
2843 occurs additional places in the section, all requiring fixes.]</i></p>
2844
2845
2846
2847
2848
2849
2850
2851
2852 <hr>
2853 <h3><a name="218"></a>218. Algorithms do not use binary predicate objects for default comparisons</h3>
2854 <p><b>Section:</b> 25.3 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2855  <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2000-03-06</p>
2856 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.sorting">issues</a> in [alg.sorting].</p>
2857 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2858 <p><b>Discussion:</b></p>
2859 <p>Many of the algorithms take an argument, pred, of template parameter type
2860 BinaryPredicate or an argument comp of template parameter type Compare. These
2861 algorithms usually have an overloaded version that does not take the predicate
2862 argument. In these cases pred is usually replaced by the use of operator== and
2863 comp is replaced by the use of operator&lt;.</p>
2864 <p>This use of hard-coded operators is inconsistent with other parts of the
2865 library, particularly the containers library, where equality is established
2866 using equal_to&lt;&gt; and ordering is established using less&lt;&gt;. Worse,
2867 the use of operator&lt;, would cause the following innocent-looking code to have
2868 undefined behavior:</p>
2869 <blockquote>
2870   <pre>vector&lt;string*&gt; vec;
2871 sort(vec.begin(), vec.end());</pre>
2872 </blockquote>
2873 <p>The use of operator&lt; is not defined for pointers to unrelated objects. If
2874 std::sort used less&lt;&gt; to compare elements, then the above code would be
2875 well-defined, since less&lt;&gt; is explicitly specialized to produce a total
2876 ordering of pointers.</p>
2877
2878
2879 <p><b>Rationale:</b></p>
2880 <p>This use of operator== and operator&lt; was a very deliberate, conscious, and
2881 explicitly made design decision; these operators are often more efficient. The
2882 predicate forms are available for users who don't want to rely on operator== and
2883 operator&lt;.</p>
2884
2885
2886
2887
2888 <hr>
2889 <h3><a name="219"></a>219. find algorithm missing version that takes a binary predicate argument</h3>
2890 <p><b>Section:</b> 25.1.2 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
2891  <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2000-03-06</p>
2892 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p>
2893 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
2894 <p><b>Discussion:</b></p>
2895 <p>The find function always searches for a value using operator== to compare the
2896 value argument to each element in the input iterator range. This is inconsistent
2897 with other find-related functions such as find_end and find_first_of, which
2898 allow the caller to specify a binary predicate object to be used for determining
2899 equality. The fact that this can be accomplished using a combination of find_if
2900 and bind_1st or bind_2nd does not negate the desirability of a consistent,
2901 simple, alternative interface to find.</p>
2902
2903
2904 <p><b>Proposed resolution:</b></p>
2905 <blockquote>
2906 <p>In section 25.1.2 [alg.find], add a second prototype for find
2907 (between the existing prototype and the prototype for find_if), as
2908 follows:</p>
2909 <pre>    template&lt;class InputIterator, class T, class BinaryPredicate&gt;
2910       InputIterator find(InputIterator first, InputIterator last,
2911                          const T&amp; value, BinaryPredicate bin_pred);</pre>
2912 <p>Change the description of the return from:</p>
2913 <blockquote>
2914   <p>Returns: The first iterator i in the range [first, last) for which the following corresponding
2915   conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.</p>
2916 </blockquote>
2917 <p>&nbsp;to:</p>
2918 <blockquote>
2919   <p>Returns: The first iterator i in the range [first, last) for which the following&nbsp;
2920   corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*)
2921   != false. Return last if no such iterator is found.</p>
2922 </blockquote>
2923 </blockquote>
2924
2925
2926 <p><b>Rationale:</b></p>
2927 <p>This is request for a pure extension, so it is not a defect in the
2928 current standard.&nbsp; As the submitter pointed out, "this can
2929 be accomplished using a combination of find_if and bind_1st or
2930 bind_2nd".</p>
2931
2932
2933
2934
2935 <hr>
2936 <h3><a name="236"></a>236. ctype&lt;char&gt;::is() member modifies facet</h3>
2937 <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#Dup">Dup</a>
2938  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p>
2939 <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>
2940 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2941 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a></p>
2942 <p><b>Discussion:</b></p>
2943 <p>The description of the <tt>is()</tt> member in paragraph 4 of 22.2.1.3.2 [facet.ctype.char.members] is broken: According to this description, the
2944 second form of the <tt>is()</tt> method modifies the masks in the
2945 <tt>ctype</tt> object. The correct semantics if, of course, to obtain
2946 an array of masks. The corresponding method in the general case,
2947 ie. the <tt>do_is()</tt> method as described in 22.2.1.1.2 [locale.ctype.virtuals] paragraph 1 does the right thing.</p>
2948
2949
2950 <p><b>Proposed resolution:</b></p>
2951   <p>Change paragraph 4 from</p>
2952     <blockquote><p>
2953     The second form, for all *p in the range [low, high), assigns
2954     vec[p-low] to table()[(unsigned char)*p].
2955     </p></blockquote>
2956   <p>to become</p>
2957     <blockquote><p>
2958     The second form, for all *p in the range [low, high), assigns
2959     table()[(unsigned char)*p] to vec[p-low].
2960   </p></blockquote>
2961
2962
2963 <p><b>Rationale:</b></p>
2964
2965
2966
2967
2968
2969 <hr>
2970 <h3><a name="244"></a>244. Must <tt>find</tt>'s third argument be CopyConstructible?</h3>
2971 <p><b>Section:</b> 25.1.2 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2972  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-05-02</p>
2973 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p>
2974 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2975 <p><b>Discussion:</b></p>
2976 <p>Is the following implementation of <tt>find</tt> acceptable?</p>
2977
2978 <pre>        template&lt;class Iter, class X&gt;
2979         Iter find(Iter begin, Iter end, const X&amp; x)
2980         {
2981             X x1 = x;           // this is the crucial statement
2982             while (begin != end &amp;&amp; *begin != x1)
2983                 ++begin;
2984             return begin;
2985         }
2986 </pre>
2987
2988 <p>If the answer is yes, then it is implementation-dependent as to
2989 whether the following fragment is well formed:</p>
2990
2991 <pre>        vector&lt;string&gt; v;
2992
2993         find(v.begin(), v.end(), "foo");
2994 </pre>
2995
2996 <p>At issue is whether there is a requirement that the third argument
2997 of find be CopyConstructible.  There may be no problem here, but
2998 analysis is necessary.</p>
2999
3000
3001 <p><b>Rationale:</b></p>
3002 <p>There is no indication in the standard that find's third argument
3003 is required to be Copy Constructible.  The LWG believes that no such
3004 requirement was intended.  As noted above, there are times when a user
3005 might reasonably pass an argument that is not Copy Constructible.</p>
3006
3007
3008
3009
3010 <hr>
3011 <h3><a name="245"></a>245. Which operations on <tt>istream_iterator</tt> trigger input operations?</h3>
3012 <p><b>Section:</b> 24.5.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3013  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-05-02</p>
3014 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3015 <p><b>Discussion:</b></p>
3016 <p>I do not think the standard specifies what operation(s) on istream
3017 iterators trigger input operations.  So, for example:</p>
3018
3019 <pre>        istream_iterator&lt;int&gt; i(cin);
3020
3021         int n = *i++;
3022 </pre>
3023
3024 <p>I do not think it is specified how many integers have been read
3025 from cin.  The number must be at least 1, of course, but can it be 2?
3026 More?</p>
3027
3028
3029 <p><b>Rationale:</b></p>
3030 <p>The standard is clear as written: the stream is read every time
3031 operator++ is called, and it is also read either when the iterator is
3032 constructed or when operator* is called for the first time.  In the
3033 example above, exactly two integers are read from cin.</p>
3034
3035 <p>There may be a problem with the interaction between istream_iterator
3036 and some STL algorithms, such as find.  There are no guarantees about
3037 how many times find may invoke operator++.</p>
3038
3039
3040
3041
3042 <hr>
3043 <h3><a name="246"></a>246. <tt>a.insert(p,t)</tt> is incorrectly specified</h3>
3044 <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#Dup">Dup</a>
3045  <b>Submitter:</b> Mark Rodgers <b>Date:</b> 2000-05-19</p>
3046 <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>
3047 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
3048 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p>
3049 <p><b>Discussion:</b></p>
3050 <p>Closed issue 192 raised several problems with the specification of
3051 this function, but was rejected as Not A Defect because it was too big
3052 a change with unacceptable impacts on existing implementations.
3053 However, issues remain that could be addressed with a smaller change
3054 and with little or no consequent impact.</p>
3055
3056 <ol>
3057    <li><p> The specification is inconsistent with the original
3058    proposal and with several implementations.</p>
3059
3060    <p>The initial implementation by Hewlett Packard only ever looked
3061    immediately <i>before</i> p, and I do not believe there was any
3062    intention to standardize anything other than this behavior.
3063    Consequently, current implementations by several leading
3064    implementors also look immediately before p, and will only insert
3065    after p in logarithmic time.  I am only aware of one implementation
3066    that does actually look after p, and it looks before p as well.  It
3067    is therefore doubtful that existing code would be relying on the
3068    behavior defined in the standard, and it would seem that fixing
3069    this defect as proposed below would standardize existing
3070    practice.</p></li>
3071
3072    <li><p>
3073    The specification is inconsistent with insertion for sequence
3074    containers.</p>
3075
3076    <p>This is difficult and confusing to teach to newcomers.  All
3077    insert operations that specify an iterator as an insertion location
3078    should have a consistent meaning for the location represented by
3079    that iterator.</p></li>
3080
3081    <li><p> As specified, there is no way to hint that the insertion
3082    should occur at the beginning of the container, and the way to hint
3083    that it should occur at the end is long winded and unnatural.</p>
3084
3085    <p>For a container containing n elements, there are n+1 possible
3086    insertion locations and n+1 valid iterators.  For there to be a
3087    one-to-one mapping between iterators and insertion locations, the
3088    iterator must represent an insertion location immediately before
3089    the iterator.</p></li>
3090
3091    <li><p> When appending sorted ranges using insert_iterators,
3092    insertions are guaranteed to be sub-optimal.</p>
3093
3094    <p>In such a situation, the optimum location for insertion is
3095    always immediately after the element previously inserted.  The
3096    mechanics of the insert iterator guarantee that it will try and
3097    insert after the element after that, which will never be correct.
3098    However, if the container first tried to insert before the hint,
3099    all insertions would be performed in amortized constant
3100    time.</p></li>
3101 </ol>
3102
3103
3104 <p><b>Proposed resolution:</b></p>
3105 <p>In 23.1.2 [lib.associative.reqmts] paragraph 7, table 69, make
3106 the following changes in the row for a.insert(p,t):</p>
3107
3108 <p><i>assertion/note pre/post condition:</i>
3109 <br>Change the last sentence from</p>
3110      <blockquote><p>
3111      "iterator p is a hint pointing to where the insert should
3112      start to search."
3113      </p></blockquote>
3114 <p>to</p>
3115      <blockquote><p>
3116      "iterator p is a hint indicating that immediately before p
3117      may be a correct location where the insertion could occur."
3118      </p></blockquote>
3119
3120 <p><i>complexity:</i><br>
3121 Change the words "right after" to "immediately before".</p>
3122
3123
3124 <p><b>Rationale:</b></p>
3125
3126
3127
3128
3129
3130 <hr>
3131 <h3><a name="249"></a>249. Return Type of <tt>auto_ptr::operator=</tt></h3>
3132 <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#NAD">NAD</a>
3133  <b>Submitter:</b> Joseph Gottman <b>Date:</b> 2000-06-30</p>
3134 <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>
3135 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3136 <p><b>Discussion:</b></p>
3137 <p>According to section 20.4.5, the function
3138 <tt>auto_ptr::operator=()</tt> returns a reference to an auto_ptr.
3139 The reason that <tt>operator=()</tt> usually returns a reference is to
3140 facilitate code like</p>
3141
3142 <pre>    int x,y,z;
3143     x = y = z = 1;
3144 </pre>
3145
3146 <p>However, given analogous code for <tt>auto_ptr</tt>s,</p>
3147 <pre>    auto_ptr&lt;int&gt; x, y, z;
3148     z.reset(new int(1));
3149     x = y = z;
3150 </pre>
3151
3152 <p>the result would be that <tt>z</tt> and <tt>y</tt> would both be set to
3153 NULL, instead of all the <tt>auto_ptr</tt>s being set to the same value.
3154 This makes such cascading assignments useless and counterintuitive for
3155 <tt>auto_ptr</tt>s.</p>
3156
3157
3158 <p><b>Proposed resolution:</b></p>
3159 <p>Change <tt>auto_ptr::operator=()</tt> to return <tt>void</tt> instead
3160 of an <tt>auto_ptr</tt> reference.</p>
3161
3162
3163 <p><b>Rationale:</b></p>
3164 <p>The return value has uses other than cascaded assignments: a user can
3165 call an auto_ptr member function, pass the auto_ptr to a
3166 function, etc.  Removing the return value could break working user
3167 code.</p>
3168
3169
3170
3171
3172 <hr>
3173 <h3><a name="257"></a>257. STL functional object and iterator inheritance.</h3>
3174 <p><b>Section:</b> 20.5.3 [base], 24.3.2 [iterator.basic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3175  <b>Submitter:</b> Robert Dick  <b>Date:</b> 2000-08-17</p>
3176 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
3177 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3178 <p><b>Discussion:</b></p>
3179 <p>
3180 According to the November 1997 Draft Standard, the results of deleting an
3181 object of a derived class through a pointer to an object of its base class are
3182 undefined if the base class has a non-virtual destructor.  Therefore, it is
3183 potentially dangerous to publicly inherit from such base classes.
3184 </p>
3185
3186 <p>Defect:
3187 <br>
3188 The STL design encourages users to publicly inherit from a number of classes
3189 which do nothing but specify interfaces, and which contain non-virtual
3190 destructors.
3191 </p>
3192
3193 <p>Attribution:
3194 <br>
3195 Wil Evers and William E. Kempf suggested this modification for functional
3196 objects.
3197 </p>
3198
3199
3200 <p><b>Proposed resolution:</b></p>
3201 <p>
3202 When a base class in the standard library is useful only as an interface
3203 specifier, i.e., when an object of the class will never be directly
3204 instantiated, specify that the class contains a protected destructor.  This
3205 will prevent deletion through a pointer to the base class without performance,
3206 or space penalties (on any implementation I'm aware of).
3207 </p>
3208
3209 <p>
3210 As an example, replace...
3211 </p>
3212
3213 <pre>    template &lt;class Arg, class Result&gt;
3214     struct unary_function {
3215             typedef Arg    argument_type;
3216             typedef Result result_type;
3217     };
3218 </pre>
3219
3220 <p>
3221 ... with...
3222 </p>
3223
3224 <pre>    template &lt;class Arg, class Result&gt;
3225     struct unary_function {
3226             typedef Arg    argument_type;
3227             typedef Result result_type;
3228     protected:
3229             ~unary_function() {}
3230     };
3231 </pre>
3232
3233 <p>
3234 Affected definitions:
3235 <br>
3236   &nbsp;20.3.1 [lib.function.objects] -- unary_function, binary_function
3237   <br>
3238   &nbsp;24.3.2 [lib.iterator.basic] -- iterator
3239 </p>
3240
3241
3242 <p><b>Rationale:</b></p>
3243 <p>
3244 The standard is clear as written; this is a request for change, not a
3245 defect in the strict sense.  The LWG had several different objections
3246 to the proposed change.  One is that it would prevent users from
3247 creating objects of type <tt>unary_function</tt> and
3248 <tt>binary_function</tt>.  Doing so can sometimes be legitimate, if users
3249 want to pass temporaries as traits or tag types in generic code.
3250 </p>
3251
3252
3253
3254
3255
3256 <hr>
3257 <h3><a name="267"></a>267. interaction of strstreambuf::overflow() and seekoff()</h3>
3258 <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#NAD">NAD</a>
3259  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-10-05</p>
3260 <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>
3261 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3262 <p><b>Discussion:</b></p>
3263 <p>
3264 It appears that the interaction of the strstreambuf members overflow()
3265 and seekoff() can lead to undefined behavior in cases where defined
3266 behavior could reasonably be expected. The following program
3267 demonstrates this behavior:
3268 </p>
3269
3270 <pre>    #include &lt;strstream&gt;
3271
3272     int main ()
3273     {
3274          std::strstreambuf sb;
3275          sb.sputc ('c');
3276
3277          sb.pubseekoff (-1, std::ios::end, std::ios::in);
3278          return !('c' == sb.sgetc ());
3279     }
3280 </pre>
3281
3282 <p>
3283 D.7.1.1, p1 initializes strstreambuf with a call to basic_streambuf&lt;&gt;(),
3284 which in turn sets all pointers to 0 in 27.5.2.1, p1.
3285 </p>
3286
3287 <p>
3288 27.5.2.2.5, p1 says that basic_streambuf&lt;&gt;::sputc(c) calls
3289 overflow(traits::to_int_type(c)) if a write position isn't available (it
3290 isn't due to the above).
3291 </p>
3292
3293 <p>
3294 D.7.1.3, p3 says that strstreambuf::overflow(off, ..., ios::in) makes at
3295 least one write position available (i.e., it allows the function to make
3296 any positive number of write positions available).
3297 </p>
3298
3299 <p>
3300 D.7.1.3, p13 computes newoff = seekhigh - eback(). In D.7.1, p4 we see
3301 seekhigh = epptr() ? epptr() : egptr(), or seekhigh = epptr() in this
3302 case. newoff is then epptr() - eback().
3303 </p>
3304
3305 <p>
3306 D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, or
3307 gptr() == epptr() + off holds.
3308 </p>
3309
3310 <p>
3311 If strstreambuf::overflow() made exactly one write position available
3312 then gptr() will be set to just before epptr(), and the program will
3313 return 0. Buf if the function made more than one write position
3314 available, epptr() and gptr() will both point past pptr() and the
3315 behavior of the program is undefined.
3316 </p>
3317
3318
3319 <p><b>Proposed resolution:</b></p>
3320
3321
3322    <p>Change the last sentence of D.7.1 [depr.strstreambuf] paragraph 4 from</p>
3323
3324       <blockquote><p>
3325       Otherwise, seeklow equals gbeg and seekhigh is either pend, if
3326       pend is not a null pointer, or gend.
3327       </p></blockquote>
3328
3329    <p>to become</p>
3330
3331       <blockquote><p>
3332       Otherwise, seeklow equals gbeg and seekhigh is either gend if
3333       0 == pptr(), or pbase() + max where max is the maximum value of
3334       pptr() - pbase() ever reached for this stream.
3335       </p></blockquote>
3336
3337 <p><i>[
3338   pre-Copenhagen: Dietmar provided wording for proposed resolution.
3339 ]</i></p>
3340
3341
3342 <p><i>[
3343   post-Copenhagen: Fixed a typo: proposed resolution said to fix
3344   4.7.1, not D.7.1.
3345 ]</i></p>
3346
3347
3348
3349
3350 <p><b>Rationale:</b></p>
3351 <p>This is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>: it's not clear what it
3352 means to seek beyond the current area.  Without resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a> we can't resolve this.  As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>,
3353 the library working group does not wish to invest time nailing down
3354 corner cases in a deprecated feature.</p>
3355
3356
3357
3358
3359
3360 <hr>
3361 <h3><a name="269"></a>269. cstdarg and unnamed parameters</h3>
3362 <p><b>Section:</b> 18.7 [support.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3363  <b>Submitter:</b> J. Stephen Adamczyk <b>Date:</b> 2000-10-10</p>
3364 <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>
3365 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3366 <p><b>Discussion:</b></p>
3367 <p>
3368 One of our customers asks whether this is valid C++:
3369 </p>
3370
3371 <pre>   #include &lt;cstdarg&gt;
3372
3373    void bar(const char *, va_list);
3374
3375    void
3376    foo(const char *file, const char *, ...)
3377    {
3378      va_list ap;
3379      va_start(ap, file);
3380      bar(file, ap);
3381      va_end(ap);
3382    }
3383 </pre>
3384
3385 <p>
3386 The issue being whether it is valid to use cstdarg when the final
3387 parameter before the "..." is unnamed.  cstdarg is, as far
3388 as I can tell, inherited verbatim from the C standard. and the
3389 definition there (7.8.1.1 in the ISO C89 standard) refers to "the
3390 identifier of the rightmost parameter".  What happens when there
3391 is no such identifier?
3392 </p>
3393
3394 <p>
3395 My personal opinion is that this should be allowed, but some tweak
3396 might be required in the C++ standard.
3397 </p>
3398
3399
3400 <p><b>Rationale:</b></p>
3401 <p>
3402 Not a defect, the C and C++ standards are clear.  It is impossible to
3403 use varargs if the parameter immediately before "..." has no
3404 name, because that is the parameter that must be passed to va_start.
3405 The example given above is broken, because va_start is being passed
3406 the wrong parameter.
3407 </p>
3408
3409 <p>
3410 There is no support for extending varargs to provide additional
3411 functionality beyond what's currently there.  For reasons of C/C++
3412 compatibility, it is especially important not to make gratuitous
3413 changes in this part of the C++ standard.  The C committee has already
3414 been requested not to touch this part of the C standard unless
3415 necessary.
3416 </p>
3417
3418
3419
3420
3421 <hr>
3422 <h3><a name="277"></a>277. Normative encouragement in allocator requirements unclear</h3>
3423 <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#NAD">NAD</a>
3424  <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-11-07</p>
3425 <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>
3426 <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>
3427 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3428 <p><b>Discussion:</b></p>
3429 <p>
3430 In 20.1.5, paragraph 5, the standard says that "Implementors are
3431 encouraged to supply libraries that can accept allocators that
3432 encapsulate more general memory models and that support non-equal
3433 instances." This is intended as normative encouragement to
3434 standard library implementors.  However, it is possible to interpret
3435 this sentence as applying to nonstandard third-party libraries.
3436 </p>
3437
3438
3439 <p><b>Proposed resolution:</b></p>
3440 <p>
3441 In 20.1.5, paragraph 5, change "Implementors" to
3442 "Implementors of the library described in this International
3443 Standard".
3444 </p>
3445
3446
3447 <p><b>Rationale:</b></p>
3448 <p>The LWG believes the normative encouragement is already
3449 sufficiently clear, and that there are no important consequences
3450 even if it is misunderstood.</p>
3451
3452
3453
3454
3455
3456 <hr>
3457 <h3><a name="279"></a>279. const and non-const iterators should have equivalent typedefs</h3>
3458 <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#NAD">NAD</a>
3459  <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-11-27</p>
3460 <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>
3461 <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>
3462 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3463 <p><b>Discussion:</b></p>
3464
3465 <p>
3466 This came from an email from Steve Cleary to Fergus in reference to
3467 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
3468 this in Toronto and believes it should be a separate issue.
3469 </p>
3470
3471 <p>
3472 Steve said: "We may want to state that the const/non-const iterators must have
3473 the same difference type, size_type, and category."
3474 </p>
3475
3476 <p>
3477 (Comment from Judy)
3478 I'm not sure if the above sentence should be true for all
3479 const and non-const iterators in a particular container, or if it means
3480 the container's iterator can't be compared with the container's
3481 const_iterator unless the above it true. I suspect the former.
3482 </p>
3483
3484
3485 <p><b>Proposed resolution:</b></p>
3486 <p>
3487 In <b>Section:</b> 23.1 [container.requirements],
3488 table 65, in the assertion/note pre/post condition for X::const_iterator,
3489 add the following:
3490 </p>
3491
3492 <blockquote>
3493 <p>
3494 typeid(X::const_iterator::difference_type) == typeid(X::iterator::difference_type)
3495 </p>
3496
3497 <p>
3498 typeid(X::const_iterator::size_type) == typeid(X::iterator::size_type)
3499 </p>
3500
3501 <p>
3502 typeid(X::const_iterator::category) == typeid(X::iterator::category)
3503 </p>
3504 </blockquote>
3505
3506
3507 <p><b>Rationale:</b></p>
3508 <p>Going through the types one by one: Iterators don't have a
3509 <tt>size_type</tt>.  We already know that the difference types are
3510 identical, because the container requirements already say that the
3511 difference types of both X::iterator and X::const_iterator are both
3512 X::difference_type.  The standard does not require that X::iterator
3513 and X::const_iterator have the same iterator category, but the LWG
3514 does not see this as a defect: it's possible to imagine cases in which
3515 it would be useful for the categories to be different.</p>
3516
3517 <p>It may be desirable to require X::iterator and X::const_iterator to
3518 have the same value type, but that is a new issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>.)</p>
3519
3520
3521
3522
3523
3524
3525 <hr>
3526 <h3><a name="287"></a>287. conflicting ios_base fmtflags</h3>
3527 <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#NAD">NAD</a>
3528  <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
3529 <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>
3530 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3531 <p><b>Discussion:</b></p>
3532 <p>
3533 The Effects clause for ios_base::setf(fmtflags fmtfl) says
3534 "Sets fmtfl in flags()".  What happens if the user first calls
3535 ios_base::scientific and then calls ios_base::fixed or vice-versa?
3536 This is an issue for all of the conflicting flags, i.e. ios_base::left
3537 and ios_base::right or ios_base::dec, ios_base::hex and ios_base::oct.
3538 </p>
3539
3540 <p>
3541 I see three possible solutions:
3542 </p>
3543
3544 <ol>
3545 <li>Set ios_base::failbit whenever the user specifies a conflicting
3546 flag with one previously explicitly set. If the constructor is
3547 supposed to set ios_base::dec (see discussion below), then
3548 the user setting hex or oct format after construction will not
3549 set failbit. </li>
3550 <li>The last call to setf "wins", i.e. it clears any conflicting
3551 previous setting.</li>
3552 <li>All the flags that the user specifies are set, but when actually
3553 interpreting them, fixed always override scientific, right always
3554 overrides left, dec overrides hex which overrides oct.</li>
3555 </ol>
3556
3557 <p>
3558 Most existing implementations that I tried seem to conform to resolution #3,
3559 except that when using the iomanip manipulator hex or oct then that always
3560 overrides dec, but calling setf(ios_base::hex) doesn't.
3561 </p>
3562
3563 <p>
3564 There is a sort of related issue, which is that although the ios_base
3565 constructor says that each ios_base member has an indeterminate value
3566 after construction, all the existing implementations I tried explicitly set
3567 ios_base::dec.
3568 </p>
3569
3570
3571 <p><b>Proposed resolution:</b></p>
3572
3573
3574 <p><b>Rationale:</b></p>
3575 <p>
3576 <tt>adjustfield</tt>, <tt>basefield</tt>, and <tt>floatfield</tt>
3577 are each multi-bit fields.  It is possible to set multiple bits within
3578 each of those fields.  (For example, <tt>dec</tt> and
3579 <tt>oct</tt>). These fields are used by locale facets. The LWG
3580 reviewed the way in which each of those three fields is used, and
3581 believes that in each case the behavior is well defined for any
3582 possible combination of bits. See for example Table 58, in 22.2.2.2.2
3583 [facet.num.put.virtuals], noting the requirement in paragraph 6 of that
3584 section.
3585 </p>
3586 <p>
3587 Users are advised to use manipulators, or else use the two-argument
3588 version of <tt>setf</tt>, to avoid unexpected behavior.
3589 </p>
3590
3591
3592
3593
3594
3595 <hr>
3596 <h3><a name="289"></a>289. &lt;cmath&gt; requirements missing C float and long double versions</h3>
3597 <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#NAD">NAD</a>
3598  <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
3599 <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>
3600 <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>
3601 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3602 <p><b>Discussion:</b></p>
3603 <p>
3604     In ISO/IEC 9899:1990 Programming Languages C we find the following
3605     concerning &lt;math.h&gt;:
3606 </p>
3607
3608 <blockquote><p>
3609          7.13.4 Mathematics &lt;math.h&gt;
3610          <br>
3611          The names of all existing functions declared in the &lt;math.h&gt;
3612          header, suffixed with f or l, are reserved respectively for
3613          corresponding functions with float and long double arguments
3614          are return values.
3615 </p></blockquote>
3616
3617 <p>
3618     For example, <tt>float&nbsp;sinf(float)</tt>
3619     is reserved.
3620 </p>
3621
3622 <p>
3623     In the C99 standard, &lt;math.h&gt; must contain declarations
3624     for these functions.
3625 </p>
3626
3627 <p>
3628 So, is it acceptable for an implementor to add these prototypes to the
3629 C++ versions of the math headers? Are they required?
3630 </p>
3631
3632
3633 <p><b>Proposed resolution:</b></p>
3634 <p>
3635 Add these Functions to Table 80, section 26.5 and to Table 99,
3636 section C.2:
3637 </p>
3638
3639 <pre>    acosf asinf atanf atan2f ceilf cosf coshf
3640     expf fabsf floorf fmodf frexpf ldexpf
3641     logf log10f modff powf sinf sinhf sqrtf
3642     tanf tanhf
3643     acosl asinl atanl atan2l ceill cosl coshl
3644     expl fabsl floorl fmodl frexpl ldexpl
3645     logl log10l modfl powl sinl sinhl sqrtl
3646     tanl tanhl
3647 </pre>
3648
3649 <p>
3650 There should probably be a note saying that these functions
3651 are optional and, if supplied, should match the description in
3652 the 1999 version of the C standard. In the next round
3653 of C++ standardization they can then become mandatory.
3654 </p>
3655
3656
3657 <p><b>Rationale:</b></p>
3658 <p>The C90 standard, as amended, already permits (but does not
3659 require) these functions, and the C++ standard incorporates the
3660 C90 standard by reference.  C99 is not an issue, because it is
3661 never referred to by the C++ standard.</p>
3662
3663
3664
3665
3666
3667 <hr>
3668 <h3><a name="293"></a>293. Order of execution in transform algorithm</h3>
3669 <p><b>Section:</b> 25.2.4 [alg.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3670  <b>Submitter:</b> Angelika Langer <b>Date:</b> 2001-01-04</p>
3671 <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>
3672 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3673 <p><b>Discussion:</b></p>
3674 <p>This issue is related to issue 242.  In case that the resolution
3675 proposed for issue 242 is accepted, we have have the following
3676 situation: The 4 numeric algorithms (accumulate and consorts) as well
3677 as transform would allow a certain category of side effects.  The
3678 numeric algorithms specify that they invoke the functor "for
3679 every iterator i in the range [first, last) in order". transform,
3680 in contrast, would not give any guarantee regarding order of
3681 invocation of the functor, which means that the functor can be invoked
3682 in any arbitrary order.
3683 </p>
3684
3685 <p>Why would that be a problem?  Consider an example: say the
3686 transformator that is a simple enumerator ( or more generally
3687 speaking, "is order-sensitive" ).  Since a standard
3688 compliant implementation of transform is free to invoke the enumerator
3689 in no definite order, the result could be a garbled enumeration.
3690 Strictly speaking this is not a problem, but it is certainly at odds
3691 with the prevalent understanding of transform as an algorithms that
3692 assigns "a new _corresponding_ value" to the output
3693 elements.
3694 </p>
3695
3696 <p>All implementations that I know of invoke the transformator in
3697 definite order, namely starting from first and proceeding to last -
3698 1. Unless there is an optimization conceivable that takes advantage of
3699 the indefinite order I would suggest to specify the order, because it
3700 eliminate the uncertainty that users would otherwise have regarding
3701 the order of execution of their potentially order-sensitive function
3702 objects.
3703 </p>
3704
3705
3706 <p><b>Proposed resolution:</b></p>
3707 <p>In section 25.2.3 - Transform [lib.alg.transform] change:</p>
3708 <blockquote><p>
3709 -1- Effects: Assigns through every iterator i in the range [result,
3710 result + (last1 - first1)) a new corresponding
3711 value equal to op(*(first1 + (i - result)) or binary_op(*(first1 +
3712 (i - result), *(first2 + (i - result))).
3713 </p></blockquote>
3714 <p>to:</p>
3715 <blockquote><p>
3716 -1- Effects: Computes values by  invoking the operation op or binary_op
3717 for every iterator in the range [first1, last1) in order. Assigns through
3718 every iterator i in the range [result, result + (last1 - first1)) a new
3719 corresponding
3720 value equal to op(*(first1 + (i - result)) or binary_op(*(first1 +
3721 (i - result), *(first2 + (i - result))).
3722 </p></blockquote>
3723
3724
3725 <p><b>Rationale:</b></p>
3726 <p>For Input Iterators an order is already guaranteed, because
3727 only one order is possible.  If a user who passes a Forward
3728 Iterator to one of these algorithms really needs a specific
3729 order of execution, it's possible to achieve that effect by
3730 wrapping it in an Input Iterator adaptor.</p>
3731
3732
3733
3734
3735
3736 <hr>
3737 <h3><a name="296"></a>296. Missing descriptions and requirements of pair operators</h3>
3738 <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#NAD">NAD</a>
3739  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-14</p>
3740 <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>
3741 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3742 <p><b>Discussion:</b></p>
3743 <p>The synopsis of the header <tt>&lt;utility&gt;</tt> in 20.2 [utility]
3744 lists the complete set of equality and relational operators for <tt>pair</tt>
3745 but the section describing the template and the operators only describes
3746 <tt>operator==()</tt> and <tt>operator&lt;()</tt>, and it fails to mention
3747 any requirements on the template arguments. The remaining operators are
3748 not mentioned at all.
3749 </p>
3750
3751
3752 <p><b>Rationale:</b></p>
3753 <p>20.2.1 [operators] paragraph 10 already specifies the semantics.
3754 That paragraph says that, if declarations of operator!=, operator&gt;,
3755 operator&lt;=, and operator&gt;= appear without definitions, they are
3756 defined as specified in 20.2.1 [operators].  There should be no user
3757 confusion, since that paragraph happens to immediately precede the
3758 specification of <tt>pair</tt>.</p>
3759
3760
3761
3762
3763
3764 <hr>
3765 <h3><a name="302"></a>302. Need error indication from codecvt&lt;&gt;::do_length</h3>
3766 <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#NAD">NAD</a>
3767  <b>Submitter:</b> Gregory Bumgardner <b>Date:</b> 2001-01-25</p>
3768 <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>
3769 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3770 <p><b>Discussion:</b></p>
3771 <p>
3772 The effects of <tt>codecvt&lt;&gt;::do_length()</tt> are described in
3773 22.2.1.5.2, paragraph 10.  As implied by that paragraph, and clarified
3774 in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <tt>codecvt&lt;&gt;::do_length()</tt> must
3775 process the source data and update the <tt>stateT</tt> argument just
3776 as if the data had been processed by <tt>codecvt&lt;&gt;::in()</tt>.
3777 However, the standard does not specify how <tt>do_length()</tt> would
3778 report a translation failure, should the source sequence contain
3779 untranslatable or illegal character sequences.
3780 </p>
3781
3782 <p>
3783 The other conversion methods return an "error" result value
3784 to indicate that an untranslatable character has been encountered, but
3785 <tt>do_length()</tt> already has a return value (the number of source
3786 characters that have been processed by the method).
3787 </p>
3788
3789
3790 <p><b>Proposed resolution:</b></p>
3791 <p>
3792 This issue cannot be resolved without modifying the interface. An exception
3793 cannot be used, as there would be no way to determine how many characters
3794 have been processed and the state object would be left in an indeterminate
3795 state.
3796 </p>
3797
3798 <p>
3799 A source compatible solution involves adding a fifth argument to length()
3800 and do_length() that could be used to return position of the offending
3801 character sequence. This argument would have a default value that would
3802 allow it to be ignored:
3803 </p>
3804
3805 <pre>  int length(stateT&amp; state,
3806              const externT* from,
3807              const externT* from_end,
3808              size_t max,
3809              const externT** from_next = 0);
3810
3811   virtual
3812   int do_length(stateT&amp; state,
3813                 const externT* from,
3814                 const externT* from_end,
3815                 size_t max,
3816                 const externT** from_next);
3817 </pre>
3818
3819 <p>
3820 Then an exception could be used to report any translation errors and
3821 the from_next argument, if used, could then be used to retrieve the
3822 location of the offending character sequence.
3823 </p>
3824
3825
3826 <p><b>Rationale:</b></p>
3827 <p>The standard is already clear: the return value is the number of
3828 "valid complete characters".  If it encounters an invalid sequence of
3829 external characters, it stops.</p>
3830
3831
3832
3833
3834
3835 <hr>
3836 <h3><a name="304"></a>304. Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</h3>
3837 <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#NAD">NAD</a>
3838  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-02-05</p>
3839 <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>
3840 <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>
3841 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3842 <p><b>Discussion:</b></p>
3843 <p>
3844 We all "know" that input iterators are allowed to produce
3845 values when dereferenced of which there is no other in-memory copy.
3846 </p>
3847
3848 <p>
3849 But: Table 72, with a careful reading, seems to imply that this can only be
3850 the case if the value_type has no members (e.g. is a built-in type).
3851 </p>
3852
3853 <p>The problem occurs in the following entry:</p>
3854
3855 <pre>  a-&gt;m     pre: (*a).m is well-defined
3856            Equivalent to (*a).m
3857 </pre>
3858
3859 <p>
3860 <tt>*a.m</tt> can be well-defined if <tt>*a</tt> is not a reference
3861 type, but since <tt>operator-&gt;()</tt> must return a pointer for
3862 <tt>a-&gt;m</tt> to be well-formed, it needs something to return a
3863 pointer <i>to</i>. This seems to indicate that <tt>*a</tt> must be
3864 buffered somewhere to make a legal input iterator.
3865 </p>
3866
3867 <p>I don't think this was intentional.</p>
3868
3869
3870 <p><b>Rationale:</b></p>
3871 <p>The current standard is clear and consistent.  Input iterators that
3872   return rvalues are in fact implementable.  They may in some cases
3873   require extra work, but it is still possible to define an operator-&gt;
3874   in such cases: it doesn't have to return a T*, but may return a
3875   proxy type.  No change to the standard is justified.</p>
3876
3877
3878
3879
3880
3881 <hr>
3882 <h3><a name="313"></a>313. set_terminate and set_unexpected question</h3>
3883 <p><b>Section:</b> 18.7.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3884  <b>Submitter:</b> Judy Ward <b>Date:</b> 2001-04-03</p>
3885 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</p>
3886 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3887 <p><b>Discussion:</b></p>
3888 <p>
3889 According to section 18.7.3.3 of the standard, std::terminate() is
3890 supposed to call the terminate_handler in effect immediately after
3891 evaluating the throw expression.
3892 </p>
3893
3894 <p>
3895 Question: what if the terminate_handler in effect is itself
3896 std::terminate?
3897 </p>
3898
3899 <p>For example:</p>
3900
3901 <pre>  #include &lt;exception&gt;
3902
3903   int main () {
3904       std::set_terminate(std::terminate);
3905       throw 5;
3906       return 0;
3907   }
3908 </pre>
3909
3910 <p>
3911 Is the implementation allowed to go into an infinite loop?
3912 </p>
3913
3914 <p>
3915 I think the same issue applies to std::set_unexpected.
3916 </p>
3917
3918
3919 <p><b>Proposed resolution:</b></p>
3920
3921
3922 <p><b>Rationale:</b></p>
3923 <p>Infinite recursion is to be expected: users who set the terminate
3924 handler to <tt>terminate</tt> are explicitly asking for <tt>terminate</tt>
3925 to call itself.</p>
3926
3927
3928
3929
3930
3931 <hr>
3932 <h3><a name="314"></a>314. Is the stack unwound when terminate() is called?</h3>
3933 <p><b>Section:</b> 18.7.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3934  <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-04-11</p>
3935 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</p>
3936 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3937 <p><b>Discussion:</b></p>
3938
3939 <p>
3940 The standard appears to contradict itself about whether the stack is
3941 unwound when the implementation calls terminate().
3942 </p>
3943
3944 <p>From 18.7.3.3p2:</p>
3945 <blockquote><p>
3946     Calls the terminate_handler function in effect immediately
3947     after evaluating the throw-expression (lib.terminate.handler),
3948     if called by the implementation [...]
3949 </p></blockquote>
3950
3951 <p>So the stack is guaranteed not to be unwound.</p>
3952
3953 <p>But from 15.3p9:</p>
3954 <blockquote><p>
3955     [...]whether or not the stack is unwound before this call
3956     to terminate() is implementation-defined (except.terminate).
3957 </p></blockquote>
3958
3959 <p>
3960 And 15.5.1 actually defines that in most cases the stack is unwound.
3961 </p>
3962
3963
3964 <p><b>Proposed resolution:</b></p>
3965
3966
3967 <p><b>Rationale:</b></p>
3968 <p>There is definitely no contradiction between the core and library
3969 clauses; nothing in the core clauses says that stack unwinding happens
3970 after <tt>terminate</tt> is called.  18.7.3.3p2 does not say anything
3971 about when terminate() is called; it merely specifies which
3972 <tt>terminate_handler</tt> is used.</p>
3973
3974
3975
3976
3977
3978 <hr>
3979 <h3><a name="323"></a>323. abs() overloads in different headers</h3>
3980 <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#NAD%20Future">NAD Future</a>
3981  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-06-04</p>
3982 <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>
3983 <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>
3984 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
3985 <p><b>Discussion:</b></p>
3986 <p>Currently the standard mandates the following overloads of
3987 abs():</p>
3988
3989 <pre>    abs(long), abs(int) in &lt;cstdlib&gt;
3990
3991     abs(float), abs(double), abs(long double) in &lt;cmath&gt;
3992
3993     template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp;) in &lt;complex&gt;
3994
3995     template&lt;class T&gt; valarray&lt;T&gt; abs(const valarray&lt;T&gt;&amp;); in &lt;valarray&gt;
3996 </pre>
3997
3998 <p>
3999 The problem is that having only some overloads visible of a function
4000 that works on "implicitly inter-convertible" types is dangerous in
4001 practice. The headers that get included at any point in a translation
4002 unit can change unpredictably during program
4003 development/maintenance. The wrong overload might be unintentionally
4004 selected.
4005 </p>
4006
4007 <p>
4008 Currently, there is nothing that mandates the simultaneous visibility
4009 of these overloads. Indeed, some vendors have begun fastidiously
4010 reducing dependencies among their (public) headers as a QOI issue: it
4011 helps people to write portable code by refusing to compile unless all
4012 the correct headers are #included.
4013 </p>
4014
4015 <p>The same issue may exist for other functions in the library.</p>
4016
4017 <p>Redmond: PJP reports that C99 adds two new kinds of abs: complex,
4018 and int_max_abs.</p>
4019
4020 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#343">343</a>.</p>
4021
4022
4023
4024 <p><b>Rationale:</b></p>
4025 <p>The programs that could potentially be broken by this situation are
4026   already fragile, and somewhat contrived: For example, a user-defined
4027   class that has conversion overloads both to <tt>long</tt> and
4028   to <tt>float</tt>.  If <tt>x</tt> is a value of such a class, then
4029   <tt>abs(x)</tt> would give the <tt>long</tt> version if the user
4030   included &lt;cstdlib&gt;, the <tt>float</tt> version if the user
4031   included &lt;cmath&gt;, and would be diagnosed as ambiguous at
4032   compile time if the user included both headers.  The LWG couldn't
4033   find an example of a program whose meaning would be changed (as
4034   opposed to changing it from well-formed to ill-formed) simply by
4035   adding another standard header.</p>
4036
4037 <p>Since the harm seems minimal, and there don't seem to be any simple
4038   and noninvasive solutions, this is being closed as NAD.  It is
4039   marked as "Future" for two reasons.  First, it might be useful to
4040   define an <tt>&lt;all&gt;</tt> header that would include all
4041   Standard Library headers.  Second, we should at least make sure that
4042   future library extensions don't make this problem worse.</p>
4043
4044
4045
4046
4047
4048 <hr>
4049 <h3><a name="326"></a>326. Missing typedef in moneypunct_byname</h3>
4050 <p><b>Section:</b> 22.2.6.4 [locale.moneypunct.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4051  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-05</p>
4052 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4053 <p><b>Discussion:</b></p>
4054 <p>The definition of the moneypunct facet contains the typedefs char_type
4055 and string_type. Only one of these names, string_type, is defined in
4056 the derived facet, moneypunct_byname.</p>
4057
4058
4059 <p><b>Proposed resolution:</b></p>
4060 <p>For consistency with the numpunct facet, add a typedef for
4061 char_type to the definition of the moneypunct_byname facet in
4062 22.2.6.4 [locale.moneypunct.byname].</p>
4063
4064
4065 <p><b>Rationale:</b></p>
4066 <p>The absence of the typedef is irrelevant.  Users can still access
4067 the typedef, because it is inherited from the base class.</p>
4068
4069
4070
4071
4072
4073 <hr>
4074 <h3><a name="330"></a>330. Misleading "exposition only" value in class locale definition</h3>
4075 <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#NAD">NAD</a>
4076  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-15</p>
4077 <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>
4078 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4079 <p><b>Discussion:</b></p>
4080 <p>
4081 The "exposition only" value of the std::locale::none constant shown in
4082 the definition of class locale is misleading in that it on many
4083 systems conflicts with the value assigned to one if the LC_XXX
4084 constants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPE
4085 on Linux and SunOS). This causes incorrect behavior when such a
4086 constant is passed to one of the locale member functions that accept a
4087 locale::category argument and interpret it as either the C LC_XXX
4088 constant or a bitmap of locale::category values. At least three major
4089 implementations adopt the suggested value without a change and
4090 consequently suffer from this problem.
4091 </p>
4092
4093 <p>
4094 For instance, the following code will (presumably) incorrectly copy facets
4095 belonging to the collate category from the German locale on AIX:
4096 </p>
4097
4098 <pre>  std::locale l (std::locale ("C"), "de_DE", std::locale::none);
4099 </pre>
4100
4101
4102 <p><b>Rationale:</b></p>
4103 <p>The LWG agrees that it may be difficult to implement locale member
4104 functions in such a way that they can take either <tt>category</tt>
4105 arguments or the LC_ constants defined in &lt;cctype&gt;.  In light of
4106 this requirement (22.1.1.1.1 [locale.category], paragraph 2), and in light
4107 of the requirement in the preceding paragraph that it is possible to
4108 combine <tt>category</tt> bitmask elements with bitwise operations,
4109 defining the <tt>category</tt> elements is delicate,
4110 particularly if an implementor is constrained to work with a
4111 preexisting C library.  (Just using the existing LC_ constants would
4112 not work in general.)  There's no set of "exposition only" values that
4113 could give library implementors proper guidance in such a delicate
4114 matter.  The non-normative example we're giving is no worse than
4115 any other choice would be.</p>
4116
4117 <p>See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>.</p>
4118
4119
4120
4121
4122
4123 <hr>
4124 <h3><a name="332"></a>332. Consider adding increment and decrement operators to std::fpos&lt; T &gt; </h3>
4125 <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#NAD">NAD</a>
4126  <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-27</p>
4127 <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>
4128 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4129 <p><b>Discussion:</b></p>
4130 <p>
4131 Increment and decrement operators are missing from
4132 Table 88 -- Position type requirements in 27.4.3 [fpos].
4133 </p>
4134
4135
4136 <p><b>Proposed resolution:</b></p>
4137 <p>
4138 Table 88 (section 27.4.3) -- Position type requirements
4139 be updated to include increment and decrement operators.
4140 </p>
4141
4142 <pre>expression        return type     operational    note
4143
4144 ++p               fpos&amp;           p += O(1)
4145 p++               fpos            { P tmp = p;
4146                                     ++p;
4147                                     return tmp; }
4148 --p               fpos&amp;           p -= O(1)
4149 p--               fpos            { P tmp = p;
4150                                     --p;
4151                                     return tmp; }
4152 </pre>
4153
4154
4155
4156 <p><b>Rationale:</b></p>
4157 <p>The LWG believes this is a request for extension, not a defect
4158 report.  Additionally, nobody saw a clear need for this extension;
4159 <tt>fpos</tt> is used only in very limited ways.</p>
4160
4161
4162
4163
4164
4165 <hr>
4166 <h3><a name="344"></a>344. grouping + showbase</h3>
4167 <p><b>Section:</b> 22.2.2 [category.numeric] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4168  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-10-13</p>
4169 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4170 <p><b>Discussion:</b></p>
4171 <p>
4172 When both grouping and showbase are active and the basefield is octal,
4173 does the leading 0 participate in the grouping or not?  For example,
4174 should one format as: 0,123,456 or 0123,456?
4175 </p>
4176 <p>
4177 An analogy can be drawn with hexadecimal.  It appears that 0x123,456 is
4178 preferred over 0x,123,456.  However, this analogy is not universally
4179 accepted to apply to the octal base.  The standard is not clear on how
4180 to format (or parse) in this manner.
4181 </p>
4182
4183 <p><b>Proposed resolution:</b></p>
4184 <p>
4185 Insert into 22.2.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last
4186 sentence:
4187 </p>
4188 <blockquote><p>
4189 The leading hexadecimal base specifier "0x" does not participate in
4190 grouping.  The leading '0' octal base specifier may participate in
4191 grouping.  It is unspecified if the leading '0' participates in
4192 formatting octal numbers.  In parsing octal numbers, the implementation
4193 is encouraged to accept both the leading '0' participating in the
4194 grouping, and not participating (e.g. 0123,456 or 0,123,456).
4195 </p></blockquote>
4196
4197 <p><b>Rationale:</b></p>
4198 <p>
4199 The current behavior may be unspecified, but it's not clear that it
4200 matters.  This is an obscure corner case, since grouping is usually
4201 intended for the benefit of humans and oct/hex prefixes are usually
4202 intended for the benefit of machines.  There is not a strong enough
4203 consensus in the LWG for action.
4204 </p>
4205
4206
4207
4208
4209 <hr>
4210 <h3><a name="348"></a>348. Minor issue with std::pair operator&lt;</h3>
4211 <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#NAD%20Future">NAD Future</a>
4212  <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-10-23</p>
4213 <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>
4214 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
4215 <p><b>Discussion:</b></p>
4216 <p>
4217 The current wording of 20.2.2 [lib.pairs] p6 precludes the use of
4218 operator&lt; on any pair type which contains a pointer.
4219 </p>
4220
4221
4222 <p><b>Proposed resolution:</b></p>
4223 <p>In 20.2.3 [pairs] paragraph 6, replace:</p>
4224 <pre>    Returns: x.first &lt; y.first || (!(y.first &lt; x.first) &amp;&amp; x.second &lt;
4225         y.second).
4226 </pre>
4227 <p>With:</p>
4228 <pre>    Returns: std::less&lt;T1&gt;()( x.first, y.first ) ||
4229              (!std::less&lt;T1&gt;()( y.first, x.first) &amp;&amp;
4230              std::less&lt;T2&gt;()( x.second, y.second ) )
4231 </pre>
4232
4233
4234
4235 <p><b>Rationale:</b></p>
4236 <p>This is an instance of a much more general problem.  If we want
4237   operator&lt; to translate to std::less for pairs of pointers, where
4238   do we draw the line?  The same issue applies to individual
4239   pointers, smart pointer wrappers, std::vector&lt;T*&gt;, and so
4240   on.</p>
4241
4242 <p>Andy Koenig suggests that the real issue here is that we aren't
4243   distinguishing adequately between two different orderings, a
4244   "useful ordering" and a "canonical ordering" that's used just
4245   because we sometimes need <i>some</i> ordering without caring much
4246   which ordering it is.  Another example of the later is typeinfo's
4247   <tt>before</tt>.</p>
4248
4249
4250
4251
4252
4253
4254 <hr>
4255 <h3><a name="350"></a>350. allocator&lt;&gt;::address</h3>
4256 <p><b>Section:</b> 20.6.1.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
4257  <b>Submitter:</b> Nathan Myers <b>Date:</b> 2001-10-25</p>
4258 <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>
4259 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
4260 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a></p>
4261 <p><b>Discussion:</b></p>
4262 <p>See c++std-lib-9006 and c++std-lib-9007.  This issue is taken
4263 verbatim from -9007.</p>
4264
4265 <p>
4266 The core language feature allowing definition of operator&amp;() applied
4267 to any non-builtin type makes that operator often unsafe to use in
4268 implementing libraries, including the Standard Library.  The result
4269 is that many library facilities fail for legal user code, such as
4270 the fragment</p>
4271 <pre>  class A { private: A* operator&amp;(); };
4272   std::vector&lt;A&gt; aa;
4273
4274   class B { };
4275   B* operator&amp;(B&amp;) { return 0; }
4276   std::vector&lt;B&gt; ba;
4277 </pre>
4278
4279 <p>
4280 In particular, the requirements table for Allocator (Table 32) specifies
4281 no semantics at all for member address(), and allocator&lt;&gt;::address is
4282 defined in terms of unadorned operator &amp;.
4283 </p>
4284
4285
4286
4287 <p><b>Proposed resolution:</b></p>
4288 <p>
4289 In 20.6.1.1, Change the definition of allocator&lt;&gt;::address from:</p>
4290 <blockquote><p>
4291   Returns: &amp;x
4292 </p></blockquote>
4293
4294 <p>to:</p>
4295
4296 <p>
4297   Returns: The value that the built in operator&amp;(x) would return if not
4298   overloaded.
4299 </p>
4300
4301 <p>
4302 In 20.1.6, Table 32, add to the Notes column of the a.address(r) and
4303 a.address(s) lines, respectively:
4304 </p>
4305
4306 <pre>  allocator&lt;T&gt;::address(r)
4307   allocator&lt;T&gt;::address(s)
4308 </pre>
4309
4310 <p>In addition, in clause 17.4.1.1, add a statement:</p>
4311
4312 <blockquote><p>
4313  The Standard Library does not apply operator&amp; to any type for which
4314  operator&amp; may be overloaded.
4315 </p></blockquote>
4316
4317
4318
4319 <p><b>Rationale:</b></p>
4320 <p>The LWG believes both examples are ill-formed.  The contained type
4321 is required to be CopyConstructible (20.1.1 [utility.arg.requirements]), and that
4322 includes the requirement that &amp;t return the usual types and
4323 values. Since allocators are intended to be used in conjunction with
4324 containers, and since the CopyConstructible requirements appear to
4325 have been written to deal with the concerns of this issue, the LWG
4326 feels it is NAD unless someone can come up with a well-formed example
4327 exhibiting a problem.</p>
4328
4329 <p>It may well be that the CopyConstructible requirements are too
4330   restrictive and that either the container requirements or the
4331   CopyConstructive requirements should be relaxed, but that's a far
4332   larger issue.  Marking this issue as "future" as a pointer to that
4333   larger issue.</p>
4334
4335
4336
4337
4338
4339 <hr>
4340 <h3><a name="351"></a>351. unary_negate and binary_negate: struct or class?</h3>
4341 <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#NAD%20Editorial">NAD Editorial</a>
4342  <b>Submitter:</b> Dale Riley <b>Date:</b> 2001-11-12</p>
4343 <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>
4344 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
4345 <p><b>Discussion:</b></p>
4346 <p>
4347 In 20.5 [function.objects] the header &lt;functional&gt; synopsis declares
4348 the unary_negate and binary_negate function objects as struct.
4349 However in 20.5.10 [negators] the unary_negate and binary_negate
4350 function objects are defined as class.  Given the context, they are
4351 not "basic function objects" like negate, so this is either a typo or
4352 an editorial oversight.
4353 </p>
4354
4355 <p><i>[Taken from comp.std.c++]</i></p>
4356
4357
4358
4359 <p><b>Proposed resolution:</b></p>
4360 <p>Change the synopsis to reflect the useage in 20.5.10 [negators]</p>
4361
4362 <p><i>[Curaçao: Since the language permits "struct", the LWG
4363 views this as NAD. They suggest, however, that the Project Editor
4364 might wish to make the change as editorial.]</i></p>
4365
4366
4367
4368
4369
4370
4371
4372 <hr>
4373 <h3><a name="353"></a>353. <tt>std::pair</tt> missing template assignment</h3>
4374 <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#NAD%20Future">NAD Future</a>
4375  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-12-02</p>
4376 <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>
4377 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
4378 <p><b>Discussion:</b></p>
4379 <p>
4380 The class template <tt>std::pair</tt> defines a template ctor (20.2.2, p4) but
4381 no template assignment operator. This may lead to inefficient code since
4382 assigning an object of <tt>pair&lt;C, D&gt;</tt> to <tt>pair&lt;A, B&gt;</tt>
4383 where the types <tt>C</tt> and <tt>D</tt> are distinct from but convertible to
4384 <tt>A</tt> and <tt>B</tt>, respectively, results in a call to the template copy
4385 ctor to construct an unnamed temporary of type <tt>pair&lt;A, B&gt;</tt>
4386 followed by an ordinary (perhaps implicitly defined) assignment operator,
4387 instead of just a straight assignment.
4388 </p>
4389
4390
4391 <p><b>Proposed resolution:</b></p>
4392 <p>
4393 Add the following declaration to the definition of <tt>std::pair</tt>:
4394 </p>
4395 <pre>    template&lt;class U, class V&gt;
4396     pair&amp; operator=(const pair&lt;U, V&gt; &amp;p);
4397 </pre>
4398 <p>
4399 And also add a paragraph describing the effects of the function template to the
4400 end of 20.2.2:
4401 </p>
4402 <pre>    template&lt;class U, class V&gt;
4403     pair&amp; operator=(const pair&lt;U, V&gt; &amp;p);
4404 </pre>
4405 <p>
4406     <b>Effects</b>: <tt>first = p.first;</tt>
4407                     <tt>second = p.second;</tt>
4408     <b>Returns</b>: <tt>*this</tt>
4409 </p>
4410
4411 <p><i>[Curaçao: There is no indication this is was anything other than
4412 a design decision, and thus NAD.&nbsp; May be appropriate for a future
4413 standard.]</i></p>
4414
4415
4416
4417
4418
4419
4420 <hr>
4421 <h3><a name="356"></a>356. Meaning of ctype_base::mask enumerators</h3>
4422 <p><b>Section:</b> 22.2.1 [category.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4423  <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-01-23</p>
4424 <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>
4425 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4426 <p><b>Discussion:</b></p>
4427
4428 <p>What should the following program print?</p>
4429
4430 <pre>  #include &lt;locale&gt;
4431   #include &lt;iostream&gt;
4432
4433   class my_ctype : public std::ctype&lt;char&gt;
4434   {
4435     typedef std::ctype&lt;char&gt; base;
4436   public:
4437     my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
4438     {
4439       std::copy(base::classic_table(), base::classic_table() + base::table_size,
4440                 my_table);
4441       my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space);
4442     }
4443   private:
4444     mask my_table[base::table_size];
4445   };
4446
4447   int main()
4448   {
4449     my_ctype ct;
4450     std::cout &lt;&lt; "isspace: " &lt;&lt; ct.is(std::ctype_base::space, '_') &lt;&lt; "    "
4451               &lt;&lt; "isalpha: " &lt;&lt; ct.is(std::ctype_base::alpha, '_') &lt;&lt; std::endl;
4452   }
4453 </pre>
4454
4455 <p>The goal is to create a facet where '_' is treated as whitespace.</p>
4456
4457 <p>On gcc 3.0, this program prints "isspace: 1 isalpha: 0".  On
4458 Microsoft C++ it prints "isspace: 1 isalpha: 1".</p>
4459
4460 <p>
4461 I believe that both implementations are legal, and the standard does not
4462 give enough guidance for users to be able to use std::ctype's
4463 protected interface portably.</p>
4464
4465 <p>
4466 The above program assumes that ctype_base::mask enumerators like
4467 <tt>space</tt> and <tt>print</tt> are disjoint, and that the way to
4468 say that a character is both a space and a printing character is to or
4469 those two enumerators together.  This is suggested by the "exposition
4470 only" values in 22.2.1 [category.ctype], but it is nowhere specified in
4471 normative text.  An alternative interpretation is that the more
4472 specific categories subsume the less specific.  The above program
4473 gives the results it does on the Microsoft compiler because, on that
4474 compiler, <tt>print</tt> has all the bits set for each specific
4475 printing character class.
4476 </p>
4477
4478 <p>From the point of view of std::ctype's public interface, there's no
4479 important difference between these two techniques.  From the point of
4480 view of the protected interface, there is.  If I'm defining a facet
4481 that inherits from std::ctype&lt;char&gt;, I'm the one who defines the
4482 value that table()['a'] returns.  I need to know what combination of
4483 mask values I should use.  This isn't so very esoteric: it's exactly
4484 why std::ctype has a protected interface.  If we care about users
4485 being able to write their own ctype facets, we have to give them a
4486 portable way to do it.
4487 </p>
4488
4489 <p>
4490 Related reflector messages:
4491 lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274,
4492 lib-9277, lib-9279.
4493 </p>
4494
4495 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> is related, but not identical.  The
4496 proposed resolution if issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> says that
4497 ctype_base::mask must be a bitmask type. It does not say that the
4498 ctype_base::mask elements are bitmask elements, so it doesn't
4499 directly affect this issue.</p>
4500
4501 <p>More comments from Benjamin Kosnik, who believes that
4502 that C99 compatibility essentially requires what we're
4503 calling option 1 below.</p>
4504
4505 <blockquote>
4506 <pre>I think the C99 standard is clear, that isspace -&gt; !isalpha.
4507 --------
4508
4509 #include &lt;locale&gt;
4510 #include &lt;iostream&gt;
4511
4512 class my_ctype : public std::ctype&lt;char&gt;
4513 {
4514 private:
4515   typedef std::ctype&lt;char&gt; base;
4516   mask my_table[base::table_size];
4517
4518 public:
4519   my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
4520   {
4521     std::copy(base::classic_table(), base::classic_table() + base::table_size,
4522               my_table);
4523     mask both = base::print | base::space;
4524     my_table[static_cast&lt;mask&gt;('_')] = both;
4525   }
4526 };
4527
4528 int main()
4529 {
4530   using namespace std;
4531   my_ctype ct;
4532   cout &lt;&lt; "isspace: " &lt;&lt; ct.is(ctype_base::space, '_') &lt;&lt; endl;
4533   cout &lt;&lt; "isprint: " &lt;&lt; ct.is(ctype_base::print, '_') &lt;&lt; endl;
4534
4535   // ISO C99, isalpha iff upper | lower set, and !space.
4536   // 7.5, p 193
4537   // -&gt; looks like g++ behavior is correct.
4538   // 356 -&gt; bitmask elements are required for ctype_base
4539   // 339 -&gt; bitmask type required for mask
4540   cout &lt;&lt; "isalpha: " &lt;&lt; ct.is(ctype_base::alpha, '_') &lt;&lt; endl;
4541 }
4542 </pre>
4543 </blockquote>
4544
4545
4546
4547 <p><b>Proposed resolution:</b></p>
4548 <p>Informally, we have three choices:</p>
4549 <ol>
4550 <li>Require that the enumerators are disjoint (except for alnum and
4551 graph)</li>
4552 <li>Require that the enumerators are not disjoint, and specify which
4553 of them subsume which others.  (e.g. mandate that lower includes alpha
4554 and print)</li>
4555 <li>Explicitly leave this unspecified, which the result that the above
4556 program is not portable.</li>
4557 </ol>
4558
4559 <p>Either of the first two options is just as good from the standpoint
4560 of portability.  Either one will require some implementations to
4561 change.</p>
4562
4563
4564 <p><b>Rationale:</b></p>
4565 <p>The LWG agrees that this is a real ambiguity, and that both
4566 interpretations are conforming under the existing standard. However,
4567 there's no evidence that it's causing problems for real users. Users
4568 who want to define ctype facets portably can test the ctype_base masks
4569 to see which interpretation is being used.</p>
4570
4571
4572
4573
4574
4575 <hr>
4576 <h3><a name="357"></a>357. &lt;cmath&gt; float functions cannot return HUGE_VAL</h3>
4577 <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#NAD%20Editorial">NAD Editorial</a>
4578  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-02-26</p>
4579 <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>
4580 <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>
4581 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
4582 <p><b>Discussion:</b></p>
4583 <p>
4584 The float versions of the math functions have no meaningful value to return
4585 for a range error. The long double versions have a value they can return,
4586 but it isn't necessarily the most reasonable value.
4587 </p>
4588
4589 <p>
4590 Section 26.5 [lib.c.math], paragraph 5, says that C++ "adds float and long
4591 double overloaded versions of these functions, with the same semantics,"
4592 referring to the math functions from the C90 standard.
4593 </p>
4594
4595 <p>
4596 The C90 standard, in section 7.5.1, paragraph 3, says that functions return
4597 "the value of the macro HUGE_VAL" when they encounter a range error.
4598 Section 7.5, paragraph 2, defines HUGE_VAL as a macro that "expands to a
4599 positive double expression, not necessarily representable as a float."
4600 </p>
4601
4602 <p>
4603 Therefore, the float versions of the math functions have no way to
4604 signal a range error. <i>[Curaçao: The LWG notes that this isn't
4605 strictly correct, since errno is set.]</i> The semantics require that they
4606 return HUGE_VAL, but they cannot because HUGE_VAL might not be
4607 representable as a float.
4608 </p>
4609
4610 <p>
4611 The problem with long double functions is less severe because HUGE_VAL is
4612 representable as a long double. On the other hand, it might not be a "huge"
4613 long double value, and might fall well within the range of normal return
4614 values for a long double function. Therefore, it does not make sense for a
4615 long double function to return a double (HUGE_VAL) for a range error.
4616 </p>
4617
4618
4619 <p><b>Proposed resolution:</b></p>
4620 <p>Curaçao: C99 was faced with a similar problem, which they fixed by
4621 adding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.</p>
4622
4623 <p>C++ must also fix, but it should be done in the context of the
4624 general C99 based changes to C++, not via DR. Thus the LWG in Curaçao
4625 felt the resolution should be NAD, FUTURE, but the issue is being held
4626 open for one more meeting to ensure LWG members not present during the
4627 discussion concur.</p>
4628
4629
4630 <p><b>Rationale:</b></p>
4631 <p>Will be fixed as part of more general work in the TR.</p>
4632
4633
4634
4635
4636
4637 <hr>
4638 <h3><a name="361"></a>361. num_get&lt;&gt;::do_get (..., void*&amp;) checks grouping</h3>
4639 <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#NAD">NAD</a>
4640  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
4641 <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>
4642 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4643 <p><b>Discussion:</b></p>
4644 <p>
4645 22.2.2.2.2, p12 specifies that <tt>thousands_sep</tt> is to be inserted only
4646 for integral types (issue 282 suggests that this should be done for
4647 all arithmetic types).
4648 </p>
4649
4650 <p>
4651 22.2.2.1.2, p12 requires that grouping be checked for all extractors
4652 including that for <tt>void*</tt>.
4653 </p>
4654
4655 <p>
4656 I don't think that's right. <tt>void*</tt> values should not be checked for
4657 grouping, should they? (Although if they should, then <tt>num_put</tt> needs
4658 to write them out, otherwise their extraction will fail.)
4659 </p>
4660
4661
4662 <p><b>Proposed resolution:</b></p>
4663 <p>
4664 Change the first sentence of 22.2.2.2.2, p12 from
4665 </p>
4666 <blockquote><p>
4667     Digit grouping is checked. That is, the positions of discarded
4668     separators is examined for consistency with
4669     use_facet&lt;numpunct&lt;charT&gt; &gt;(loc).grouping().
4670     If they are not consistent then ios_base::failbit is assigned
4671     to err.
4672 </p></blockquote>
4673
4674 <p>to</p>
4675 <blockquote><p>
4676     Except for conversions to void*, digit grouping is checked...
4677 </p></blockquote>
4678
4679
4680
4681 <p><b>Rationale:</b></p>
4682 <p>This would be a change: as it stands, the standard clearly
4683   specifies that grouping applies to void*.  A survey of existing
4684   practice shows that most existing implementations do that, as they
4685   should.</p>
4686
4687
4688
4689
4690
4691 <hr>
4692 <h3><a name="366"></a>366. Excessive const-qualification</h3>
4693 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4694  <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 2002-05-10</p>
4695 <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>
4696 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4697 <p><b>Discussion:</b></p>
4698 <p>
4699 The following member functions are declared const, yet return non-const
4700 pointers. We believe they are should be changed, because they allow code
4701 that may surprise the user. See document N1360 for details and
4702 rationale.
4703 </p>
4704
4705 <p><i>[Santa Cruz: the real issue is that we've got const member
4706 functions that return pointers to non-const, and N1360 proposes
4707 replacing them by overloaded pairs.  There isn't a consensus about
4708 whether this is a real issue, since we've never said what our
4709 constness policy is for iostreams.  N1360 relies on a distinction
4710 between physical constness and logical constness; that distinction, or
4711 those terms, does not appear in the standard.]</i></p>
4712
4713
4714
4715
4716 <p><b>Proposed resolution:</b></p>
4717 <p>In 27.4.4 and 27.4.4.2</p>
4718 <p>Replace</p>
4719 <pre>  basic_ostream&lt;charT,traits&gt;* tie() const;
4720 </pre>
4721 <p>with</p>
4722 <pre>  basic_ostream&lt;charT,traits&gt;* tie();
4723   const basic_ostream&lt;charT,traits&gt;* tie() const;
4724 </pre>
4725
4726 <p>and replace</p>
4727 <pre>  basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
4728 </pre>
4729 <p>with</p>
4730 <pre>  basic_streambuf&lt;charT,traits&gt;* rdbuf();
4731   const basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
4732 </pre>
4733
4734 <p>In 27.5.2 and 27.5.2.3.1</p>
4735 <p>Replace</p>
4736 <pre>  char_type* eback() const;
4737 </pre>
4738 <p>with</p>
4739 <pre>  char_type* eback();
4740   const char_type* eback() const;
4741 </pre>
4742
4743 <p>Replace</p>
4744 <pre>  char_type gptr() const;
4745 </pre>
4746 <p>with</p>
4747 <pre>  char_type* gptr();
4748   const char_type* gptr() const;
4749 </pre>
4750
4751 <p>Replace</p>
4752 <pre>  char_type* egptr() const;
4753 </pre>
4754 <p>with</p>
4755 <pre>  char_type* egptr();
4756   const char_type* egptr() const;
4757 </pre>
4758
4759 <p>In 27.5.2 and 27.5.2.3.2</p>
4760 <p>Replace</p>
4761 <pre>  char_type* pbase() const;
4762 </pre>
4763 <p>with</p>
4764 <pre>  char_type* pbase();
4765   const char_type* pbase() const;
4766 </pre>
4767
4768 <p>Replace</p>
4769 <pre>  char_type* pptr() const;
4770 </pre>
4771 <p>with</p>
4772 <pre>  char_type* pptr();
4773   const char_type* pptr() const;
4774 </pre>
4775
4776 <p>Replace</p>
4777 <pre>  char_type* epptr() const;
4778 </pre>
4779 <p>with</p>
4780 <pre>  char_type* epptr();
4781   const char_type* epptr() const;
4782 </pre>
4783
4784 <p>In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6</p>
4785 <p>Replace</p>
4786 <pre>  basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
4787 </pre>
4788 <p>with</p>
4789 <pre>  basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf();
4790   const basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
4791 </pre>
4792
4793 <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>
4794 <p>Replace</p>
4795 <pre>  basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
4796 </pre>
4797 <p>with</p>
4798 <pre>  basic_filebuf&lt;charT,traits&gt;* rdbuf();
4799   const basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
4800 </pre>
4801
4802
4803 <p><b>Rationale:</b></p>
4804 <p>The existing specification is a bit sloppy, but there's no
4805   particular reason to change this other than tidiness, and there are
4806   a number of ways in which streams might have been designed
4807   differently if we were starting today.  There's no evidence that the
4808   existing constness policy is harming users.  We might consider
4809   a different constness policy as part of a full stream redesign.</p>
4810
4811
4812
4813
4814
4815 <hr>
4816 <h3><a name="367"></a>367. remove_copy/remove_copy_if and Input Iterators</h3>
4817 <p><b>Section:</b> 25.2.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4818  <b>Submitter:</b> Anthony Williams <b>Date:</b> 2002-05-13</p>
4819 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</p>
4820 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4821 <p><b>Discussion:</b></p>
4822 <p>
4823 remove_copy and remove_copy_if (25.2.8 [alg.remove]) permit their
4824 input range to be marked with Input Iterators. However, since two
4825 operations are required against the elements to copy (comparison and
4826 assigment), when the input range uses Input Iterators, a temporary
4827 copy must be taken to avoid dereferencing the iterator twice. This
4828 therefore requires the value type of the InputIterator to be
4829 CopyConstructible. If the iterators are at least Forward Iterators,
4830 then the iterator can be dereferenced twice, or a reference to the
4831 result maintained, so the temporary is not required.
4832 </p>
4833
4834
4835 <p><b>Proposed resolution:</b></p>
4836 <p>
4837 Add "If InputIterator does not meet the requirements of forward
4838 iterator, then the value type of InputIterator must be copy
4839 constructible. Otherwise copy constructible is not required." to
4840 25.2.8 [alg.remove] paragraph 6.
4841 </p>
4842
4843
4844 <p><b>Rationale:</b></p>
4845 <p>The assumption is that an input iterator can't be dereferenced
4846   twice.  There's no basis for that assumption in the Standard.</p>
4847
4848
4849
4850
4851
4852 <hr>
4853 <h3><a name="368"></a>368. basic_string::replace has two "Throws" paragraphs</h3>
4854 <p><b>Section:</b> 21.3.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
4855  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2002-06-03</p>
4856 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
4857 <p><b>Discussion:</b></p>
4858 <p>
4859 21.3.6.6 [string::replace] basic_string::replace, second
4860 signature, given in paragraph 1, has two "Throws" paragraphs (3 and
4861 5).
4862 </p>
4863
4864 <p>
4865 In addition, the second "Throws" paragraph (5) includes specification
4866 (beginning with "Otherwise, the function replaces ...") that should be
4867 part of the "Effects" paragraph.
4868 </p>
4869
4870
4871 <p><b>Proposed resolution:</b></p>
4872
4873
4874 <p><b>Rationale:</b></p>
4875 <p>This is editorial. Both "throws" statements are true. The bug is
4876   just that the second one should be a sentence, part of the "Effects"
4877   clause, not a separate "Throws".  The project editor has been
4878   notified.</p>
4879
4880
4881
4882
4883
4884 <hr>
4885 <h3><a name="372"></a>372. Inconsistent description of stdlib exceptions</h3>
4886 <p><b>Section:</b> 17.4.4.8 [res.on.exception.handling], 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4887  <b>Submitter:</b> Randy Maddox <b>Date:</b> 2002-07-22</p>
4888 <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>
4889 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4890 <p><b>Discussion:</b></p>
4891
4892 <p>Paragraph 3 under clause 17.4.4.8 [res.on.exception.handling], Restrictions on
4893 Exception Handling, states that "Any other functions defined in the
4894 C++ Standard Library that do not have an exception-specification may
4895 throw implementation-defined exceptions unless otherwise specified."
4896 This statement is followed by a reference to footnote 178 at the
4897 bottom of that page which states, apparently in reference to the C++
4898 Standard Library, that "Library implementations are encouraged (but
4899 not required) to report errors by throwing exceptions from (or derived
4900 from) the standard exceptions."</p>
4901
4902 <p>These statements appear to be in direct contradiction to clause
4903 18.6.1 [type.info], which states "The class exception defines the
4904 base class for the types of objects thrown as exceptions by the C++
4905 Standard library components ...".</p>
4906
4907 <p>Is this inconsistent?</p>
4908
4909
4910
4911 <p><b>Proposed resolution:</b></p>
4912
4913
4914 <p><b>Rationale:</b></p>
4915 <p>Clause 17 is setting the overall library requirements, and it's
4916   clear and consistent.  This sentence from Clause 18 is descriptive,
4917   not setting a requirement on any other class.
4918 </p>
4919
4920
4921
4922
4923
4924 <hr>
4925 <h3><a name="374"></a>374. moneypunct::frac_digits returns int not unsigned</h3>
4926 <p><b>Section:</b> 22.2.6.3.1 [locale.moneypunct.members], 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#NAD">NAD</a>
4927  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-08</p>
4928 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4929 <p><b>Discussion:</b></p>
4930 <p>
4931 In section 22.2.6.3.1 [locale.moneypunct.members], frac_digits() returns type
4932 "int". This implies that frac_digits() might return a negative value,
4933 but a negative value is nonsensical. It should return "unsigned".
4934 </p>
4935
4936 <p>
4937 Similarly, in section 22.2.6.3.2 [locale.moneypunct.virtuals], do_frac_digits()
4938 should return "unsigned".
4939 </p>
4940
4941
4942
4943 <p><b>Proposed resolution:</b></p>
4944
4945
4946 <p><b>Rationale:</b></p>
4947 <p>Regardless of whether the return value is int or unsigned, it's
4948 always conceivable that frac_digits might return a nonsensical
4949 value. (Is 4294967295 really any better than -1?)  The clients of
4950 moneypunct, the get and put facets, can and do perform range
4951 checks.</p>
4952
4953
4954
4955
4956
4957 <hr>
4958 <h3><a name="377"></a>377. basic_string::insert and length_error</h3>
4959 <p><b>Section:</b> 21.3.6.4 [string::insert] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4960  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-16</p>
4961 <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>
4962 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4963 <p><b>Discussion:</b></p>
4964 <p>
4965 Section 21.3.6.4 [string::insert], paragraph 4, contains the following,
4966 "Then throws length_error if size() &gt;= npos - rlen."
4967 </p>
4968
4969 <p>
4970 Related to DR 83, this sentence should probably be removed.
4971 </p>
4972
4973
4974 <p><b>Proposed resolution:</b></p>
4975
4976
4977 <p><b>Rationale:</b></p><p>This requirement is redundant but correct.  No change is
4978 needed.</p>
4979
4980
4981
4982
4983 <hr>
4984 <h3><a name="378"></a>378. locale immutability and locale::operator=()</h3>
4985 <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#Dup">Dup</a>
4986  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p>
4987 <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>
4988 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
4989 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a></p>
4990 <p><b>Discussion:</b></p>
4991 <p>
4992 I think there is a problem with 22.1.1, p6 which says that
4993 </p>
4994 <pre>    -6- An instance of locale is immutable; once a facet reference
4995         is obtained from it, that reference remains usable as long
4996         as the locale value itself exists.
4997 </pre>
4998 <p>
4999 and 22.1.1.2, p4:
5000 </p>
5001 <pre>    const locale&amp; operator=(const locale&amp; other) throw();
5002
5003     -4- Effects: Creates a copy of other, replacing the current value.
5004 </pre>
5005 <p>
5006 How can a reference to a facet obtained from a locale object remain
5007 valid after an assignment that clearly must replace all the facets
5008 in the locale object? Imagine a program such as this
5009 </p>
5010 <pre>    std::locale loc ("de_DE");
5011     const std::ctype&lt;char&gt; &amp;r0 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
5012     loc = std::locale ("en_US");
5013     const std::ctype&lt;char&gt; &amp;r1 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
5014 </pre>
5015 <p>
5016 Is r0 really supposed to be preserved and destroyed only when loc goes
5017 out of scope?
5018 </p>
5019
5020
5021 <p><b>Proposed resolution:</b></p>
5022 <p><i>[Summer '04 mid-meeting mailing: Martin and Dietmar believe this
5023   is a duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a> and recommend that it be
5024   closed.
5025 ]</i></p>
5026
5027
5028
5029
5030
5031
5032 <hr>
5033 <h3><a name="385"></a>385. Does call by value imply the CopyConstructible requirement?</h3>
5034 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5035  <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-10-23</p>
5036 <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>
5037 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5038 <p><b>Discussion:</b></p>
5039 <p>
5040 Many function templates have parameters that are passed by value;
5041 a typical example is <tt>find_if</tt>'s <i>pred</i> parameter in
5042 25.1.2 [alg.find].  Are the corresponding template parameters
5043 (<tt>Predicate</tt> in this case) implicitly required to be
5044 CopyConstructible, or does that need to be spelled out explicitly?
5045 </p>
5046
5047 <p>
5048 This isn't quite as silly a question as it might seem to be at first
5049 sight.  If you call <tt>find_if</tt> in such a way that template
5050 argument deduction applies, then of course you'll get call by value
5051 and you need to provide a copy constructor.  If you explicitly provide
5052 the template arguments, however, you can force call by reference by
5053 writing something like <tt>find_if&lt;my_iterator,
5054 my_predicate&amp;&gt;</tt>.  The question is whether implementation
5055 are required to accept this, or whether this is ill-formed because
5056 my_predicate&amp; is not CopyConstructible.
5057 </p>
5058
5059 <p>
5060 The scope of this problem, if it is a problem, is unknown.  Function
5061 object arguments to generic algorithms in clauses 25 [algorithms]
5062 and 26 [numerics] are obvious examples.  A review of the whole
5063 library is necessary.
5064 </p>
5065 <p><i>[
5066 This is really two issues.  First, predicates are typically passed by
5067 value but we don't say they must be Copy Constructible.  They should
5068 be. Second: is specialization allowed to transform value arguments
5069 into references? References aren't copy constructible, so this should
5070 not be allowed.
5071 ]</i></p>
5072
5073 <p><i>[
5074 2007-01-12, Howard: First, despite the note above, references <b>are</b>
5075 copy constructible. They just aren't assignable.  Second, this is very
5076 closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a> and should be consistent with that.
5077 That issue already says that implementations are allowed to copy
5078 function objects.  If one passes in a reference, it is copyable, but
5079 susceptible to slicing if one passes in a reference to a base.  Third,
5080 with rvalue reference in the language one only needs to satisfy
5081 MoveConstructible to pass an rvalue "by value".  Though the function
5082 might still copy the function object internally (requiring
5083 CopyConstructible). Finally (and fwiw), if we wanted to, it is easy to
5084 code all of the std::algorithms such that they do not copy function
5085 objects internally.  One merely passes them by reference internally if
5086 desired (this has been fully implemented and shipped for several years).
5087  If this were mandated, it would reverse <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, allowing
5088 function objects to reliably maintain state.  E.g. the example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a> would reliably remove only the third element.
5089 ]</i></p>
5090
5091
5092
5093 <p><b>Proposed resolution:</b></p>
5094 <p>
5095 Recommend NAD.
5096 </p>
5097
5098
5099 <p><b>Rationale:</b></p>
5100 <p>
5101 Generic algorithms will be marked with concepts and these will imply a requirement
5102 of MoveConstructible (not CopyConstructible).  The signature of the function will
5103 then precisely describe and enforce the precise requirements.
5104 </p>
5105
5106
5107
5108
5109
5110 <hr>
5111 <h3><a name="388"></a>388. Use of complex as a key in associative containers</h3>
5112 <p><b>Section:</b> 26.3 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
5113  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
5114 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p>
5115 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
5116 <p><b>Discussion:</b></p>
5117 <p>
5118 Practice with std::complex&lt;&gt; and the associative containers
5119 occasionally reveals artificial and distracting issues with constructs
5120 resembling: std::set&lt;std::complex&lt;double&gt; &gt; s;
5121 </p>
5122
5123 <p>
5124 The main reason for the above to fail is the absence of an approriate
5125 definition for std::less&lt;std::complex&lt;T&gt; &gt;. That in turn comes from
5126 the definition of the primary template std::less&lt;&gt; in terms of
5127 operator&lt;.
5128 </p>
5129
5130 <p>
5131 The usual argument goes as follows: Since there is no ordering over
5132 the complex field compatible with field operations it makes little
5133 sense to define a function operator&lt; operating on the datatype
5134 std::complex&lt;T&gt;.  That is fine. However, that reasoning does not carry
5135 over to std::less&lt;T&gt; which is used, among other things, by associative
5136 containers as an ordering useful to meet complexity requirements.
5137 </p>
5138
5139 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</p>
5140
5141
5142
5143 <p><b>Proposed resolution:</b></p>
5144 <p>Informally: Add a specialization of std::less for std::complex.</p>
5145
5146
5147 <p><b>Rationale:</b></p>
5148 <p>Discussed in Santa Cruz.  An overwhelming majority of the LWG
5149 believes this should not be treated a DR: it's a request for a design
5150 change, not a defect in the existing standard.  Most people (10-3)
5151 believed that we probably don't want this change, period: as with
5152 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, it's hard to know where to draw the line.
5153 The LWG noted that users who want to put objects into an associative
5154 container for which <tt>operator&lt;</tt> isn't defined can simply
5155 provide their own comparison function object.</p>
5156
5157
5158
5159
5160
5161 <hr>
5162 <h3><a name="390"></a>390. CopyConstructible requirements too strict</h3>
5163 <p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
5164  <b>Submitter:</b> Doug Gregor <b>Date:</b> 2002-10-24</p>
5165 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
5166 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
5167 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
5168 <p><b>Discussion:</b></p>
5169 <p>
5170 The CopyConstructible requirements in Table 30 state that for an
5171 object t of type T (where T is CopyConstructible), the expression &amp;t
5172 returns the address of t (with type T*). This requirement is overly
5173 strict, in that it disallows types that overload operator&amp; to not
5174 return a value of type T*. This occurs, for instance, in the <a href="http://www.boost.org/libs/lambda">Boost.Lambda</a> library, where
5175 operator&amp; is overloaded for a Boost.Lambda function object to return
5176 another function object.
5177 </p>
5178
5179 <p>Example:</p>
5180
5181 <pre>  std::vector&lt;int&gt; u, v;
5182   int x;
5183   // ...
5184   std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x);
5185 </pre>
5186
5187 <p>
5188 _1 * x returns an unnamed function object with operator&amp; overloaded to
5189 not return T* , therefore rendering the std::transform call ill-formed.
5190 However, most standard library implementations will compile this code
5191 properly, and the viability of such binder libraries is severely hindered
5192 by the unnecessary restriction in the CopyConstructible requirements.
5193 </p>
5194
5195 <p>
5196 For reference, the address of an object can be retrieved without using
5197 the address-of operator with the following function template:
5198 </p>
5199
5200 <pre>  template &lt;typename T&gt; T* addressof(T&amp; v)
5201   {
5202     return reinterpret_cast&lt;T*&gt;(
5203          &amp;const_cast&lt;char&amp;&gt;(reinterpret_cast&lt;const volatile char &amp;&gt;(v)));
5204   }
5205 </pre>
5206
5207 <p>
5208 Note: this relates directly to library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, which
5209 will need to be reexamined if the CopyConstructible requirements
5210 change.
5211 </p>
5212
5213
5214 <p><b>Proposed resolution:</b></p>
5215 <p>
5216 Remove the last two rows of Table 30, eliminating the requirements
5217 that &amp;t and &amp;u return the address of t and u, respectively.
5218 </p>
5219
5220
5221 <p><b>Rationale:</b></p>
5222 <p>This was a deliberate design decision.  Perhaps it should be
5223    reconsidered for C++0x. </p>
5224
5225
5226
5227
5228
5229 <hr>
5230 <h3><a name="392"></a>392. 'equivalence' for input iterators</h3>
5231 <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#NAD">NAD</a>
5232  <b>Submitter:</b> Corwin Joy <b>Date:</b> 2002-12-11</p>
5233 <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>
5234 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5235 <p><b>Discussion:</b></p>
5236
5237 <p>
5238 In section 24.1.1 [input.iterators] table 72 -
5239 'Input Iterator Requirements' we have as a postcondition of *a:
5240 "If a==b and (a, b) is in the domain of == then *a is equivalent to *b".
5241 </p>
5242
5243 <p>
5244 In section 24.5.3.5 [istreambuf.iterator::equal] it states that
5245 "istreambuf_iterator::equal returns true if and only if both iterators
5246 are at end-of-stream, or neither is at end-of-stream, <i>regardless of
5247 what streambuf object they use</i>."  (My emphasis).
5248 </p>
5249
5250 <p>
5251 The defect is that either 'equivalent' needs to be more precisely
5252 defined or the conditions for equality in 24.5.3.5 [istreambuf.iterator::equal]
5253 are incorrect. (Or both).
5254 </p>
5255
5256 <p>Consider the following example:</p>
5257 <pre>   #include &lt;iostream&gt;
5258    #include &lt;fstream&gt;
5259    #include &lt;iterator&gt;
5260    using namespace std;
5261
5262    int main() {
5263     ifstream file1("file1.txt"), file2("file2.txt");
5264     istreambuf_iterator&lt;char&gt; f1(file1), f2(file2);
5265     cout &lt;&lt; "f1 == f2 : " &lt;&lt; boolalpha &lt;&lt; (f1 == f2) &lt;&lt; endl;
5266     cout &lt;&lt; "f1 = " &lt;&lt; *f1 &lt;&lt; endl;
5267     cout &lt;&lt; "f2 = " &lt;&lt; *f2 &lt;&lt; endl;
5268     return 0;
5269    }
5270 </pre>
5271
5272 <p>Now assuming that neither f1 or f2 are at the end-of-stream then
5273 f1 == f2 by 24.5.3.5 [istreambuf.iterator::equal].</p>
5274
5275 <p>However, it is unlikely that *f1 will give the same value as *f2 except
5276 by accident.</p>
5277
5278 <p>So what does *f1 'equivalent' to *f2 mean?  I think the standard should
5279 be clearer on this point, or at least be explicit that this does not
5280 mean that *f1 and *f2 are required to have the same value in the case
5281 of input iterators.</p>
5282
5283
5284 <p><b>Proposed resolution:</b></p>
5285
5286
5287 <p><b>Rationale:</b></p><p>The two iterators aer not in the domain of ==</p>
5288
5289
5290
5291
5292
5293
5294 <hr>
5295 <h3><a name="393"></a>393. do_in/do_out operation on state unclear</h3>
5296 <p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
5297  <b>Submitter:</b> Alberto Barbati <b>Date:</b> 2002-12-24</p>
5298 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt.virtuals">active issues</a> in [locale.codecvt.virtuals].</p>
5299 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
5300 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
5301 <p><b>Discussion:</b></p>
5302 <p>
5303 this DR follows the discussion on the previous thread "codecvt::do_in
5304 not consuming external characters". It's just a clarification issue
5305 and not a request for a change.
5306 </p>
5307 <p>
5308 Can do_in()/do_out() produce output characters without consuming input
5309 characters as a result of operation on state?
5310 </p>
5311
5312
5313 <p><b>Proposed resolution:</b></p>
5314 <p>
5315 Add a note at the end of 22.2.1.4.2 [locale.codecvt.virtuals],
5316 paragraph 3:
5317 </p>
5318
5319 <p>
5320 [Note: As a result of operations on state, it can return ok or partial
5321 and set from_next == from and to_next != to. --end note]
5322 </p>
5323
5324
5325 <p><b>Rationale:</b></p>
5326 <p>
5327 The submitter believes that standard already provides an affirmative
5328 answer to the question. However, the current wording has induced a few
5329 library implementors to make the incorrect assumption that
5330 do_in()/do_out() always consume at least one internal character when
5331 they succeed.
5332 </p>
5333
5334 <p>
5335 The submitter also believes that the proposed resolution is not in
5336 conflict with the related issue 76. Moreover, by explicitly allowing
5337 operations on state to produce characters, a codecvt implementation
5338 may effectively implement N-to-M translations without violating the
5339 "one character at a time" principle described in such issue. On a side
5340 note, the footnote in the proposed resolution of issue 76 that
5341 informally rules out N-to-M translations for basic_filebuf should be
5342 removed if this issue is accepted as valid.
5343 </p>
5344
5345
5346 <p><i>[
5347 Kona (2007): The proposed resolution is to add a note. Since this is
5348 non-normative, the issue is editorial, but we believe that the note is
5349 correct. Proposed Disposition: NAD, Editorial
5350 ]</i></p>
5351
5352
5353
5354
5355
5356
5357 <hr>
5358 <h3><a name="399"></a>399. volations of unformatted input function requirements</h3>
5359 <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#NAD">NAD</a>
5360  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
5361 <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>
5362 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5363 <p><b>Discussion:</b></p>
5364     <p>
5365 The Effects clauses for the two functions below violate the
5366 general requirements on unformatted input functions outlined
5367 in 27.6.1.3: they do not begin by constructing a sentry object.
5368 Instead, they begin by calling widen ('\n'), which may throw
5369 an exception. The exception is then allowed to propagate from
5370 the unformatted input function irrespective of the setting of
5371 exceptions().
5372     </p>
5373     <p>
5374 Note that in light of 27.6.1.1, p3 and p4, the fact that the
5375 functions allow exceptions thrown from widen() to propagate
5376 may not strictly speaking be a defect (but the fact that the
5377 functions do not start by constructing a sentry object still
5378 is). However, since an exception thrown from ctype&lt;charT&gt;
5379 ::widen() during any other input operation (say, from within
5380 a call to num_get&lt;charT&gt;::get()) will be caught and cause
5381 badbit to be set, these two functions should not be treated
5382 differently for the sake of consistency.
5383     </p>
5384
5385
5386 <p><b>Proposed resolution:</b></p>
5387
5388
5389 <p><b>Rationale:</b></p>
5390 <p>
5391 Not a defect.  The standard is consistent, and the behavior required
5392 by the standard is unambiguous.  Yes, it's theoretically possible for
5393 widen to throw.  (Not that this will happen for the default ctype
5394 facet or for most real-world replacement ctype facets.)  Users who
5395 define ctype facets that can throw, and who care about this behavior,
5396 can use alternative signatures that don't call widen.
5397 </p>
5398
5399
5400
5401
5402
5403
5404 <hr>
5405 <h3><a name="429"></a>429. typo in basic_ios::clear(iostate)</h3>
5406 <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#Dup">Dup</a>
5407  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
5408 <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>
5409 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
5410 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a></p>
5411 <p><b>Discussion:</b></p>
5412         <p>
5413
5414 The Effects clause in 27.4.4.3, p5 describing the effects of a call to
5415 the ios_base member function clear(iostate state) says that the function
5416 only throws if the respective bits are already set prior to the function
5417 call. That's obviously not the intent. If it was, a call to clear(badbit)
5418 on an object for which (rdstate() == goodbit &amp;&amp; exceptions() == badbit)
5419 holds would not result in an exception being thrown.
5420
5421         </p>
5422
5423     <p><b>Proposed resolution:</b></p>
5424         <p>
5425
5426 The text ought to be changed from
5427 <br>
5428
5429 "If (rdstate() &amp; exceptions()) == 0, returns. ..."
5430 <br>
5431
5432 to
5433 <br>
5434
5435 "If (state &amp; exceptions()) == 0, returns. ..."
5436         </p>
5437
5438
5439 <p><b>Rationale:</b></p>
5440
5441
5442
5443
5444
5445
5446 <hr>
5447 <h3><a name="433"></a>433. Contradiction in specification of unexpected()</h3>
5448 <p><b>Section:</b> 18.7.2.4 [unexpected] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5449  <b>Submitter:</b> Vyatcheslav Sysoltsev <b>Date:</b> 2003-09-29</p>
5450 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5451 <p><b>Discussion:</b></p>
5452 <p>
5453 Clause 15.5.2 [except.unexpected] paragraph 1 says that "void unexpected();
5454 is called (18.7.2) immediately after completing the stack unwinding
5455 for the former function", but 18.7.2.4 (Effects) says that "void
5456 unexpected(); . . . Calls the unexpected_handler function in effect
5457 immediately after evaluating the throwexpression (18.7.2.2),".  Isn't
5458 here a contradiction: 15.5.2 requires stack have been unwound when in
5459 void unexpected() and therefore in unexpected_handler but 18.7.2.4
5460 claims that unexpected_handler is called "in effect immediately" after
5461 evaluation of throw expression is finished, so there is no space left
5462 for stack to be unwound therefore?  I think the phrase "in effect
5463 immediately" should be removed from the standard because it brings
5464 ambiguity in understanding.
5465 </p>
5466
5467
5468 <p><b>Proposed resolution:</b></p>
5469
5470
5471 <p><b>Rationale:</b></p>
5472 <p>There is no contradiction.  The phrase "in effect immediately" is
5473   just to clarify which handler is to be called.</p>
5474
5475
5476
5477
5478
5479 <hr>
5480 <h3><a name="437"></a>437. Formatted output of function pointers is confusing</h3>
5481 <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#NAD">NAD</a>
5482  <b>Submitter:</b> Ivan Godard <b>Date:</b> 2003-10-24</p>
5483 <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>
5484 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5485 <p><b>Discussion:</b></p>
5486 <p>
5487 Given:
5488 </p>
5489 <pre>void f(int) {}
5490 void(*g)(int) = f;
5491 cout &lt;&lt; g;
5492 </pre>
5493
5494 <p>
5495 (with the expected #include and usings), the value printed is a rather
5496 surprising "true". Rather useless too.
5497 </p>
5498
5499 <p>The standard defines:</p>
5500
5501 <pre>ostream&amp; operator&lt;&lt;(ostream&amp;, void*);</pre>
5502
5503 <p>which picks up all data pointers and prints their hex value, but does
5504 not pick up function pointers because there is no default conversion
5505 from function pointer to void*. Absent that, we fall back to legacy
5506 conversions from C and the function pointer is converted to bool.
5507 </p>
5508
5509 <p>There should be an analogous inserter that prints the address of a
5510   function pointer.</p>
5511
5512
5513 <p><b>Proposed resolution:</b></p>
5514
5515
5516 <p><b>Rationale:</b></p>
5517 <p>This is indeed a wart, but there is no good way to solve it.  C
5518   doesn't provide a portable way of outputting the address of a
5519   function point either.</p>
5520
5521
5522
5523
5524
5525 <hr>
5526 <h3><a name="439"></a>439. Should facets be copyable?</h3>
5527 <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#NAD">NAD</a>
5528  <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-11-02</p>
5529 <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>
5530 <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>
5531 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5532 <p><b>Discussion:</b></p>
5533 <p>The following facets classes have no copy constructors described in
5534   the standard, which, according to the standard, means that they are
5535   supposed to use the compiler-generated defaults.  Default copy
5536   behavior is probably inappropriate.  We should either make these
5537   classes uncopyable or else specify exactly what their constructors do.</p>
5538
5539 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#421">421</a>.</p>
5540
5541 <pre>        ctype_base
5542         ctype
5543         ctype_byname
5544         ctype&lt;char&gt;
5545         ctype_byname&lt;char&gt;
5546         codecvt_base
5547         codecvt
5548         codecvt_byname
5549         num_get
5550         num_put
5551         numpunct
5552         numpunct_byname
5553         collate
5554         collate_byname
5555         time_base
5556         time_get
5557         time_get_byname
5558         time_put
5559         time_put_byname
5560         money_get
5561         money_put
5562         money_base
5563         moneypunct
5564         moneypunct_byname
5565         messages_base
5566         messages
5567         messages_byname
5568 </pre>
5569
5570
5571
5572 <p><b>Proposed resolution:</b></p>
5573
5574
5575 <p><b>Rationale:</b></p>
5576 <p>The copy constructor in the base class is private.</p>
5577
5578
5579
5580
5581
5582 <hr>
5583 <h3><a name="440"></a>440. Should std::complex use unqualified transcendentals?</h3>
5584 <p><b>Section:</b> 26.3.8 [complex.transcendentals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5585  <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-11-05</p>
5586 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5587 <p><b>Discussion:</b></p>
5588 <p>
5589 Operations like <tt>pow</tt> and <tt>exp</tt> on
5590 <tt>complex&lt;T&gt;</tt> are typically implemented in terms of
5591 operations like <tt>sin</tt> and <tt>cos</tt> on <tt>T</tt>.
5592 Should implementations write this as <tt>std::sin</tt>, or as plain
5593 unqualified <tt>sin</tt>?
5594 </p>
5595
5596 <p>The issue, of course, is whether we want to use
5597 argument-dependent lookup in the case where <tt>T</tt> is a
5598 user-defined type.  This is similar to the issue of valarray
5599 transcendentals, as discussed in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>.</p>
5600
5601 <p>This issue differs from valarray transcendentals in two important
5602 ways.  First, "the effect of instantiating the template
5603 <tt>complex</tt> for types other than float, double or long double is
5604 unspecified." (26.3.1 [complex.synopsis]) Second, the standard does not
5605 dictate implementation, so there is no guarantee that a particular
5606 real math function is used in the implementation of a particular
5607 complex function.</p>
5608
5609
5610
5611 <p><b>Proposed resolution:</b></p>
5612
5613
5614 <p><b>Rationale:</b></p>
5615 <p>If you instantiate std::complex for user-defined types, all bets
5616 are off.</p>
5617
5618
5619
5620
5621
5622 <hr>
5623 <h3><a name="447"></a>447. Wrong template argument for time facets</h3>
5624 <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#Dup">Dup</a>
5625  <b>Submitter:</b> Pete Becker <b>Date:</b> 2003-12-26</p>
5626 <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>
5627 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
5628 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a></p>
5629 <p><b>Discussion:</b></p>
5630 <p>
5631 22.1.1.1.1/4, table 52, "Required Instantiations", lists, among others:
5632 </p>
5633 <pre>    time_get&lt;char,InputIterator&gt;
5634     time_get_byname&lt;char,InputIterator&gt;
5635     time_get&lt;wchar_t,OutputIterator&gt;
5636     time_get_byname&lt;wchar_t,OutputIterator&gt;
5637 </pre>
5638
5639 <p>
5640 The second argument to the last two should be InputIterator, not
5641 OutputIterator.
5642 </p>
5643
5644
5645 <p><b>Proposed resolution:</b></p>
5646 <p>
5647 Change the second template argument to InputIterator.
5648 </p>
5649
5650
5651 <p><b>Rationale:</b></p>
5652
5653
5654
5655
5656
5657
5658 <hr>
5659 <h3><a name="450"></a>450. set::find is inconsistent with associative container requirements</h3>
5660 <p><b>Section:</b> 23.3.3 [set] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
5661  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
5662 <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>
5663 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
5664 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a></p>
5665 <p><b>Discussion:</b></p>
5666 <p>map/multimap have:</p>
5667
5668 <pre>   iterator find(const key_type&amp; x) const;
5669         const_iterator find(const key_type&amp; x) const;
5670 </pre>
5671
5672 <p>
5673 which is consistent with the table of associative container requirements.
5674 But set/multiset have:
5675 </p>
5676 <pre>   iterator find(const key_type&amp;) const;
5677 </pre>
5678
5679 <p>
5680 set/multiset should look like map/multimap, and honor the requirements
5681 table, in this regard.
5682 </p>
5683
5684
5685 <p><b>Proposed resolution:</b></p>
5686
5687
5688 <p><b>Rationale:</b></p>
5689
5690
5691
5692
5693
5694
5695 <hr>
5696 <h3><a name="451"></a>451. Associative erase should return an iterator</h3>
5697 <p><b>Section:</b> 23.1.2 [associative.reqmts], 23.3 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
5698  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
5699 <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>
5700 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
5701 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a></p>
5702 <p><b>Discussion:</b></p>
5703 <p>map/multimap/set/multiset have:</p>
5704 <pre>   void erase(iterator);
5705         void erase(iterator, iterator);
5706 </pre>
5707
5708 <p>But there's no good reason why these can't return an iterator, as for
5709 vector/deque/list:</p>
5710 <pre>   iterator erase(iterator);
5711         iterator erase(iterator, iterator);
5712 </pre>
5713
5714
5715
5716 <p><b>Proposed resolution:</b></p>
5717 <p>
5718 Informally: The table of associative container requirements, and the
5719 relevant template classes, should return an iterator designating the
5720 first element beyond the erased subrange.
5721 </p>
5722
5723
5724 <p><b>Rationale:</b></p>
5725
5726
5727
5728
5729
5730
5731 <hr>
5732 <h3><a name="452"></a>452.  locale::combine should be permitted to generate a named locale</h3>
5733 <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#NAD">NAD</a>
5734  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
5735 <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>
5736 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5737 <p><b>Discussion:</b></p>
5738 <pre>template&lt;class Facet&gt;
5739         locale::combine(const locale&amp;) const;
5740 </pre>
5741 <p>
5742 is obliged to create a locale that has no name. This is overspecification
5743 and overkill. The resulting locale should follow the usual rules -- it
5744 has a name if the locale argument has a name and Facet is one of the
5745 standard facets.
5746 </p>
5747
5748 <p><i>[
5749  Sydney and post-Sydney (see c++std-lib-13439, c++std-lib-13440,
5750  c++std-lib-13443): agreed that it's overkill to say that the locale
5751  is obligated to be nameless.  However, we also can't require it to
5752  have a name.  At the moment, locale names are based on categories
5753  and not on individual facets.  If a locale contains two different
5754  facets of different names from the same category, then this would
5755  not fit into existing naming schemes.  We need to give
5756  implementations more freedom.  Bill will provide wording.
5757 ]</i></p>
5758
5759
5760
5761
5762 <p><b>Rationale:</b></p>
5763 <p>After further discussion the LWG decided to close this as NAD.
5764   The fundamental problem is that names right now are per-category,
5765   not per-facet.  The <tt>combine</tt> member function works at the
5766   wrong level of granularity.</p>
5767
5768
5769
5770
5771
5772 <hr>
5773 <h3><a name="463"></a>463. auto_ptr usability issues</h3>
5774 <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#NAD">NAD</a>
5775  <b>Submitter:</b> Rani Sharoni <b>Date:</b> 2003-12-07</p>
5776 <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>
5777 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5778 <p><b>Discussion:</b></p>
5779
5780 <p>
5781 TC1 CWG DR #84 effectively made the template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;()
5782 member of auto_ptr (20.4.5.3/4) obsolete.
5783 </p>
5784
5785 <p>
5786 The sole purpose of this obsolete conversion member is to enable copy
5787 initialization base from r-value derived (or any convertible types like
5788 cv-types) case:
5789 </p>
5790 <pre>#include &lt;memory&gt;
5791 using std::auto_ptr;
5792
5793 struct B {};
5794 struct D : B {};
5795
5796 auto_ptr&lt;D&gt; source();
5797 int sink(auto_ptr&lt;B&gt;);
5798 int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
5799 </pre>
5800
5801 <p>
5802 The excellent analysis of conversion operations that was given in the final
5803 auto_ptr proposal
5804 (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
5805 explicitly specifies this case analysis (case 4). DR #84 makes the analysis
5806 wrong and actually comes to forbid the loophole that was exploited by the
5807 auto_ptr designers.
5808 </p>
5809
5810 <p>
5811 I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
5812 ever allowed this case. This is probably because it requires 3 user defined
5813 conversions and in fact current compilers conform to DR #84.
5814 </p>
5815
5816 <p>
5817 I was surprised to discover that the obsolete conversion member actually has
5818 negative impact of the copy initialization base from l-value derived
5819 case:</p>
5820 <pre>auto_ptr&lt;D&gt; dp;
5821 int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
5822 </pre>
5823
5824 <p>
5825 I'm sure that the original intention was allowing this initialization using
5826 the template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;&amp; a) constructor (20.4.5.1/4) but
5827 since in this copy initialization it's merely user defined conversion (UDC)
5828 and the obsolete conversion member is UDC with the same rank (for the early
5829 overloading stage) there is an ambiguity between them.
5830 </p>
5831
5832 <p>
5833 Removing the obsolete member will have impact on code that explicitly
5834 invokes it:
5835 </p>
5836 <pre>int y = sink(source().operator auto_ptr&lt;B&gt;());
5837 </pre>
5838
5839 <p>
5840 IMHO no one ever wrote such awkward code and the reasonable workaround for
5841 #1 is:
5842 </p>
5843 <pre>int y = sink( auto_ptr&lt;B&gt;(source()) );
5844 </pre>
5845
5846 <p>
5847 I was even more surprised to find out that after removing the obsolete
5848 conversion member the initialization was still ill-formed:
5849 int x3 = sink(dp); // #3 EDG - no suitable copy constructor
5850 </p>
5851
5852 <p>
5853 This copy initialization semantically requires copy constructor which means
5854 that both template conversion constructor and the auto_ptr_ref conversion
5855 member (20.4.5.3/3) are required which is what was explicitly forbidden in
5856 DR #84. This is a bit amusing case in which removing ambiguity results with
5857 no candidates.
5858 </p>
5859
5860 <p>
5861 I also found exception safety issue with auto_ptr related to auto_ptr_ref:
5862 </p>
5863 <pre>int f(auto_ptr&lt;B&gt;, std::string);
5864 auto_ptr&lt;B&gt; source2();
5865
5866 // string constructor throws while auto_ptr_ref
5867 // "holds" the pointer
5868 int x4 = f(source2(), "xyz"); // #4
5869 </pre>
5870
5871 <p>
5872 The theoretic execution sequence that will cause a leak:
5873 </p>
5874 <ol>
5875 <li>call auto_ptr&lt;B&gt;::operator auto_ptr_ref&lt;B&gt;()</li>
5876 <li>call string::string(char const*) and throw</li>
5877 </ol>
5878
5879 <p>
5880 According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
5881 returns auto_ptr_ref&lt;Y&gt; that holds *this and this is another defect since
5882 the type of *this is auto_ptr&lt;X&gt; where X might be different from Y. Several
5883 library vendors (e.g. SGI) implement auto_ptr_ref&lt;Y&gt; with Y* as member which
5884 is much more reasonable. Other vendor implemented auto_ptr_ref as
5885 defectively required and it results with awkward and catastrophic code:
5886 int oops = sink(auto_ptr&lt;B&gt;(source())); // warning recursive on all control
5887 paths
5888 </p>
5889
5890 <p>
5891 Dave Abrahams noticed that there is no specification saying that
5892 auto_ptr_ref copy constructor can't throw.
5893 </p>
5894
5895 <p>
5896 My proposal comes to solve all the above issues and significantly simplify
5897 auto_ptr implementation. One of the fundamental requirements from auto_ptr
5898 is that it can be constructed in an intuitive manner (i.e. like ordinary
5899 pointers) but with strict ownership semantics which yield that source
5900 auto_ptr in initialization must be non-const. My idea is to add additional
5901 constructor template with sole propose to generate ill-formed, diagnostic
5902 required, instance for const auto_ptr arguments during instantiation of
5903 declaration. This special constructor will not be instantiated for other
5904 types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
5905 in hand makes the constructor template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;)
5906 legitimate since the actual argument can't be const yet non const r-value
5907 are acceptable.
5908 </p>
5909
5910 <p>
5911 This implementation technique makes the "private auxiliary class"
5912 auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
5913 GCC and VC) consume the new implementation as expected and allow all
5914 intuitive initialization and assignment cases while rejecting illegal cases
5915 that involve const auto_ptr arguments.
5916 </p>
5917
5918 <p>The proposed auto_ptr interface:</p>
5919
5920 <pre>namespace std {
5921     template&lt;class X&gt; class auto_ptr {
5922     public:
5923         typedef X element_type;
5924
5925         // 20.4.5.1 construct/copy/destroy:
5926         explicit auto_ptr(X* p=0) throw();
5927         auto_ptr(auto_ptr&amp;) throw();
5928         template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;) throw();
5929         auto_ptr&amp; operator=(auto_ptr&amp;) throw();
5930         template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;) throw();
5931         ~auto_ptr() throw();
5932
5933         // 20.4.5.2 members:
5934         X&amp; operator*() const throw();
5935         X* operator-&gt;() const throw();
5936         X* get() const throw();
5937         X* release() throw();
5938         void reset(X* p=0) throw();
5939
5940     private:
5941         template&lt;class U&gt;
5942         auto_ptr(U&amp; rhs, typename
5943 unspecified_error_on_const_auto_ptr&lt;U&gt;::type = 0);
5944     };
5945 }
5946 </pre>
5947
5948 <p>
5949 One compliant technique to implement the unspecified_error_on_const_auto_ptr
5950 helper class is using additional private auto_ptr member class template like
5951 the following:
5952 </p>
5953 <pre>template&lt;typename T&gt; struct unspecified_error_on_const_auto_ptr;
5954
5955 template&lt;typename T&gt;
5956 struct unspecified_error_on_const_auto_ptr&lt;auto_ptr&lt;T&gt; const&gt;
5957 { typedef typename auto_ptr&lt;T&gt;::const_auto_ptr_is_not_allowed type; };
5958 </pre>
5959
5960 <p>
5961 There are other techniques to implement this helper class that might work
5962 better for different compliers (i.e. better diagnostics) and therefore I
5963 suggest defining its semantic behavior without mandating any specific
5964 implementation. IMO, and I didn't found any compiler that thinks otherwise,
5965 14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
5966 verifying this with core language experts.
5967 </p>
5968
5969 <p><b>Further changes in standard text:</b></p>
5970 <p>Remove section 20.4.5.3</p>
5971
5972 <p>Change 20.4.5/2 to read something like:
5973 Initializing auto_ptr&lt;X&gt; from const auto_ptr&lt;Y&gt; will result with unspecified
5974 ill-formed declaration that will require unspecified diagnostic.</p>
5975
5976 <p>Change 20.4.5.1/4,5,6 to read:</p>
5977
5978 <pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp; a) throw();</pre>
5979 <p> 4 Requires: Y* can be implicitly converted to X*.</p>
5980 <p> 5 Effects: Calls const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(a).release().</p>
5981 <p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
5982
5983 <p>Change 20.4.5.1/10</p>
5984 <pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt; a) throw();
5985 </pre>
5986 <p>
5987 10 Requires: Y* can be implicitly converted to X*. The expression delete
5988 get() is well formed.
5989 </p>
5990
5991 <p>LWG TC DR #127 is obsolete.</p>
5992
5993 <p>
5994 Notice that the copy constructor and copy assignment operator should remain
5995 as before and accept non-const auto_ptr&amp; since they have effect on the form
5996 of the implicitly declared copy constructor and copy assignment operator of
5997 class that contains auto_ptr as member per 12.8/5,10:
5998 </p>
5999 <pre>struct X {
6000     // implicit X(X&amp;)
6001     // implicit X&amp; operator=(X&amp;)
6002     auto_ptr&lt;D&gt; aptr_;
6003 };
6004 </pre>
6005
6006 <p>
6007 In most cases this indicates about sloppy programming but preserves the
6008 current auto_ptr behavior.
6009 </p>
6010
6011 <p>
6012 Dave Abrahams encouraged me to suggest fallback implementation in case that
6013 my suggestion that involves removing of auto_ptr_ref will not be accepted.
6014 In this case removing the obsolete conversion member to auto_ptr&lt;Y&gt; and
6015 20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
6016 cases. The two constructors that I suggested will co exist with the current
6017 members but will make auto_ptr_ref obsolete in initialization contexts.
6018 auto_ptr_ref will be effective in assignment contexts as suggested in DR
6019 #127 and I can't see any serious exception safety issues in those cases
6020 (although it's possible to synthesize such). auto_ptr_ref&lt;X&gt; semantics will
6021 have to be revised to say that it strictly holds pointer of type X and not
6022 reference to an auto_ptr for the favor of cases in which auto_ptr_ref&lt;Y&gt; is
6023 constructed from auto_ptr&lt;X&gt; in which X is different from Y (i.e. assignment
6024 from r-value derived to base).
6025 </p>
6026
6027
6028
6029 <p><b>Proposed resolution:</b></p>
6030 <p><i>[Redmond: punt for the moment. We haven't decided yet whether we
6031   want to fix auto_ptr for C++-0x, or remove it and replace it with
6032   move_ptr and unique_ptr.]</i></p>
6033
6034
6035
6036 <p><b>Rationale:</b></p>
6037 <p>
6038 Recommend NAD.  We're just going to deprecate it.  It still works for simple use cases
6039 and people know how to deal with it.  Going forward <tt>unique_ptr</tt> is the recommended
6040 tool.
6041 </p>
6042
6043
6044
6045
6046
6047 <hr>
6048 <h3><a name="466"></a>466. basic_string ctor should prevent null pointer error</h3>
6049 <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#NAD">NAD</a>
6050  <b>Submitter:</b> Daniel Frey <b>Date:</b> 2004-06-10</p>
6051 <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>
6052 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6053 <p><b>Discussion:</b></p>
6054 <p>
6055 Today, my colleagues and me wasted a lot of time. After some time, I
6056 found the problem. It could be reduced to the following short example:
6057 </p>
6058
6059 <pre>  #include &lt;string&gt;
6060   int main() { std::string( 0 ); }
6061 </pre>
6062
6063 <p>The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and
6064 Comeau online) compile the above without errors or warnings! The
6065 programs (at least for the GCC) resulted in a SEGV.</p>
6066
6067 <p>I know that the standard explicitly states that the ctor of string
6068 requires a char* which is not zero. STLs could easily detect the above
6069 case with a private ctor for basic_string which takes a single 'int'
6070 argument. This would catch the above code at compile time and would not
6071 ambiguate any other legal ctors.</p>
6072
6073 <p><i>[Redmond: No great enthusiasm for doing this.  If we do,
6074   however, we want to do it for all places that take <tt>charT*</tt>
6075   pointers, not just the single-argument constructor.  The other
6076   question is whether we want to catch this at compile time (in which
6077   case we catch the error of a literal 0, but not an expression whose
6078   value is a null pointer), at run time, or both.]</i></p>
6079
6080
6081
6082
6083 <p><b>Proposed resolution:</b></p>
6084
6085
6086 <p><b>Rationale:</b></p>
6087 <p>
6088 Recommend NAD.  Relegate this functionality to debugging implementations.
6089 </p>
6090
6091
6092
6093
6094
6095 <hr>
6096 <h3><a name="470"></a>470. accessing containers from their elements' special functions</h3>
6097 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6098  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
6099 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
6100 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6101 <p><b>Discussion:</b></p>
6102
6103 <p>
6104 The standard doesn't prohibit the destructors (or any other special
6105 functions) of containers' elements invoked from a member function
6106 of the container from "recursively" calling the same (or any other)
6107 member function on the same container object, potentially while the
6108 container is in an intermediate state, or even changing the state
6109 of the container object while it is being modified. This may result
6110 in some surprising (i.e., undefined) behavior.
6111 </p>
6112
6113 <p>Read email thread starting with c++std-lib-13637 for more.</p>
6114
6115
6116
6117 <p><b>Proposed resolution:</b></p>
6118
6119 <p>Add to Container Requirements the following new paragraph:</p>
6120
6121 <pre>    Unless otherwise specified, the behavior of a program that
6122     invokes a container member function f from a member function
6123     g of the container's value_type on a container object c that
6124     called g from its mutating member function h, is undefined.
6125     I.e., if v is an element of c, directly or indirectly calling
6126     c.h() from v.g() called from c.f(), is undefined.
6127 </pre>
6128
6129 <p><i>[Redmond: This is a real issue, but it's probably a clause 17
6130   issue, not clause 23.  We get the same issue, for example, if we
6131   try to destroy a stream from one of the stream's callback functions.]</i></p>
6132
6133
6134
6135
6136 <p><b>Rationale:</b></p>
6137 <p>
6138 Recommend NAD.  We agree this is an issue, but not a defect.
6139 We believe that there is no wording we can put in the standard
6140 that will cover all cases without introducing unfortunate
6141 corner cases.
6142 </p>
6143
6144
6145
6146
6147
6148 <hr>
6149 <h3><a name="472"></a>472. Missing "Returns" clause in std::equal_range</h3>
6150 <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#Dup">Dup</a>
6151  <b>Submitter:</b> Prateek R Karandikar <b>Date:</b> 2004-06-30</p>
6152 <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>
6153 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6154 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a></p>
6155 <p><b>Discussion:</b></p>
6156 <p>
6157 There is no "Returns:" clause for std::equal_range, which returns non-void.
6158 </p>
6159
6160
6161 <p><b>Proposed resolution:</b></p>
6162
6163
6164 <p><b>Rationale:</b></p>
6165 <p>Fixed as part of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>.</p>
6166
6167
6168
6169
6170
6171
6172 <hr>
6173 <h3><a name="476"></a>476. Forward Iterator implied mutability</h3>
6174 <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#NAD">NAD</a>
6175  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-07-09</p>
6176 <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>
6177 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6178 <p><b>Discussion:</b></p>
6179
6180 <p>24.1/3 says:</p>
6181 <blockquote><p>
6182   Forward iterators satisfy all the requirements of the input and
6183   output iterators and can be used whenever either kind is specified
6184 </p></blockquote>
6185
6186 <p>
6187 The problem is that satisfying the requirements of output iterator
6188 means that you can always assign *something* into the result of
6189 dereferencing it.  That makes almost all non-mutable forward
6190 iterators non-conforming.  I think we need to sever the refinement
6191 relationship between forward iterator and output iterator.
6192 </p>
6193
6194 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.  But this is not a dup.</p>
6195
6196
6197
6198 <p><b>Proposed resolution:</b></p>
6199
6200
6201 <p><b>Rationale:</b></p>
6202 <p>Yes, 24.1/3 does say that. But it's introductory material. The
6203 precise specification is in 24.1.3, and the requrements table there is
6204 right.  We don't need to fine-tune introductory wording.  (Especially
6205 since this wording is likely to be changed as part of the iterator
6206 overhaul.)</p>
6207
6208
6209
6210
6211
6212 <hr>
6213 <h3><a name="477"></a>477. Operator-&gt; for const forward iterators</h3>
6214 <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#Dup">Dup</a>
6215  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-07-11</p>
6216 <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>
6217 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6218 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p>
6219 <p><b>Discussion:</b></p>
6220 <p>
6221 The Forward Iterator requirements table contains the following:
6222 </p>
6223 <pre> expression  return type         operational  precondition
6224                                   semantics
6225   ==========  ==================  ===========  ==========================
6226   a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
6227               otherwise const U&amp;
6228
6229   r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
6230 </pre>
6231
6232 <p>
6233 The first line is exactly right.  The second line is wrong.  Basically
6234 it implies that the const-ness of the iterator affects the const-ness
6235 of referenced members.  But Paragraph 11 of [lib.iterator.requirements] says:
6236 </p>
6237
6238 <blockquote><p>
6239    In the following sections, a and b denote values of type const X, n
6240    denotes a value of the difference type Distance, u, tmp, and m
6241    denote identifiers, r denotes a value of X&amp;, t denotes a value of
6242    value type T, o denotes a value of some type that is writable to
6243    the output iterator.
6244 </p></blockquote>
6245
6246 <p>AFAICT if we need the second line at all, it should read the same
6247 as the first line.</p>
6248
6249 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p>
6250
6251
6252 <p><b>Proposed resolution:</b></p>
6253
6254
6255 <p><b>Rationale:</b></p>
6256 <p>The LWG agrees that this is a real problem.  Marked as a DUP
6257   because the LWG chose to adopt the solution proposed in
6258   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
6259 </p>
6260
6261
6262
6263
6264
6265 <hr>
6266 <h3><a name="479"></a>479. Container requirements and placement new</h3>
6267 <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#Dup">Dup</a>
6268  <b>Submitter:</b> Herb Sutter <b>Date:</b> 2004-08-01</p>
6269 <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>
6270 <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>
6271 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6272 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a></p>
6273 <p><b>Discussion:</b></p>
6274 <p>Nothing in the standard appears to make this program ill-formed:</p>
6275
6276 <pre>  struct C {
6277     void* operator new( size_t s ) { return ::operator new( s ); }
6278     // NOTE: this hides in-place and nothrow new
6279   };
6280
6281   int main() {
6282     vector&lt;C&gt; v;
6283     v.push_back( C() );
6284   }
6285 </pre>
6286
6287 <p>Is that intentional?  We should clarify whether or not we intended
6288   to require containers to support types that define their own special
6289   versions of <tt>operator new</tt>.</p>
6290
6291 <p><i>[
6292 Lillehammer: A container will definitely never use this overridden
6293 operator new, but whether it will fail to compile is unclear from the
6294 standard.  Are containers supposed to use qualified or unqualified
6295 placement new?  20.4.1.1 is somewhat relevant, but the standard
6296 doesn't make it completely clear whether containers have to use
6297 Allocator::construct(). If containers don't use it, the details of how
6298 containers use placement new are unspecified. That is the real bug,
6299 but it needs to be fixed as part of the allocator overhaul.  Weak
6300 support that the eventual solution should make this code well formed.
6301 ]</i></p>
6302
6303
6304
6305
6306 <p><b>Proposed resolution:</b></p>
6307
6308
6309
6310
6311
6312
6313
6314 <hr>
6315 <h3><a name="480"></a>480. unary_function and binary_function should have protected nonvirtual destructors</h3>
6316 <p><b>Section:</b> 20.5.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6317  <b>Submitter:</b> Joe Gottman <b>Date:</b> 2004-08-19</p>
6318 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
6319 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6320 <p><b>Discussion:</b></p>
6321 <p>The classes std::unary_function and std::binary_function are both
6322 designed to be inherited from but contain no virtual functions.  This
6323 makes it too easy for a novice programmer to write code like
6324 binary_function&lt;int, int, int&gt; *p = new plus&lt;int&gt;; delete p;</p>
6325
6326 <p>There are two common ways to prevent this source of undefined
6327 behavior: give the base class a public virtual destructor, or give it
6328 a protected nonvirtual destructor.  Since unary_function and
6329 binary_function have no other virtual functions, (note in particular
6330 the absence of an operator()() ), it would cost too much to give them
6331 public virtual destructors.  Therefore, they should be given protected
6332 nonvirtual destructors.</p>
6333
6334
6335 <p><b>Proposed resolution:</b></p>
6336 <p>Change Paragraph 20.3.1 of the Standard from</p>
6337 <pre>    template &lt;class Arg, class Result&gt;
6338     struct unary_function {
6339         typedef Arg argument_type;
6340         typedef Result result_type;
6341     };
6342
6343     template &lt;class Arg1, class Arg2, class Result&gt;
6344     struct binary_function {
6345         typedef Arg1 first_argument_type;
6346         typedef Arg2 second_argument_type;
6347         typedef Result result_type;
6348     };
6349 </pre>
6350
6351 <p>to</p>
6352 <pre>    template &lt;class Arg, class Result&gt;
6353         struct unary_function {
6354         typedef Arg argument_type;
6355         typedef Result result_type;
6356     protected:
6357         ~unary_function() {}
6358     };
6359
6360     template &lt;class Arg1, class Arg2, class Result&gt;
6361     struct binary_function {
6362         typedef Arg1 first_argument_type;
6363         typedef Arg2 second_argument_type;
6364         typedef Result result_type;
6365     protected:
6366         ~binary_function() {}
6367     };
6368 </pre>
6369
6370
6371 <p><b>Rationale:</b></p>
6372 <p>The LWG doesn't believe the existing definition causes anybody any
6373   concrete harm.</p>
6374
6375
6376
6377
6378
6379 <hr>
6380 <h3><a name="481"></a>481. unique's effects on the range [result, last)</h3>
6381 <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#NAD">NAD</a>
6382  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2004-08-30</p>
6383 <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>
6384 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6385 <p><b>Discussion:</b></p>
6386 <p>
6387 The standard says that unique(first, last) "eliminates all but the
6388 first element from every consecutive group of equal elements" in
6389 [first, last) and returns "the end of the resulting range".  So a
6390 postcondition is that [first, result) is the same as the old [first,
6391 last) except that duplicates have been eliminated.
6392 </p>
6393
6394 <p>What postconditions are there on the range [result, last)?  One
6395   might argue that the standard says nothing about those values, so
6396   they can be anything.  One might also argue that the standard
6397   doesn't permit those values to be changed, so they must not be.
6398   Should the standard say something explicit one way or the other?</p>
6399
6400
6401
6402 <p><b>Proposed resolution:</b></p>
6403 <p>
6404 </p>
6405
6406
6407 <p><b>Rationale:</b></p>
6408 <p>We don't want to make many guarantees about what's in [result,
6409 end). Maybe we aren't being quite explicit enough about not being
6410 explicit, but it's hard to think that's a major problem.</p>
6411
6412
6413
6414
6415
6416 <hr>
6417 <h3><a name="482"></a>482. Swapping pairs</h3>
6418 <p><b>Section:</b> 20.2.3 [pairs], 20.3 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
6419  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2004-09-14</p>
6420 <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>
6421 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
6422 <p><b>Discussion:</b></p>
6423 <p>(Based on recent comp.std.c++ discussion)</p>
6424
6425 <p>Pair (and tuple) should specialize std::swap to work in terms of
6426 std::swap on their components.  For example, there's no obvious reason
6427 why swapping two objects of type pair&lt;vector&lt;int&gt;,
6428 list&lt;double&gt; &gt; should not take O(1).</p>
6429
6430 <p><i>[Lillehammer: We agree it should be swappable.  Howard will
6431   provide wording.]</i></p>
6432
6433
6434 <p><i>[
6435 Post Oxford:  We got <tt>swap</tt> for <tt>pair</tt> but accidently
6436 missed <tt>tuple</tt>.  <tt>tuple::swap</tt> is being tracked by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
6437 ]</i></p>
6438
6439
6440
6441
6442 <p><b>Proposed resolution:</b></p>
6443 <p>
6444 Wording provided in
6445 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>.
6446 </p>
6447
6448 <p><b>Rationale:</b></p>
6449 <p>
6450 Recommend NAD, fixed by
6451 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>.
6452 </p>
6453
6454
6455
6456
6457
6458 <hr>
6459 <h3><a name="483"></a>483. Heterogeneous equality and EqualityComparable</h3>
6460 <p><b>Section:</b> 25.1 [alg.nonmodifying], 25.2 [alg.modifying.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
6461  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2004-09-20</p>
6462 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6463 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a></p>
6464 <p><b>Discussion:</b></p>
6465 <p>c++std-lib-14262</p>
6466
6467 <p>[lib.alg.find] requires T to be EqualityComparable:</p>
6468
6469 <pre>template &lt;class InputIterator, class T&gt;
6470    InputIterator find(InputIterator first, InputIterator last,
6471                       const T&amp; value);
6472 </pre>
6473
6474 <p>
6475 However the condition being tested, as specified in the Effects
6476 clause, is actually *i == value, where i is an InputIterator.
6477 </p>
6478
6479 <p>
6480 The two clauses are in agreement only if the type of *i is T, but this
6481 isn't necessarily the case. *i may have a heterogeneous comparison
6482 operator that takes a T, or a T may be convertible to the type of *i.
6483 </p>
6484
6485 <p>Further discussion (c++std-lib-14264): this problem affects a
6486   number of algorithsm in clause 25, not just <tt>find</tt>.  We
6487   should try to resolve this problem everywhere it appears.</p>
6488
6489
6490 <p><b>Proposed resolution:</b></p>
6491
6492 <p>[lib.alg.find]:</p>
6493 <blockquote><p>
6494    Remove [lib.alg.find]/1.
6495 </p></blockquote>
6496
6497 <p>[lib.alg.count]:</p>
6498 <blockquote><p>
6499    Remove [lib.alg.count]/1.
6500 </p></blockquote>
6501
6502 <p>[lib.alg.search]:</p>
6503 <blockquote><p>
6504    Remove "Type T is EqualityComparable (20.1.1), " from [lib.alg.search]/4.
6505 </p></blockquote>
6506
6507 <p>[lib.alg.replace]:</p>
6508
6509 <blockquote>
6510    <p>
6511    Remove [lib.alg.replace]/1.
6512    Replace [lb.alg.replace]/2 with:
6513    </p>
6514
6515        <blockquote><p>
6516        For every iterator i in the range [first, last) for which *i == value
6517        or pred(*i) holds perform *i = new_value.
6518        </p></blockquote>
6519
6520    <p>
6521    Remove the first sentence of /4.
6522    Replace the beginning of /5 with:
6523    </p>
6524
6525        <blockquote><p>
6526        For every iterator i in the range [result, result + (last -
6527        first)), assign to *i either...
6528        </p></blockquote>
6529
6530    <p>(Note the defect here, current text says assign to i, not *i).</p>
6531 </blockquote>
6532
6533 <p>[lib.alg.fill]:</p>
6534
6535 <blockquote>
6536    <p>
6537    Remove "Type T is Assignable (23.1), " from /1.
6538    Replace /2 with:
6539    </p>
6540
6541        <blockquote><p>
6542        For every iterator i in the range [first, last) or [first, first + n),
6543        perform *i = value.
6544        </p></blockquote>
6545 </blockquote>
6546
6547 <p>[lib.alg.remove]:</p>
6548 <blockquote><p>
6549    Remove /1.
6550    Remove the first sentence of /6.
6551 </p></blockquote>
6552
6553
6554
6555 <p><b>Rationale:</b></p>
6556 <p>Duplicate of (a subset of) issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a>.</p>
6557
6558
6559
6560
6561
6562
6563 <hr>
6564 <h3><a name="486"></a>486. min/max CopyConstructible requirement is too strict</h3>
6565 <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#Dup">Dup</a>
6566  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-10-13</p>
6567 <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>
6568 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6569 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a></p>
6570 <p><b>Discussion:</b></p>
6571 <p>A straightforward implementation of these algorithms does not need to
6572 copy T.</p>
6573
6574
6575 <p><b>Proposed resolution:</b></p>
6576 <p>drop the the words "and CopyConstructible" from paragraphs 1 and 4</p>
6577
6578
6579 <p><b>Rationale:</b></p>
6580
6581
6582
6583
6584
6585
6586 <hr>
6587 <h3><a name="487"></a>487. Allocator::construct is too limiting</h3>
6588 <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#NAD">NAD</a>
6589  <b>Submitter:</b> Dhruv Matani <b>Date:</b> 2004-10-17</p>
6590 <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>
6591 <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>
6592 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6593 <p><b>Discussion:</b></p>
6594 <p>
6595 The standard's version of allocator::construct(pointer,
6596 const_reference) severely limits what you can construct using this
6597 function.  Say you can construct a socket from a file descriptor. Now,
6598 using this syntax, I first have to manually construct a socket from
6599 the fd, and then pass the constructed socket to the construct()
6600 function so it will just to an uninitialized copy of the socket I
6601 manually constructed. Now it may not always be possible to copy
6602 construct a socket eh! So, I feel that the changes should go in the
6603 allocator::construct(), making it:
6604 </p>
6605 <pre>    template&lt;typename T&gt;
6606     struct allocator{
6607       template&lt;typename T1&gt;
6608       void construct(pointer T1 const&amp; rt1);
6609     };
6610 </pre>
6611
6612 <p>
6613 Now, the ctor of the class T which matches the one that takes a T1 can
6614 be called! Doesn't that sound great?
6615 </p>
6616
6617
6618 <p><b>Proposed resolution:</b></p>
6619
6620
6621 <p><b>Rationale:</b></p>
6622 <p>NAD. STL uses copying all the time, and making it possible for
6623   allocators to construct noncopyable objects is useless in the
6624   absence of corresponding container changes. We might consider this
6625   as part of a larger redesign of STL.</p>
6626
6627
6628
6629
6630
6631 <hr>
6632 <h3><a name="489"></a>489. std::remove / std::remove_if wrongly specified</h3>
6633 <p><b>Section:</b> 25.2.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6634  <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
6635 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</p>
6636 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6637 <p><b>Discussion:</b></p>
6638 <p>In Section 25.2.7 [lib.alg.remove], paragraphs 1 to 5 describe the
6639 behavior of the mutating sequence operations std::remove and
6640 std::remove_if. However, the wording does not reflect the intended
6641 behavior [Note: See definition of intended behavior below] of these
6642 algorithms, as it is known to the C++ community [1].
6643 </p>
6644
6645
6646
6647 <p>1) Analysis of current wording:</p>
6648
6649
6650 <p>25.2.7 [lib.alg.remove], paragraph 2:</p>
6651
6652 <p>Current wording says:
6653 "Effects: Eliminates all the elements referred to by iterator i in the
6654 range [first, last) for which the following corresponding conditions
6655 hold: *i == value, pred(*i) != false."</p>
6656
6657 <p>
6658 This sentences expresses specifically that all elements denoted by the
6659 (original) range [first, last) for which the corresponding condition
6660 hold will be eliminated. Since there is no formal definition of the term
6661 "eliminate" provided, the meaning of "eliminate" in everyday language
6662 implies that as postcondition, no element in the range denoted by
6663 [first, last) will hold the corresponding condition on reiteration over
6664 the range [first, last).
6665 </p>
6666
6667 <p>
6668 However, this is neither the intent [Note: See definition of intended
6669 behavior below] nor a general possible approach. It can be easily proven
6670 that if all elements of the original range[first, last) will hold the
6671 condition, it is not possible to substitute them by an element for which
6672 the condition will not hold.
6673 </p>
6674
6675
6676 <p>25.2.7 [lib.alg.remove], paragraph 3:</p>
6677
6678 <p>
6679 Current wording says:
6680 "Returns: The end of the resulting range."
6681 </p>
6682
6683 <p>
6684 The resulting range is not specified. In combination with 25.2.7
6685 [lib.alg.remove], paragraph 2, the only reasonable interpretation of
6686 this so-called resulting range is the range [first,last) - thus
6687 returning always the ForwardIterator 'last' parameter.
6688 </p>
6689
6690
6691 <p>
6692 25.2.7 [lib.alg.remove], paragraph 4:
6693 </p>
6694
6695 <p>
6696 Current wording says:
6697 "Notes: Stable: the relative order of the elements that are not removed
6698 is the same as their relative order in the original range"
6699 </p>
6700
6701 <p>
6702 This sentences makes use of the term "removed", which is neither
6703 specified, nor used in a previous paragraph (which uses the term
6704 "eliminate"), nor unamgiuously separated from the name of the algorithm.
6705 </p>
6706
6707
6708 <p>2) Description of intended behavior:</p>
6709
6710 <p>
6711 For the rest of this Defect Report, it is assumed that the intended
6712 behavior was that all elements of the range [first, last) which do not
6713 hold the condition *i == value (std::remove) or  pred(*i) != false
6714 (std::remove_if)], call them s-elements [Note: s...stay], will be placed
6715 into a contiguous subrange of [first, last), denoted by the iterators
6716 [first, return value). The number of elements in the resulting range
6717 [first, return value) shall be equal to the number of s-elements in the
6718 original range [first, last). The relative order of the elements in the
6719 resulting subrange[first, return value) shall be the same as the
6720 relative order of the corresponding elements in the original range. It
6721 is undefined whether any elements in the resulting subrange [return
6722 value, last) will hold the corresponding condition, or not.
6723 </p>
6724
6725 <p>
6726 All implementations known to the author of this Defect Report comply
6727 with this intent. Since the intent  of the behavior (contrary to the
6728 current wording) is also described in various utility references serving
6729 the C++ community [1], it is not expected that fixing the paragraphs
6730 will influence current code - unless the code relies on the behavior as
6731 it is described by current wording and the implementation indeed
6732 reflects the current wording, and not the intent.
6733 </p>
6734
6735
6736
6737 <p>3) Proposed fixes:</p>
6738
6739
6740 <p>Change 25.2.7 [lib.alg.remove], paragraph 2 to:</p>
6741
6742 <p>
6743 "Effect: Places all the elements referred to by iterator i in the range
6744 [first, last) for which the following corresponding conditions hold :
6745 !(*i == value), pred(*i) == false into the subrange [first, k) of the
6746 original range, where k shall denote a value of type ForwardIterator. It
6747 is undefined whether any elements in the resulting subrange [k, last)
6748 will hold the corresponding condition, or not."
6749 </p>
6750
6751 <p>Comments to the new wording:</p>
6752
6753 <p>
6754 a) "Places" has no special meaning, and the everyday language meaning
6755 should fit.
6756 b) The corresponding conditions were negated compared to the current
6757 wording, becaue the new wording requires it.
6758 c) The wording "of the original range" might be redundant, since any
6759 subrange starting at 'first' and containing no more elements than the
6760 original range is implicitly a subrange of the original range [first,
6761 last).
6762 d) The iterator k was introduced instead of "return value" in order to
6763 avoid a cyclic dependency on 25.2.7/3. The wording ", where k shall
6764 denote a value of type ForwardIterator" might be redundant, because it
6765 follows implicitly by 25.2.7/3.
6766 e) "Places" does, in the author's opinion, explicitly forbid duplicating
6767 any element holding the corresponding condition in the original range
6768 [first, last) within the resulting range [first, k). If there is doubt
6769 this term might be not unambiguous regarding this, it is suggested that
6770 k is specified more closely by the following wording: "k shall denote a
6771 value of type ForwardIterator [Note: see d)] so that k - first is equal
6772 to the number of elements in the original range [first, last) for which
6773 the corresponding condition did hold". This could also be expressed as a
6774 separate paragraph "Postcondition:"
6775 f) The senctence "It is undefined whether any elements in the resulting
6776 subrange [k, last) will hold the corresponding condition, or not." was
6777 added consciously so the term "Places" does not imply if the original
6778 range [first, last) contains n elements holding the corresponding
6779 condition, the identical range[first, last) will also contain exactly n
6780 elements holding the corresponding condition after application of the
6781 algorithm.
6782 </p>
6783
6784 <p>
6785 Change 25.2.7 [lib.alg.remove], paragraph 3 to:
6786
6787 "Returns: The iterator k."
6788 </p>
6789
6790 <p>
6791 Change 25.2.7 [lib.alg.remove], paragraph 4 to:
6792
6793 "Notes: Stable: the relative order of the elements that are placed into
6794 the subrange [first, return value) shall be the same as their relative
6795 order was in the original range [first, last) prior to application of
6796 the algorithm."
6797 </p>
6798
6799 <p>
6800 Comments to the new wording:
6801 </p>
6802
6803 <p>
6804 a) the wording "was ...  prior to application of the algorithm" is used
6805 to explicitly distinguish the original range not only by means of
6806 iterators, but also by a 'chronological' factor from the resulting range
6807 [first, return value). It might be redundant.
6808 </p>
6809
6810 <p>
6811 [1]:
6812 The wording of these references is not always unambiguous, and provided
6813 examples partially contradict verbal description of the algorithms,
6814 because the verbal description resembles the problematic wording of
6815 ISO/IEC 14882:2003.
6816 </p>
6817
6818
6819 <p><b>Proposed resolution:</b></p>
6820
6821
6822 <p><b>Rationale:</b></p>
6823 <p>The LWG believes that the standard is sufficiently clear, and that
6824   there is no evidence of any real-world confusion about this point.</p>
6825
6826
6827
6828
6829
6830 <hr>
6831 <h3><a name="490"></a>490. std::unique wrongly specified</h3>
6832 <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#NAD">NAD</a>
6833  <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
6834 <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>
6835 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6836 <p><b>Discussion:</b></p>
6837 <p>In Section 25.2.8 [lib.alg.unique], paragraphs 1 to 3 describe the
6838 behavior of the mutating sequence operation std::unique. However, the
6839 wording does not reflect the intended behavior [Note: See definition of
6840 intended behavior below] of these algorithms, as it is known to the C++
6841 community [1].</p>
6842
6843
6844
6845 <p>1) Analysis of current wording:</p>
6846
6847
6848 <p>25.2.8 [lib.alg.unique], paragraph 1:</p>
6849
6850 <p>
6851 Current wording says:
6852 "Effects: Eliminates all but the first element from every consecutive
6853 group of equal elements referred to by the iterator i in the range
6854 [first, last) for which the following corresponding conditions hold: *i
6855 == *(i - 1) or pred(*i, *(i -1)) != false"
6856 </p>
6857
6858 <p>
6859 This sentences expresses specifically that all elements denoted by the
6860 (original) range [first, last) which are not but the first element from
6861 a consecutive group of equal elements (where equality is defined as *i
6862 == *(i - 1) or pred(*i, *(i - 1)) ! = false) [Note: See DR 202], call
6863 them r-elements [Note: r...remove], will be eliminated. Since there is
6864 no formal definition of the term "eliminate" provided, it is undefined
6865 how this "elimination" takes place. But the meaning of "eliminate" in
6866 everyday language seems to disallow explicitly that after application of
6867 the algorithm, any r-element will remain at any position of the range
6868 [first, last) [2].
6869 </p>
6870
6871 <p>
6872 Another defect in the current wording concerns the iterators used to
6873 compare two elements for equality: The current wording contains the
6874 expression "(i - 1)", which is not covered by 25/9 [Note: See DR
6875 submitted by Thomas Mang regarding invalid iterator arithmetic
6876 expressions].
6877 </p>
6878
6879
6880 <p>
6881 25.2.8 [lib.alg.unique], paragraph 2:
6882 </p>
6883 <p>Current wording says:
6884 "Returns: The end of the resulting range."</p>
6885
6886 <p>
6887 The resulting range is not specified. In combination with 25.2.8
6888 [lib.alg.unique], paragraph 1, one reasonable interpretation (in the
6889 author's opinion even the only possible interpretation) of this
6890 so-called resulting range is the range [first, last) - thus returning
6891 always the ForwardIterator 'last' parameter.
6892 </p>
6893
6894 <p>2) Description of intended behavior:</p>
6895
6896 <p>
6897 For the rest of this Defect Report, it is assumed that the intended
6898 behavior was that all elements denoted by the original range [first,
6899 last) which are the first element from a consecutive group of elements
6900 for which the corresponding conditions: *(i-1) == *i (for the version of
6901 unique without a predicate argument) or pred(*(i-1), *i) ! = false (for
6902 the version of unique with a predicate argument) [Note: If such a group
6903 of elements consists of only a single element, this is also considered
6904 the first element] [Note: See resolutions of DR 202], call them
6905 s-elements [Note: s...stay], will be placed into a contiguous subrange
6906 of [first, last), denoted by the iterators [first, return value). The
6907 number of elements in the resulting range [first, return value) shall be
6908 equal to the number of s-elements in the original range [first, last).
6909 Invalid iterator arithmetic expressions are expected to be resolved as
6910 proposed in DR submitted by Thomas Mang regarding invalid iterator
6911 arithmetic expressions. It is also assumed by the author that the
6912 relative order of the elements in the resulting subrange [first, return
6913 value) shall be the same as the relative order of the corresponding
6914 elements (the s-elements) in the original range [Note: If this was not
6915 intended behavior, the additional proposed paragraph about stable order
6916 will certainly become obsolete].
6917 Furthermore, the resolutions of DR 202 are partially considered.
6918 </p>
6919
6920 <p>
6921 All implementations known to the author of this Defect Report comply
6922 with this intent [Note: Except possible effects of DR 202]. Since this
6923 intent of the behavior (contrary to the current wording) is also
6924 described in various utility references serving the C++ community [1],
6925 it is not expected that fixing the paragraphs will influence current
6926 code [Note: Except possible effects of DR 202] - unless the code relies
6927 on the behavior as it is described by current wording and the
6928 implementation indeed reflects the current wording, and not the intent.
6929 </p>
6930
6931
6932
6933 <p>3) Proposed fixes:</p>
6934
6935 <p>
6936 Change 25.2.8 [lib.alg.unique], paragraph 1 to:
6937 </p>
6938
6939 <p>
6940 "Effect: Places the first element from every consecutive group of
6941 elements, referred to by the iterator i in the range [first, last), for
6942 which the following conditions hold: *(i-1) == *i (for the version of
6943 unique without a predicate argument) or pred(*(i -1), *i) != false (for
6944 the version of unique with a predicate argument), into the subrange
6945 [first, k) of the original range, where k shall denote a value of type
6946 ForwardIterator."
6947 </p>
6948
6949 <p>Comments to the new wording:</p>
6950
6951 <p>
6952 a) The new wording was influenced by the resolutions of DR 202. If DR
6953 202 is resolved in another way, the proposed wording need also
6954 additional review.
6955 b) "Places" has no special meaning, and the everyday language meaning
6956 should fit.
6957 c) The expression "(i - 1)" was left, but is expected that DR submitted
6958 by Thomas Mang regarding invalid iterator arithmetic expressions will
6959 take this into account.
6960 d) The wording "(for the version of unique without a predicate
6961 argument)" and "(for the version of unique with a predicate argument)"
6962 was added consciously for clarity and is in resemblence with current
6963 23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant.
6964 e) The wording "of the original range" might be redundant, since any
6965 subrange starting at first and containing no more elements than the
6966 original range is implicitly a subrange of the original range [first,
6967 last).
6968 f) The iterator k was introduced instead of "return value" in order to
6969 avoid a cyclic dependency on 25.2.8 [lib.alg.unique], paragraph 2. The
6970 wording ", where k shall denote a value of type ForwardIterator" might
6971 be redundant, because it follows implicitly by 25.2.8 [lib.alg.unique],
6972 paragraph 2.
6973 g) "Places" does, in the author's opinion, explicitly forbid duplicating
6974 any s-element in the original range [first, last) within the resulting
6975 range [first, k). If there is doubt this term might be not unambiguous
6976 regarding this, it is suggested that k is specified more closely by the
6977 following wording: "k shall denote a value of type ForwardIterator
6978 [Note: See f)] so that k - first is equal to the number of elements in
6979 the original range [first, last) being the first element from every
6980 consecutive group of elements for which the corresponding condition did
6981 hold". This could also be expressed as a separate paragraph
6982 "Postcondition:".
6983 h) If it is considered that the wording is unclear whether it declares
6984 the element of a group which consists of only a single element
6985 implicitly to be the first element of this group [Note: Such an
6986 interpretation could eventually arise especially in case last - first ==
6987 1] , the following additional sentence is proposed: "If such a group of
6988 elements consists of only a single element, this element is also
6989 considered the first element."
6990 </p>
6991
6992 <p>
6993 Change 25.2.8 [lib.alg.unique], paragraph 2 to:
6994 "Returns: The iterator k."
6995 </p>
6996
6997 <p>
6998 Add a separate paragraph "Notes:" as 25.2.8 [lib.alg.unique], paragraph
6999 2a or 3a, or a separate paragraph "Postcondition:" before 25.2.8
7000 [lib.alg.unique], paragraph 2 (wording inside {} shall be eliminated if
7001 the preceding expressions are used, or the preceding expressions shall
7002 be eliminated if wording inside {} is used):
7003 </p>
7004
7005 <p>
7006 "Notes:{Postcondition:} Stable: the relative order of the elements that
7007 are placed into the subrange [first, return value {k}) shall be the same
7008 as their relative order was in the original range [first, last) prior to
7009 application of the algorithm."
7010 </p>
7011
7012 <p>Comments to the new wording:</p>
7013
7014 <p>
7015 a) It is assumed by the author that the algorithm was intended to be
7016 stable.
7017 In case this was not the intent, this paragraph becomes certainly
7018 obsolete.
7019 b) The wording "was ...  prior to application of the algorithm" is used
7020 to explicitly distinguish the original range not only by means of
7021 iterators, but also by a 'chronological' factor from the resulting range
7022 [first, return value). It might be redundant.
7023 </p>
7024
7025 <p>
7026 25.2.8 [lib.alg.unique], paragraph 3:
7027 </p>
7028 <p>See DR 239.</p>
7029
7030 <p>
7031 4) References to other DRs:
7032 </p>
7033
7034 <p>
7035 See DR 202, but which does not address any of the problems described in
7036 this Defect Report [Note: This DR is supposed to complement DR 202].
7037 See DR 239.
7038 See DR submitted by Thomas Mang regarding invalid iterator arithmetic
7039 expressions.
7040 </p>
7041
7042 <p>
7043 [1]:
7044 The wording of these references is not always unambiguous, and provided
7045 examples partially contradict verbal description of the algorithms,
7046 because the verbal description resembles the problematic wording of
7047 ISO/IEC 14882:2003.
7048 </p>
7049
7050 <p>
7051 [2]:
7052 Illustration of conforming implementations according to current wording:
7053 </p>
7054
7055 <p>
7056 One way the author of this DR considers how this "elimination" could be
7057 achieved by a conforming implementation according to current wording is
7058 by substituting each r-element by _any_ s-element [Note: s...stay; any
7059 non-r-element], since all r-elements are "eliminated".
7060 </p>
7061
7062 <p>
7063 In case of a sequence consisting of elements being all 'equal' [Note:
7064 See DR 202], substituting each r-element by the single s-element is the
7065 only possible solution according to current wording.
7066 </p>
7067
7068
7069 <p><b>Proposed resolution:</b></p>
7070
7071
7072 <p><b>Rationale:</b></p>
7073 <p>The LWG believes the standard is sufficiently clear. No
7074 implementers get it wrong, and changing it wouldn't cause any code to
7075 change, so there is no real-world harm here.</p>
7076
7077
7078
7079
7080
7081 <hr>
7082 <h3><a name="491"></a>491. std::list&lt;&gt;::unique incorrectly specified</h3>
7083 <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#NAD">NAD</a>
7084  <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
7085 <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>
7086 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7087 <p><b>Discussion:</b></p>
7088 <p>In Section 23.2.3.4 [list.ops], paragraphs 19 to 21 describe the
7089 behavior of the std::list&lt;T, Allocator&gt;::unique operation. However, the
7090 current wording is defective for various reasons.</p>
7091
7092
7093
7094 <p>
7095 1) Analysis of current wording:
7096 </p>
7097
7098 <p>23.2.3.4 [list.ops], paragraph 19:</p>
7099
7100 <p>
7101 Current wording says:
7102 "Effects:  Eliminates all but the first element from every consecutive
7103 group of equal elements referred to by the iterator i in the range
7104 [first + 1, last) for which *i == *(i - 1) (for the version of unique
7105 with no argument) or pred(*i, *(i -1)) (for the version of unique with a
7106 predicate argument) holds."</p>
7107
7108 <p>
7109 This sentences makes use of the undefined term "Eliminates". Although it
7110 is, to a certain degree, reasonable to consider the term "eliminate"
7111 synonymous with "erase", using "Erase" in the first place, as the
7112 wording of 23.2.3.4 [list.ops], paragraph 15 does, would be clearer.</p>
7113
7114 <p>
7115 The range of the elements referred to by iterator i is "[first + 1,
7116 last)". However, neither "first" nor "last" is defined.</p>
7117
7118 <p>
7119 The sentence makes three times use of iterator arithmetic expressions (
7120 "first + 1", "*i == *(i - 1)", "pred(*i, *(i -1))" ) which is not
7121 defined for bidirectional iterator [see DR submitted by Thomas Mang
7122 regarding invalid iterator arithmetic expressions].</p>
7123
7124 <p>
7125 The same problems as pointed out in DR 202 (equivalence relation / order
7126 of arguments for pred()) apply to this paragraph.</p>
7127
7128 <p>
7129 23.2.3.4 [list.ops], paragraph 20:
7130 </p>
7131
7132 <p>
7133 Current wording says:
7134 "Throws: Nothing unless an exception in thrown by *i == *(i-1) or
7135 pred(*i, *(i - 1))"</p>
7136
7137 <p>
7138 The sentence makes two times use of invalid iterator arithmetic
7139 expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ).
7140 </p>
7141 <p>
7142 [Note: Minor typos: "in" / missing dot at end of sentence.]
7143 </p>
7144
7145 <p>
7146 23.2.3.4 [list.ops], paragraph 21:</p>
7147
7148 <p>
7149 Current wording says:
7150 "Complexity: If the range (last - first) is not empty, exactly (last -
7151 first) - 1 applications of the corresponding predicate, otherwise no
7152 application of the predicate.</p>
7153
7154 <p>
7155 See DR 315 regarding "(last - first)" not yielding a range.</p>
7156
7157 <p>
7158 Invalid iterator arithmetic expression "(last - first) - 1" left .</p>
7159
7160
7161 <p>2) Description of intended behavior:</p>
7162
7163 <p>
7164 For the rest of this Defect Report, it is assumed that "eliminate" is
7165 supposed to be synonymous to "erase", that "first" is equivalent to an
7166 iterator obtained by a call to begin(), "last" is equivalent to an
7167 iterator obtained by a call to end(), and that all invalid iterator
7168 arithmetic expressions are resolved as described in DR submitted by
7169 Thomas Mang regarding invalid iterator arithmetic expressions.</p>
7170
7171 <p>
7172 Furthermore, the resolutions of DR 202 are considered regarding
7173 equivalence relation and order of arguments for a call to pred.</p>
7174
7175 <p>
7176 All implementations known to the author of this Defect Report comply
7177 with these assumptions, apart from the impact of the alternative
7178 resolution of DR 202. Except for the changes implied by the resolutions
7179 of DR 202, no impact on current code is expected.</p>
7180
7181 <p>
7182 3) Proposed fixes:</p>
7183
7184 <p>
7185 Change 23.2.3.4 [list.ops], paragraph 19 to:</p>
7186
7187 <p>
7188 "Effect: Erases all but the first element from every consecutive group
7189 of elements, referred to by the iterator i in the range [begin(),
7190 end()), for which the following conditions hold: *(i-1) == *i (for the
7191 version of unique with no argument) or pred(*(i-1), *i) != false (for
7192 the version of unique with a predicate argument)."</p>
7193
7194 <p>
7195 Comments to the new wording:</p>
7196
7197 <p>
7198 a) The new wording was influenced by DR 202 and the resolutions
7199 presented there. If DR 202 is resolved in another way, the proposed
7200 wording need also additional review.
7201 b) "Erases" refers in the author's opinion unambiguously to the member
7202 function "erase". In case there is doubt this might not be unamgibuous,
7203 a direct reference to the member function "erase" is suggested [Note:
7204 This would also imply a change of 23.2.3.4 [list.ops], paragraph
7205 15.].
7206 c) The expression "(i - 1)" was left, but is expected that DR submitted
7207 by Thomas Mang regarding invalid iterator arithmetic expressions will
7208 take this into account.
7209 d) The wording "(for the version of unique with no argument)" and "(for
7210 the version of unique with a predicate argument)" was kept consciously
7211 for clarity.
7212 e) "begin()" substitutes "first", and "end()" substitutes "last". The
7213 range need adjustment from "[first + 1, last)" to "[begin(), end())" to
7214 ensure a valid range in case of an empty list.
7215 f) If it is considered that the wording is unclear whether it declares
7216 the element of a group which consists of only a single element
7217 implicitly to be the first element of this group [Note: Such an
7218 interpretation could eventually arise especially in case size() == 1] ,
7219 the following additional sentence is proposed: "If such a group of
7220 elements consists of only a single element, this element is also
7221 considered the first element."</p>
7222
7223 <p>
7224 Change 23.2.3.4 [list.ops], paragraph 20 to:</p>
7225
7226 <p>
7227 "Throws: Nothing unless an exception is thrown by *(i-1) == *i or
7228 pred(*(i-1), *i)."</p>
7229
7230 <p>
7231 Comments to the new wording:</p>
7232
7233 <p>
7234 a) The wording regarding the conditions is identical to proposed
7235 23.2.3.4 [list.ops], paragraph 19. If 23.2.3.4 [list.ops],
7236 paragraph 19 is resolved in another way, the proposed wording need also
7237 additional review.
7238 b) The expression "(i - 1)" was left, but is expected that DR submitted
7239 by Thomas Mang regarding invalid iterator arithmetic expressions will
7240 take this into account.
7241 c) Typos fixed.</p>
7242
7243 <p>
7244 Change 23.2.3.4 [list.ops], paragraph 21 to:</p>
7245
7246 <p>
7247 "Complexity: If empty() == false, exactly size() - 1 applications of the
7248 corresponding predicate, otherwise no applications of the corresponding
7249 predicate."</p>
7250
7251 <p>
7252 Comments to the new wording:</p>
7253
7254 <p>
7255 a) The new wording is supposed to also replace the proposed resolution
7256 of DR 315, which suffers from the problem of undefined "first" / "last".
7257 </p>
7258
7259 <p>
7260 5) References to other DRs:</p>
7261
7262 <p>See DR 202.
7263 See DR 239.
7264 See DR 315.
7265 See DR submitted by Thomas Mang regarding invalid iterator arithmetic
7266 expressions.</p>
7267
7268
7269
7270 <p><b>Proposed resolution:</b></p>
7271
7272
7273 <p><b>Rationale:</b></p>
7274 <p>"All implementations known to the author of this Defect Report
7275 comply with these assumption", and "no impact on current code is
7276 expected", i.e. there is no evidence of real-world confusion or
7277 harm.</p>
7278
7279
7280
7281
7282
7283 <hr>
7284 <h3><a name="493"></a>493. Undefined Expression in Input Iterator Note Title</h3>
7285 <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#NAD">NAD</a>
7286  <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-12-13</p>
7287 <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>
7288 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7289 <p><b>Discussion:</b></p>
7290 <p>1) In 24.1.1/3, the following text is currently present.</p>
7291
7292 <p>"Note: For input iterators, a==b does not imply ++a=++b (Equality does
7293 not guarantee the substitution property or referential transparency)."</p>
7294
7295 <p>However, when in Table 72, part of the definition of ++r is given as:</p>
7296
7297 <p>"pre: r is dereferenceable.
7298 post: any copies of the previous value of r are no longer required
7299 either to be dereferenceable ..."</p>
7300
7301 <p>While a==b does not imply that b is a copy of a, this statement should
7302 perhaps still be made more clear.</p>
7303
7304 <p>2) There are no changes to intended behaviour</p>
7305
7306 <p>
7307 3) This Note should be altered to say "Note: For input iterators a==b,
7308 when its behaviour is defined ++a==++b may still be false (Equality does
7309 not guarantee the substitution property or referential transparency).</p>
7310
7311
7312
7313 <p><b>Proposed resolution:</b></p>
7314
7315
7316 <p><b>Rationale:</b></p>
7317 <p>This is descriptive text, not normative, and the meaning is clear.</p>
7318
7319
7320
7321
7322
7323 <hr>
7324 <h3><a name="494"></a>494. Wrong runtime complexity for associative container's insert and delete</h3>
7325 <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#NAD">NAD</a>
7326  <b>Submitter:</b> Hans B os <b>Date:</b> 2004-12-19</p>
7327 <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>
7328 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7329 <p><b>Discussion:</b></p>
7330 <p>According to [lib.associative.reqmts] table 69, the runtime comlexity
7331 of insert(p, t) and erase(q) can be done in amortized constant time.</p>
7332
7333 <p>It was my understanding that an associative container could be
7334 implemented as a balanced binary tree.</p>
7335
7336 <p>For inser(p, t), you 'll have to iterate to p's next node to see if t
7337 can be placed next to p.  Furthermore, the insertion usually takes
7338 place at leaf nodes. An insert next to the root node will be done at
7339 the left of the root next node</p>
7340
7341 <p>So when p is the root node you 'll have to iterate from the root to
7342 its next node, which  takes O(log(size)) time in a balanced tree.</p>
7343
7344 <p>If you insert all values with insert(root, t) (where root is the
7345 root of the tree before insertion) then each insert takes O(log(size))
7346 time.  The amortized complexity per insertion will be O(log(size))
7347 also.</p>
7348
7349 <p>For erase(q), the normal algorithm for deleting a node that has no
7350 empty left or right subtree, is to iterate to the next (or previous),
7351 which is a leaf node. Then exchange the node with the next and delete
7352 the leaf node.  Furthermore according to DR 130, erase should return
7353 the next node of the node erased.  Thus erasing the root node,
7354 requires iterating to the next node.</p>
7355
7356 <p>Now if you empty a map by deleting the root node until the map is
7357 empty, each operation will take O(log(size)), and the amortized
7358 complexity is still O(log(size)).</p>
7359
7360 <p>The operations can be done in amortized constant time if iterating
7361 to the next node can be done in (non amortized) constant time.  This
7362 can be done by putting all nodes in a double linked list.  This
7363 requires two extra links per node.  To me this is a bit overkill since
7364 you can already efficiently insert or erase ranges with erase(first,
7365 last) and insert(first, last).</p>
7366
7367
7368
7369 <p><b>Proposed resolution:</b></p>
7370
7371
7372 <p><b>Rationale:</b></p>
7373 <p>Only "amortized constant" in special circumstances, and we believe
7374   that's implementable. That is: doing this N times will be O(N), not
7375   O(log N).</p>
7376
7377
7378
7379
7380
7381 <hr>
7382 <h3><a name="499"></a>499. Std. doesn't seem to require stable_sort() to be stable!</h3>
7383 <p><b>Section:</b> 25.3.1.2 [stable.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
7384  <b>Submitter:</b> Prateek Karandikar <b>Date:</b> 2005-04-12</p>
7385 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
7386 <p><b>Discussion:</b></p>
7387 <blockquote><p>
7388 17.3.1.1 Summary</p>
7389
7390 <p>
7391 1 The Summary provides a synopsis of the category, and introduces the
7392 first-level subclauses. Each subclause also provides a summary, listing
7393 the headers specified in the subclause and the library entities
7394 provided in each header.
7395 </p>
7396 <p>
7397 2 Paragraphs labelled "Note(s):" or "Example(s):" are informative,
7398 other paragraphs are normative.
7399 </p></blockquote>
7400
7401 <p>So this means that a "Notes" paragraph wouldn't be normative. </p>
7402
7403 <blockquote><p>
7404 25.3.1.2 stable_sort
7405 </p>
7406 <pre>template&lt;class RandomAccessIterator&gt;
7407 void stable_sort(RandomAccessIterat or first, RandomAccessIterator last);
7408
7409 template&lt;class RandomAccessIterator, class Compare&gt;
7410 void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp);
7411 </pre>
7412 <p>
7413 1 Effects: Sorts the elements in the range [first, last).
7414 </p>
7415 <p>
7416 2 Complexity: It does at most N(log N)^2 (where N == last - first)
7417 comparisons; if enough extra memory is available, it is N log N.
7418 </p>
7419 <p>
7420 3 Notes: Stable: the relative order of the equivalent elements is
7421 preserved.
7422 </p></blockquote>
7423
7424 <p>
7425 The Notes para is informative, and nowhere else is stability mentioned above.
7426 </p>
7427
7428 <p>
7429 Also, I just searched for the word "stable" in my copy of the Standard.
7430 and the phrase "Notes: Stable: the relative order of the elements..."
7431 is repeated several times in the Standard library clauses for
7432 describing various functions. How is it that stability is talked about
7433 in the informative paragraph? Or am I missing something obvious?
7434 </p>
7435
7436
7437 <p><b>Proposed resolution:</b></p>
7438 <p>
7439 </p>
7440
7441
7442 <p><b>Rationale:</b></p>
7443 <p>
7444 This change has already been made.
7445 </p>
7446
7447
7448
7449
7450
7451 <hr>
7452 <h3><a name="500"></a>500. do_length cannot be implemented correctly</h3>
7453 <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#NAD">NAD</a>
7454  <b>Submitter:</b> Krzysztof &#379;elechowski <b>Date:</b> 2005-05-24</p>
7455 <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>
7456 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7457 <p><b>Discussion:</b></p>
7458 <ol>
7459 <li>codecvt::do_length is of type int;</li>
7460 <li>it is assumed to be sort-of returning from_next - from of type ptrdiff_t;</li>
7461 <li>ptrdiff_t cannot be cast to an int without data loss.</li>
7462 </ol>
7463 <p>
7464 Contradiction.
7465 </p>
7466
7467
7468 <p><b>Proposed resolution:</b></p>
7469 <p>
7470 </p>
7471
7472
7473
7474
7475
7476 <hr>
7477 <h3><a name="501"></a>501. Proposal: strengthen guarantees of lib.comparisons</h3>
7478 <p><b>Section:</b> 20.5.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7479  <b>Submitter:</b> Me &lt;anti_spam_email2003@yahoo.com&gt; <b>Date:</b> 2005-06-07</p>
7480 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
7481 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7482 <p><b>Discussion:</b></p>
7483 <blockquote><p>
7484 "For templates greater, less, greater_equal, and less_equal,
7485 the specializations for any pointer type yield a total order, even if
7486 the built-in operators &lt;, &gt;, &lt;=, &gt;= do not."
7487 </p></blockquote>
7488
7489 <p>
7490 The standard should do much better than guarantee that these provide a
7491 total order, it should guarantee that it can be used to test if memory
7492 overlaps, i.e. write a portable memmove. You can imagine a platform
7493 where the built-in operators use a uint32_t comparison (this tests for
7494 overlap on this platform) but the less&lt;T*&gt; functor is allowed to be
7495 defined to use a int32_t comparison. On this platform, if you use
7496 std::less with the intent of making a portable memmove, comparison on
7497 an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give
7498 incorrect results.
7499 </p>
7500
7501
7502 <p><b>Proposed resolution:</b></p>
7503 <p>
7504 Add a footnote to 20.5.3/8 saying:
7505 </p>
7506
7507 <blockquote><p>
7508 Given a p1 and p2 such that p1 points to N objects of type T and p2
7509 points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M),
7510 less returns the same value when comparing all pointers in [p1,p1+N) to
7511 all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R
7512 such that less returns the same value when comparing all pointers in
7513 [p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when
7514 comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M).
7515 For the sake of completeness, the null pointer value (4.10) for T is
7516 considered to be an array of 1 object that doesn't overlap with any
7517 non-null pointer to T. less_equal, greater, greater_equal, equal_to,
7518 and not_equal_to give the expected results based on the total ordering
7519 semantics of less. For T of void, treat it as having similar semantics
7520 as T of char i.e. less&lt;cv T*&gt;(a, b) gives the same results as less&lt;cv
7521 void*&gt;(a, b) which gives the same results as less&lt;cv char*&gt;((cv
7522 char*)(cv void*)a, (cv char*)(cv void*)b).
7523 </p></blockquote>
7524
7525 <p>
7526 I'm also thinking there should be a footnote to 20.5.3/1 saying that if
7527 A and B are similar types (4.4/4), comp&lt;A&gt;(a,b) returns the same value
7528 as comp&lt;B&gt;(a,b) (where comp is less, less_equal, etc.). But this might
7529 be problematic if there is some really funky operator overloading going
7530 on that does different things based on cv (that should be undefined
7531 behavior if somebody does that though). This at least should be
7532 guaranteed for all POD types (especially pointers) that use the
7533 built-in comparison operators.
7534 </p>
7535
7536
7537
7538 <p><b>Rationale:</b></p>
7539 <p>
7540 less is already required to provide a strict weak ordering which is good enough
7541 to detect overlapping memory situations.
7542 </p>
7543
7544
7545
7546
7547
7548 <hr>
7549 <h3><a name="504"></a>504. Integer types in pseudo-random number engine requirements</h3>
7550 <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#NAD%20Editorial">NAD Editorial</a>
7551  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7552 <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>
7553 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
7554 <p><b>Discussion:</b></p>
7555 <p>
7556 In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type,
7557 g is an ... object returning values of unsigned integral type ..."
7558 </p>
7559
7560
7561 <p><b>Proposed resolution:</b></p>
7562 <p>
7563 In 5.1.1 [tr.rand.req], Paragraph 2 replace
7564 </p>
7565
7566 <blockquote><p>
7567 ... s is a value of integral type, g is an lvalue of a type other than X that
7568 defines a zero-argument function object returning values of <del>unsigned integral</del> type
7569 <ins><tt>unsigned long int</tt></ins>,
7570 ...
7571 </p></blockquote>
7572
7573 <p>
7574 In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s)
7575 </p>
7576
7577 <blockquote><p>
7578 creates an engine with the initial internal state
7579 determined by <ins><tt>static_cast&lt;unsigned long&gt;(</tt></ins><tt><i>s</i></tt><ins><tt>)</tt></ins>
7580 </p></blockquote>
7581
7582 <p><i>[
7583 Mont Tremblant:  Both s and g should be unsigned long.
7584 This should refer to the constructor signatures. Jens  provided wording post Mont Tremblant.
7585 ]</i></p>
7586
7587
7588 <p><i>[
7589 Berlin:  N1932 adopts the proposed resolution:  see 26.3.1.3/1e and Table 3 row 2. Moved
7590 to Ready.
7591 ]</i></p>
7592
7593
7594
7595
7596 <p><b>Rationale:</b></p>
7597 <p>
7598 Jens:  Just requiring X(unsigned long) still makes it possible
7599 for an evil library writer to also supply a X(int) that does something
7600 unexpected.  The wording above requires that X(s) always performs
7601 as if X(unsigned long) would have been called.  I believe that is
7602 sufficient and implements our intentions from Mont Tremblant.  I
7603 see no additional use in actually requiring a X(unsigned long)
7604 signature.  u.seed(s) is covered by its reference to X(s), same
7605 arguments.
7606 </p>
7607
7608
7609 <p><i>[
7610 Portland:  Subsumed by N2111.
7611 ]</i></p>
7612
7613
7614
7615
7616
7617 <hr>
7618 <h3><a name="506"></a>506. Requirements of Distribution parameter for variate_generator</h3>
7619 <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#NAD">NAD</a>
7620  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7621 <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>
7622 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7623 <p><b>Discussion:</b></p>
7624 <p>
7625 Paragraph 3 requires that template argument U (which corresponds to template
7626 parameter Engine) satisfy all uniform random number generator requirements.
7627 However, there is no  analogous requirement regarding the template argument
7628 that corresponds to template parameter Distribution.  We believe there should
7629 be, and that it should require that this template argument satisfy all random
7630 distribution requirements.
7631 </p>
7632
7633
7634 <p><b>Proposed resolution:</b></p>
7635 <p>
7636 Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18.
7637 </p>
7638 <p>
7639 Consequence 2: Add max() and min() functions to those distributions that
7640 do not already have them.
7641 </p>
7642
7643 <p><i>[
7644 Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere.
7645 Marc supports having min and max to satisfy generic programming interface.
7646 ]</i></p>
7647
7648
7649
7650
7651 <p><b>Rationale:</b></p>
7652 <p>Berlin:  N1932 makes this moot: variate_generator has been eliminated.</p>
7653
7654
7655
7656
7657
7658 <hr>
7659 <h3><a name="509"></a>509. Uniform_int template parameters</h3>
7660 <p><b>Section:</b> 26.4.8.1 [rand.dist.uni], TR1 5.1.7.1 [tr.rand.dist.iunif] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7661  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7662 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7663 <p><b>Discussion:</b></p>
7664 <p>
7665 In [tr.rand.dist.iunif] the uniform_int distribution currently has a single
7666 template parameter, IntType, used as the input_type and as the result_type
7667 of the distribution.  We believe there is no reason to conflate these types
7668 in this way.
7669 </p>
7670
7671
7672 <p><b>Proposed resolution:</b></p>
7673 <p>
7674 We recommend that there be a second template  parameter to
7675 reflect the distribution's input_type, and that the existing first template
7676 parameter continue to reflect (solely) the result_type:
7677 </p>
7678 <blockquote><pre>template&lt; class IntType = int, UIntType = unsigned int &gt;
7679 class uniform_int
7680 {
7681 public:
7682   // types
7683   typedef  UIntType  input_type;
7684   typedef  IntType   result_type;
7685 </pre></blockquote>
7686
7687 <p><i>[
7688 Berlin: Moved to NAD.  N1932 makes this moot: the input_type template parameter has been
7689 eliminated.
7690 ]</i></p>
7691
7692
7693
7694
7695
7696
7697
7698 <hr>
7699 <h3><a name="510"></a>510. Input_type for bernoulli_distribution</h3>
7700 <p><b>Section:</b> 26.4.8.2 [rand.dist.bern], TR1 5.1.7.2 [tr.rand.dist.bern] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7701  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7702 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7703 <p><b>Discussion:</b></p>
7704 <p>
7705 In [tr.rand.dist.bern] the distribution currently requires;
7706 </p>
7707 <blockquote><pre>typedef  int  input_type;
7708 </pre></blockquote>
7709
7710
7711 <p><b>Proposed resolution:</b></p>
7712 <p>
7713 We believe this is an unfortunate choice, and recommend instead:
7714 </p>
7715 <blockquote><pre>typedef  unsigned int  input_type;
7716 </pre></blockquote>
7717
7718 <p><i>[
7719 Berlin:  Moved to NAD. N1932 makes this moot: the input_type template parameter has been
7720 eliminated.
7721 ]</i></p>
7722
7723
7724
7725
7726
7727
7728
7729 <hr>
7730 <h3><a name="511"></a>511. Input_type for binomial_distribution</h3>
7731 <p><b>Section:</b> 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7732  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7733 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</p>
7734 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7735 <p><b>Discussion:</b></p>
7736 <p>
7737 Unlike all other distributions in TR1, this binomial_distribution has an
7738 implementation-defined  input_type.  We believe this is an unfortunate choice,
7739 because it hinders users from writing portable code.  It also hinders the
7740 writing of compliance tests.  We recommend instead:
7741 </p>
7742 <blockquote><pre>typedef  RealType  input_type;
7743 </pre></blockquote>
7744 <p>
7745 While this choice is somewhat arbitrary (as it was for some of the other
7746 distributions), we make  this particular choice because (unlike all other
7747 distributions) otherwise this template would not publish its RealType
7748 argument and so users could not write generic code that accessed this
7749 second template parameter.  In this respect, the choice is consistent with
7750 the other distributions in  TR1.
7751 </p>
7752 <p>
7753 We have two reasons for recommending that a real type be specified instead.
7754 One reason is  based specifically on characteristics of binomial distribution
7755 implementations, while the other is based on mathematical characteristics of
7756 probability distribution functions in general.
7757 </p>
7758 <p>
7759 Implementations of binomial distributions commonly use Stirling approximations
7760 for values in certain ranges.  It is far more natural to use real values to
7761 represent these approximations than it would be to use integral values to do
7762 so.  In other ranges, implementations reply on the Bernoulli  distribution to
7763 obtain values.  While TR1's bernoulli_distribution::input_type is specified as
7764 int, we believe this would be better specified as double.
7765 </p>
7766 <p>
7767 This brings us to our main point:  The notion of a random distribution rests
7768 on the notion of a cumulative distribution function, which in turn mathematically
7769 depends on a continuous dependent variable.  Indeed, such a distribution function
7770 would be meaningless if it depended on  discrete values such as integers - and this
7771 remains true even if the distribution function were to take discrete steps.
7772 </p>
7773 <p>
7774 Although this note is specifically about binomial_distribution::input_type,
7775 we intend to recommend that all of the random distributions input_types be
7776 specified as a real type (either a RealType template parameter, or double,
7777 as appropriate).
7778 </p>
7779 <p>
7780 Of the nine distributions in TR1, four already have this characteristic
7781 (uniform_real, exponential_distribution, normal_distribution, and
7782 gamma_distribution).  We have already argued the case for the binomial the
7783 remaining four distributions.
7784 </p>
7785 <p>
7786 In the case of uniform_int, we believe that the calculations to produce an
7787 integer result in a  specified range from an integer in a different specified
7788 range is best done using real arithmetic.  This is because it involves a
7789 product, one of whose terms is the ratio of the extents of the two ranges.
7790 Without real arithmetic, the results become less uniform: some numbers become
7791 more  (or less) probable that they should be.  This is, of course, undesireable
7792 behavior in a uniform distribution.
7793 </p>
7794 <p>
7795 Finally, we believe that in the case of the bernoulli_distribution (briefly
7796 mentioned earlier), as well as the cases of the geometric_distribution and the
7797 poisson_distribution, it would be far more natural to have a real input_type.
7798 This is because the most natural computation involves the  random number
7799 delivered and the distribution's parameter p (in the case of bernoulli_distribution,
7800 for example, the computation is a comparison against p), and p is already specified
7801 in each case as having some real type.
7802 </p>
7803
7804
7805 <p><b>Proposed resolution:</b></p>
7806 <blockquote><pre>typedef  RealType  input_type;
7807 </pre></blockquote>
7808
7809 <p><i>[
7810 Berlin:  Moved to NAD.  N1932 makes this moot: the input_type template parameter has been
7811 eliminated.
7812 ]</i></p>
7813
7814
7815
7816
7817
7818
7819 <hr>
7820 <h3><a name="512"></a>512. Seeding subtract_with_carry_01 from a single unsigned long</h3>
7821 <p><b>Section:</b> 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
7822  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7823 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
7824 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
7825 <p><b>Discussion:</b></p>
7826 <p>
7827 Paragraph 8 specifies the algorithm by which a subtract_with_carry_01  engine
7828 is to be seeded given a single unsigned long.  This algorithm is seriously
7829 flawed in the case where the engine parameter w (also known as word_size)
7830 exceeds 31 [bits].  The key part of the paragraph reads:
7831 </p>
7832 <blockquote><p>
7833 sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1
7834 </p></blockquote>
7835 <p>
7836 and so forth.
7837 </p>
7838 <p>
7839 Since the specified linear congruential engine, lcg, delivers numbers with
7840 a maximum of 2147483563 (just a shade under 31 bits), then when w is, for
7841 example, 48, each of the x(i) will be less than 2**-17.  The consequence
7842 is that roughly the first 400 numbers delivered will be  conspicuously
7843 close to either zero or one.
7844 </p>
7845 <p>
7846 Unfortunately, this is not an innocuous flaw:  One of the predefined engines
7847 in [tr.rand.predef],  namely ranlux64_base_01, has w = 48 and would exhibit
7848 this poor behavior, while the original N1378 proposal states that these
7849 pre-defined engines are intended to be of "known good properties."
7850 </p>
7851
7852
7853 <p><b>Proposed resolution:</b></p>
7854 <p>
7855 In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for
7856 void seed(unsigned long value = 19780503) by
7857 </p>
7858
7859 <blockquote><p>
7860 <i>Effects:</i> If <tt>value == 0</tt>, sets value to <tt>19780503</tt>. In any
7861 case, <del>with a linear congruential generator <tt>lcg</tt>(i) having parameters
7862 <tt><i>m<sub>lcg</sub></i> = 2147483563</tt>, <tt><i>a<sub>lcg</sub></i> = 40014</tt>,
7863 <tt><i>c<sub>lcg</sub></i> = 0</tt>, and <tt><i>lcg</i>(0) = value</tt>,</del>
7864 sets <ins>carry<tt>(-1)</tt> and</ins> <tt>x(-r) &#8230; x(-1)</tt>
7865 <ins>as if executing</ins></p>
7866
7867 <blockquote><pre><ins>
7868 linear_congruential&lt;unsigned long, 40014, 0, 2147483563&gt; lcg(value);
7869 seed(lcg);
7870 </ins></pre></blockquote>
7871
7872 <p>
7873 <del>to <tt>(<i>lcg</i>(1) · 2<sup>-<i>w</i></sup>) mod 1
7874 &#8230; (<i>lcg</i>(<i>r</i>) · 2<sup>-<i>w</i></sup>) mod 1</tt>,
7875 respectively. If <tt><i>x</i>(-1) == 0</tt>, sets carry<tt>(-1) = 2<sup>-<i>w</i></sup></tt>,
7876 else sets carry<tt>(-1) = 0</tt>.</del></p>
7877 </blockquote>
7878
7879 <p><i>[
7880 Jens provided revised wording post Mont Tremblant.
7881 ]</i></p>
7882
7883
7884 <p><i>[
7885 Berlin: N1932 adopts the originally-proposed resolution of the issue.
7886 Jens's supplied wording is a clearer description of what is
7887 intended.  Moved to Ready.
7888 ]</i></p>
7889
7890
7891
7892
7893 <p><b>Rationale:</b></p>
7894 <p>
7895 Jens: I'm using an explicit type here, because fixing the
7896 prose would probably not qualify for the (with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a> even
7897 stricter) requirements we have for seed(Gen&amp;).
7898 </p>
7899
7900 <p><i>[
7901 Portland:  Subsumed by N2111.
7902 ]</i></p>
7903
7904
7905
7906
7907
7908
7909 <hr>
7910 <h3><a name="513"></a>513. Size of state for subtract_with_carry_01</h3>
7911 <p><b>Section:</b> 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
7912  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7913 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
7914 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
7915 <p><b>Discussion:</b></p>
7916 <p>
7917 Paragraph 3 begins:
7918 </p>
7919 <blockquote><p>
7920 The size of the state is r.
7921 </p></blockquote>
7922 <p>
7923 However, this is not quite consistent with the remainder of the paragraph
7924 which specifies a total  of nr+1 items in the textual representation of
7925 the state.  We recommend the sentence be corrected to match:
7926 </p>
7927 <blockquote><p>
7928 The size of the state is nr+1.
7929 </p></blockquote>
7930 <p>
7931 To give meaning to the coefficient n, it may be also desirable to move
7932 n's definition from later in the paragraph.  Either of the following
7933 seem reasonable formulations:
7934 </p>
7935 <blockquote><p>
7936 With n=..., the size of the state is nr+1.
7937 </p></blockquote>
7938 <blockquote><p>
7939 The size of the state is nr+1, where n=... .
7940 </p></blockquote>
7941
7942
7943
7944 <p><b>Proposed resolution:</b></p>
7945 <p><i>[
7946 Jens:  I plead for "NAD" on the grounds that "size of state" is only
7947 used as an argument for big-O complexity notation, thus
7948 constant factors and additions don't count.
7949 ]</i></p>
7950
7951
7952 <p><i>[
7953 Berlin: N1932 adopts the proposed NAD.
7954 ]</i></p>
7955
7956
7957
7958
7959
7960
7961
7962 <hr>
7963 <h3><a name="514"></a>514. Size of state for subtract_with_carry</h3>
7964 <p><b>Section:</b> 26.4.3.3 [rand.eng.sub], TR1 5.1.4.3 [tr.rand.eng.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
7965  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7966 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
7967 <p><b>Discussion:</b></p>
7968 <p>
7969 Paragraph 2 begins:
7970 </p>
7971 <blockquote><p>
7972 The size of the state is r.
7973 </p></blockquote>
7974 <p>
7975 However, the next sentence specifies a total of r+1 items in the textual
7976 representation of the state,  r specific x's as well as a specific carry.
7977 This makes a total of r+1 items that constitute the size of the state,
7978 rather than r.
7979 </p>
7980
7981
7982 <p><b>Proposed resolution:</b></p>
7983 <p>
7984 We recommend the sentence be corrected to match:
7985 </p>
7986 <blockquote><p>
7987  The size of the state is r+1.
7988 </p></blockquote>
7989
7990 <p><i>[
7991 Jens:  I plead for "NAD" on the grounds that "size of state" is only
7992 used as an argument for big-O complexity notation, thus
7993 constant factors and additions don't count.
7994 ]</i></p>
7995
7996
7997 <p><i>[
7998 Berlin: N1932 adopts the proposed NAD.
7999 ]</i></p>
8000
8001
8002
8003
8004
8005
8006
8007 <hr>
8008 <h3><a name="515"></a>515. Random number engine traits</h3>
8009 <p><b>Section:</b> 26.4.2 [rand.synopsis], TR1 5.1.2 [tr.rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8010  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
8011 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</p>
8012 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8013 <p><b>Discussion:</b></p>
8014 <p>
8015 To accompany the concept of a pseudo-random number engine as defined in Table 17,
8016 we propose and recommend an adjunct template, engine_traits, to be declared in
8017 [tr.rand.synopsis] as:
8018 </p>
8019 <blockquote><pre>template&lt; class PSRE &gt;
8020 class engine_traits;
8021 </pre></blockquote>
8022 <p>
8023 This template's primary purpose would be as an aid to generic programming involving
8024 pseudo-random number engines.  Given only the facilities described in tr1, it would
8025 be very difficult to produce any algorithms involving the notion of a generic engine.
8026 The intent of this proposal is to  provide, via engine_traits&lt;&gt;, sufficient
8027 descriptive information to allow an algorithm to employ a pseudo-random number engine
8028 without regard to its exact type, i.e., as a template parameter.
8029 </p>
8030 <p>
8031 For example, today it is not possible to write an efficient generic function that
8032 requires any specific number of random bits.  More specifically, consider a
8033 cryptographic application that internally needs 256 bits of randomness per call:
8034 </p>
8035 <blockquote><pre>template&lt; class Eng, class InIter, class OutIter &gt;
8036 void crypto( Eng&amp; e, InIter in, OutIter out );
8037 </pre></blockquote>
8038 <p>
8039 Without knowning the number of bits of randomness produced per call to a provided
8040 engine, the algorithm has no means of determining how many times to call the engine.
8041 </p>
8042 <p>
8043 In a new section [tr.rand.eng.traits], we proposed to define the engine_traits
8044 template as:
8045 </p>
8046 <blockquote><pre>template&lt; class PSRE &gt;
8047 class engine_traits
8048 {
8049   static  std::size_t  bits_of_randomness = 0u;
8050   static  std::string  name()  { return "unknown_engine"; }
8051   // TODO: other traits here
8052 };
8053 </pre></blockquote>
8054 <p>
8055 Further, each engine described in [tr.rand.engine] would be accompanied by a
8056 complete specialization of this new engine_traits template.
8057 </p>
8058
8059
8060
8061 <p><b>Proposed resolution:</b></p>
8062 <p><i>[
8063 Berlin:  Walter: While useful for implementation per TR1, N1932 has no need for this
8064 feature.  Recommend close as NAD.
8065 ]</i></p>
8066
8067
8068
8069 <p><b>Rationale:</b></p>
8070 <p>
8071 Recommend NAD,
8072 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1932.pdf">N1932</a>,
8073 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
8074 covers this.  Already in WP.
8075 </p>
8076
8077
8078
8079
8080
8081 <hr>
8082 <h3><a name="516"></a>516. Seeding subtract_with_carry_01 using a generator</h3>
8083 <p><b>Section:</b> 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8084  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
8085 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
8086 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8087 <p><b>Discussion:</b></p>
8088 <p>
8089 Paragraph 6 says:
8090 </p>
8091 <blockquote><p>
8092 ... obtained by successive invocations of g, ...
8093 </p></blockquote>
8094 <p>
8095 We recommend instead:
8096 </p>
8097 <blockquote><p>
8098 ... obtained by taking successive invocations of g mod 2**32, ...
8099 </p></blockquote>
8100 <p>
8101 as the context seems to require only 32-bit quantities be used here.
8102 </p>
8103
8104
8105 <p><b>Proposed resolution:</b></p>
8106 <p>
8107 Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7.  Moved to Ready.
8108 </p>
8109
8110 <p><i>[
8111 Portland:  Subsumed by N2111.
8112 ]</i></p>
8113
8114
8115
8116
8117
8118
8119 <hr>
8120 <h3><a name="517"></a>517. Should include name in external representation</h3>
8121 <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#NAD">NAD</a>
8122  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
8123 <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>
8124 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8125 <p><b>Discussion:</b></p>
8126 <p>
8127 The last two rows of Table 16 deal with the i/o requirements of an engine,
8128 specifying that the textual representation of an engine's state,
8129 appropriately formatted, constitute the engine's  external representation.
8130 </p>
8131 <p>
8132 This seems adequate when an engine's type is known.  However, it seems
8133 inadequate in the  context of generic code, where it becomes useful and
8134 perhaps even necessary to determine an engine's type via input.
8135 </p>
8136 <p>
8137 </p>
8138
8139
8140 <p><b>Proposed resolution:</b></p>
8141 <p>
8142 We therefore recommend that, in each of these two rows of Table 16, the
8143 text "textual representation" be expanded so as to read "engine name
8144 followed by the textual representation."
8145 </p>
8146
8147 <p><i>[
8148 Berlin: N1932 considers this NAD. This is a QOI issue.
8149 ]</i></p>
8150
8151
8152
8153
8154
8155
8156
8157 <hr>
8158 <h3><a name="525"></a>525. type traits definitions not clear</h3>
8159 <p><b>Section:</b> 20.4.4 [meta.unary], TR1 4.5 [tr.meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8160  <b>Submitter:</b> Robert Klarer <b>Date:</b> 2005-07-11</p>
8161 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8162 <p><b>Discussion:</b></p>
8163 <p>
8164 It is not completely clear how the primary type traits deal with
8165 cv-qualified types.  And several of the secondary type traits
8166 seem to be lacking a definition.
8167 </p>
8168
8169 <p><i>[
8170 Berlin:  Howard to provide wording.
8171 ]</i></p>
8172
8173
8174
8175 <p><b>Proposed resolution:</b></p>
8176 <p>
8177 Wording provided in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2028.html">N2028</a>.
8178 A
8179 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a>
8180 provides more detail for motivation.
8181 </p>
8182
8183
8184 <p><b>Rationale:</b></p>
8185 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a>
8186 in the WP.
8187
8188
8189
8190
8191
8192 <hr>
8193 <h3><a name="526"></a>526. Is it undefined if a function in the standard changes in parameters?</h3>
8194 <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#NAD">NAD</a>
8195  <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2005-09-14</p>
8196 <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>
8197 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8198 <p><b>Discussion:</b></p>
8199 <p>
8200 Problem: There are a number of places in the C++ standard library where
8201 it is possible to write what appear to be sensible ways of calling
8202 functions, but which can cause problems in some (or all)
8203 implementations, as they cause the values given to the function to be
8204 changed in a way not specified in standard (and therefore not coded to
8205 correctly work). These fall into two similar categories.
8206 </p>
8207
8208 <p>
8209 1) Parameters taken by const reference can be changed during execution
8210 of the function
8211 </p>
8212
8213 <p>
8214 Examples:
8215 </p>
8216
8217 <p>
8218 Given std::vector&lt;int&gt; v:
8219 </p>
8220 <p>
8221 v.insert(v.begin(), v[2]);
8222 </p>
8223 <p>
8224 v[2] can be changed by moving elements of vector
8225 </p>
8226
8227
8228 <p>
8229 Given std::list&lt;int&gt; l:
8230 </p>
8231 <p>
8232 l.remove(*l.begin());
8233 </p>
8234 <p>
8235 Will delete the first element, and then continue trying to access it.
8236 This is particularily vicious, as it will appear to work in almost all
8237 cases.
8238 </p>
8239
8240 <p>
8241 2) A range is given which changes during the execution of the function:
8242 Similarly,
8243 </p>
8244
8245 <p>
8246 v.insert(v.begin(), v.begin()+4, v.begin()+6);
8247 </p>
8248
8249 <p>
8250 This kind of problem has been partly covered in some cases. For example
8251 std::copy(first, last, result) states that result cannot be in the range
8252 [first, last). However, does this cover the case where result is a
8253 reverse_iterator built from some iterator in the range [first, last)?
8254 Also, std::copy would still break if result was reverse_iterator(last +
8255 1), yet this is not forbidden by the standard
8256 </p>
8257
8258 <p>
8259 Solution:
8260 </p>
8261
8262 <p>
8263 One option would be to try to more carefully limit the requirements of
8264 each function. There are many functions which would have to be checked.
8265 However as has been shown in the std::copy case, this may be difficult.
8266 A simpler, more global option would be to somewhere insert text similar to:
8267 </p>
8268
8269 <p>
8270 If the execution of any function would change either any values passed
8271 by reference or any value in any range passed to a function in a way not
8272 defined in the definition of that function, the result is undefined.
8273 </p>
8274
8275 <p>
8276 Such code would have to at least cover chapters 23 and 25 (the sections
8277 I read through carefully). I can see no harm on applying it to much of
8278 the rest of the standard.
8279 </p>
8280
8281 <p>
8282 Some existing parts of the standard could be improved to fit with this,
8283 for example the requires for 25.2.1 (Copy) could be adjusted to:
8284 </p>
8285
8286 <p>
8287 Requires: For each non-negative integer n &lt; (last - first), assigning to
8288 *(result + n) must not alter any value in the range [first + n, last).
8289 </p>
8290
8291 <p>
8292 However, this may add excessive complication.
8293 </p>
8294
8295 <p>
8296 One other benefit of clearly introducing this text is that it would
8297 allow a number of small optimisations, such as caching values passed
8298 by const reference.
8299 </p>
8300
8301 <p>
8302 Matt Austern adds that this issue also exists for the <tt>insert</tt> and
8303 <tt>erase</tt> members of the ordered and unordered associative containers.
8304 </p>
8305
8306 <p><i>[
8307 Berlin: Lots of controversey over how this should be solved. Lots of confusion
8308 as to whether we're talking about self referencing iterators or references.
8309 Needs a good survey as to the cases where this matters, for which
8310 implementations, and how expensive it is to fix each case.
8311 ]</i></p>
8312
8313
8314
8315
8316 <p><b>Proposed resolution:</b></p>
8317
8318
8319 <p><b>Rationale:</b></p>
8320 <p>
8321 Recommend NAD.
8322 </p>
8323 <ul>
8324 <li><tt>vector::insert(iter, value)</tt> is required to work because the standard
8325 doesn't give permission for it not to work.</li>
8326 <li><tt>list::remove(value)</tt> is required to work because the standard
8327 doesn't give permission for it not to work.</li>
8328 <li><tt>vector::insert(iter, iter, iter)</tt> is not required to work because
8329 23.1.1 [sequence.reqmts], p4 says so.</li>
8330 <li><tt>copy</tt> has to work, except where 25.2.1 [alg.copy] says
8331 it doesn't have to work.  While a language lawyer can tear this wording apart,
8332 it is felt that the wording is not prone to accidental interpretation.</li>
8333 <li>The current working draft provide exceptions for the unordered associative
8334 containers similar to the containers requirements which exempt the member
8335 template insert functions from self referencing.</li>
8336 </ul>
8337
8338
8339
8340
8341
8342 <hr>
8343 <h3><a name="528"></a>528. <tt>const_iterator</tt> <tt>iterator</tt> issue when they are the same type</h3>
8344 <p><b>Section:</b> 23.4 [unord], TR1 6.3.4 [tr.unord.unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8345  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2005-10-12</p>
8346 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p>
8347 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p>
8348 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8349 <p><b>Discussion:</b></p>
8350 <p>
8351 while implementing the resolution of issue 6.19 I'm noticing the
8352 following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and
8353 unordered_multiset:
8354 </p>
8355
8356 <blockquote><p>
8357     "The iterator and const_iterator types are both const types. It is
8358 unspecified whether they are the same type"
8359 </p></blockquote>
8360
8361 <p>
8362 Now, according to the resolution of 6.19, we have overloads of insert
8363 with hint and erase (single and range) both for iterator and
8364 const_iterator, which, AFAICS, can be meaningful at the same time *only*
8365 if iterator and const_iterator *are* in fact different types.
8366 </p>
8367 <p>
8368 Then, iterator and const_iterator are *required* to be different types?
8369 Or that is an unintended consequence? Maybe the overloads for plain
8370 iterators should be added only to unordered_map and unordered_multimap?
8371 Or, of course, I'm missing something?
8372 </p>
8373
8374
8375
8376 <p><b>Proposed resolution:</b></p>
8377 <p>
8378 Add to 6.3.4.3p2 (and 6.3.4.5p2):
8379 </p>
8380 <p>
8381 2  ... The iterator and const_iterator types are both <del>const</del>
8382 <ins>constant</ins> iterator types.
8383 It is unspecified whether they are the same type.
8384 </p>
8385
8386 <p>
8387 Add a new subsection to 17.4.4 [lib.conforming]:
8388 </p>
8389
8390 <blockquote>
8391 <p>
8392 An implementation shall not supply an overloaded function
8393        signature specified in any library clause if such a signature
8394        would be inherently ambiguous during overload resolution
8395        due to two library types referring to the same type.
8396 </p>
8397 <p>
8398        [Note: For example, this occurs when a container's iterator
8399        and const_iterator types are the same. -- end note]
8400 </p>
8401 </blockquote>
8402
8403 <p><i>[
8404 Post-Berlin: Beman supplied wording.
8405 ]</i></p>
8406
8407
8408
8409
8410 <p><b>Rationale:</b></p>
8411 Toronto:  The first issue has been fixed by N2350 (the insert and erase members
8412 are collapsed into one signature).  Alisdair to open a separate issue on the
8413 chapter 17 wording.
8414
8415
8416
8417
8418
8419 <hr>
8420 <h3><a name="532"></a>532. Tuple comparison</h3>
8421 <p><b>Section:</b> 20.3.1.5 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
8422  <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-11-29</p>
8423 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
8424 <p><b>Discussion:</b></p>
8425 <p>
8426 Where possible, tuple comparison operators &lt;,&lt;=,=&gt;, and &gt; ought to be
8427 defined in terms of std::less rather than operator&lt;, in order to
8428 support comparison of tuples of pointers.
8429 </p>
8430
8431
8432 <p><b>Proposed resolution:</b></p>
8433 <p>
8434 change 6.1.3.5/5 from:
8435 </p>
8436
8437 <blockquote><p>
8438   Returns: The result of a lexicographical comparison between t and
8439   u. The result is defined as: (bool)(get&lt;0&gt;(t) &lt; get&lt;0&gt;(u)) ||
8440   (!(bool)(get&lt;0&gt;(u) &lt; get&lt;0&gt;(t)) &amp;&amp; ttail &lt; utail), where rtail for
8441   some tuple r is a tuple containing all but the first element of
8442   r. For any two zero-length tuples e and f, e &lt; f returns false.
8443 </p></blockquote>
8444
8445 <p>
8446 to:
8447 </p>
8448
8449 <blockquote>
8450 <p>
8451   Returns: The result of a lexicographical comparison between t and
8452   u. For any two zero-length tuples e and f, e &lt; f returns false.
8453   Otherwise, the result is defined as: cmp( get&lt;0&gt;(t), get&lt;0&gt;(u)) ||
8454   (!cmp(get&lt;0&gt;(u), get&lt;0&gt;(t)) &amp;&amp; ttail &lt; utail), where rtail for some
8455   tuple r is a tuple containing all but the first element of r, and
8456   cmp(x,y) is an unspecified function template defined as follows.
8457 </p>
8458 <p>
8459   Where T is the type of x and U is the type of y:
8460 </p>
8461
8462 <p>
8463      if T and U are pointer types and T is convertible to U, returns
8464      less&lt;U&gt;()(x,y)
8465 </p>
8466
8467 <p>
8468      otherwise, if T and U are pointer types, returns less&lt;T&gt;()(x,y)
8469 </p>
8470
8471 <p>
8472      otherwise, returns (bool)(x &lt; y)
8473 </p>
8474 </blockquote>
8475
8476 <p><i>[
8477 Berlin: This issue is much bigger than just tuple (pair, containers,
8478 algorithms). Dietmar will survey and work up proposed wording.
8479 ]</i></p>
8480
8481
8482
8483
8484 <p><b>Rationale:</b></p>
8485 <p>
8486 Recommend NAD.  This will be fixed with the next revision of concepts.
8487 </p>
8488
8489
8490
8491
8492
8493 <hr>
8494 <h3><a name="536"></a>536. Container iterator constructor and explicit convertibility</h3>
8495 <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#Dup">Dup</a>
8496  <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2005-12-17</p>
8497 <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>
8498 <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>
8499 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
8500 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a></p>
8501 <p><b>Discussion:</b></p>
8502 <p>
8503 The iterator constructor X(i,j) for containers as defined in 23.1.1 and
8504 23.2.2 does only require that i and j be input iterators but
8505 nothing is said about their associated value_type. There are three
8506 sensible
8507 options:
8508 </p>
8509 <ol>
8510 <li>iterator's value_type is exactly X::value_type (modulo cv).</li>
8511 <li>iterator's value_type is *implicitly* convertible to X::value_type.</li>
8512 <li>iterator's value_type is *explicitly* convertible to X::value_type.</li>
8513 </ol>
8514 <p>
8515 The issue has practical implications, and stdlib vendors have
8516 taken divergent approaches to it: Dinkumware follows 2,
8517 libstdc++ follows 3.
8518 </p>
8519 <p>
8520 The same problem applies to the definition of insert(p,i,j) for
8521 sequences and insert(i,j) for associative contianers, as well as
8522 assign.
8523 </p>
8524
8525 <p><i>[
8526 The following added by Howard and the example code was originally written by
8527 Dietmar.
8528 ]</i></p>
8529
8530 <p>
8531 Valid code below?
8532 </p>
8533
8534 <blockquote><pre>#include &lt;vector&gt;
8535 #include &lt;iterator&gt;
8536 #include &lt;iostream&gt;
8537
8538 struct foo
8539 {
8540     explicit foo(int) {}
8541 };
8542
8543 int main()
8544 {
8545     std::vector&lt;int&gt; v_int;
8546     std::vector&lt;foo&gt; v_foo1(v_int.begin(), v_int.end());
8547     std::vector&lt;foo&gt; v_foo2((std::istream_iterator&lt;int&gt;(std::cin)),
8548                              std::istream_iterator&lt;int&gt;());
8549 }
8550 </pre></blockquote>
8551 <p><i>[
8552 Berlin: Some support, not universal, for respecting the explicit qualifier.
8553 ]</i></p>
8554
8555
8556
8557
8558 <p><b>Proposed resolution:</b></p>
8559
8560
8561
8562
8563
8564
8565 <hr>
8566 <h3><a name="544"></a>544. minor NULL problems in C.2</h3>
8567 <p><b>Section:</b> C.2 [diff.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8568  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-11-25</p>
8569 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8570 <p><b>Discussion:</b></p>
8571 <p>
8572 According to C.2.2.3, p1, "the macro NULL, defined in any of &lt;clocale&gt;,
8573 &lt;cstddef&gt;, &lt;cstdio&gt;, &lt;cstdlib&gt;, &lt;cstring&gt;, &lt;ctime&gt;,
8574 or &lt;cwchar&gt;." This is consistent with the C standard.
8575 </p>
8576 <p>
8577 However, Table 95 in C.2 fails to mention &lt;clocale&gt; and &lt;cstdlib&gt;.
8578 </p>
8579 <p>
8580 In addition, C.2, p2 claims that "The C++ Standard library provides
8581 54 standard macros from the C library, as shown in Table 95." While
8582 table 95 does have 54 entries, since a couple of them (including the
8583 NULL macro) are listed more than once, the actual number of macros
8584 defined by the C++ Standard Library may not be 54.
8585 </p>
8586
8587
8588 <p><b>Proposed resolution:</b></p>
8589 <p>
8590 I propose we add &lt;clocale&gt; and &lt;cstdlib&gt; to Table 96 and remove the
8591 number of macros from C.2, p2 and reword the sentence as follows:
8592 </p>
8593 <blockquote><p>
8594 The C++ Standard library <del>provides 54 standard macros from</del>
8595 <ins>defines a number macros corresponding to those defined by</ins> the C
8596 <ins>Standard</ins> library, as shown in Table 96.
8597 </p></blockquote>
8598
8599 <p><i>[
8600 Portland:  Resolution is considered editorial.  It will be incorporated into the WD.
8601 ]</i></p>
8602
8603
8604
8605
8606
8607
8608
8609 <hr>
8610 <h3><a name="547"></a>547. division should be floating-point, not integer</h3>
8611 <p><b>Section:</b> 26.4 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8612  <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
8613 <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>
8614 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8615 <p><b>Discussion:</b></p>
8616 <p>
8617 Paragraph 10 describes how a variate generator uses numbers produced by an
8618 engine to pass to a generator. The sentence that concerns me is: "Otherwise, if
8619 the value for engine_value_type::result_type is true and the value for
8620 Distribution::input_type is false [i.e. if the engine produces integers and the
8621 engine wants floating-point values], then the numbers in s_eng are divided by
8622 engine().max() - engine().min() + 1 to obtain the numbers in s_e." Since the
8623 engine is producing integers, both the numerator and the denominator are
8624 integers and we'll be doing integer division, which I don't think is what we
8625 want. Shouldn't we be performing a conversion to a floating-point type first?
8626 </p>
8627
8628
8629 <p><b>Proposed resolution:</b></p>
8630
8631
8632 <p><b>Rationale:</b></p>
8633 <p>
8634 Recommend NAD as the affected section is now gone and so the issue is moot.
8635 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>.
8636 </p>
8637
8638
8639
8640
8641
8642 <hr>
8643 <h3><a name="548"></a>548. May random_device block?</h3>
8644 <p><b>Section:</b> 26.4.6 [rand.device], TR1 5.1.6 [tr.rand.device] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8645  <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
8646 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8647 <p><b>Discussion:</b></p>
8648 <p>
8649 Class random_device "produces non-deterministic random numbers", using some
8650 external source of entropy. In most real-world systems, the amount of available
8651 entropy is limited. Suppose that entropy has been exhausted. What is an
8652 implementation permitted to do? In particular, is it permitted to block
8653 indefinitely until more random bits are available, or is the implementation
8654 required to detect failure immediately? This is not an academic question. On
8655 Linux a straightforward implementation would read from /dev/random, and "When
8656 the entropy pool is empty, reads to /dev/random will block until additional
8657 environmental noise is gathered." Programmers need to know whether random_device
8658 is permitted to (or possibly even required to?) behave the same way.
8659 </p>
8660
8661 <p><i>[
8662 Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin
8663 may block?
8664 ]</i></p>
8665
8666
8667 <p>
8668 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
8669 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
8670 for some further discussion.
8671 </p>
8672
8673
8674 <p><b>Proposed resolution:</b></p>
8675 <p>
8676 Adopt the proposed resolution in
8677 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> (NAD).
8678 </p>
8679
8680
8681
8682
8683
8684 <hr>
8685 <h3><a name="549"></a>549. Undefined variable in binomial_distribution</h3>
8686 <p><b>Section:</b> 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8687  <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
8688 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</p>
8689 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8690 <p><b>Discussion:</b></p>
8691 <p>
8692 Paragraph 1 says that "A binomial distributon random distribution produces
8693 integer values i&gt;0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t and
8694 p are the parameters of the distribution. OK, that tells us what t, p, and i
8695 are. What's n?
8696 </p>
8697
8698
8699 <p><b>Proposed resolution:</b></p>
8700 <p>
8701 Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1.
8702 </p>
8703
8704 <p><i>[
8705 Portland:  Subsumed by N2111.
8706 ]</i></p>
8707
8708
8709
8710
8711
8712
8713 <hr>
8714 <h3><a name="553"></a>553. very minor editorial change intptr_t / uintptr_t</h3>
8715 <p><b>Section:</b> 18.3.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8716  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-01-30</p>
8717 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8718 <p><b>Discussion:</b></p>
8719 <p>
8720 In the synopsis, some types are identified as optional: int8_t, int16_t,
8721 and so on, consistently with C99, indeed.
8722 </p>
8723 <p>
8724 On the other hand, intptr_t and uintptr_t, are not marked as such and
8725 probably should, consistently with C99, 7.18.1.4.
8726 </p>
8727
8728
8729 <p><b>Proposed resolution:</b></p>
8730 <p>
8731 Change 18.3.1 [cstdint.syn]:
8732 </p>
8733
8734 <blockquote><pre>...
8735 typedef <i>signed integer type</i> intptr_t;    <ins><i>// optional</i></ins>
8736 ...
8737 typedef <i>unsigned integer type</i> uintptr_t;    <ins><i>// optional</i></ins>
8738 ...
8739 </pre></blockquote>
8740
8741
8742
8743 <p><b>Rationale:</b></p>
8744 Recommend NAD and fix as editorial with the proposed resolution.
8745
8746
8747
8748
8749
8750 <hr>
8751 <h3><a name="554"></a>554. Problem with lwg DR 184 numeric_limits&lt;bool&gt;</h3>
8752 <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#NAD">NAD</a>
8753  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-29</p>
8754 <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>
8755 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8756 <p><b>Discussion:</b></p>
8757 <p>
8758 I believe we have a bug in the resolution of:
8759 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">lwg 184</a>
8760 (WP status).
8761 </p>
8762
8763 <p>
8764 The resolution spells out each member of <tt>numeric_limits&lt;bool&gt;</tt>.
8765 The part I'm having a little trouble with is:
8766 </p>
8767 <blockquote><pre>static const bool traps = false;
8768 </pre></blockquote>
8769
8770 <p>
8771 Should this not be implementation defined?  Given:
8772 </p>
8773
8774 <blockquote><pre>int main()
8775 {
8776      bool b1 = true;
8777      bool b2 = false;
8778      bool b3 = b1/b2;
8779 }
8780 </pre></blockquote>
8781
8782 <p>
8783 If this causes a trap, shouldn't <tt>numeric_limits&lt;bool&gt;::traps</tt> be
8784 <tt>true</tt>?
8785 </p>
8786
8787
8788 <p><b>Proposed resolution:</b></p>
8789 <p>
8790 Change 18.2.1.5p3:
8791 </p>
8792
8793 <blockquote><p>
8794 -3- The specialization for <tt>bool</tt> shall be provided as follows: </p>
8795 <blockquote><pre>namespace std {
8796    template &lt;&gt; class numeric_limits&lt;bool&gt; {
8797       ...
8798       static const bool traps = <del>false</del> <ins><i>implementation-defined</i></ins>;
8799       ...
8800    };
8801 }
8802 </pre></blockquote>
8803 </blockquote>
8804
8805 <p><i>[
8806 Redmond:  NAD because traps refers to values, not operations.  There is no bool
8807 value that will trap.
8808 ]</i></p>
8809
8810
8811
8812
8813
8814
8815
8816 <hr>
8817 <h3><a name="555"></a>555. TR1, 8.21/1: typo</h3>
8818 <p><b>Section:</b> TR1 8.21 [tr.c99.boolh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8819  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-02</p>
8820 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8821 <p><b>Discussion:</b></p>
8822 <p>
8823 This one, if nobody noticed it yet, seems really editorial:
8824 s/cstbool/cstdbool/
8825 </p>
8826
8827
8828 <p><b>Proposed resolution:</b></p>
8829 <p>
8830 Change 8.21p1:
8831 </p>
8832 <blockquote><p>
8833 -1- The header behaves as if it defines the additional macro defined in
8834 <tt>&lt;cst<ins>d</ins>bool&gt;</tt> by including the header <tt>&lt;cstdbool&gt;</tt>.
8835 </p></blockquote>
8836
8837 <p><i>[
8838 Redmond:  Editorial.
8839 ]</i></p>
8840
8841
8842
8843
8844
8845
8846
8847 <hr>
8848 <h3><a name="558"></a>558. lib.input.iterators Defect</h3>
8849 <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#NAD%20Editorial">NAD Editorial</a>
8850  <b>Submitter:</b> David Abrahams <b>Date:</b> 2006-02-09</p>
8851 <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>
8852 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8853 <p><b>Discussion:</b></p>
8854 <blockquote>
8855 <p>
8856   24.1.1 Input iterators [lib.input.iterators]
8857 </p>
8858 <p>
8859   1 A class or a built-in type X satisfies the requirements of an
8860   input iterator for the value type T if the following expressions are
8861   valid, where U is the type of any specified member of type T, as
8862   shown in Table 73.
8863 </p>
8864 </blockquote>
8865 <p>
8866 There is no capital U used in table 73.  There is a lowercase u, but
8867 that is clearly not meant to denote a member of type T.  Also, there's
8868 no description in 24.1.1 of what lowercase a means.  IMO the above
8869 should have been...Hah, a and b are already covered in 24.1/11, so maybe it
8870 should have just been:
8871 </p>
8872
8873
8874 <p><b>Proposed resolution:</b></p>
8875 <p>
8876 Change 24.1.1p1:
8877 </p>
8878 <blockquote><p>
8879 -1- A class or a built-in type <tt>X</tt> satisfies the requirements of an
8880 input iterator for the value type <tt>T</tt> if the following expressions
8881 are valid<del>, where <tt>U</tt> is the type of any specified member of type
8882 <tt>T</tt>,</del> as shown in Table 73.
8883 </p></blockquote>
8884
8885 <p><i>[
8886 Portland: Editorial.
8887 ]</i></p>
8888
8889
8890
8891
8892
8893
8894
8895 <hr>
8896 <h3><a name="560"></a>560. User-defined allocators without default constructor</h3>
8897 <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#NAD">NAD</a>
8898  <b>Submitter:</b> Sergey P. Derevyago <b>Date:</b> 2006-02-17</p>
8899 <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>
8900 <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>
8901 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8902 <p><b>Discussion:</b></p>
8903 <h4>1. The essence of the problem.</h4>
8904 <p>
8905 User-defined allocators without default constructor are not explicitly
8906 supported by the standard but they can be supported just like std::vector
8907 supports elements without default constructor.
8908 </p>
8909 <p>
8910 As a result, there exist implementations that work well with such allocators
8911 and implementations that don't.
8912 </p>
8913
8914 <h4>2. The cause of the problem.</h4>
8915 <p>
8916 1) The standard doesn't explicitly state this intent but it should. In
8917 particular, 20.1.5p5 explicitly state the intent w.r.t. the allocator
8918 instances that compare non-equal. So it can similarly state the intent w.r.t.
8919 the user-defined allocators without default constructor.
8920 </p>
8921 <p>
8922 2) Some container operations are obviously underspecified. In particular,
8923 21.3.7.1p2 tells:
8924 </p>
8925 <blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
8926   basic_string&lt;charT,traits,Allocator&gt; operator+(
8927     const charT* lhs,
8928     const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs
8929   );
8930 </pre>
8931 <p>
8932 Returns: <tt>basic_string&lt;charT,traits,Allocator&gt;(lhs) + rhs</tt>.
8933 </p>
8934 </blockquote>
8935 <p>
8936 That leads to the basic_string&lt;charT,traits,Allocator&gt;(lhs, Allocator()) call.
8937 Obviously, the right requirement is:
8938 </p>
8939 <blockquote><p>
8940 Returns: <tt>basic_string&lt;charT,traits,Allocator&gt;(lhs, rhs.get_allocator()) + rhs</tt>.
8941 </p></blockquote>
8942 <p>
8943 It seems like a lot of DRs can be submitted on this "Absent call to
8944 get_allocator()" topic.
8945 </p>
8946
8947 <h4>3. Proposed actions.</h4>
8948 <p>
8949 1) Explicitly state the intent to allow for user-defined allocators without
8950 default constructor in 20.1.5 Allocator requirements.
8951 </p>
8952 <p>
8953 2) Correct all the places, where a correct allocator object is available
8954 through the get_allocator() call but default Allocator() gets passed instead.
8955 </p>
8956 <h4>4. Code sample.</h4>
8957 <p>
8958 Let's suppose that the following memory pool is available:
8959 </p>
8960 <blockquote><pre>class mem_pool {
8961       // ...
8962       void* allocate(size_t size);
8963       void deallocate(void* ptr, size_t size);
8964 };
8965 </pre></blockquote>
8966 <p>
8967 So the following allocator can be implemented via this pool:
8968 </p>
8969 <blockquote><pre>class stl_allocator {
8970       mem_pool&amp; pool;
8971
8972  public:
8973       explicit stl_allocator(mem_pool&amp; mp) : pool(mp) {}
8974       stl_allocator(const stl_allocator&amp; sa) : pool(sa.pool) {}
8975       template &lt;class U&gt;
8976       stl_allocator(const stl_allocator&lt;U&gt;&amp; sa)  : pool(sa.get_pool()) {}
8977       ~stl_allocator() {}
8978
8979       pointer allocate(size_type n, std::allocator&lt;void&gt;::const_pointer = 0)
8980       {
8981        return (n!=0) ? static_cast&lt;pointer&gt;(pool.allocate(n*sizeof(T))) : 0;
8982       }
8983
8984       void deallocate(pointer p, size_type n)
8985       {
8986        if (n!=0) pool.deallocate(p, n*sizeof(T));
8987       }
8988
8989       // ...
8990 };
8991 </pre></blockquote>
8992 <p>
8993 Then the following code works well on some implementations and doesn't work on
8994 another:
8995 </p>
8996 <blockquote><pre>typedef basic_string&lt;char, char_traits&lt;char&gt;, stl_allocator&lt;char&gt; &gt;
8997   tl_string;
8998 mem_pool mp;
8999 tl_string s1("abc", stl_allocator&lt;int&gt;(mp));
9000 printf("(%s)\n", ("def"+s1).c_str());
9001 </pre></blockquote>
9002 <p>
9003 In particular, on some implementations the code can't be compiled without
9004 default stl_allocator() constructor.
9005 </p>
9006 <p>
9007 The obvious way to solve the compile-time problems is to intentionally define
9008 a NULL pointer dereferencing default constructor
9009 </p>
9010 <blockquote><pre>stl_allocator() : pool(*static_cast&lt;mem_pool*&gt;(0)) {}
9011 </pre></blockquote>
9012 <p>
9013 in a hope that it will not be called. The problem is that it really gets
9014 called by operator+(const char*, const string&amp;) under the current 21.3.7.1p2
9015 wording.
9016 </p>
9017
9018
9019 <p><b>Proposed resolution:</b></p>
9020 <p>
9021 </p>
9022
9023
9024 <p><b>Rationale:</b></p>
9025 <p>
9026 Recommend NAD.  <tt>operator+()</tt> with <tt>string</tt> already requires the desired
9027 semantics of copying the allocator from one of the strings (<i>lhs</i> when there is a choice).
9028 </p>
9029
9030
9031
9032
9033
9034 <hr>
9035 <h3><a name="569"></a>569. Postcondition for basic_ios::clear(iostate) incorrectly stated</h3>
9036 <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#Dup">Dup</a>
9037  <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 2006-03-10</p>
9038 <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>
9039 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
9040 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a></p>
9041 <p><b>Discussion:</b></p>
9042 <p>
9043 Section: 27.4.4.3 [lib.iostate.flags]
9044 </p>
9045 <p>
9046 Paragraph 4 says:
9047 </p>
9048 <blockquote>
9049 <blockquote><pre>void clear(iostate <i>state</i> = goodbit);
9050 </pre></blockquote>
9051 <p>
9052 <i>Postcondition:</i> If <tt>rdbuf()!=0</tt> then <tt><i>state</i> == rdstate();</tt>
9053 otherwise <tt>rdstate()==<i>state</i>|ios_base::badbit</tt>.
9054 </p>
9055 </blockquote>
9056
9057 <p>
9058 The postcondition "rdstate()==state|ios_base::badbit" is parsed as
9059 "(rdstate()==state)|ios_base::badbit", which is probably what the
9060 committee meant.
9061 </p>
9062
9063
9064
9065
9066 <p><b>Rationale:</b></p>
9067
9068
9069
9070
9071
9072
9073 <hr>
9074 <h3><a name="571"></a>571. Update C90 references to C99?</h3>
9075 <p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9076  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-08</p>
9077 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p>
9078 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9079 <p><b>Discussion:</b></p>
9080 <p>
9081 1.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC
9082 9899:1990, Programming languages - C. Should that be changed to ISO/IEC
9083 9899:1999?
9084 </p>
9085 <p>
9086 What impact does this have on the library?
9087 </p>
9088
9089
9090 <p><b>Proposed resolution:</b></p>
9091 <p>
9092 In 1.2/1 [intro.refs] of the WP, change:
9093 </p>
9094 <blockquote>
9095 <ul>
9096 <li>ISO/IEC 9899:<del>1990</del><ins>1999 + TC1 + TC2</ins>, <i>Programming languages - C</i></li>
9097 </ul>
9098 </blockquote>
9099
9100
9101
9102 <p><b>Rationale:</b></p>
9103 Recommend NAD, fixed editorially.
9104
9105
9106
9107
9108
9109 <hr>
9110 <h3><a name="572"></a>572. Oops, we gave 507 WP status</h3>
9111 <p><b>Section:</b> 26.4 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9112  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-04-11</p>
9113 <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>
9114 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9115 <p><b>Discussion:</b></p>
9116 <p>
9117 In Berlin, as a working group, we voted in favor of N1932 which makes issue 507 moot:
9118 variate_generator has been eliminated.  Then in full committee we voted to give
9119 this issue WP status (mistakenly).
9120 </p>
9121
9122
9123 <p><b>Proposed resolution:</b></p>
9124 <p>
9125 Strike the proposed resolution of issue 507.
9126 </p>
9127 <p><i>[
9128 post-Portland:  Walter and Howard recommend NAD.  The proposed resolution of 507 no longer
9129 exists in the current WD.
9130 ]</i></p>
9131
9132
9133
9134 <p><b>Rationale:</b></p>
9135 <p>
9136 NAD.  Will be moot once
9137 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2135.pdf">N2135</a>
9138 is adopted.
9139 </p>
9140
9141
9142
9143
9144
9145 <hr>
9146 <h3><a name="583"></a>583. div() for unsigned integral types</h3>
9147 <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#NAD">NAD</a>
9148  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-06-15</p>
9149 <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>
9150 <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>
9151 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9152 <p><b>Discussion:</b></p>
9153 <p>
9154 There is no div() function for unsigned integer types.
9155 </p>
9156 <p>
9157 There are several possible resolutions.  The simplest one is noted below.  Other
9158 possibilities include a templated solution.
9159 </p>
9160
9161
9162 <p><b>Proposed resolution:</b></p>
9163 <p>
9164 Add to 26.7 [lib.c.math] paragraph 8:
9165 </p>
9166
9167 <blockquote><pre>struct udiv_t div(unsigned, unsigned);
9168 struct uldiv_t div(unsigned long, unsigned long);
9169 struct ulldiv_t div(unsigned long long, unsigned long long);
9170 </pre></blockquote>
9171
9172
9173
9174 <p><b>Rationale:</b></p>
9175 Toronto:  C99 does not have these unsigned versions because
9176 the signed version exist just to define the implementation-defined behavior
9177 of signed integer division.  Unsigned integer division has no implementation-defined
9178 behavior and thus does not need this treatment.
9179
9180
9181
9182
9183
9184 <hr>
9185 <h3><a name="584"></a>584. missing int pow(int,int) functionality</h3>
9186 <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#NAD">NAD</a>
9187  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-06-15</p>
9188 <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>
9189 <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>
9190 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9191 <p><b>Discussion:</b></p>
9192 <p>
9193 There is no pow() function for any integral type.
9194 </p>
9195
9196
9197 <p><b>Proposed resolution:</b></p>
9198 <p>
9199 Add something like:
9200 </p>
9201
9202 <blockquote><pre>template&lt; typename T&gt;
9203 T power( T x, int n );
9204 // requires: n &gt;=0
9205 </pre></blockquote>
9206
9207
9208 <p><b>Rationale:</b></p>
9209 Toronto:  We already have double pow(integral, integral) from 26.7 [c.math] p11.
9210
9211
9212
9213
9214
9215 <hr>
9216 <h3><a name="587"></a>587. iststream ctor missing description</h3>
9217 <p><b>Section:</b> D.7.2.1 [depr.istrstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9218  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-22</p>
9219 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9220 <p><b>Discussion:</b></p>
9221         <p>
9222
9223 The  <code>iststream(char*, streamsize)</code>  ctor is  in  the class
9224 synopsis  in D.7.2  but its  signature is  missing in  the description
9225 below (in D.7.2.1).
9226
9227         </p>
9228
9229
9230     <p><b>Proposed resolution:</b></p>
9231         <p>
9232
9233 This seems like a simple editorial issue and the missing signature can
9234 be added to the one for <code>const char*</code> in paragraph 2.
9235
9236         </p>
9237
9238 <p><i>[
9239 post Oxford: Noted that it is already fixed in
9240 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
9241 ]</i></p>
9242
9243
9244
9245
9246
9247
9248 <hr>
9249 <h3><a name="590"></a>590. Type traits implementation latitude should be removed for C++0x</h3>
9250 <p><b>Section:</b> 20.4 [meta], TR1 4.9 [tr.meta.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9251  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-08-10</p>
9252 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
9253 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9254 <p><b>Discussion:</b></p>
9255 <p>
9256 20.4.9 [lib.meta.req], Implementation requirements, provides latitude for type
9257 traits implementers that is not needed in C++0x. It includes the wording:
9258 </p>
9259
9260 <blockquote><p>
9261 [<i>Note:</i> the latitude granted to implementers in this clause is temporary,
9262 and is expected to be removed in future revisions of this document. -- <i>end note</i>]
9263 </p></blockquote>
9264
9265 <p>
9266 Note:
9267 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">N2157: Minor Modifications to the type traits Wording</a>
9268 also has the intent of removing this wording from the WP.
9269 </p>
9270
9271
9272
9273 <p><b>Proposed resolution:</b></p>
9274 <p>
9275 Remove 20.4.9 [lib.meta.req] in its entirety from the WP.
9276 </p>
9277
9278 <p><i>[
9279 post-Oxford: Recommend NAD Editorial.  This resolution is now in the
9280 current working draft.
9281 ]</i></p>
9282
9283
9284
9285
9286
9287
9288
9289 <hr>
9290 <h3><a name="591"></a>591. Misleading "built-in</h3>
9291 <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#NAD%20Editorial">NAD Editorial</a>
9292  <b>Submitter:</b> whyglinux <b>Date:</b> 2006-08-08</p>
9293 <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>
9294 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9295 <p><b>Discussion:</b></p>
9296 <p>
9297 18.2.1.2 numeric_limits members [lib.numeric.limits.members]
9298 Paragraph 7:
9299 </p>
9300 <blockquote><p>
9301 "For built-in integer types, the number of non-sign bits in the
9302 representation."
9303 </p></blockquote>
9304
9305 <p>
9306 26.1 Numeric type requirements [lib.numeric.requirements]
9307 Footnote:
9308 </p>
9309
9310 <blockquote><p>
9311 "In other words, value types. These include built-in arithmetic types,
9312 pointers, the library class complex, and instantiations of valarray for
9313 value types."
9314 </p></blockquote>
9315
9316 <p>
9317 Integer types (which are bool, char, wchar_t, and the signed and
9318 unsigned integer types) and arithmetic types (which are integer and
9319 floating types) are all built-in types and thus there are no
9320 non-built-in (that is, user-defined) integer or arithmetic types. Since
9321 the redundant "built-in" in the above 2 sentences can mislead that
9322 there may be built-in or user-defined integer and arithmetic types
9323 (which is not correct), the "built-in" should be removed.
9324 </p>
9325
9326
9327 <p><b>Proposed resolution:</b></p>
9328 <p>
9329 18.2.1.2 numeric_limits members [lib.numeric.limits.members]
9330 Paragraph 7:
9331 </p>
9332 <blockquote><p>
9333 "For <del>built-in</del> integer types, the number of non-sign bits in the
9334 representation."
9335 </p></blockquote>
9336
9337 <p>
9338 26.1 Numeric type requirements [lib.numeric.requirements]
9339 Footnote:
9340 </p>
9341
9342 <blockquote><p>
9343 "In other words, value types. These include <del>built-in</del> arithmetic types,
9344 pointers, the library class complex, and instantiations of valarray for
9345 value types."
9346 </p></blockquote>
9347
9348
9349 <p><b>Rationale:</b></p>
9350 <p>
9351 Recommend NAD / Editorial.  The proposed resolution is accepted as editorial.
9352 </p>
9353
9354
9355
9356
9357
9358 <hr>
9359 <h3><a name="592"></a>592. Incorrect treatment of rdbuf()-&gt;close() return type</h3>
9360 <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#NAD%20Editorial">Pending NAD Editorial</a>
9361  <b>Submitter:</b> Christopher Kohlhoff <b>Date:</b> 2006-08-17</p>
9362 <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>
9363 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
9364 <p><b>Discussion:</b></p>
9365 <p>
9366 I just spotted a minor problem in 27.8.1.7
9367 [lib.ifstream.members] para 4 and also 27.8.1.13
9368 [lib.fstream.members] para 4. In both places it says:
9369 </p>
9370 <blockquote>
9371 <pre>void close();
9372 </pre>
9373 <p>
9374 Effects: Calls rdbuf()-&gt;close() and, if that function returns false, ...
9375 </p>
9376 </blockquote>
9377 <p>
9378 However, basic_filebuf::close() (27.8.1.2) returns a pointer to the
9379 filebuf on success, null on failure, so I think it is meant to
9380 say "if that function returns a null pointer". Oddly, it is
9381 correct for basic_ofstream.
9382 </p>
9383
9384
9385 <p><b>Proposed resolution:</b></p>
9386 <p>
9387 Change 27.8.1.9 [ifstream.members], p5:
9388 </p>
9389
9390 <blockquote><p>
9391 <i>Effects:</i> Calls <tt>rdbuf()-&gt;close()</tt> and, if that function
9392 <ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>,
9393 calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>
9394 (27.4.4.3)).
9395 </p></blockquote>
9396
9397 <p>
9398 Change 27.8.1.17 [fstream.members], p5:
9399 </p>
9400
9401 <blockquote><p>
9402 <i>Effects:</i> Calls <tt>rdbuf()-&gt;close()</tt> and, if that function
9403 <ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>,
9404 calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>
9405 (27.4.4.3)).
9406 </p></blockquote>
9407
9408
9409
9410 <p><i>[
9411 Kona (2007): Proposed Disposition: NAD, Editorial
9412 ]</i></p>
9413
9414
9415
9416
9417
9418 <hr>
9419 <h3><a name="594"></a>594. Disadvantages of defining Swappable in terms of CopyConstructible and Assignable</h3>
9420 <p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
9421  <b>Submitter:</b> Niels Dekker <b>Date:</b> 2006-11-02</p>
9422 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
9423 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
9424 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
9425 <p><b>Discussion:</b></p>
9426 <p>
9427 It seems undesirable to define the Swappable requirement in terms of
9428 CopyConstructible and Assignable requirements. And likewise, once the
9429 MoveConstructible and MoveAssignable requirements (N1860) have made it
9430 into the Working Draft, it seems undesirable to define the Swappable
9431 requirement in terms of those requirements. Instead, it appears
9432 preferable to have the Swappable requirement defined exclusively in
9433 terms of the existence of an appropriate swap function.
9434 </p>
9435 <p>
9436 Section 20.1.4 [lib.swappable] of the current Working Draft (N2009)
9437 says:
9438 </p>
9439 <blockquote><p>
9440 The Swappable requirement is met by satisfying one or more of the
9441 following conditions:</p>
9442 <ul>
9443 <li>
9444 T is Swappable if T satisfies the CopyConstructible requirements
9445 (20.1.3) and the Assignable requirements (23.1);
9446 </li>
9447 <li>
9448 T is Swappable if a namespace scope function named swap exists in the
9449 same namespace as the definition of T, such that the expression
9450 swap(t,u) is valid and has the semantics described in Table 33.
9451 </li>
9452 </ul>
9453 </blockquote>
9454 I can think of three disadvantages of this definition:
9455 <ol>
9456 <li>
9457 If a client's type T satisfies the first condition (T is both
9458 CopyConstructible and Assignable), the client cannot stop T from
9459 satisfying the Swappable requirement without stopping T from
9460 satisfying the first condition.
9461 <p>
9462 A client might want to stop T from satisfying the Swappable
9463 requirement, because swapping by means of copy construction and
9464 assignment might throw an exception, and she might find a throwing
9465 swap unacceptable for her type. On the other hand, she might not feel
9466 the need to fully implement her own swap function for this type. In
9467 this case she would want to be able to simply prevent algorithms that
9468 would swap objects of type T from being used, e.g., by declaring a
9469 swap function for T, and leaving this function purposely undefined.
9470 This would trigger a link error, if an attempt would be made to use
9471 such an algorithm for this type. For most standard library
9472 implementations, this practice would indeed have the effect of
9473 stopping T from satisfying the Swappable requirement.
9474 </p>
9475 </li>
9476 <li>
9477 A client's type T that does not satisfy the first condition can not be
9478 made Swappable by providing a specialization of std::swap for T.
9479 <p>
9480 While I'm aware about the fact that people have mixed feelings about
9481 providing a specialization of std::swap, it is well-defined to do so.
9482 It sounds rather counter-intuitive to say that T is not Swappable, if
9483 it has a valid and semantically correct specialization of std::swap.
9484 Also in practice, providing such a specialization will have the same
9485 effect as satisfying the Swappable requirement.
9486 </p>
9487 </li>
9488 <li>
9489 For a client's type T that satisfies both conditions of the Swappable
9490 requirement, it is not specified which of the two conditions prevails.
9491 After reading section 20.1.4 [lib.swappable], one might wonder whether
9492 objects of T will be swapped by doing copy construction and
9493 assignments, or by calling the swap function of T.
9494 <p>
9495 I'm aware that the intention of the Draft is to prefer calling the
9496 swap function of T over doing copy construction and assignments. Still
9497 in my opinion, it would be better to make this clear in the wording of
9498 the definition of Swappable.
9499 </p>
9500 </li>
9501 </ol>
9502 <p>
9503 I would like to have the Swappable requirement defined in such a way
9504 that the following code fragment will correctly swap two objects of a
9505 type T, if and only if T is Swappable:
9506 </p>
9507 <pre>   using std::swap;
9508    swap(t, u);  // t and u are of type T.
9509 </pre>
9510 <p>
9511 This is also the way Scott Meyers recommends calling a swap function,
9512 in Effective C++, Third Edition, item 25.
9513 </p>
9514 <p>
9515 Most aspects of this issue have been dealt with in a discussion on
9516 comp.std.c++ about the Swappable requirement, from 13 September to 4
9517 October 2006, including valuable input by David Abrahams, Pete Becker,
9518 Greg Herlihy, Howard Hinnant and others.
9519 </p>
9520
9521 <p><b>Proposed resolution:</b></p>
9522 <p>
9523 Change section 20.1.4 [lib.swappable] as follows:
9524 </p>
9525 <blockquote><p>
9526 The Swappable requirement is met by satisfying
9527 <del>one or more of the following conditions:</del>
9528 <ins>the following condition:</ins></p>
9529 <ul>
9530
9531 <li>
9532 <del>T is Swappable if T satisfies the CopyConstructible requirements
9533 (20.1.3) and the Assignable requirements (23.1);</del>
9534 </li>
9535 <li>
9536 <del>
9537 T is Swappable if a namespace scope function named swap exists in the
9538 same namespace as the definition of T, such that the expression
9539 swap(t,u) is valid and has the semantics described in Table 33.
9540 </del>
9541 T is Swappable if an unqualified function call swap(t,u) is valid
9542 within the namespace std, and has the semantics described in Table 33.
9543 </li>
9544 </ul>
9545 </blockquote>
9546
9547
9548 <p><b>Rationale:</b></p>
9549 <p>
9550 Recommend NAD.  Concepts, specifically
9551 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2082.pdf">N2082</a>
9552 and
9553 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2084.pdf">N2084</a>,
9554 will essentially rewrite this section and provide the desired semantics.
9555 </p>
9556
9557
9558
9559
9560
9561 <hr>
9562 <h3><a name="615"></a>615. Inconsistencies in Section 21.4</h3>
9563 <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#NAD%20Editorial">NAD Editorial</a>
9564  <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-11</p>
9565 <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>
9566 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9567 <p><b>Discussion:</b></p>
9568 <p>
9569 In the current draft N2134, 21.4/1 says
9570 </p>
9571 <p>
9572 "Tables 59,228) 60, 61, 62,and 63 229) 230) describe headers &lt;cctype&gt;,
9573 &lt;cwctype&gt;, &lt;cstring&gt;, &lt;cwchar&gt;, and &lt;cstdlib&gt; (character conversions),
9574 respectively."
9575 </p>
9576 <p>
9577 Here footnote 229 applies to table 62, not table 63.
9578 </p>
9579 <p>
9580 Also, footnote 230 lists the new functions in table 63, "atoll, strtoll,
9581 strtoull, strtof, and strtold added by TR1". However, strtof is not present
9582 in table 63.
9583 </p>
9584
9585
9586 <p><b>Proposed resolution:</b></p>
9587 <p>
9588 </p>
9589
9590
9591 <p><b>Rationale:</b></p>
9592 <p>
9593 Recommend NAD, editorial.  Send to Pete.
9594 </p>
9595
9596
9597
9598
9599
9600 <hr>
9601 <h3><a name="633"></a>633. Return clause mentions undefined "type()"</h3>
9602 <p><b>Section:</b> 20.5.15.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9603  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-03</p>
9604 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9605 <p><b>Discussion:</b></p>
9606 <p>
9607 20.5.15.2.5 [func.wrap.func.targ], p4 says:
9608 </p>
9609 <blockquote><p>
9610 <i>Returns:</i> If <tt>type() == typeid(T)</tt>, a pointer to the stored
9611 function target; otherwise a null pointer.
9612 </p></blockquote>
9613
9614 <ol>
9615 <li>
9616 There exists neither a type, a typedef <tt>type</tt>, nor member
9617 function <tt>type()</tt> in class template function nor in the global or
9618 <tt>std</tt> namespace.
9619 </li>
9620 <li>
9621 Assuming that <tt>type</tt> should have been <tt>target_type()</tt>,
9622 this description would lead to false results, if <tt>T = <i>cv</i>
9623 void</tt> due to returns clause 20.5.15.2.5 [func.wrap.func.targ], p1.
9624 </li>
9625 </ol>
9626
9627
9628
9629 <p><b>Proposed resolution:</b></p>
9630 <p>
9631 Change 20.5.15.2.5 [func.wrap.func.targ], p4:
9632 </p>
9633
9634 <blockquote><p>
9635 <i>Returns:</i> If <tt><del>type()</del> <ins>target_type()</ins> == typeid(T) <ins>&amp;&amp; typeid(T) !=
9636 typeid(void)</ins></tt>, a pointer to the stored function target;
9637 otherwise a null pointer.
9638 </p></blockquote>
9639
9640 <p><i>[
9641 Pete: Agreed. It's editorial, so I'll fix it.
9642 ]</i></p>
9643
9644
9645
9646
9647
9648
9649
9650 <hr>
9651 <h3><a name="636"></a>636. 26.5.2.3 valarray::operator[]</h3>
9652 <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#NAD%20Editorial">NAD Editorial</a>
9653  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-11</p>
9654 <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>
9655 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9656 <p><b>Discussion:</b></p>
9657 <p>
9658 The signature of the const operator[] has been changed to return a const
9659 reference.
9660 </p>
9661 <p>
9662 The description in paragraph 1 still says that the operator returns by
9663 value.
9664 </p>
9665 <p><i>[
9666 Pete recommends editorial fix.
9667 ]</i></p>
9668
9669
9670
9671 <p><b>Proposed resolution:</b></p>
9672 <p>
9673 </p>
9674
9675
9676
9677
9678
9679 <hr>
9680 <h3><a name="637"></a>637. [c.math]/10 inconsistent return values</h3>
9681 <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#NAD%20Editorial">NAD Editorial</a>
9682  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-13</p>
9683 <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>
9684 <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>
9685 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9686 <p><b>Discussion:</b></p>
9687 <p>
9688 26.7 [c.math], paragraph 10 has long lists of added signatures for float and long double
9689 functions. All the signatures have float/long double return values, which is
9690 inconsistent with some of the double functions they are supposed to
9691 overload.
9692 </p>
9693
9694
9695 <p><b>Proposed resolution:</b></p>
9696 <p>
9697 Change 26.7 [c.math], paragraph 10,
9698 </p>
9699
9700 <blockquote><pre><del>float</del> <ins>int</ins> ilogb(float);
9701 <del>float</del> <ins>long</ins> lrint(float);
9702 <del>float</del> <ins>long</ins> lround(float);
9703 <del>float</del> <ins>long long</ins> llrint(float);
9704 <del>float</del> <ins>long long</ins> llround(float);
9705
9706 <del>long double</del> <ins>int</ins> ilogb(long double);
9707 <del>long double</del> <ins>long</ins> lrint(long double);
9708 <del>long double</del> <ins>long</ins> lround(long double);
9709 <del>long double</del> <ins>long long</ins> llrint(long double);
9710 <del>long double</del> <ins>long long</ins> llround(long double);
9711 </pre></blockquote>
9712
9713
9714
9715
9716
9717 <hr>
9718 <h3><a name="639"></a>639. Still problems with exceptions during streambuf IO</h3>
9719 <p><b>Section:</b> 27.6.1.2.3 [istream::extractors], 27.6.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9720  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-17</p>
9721 <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>
9722 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9723 <p><b>Discussion:</b></p>
9724 <p>
9725 There already exist two active DR's for the wording of 27.6.1.2.3 [istream::extractors]/13
9726 from 14882:2003(E), namely <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>.
9727 </p>
9728
9729 <p>
9730 Even with these proposed corrections, already maintained in N2134,
9731 I have the feeling, that the current wording does still not properly
9732 handle the "exceptional" situation. The combination of para 14
9733 </p>
9734
9735 <blockquote><p>
9736 "[..] Characters are extracted and inserted until
9737 any of the following occurs:
9738 </p>
9739 <p>
9740 [..]
9741 </p>
9742 <p>
9743 - an exception occurs (in which case the exception is caught)."
9744 </p></blockquote>
9745
9746 <p>
9747 and 15
9748 </p>
9749
9750 <blockquote><p>
9751 "If the function inserts no characters, it calls setstate(failbit),
9752 which
9753 may throw ios_base::failure (27.4.4.3). If it inserted no characters
9754 because it caught an exception thrown while extracting characters
9755 from *this and failbit is on in exceptions() (27.4.4.3), then the
9756 caught
9757 exception is rethrown."
9758 </p></blockquote>
9759
9760 <p>
9761 both in N2134 seems to imply that any exception, which occurs
9762 *after* at least one character has been inserted is caught and lost
9763 for
9764 ever. It seems that even if failbit is on in exceptions() rethrow is
9765 not
9766 allowed due to the wording "If it inserted no characters because it
9767 caught an exception thrown while extracting".
9768 </p>
9769
9770 <p>
9771 Is this behaviour by design?
9772 </p>
9773
9774 <p>
9775 I would like to add that its output counterpart in 27.6.2.6.3 [ostream.inserters]/7-9
9776 (also
9777 N2134) does not demonstrate such an exception-loss-behaviour.
9778 On the other side, I wonder concerning several subtle differences
9779 compared to input::
9780 </p>
9781 <p>
9782 1) Paragraph 8 says at its end:
9783 </p>
9784
9785 <blockquote><p>
9786 "- an exception occurs while getting a character from sb."
9787 </p></blockquote>
9788
9789 <p>
9790 Note that there is nothing mentioned which would imply that such
9791 an exception will be caught compared to 27.6.1.2.3 [istream::extractors]/14.
9792 </p>
9793
9794 <p>
9795 2) Paragraph 9 says:
9796 </p>
9797
9798 <blockquote><p>
9799 "If the function inserts no characters, it calls setstate(failbit)
9800 (which
9801 may throw ios_base::failure (27.4.4.3)). If an exception was thrown
9802 while extracting a character, the function sets failbit in error
9803 state,
9804 and if failbit is on in exceptions() the caught exception is
9805 rethrown."
9806 </p></blockquote>
9807
9808 <p>
9809 The sentence starting with "If an exception was thrown" seems to
9810 imply that such an exception *should* be caught before.
9811 </p>
9812
9813
9814 <p><b>Proposed resolution:</b></p>
9815 <p>
9816 (a) In 27.6.1.2.3 [istream::extractors]/15 (N2134) change the sentence
9817 </p>
9818
9819 <blockquote><p>
9820 If the function inserts no characters, it calls
9821 <tt>setstate(failbit)</tt>, which may throw <tt>ios_base::failure</tt>
9822 (27.4.4.3). If <del>it inserted no characters because it caught an
9823 exception thrown while extracting characters from <tt>*this</tt></del>
9824 <ins>an exception was thrown while extracting a character from
9825 <tt>*this</tt>, the function sets <tt>failbit</tt> in error state,</ins>
9826 and <tt>failbit</tt> is on in <tt>exceptions()</tt> (27.4.4.3), then the
9827 caught exception is rethrown.
9828 </p></blockquote>
9829
9830 <p>
9831 (b) In 27.6.2.6.3 [ostream.inserters]/8 (N2134) change the sentence:
9832 </p>
9833
9834 <blockquote>
9835 <p>
9836 Gets characters from <tt>sb</tt> and inserts them in <tt>*this</tt>.
9837 Characters are read from <tt>sb</tt> and inserted until any of the
9838 following occurs:
9839 </p>
9840 <ul>
9841 <li>end-of-file occurs on the input sequence;</li>
9842 <li>inserting in the output sequence fails (in which case the character to be inserted is not extracted);</li>
9843 <li>an exception occurs while getting a character from <tt>sb</tt> <ins>(in which
9844 case the exception is caught)</ins>.</li>
9845 </ul>
9846 </blockquote>
9847
9848
9849
9850 <p><b>Rationale:</b></p>
9851 This extractor is described as a formatted input function so the
9852 exception behavior is already specified. There is additional behavior
9853 described in this section that applies to the case in which failbit is
9854 set. This doesn't contradict the usual exception behavior for formatted
9855 input functions because that applies to the case in which badbit is set.
9856
9857
9858
9859
9860
9861 <hr>
9862 <h3><a name="641"></a>641. Editorial fix for 27.6.4 (N2134)</h3>
9863 <p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9864  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-18</p>
9865 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
9866 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9867 <p><b>Discussion:</b></p>
9868 <p>
9869 The function <tt>f</tt> in para 4 (27.6.4 [ext.manip]) references an unknown <tt>strm</tt>
9870 in the following line:
9871 </p>
9872
9873 <blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon);
9874 </pre></blockquote>
9875
9876
9877 <p><b>Proposed resolution:</b></p>
9878 <p>
9879 Change 27.6.4 [ext.manip], p4:
9880 </p>
9881
9882 <blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, str<del>m</del>, err, mon);
9883 </pre></blockquote>
9884
9885 <p><i>[
9886 Oxford:  Editorial.
9887 ]</i></p>
9888
9889
9890
9891
9892
9893
9894
9895 <hr>
9896 <h3><a name="642"></a>642. Invalidated fstream footnotes in N2134</h3>
9897 <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#NAD%20Editorial">NAD Editorial</a>
9898  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-20</p>
9899 <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>
9900 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9901 <p><b>Discussion:</b></p>
9902 <p>
9903 The standard wording of N2134 has extended the 14882:2003(E)
9904 wording for the ifstream/ofstream/fstream open function to fix
9905 a long standing problem, see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>.
9906 </p>
9907
9908 <p>
9909 Now it's properly written as
9910 </p>
9911
9912 <blockquote><p>
9913 "If that function does not return a null pointer calls clear(),
9914 otherwise
9915 calls setstate(failbit)[..]"
9916 </p></blockquote>
9917
9918 <p>
9919 instead of the previous
9920 </p>
9921
9922 <blockquote><p>
9923 "If that function returns a null pointer, calls setstate(failbit)[..]
9924 </p></blockquote>
9925
9926 <p>
9927 While the old footnotes saying
9928 </p>
9929
9930 <blockquote><p>
9931 "A successful open does not change the error state."
9932 </p></blockquote>
9933
9934 <p>
9935 where correct and important, they are invalid now for ifstream and
9936 ofstream (because clear *does* indeed modify the error state) and
9937 should be removed (Interestingly fstream itself never had these,
9938 although
9939 they where needed for that time).
9940 </p>
9941
9942
9943 <p><b>Proposed resolution:</b></p>
9944 <p>
9945 In 27.8.1.9 [ifstream.members], remove footnote:
9946 </p>
9947
9948 <blockquote><p>
9949 <del><sup>334)</sup> A successful open does not change the error state.</del>
9950 </p></blockquote>
9951
9952 <p>
9953 In 27.8.1.13 [ofstream.members], remove footnote:
9954 </p>
9955
9956 <blockquote><p>
9957 <del><sup>335)</sup> A successful open does not change the error state.</del>
9958 </p></blockquote>
9959
9960
9961
9962
9963
9964
9965 <hr>
9966 <h3><a name="647"></a>647. Inconsistent regex_search params</h3>
9967 <p><b>Section:</b> 28.11.3 [re.alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9968  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p>
9969 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9970 <p><b>Discussion:</b></p>
9971 <p>
9972 28.11.3 [re.alg.search]/5 declares
9973 </p>
9974
9975 <blockquote><pre>template &lt;class iterator, class charT, class traits&gt;
9976 bool regex_search(iterator first, iterator last,
9977                   const basic_regex&lt;charT, traits&gt;&amp; e,
9978                   regex_constants::match_flag_type flags =
9979                       regex_constants::match_default);
9980 </pre></blockquote>
9981
9982 <p>
9983 where it's not explained, which iterator category
9984 the parameter iterator belongs to. This is inconsistent
9985 to the preceding declaration in the synopsis section
9986 28.4 [re.syn], which says:
9987 </p>
9988
9989 <blockquote><pre>template &lt;class BidirectionalIterator, class charT, class traits&gt;
9990 bool regex_search(BidirectionalIterator first, BidirectionalIterator last,
9991                   const basic_regex&lt;charT, traits&gt;&amp; e,
9992                   regex_constants::match_flag_type flags =
9993                       regex_constants::match_default);
9994 </pre></blockquote>
9995
9996
9997 <p><b>Proposed resolution:</b></p>
9998 <p>
9999 In 28.11.3 [re.alg.search]/5 replace all three occurences of param "iterator" with
10000 "BidirectionalIterator"
10001 </p>
10002
10003 <blockquote><pre>template &lt;class <del>iterator</del> <ins>BidirectionalIterator</ins>, class charT, class traits&gt;
10004   bool regex_search(<del>iterator</del> <ins>BidirectionalIterator</ins> first, <del>iterator</del> <ins>BidirectionalIterator</ins> last,
10005                     const basic_regex&lt;charT, traits&gt;&amp; e,
10006                     regex_constants::match_flag_type flags =
10007                       regex_constants::match_default);
10008 </pre>
10009 <p>
10010 -6- <i>Effects:</i> Behaves "as if" by constructing an object what of
10011 type <tt>match_results&lt;<del>iterator</del>
10012 <ins>BidirectionalIterator</ins>&gt;</tt> and then returning the result
10013 of <tt>regex_search(first, last, what, e, flags)</tt>.
10014 </p>
10015 </blockquote>
10016
10017
10018 <p><b>Rationale:</b></p>
10019 Applied to working paper while issue was still in New status.
10020
10021
10022
10023
10024
10025 <hr>
10026 <h3><a name="648"></a>648. regex_iterator c'tor needs clarification/editorial fix</h3>
10027 <p><b>Section:</b> 28.12.1.1 [re.regiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
10028  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-03</p>
10029 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10030 <p><b>Discussion:</b></p>
10031 <p>
10032 In 28.12.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with:
10033 </p>
10034
10035 <blockquote>
10036 <p>
10037 <i>Effects:</i> Initializes begin and end to point to the beginning and the
10038 end of the target sequence, sets pregex to &amp;re, sets flags to f,[..]
10039 </p></blockquote>
10040
10041 <p>
10042 There are two issues with this description:
10043 </p>
10044
10045 <ol>
10046 <li>
10047 The meaning of very first part of this quote is unclear, because
10048 there is no target sequence provided, instead there are given two
10049 parameters a and b, both of type BidirectionalIterator. The mentioned
10050 part does not explain what a and b represent.
10051 </li>
10052 <li>
10053 There does not exist any parameter f, but instead a parameter
10054 m in the constructor declaration, so this is actually an editorial
10055 fix.
10056 </li>
10057 </ol>
10058
10059
10060 <p><b>Proposed resolution:</b></p>
10061 <p>
10062 In 28.12.1.1 [re.regiter.cnstr]/2 change the above quoted part by
10063 </p>
10064
10065 <blockquote><p>
10066 <i>Effects:</i> Initializes <tt>begin</tt> and <tt>end</tt> to point to
10067 the beginning and the end of the target sequence <ins>designated by the
10068 iterator range <tt>[a, b)</tt></ins>, sets <tt>pregex</tt> to
10069 <tt>&amp;re</tt>, sets <tt>flags</tt> to <tt><del>f</del>
10070 <ins>m</ins></tt>, then calls <tt>regex_search(begin, end, match,
10071 *pregex, flags)</tt>. If this call returns <tt>false</tt> the
10072 constructor sets <tt>*this</tt> to the end-of-sequence iterator.
10073 </p></blockquote>
10074
10075
10076
10077
10078
10079 <hr>
10080 <h3><a name="649"></a>649. Several typos in regex_token_iterator constructors</h3>
10081 <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#NAD%20Editorial">NAD Editorial</a>
10082  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-03</p>
10083 <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>
10084 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10085 <p><b>Discussion:</b></p>
10086 <p>
10087 In 28.12.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration
10088 and the following text shows some obvious typos:
10089 </p>
10090 <p>
10091 1) The third constructor form is written as
10092 </p>
10093 <blockquote><pre>template &lt;std::size_t N&gt;
10094   regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
10095                        const regex_type&amp; re,
10096                        const int (&amp;submatches)[R],
10097                        regex_constants::match_flag_type m =
10098                          regex_constants::match_default);
10099 </pre></blockquote>
10100
10101 <p>
10102 where the dimensions of submatches are specified by an
10103 unknown value R, which should be N.
10104 </p>
10105 <p>
10106 2) Paragraph 2 of the same section says in its last sentence:
10107 </p>
10108
10109 <blockquote><p>
10110 The third constructor initializes the member <tt>subs</tt> to hold a
10111 copy of the sequence of integer values pointed to by the iterator range
10112 <tt>[&amp;submatches, &amp;submatches + R)</tt>.
10113 </p></blockquote>
10114
10115 <p>
10116 where again R must be replaced by N.
10117 </p>
10118
10119 <p>
10120 3) Paragraph 3 of the same section says in its first sentence:
10121 </p>
10122
10123 <blockquote><p>
10124 Each constructor then sets <tt>N</tt> to <tt>0</tt>, and
10125 <tt>position</tt> to <tt>position_iterator(a, b, re, f)</tt>.
10126 </p></blockquote>
10127
10128 <p>
10129 where a non-existing parameter "f" is mentioned, which must be
10130 replaced
10131 by the parameter "m".
10132 </p>
10133
10134
10135 <p><b>Proposed resolution:</b></p>
10136 <p>
10137 Change 28.12.2.1 [re.tokiter.cnstr]/1:
10138 </p>
10139 <blockquote><pre>template &lt;std::size_t N&gt;
10140   regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
10141                        const regex_type&amp; re,
10142                        const int (&amp;submatches)[<del>R</del> <ins>N</ins>],
10143                        regex_constants::match_flag_type m =
10144                          regex_constants::match_default);
10145 </pre></blockquote>
10146
10147 <p>
10148 Change 28.12.2.1 [re.tokiter.cnstr]/2:
10149 </p>
10150
10151 <blockquote><p>
10152 <i>Effects:</i> The first constructor initializes the member
10153 <tt>subs</tt> to hold the single value <tt>submatch</tt>. The second
10154 constructor initializes the member <tt>subs</tt> to hold a copy of the
10155 argument <tt>submatches</tt>. The third constructor initializes the
10156 member <tt>subs</tt> to hold a copy of the sequence of integer values
10157 pointed to by the iterator range <tt>[&amp;submatches, &amp;submatches +
10158 <del>R</del> <ins>N</ins>)</tt>.
10159 </p></blockquote>
10160
10161 <p>
10162 Change 28.12.2.1 [re.tokiter.cnstr]/3:
10163 </p>
10164
10165 <blockquote><p>
10166 Each constructor then sets <tt>N</tt> to <tt>0</tt>, and
10167 <tt>position</tt> to <tt>position_iterator(a, b, re, <del>f</del>
10168 <ins>m</ins>)</tt>. If <tt>position</tt> is not an end-of-sequence
10169 iterator the constructor sets <tt>result</tt> to the address of the
10170 current match. Otherwise if any of the values stored in <tt>subs</tt> is
10171 equal to <tt>-1</tt> the constructor sets <tt>*this</tt> to a suffix
10172 iterator that points to the range <tt>[a, b)</tt>, otherwise the
10173 constructor sets <tt>*this</tt> to an end-of-sequence iterator.
10174 </p></blockquote>
10175
10176
10177
10178
10179
10180
10181 <hr>
10182 <h3><a name="656"></a>656. Typo in subtract_with_carry_engine declaration</h3>
10183 <p><b>Section:</b> 26.4.2 [rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
10184  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
10185 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</p>
10186 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10187 <p><b>Discussion:</b></p>
10188 <p>
10189 26.4.2 [rand.synopsis] the header <tt>&lt;random&gt;</tt> synopsis
10190 contains an unreasonable closing curly brace inside the
10191 <tt>subtract_with_carry_engine</tt> declaration.
10192 </p>
10193
10194
10195 <p><b>Proposed resolution:</b></p>
10196 <p>
10197 Change the current declaration in 26.4.2 [rand.synopsis]
10198 </p>
10199
10200 <blockquote><pre>template &lt;class UIntType, size_t w<del>}</del>, size_t s, size_t r&gt;
10201 class subtract_with_carry_engine;
10202 </pre></blockquote>
10203
10204
10205 <p><i>[
10206 Pete: Recommends editorial.
10207 ]</i></p>
10208
10209
10210
10211
10212
10213 <hr>
10214 <h3><a name="657"></a>657. unclear requirement about header inclusion</h3>
10215 <p><b>Section:</b> 17.4.2.1 [using.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
10216  <b>Submitter:</b> Gennaro Prota <b>Date:</b> 2007-03-14</p>
10217 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10218 <p><b>Discussion:</b></p>
10219 <p>
10220 17.4.2.1 [using.headers] states:
10221 </p>
10222
10223 <blockquote><p>
10224 A translation unit shall include a header only outside of any
10225 external declaration or definition, [...]
10226 </p></blockquote>
10227
10228 <p>
10229 I see three problems with this requirement:
10230 </p>
10231
10232 <ol type="a">
10233 <li><p>The C++ standard doesn't define what an "external declaration" or
10234 an "external definition" are (incidentally the C99 standard does, and
10235 has a sentence very similar to the above regarding header inclusion).
10236 </p><p>
10237 I think the intent is that the #include directive shall lexically
10238 appear outside *any* declaration; instead, when the issue was pointed
10239 out on comp.std.c++ at least one poster interpreted "external
10240 declaration" as "declaration of an identifier with external linkage".
10241 If this were the correct interpretation, then the two inclusions below
10242 would be legal:
10243 </p>
10244 <blockquote><pre>  // at global scope
10245   static void f()
10246   {
10247 # include &lt;cstddef&gt;
10248   }
10249
10250   static void g()
10251   {
10252 # include &lt;stddef.h&gt;
10253   }
10254 </pre></blockquote>
10255 <p>
10256 (note that while the first example is unlikely to compile correctly,
10257 the second one may well do)
10258 </p></li>
10259
10260 <li><p>as the sentence stands, violations will require a diagnostic; is
10261 this the intent? It was pointed out on comp.std.c++ (by several
10262 posters) that at least one way to ensure a diagnostic exists:
10263 </p>
10264 <blockquote><p>
10265    [If there is an actual file for each header,] one simple way
10266    to implement this would be to insert a reserved identifier
10267    such as __begin_header  at the start of each standard header.
10268    This reserved identifier would be ignored for all other
10269    purposes, except that, at the appropriate point in phase 7, if
10270    it is found inside an external definition, a diagnostic is
10271    generated. There's many other similar ways to achieve the same
10272    effect.
10273    </p>
10274 <p>                                 --James Kuyper, on comp.std.c++
10275 </p></blockquote></li>
10276
10277 <li><p>is the term "header" meant to be limited to standard headers?
10278 Clause 17 is all about the library, but still the general question is
10279 interesting and affects one of the points in the explicit namespaces
10280 proposal (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1691.html">n1691</a>):
10281 </p>
10282 <blockquote><p>
10283     Those seeking to conveniently enable argument-dependent
10284     lookups for all operators within an explicit namespace
10285     could easily create a header file that does so:
10286 </p><pre>    namespace mymath::
10287     {
10288         #include "using_ops.hpp"
10289     }
10290 </pre></blockquote>
10291 </li>
10292 </ol>
10293
10294
10295 <p><b>Proposed resolution:</b></p>
10296 <p>
10297 </p>
10298
10299
10300 <p><b>Rationale:</b></p>
10301 We believe that the existing language does not cause any real confusion
10302 and any new formulation of the rules that we could come up with are
10303 unlikely to be better than what's already in the standard.
10304
10305
10306
10307
10308
10309 <hr>
10310 <h3><a name="658"></a>658. Two unspecified function comparators in [function.objects]</h3>
10311 <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#NAD%20Editorial">NAD Editorial</a>
10312  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-19</p>
10313 <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>
10314 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10315 <p><b>Discussion:</b></p>
10316 <p>
10317 The header <tt>&lt;functional&gt;</tt> synopsis in 20.5 [function.objects]
10318 contains the following two free comparison operator templates
10319 for the <tt>function</tt> class template
10320 </p>
10321
10322 <blockquote><pre>template&lt;class Function1, class Function2&gt;
10323 void operator==(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
10324 template&lt;class Function1, class Function2&gt;
10325 void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
10326 </pre></blockquote>
10327
10328 <p>
10329 which are nowhere described. I assume that they are relicts before the
10330 corresponding two private and undefined member templates in the function
10331 template (see 20.5.15.2 [func.wrap.func] and X [func.wrap.func.undef]) have been introduced. The original free
10332 function templates should be removed, because using an undefined entity
10333 would lead to an ODR violation of the user.
10334 </p>
10335
10336
10337 <p><b>Proposed resolution:</b></p>
10338 <p>
10339 Remove the above mentioned two function templates from
10340 the header <tt>&lt;functional&gt;</tt> synopsis (20.5 [function.objects])
10341 </p>
10342
10343 <blockquote><pre><del>template&lt;class Function1, class Function2&gt;
10344 void operator==(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
10345 template&lt;class Function1, class Function2&gt;
10346 void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);</del>
10347 </pre></blockquote>
10348
10349
10350
10351 <p><b>Rationale:</b></p>
10352 Fixed by
10353 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
10354 Standard Library Applications for Deleted Functions.
10355
10356
10357
10358
10359
10360 <hr>
10361 <h3><a name="662"></a>662. Inconsistent handling of incorrectly-placed thousands separators</h3>
10362 <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#NAD">NAD</a>
10363  <b>Submitter:</b> Cosmin Truta <b>Date:</b> 2007-04-05</p>
10364 <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>
10365 <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>
10366 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10367 <p><b>Discussion:</b></p>
10368 <p>
10369 From Section 22.2.2.1.2 [facet.num.get.virtuals], paragraphs 11 and 12, it is implied
10370 that the value read from a stream must be stored
10371 even if the placement of thousands separators does not conform to the
10372 <code>grouping()</code> specification from the <code>numpunct</code> facet.
10373 Since incorrectly-placed thousands separators are flagged as an extraction
10374 failure (by the means of <code>failbit</code>), we believe it is better not
10375 to store the value. A consistent strategy, in which any kind of extraction
10376 failure leaves the input item intact, is conceptually cleaner, is able to avoid
10377 corner-case traps, and is also more understandable from the programmer's point
10378 of view.
10379 </p>
10380 <p>
10381 Here is a quote from <i>"The C++ Programming Language (Special Edition)"</i>
10382 by B.&nbsp;Stroustrup (Section&nbsp;D.4.2.3, pg.&nbsp;897):
10383 </p>
10384 <blockquote><p>
10385 <i>"If a value of the desired type could not be read, failbit is set in r.
10386 [...] An input operator will use r to determine how to set the state of its
10387 stream. If no error was encountered, the value read is assigned through v;
10388 otherwise, v is left unchanged."</i>
10389 </p></blockquote>
10390 <p>
10391 This statement implies that <code>rdstate()</code> alone is sufficient to
10392 determine whether an extracted value is to be assigned to the input item
10393 <i>val</i> passed to <code>do_get</code>. However, this is in disagreement
10394 with the current C++ Standard. The above-mentioned assumption is true in all
10395 cases, except when there are mismatches in digit grouping. In the latter case,
10396 the parsed value is assigned to <i>val</i>, and, at the same time, <i>err</i>
10397 is assigned to <code>ios_base::failbit</code> (essentially "lying" about the
10398 success of the operation). Is this intentional? The current behavior raises
10399 both consistency and usability concerns.
10400 </p>
10401 <p>
10402 Although digit grouping is outside the scope of <code>scanf</code> (on which
10403 the virtual methods of <code>num_get</code> are based), handling of grouping
10404 should be consistent with the overall behavior of scanf. The specification of
10405 <code>scanf</code> makes a distinction between input failures and matching
10406 failures, and yet both kinds of failures have no effect on the input items
10407 passed to <code>scanf</code>. A mismatch in digit grouping logically falls in
10408 the category of matching failures, and it would be more consistent, and less
10409 surprising to the user, to leave the input item intact whenever a failure is
10410 being signaled.
10411 </p>
10412 <p>
10413 The extraction of <code>bool</code> is another example outside the scope of
10414 <code>scanf</code>, and yet consistent, even in the event of a successful
10415 extraction of a <code>long</code> but a failed conversion from
10416 <code>long</code> to <code>bool</code>.
10417 </p>
10418 <p>
10419 Inconsistency is further aggravated by the fact that, when failbit is set,
10420 subsequent extraction operations are no-ops until <code>failbit</code> is
10421 explicitly cleared. Assuming that there is no explicit handling of
10422 <code>rdstate()</code> (as in <code>cin&gt;&gt;i&gt;&gt;j</code>) it is
10423 counter-intuitive to be able to extract an integer with mismatched digit
10424 grouping, but to be unable to extract another, properly-formatted integer
10425 that immediately follows.
10426 </p>
10427 <p>
10428 Moreover, setting <code>failbit</code>, and selectively assigning a value to
10429 the input item, raises usability problems. Either the strategy of
10430 <code>scanf</code> (when there is no extracted value in case of failure), or
10431 the strategy of the <code>strtol</code> family (when there is always an
10432 extracted value, and there are well-defined defaults in case of a failure) are
10433 easy to understand and easy to use. On the other hand, if <code>failbit</code>
10434 alone cannot consistently make a difference between a failed extraction, and a
10435 successful but not-quite-correct extraction whose output happens to be the same
10436 as the previous value, the programmer must resort to implementation tricks.
10437 Consider the following example:
10438 </p>
10439 <pre>    int i = old_i;
10440     cin &gt;&gt; i;
10441     if (cin.fail())
10442         // can the value of i be trusted?
10443         // what does it mean if i == old_i?
10444         // ...
10445 </pre>
10446 <p>
10447 Last but not least, the current behvaior is not only confusing to the casual
10448 reader, but it has also been confusing to some book authors. Besides
10449 Stroustrup's book, other books (e.g. "Standard C++ IOStreams and Locales" by
10450 Langer and Kreft) are describing the same mistaken assumption. Although books
10451 are not to be used instead of the standard reference, the readers of these
10452 books, as well as the people who are generally familiar to <code>scanf</code>,
10453 are even more likely to misinterpret the standard, and expect the input items
10454 to remain intact when a failure occurs.
10455 </p>
10456
10457
10458 <p><b>Proposed resolution:</b></p>
10459
10460 <p>
10461 Change 22.2.2.1.2 [facet.num.get.virtuals]:
10462 </p>
10463
10464 <blockquote>
10465 <p>
10466 <b>Stage 3:</b> The result of stage 2 processing can be one of
10467 </p>
10468 <ul>
10469 <li>A sequence of <code>chars</code> has been accumulated in stage 2 that is converted (according to the rules of <code>scanf</code>) to a value of the type of <code><i>val</i></code>.  <del>This value is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</del></li>
10470
10471 <li>The sequence of <code>chars</code> accumulated in stage 2 would have caused <code>scanf</code> to report an input failure. <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>.</li>
10472 </ul>
10473 <p>
10474 <ins>In the first case,</ins> <del>D</del><ins>d</ins>igit grouping is checked.  That is, the positions of discarded separators is examined for consistency with <code>use_facet&lt;numpunct&lt;charT&gt; &gt;(<i>loc</i>).grouping()</code>.  If they are not consistent then <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>.  <ins>Otherwise, the value that was converted in stage 2 is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</ins>
10475 </p>
10476 </blockquote>
10477
10478
10479 <p><b>Rationale:</b></p>
10480 post-Toronto: Changed from New to NAD at the request of the author.  The preferred solution of
10481 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
10482 makes this resolution obsolete.
10483
10484
10485
10486
10487
10488 <hr>
10489 <h3><a name="663"></a>663. Complexity Requirements</h3>
10490 <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#NAD">NAD</a>
10491  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
10492 <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>
10493 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10494 <p><b>Discussion:</b></p>
10495 <p>
10496 17.3.1.3 [structure.specifications] para 5 says
10497 </p>
10498
10499 <blockquote><p>
10500 -5- Complexity requirements specified in the library&nbsp;
10501 clauses are upper bounds, and implementations that provide better
10502 complexity guarantees satisfy the requirements.
10503 </p></blockquote>
10504
10505 <p>
10506 The following
10507 objection has been raised:
10508 </p>
10509
10510 <blockquote><p>
10511 The library clauses suggest general
10512 guidelines regarding complexity, but we have been unable to discover
10513 any absolute hard-and-fast formulae for these requirements.&nbsp; Unless
10514 or until the Library group standardizes specific hard-and-fast
10515 formulae, we regard all the complexity requirements as subject to a&nbsp;
10516 "fudge factor" without any intrinsic upper bound.
10517 </p></blockquote>
10518
10519 <p>
10520 [Plum ref&nbsp;
10521 _23213Y31 etc]
10522 </p>
10523
10524
10525 <p><b>Proposed resolution:</b></p>
10526 <p>
10527 </p>
10528
10529
10530 <p><b>Rationale:</b></p>
10531 Kona (2007): No specific instances of underspecification have been
10532 identified, and big-O notation always involves constant factors.
10533
10534
10535
10536
10537
10538 <hr>
10539 <h3><a name="683"></a>683. regex_token_iterator summary error</h3>
10540 <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#NAD%20Editorial">Pending NAD Editorial</a>
10541  <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-02</p>
10542 <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>
10543 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
10544 <p><b>Discussion:</b></p>
10545 <p>
10546 28.12.2 [re.tokiter], p3 says:
10547 </p>
10548 <blockquote>
10549 <p>
10550 After it is constructed, the iterator finds and stores a value
10551 <tt>match_results&lt;BidirectionalIterator&gt;</tt> position and sets the
10552 internal count <tt>N</tt> to zero.
10553 </p>
10554 </blockquote>
10555
10556 <p>
10557 Should read:
10558 </p>
10559
10560 <blockquote>
10561 <p>
10562 After it is constructed, the iterator finds and stores a value
10563 <tt><del>match_results</del><ins>regex_iterator</ins>&lt;BidirectionalIterator<ins>, charT, traits</ins>&gt;</tt>
10564 position and sets the internal count <tt>N</tt> to zero.
10565 </p>
10566 </blockquote>
10567
10568 <p><i>[
10569 John adds:
10570 ]</i></p>
10571
10572
10573 <blockquote><p>
10574 Yep, looks like a typo/administrative fix to me.
10575 </p></blockquote>
10576
10577
10578
10579 <p><b>Proposed resolution:</b></p>
10580 <p>
10581 </p>
10582
10583
10584
10585
10586
10587 <hr>
10588 <h3><a name="690"></a>690. abs(long long) should return long long</h3>
10589 <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#NAD%20Editorial">NAD Editorial</a>
10590  <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-06-10</p>
10591 <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>
10592 <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>
10593 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10594 <p><b>Discussion:</b></p>
10595 <p>
10596 Quoting the latest draft (n2135), 26.7 [c.math]:
10597 </p>
10598
10599 <blockquote>
10600 <p>
10601 The added signatures are:
10602 </p>
10603 <blockquote><pre>long abs(long); // labs()
10604 long abs(long long); // llabs()
10605 </pre></blockquote>
10606 </blockquote>
10607 <p>
10608 Shouldn't <tt>abs(long long)</tt> have <tt>long long</tt> as return type?
10609 </p>
10610
10611
10612 <p><b>Proposed resolution:</b></p>
10613 <p>
10614 Change 26.7 [c.math]:
10615 </p>
10616 <blockquote><pre><ins>long </ins>long abs(long long); // llabs()
10617 </pre></blockquote>
10618
10619
10620 <p><b>Rationale:</b></p>
10621 Had already been fixed in the WP by the time the LWG reviewed this.
10622
10623
10624
10625
10626
10627 </body></html>