l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.3.3/doc/html/ext/lwg-active.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 Active 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">N2456=07-0326</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 Active 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-defects.html">Library Defect Reports List</a></li>
  39       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
  40   </ul>
  41   <p>The purpose of this document is to record the status of issues
  42   which have come before the Library Working Group (LWG) of the ANSI
  43   (J16) and ISO (WG21) C++ Standards Committee. Issues represent
  44   potential defects in the ISO/IEC IS 14882:1998(E) document.  Issues
  45   are not to be used to request new features. </p>
  46
  47   <p>This document contains only library issues which are actively being
  48   considered by the Library Working Group. That is, issues which have a
  49   status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>,
  50   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>. See
  51   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered defects and
  52   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</p>
  53
  54   <p>The issues in these lists are not necessarily formal ISO Defect
  55   Reports (DR's). While some issues will eventually be elevated to
  56   official Defect Report status, other issues will be disposed of in
  57   other ways. See <a href="#Status">Issue Status</a>.</p>
  58
  59   <p>This document is in an experimental format designed for both
  60   viewing via a world-wide web browser and hard-copy printing. It
  61   is available as an HTML file for browsing or PDF file for
  62   printing.</p>
  63
  64   <p>Prior to Revision 14, library issues lists existed in two slightly
  65   different versions; a Committee Version and a Public
  66   Version. Beginning with Revision 14 the two versions were combined
  67   into a single version.</p>
  68
  69   <p>This document includes <i>[bracketed italicized notes]</i> as a
  70   reminder to the LWG of current progress on issues. Such notes are
  71   strictly unofficial and should be read with caution as they may be
  72   incomplete or incorrect. Be aware that LWG support for a particular
  73   resolution can quickly change if new viewpoints or killer examples are
  74   presented in subsequent discussions.</p>
  75
  76   <p>For the most current official version of this document see
  77   <a href="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21/</a>.
  78   Requests for further information about this document should include
  79   the document number above, reference ISO/IEC 14882:1998(E), and be
  80   submitted to Information Technology Industry Council (ITI), 1250 Eye
  81   Street NW, Washington, DC 20005.</p>
  82
  83   <p>Public information as to how to obtain a copy of the C++ Standard,
  84   join the standards committee, submit an issue, or comment on an issue
  85   can be found in the comp.std.c++ FAQ.
  86   Public discussion of C++ Standard related issues occurs on <a href="news:comp.std.c++">news:comp.std.c++</a>.
  87   </p>
  88
  89  <p>For committee members, files available on the committee's private
  90   web site include the HTML version of the Standard itself. HTML
  91   hyperlinks from this issues list to those files will only work for
  92   committee members who have downloaded them into the same disk
  93   directory as the issues list files.  </p>
  94
  95 <h2>Revision History</h2>
  96 <ul>
  97 <li>R52:
  98 2007-10-19 post-Kona mailing.
  99 <ul>
 100 <li><b>Summary:</b><ul>
 101 <li>172 open issues, up by 4.</li>
 102 <li>582 closed issues, up by 27.</li>
 103 <li>754 issues total, up by 31.</li>
 104 </ul></li>
 105 <li><b>Details:</b><ul>
 106 <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>
 107 <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>
 108 <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>
 109 <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>
 110 <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>
 111 <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>
 112 <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>
 113 <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>
 114 <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>
 115 <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>
 116 <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>
 117 <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>
 118 <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>
 119 </ul></li>
 120 </ul>
 121 </li>
 122 <li>R51:
 123 2007-09-09 pre-Kona mailing.
 124 <ul>
 125 <li><b>Summary:</b><ul>
 126 <li>168 open issues, up by 15.</li>
 127 <li>555 closed issues, up by 0.</li>
 128 <li>723 issues total, up by 15.</li>
 129 </ul></li>
 130 <li><b>Details:</b><ul>
 131 <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>
 132 </ul></li>
 133 </ul>
 134 </li>
 135 <li>R50:
 136 2007-08-05 post-Toronto mailing.
 137 <ul>
 138 <li><b>Summary:</b><ul>
 139 <li>153 open issues, down by 5.</li>
 140 <li>555 closed issues, up by 17.</li>
 141 <li>708 issues total, up by 12.</li>
 142 </ul></li>
 143 <li><b>Details:</b><ul>
 144 <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>
 145 <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>
 146 <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>
 147 <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>
 148 <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>
 149 <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>
 150 <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>
 151 <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>
 152 <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>
 153 <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>
 154 <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>
 155 <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>
 156 <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>
 157 <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>
 158 <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>
 159 </ul></li>
 160 </ul>
 161 </li>
 162 <li>R49:
 163 2007-06-23 pre-Toronto mailing.
 164 <ul>
 165 <li><b>Summary:</b><ul>
 166 <li>158 open issues, up by 13.</li>
 167 <li>538 closed issues, up by 7.</li>
 168 <li>696 issues total, up by 20.</li>
 169 </ul></li>
 170 <li><b>Details:</b><ul>
 171 <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>
 172 <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>
 173 <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>
 174 <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>
 175 <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>
 176 </ul></li>
 177 </ul>
 178 </li>
 179 <li>R48:
 180 2007-05-06 post-Oxford mailing.
 181 <ul>
 182 <li><b>Summary:</b><ul>
 183 <li>145 open issues, down by 33.</li>
 184 <li>531 closed issues, up by 53.</li>
 185 <li>676 issues total, up by 20.</li>
 186 </ul></li>
 187 <li><b>Details:</b><ul>
 188 <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>
 189 <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>
 190 <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>
 191 <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>
 192 <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>
 193 <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>
 194 <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>
 195 <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>
 196 <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>
 197 <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>
 198 <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>
 199 <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>
 200 <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>
 201 <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>
 202 <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>
 203 </ul></li>
 204 </ul>
 205 </li>
 206 <li>R47:
 207 2007-03-09 pre-Oxford mailing.
 208 <ul>
 209 <li><b>Summary:</b><ul>
 210 <li>178 open issues, up by 37.</li>
 211 <li>478 closed issues, up by 0.</li>
 212 <li>656 issues total, up by 37.</li>
 213 </ul></li>
 214 <li><b>Details:</b><ul>
 215 <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>
 216 <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>
 217 <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>
 218 <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>
 219 <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>
 220 <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>
 221 </ul></li>
 222 </ul>
 223 </li>
 224 <li>R46:
 225 2007-01-12 mid-term mailing.
 226 <ul>
 227 <li><b>Summary:</b><ul>
 228 <li>141 open issues, up by 11.</li>
 229 <li>478 closed issues, down by 1.</li>
 230 <li>619 issues total, up by 10.</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#610">610</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
 234 </ul></li>
 235 </ul>
 236 </li>
 237 <li>R45:
 238 2006-11-03 post-Portland mailing.
 239 <ul>
 240 <li><b>Summary:</b><ul>
 241 <li>130 open issues, up by 0.</li>
 242 <li>479 closed issues, up by 17.</li>
 243 <li>609 issues total, up by 17.</li>
 244 </ul></li>
 245 <li><b>Details:</b><ul>
 246 <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>
 247 <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>
 248 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
 249 <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>
 250 <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>
 251 <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>
 252 <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>
 253 </ul></li>
 254 </ul>
 255 </li>
 256 <li>R44:
 257 2006-09-08 pre-Portland mailing.
 258 <ul>
 259 <li><b>Summary:</b><ul>
 260 <li>130 open issues, up by 6.</li>
 261 <li>462 closed issues, down by 1.</li>
 262 <li>592 issues total, up by 5.</li>
 263 </ul></li>
 264 <li><b>Details:</b><ul>
 265 <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>
 266 </ul></li>
 267 </ul>
 268 </li>
 269 <li>R43:
 270 2006-06-23 mid-term mailing.
 271 <ul>
 272 <li><b>Summary:</b><ul>
 273 <li>124 open issues, up by 14.</li>
 274 <li>463 closed issues, down by 1.</li>
 275 <li>587 issues total, up by 13.</li>
 276 </ul></li>
 277 <li><b>Details:</b><ul>
 278 <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>
 279 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
 280 <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>
 281 </ul></li>
 282 </ul>
 283 </li>
 284 <li>R42:
 285 2006-04-21 post-Berlin mailing.
 286 <ul>
 287 <li><b>Summary:</b><ul>
 288 <li>110 open issues, down by 16.</li>
 289 <li>464 closed issues, up by 24.</li>
 290 <li>574 issues total, up by 8.</li>
 291 </ul></li>
 292 <li><b>Details:</b><ul>
 293 <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>
 294 <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>
 295 <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>
 296 <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>
 297 <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>
 298 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
 299 </ul></li>
 300 </ul>
 301 </li>
 302 <li>R41:
 303 2006-02-24 pre-Berlin mailing.
 304 <ul>
 305 <li><b>Summary:</b><ul>
 306 <li>126 open issues, up by 31.</li>
 307 <li>440 closed issues, up by 0.</li>
 308 <li>566 issues total, up by 31.</li>
 309 </ul></li>
 310 <li><b>Details:</b><ul>
 311 <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>
 312 <li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
 313 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
 314 </ul></li>
 315 </ul>
 316 </li>
 317 <li>R40:
 318 2005-12-16 mid-term mailing.
 319 <ul>
 320 <li><b>Summary:</b><ul>
 321 <li>95 open issues.</li>
 322 <li>440 closed issues.</li>
 323 <li>535 issues total.</li>
 324 </ul></li>
 325 <li><b>Details:</b><ul>
 326 <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>
 327 </ul></li>
 328 </ul>
 329 </li>
 330 <li>R39:
 331 2005-10-14 post-Mont Tremblant mailing.
 332 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>.
 333 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.
 334 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.
 335 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.
 336 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.
 337 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
 338 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
 339 </li>
 340 <li>R38:
 341 2005-07-03 pre-Mont Tremblant mailing.
 342 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>.
 343 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>
 344 </li>
 345 <li>R37:
 346 2005-06 mid-term mailing.
 347 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>.
 348 </li>
 349 <li>R36:
 350 2005-04 post-Lillehammer mailing. All issues in "ready" status except
 351 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
 352 previously in "DR" status were moved to "WP".
 353 </li>
 354 <li>R35:
 355 2005-03 pre-Lillehammer mailing.
 356 </li>
 357 <li>R34:
 358 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>.
 359 </li>
 360 <li>R33:
 361 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
 362 </li>
 363 <li>R32:
 364 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
 365 new issues received after the 2004-07 mailing.  Added
 366 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>.
 367 </li>
 368 <li>R31:
 369 2004-07 mid-term mailing: reflects new proposed resolutions and
 370 new issues received after the post-Sydney mailing.  Added
 371 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>.
 372 </li>
 373 <li>R30:
 374 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 375 Voted all "Ready" issues from R29 into the working paper.
 376 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>.
 377 </li>
 378 <li>R29:
 379 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>.
 380 </li>
 381 <li>R28:
 382 Post-Kona mailing: reflects decisions made at the Kona meeting.
 383 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>.
 384 </li>
 385 <li>R27:
 386 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>.
 387 </li>
 388 <li>R26:
 389 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
 390 All issues in Ready status were voted into DR status.  All issues in
 391 DR status were voted into WP status.
 392 </li>
 393 <li>R25:
 394 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>.
 395 </li>
 396 <li>R24:
 397 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
 398 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
 399 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
 400 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
 401 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
 402 </li>
 403 <li>R23:
 404 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>.
 405 Moved issues in the TC to TC status.
 406 </li>
 407 <li>R22:
 408 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>.
 409 </li>
 410 <li>R21:
 411 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>.
 412 </li>
 413 <li>R20:
 414 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 415 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
 416 <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
 417 not discussed at the meeting.
 418
 419 All Ready issues were moved to DR status, with the exception of issues
 420 <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>.
 421
 422 Noteworthy issues discussed at Redmond include
 423 <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>,
 424 <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>.
 425 </li>
 426 <li>R19:
 427 Pre-Redmond mailing.  Added new issues
 428 <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>.
 429 </li>
 430 <li>R18:
 431 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
 432 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
 433 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>.
 434
 435 Changed status of issues
 436 <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>
 437 <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>
 438 <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>
 439 <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>
 440 <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>
 441 <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>
 442 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
 443 to DR.
 444
 445 Changed status of issues
 446 <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>
 447 <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>
 448 <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>
 449 <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>
 450 <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>
 451 <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>
 452 <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>
 453 <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>
 454 <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>
 455 to Ready.
 456
 457 Closed issues
 458 <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>
 459 <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>
 460 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
 461 as NAD.
 462
 463 </li>
 464 <li>R17:
 465 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 466 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>.
 467 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>.
 468 </li>
 469 <li>R16:
 470 post-Toronto mailing; reflects actions taken in Toronto. Added new
 471 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
 472 <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>,
 473 <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>,
 474 <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>,
 475 <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>,
 476 <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>,
 477 <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>,
 478 <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>,
 479 <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>,
 480 <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>,
 481 <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>,
 482 <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>,
 483 <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>,
 484 <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
 485 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
 486 <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
 487 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
 488 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
 489 the bug in enough places.
 490 </li>
 491 <li>R15:
 492 pre-Toronto mailing. Added issues
 493 <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
 494 changes so that we pass Weblint tests.
 495 </li>
 496 <li>R14:
 497 post-Tokyo II mailing; reflects committee actions taken in
 498 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)
 499 </li>
 500 <li>R13:
 501 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>.
 502 </li>
 503 <li>R12:
 504 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
 505 <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
 506 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
 507 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
 508 </li>
 509 <li>R11:
 510 post-Kona mailing: Updated to reflect LWG and full committee actions
 511 in Kona (99-0048/N1224). Note changed resolution of issues
 512 <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>
 513 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
 514 "closed" documents.  Changed the proposed resolution of issue
 515 <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
 516 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
 517 </li>
 518 <li>R10:
 519 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 520 <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>,
 521 <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
 522 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 523 </li>
 524 <li>R9:
 525 pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
 526 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
 527 "closed" documents. (99-0030/N1206, 25 Aug 99)
 528 </li>
 529 <li>R8:
 530 post-Dublin mailing. Updated to reflect LWG and full committee actions
 531 in Dublin. (99-0016/N1193, 21 Apr 99)
 532 </li>
 533 <li>R7:
 534 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>,
 535 <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>,
 536 <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>,
 537 <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)
 538 </li>
 539 <li>R6:
 540 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>,
 541 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 542 </li>
 543 <li>R5:
 544 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
 545 <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
 546 for making list public. (30 Dec 98)
 547 </li>
 548 <li>R4:
 549 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
 550 <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
 551 issues corrected. (22 Oct 98)
 552 </li>
 553 <li>R3:
 554 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>
 555 added, many issues updated to reflect LWG consensus (12 Oct 98)
 556 </li>
 557 <li>R2:
 558 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,
 559 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
 560 </li>
 561 <li>R1:
 562 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
 563 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
 564 </li>
 565 </ul>
 566
 567 <h2><a name="Status"></a>Issue Status</h2>
 568
 569   <p><b><a name="New">New</a></b> - The issue has not yet been
 570   reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a
 571   suggestion from the issue submitter, and should not be construed as
 572   the view of LWG.</p>
 573
 574   <p><b><a name="Open">Open</a></b> - The LWG has discussed the issue
 575   but is not yet ready to move the issue forward. There are several
 576   possible reasons for open status:</p>
 577      <ul>
 578         <li>Consensus may have not yet have been reached as to how to deal
 579             with the issue.</li>
 580         <li>Informal consensus may have been reached, but the LWG awaits
 581             exact <b>Proposed Resolution</b> wording for review.</li>
 582         <li>The LWG wishes to consult additional technical experts before
 583             proceeding.</li>
 584         <li>The issue may require further study.</li>
 585      </ul>
 586
 587   <p>A <b>Proposed Resolution</b> for an open issue is still not be
 588   construed as the view of LWG. Comments on the current state of
 589   discussions are often given at the end of open issues in an italic
 590   font. Such comments are for information only and should not be given
 591   undue importance.</p>
 592
 593   <p><b><a name="Dup">Dup</a></b> - The LWG has reached consensus that
 594   the issue is a duplicate of another issue, and will not be further
 595   dealt with. A <b>Rationale</b> identifies the duplicated issue's
 596   issue number.  </p>
 597
 598   <p><b><a name="NAD">NAD</a></b> - The LWG has reached consensus that
 599   the issue is not a defect in the Standard.</p>
 600
 601   <p><b><a name="NAD Editorial">NAD Editorial</a></b> - The LWG has reached consensus that
 602   the issue can either be handled editorially, or is handled by a paper (usually
 603   linked to in the rationale).</p>
 604
 605   <p><b><a name="NAD Future">NAD Future</a></b> - In addition to the regular
 606   status, the LWG believes that this issue should be revisited at the
 607   next revision of the standard.</p>
 608
 609   <p><b><a name="Review">Review</a></b> - Exact wording of a
 610   <b>Proposed Resolution</b> is now available for review on an issue
 611   for which the LWG previously reached informal consensus.</p>
 612
 613   <p><b><a name="Tentatively Ready">Tentatively Ready</a></b> - The issue has
 614   been reviewed online, but not in a meeting, and some support has been formed
 615   for the proposed resolution.  Tentatively Ready issues may be moved to Ready
 616   and forwarded to full committee within the same meeting.  Unlike Ready issues
 617   they will be reviewed in subcommittee prior to forwarding to full committee.</p>
 618
 619   <p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus
 620   that the issue is a defect in the Standard, the <b>Proposed
 621   Resolution</b> is correct, and the issue is ready to forward to the
 622   full committee for further action as a Defect Report (DR).</p>
 623
 624   <p><b><a name="DR">DR</a></b> - (Defect Report) - The full J16
 625   committee has voted to forward the issue to the Project Editor to be
 626   processed as a Potential Defect Report. The Project Editor reviews
 627   the issue, and then forwards it to the WG21 Convenor, who returns it
 628   to the full committee for final disposition. This issues list
 629   accords the status of DR to all these Defect Reports regardless of
 630   where they are in that process.</p>
 631
 632   <p><b><a name="TC">TC</a></b> - (Technical Corrigenda) - The full
 633   WG21 committee has voted to accept the Defect Report's Proposed
 634   Resolution as a Technical Corrigenda.  Action on this issue is thus
 635   complete and no further action is possible under ISO rules.</p>
 636
 637   <p><b><a name="TRDec">TRDec</a></b> - (Decimal TR defect) - The
 638   LWG has voted to accept the Defect Report's Proposed
 639   Resolution into the Decimal TR.  Action on this issue is thus
 640   complete and no further action is expected.</p>
 641
 642   <p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed
 643   resolution has not been accepted as a Technical Corrigendum, but
 644   the full WG21 committee has voted to apply the Defect Report's Proposed
 645   Resolution to the working paper.</p>
 646
 647   <p><b>Pending</b> - This is a <i>status qualifier</i>.  When prepended to
 648   a status this indicates the issue has been
 649   processed by the committee, and a decision has been made to move the issue to
 650   the associated unqualified status.  However for logistical reasons the indicated
 651   outcome of the issue has not yet appeared in the latest working paper.
 652
 653   </p><p>Issues are always given the status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> when
 654   they first appear on the issues list. They may progress to
 655   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> while the LWG
 656   is actively working on them. When the LWG has reached consensus on
 657   the disposition of an issue, the status will then change to
 658   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>, or
 659   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> as appropriate.  Once the full J16 committee votes to
 660   forward Ready issues to the Project Editor, they are given the
 661   status of Defect Report ( <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>). These in turn may
 662   become the basis for Technical Corrigenda (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>),
 663   or are closed without action other than a Record of Response
 664   (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a> ). The intent of this LWG process is that
 665   only issues which are truly defects in the Standard move to the
 666   formal ISO DR status.
 667   </p>
 668
 669
 670 <h2>Active Issues</h2>
 671 <hr>
 672 <h3><a name="23"></a>23. Num_get overflow result</h3>
 673 <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#Open">Open</a>
 674  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
 675 <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>
 676 <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>
 677 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 678 <p><b>Discussion:</b></p>
 679 <p>The current description of numeric input does not account for the
 680 possibility of overflow. This is an implicit result of changing the
 681 description to rely on the definition of scanf() (which fails to
 682 report overflow), and conflicts with the documented behavior of
 683 traditional and current implementations. </p>
 684
 685 <p>Users expect, when reading a character sequence that results in a
 686 value unrepresentable in the specified type, to have an error
 687 reported. The standard as written does not permit this. </p>
 688
 689 <p><b>Further comments from Dietmar:</b></p>
 690
 691 <p>
 692 I don't feel comfortable with the proposed resolution to issue 23: It
 693 kind of simplifies the issue to much. Here is what is going on:
 694 </p>
 695
 696 <p>
 697 Currently, the behavior of numeric overflow is rather counter intuitive
 698 and hard to trace, so I will describe it briefly:
 699 </p>
 700
 701 <ul>
 702   <li>
 703     According to 22.2.2.1.2 [facet.num.get.virtuals]
 704     paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
 705     return an input error; otherwise a value is converted to the rules
 706     of <tt>scanf</tt>.
 707   </li>
 708   <li>
 709     <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>.
 710   </li>
 711   <li>
 712     <tt>fscanf()</tt> returns an input failure if during conversion no
 713     character matching the conversion specification could be extracted
 714     before reaching EOF. This is the only reason for <tt>fscanf()</tt>
 715     to fail due to an input error and clearly does not apply to the case
 716     of overflow.
 717   </li>
 718   <li>
 719     Thus, the conversion is performed according to the rules of
 720     <tt>fscanf()</tt> which basically says that <tt>strtod</tt>,
 721     <tt>strtol()</tt>, etc. are to be used for the conversion.
 722   </li>
 723   <li>
 724     The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as
 725     many matching characters as there are and on overflow continue to
 726     consume matching characters but also return a value identical to
 727     the maximum (or minimum for signed types if there was a leading minus)
 728     value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>.
 729   </li>
 730   <li>
 731     Thus, according to the current wording in the standard, overflows
 732     can be detected! All what is to be done is to check <tt>errno</tt>
 733     after reading an element and, of course, clearing <tt>errno</tt>
 734     before trying a conversion. With the current wording, it can be
 735     detected whether the overflow was due to a positive or negative
 736     number for signed types.
 737   </li>
 738 </ul>
 739
 740 <p><b>Further discussion from Redmond:</b></p>
 741
 742 <p>The basic problem is that we've defined our behavior,
 743 including our error-reporting behavior, in terms of C90.  However,
 744 C90's method of reporting overflow in scanf is not technically an
 745 "input error".  The <tt>strto_*</tt> functions are more precise.</p>
 746
 747 <p>There was general consensus that <tt>failbit</tt> should be set
 748 upon overflow.  We considered three options based on this:</p>
 749 <ol>
 750 <li>Set failbit upon conversion error (including overflow), and
 751     don't store any value.</li>
 752 <li>Set failbit upon conversion error, and also set <tt>errno</tt> to
 753     indicated the precise nature of the error.</li>
 754 <li>Set failbit upon conversion error.  If the error was due to
 755     overflow, store +-numeric_limits&lt;T&gt;::max() as an
 756     overflow indication.</li>
 757 </ol>
 758
 759 <p>Straw poll: (1) 5; (2) 0; (3) 8.</p>
 760
 761
 762 <p>Discussed at Lillehammer.  General outline of what we want the
 763   solution to look like: we want to say that overflow is an error, and
 764   provide a way to distinguish overflow from other kinds of errors.
 765   Choose candidate field the same way scanf does, but don't describe
 766   the rest of the process in terms of format.  If a finite input field
 767   is too large (positive or negative) to be represented as a finite
 768   value, then set failbit and assign the nearest representable value.
 769   Bill will provide wording.</p>
 770
 771 <p>
 772 Discussed at Toronto:
 773 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
 774 is in alignment with the direction we wanted to go with in Lillehammer.  Bill
 775 to work on.
 776 </p>
 777
 778
 779
 780 <p><b>Proposed resolution:</b></p>
 781
 782 <p>
 783 Change 22.2.2.1.2 [facet.num.get.virtuals], end of p3:
 784 </p>
 785
 786 <blockquote>
 787 <p>
 788 <b>Stage 3:</b> <del>The result of stage 2 processing can be one of</del>
 789 <ins>The sequence of <tt>char</tt>s accumulated in stage 2 (the field) is
 790 converted to a numeric value by the rules of one of the functions declared
 791 in the header <tt>&lt;cstdlib&gt;</tt>:</ins>
 792 </p>
 793 <ul>
 794 <li>
 795 <del>A sequence of <tt>char</tt>s has been accumulated in stage 2 that is
 796 converted (according to the rules of <tt>scanf</tt>) to a value of the
 797 type of <i>val</i>. This value is stored in <i>val</i> and <tt>ios_base::goodbit</tt> is
 798 stored in <i>err</i>.</del>
 799 <ins>For a signed integer value, the function <tt>strtoll</tt>.</ins>
 800 </li>
 801 <li>
 802 <del>The sequence of <tt>char</tt>s accumulated in stage 2 would have caused
 803 <tt>scanf</tt> to report an input failure. <tt>ios_base::failbit</tt> is
 804 assigned to <i>err</i>.</del>
 805 <ins>For an unsigned integer value, the function <tt>strtoull</tt>.</ins>
 806 </li>
 807 <li>
 808 <ins>For a floating-point value, the function <tt>strtold</tt>.</ins>
 809 </li>
 810 </ul>
 811 <p>
 812 <ins>The numeric value to be stored can be one of:</ins>
 813 </p>
 814 <ul>
 815 <li><ins>zero, if the conversion function fails to convert the entire field.
 816 <tt>ios_base::failbit</tt> is assigned to err.</ins></li>
 817 <li><ins>the most positive representable value, if the field represents a value
 818 too large positive to be represented in <i>val</i>. <tt>ios_base::failbit</tt> is assigned
 819 to <i>err</i>.</ins></li>
 820 <li><ins>the most negative representable value (zero for unsigned integer), if
 821 the field represents a value too large negative to be represented in <i>val</i>.
 822 <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins></li>
 823 <li><ins>the converted value, otherwise.</ins></li>
 824 </ul>
 825
 826 <p><ins>
 827 The resultant numeric value is stored in <i>val</i>.
 828 </ins></p>
 829 </blockquote>
 830
 831 <p>
 832 Change 22.2.2.1.2 [facet.num.get.virtuals], p6-p7:
 833 </p>
 834
 835 <blockquote>
 836 <pre>iter_type do_get(iter_type <i>in</i>, iter_type <i>end</i>, ios_base&amp; <i>str</i>,
 837                  ios_base::iostate&amp; <i>err</i>, bool&amp; <i>val</i>) const;
 838 </pre>
 839 <blockquote>
 840 <p>
 841 -6- <i>Effects:</i> If
 842 <tt>(<i>str</i>.flags()&amp;ios_base::boolalpha)==0</tt> then input
 843 proceeds as it would for a <tt>long</tt> except that if a value is being
 844 stored into <i>val</i>, the value is determined according to the
 845 following: If the value to be stored is 0 then <tt>false</tt> is stored.
 846 If the value is 1 then <tt>true</tt> is stored. Otherwise
 847 <del><tt><i>err</i>|=ios_base::failbit</tt> is performed and no value</del> <ins><tt>true</tt></ins> is
 848 stored<del>.</del> <ins>and <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins>
 849 </p>
 850 <p>
 851 -7- Otherwise target sequences are determined "as if" by calling the
 852 members <tt>falsename()</tt> and <tt>truename()</tt> of the facet
 853 obtained by <tt>use_facet&lt;numpunct&lt;charT&gt;
 854 &gt;(<i>str</i>.getloc())</tt>. Successive characters in the range
 855 <tt>[<i>in</i>,<i>end</i>)</tt> (see 23.1.1) are obtained and matched
 856 against corresponding positions in the target sequences only as
 857 necessary to identify a unique match. The input iterator <i>in</i> is
 858 compared to <i>end</i> only when necessary to obtain a character. If <del>and
 859 only if</del> a target sequence is uniquely matched, <i>val</i> is set to the
 860 corresponding value. <ins>Otherwise <tt>false</tt> is stored and <tt>ios_base::failbit</tt>
 861 is assigned to <i>err</i>.</ins>
 862 </p>
 863 </blockquote>
 864 </blockquote>
 865
 866
 867
 868
 869
 870 <hr>
 871 <h3><a name="96"></a>96. Vector&lt;bool&gt; is not a container</h3>
 872 <p><b>Section:</b> 23.2.5 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
 873  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
 874 <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>
 875 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 876 <p><b>Discussion:</b></p>
 877 <p><tt>vector&lt;bool&gt;</tt> is not a container as its reference and
 878 pointer types are not references and pointers. </p>
 879
 880 <p>Also it forces everyone to have a space optimization instead of a
 881 speed one.</p>
 882
 883 <p><b>See also:</b> 99-0008 == N1185 Vector&lt;bool&gt; is
 884 Nonconforming, Forces Optimization Choice.</p>
 885
 886 <p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>
 887
 888
 889 <p><i>[In Dublin many present felt that failure to meet Container
 890 requirements was a defect. There was disagreement as to whether
 891 or not the optimization requirements constituted a defect.]</i></p>
 892
 893
 894 <p><i>[The LWG looked at the following resolutions in some detail:
 895 <br>
 896 &nbsp;&nbsp;&nbsp;&nbsp; * Not A Defect.<br>
 897 &nbsp;&nbsp;&nbsp;&nbsp; * Add a note explaining that vector&lt;bool&gt; does not meet
 898 Container requirements.<br>
 899 &nbsp;&nbsp;&nbsp;&nbsp; * Remove vector&lt;bool&gt;.<br>
 900 &nbsp;&nbsp;&nbsp;&nbsp; * Add a new category of container requirements which
 901 vector&lt;bool&gt; would meet.<br>
 902 &nbsp;&nbsp;&nbsp;&nbsp; * Rename vector&lt;bool&gt;.<br>
 903 <br>
 904 No alternative had strong, wide-spread, support and every alternative
 905 had at least one "over my dead body" response.<br>
 906 <br>
 907 There was also mention of a transition scheme something like (1) add
 908 vector_bool and deprecate vector&lt;bool&gt; in the next standard. (2)
 909 Remove vector&lt;bool&gt; in the following standard.]</i></p>
 910
 911
 912 <p><i>[Modifying container requirements to permit returning proxies
 913 (thus allowing container requirements conforming vector&lt;bool&gt;)
 914 was also discussed.]</i></p>
 915
 916
 917 <p><i>[It was also noted that there is a partial but ugly workaround in
 918 that vector&lt;bool&gt; may be further specialized with a customer
 919 allocator.]</i></p>
 920
 921
 922 <p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
 923 vector&lt;bool&gt;: More Problems, Better Solutions. Much discussion
 924 of a two step approach: a) deprecate, b) provide replacement under a
 925 new name.  LWG straw vote on that: 1-favor, 11-could live with, 2-over
 926 my dead body.  This resolution was mentioned in the LWG report to the
 927 full committee, where several additional committee members indicated
 928 over-my-dead-body positions.]</i></p>
 929
 930
 931 <p>Discussed at Lillehammer.  General agreement that we should
 932   deprecate vector&lt;bool&gt; and introduce this functionality under
 933   a different name, e.g. bit_vector.  This might make it possible to
 934   remove the vector&lt;bool&gt; specialization in the standard that comes
 935   after C++0x. There was also a suggestion that
 936   in C++0x we could additional say that it's implementation defined
 937   whether vector&lt;bool&gt; refers to the specialization or to the
 938   primary template, but there wasn't general agreement that this was a
 939   good idea.</p>
 940
 941 <p>We need a paper for the new bit_vector class.</p>
 942
 943
 944
 945
 946 <p><b>Proposed resolution:</b></p>
 947 <p>
 948 We now have:
 949 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
 950 and
 951 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html">N2160</a>.
 952 </p>
 953
 954 <p><i>[
 955 Batavia: The LWG feels we need something closer to SGI's <tt>bitvector</tt> to ease migration
 956 from <tt>vector&lt;bool&gt;</tt>.  Although some of the funcitonality from
 957 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
 958 could well be used in such a template.  The concern is easing the API migration for those
 959 users who want to continue using a bit-packed container.  Alan and Beman to work.
 960 ]</i></p>
 961
 962
 963
 964
 965
 966
 967 <hr>
 968 <h3><a name="255"></a>255. Why do <tt>basic_streambuf&lt;&gt;::pbump()</tt> and <tt>gbump()</tt> take an int?</h3>
 969 <p><b>Section:</b> 27.5.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
 970  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-12</p>
 971 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf">issues</a> in [streambuf].</p>
 972 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
 973 <p><b>Discussion:</b></p>
 974 <p>
 975 The basic_streambuf members gbump() and pbump() are specified to take an
 976 int argument. This requirement prevents the functions from effectively
 977 manipulating buffers larger than std::numeric_limits&lt;int&gt;::max()
 978 characters. It also makes the common use case for these functions
 979 somewhat difficult as many compilers will issue a warning when an
 980 argument of type larger than int (such as ptrdiff_t on LLP64
 981 architectures) is passed to either of the function. Since it's often the
 982 result of the subtraction of two pointers that is passed to the
 983 functions, a cast is necessary to silence such warnings. Finally, the
 984 usage of a native type in the functions signatures is inconsistent with
 985 other member functions (such as sgetn() and sputn()) that manipulate the
 986 underlying character buffer. Those functions take a streamsize argument.
 987 </p>
 988
 989
 990 <p><b>Proposed resolution:</b></p>
 991 <p>
 992 Change the signatures of these functions in the synopsis of template
 993 class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4
 994 and 27.5.2.3.2, p4) to take a streamsize argument.
 995 </p>
 996
 997 <p>
 998 Although this change has the potential of changing the ABI of the
 999 library, the change will affect only platforms where int is different
1000 than the definition of streamsize. However, since both functions are
1001 typically inline (they are on all known implementations), even on such
1002 platforms the change will not affect any user code unless it explicitly
1003 relies on the existing type of the functions (e.g., by taking their
1004 address). Such a possibility is IMO quite remote.
1005 </p>
1006
1007 <p>
1008 Alternate Suggestion from Howard Hinnant, c++std-lib-7780:
1009 </p>
1010
1011 <p>
1012 This is something of a nit, but I'm wondering if streamoff wouldn't be a
1013 better choice than streamsize.  The argument to pbump and gbump MUST be
1014 signed.  But the standard has this to say about streamsize
1015 (27.4.1/2/Footnote):
1016 </p>
1017
1018 <blockquote><p>
1019      [Footnote: streamsize is used in most places where ISO C would use
1020      size_t.  Most of the uses of streamsize could use size_t, except for
1021      the strstreambuf constructors, which require negative values. It
1022      should probably be the signed type corresponding to size_t (which is
1023      what Posix.2 calls ssize_t). --- end footnote]
1024 </p></blockquote>
1025
1026 <p>
1027 This seems a little weak for the argument to pbump and gbump.  Should we
1028 ever really get rid of strstream, this footnote might go with it, along
1029 with the reason to make streamsize signed.
1030 </p>
1031
1032
1033 <p><b>Rationale:</b></p>
1034 <p>The LWG believes this change is too big for now.  We may wish to
1035 reconsider this for a future revision of the standard.  One
1036 possibility is overloading pbump, rather than changing the
1037 signature.</p>
1038 <p><i>[
1039 [2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)]
1040 ]</i></p>
1041
1042
1043
1044
1045
1046 <hr>
1047 <h3><a name="290"></a>290. Requirements to for_each and its function object</h3>
1048 <p><b>Section:</b> 25.1.1 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1049  <b>Submitter:</b> Angelika Langer <b>Date:</b> 2001-01-03</p>
1050 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
1051 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1052 <p><b>Discussion:</b></p>
1053 <p>The specification of the for_each algorithm does not have a
1054 "Requires" section, which means that there are no
1055 restrictions imposed on the function object whatsoever. In essence it
1056 means that I can provide any function object with arbitrary side
1057 effects and I can still expect a predictable result. In particular I
1058 can expect that the function object is applied exactly last - first
1059 times, which is promised in the "Complexity" section.
1060 </p>
1061
1062 <p>I don't see how any implementation can give such a guarantee
1063 without imposing requirements on the function object.
1064 </p>
1065
1066 <p>Just as an example: consider a function object that removes
1067 elements from the input sequence.  In that case, what does the
1068 complexity guarantee (applies f exactly last - first times) mean?
1069 </p>
1070
1071 <p>One can argue that this is obviously a nonsensical application and
1072 a theoretical case, which unfortunately it isn't.  I have seen
1073 programmers shooting themselves in the foot this way, and they did not
1074 understand that there are restrictions even if the description of the
1075 algorithm does not say so.
1076 </p>
1077 <p><i>[Lillehammer: This is more general than for_each.  We don't want
1078   the function object in transform invalidiating iterators
1079   either. There should be a note somewhere in clause 17 (17, not 25)
1080   saying that user code operating on a range may not invalidate
1081   iterators unless otherwise specified.  Bill will provide wording.]</i></p>
1082
1083
1084
1085 <p><b>Proposed resolution:</b></p>
1086
1087
1088
1089
1090
1091
1092 <hr>
1093 <h3><a name="299"></a>299. Incorrect return types for iterator dereference</h3>
1094 <p><b>Section:</b> 24.1.4 [bidirectional.iterators], 24.1.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1095  <b>Submitter:</b> John Potter <b>Date:</b> 2001-01-22</p>
1096 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bidirectional.iterators">issues</a> in [bidirectional.iterators].</p>
1097 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1098 <p><b>Discussion:</b></p>
1099 <p>
1100 In section 24.1.4 [bidirectional.iterators],
1101 Table 75 gives the return type of *r-- as convertible to T.  This is
1102 not consistent with Table 74 which gives the return type of *r++ as
1103 T&amp;.  *r++ = t is valid while *r-- = t is invalid.
1104 </p>
1105
1106 <p>
1107 In section 24.1.5 [random.access.iterators],
1108 Table 76 gives the return type of a[n] as convertible to T.  This is
1109 not consistent with the semantics of *(a + n) which returns T&amp; by
1110 Table 74.  *(a + n) = t is valid while a[n] = t is invalid.
1111 </p>
1112
1113 <p>
1114 Discussion from the Copenhagen meeting: the first part is
1115 uncontroversial.  The second part, operator[] for Random Access
1116 Iterators, requires more thought.  There are reasonable arguments on
1117 both sides.  Return by value from operator[] enables some potentially
1118 useful iterators, e.g. a random access "iota iterator" (a.k.a
1119 "counting iterator" or "int iterator").  There isn't any obvious way
1120 to do this with return-by-reference, since the reference would be to a
1121 temporary.  On the other hand, <tt>reverse_iterator</tt> takes an
1122 arbitrary Random Access Iterator as template argument, and its
1123 operator[] returns by reference.  If we decided that the return type
1124 in Table 76 was correct, we would have to change
1125 <tt>reverse_iterator</tt>.  This change would probably affect user
1126 code.
1127 </p>
1128
1129 <p>
1130 History: the contradiction between <tt>reverse_iterator</tt> and the
1131 Random Access Iterator requirements has been present from an early
1132 stage.  In both the STL proposal adopted by the committee
1133 (N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
1134 Stepanov and Lee), the Random Access Iterator requirements say that
1135 operator[]'s return value is "convertible to T".  In N0527
1136 reverse_iterator's operator[] returns by value, but in HPL-95-11
1137 (R.1), and in the STL implementation that HP released to the public,
1138 reverse_iterator's operator[] returns by reference.  In 1995, the
1139 standard was amended to reflect the contents of HPL-95-11 (R.1).  The
1140 original intent for operator[] is unclear.
1141 </p>
1142
1143 <p>
1144 In the long term it may be desirable to add more fine-grained
1145 iterator requirements, so that access method and traversal strategy
1146 can be decoupled.  (See "Improved Iterator Categories and
1147 Requirements", N1297 = 01-0011, by Jeremy Siek.)  Any decisions
1148 about issue 299 should keep this possibility in mind.
1149 </p>
1150
1151 <p>Further discussion: I propose a compromise between John Potter's
1152 resolution, which requires <tt>T&amp;</tt> as the return type of
1153 <tt>a[n]</tt>, and the current wording, which requires convertible to
1154 <tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt>
1155 for the return type of the expression <tt>a[n]</tt>, but to also add
1156 <tt>a[n] = t</tt> as a valid expression. This compromise "saves" the
1157 common case uses of random access iterators, while at the same time
1158 allowing iterators such as counting iterator and caching file
1159 iterators to remain random access iterators (iterators where the
1160 lifetime of the object returned by <tt>operator*()</tt> is tied to the
1161 lifetime of the iterator).
1162 </p>
1163
1164 <p>
1165 Note that the compromise resolution necessitates a change to
1166 <tt>reverse_iterator</tt>. It would need to use a proxy to support
1167 <tt>a[n] = t</tt>.
1168 </p>
1169
1170 <p>
1171 Note also there is one kind of mutable random access iterator that
1172 will no longer meet the new requirements. Currently, iterators that
1173 return an r-value from <tt>operator[]</tt> meet the requirements for a
1174 mutable random access iterartor, even though the expression <tt>a[n] =
1175 t</tt> will only modify a temporary that goes away. With this proposed
1176 resolution, <tt>a[n] = t</tt> will be required to have the same
1177 operational semantics as <tt>*(a + n) = t</tt>.
1178 </p>
1179
1180
1181
1182 <p><b>Proposed resolution:</b></p>
1183
1184 <p>
1185 In section 24.1.4 [lib.bidirectdional.iterators], change the return
1186 type in table 75 from "convertible to <tt>T</tt>" to
1187 <tt>T&amp;</tt>.
1188 </p>
1189
1190 <p>
1191 In section 24.1.5 [lib.random.access.iterators], change the
1192 operational semantics for <tt>a[n]</tt> to " the r-value of
1193 <tt>a[n]</tt> is equivalent to the r-value of <tt>*(a +
1194 n)</tt>". Add a new row in the table for the expression <tt>a[n] = t</tt>
1195 with a return type of convertible to <tt>T</tt> and operational semantics of
1196 <tt>*(a + n) = t</tt>.
1197 </p>
1198
1199 <p><i>[Lillehammer: Real problem, but should be addressed as part of
1200   iterator redesign]</i></p>
1201
1202
1203
1204
1205
1206
1207
1208
1209 <hr>
1210 <h3><a name="309"></a>309. Does sentry catch exceptions?</h3>
1211 <p><b>Section:</b> 27.6 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1212  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-19</p>
1213 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iostream.format">active issues</a> in [iostream.format].</p>
1214 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p>
1215 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1216 <p><b>Discussion:</b></p>
1217 <p>
1218 The descriptions of the constructors of basic_istream&lt;&gt;::sentry
1219 (27.6.1.1.3 [istream::sentry]) and basic_ostream&lt;&gt;::sentry
1220 (27.6.2.4 [ostream::sentry]) do not explain what the functions do in
1221 case an exception is thrown while they execute. Some current
1222 implementations allow all exceptions to propagate, others catch them
1223 and set ios_base::badbit instead, still others catch some but let
1224 others propagate.
1225 </p>
1226
1227 <p>
1228 The text also mentions that the functions may call setstate(failbit)
1229 (without actually saying on what object, but presumably the stream
1230 argument is meant).  That may have been fine for
1231 basic_istream&lt;&gt;::sentry prior to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, since
1232 the function performs an input operation which may fail. However,
1233 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a> amends 27.6.1.1.3 [istream::sentry], p2 to
1234 clarify that the function should actually call setstate(failbit |
1235 eofbit), so the sentence in p3 is redundant or even somewhat
1236 contradictory.
1237 </p>
1238
1239 <p>
1240 The same sentence that appears in 27.6.2.4 [ostream::sentry], p3
1241 doesn't seem to be very meaningful for basic_istream&lt;&gt;::sentry
1242 which performs no input. It is actually rather misleading since it
1243 would appear to guide library implementers to calling
1244 setstate(failbit) when os.tie()-&gt;flush(), the only called function,
1245 throws an exception (typically, it's badbit that's set in response to
1246 such an event).
1247 </p>
1248
1249 <p><b>Additional comments from Martin, who isn't comfortable with the
1250     current proposed resolution</b> (see c++std-lib-11530)</p>
1251
1252 <p>
1253 The istream::sentry ctor says nothing about how the function
1254 deals with exemptions (27.6.1.1.2, p1 says that the class is
1255 responsible for doing "exception safe"(*) prefix and suffix
1256 operations but it doesn't explain what level of exception
1257 safety the class promises to provide). The mockup example
1258 of a "typical implementation of the sentry ctor" given in
1259 27.6.1.1.2, p6, removed in ISO/IEC 14882:2003, doesn't show
1260 exception handling, either. Since the ctor is not classified
1261 as a formatted or unformatted input function, the text in
1262 27.6.1.1, p1 through p4 does not apply. All this would seem
1263 to suggest that the sentry ctor should not catch or in any
1264 way handle exceptions thrown from any functions it may call.
1265 Thus, the typical implementation of an istream extractor may
1266 look something like [1].
1267 </p>
1268
1269 <p>
1270 The problem with [1] is that while it correctly sets ios::badbit
1271 if an exception is thrown from one of the functions called from
1272 the sentry ctor, if the sentry ctor reaches EOF while extracting
1273 whitespace from a stream that has eofbit or failbit set in
1274 exceptions(), it will cause an ios::failure to be thrown, which
1275 will in turn cause the extractor to set ios::badbit.
1276 </p>
1277
1278 <p>
1279 The only straightforward way to prevent this behavior is to
1280 move the definition of the sentry object in the extractor
1281 above the try block (as suggested by the example in 22.2.8,
1282 p9 and also indirectly supported by 27.6.1.3, p1). See [2].
1283 But such an implementation will allow exceptions thrown from
1284 functions called from the ctor to freely propagate to the
1285 caller regardless of the setting of ios::badbit in the stream
1286 object's exceptions().
1287 </p>
1288
1289 <p>
1290 So since neither [1] nor [2] behaves as expected, the only
1291 possible solution is to have the sentry ctor catch exceptions
1292 thrown from called functions, set badbit, and propagate those
1293 exceptions if badbit is also set in exceptions(). (Another
1294 solution exists that deals with both kinds of sentries, but
1295 the code is non-obvious and cumbersome -- see [3].)
1296 </p>
1297
1298 <p>
1299 Please note that, as the issue points out, current libraries
1300 do not behave consistently, suggesting  that implementors are
1301 not quite clear on the exception handling in istream::sentry,
1302 despite the fact that some LWG members might feel otherwise.
1303 (As documented by the parenthetical comment here:
1304 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1480.html#309)
1305 </p>
1306
1307 <p>
1308 Also please note that those LWG members who in Copenhagen
1309 felt that "a sentry's constructor should not catch exceptions,
1310 because sentries should only be used within (un)formatted input
1311 functions and that exception handling is the responsibility of
1312 those functions, not of the sentries," as noted here
1313 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1310.html#309
1314 would in effect be either arguing for the behavior described
1315 in [1] or for extractors implemented along the lines of [3].
1316 </p>
1317
1318 <p>
1319 The original proposed resolution (Revision 25 of the issues
1320 list) clarifies the role of the sentry ctor WRT exception
1321 handling by making it clear that extractors (both library
1322 or user-defined) should be implemented along the lines of
1323 [2] (as opposed to [1]) and that no exception thrown from
1324 the callees should propagate out of either function unless
1325 badbit is also set in exceptions().
1326 </p>
1327
1328
1329 <p>[1] Extractor that catches exceptions thrown from sentry:</p>
1330
1331 <blockquote>
1332 <pre>struct S { long i; };
1333
1334 istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
1335 {
1336     ios::iostate err = ios::goodbit;
1337     try {
1338         const istream::sentry guard (strm, false);
1339         if (guard) {
1340             use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
1341                 .get (istreambuf_iterator&lt;char&gt;(strm),
1342                       istreambuf_iterator&lt;char&gt;(),
1343                       strm, err, s.i);
1344         }
1345     }
1346     catch (...) {
1347         bool rethrow;
1348         try {
1349             strm.setstate (ios::badbit);
1350             rethrow = false;
1351         }
1352         catch (...) {
1353             rethrow = true;
1354         }
1355         if (rethrow)
1356             throw;
1357     }
1358     if (err)
1359         strm.setstate (err);
1360     return strm;
1361 }
1362 </pre>
1363 </blockquote>
1364
1365 <p>[2] Extractor that propagates exceptions thrown from sentry:</p>
1366
1367 <blockquote>
1368 <pre>istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
1369 {
1370     istream::sentry guard (strm, false);
1371     if (guard) {
1372         ios::iostate err = ios::goodbit;
1373         try {
1374             use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
1375                 .get (istreambuf_iterator&lt;char&gt;(strm),
1376                       istreambuf_iterator&lt;char&gt;(),
1377                       strm, err, s.i);
1378         }
1379         catch (...) {
1380             bool rethrow;
1381             try {
1382                 strm.setstate (ios::badbit);
1383                 rethrow = false;
1384             }
1385             catch (...) {
1386                 rethrow = true;
1387             }
1388             if (rethrow)
1389                 throw;
1390         }
1391         if (err)
1392             strm.setstate (err);
1393     }
1394     return strm;
1395 }
1396 </pre>
1397 </blockquote>
1398
1399 <p>
1400 [3] Extractor that catches exceptions thrown from sentry
1401 but doesn't set badbit if the exception was thrown as a
1402 result of a call to strm.clear().
1403 </p>
1404
1405 <blockquote>
1406 <pre>istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
1407 {
1408     const ios::iostate state = strm.rdstate ();
1409     const ios::iostate except = strm.exceptions ();
1410     ios::iostate err = std::ios::goodbit;
1411     bool thrown = true;
1412     try {
1413         const istream::sentry guard (strm, false);
1414         thrown = false;
1415         if (guard) {
1416             use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
1417                 .get (istreambuf_iterator&lt;char&gt;(strm),
1418                       istreambuf_iterator&lt;char&gt;(),
1419                       strm, err, s.i);
1420         }
1421     }
1422     catch (...) {
1423         if (thrown &amp;&amp; state &amp; except)
1424             throw;
1425         try {
1426             strm.setstate (ios::badbit);
1427             thrown = false;
1428         }
1429         catch (...) {
1430             thrown = true;
1431         }
1432         if (thrown)
1433             throw;
1434     }
1435     if (err)
1436         strm.setstate (err);
1437
1438     return strm;
1439 }
1440 </pre>
1441 </blockquote>
1442
1443 <p>
1444 [Pre-Berlin] Reopened at the request of Paolo Carlini and Steve Clamage.
1445 </p>
1446
1447 <p>
1448 [Pre-Portland] A relevant newsgroup post:
1449 </p>
1450
1451 <p>
1452 The current proposed resolution of issue #309
1453 (http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309)  is
1454 unacceptable.   I write commerical software and coding around this
1455 makes my code ugly, non-intuitive, and requires comments referring
1456 people to this very issue.   Following is the full explanation of my
1457 experience.
1458 </p>
1459 <p>
1460 In the course of writing software for commercial use, I constructed
1461 std::ifstream's based on user-supplied pathnames on typical POSIX
1462 systems.
1463 </p>
1464 <p>
1465 It was expected that some files that opened successfully might not read
1466 successfully -- such as a pathname which actually refered to a
1467 directory.   Intuitively, I expected the streambuffer underflow() code
1468 to throw an exception in this situation, and recent implementations of
1469 libstdc++'s basic_filebuf do just that (as well as many of my own
1470 custom streambufs).
1471 </p>
1472 <p>
1473 I also intuitively expected that the istream code would convert these
1474 exceptions to the "badbit' set on the stream object, because I had not
1475 requested exceptions.    I refer to 27.6.1.1. P4.
1476 </p>
1477 <p>
1478 However, this was not the case on at least two implementations -- if
1479 the first thing I did with an istream was call operator&gt;&gt;( T&amp; ) for T
1480 among the basic arithmetic types and std::string.   Looking further I
1481 found that the sentry's constructor was invoking the exception when it
1482 pre-scanned for whitespace, and the extractor function (operator&gt;&gt;())
1483 was not catching exceptions in this situation.
1484 </p>
1485 <p>
1486 So, I was in a situation where setting 'noskipws' would change the
1487 istream's behavior even though no characters (whitespace or not) could
1488 ever be successfully read.
1489 </p>
1490 <p>
1491 Also, calling .peek() on the istream before calling the extractor()
1492 changed the behavior (.peek() had the effect of setting the badbit
1493 ahead of time).
1494 </p>
1495 <p>
1496 I found this all to be so inconsistent and inconvenient for me and my
1497 code design, that I filed a bugzilla entry for libstdc++.   I was then
1498 told that the bug cannot be fixed until issue #309 is resolved by the
1499 committee.
1500 </p>
1501
1502
1503
1504 <p><b>Proposed resolution:</b></p>
1505
1506
1507 <p><b>Rationale:</b></p>
1508 <p>The LWG agrees there is minor variation between implementations,
1509   but believes that it doesn't matter. This is a rarely used corner
1510   case. There is no evidence that this has any commercial importance
1511   or that it causes actual portability problems for customers trying
1512   to write code that runs on multiple implementations.</p>
1513
1514
1515
1516
1517
1518 <hr>
1519 <h3><a name="342"></a>342. seek and eofbit</h3>
1520 <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#Open">Open</a>
1521  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-10-09</p>
1522 <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>
1523 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1524 <p><b>Discussion:</b></p>
1525 <p>I think we have a defect.</p>
1526
1527 <p>According to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> which is now a dr, the
1528 description of seekg in 27.6.1.3 [istream.unformatted] paragraph 38 now looks
1529 like:</p>
1530
1531 <blockquote><p>
1532 Behaves as an unformatted input function (as described in 27.6.1.3,
1533 paragraph 1), except that it does not count the number of characters
1534 extracted and does not affect the value returned by subsequent calls to
1535 gcount(). After constructing a sentry object, if fail() != true,
1536 executes rdbuf()-&gt;pubseekpos( pos).
1537 </p></blockquote>
1538
1539 <p>And according to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> which is also now a dr,
1540 27.6.1.3, paragraph 1 looks like:</p>
1541
1542 <blockquote><p>
1543 Each unformatted input function begins execution by constructing an
1544 object of class sentry with the default argument noskipws (second)
1545 argument true. If the sentry object returns true, when converted to a
1546 value of type bool, the function endeavors to obtain the requested
1547 input.  Otherwise, if the sentry constructor exits by throwing an
1548 exception or if the sentry object returns false, when converted to a
1549 value of type bool, the function returns without attempting to obtain
1550 any input. In either case the number of extracted characters is set to
1551 0; unformatted input functions taking a character array of non-zero
1552 size as an argument shall also store a null character (using charT())
1553 in the first location of the array. If an exception is thrown during
1554 input then ios::badbit is turned on in *this'ss error state. If
1555 (exception()&amp;badbit)!= 0 then the exception is rethrown. It also counts
1556 the number of characters extracted. If no exception has been thrown it
1557 ends by storing the count in a member object and returning the value
1558 specified. In any event the sentry object is destroyed before leaving
1559 the unformatted input function.
1560 </p></blockquote>
1561
1562 <p>And finally 27.6.1.1.2/5 says this about sentry:</p>
1563
1564 <blockquote><p>
1565 If, after any preparation is completed, is.good() is true, ok_ != false
1566 otherwise, ok_ == false.
1567 </p></blockquote>
1568
1569 <p>
1570 So although the seekg paragraph says that the operation proceeds if
1571 !fail(), the behavior of unformatted functions says the operation
1572 proceeds only if good().  The two statements are contradictory when only
1573 eofbit is set.  I don't think the current text is clear which condition
1574 should be respected.
1575 </p>
1576
1577 <p><b>Further discussion from Redmond:</b></p>
1578
1579 <p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is
1580 "unformatted". That makes specific claims about sentry that
1581 aren't quite appropriate for seeking, which has less fragile failure
1582 modes than actual input.  If we do really mean that it's unformatted
1583 input, it should behave the same way as other unformatted input.  On
1584 the other hand, "principle of least surprise" is that seeking from EOF
1585 ought to be OK.</p>
1586
1587 <p>
1588 Pre-Berlin:  Paolo points out several problems with the proposed resolution in
1589 Ready state:
1590 </p>
1591
1592 <ul>
1593 <li>It should apply to both overloads of seekg.</li>
1594 <li>tellg has similar issues, except that it should not call clear().</li>
1595 <li>The point about clear() seems to apply to seekp().</li>
1596 <li>Depending on the outcome of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#419">419</a>
1597 if the sentry
1598 sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
1599 you can never seek away from the end of stream.</li>
1600 </ul>
1601
1602
1603
1604 <p><b>Proposed resolution:</b></p>
1605
1606 <p>Change 27.6.1.3 [istream.unformatted] to:</p>
1607 <blockquote><p>
1608 Behaves as an unformatted input function (as described in 27.6.1.3,
1609 paragraph 1), except that it does not count the number of characters
1610 extracted, does not affect the value returned by subsequent calls to
1611 gcount(), and does not examine the value returned by the sentry
1612 object. After constructing a sentry object, if <tt>fail() !=
1613 true</tt>, executes <tt>rdbuf()-&gt;pubseekpos(pos)</tt>.  In
1614 case of success, the function calls clear().
1615 In case of failure, the function calls <tt>setstate(failbit)</tt>
1616 (which may throw <tt>ios_base::failure</tt>).
1617 </p></blockquote>
1618
1619 <p><i>[Lillehammer: Matt provided wording.]</i></p>
1620
1621
1622
1623
1624 <p><b>Rationale:</b></p>
1625 <p>In C, fseek does clear EOF.  This is probably what most users would
1626   expect.  We agree that having eofbit set should not deter a seek,
1627   and that a successful seek should clear eofbit. Note
1628   that <tt>fail()</tt> is true only if <tt>failbit</tt>
1629   or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather
1630   than <tt>good()</tt>, satisfies this goal.</p>
1631
1632
1633
1634
1635
1636 <hr>
1637 <h3><a name="343"></a>343. Unspecified library header dependencies</h3>
1638 <p><b>Section:</b> 21 [strings], 23 [containers], 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1639  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-10-09</p>
1640 <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>
1641 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1642 <p><b>Discussion:</b></p>
1643 <p>
1644 The synopses of the C++ library headers clearly show which names are
1645 required to be defined in each header. Since in order to implement the
1646 classes and templates defined in these headers declarations of other
1647 templates (but not necessarily their definitions) are typically
1648 necessary the standard in 17.4.4, p1 permits library implementers to
1649 include any headers needed to implement the definitions in each header.
1650 </p>
1651
1652 <p>
1653 For instance, although it is not explicitly specified in the synopsis of
1654 &lt;string&gt;, at the point of definition of the std::basic_string template
1655 the declaration of the std::allocator template must be in scope. All
1656 current implementations simply include &lt;memory&gt; from within &lt;string&gt;,
1657 either directly or indirectly, to bring the declaration of
1658 std::allocator into scope.
1659 </p>
1660
1661 <p>
1662 Additionally, however, some implementation also include &lt;istream&gt; and
1663 &lt;ostream&gt; at the top of &lt;string&gt; to bring the declarations of
1664 std::basic_istream and std::basic_ostream into scope (which are needed
1665 in order to implement the string inserter and extractor operators
1666 (21.3.7.9 [lib.string.io])). Other implementations only include
1667 &lt;iosfwd&gt;, since strictly speaking, only the declarations and not the
1668 full definitions are necessary.
1669 </p>
1670
1671 <p>
1672 Obviously, it is possible to implement &lt;string&gt; without actually
1673 providing the full definitions of all the templates std::basic_string
1674 uses (std::allocator, std::basic_istream, and std::basic_ostream).
1675 Furthermore, not only is it possible, doing so is likely to have a
1676 positive effect on compile-time efficiency.
1677 </p>
1678
1679 <p>
1680 But while it may seem perfectly reasonable to expect a program that uses
1681 the std::basic_string insertion and extraction operators to also
1682 explicitly include &lt;istream&gt; or &lt;ostream&gt;, respectively, it doesn't seem
1683 reasonable to also expect it to explicitly include &lt;memory&gt;. Since
1684 what's reasonable and what isn't is highly subjective one would expect
1685 the standard to specify what can and what cannot be assumed.
1686 Unfortunately, that isn't the case.
1687 </p>
1688
1689 <p>The examples below demonstrate the issue.</p>
1690
1691 <p>Example 1:</p>
1692
1693 <p>It is not clear whether the following program is complete:</p>
1694
1695 <pre>#include &lt;string&gt;
1696
1697 extern std::basic_ostream&lt;char&gt; &amp;strm;
1698
1699 int main () {
1700     strm &lt;&lt; std::string ("Hello, World!\n");
1701 }
1702 </pre>
1703
1704 <p>or whether one must explicitly include &lt;memory&gt; or
1705 &lt;ostream&gt; (or both) in addition to &lt;string&gt; in order for
1706 the program to compile.</p>
1707
1708
1709 <p>Example 2:</p>
1710
1711 <p>Similarly, it is unclear whether the following program is complete:</p>
1712
1713 <pre>#include &lt;istream&gt;
1714
1715 extern std::basic_iostream&lt;char&gt; &amp;strm;
1716
1717 int main () {
1718     strm &lt;&lt; "Hello, World!\n";
1719 }
1720 </pre>
1721
1722 <p>
1723 or whether one needs to explicitly include &lt;ostream&gt;, and
1724 perhaps even other headers containing the definitions of other
1725 required templates:</p>
1726
1727 <pre>#include &lt;ios&gt;
1728 #include &lt;istream&gt;
1729 #include &lt;ostream&gt;
1730 #include &lt;streambuf&gt;
1731
1732 extern std::basic_iostream&lt;char&gt; &amp;strm;
1733
1734 int main () {
1735     strm &lt;&lt; "Hello, World!\n";
1736 }
1737 </pre>
1738
1739 <p>Example 3:</p>
1740
1741 <p>Likewise, it seems unclear whether the program below is complete:</p>
1742 <pre>#include &lt;iterator&gt;
1743
1744 bool foo (std::istream_iterator&lt;int&gt; a, std::istream_iterator&lt;int&gt; b)
1745 {
1746     return a == b;
1747 }
1748
1749 int main () { }
1750 </pre>
1751
1752 <p>or whether one should be required to include &lt;istream&gt;.</p>
1753
1754 <p>There are many more examples that demonstrate this lack of a
1755 requirement.  I believe that in a good number of cases it would be
1756 unreasonable to require that a program explicitly include all the
1757 headers necessary for a particular template to be specialized, but I
1758 think that there are cases such as some of those above where it would
1759 be desirable to allow implementations to include only as much as
1760 necessary and not more.</p>
1761
1762
1763 <p><b>Proposed resolution:</b></p>
1764 <p>
1765 For every C++ library header, supply a minimum set of other C++ library
1766 headers that are required to be included by that header. The proposed
1767 list is below (C++ headers for C Library Facilities, table 12 in
1768 17.4.1.2, p3, are omitted):
1769 </p>
1770
1771 <pre>+------------+--------------------+
1772 | C++ header |required to include |
1773 +============+====================+
1774 |&lt;algorithm&gt; |                    |
1775 +------------+--------------------+
1776 |&lt;bitset&gt;    |                    |
1777 +------------+--------------------+
1778 |&lt;complex&gt;   |                    |
1779 +------------+--------------------+
1780 |&lt;deque&gt;     |&lt;memory&gt;            |
1781 +------------+--------------------+
1782 |&lt;exception&gt; |                    |
1783 +------------+--------------------+
1784 |&lt;fstream&gt;   |&lt;ios&gt;               |
1785 +------------+--------------------+
1786 |&lt;functional&gt;|                    |
1787 +------------+--------------------+
1788 |&lt;iomanip&gt;   |&lt;ios&gt;               |
1789 +------------+--------------------+
1790 |&lt;ios&gt;       |&lt;streambuf&gt;         |
1791 +------------+--------------------+
1792 |&lt;iosfwd&gt;    |                    |
1793 +------------+--------------------+
1794 |&lt;iostream&gt;  |&lt;istream&gt;, &lt;ostream&gt;|
1795 +------------+--------------------+
1796 |&lt;istream&gt;   |&lt;ios&gt;               |
1797 +------------+--------------------+
1798 |&lt;iterator&gt;  |                    |
1799 +------------+--------------------+
1800 |&lt;limits&gt;    |                    |
1801 +------------+--------------------+
1802 |&lt;list&gt;      |&lt;memory&gt;            |
1803 +------------+--------------------+
1804 |&lt;locale&gt;    |                    |
1805 +------------+--------------------+
1806 |&lt;map&gt;       |&lt;memory&gt;            |
1807 +------------+--------------------+
1808 |&lt;memory&gt;    |                    |
1809 +------------+--------------------+
1810 |&lt;new&gt;       |&lt;exception&gt;         |
1811 +------------+--------------------+
1812 |&lt;numeric&gt;   |                    |
1813 +------------+--------------------+
1814 |&lt;ostream&gt;   |&lt;ios&gt;               |
1815 +------------+--------------------+
1816 |&lt;queue&gt;     |&lt;deque&gt;             |
1817 +------------+--------------------+
1818 |&lt;set&gt;       |&lt;memory&gt;            |
1819 +------------+--------------------+
1820 |&lt;sstream&gt;   |&lt;ios&gt;, &lt;string&gt;     |
1821 +------------+--------------------+
1822 |&lt;stack&gt;     |&lt;deque&gt;             |
1823 +------------+--------------------+
1824 |&lt;stdexcept&gt; |                    |
1825 +------------+--------------------+
1826 |&lt;streambuf&gt; |&lt;ios&gt;               |
1827 +------------+--------------------+
1828 |&lt;string&gt;    |&lt;memory&gt;            |
1829 +------------+--------------------+
1830 |&lt;strstream&gt; |                    |
1831 +------------+--------------------+
1832 |&lt;typeinfo&gt;  |&lt;exception&gt;         |
1833 +------------+--------------------+
1834 |&lt;utility&gt;   |                    |
1835 +------------+--------------------+
1836 |&lt;valarray&gt;  |                    |
1837 +------------+--------------------+
1838 |&lt;vector&gt;    |&lt;memory&gt;            |
1839 +------------+--------------------+
1840 </pre>
1841
1842
1843 <p><b>Rationale:</b></p>
1844 <p>The portability problem is real.  A program that works correctly on
1845 one implementation might fail on another, because of different header
1846 dependencies.  This problem was understood before the standard was
1847 completed, and it was a conscious design choice.</p>
1848 <p>One possible way to deal with this, as a library extension, would
1849 be an &lt;all&gt; header.</p>
1850
1851 <p>
1852 Hinnant:  It's time we dealt with this issue for C++0X.  Reopened.
1853 </p>
1854
1855
1856
1857
1858
1859
1860
1861 <hr>
1862 <h3><a name="382"></a>382. codecvt do_in/out result</h3>
1863 <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#Open">Open</a>
1864  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-08-30</p>
1865 <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>
1866 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1867 <p><b>Discussion:</b></p>
1868 <p>
1869 It seems that the descriptions of codecvt do_in() and do_out() leave
1870 sufficient room for interpretation so that two implementations of
1871 codecvt may not work correctly with the same filebuf. Specifically,
1872 the following seems less than adequately specified:
1873 </p>
1874
1875 <ol>
1876 <li>
1877   the conditions under which the functions terminate
1878 </li>
1879 <li>
1880   precisely when the functions return ok
1881 </li>
1882 <li>
1883   precisely when the functions return partial
1884 </li>
1885 <li>
1886   the full set of conditions when the functions return error
1887 </li>
1888 </ol>
1889
1890 <ol>
1891 <li>
1892    22.2.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the
1893    function: ...Stops if it encounters a character it cannot
1894    convert...  This assumes that there *is* a character to
1895    convert. What happens when there is a sequence that doesn't form a
1896    valid source character, such as an unassigned or invalid UNICODE
1897    character, or a sequence that cannot possibly form a character
1898    (e.g., the sequence "\xc0\xff" in UTF-8)?
1899 </li>
1900 <li>
1901    Table 53 says that the function returns codecvt_base::ok
1902    to indicate that the function(s) "completed the conversion."
1903    Suppose that the source sequence is "\xc0\x80" in UTF-8,
1904    with from pointing to '\xc0' and (from_end==from + 1).
1905    It is not clear whether the return value should be ok
1906    or partial (see below).
1907 </li>
1908 <li>
1909    Table 53 says that the function returns codecvt_base::partial
1910    if "not all source characters converted." With the from pointers
1911    set up the same way as above, it is not clear whether the return
1912    value should be partial or ok (see above).
1913 </li>
1914 <li>
1915    Table 53, in the row describing the meaning of error mistakenly
1916    refers to a "from_type" character, without the symbol from_type
1917    having been defined. Most likely, the word "source" character
1918    is intended, although that is not sufficient. The functions
1919    may also fail when they encounter an invalid source sequence
1920    that cannot possibly form a valid source character (e.g., as
1921    explained in bullet 1 above).
1922 </li>
1923 </ol>
1924 <p>
1925 Finally, the conditions described at the end of 22.2.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible:
1926 </p>
1927 <blockquote><p>
1928     "A return value of partial, if (from_next == from_end),
1929     indicates that either the destination sequence has not
1930     absorbed all the available destination elements, or that
1931     additional source elements are needed before another
1932     destination element can be produced."
1933 </p></blockquote>
1934 <p>
1935 If the value is partial, it's not clear to me that (from_next
1936 ==from_end) could ever hold if there isn't enough room
1937 in the destination buffer. In order for (from_next==from_end) to
1938 hold, all characters in that range must have been successfully
1939 converted (according to 22.2.1.4.2 [locale.codecvt.virtuals], p2) and since there are no
1940 further source characters to convert, no more room in the
1941 destination buffer can be needed.
1942 </p>
1943 <p>
1944 It's also not clear to me that (from_next==from_end) could ever
1945 hold if additional source elements are needed to produce another
1946 destination character (not element as incorrectly stated in the
1947 text). partial is returned if "not all source characters have
1948 been converted" according to Table 53, which also implies that
1949 (from_next==from) does NOT hold.
1950 </p>
1951 <p>
1952 Could it be that the intended qualifying condition was actually
1953 (from_next != from_end), i.e., that the sentence was supposed
1954 to read
1955 </p>
1956 <blockquote><p>
1957     "A return value of partial, if (from_next != from_end),..."
1958 </p></blockquote>
1959 <p>
1960 which would make perfect sense, since, as far as I understand it,
1961 partial can only occur if (from_next != from_end)?
1962 </p>
1963 <p><i>[Lillehammer: Defer for the moment, but this really needs to be
1964   fixed. Right now, the description of codecvt is too vague for it to
1965   be a useful contract between providers and clients of codecvt
1966   facets.  (Note that both vendors and users can be both providers and
1967   clients of codecvt facets.) The major philosophical issue is whether
1968   the standard should only describe mappings that take a single wide
1969   character to multiple narrow characters (and vice versa), or whether
1970   it should describe fully general N-to-M conversions. When the
1971   original standard was written only the former was contemplated, but
1972   today, in light of the popularity of utf8 and utf16, that doesn't
1973   seem sufficient for C++0x. Bill supports general N-to-M conversions;
1974   we need to make sure Martin and Howard agree.]</i></p>
1975
1976
1977
1978 <p><b>Proposed resolution:</b></p>
1979
1980
1981
1982
1983 <hr>
1984 <h3><a name="387"></a>387. std::complex over-encapsulated</h3>
1985 <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#Open">Open</a>
1986  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
1987 <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>
1988 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1989 <p><b>Discussion:</b></p>
1990 <p>
1991 The absence of explicit description of std::complex&lt;T&gt; layout
1992 makes it imposible to reuse existing software developed in traditional
1993 languages like Fortran or C with unambigous and commonly accepted
1994 layout assumptions.  There ought to be a way for practitioners to
1995 predict with confidence the layout of std::complex&lt;T&gt; whenever T
1996 is a numerical datatype.  The absence of ways to access individual
1997 parts of a std::complex&lt;T&gt; object as lvalues unduly promotes
1998 severe pessimizations. For example, the only way to change,
1999 independently, the real and imaginary parts is to write something like
2000 </p>
2001
2002 <pre>complex&lt;T&gt; z;
2003 // ...
2004 // set the real part to r
2005 z = complex&lt;T&gt;(r, z.imag());
2006 // ...
2007 // set the imaginary part to i
2008 z = complex&lt;T&gt;(z.real(), i);
2009 </pre>
2010
2011 <p>
2012 At this point, it seems appropriate to recall that a complex number
2013 is, in effect, just a pair of numbers with no particular invariant to
2014 maintain.  Existing practice in numerical computations has it that a
2015 complex number datatype is usually represented by Cartesian
2016 coordinates. Therefore the over-encapsulation put in the specification
2017 of std::complex&lt;&gt; is not justified.
2018 </p>
2019
2020
2021
2022 <p><b>Proposed resolution:</b></p>
2023 <p>Add the following requirements to 26.3 [complex.numbers] as 26.3/4:</p>
2024 <blockquote>
2025 <p>If z is an lvalue expression of type cv std::complex&lt;T&gt; then</p>
2026
2027 <ul>
2028 <li>the expression reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)
2029 is well-formed; and</li>
2030 <li>reinterpret_cast&lt;cvT(&amp;)[2]&gt;(z)[0]designates the
2031 real part of z; and</li>
2032 <li>reinterpret_cast&lt;cvT(&amp;)[2]&gt;(z)[1]designates the
2033 imaginary part of z.</li>
2034 </ul>
2035
2036 <p>
2037 Moreover, if a is an expression of pointer type cv complex&lt;T&gt;*
2038 and the expression a[i] is well-defined for an integer expression
2039 i then:
2040 </p>
2041
2042 <ul>
2043 <li>reinterpret_cast&lt;cvT*&gt;(a)[2+i] designates the real
2044 part of a[i]; and</li>
2045 <li>reinterpret_cast&lt;cv T*&gt;(a)[2+i+1] designates the
2046 imaginary part of a[i].</li>
2047 </ul>
2048 </blockquote>
2049
2050 <p>In the header synopsis in 26.3.1 [complex.synopsis], replace</p>
2051 <pre>  template&lt;class T&gt; T real(const complex&lt;T&gt;&amp;);
2052   template&lt;class T&gt; T imag(const complex&lt;T&gt;&amp;);
2053 </pre>
2054
2055 <p>with</p>
2056
2057 <pre>  template&lt;class T&gt; const T&amp; real(const complex&lt;T&gt;&amp;);
2058   template&lt;class T&gt;       T&amp; real(      complex&lt;T&gt;&amp;);
2059   template&lt;class T&gt; const T&amp; imag(const complex&lt;T&gt;&amp;);
2060   template&lt;class T&gt;       T&amp; imag(      complex&lt;T&gt;&amp;);
2061 </pre>
2062
2063 <p>In 26.3.7 [complex.value.ops] paragraph 1, change</p>
2064 <pre>  template&lt;class T&gt; T real(const complex&lt;T&gt;&amp;);
2065 </pre>
2066 <p>to</p>
2067 <pre>  template&lt;class T&gt; const T&amp; real(const complex&lt;T&gt;&amp;);
2068   template&lt;class T&gt;       T&amp; real(      complex&lt;T&gt;&amp;);
2069 </pre>
2070 <p>and change the <b>Returns</b> clause to "<b>Returns:</b> The real
2071 part of <i>x</i>.</p>
2072
2073 <p>In 26.3.7 [complex.value.ops] paragraph 2, change</p>
2074 <pre>  template&lt;class T&gt; T imag(const complex&lt;T&gt;&amp;);
2075 </pre>
2076 <p>to</p>
2077 <pre>  template&lt;class T&gt; const T&amp; imag(const complex&lt;T&gt;&amp;);
2078   template&lt;class T&gt;       T&amp; imag(      complex&lt;T&gt;&amp;);
2079 </pre>
2080 <p>and change the <b>Returns</b> clause to "<b>Returns:</b> The imaginary
2081 part of <i>x</i>.</p>
2082
2083 <p><i>[Kona: The layout guarantee is absolutely necessary for C
2084   compatibility.  However, there was disagreement about the other part
2085   of this proposal: retrieving elements of the complex number as
2086   lvalues.  An alternative: continue to have real() and imag() return
2087   rvalues, but add set_real() and set_imag().  Straw poll: return
2088   lvalues - 2, add setter functions - 5.  Related issue: do we want
2089   reinterpret_cast as the interface for converting a complex to an
2090   array of two reals, or do we want to provide a more explicit way of
2091   doing it?  Howard will try to resolve this issue for the next
2092   meeting.]</i></p>
2093
2094
2095 <p><i>[pre-Sydney: Howard summarized the options in n1589.]</i></p>
2096
2097
2098
2099
2100 <p><b>Rationale:</b></p>
2101 <p>The LWG believes that C99 compatibility would be enough
2102 justification for this change even without other considerations.  All
2103 existing implementations already have the layout proposed here.</p>
2104
2105
2106
2107
2108
2109 <hr>
2110 <h3><a name="394"></a>394. behavior of formatted output on failure</h3>
2111 <p><b>Section:</b> 27.6.2.6.1 [ostream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2112  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-12-27</p>
2113 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2114 <p><b>Discussion:</b></p>
2115 <p>
2116 There is a contradiction in Formatted output about what bit is
2117 supposed to be set if the formatting fails. On sentence says it's
2118 badbit and another that it's failbit.
2119 </p>
2120 <p>
2121 27.6.2.5.1, p1 says in the Common Requirements on Formatted output
2122 functions:
2123 </p>
2124 <pre>     ... If the generation fails, then the formatted output function
2125      does setstate(ios::failbit), which might throw an exception.
2126 </pre>
2127 <p>
2128 27.6.2.5.2, p1 goes on to say this about Arithmetic Inserters:
2129 </p>
2130 <p>
2131      ... The formatting conversion occurs as if it performed the
2132      following code fragment:
2133 </p>
2134 <pre>     bool failed =
2135          use_facet&lt;num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt;
2136          &gt; &gt;
2137          (getloc()).put(*this, *this, fill(), val). failed();
2138
2139      ... If failed is true then does setstate(badbit) ...
2140 </pre>
2141 <p>
2142 The original intent of the text, according to Jerry Schwarz (see
2143 c++std-lib-10500), is captured in the following paragraph:
2144 </p>
2145 <p>
2146 In general "badbit" should mean that the stream is unusable because
2147 of some underlying failure, such as disk full or socket closure;
2148 "failbit" should mean that the requested formatting wasn't possible
2149 because of some inconsistency such as negative widths.  So typically
2150 if you clear badbit and try to output something else you'll fail
2151 again, but if you clear failbit and try to output something else
2152 you'll succeed.
2153 </p>
2154 <p>
2155 In the case of the arithmetic inserters, since num_put cannot
2156 report failure by any means other than exceptions (in response
2157 to which the stream must set badbit, which prevents the kind of
2158 recoverable error reporting mentioned above), the only other
2159 detectable failure is if the iterator returned from num_put
2160 returns true from failed().
2161 </p>
2162 <p>
2163 Since that can only happen (at least with the required iostream
2164 specializations) under such conditions as the underlying failure
2165 referred to above (e.g., disk full), setting badbit would seem
2166 to be the appropriate response (indeed, it is required in
2167 27.6.2.5.2, p1). It follows that failbit can never be directly
2168 set by the arithmetic (it can only be set by the sentry object
2169 under some unspecified conditions).
2170 </p>
2171 <p>
2172 The situation is different for other formatted output functions
2173 which can fail as a result of the streambuf functions failing
2174 (they may do so by means other than exceptions), and which are
2175 then required to set failbit.
2176 </p>
2177 <p>
2178 The contradiction, then, is that ostream::operator&lt;&lt;(int) will
2179 set badbit if the disk is full, while operator&lt;&lt;(ostream&amp;,
2180 char) will set failbit under the same conditions. To make the behavior
2181 consistent, the Common requirements sections for the Formatted output
2182 functions should be changed as proposed below.
2183 </p>
2184 <p><i>[Kona: There's agreement that this is a real issue.  What we
2185   decided at Kona: 1. An error from the buffer (which can be detected
2186   either directly from streambuf's member functions or by examining a
2187   streambuf_iterator) should always result in badbit getting set.
2188   2. There should never be a circumstance where failbit gets set.
2189   That represents a formatting error, and there are no circumstances
2190   under which the output facets are specified as signaling a
2191   formatting error. (Even more so for string output that for numeric
2192   because there's nothing to format.)  If we ever decide to make it
2193   possible for formatting errors to exist then the facets can signal
2194   the error directly, and that should go in clause 22, not clause 27.
2195   3. The phrase "if generation fails" is unclear and should be
2196   eliminated.  It's not clear whether it's intended to mean a buffer
2197   error (e.g. a full disk), a formatting error, or something else.
2198   Most people thought it was supposed to refer to buffer errors; if
2199   so, we should say so.  Martin will provide wording.]</i></p>
2200
2201
2202
2203
2204 <p><b>Proposed resolution:</b></p>
2205
2206
2207 <p><b>Rationale:</b></p>
2208
2209
2210
2211
2212
2213
2214 <hr>
2215 <h3><a name="396"></a>396. what are characters zero and one</h3>
2216 <p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2217  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
2218 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
2219 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2220 <p><b>Discussion:</b></p>
2221     <p>
2222 23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
2223 having the value of 0 or 1 but there is no definition of what
2224 that means for charT other than char and wchar_t. And even for
2225 those two types, the values 0 and 1 are not actually what is
2226 intended -- the values '0' and '1' are. This, along with the
2227 converse problem in the description of to_string() in 23.3.5.2,
2228 p33, looks like a defect remotely related to DR 303.
2229     </p>
2230     <p>
2231 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
2232     </p>
2233     <pre>23.3.5.1:
2234   -6-  An element of the constructed string has value zero if the
2235        corresponding character in str, beginning at position pos,
2236        is 0. Otherwise, the element has the value one.
2237     </pre>
2238     <pre>23.3.5.2:
2239   -33-  Effects: Constructs a string object of the appropriate
2240         type and initializes it to a string of length N characters.
2241         Each character is determined by the value of its
2242         corresponding bit position in *this. Character position N
2243         ?- 1 corresponds to bit position zero. Subsequent decreasing
2244         character positions correspond to increasing bit positions.
2245         Bit value zero becomes the character 0, bit value one becomes
2246         the character 1.
2247     </pre>
2248     <p>
2249 Also note the typo in 23.3.5.1, p6: the object under construction
2250 is a bitset, not a string.
2251     </p>
2252
2253
2254 <p><b>Proposed resolution:</b></p>
2255 <p>Change the constructor's function declaration immediately before
2256 23.3.5.1 [bitset.cons] p3 to:</p>
2257 <pre>    template &lt;class charT, class traits, class Allocator&gt;
2258     explicit
2259     bitset(const basic_string&lt;charT, traits, Allocator&gt;&amp; str,
2260            typename basic_string&lt;charT, traits, Allocator&gt;::size_type pos = 0,
2261            typename basic_string&lt;charT, traits, Allocator&gt;::size_type n =
2262              basic_string&lt;charT, traits, Allocator&gt;::npos,
2263            charT zero = charT('0'), charT one = charT('1'))
2264 </pre>
2265 <p>Change the first two sentences of 23.3.5.1 [bitset.cons] p6 to: "An
2266 element of the constructed string has value 0 if the corresponding
2267 character in <i>str</i>, beginning at position <i>pos</i>,
2268 is <i>zero</i>. Otherwise, the element has the value 1.</p>
2269
2270 <p>Change the text of the second sentence in 23.3.5.1, p5 to read:
2271     "The function then throws invalid_argument if any of the rlen
2272     characters in str beginning at position pos is other than <i>zero</i>
2273     or <i>one</i>. The function uses traits::eq() to compare the character
2274     values."
2275 </p>
2276
2277 <p>Change the declaration of the <tt>to_string</tt> member function
2278   immediately before 23.3.5.2 [bitset.members] p33 to:</p>
2279 <pre>    template &lt;class charT, class traits, class Allocator&gt;
2280     basic_string&lt;charT, traits, Allocator&gt;
2281     to_string(charT zero = charT('0'), charT one = charT('1')) const;
2282 </pre>
2283 <p>Change the last sentence of 23.3.5.2 [bitset.members] p33 to: "Bit
2284   value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the
2285   character <tt><i>one</i></tt>.</p>
2286 <p>Change 23.3.5.3 [bitset.operators] p8 to:</p>
2287 <p><b>Returns</b>:</p>
2288 <pre>  os &lt;&lt; x.template to_string&lt;charT,traits,allocator&lt;charT&gt; &gt;(
2289       use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('0'),
2290       use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('1'));
2291 </pre>
2292
2293
2294 <p><b>Rationale:</b></p>
2295 <p>There is a real problem here: we need the character values of '0'
2296   and '1', and we have no way to get them since strings don't have
2297   imbued locales. In principle the "right" solution would be to
2298   provide an extra object, either a ctype facet or a full locale,
2299   which would be used to widen '0' and '1'. However, there was some
2300   discomfort about using such a heavyweight mechanism.  The proposed
2301   resolution allows those users who care about this issue to get it
2302   right.</p>
2303 <p>We fix the inserter to use the new arguments.  Note that we already
2304   fixed the analogous problem with the extractor in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>.</p>
2305
2306
2307
2308
2309
2310
2311 <hr>
2312 <h3><a name="397"></a>397. ostream::sentry dtor throws exceptions</h3>
2313 <p><b>Section:</b> 27.6.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2314  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
2315 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ostream::sentry">active issues</a> in [ostream::sentry].</p>
2316 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
2317 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2318 <p><b>Discussion:</b></p>
2319     <p>
2320 17.4.4.8, p3 prohibits library dtors from throwing exceptions.
2321     </p>
2322     <p>
2323 27.6.2.3, p4 says this about the ostream::sentry dtor:
2324     </p>
2325     <pre>    -4- If ((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception())
2326         is true, calls os.flush().
2327     </pre>
2328     <p>
2329 27.6.2.6, p7 that describes ostream::flush() says:
2330     </p>
2331     <pre>    -7- If rdbuf() is not a null pointer, calls rdbuf()-&gt;pubsync().
2332         If that function returns ?-1 calls setstate(badbit) (which
2333         may throw ios_base::failure (27.4.4.3)).
2334     </pre>
2335     <p>
2336 That seems like a defect, since both pubsync() and setstate() can
2337 throw an exception.
2338     </p>
2339 <p><i>[
2340 The contradiction is real.  Clause 17 says destructors may never
2341 throw exceptions, and clause 27 specifies a destructor that does
2342 throw.  In principle we might change either one.  We're leaning
2343 toward changing clause 17: putting in an "unless otherwise specified"
2344 clause, and then putting in a footnote saying the sentry destructor
2345 is the only one that can throw.  PJP suggests specifying that
2346 sentry::~sentry() should internally catch any exceptions it might cause.
2347 ]</i></p>
2348
2349
2350 <p><i>[
2351 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">418</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a> for related issues.
2352 ]</i></p>
2353
2354
2355
2356
2357 <p><b>Proposed resolution:</b></p>
2358
2359
2360
2361
2362
2363 <hr>
2364 <h3><a name="398"></a>398. effects of end-of-file on unformatted input functions</h3>
2365 <p><b>Section:</b> 27.6.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2366  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
2367 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ostream::sentry">active issues</a> in [ostream::sentry].</p>
2368 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
2369 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2370 <p><b>Discussion:</b></p>
2371     <p>
2372 While reviewing unformatted input member functions of istream
2373 for their behavior when they encounter end-of-file during input
2374 I found that the requirements vary, sometimes unexpectedly, and
2375 in more than one case even contradict established practice (GNU
2376 libstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC
2377 5.38, Rogue Wave libstd 3.1, and Classic Iostreams).
2378     </p>
2379     <p>
2380 The following unformatted input member functions set eofbit if they
2381 encounter an end-of-file (this is the expected behavior, and also
2382 the behavior of all major implementations):
2383     </p>
2384     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2385     get (char_type*, streamsize, char_type);
2386     </pre>
2387     <p>
2388     Also sets failbit if it fails to extract any characters.
2389     </p>
2390     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2391     get (char_type*, streamsize);
2392     </pre>
2393     <p>
2394     Also sets failbit if it fails to extract any characters.
2395     </p>
2396     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2397     getline (char_type*, streamsize, char_type);
2398     </pre>
2399     <p>
2400     Also sets failbit if it fails to extract any characters.
2401     </p>
2402     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2403     getline (char_type*, streamsize);
2404     </pre>
2405     <p>
2406     Also sets failbit if it fails to extract any characters.
2407     </p>
2408     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2409     ignore (int, int_type);
2410     </pre>
2411     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2412     read (char_type*, streamsize);
2413     </pre>
2414     <p>
2415     Also sets failbit if it encounters end-of-file.
2416     </p>
2417     <pre>    streamsize readsome (char_type*, streamsize);
2418     </pre>
2419
2420     <p>
2421 The following unformated input member functions set failbit but
2422 not eofbit if they encounter an end-of-file (I find this odd
2423 since the functions make it impossible to distinguish a general
2424 failure from a failure due to end-of-file; the requirement is
2425 also in conflict with all major implementation which set both
2426 eofbit and failbit):
2427     </p>
2428     <pre>    int_type get();
2429     </pre>
2430     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2431     get (char_type&amp;);
2432     </pre>
2433     <p>
2434 These functions only set failbit of they extract no characters,
2435 otherwise they don't set any bits, even on failure (I find this
2436 inconsistency quite unexpected; the requirement is also in
2437 conflict with all major implementations which set eofbit
2438 whenever they encounter end-of-file):
2439     </p>
2440     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2441     get (basic_streambuf&lt;charT, traits&gt;&amp;, char_type);
2442     </pre>
2443     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2444     get (basic_streambuf&lt;charT, traits&gt;&amp;);
2445     </pre>
2446     <p>
2447 This function sets no bits (all implementations except for
2448 STLport and Classic Iostreams set eofbit when they encounter
2449 end-of-file):
2450     </p>
2451     <pre>    int_type peek ();
2452     </pre>
2453 <p>Informally, what we want is a global statement of intent saying
2454   that eofbit gets set if we trip across EOF, and then we can take
2455   away the specific wording for individual functions.  A full review
2456   is necessary.  The wording currently in the standard is a mishmash,
2457   and changing it on an individual basis wouldn't make things better.
2458   Dietmar will do this work.</p>
2459
2460
2461 <p><b>Proposed resolution:</b></p>
2462
2463
2464
2465
2466 <hr>
2467 <h3><a name="408"></a>408. Is vector&lt;reverse_iterator&lt;char*&gt; &gt; forbidden?</h3>
2468 <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#Open">Open</a>
2469  <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
2470 <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>
2471 <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>
2472 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2473 <p><b>Discussion:</b></p>
2474 <p>
2475 I've been discussing iterator semantics with Dave Abrahams, and a
2476 surprise has popped up.  I don't think this has been discussed before.
2477 </p>
2478
2479 <p>
2480 24.1 [iterator.requirements] says that the only operation that can be performed on "singular"
2481 iterator values is to assign a non-singular value to them.  (It
2482 doesn't say they can be destroyed, and that's probably a defect.)
2483 Some implementations have taken this to imply that there is no need
2484 to initialize the data member of a reverse_iterator&lt;&gt; in the default
2485 constructor.  As a result, code like
2486 </p>
2487 <blockquote><pre>  std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt; v(7);
2488   v.reserve(1000);
2489 </pre></blockquote>
2490 <p>
2491 invokes undefined behavior, because it must default-initialize the
2492 vector elements, and then copy them to other storage.  Of course many
2493 other vector operations on these adapters are also left undefined,
2494 and which those are is not reliably deducible from the standard.
2495 </p>
2496
2497 <p>
2498 I don't think that 24.1 was meant to make standard-library iterator
2499 types unsafe.  Rather, it was meant to restrict what operations may
2500 be performed by functions which take general user- and standard
2501 iterators as arguments, so that raw pointers would qualify as
2502 iterators.  However, this is not clear in the text, others have come
2503 to the opposite conclusion.
2504 </p>
2505
2506 <p>
2507 One question is whether the standard iterator adaptors have defined
2508 copy semantics.  Another is whether they have defined destructor
2509 semantics: is
2510 </p>
2511 <blockquote><pre>  { std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt;  v(7); }
2512 </pre></blockquote>
2513 <p>
2514 undefined too?
2515 </p>
2516
2517 <p>
2518 Note this is not a question of whether algorithms are allowed to
2519 rely on copy semantics for arbitrary iterators, just whether the
2520 types we actually supply support those operations.  I believe the
2521 resolution must be expressed in terms of the semantics of the
2522 adapter's argument type.  It should make clear that, e.g., the
2523 reverse_iterator&lt;T&gt; constructor is actually required to execute
2524 T(), and so copying is defined if the result of T() is copyable.
2525 </p>
2526
2527 <p>
2528 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, which defines reverse_iterator's default
2529 constructor more precisely, has some relevance to this issue.
2530 However, it is not the whole story.
2531 </p>
2532
2533 <p>
2534 The issue was whether
2535 </p>
2536 <blockquote><pre>  reverse_iterator() { }
2537 </pre></blockquote>
2538 <p>
2539 is allowed, vs.
2540 </p>
2541 <blockquote><pre>  reverse_iterator() : current() { }
2542 </pre></blockquote>
2543
2544 <p>
2545 The difference is when T is char*, where the first leaves the member
2546 uninitialized, and possibly equal to an existing pointer value, or
2547 (on some targets) may result in a hardware trap when copied.
2548 </p>
2549
2550 <p>
2551 8.5 paragraph 5 seems to make clear that the second is required to
2552 satisfy DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, at least for non-class Iterator argument
2553 types.
2554 </p>
2555
2556 <p>
2557 But that only takes care of reverse_iterator, and doesn't establish
2558 a policy for all iterators.  (The reverse iterator adapter was just
2559 an example.)  In particular, does my function
2560 </p>
2561 <blockquote><pre>  template &lt;typename Iterator&gt;
2562     void f() { std::vector&lt;Iterator&gt;  v(7); }
2563 </pre></blockquote>
2564 <p>
2565 evoke undefined behavior for some conforming iterator definitions?
2566 I think it does, now, because vector&lt;&gt; will destroy those singular
2567 iterator values, and that's explicitly disallowed.
2568 </p>
2569
2570 <p>
2571 24.1 shouldn't give blanket permission to copy all singular iterators,
2572 because then pointers wouldn't qualify as iterators.  However, it
2573 should allow copying of that subset of singular iterator values that
2574 are default-initialized, and it should explicitly allow destroying any
2575 iterator value, singular or not, default-initialized or not.
2576 </p>
2577
2578 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a></p>
2579 <p><i>[
2580 We don't want to require all singular iterators to be copyable,
2581 because that is not the case for pointers.  However, default
2582 construction may be a special case.  Issue: is it really default
2583 construction we want to talk about, or is it something like value
2584 initialization?  We need to check with core to see whether default
2585 constructed pointers are required to be copyable; if not, it would be
2586 wrong to impose so strict a requirement for iterators.
2587 ]</i></p>
2588
2589
2590
2591
2592 <p><b>Proposed resolution:</b></p>
2593
2594
2595
2596
2597
2598 <hr>
2599 <h3><a name="417"></a>417. what does ctype::do_widen() return on failure</h3>
2600 <p><b>Section:</b> 22.2.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2601  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
2602 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.virtuals].</p>
2603 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2604 <p><b>Discussion:</b></p>
2605 <p>
2606 The Effects and Returns clauses of the do_widen() member function of
2607 the ctype facet fail to specify the behavior of the function on failure.
2608 That the function may not be able to simply cast the narrow character
2609 argument to the type of the result since doing so may yield the wrong value
2610 for some wchar_t encodings. Popular implementations of ctype&lt;wchar_t&gt; that
2611 use mbtowc() and UTF-8 as the native encoding (e.g., GNU glibc) will fail
2612 when the argument's MSB is set. There is no way for the the rest of locale
2613 and iostream to reliably detect this failure.
2614 </p>
2615 <p><i>[Kona: This is a real problem.  Widening can fail.  It's unclear
2616   what the solution should be.  Returning WEOF works for the wchar_t
2617   specialization, but not in general.  One option might be to add a
2618   default, like <i>narrow</i>.  But that's an incompatible change.
2619   Using <i>traits::eof</i> might seem like a good idea, but facets
2620   don't have access to traits (a recurring problem).  We could
2621   have <i>widen</i> throw an exception, but that's a scary option;
2622   existing library components aren't written with the assumption
2623   that <i>widen</i> can throw.]</i></p>
2624
2625
2626
2627 <p><b>Proposed resolution:</b></p>
2628
2629
2630
2631
2632 <hr>
2633 <h3><a name="418"></a>418. exceptions thrown during iostream cleanup</h3>
2634 <p><b>Section:</b> 27.4.2.1.6 [ios::Init] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2635  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
2636 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2637 <p><b>Discussion:</b></p>
2638 <p>
2639 The dtor of the ios_base::Init object is supposed to call flush() on the
2640 6 standard iostream objects cout, cerr, clog, wcout, wcerr, and wclog.
2641 This call may cause an exception to be thrown.
2642 </p>
2643
2644 <p>
2645 17.4.4.8, p3 prohibits all library destructors from throwing exceptions.
2646 </p>
2647
2648 <p>
2649 The question is: What should this dtor do if one or more of these calls
2650 to flush() ends up throwing an exception? This can happen quite easily
2651 if one of the facets installed in the locale imbued in the iostream
2652 object throws.
2653 </p>
2654 <p><i>[Kona: We probably can't do much better than what we've got, so
2655   the LWG is leaning toward NAD.  At the point where the standard
2656   stream objects are being cleaned up, the usual error reporting
2657   mechanism are all unavailable.  And exception from flush at this
2658   point will definitely cause problems.  A quality implementation
2659   might reasonably swallow the exception, or call abort, or do
2660   something even more drastic.]</i></p>
2661
2662
2663 <p><i>[
2664 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a> for related issues.
2665 ]</i></p>
2666
2667
2668
2669
2670 <p><b>Proposed resolution:</b></p>
2671
2672
2673
2674
2675 <hr>
2676 <h3><a name="419"></a>419. istream extractors not setting failbit if eofbit is already set</h3>
2677 <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#Open">Open</a>
2678  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
2679 <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>
2680 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2681 <p><b>Discussion:</b></p>
2682         <p>
2683
2684 27.6.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good()
2685 is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to
2686 true if the stream state is good after any preparation. 27.6.1.2.1 [istream.formatted.reqmts], p1 then
2687 says that a formatted input function endeavors to obtain the requested input
2688 if the sentry's operator bool() returns true.
2689
2690 Given these requirements, no formatted extractor should ever set failbit if
2691 the initial stream rdstate() == eofbit. That is contrary to the behavior of
2692 all implementations I tested. The program below prints out
2693
2694 eof = 1, fail = 0
2695 eof = 1, fail = 1
2696
2697 on all of them.
2698         </p>
2699 <pre>
2700 #include &lt;sstream&gt;
2701 #include &lt;cstdio&gt;
2702
2703 int main()
2704 {
2705     std::istringstream strm ("1");
2706
2707     int i = 0;
2708
2709     strm &gt;&gt; i;
2710
2711     std::printf ("eof = %d, fail = %d\n",
2712                  !!strm.eof (), !!strm.fail ());
2713
2714     strm &gt;&gt; i;
2715
2716     std::printf ("eof = %d, fail = %d\n",
2717                  !!strm.eof (), !!strm.fail ());
2718 }
2719
2720 </pre>
2721         <p>
2722 <br>
2723
2724 Comments from Jerry Schwarz (c++std-lib-11373):
2725 <br>
2726
2727 Jerry Schwarz wrote:
2728 <br>
2729
2730 I don't know where (if anywhere) it says it in the standard, but the
2731 formatted extractors are supposed to set failbit if they don't extract
2732 any characters. If they didn't then simple loops like
2733 <br>
2734
2735 while (cin &gt;&gt; x);
2736 <br>
2737
2738 would loop forever.
2739 <br>
2740
2741 Further comments from Martin Sebor:
2742 <br>
2743
2744 The question is which part of the extraction should prevent this from happening
2745 by setting failbit when eofbit is already set. It could either be the sentry
2746 object or the extractor. It seems that most implementations have chosen to
2747 set failbit in the sentry [...] so that's the text that will need to be
2748 corrected.
2749
2750         </p>
2751 <p>
2752 Pre Berlin:  This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>.  If the sentry
2753 sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
2754 you can never seek away from the end of stream.
2755 </p>
2756 <p>Kona: Possibly NAD.  If eofbit is set then good() will return false.  We
2757   then set <i>ok</i> to false.  We believe that the sentry's
2758   constructor should always set failbit when <i>ok</i> is false, and
2759   we also think the standard already says that.  Possibly it could be
2760   clearer.</p>
2761
2762
2763
2764 <p><b>Proposed resolution:</b></p>
2765 <p>
2766 Change 27.6.1.1.3 [istream::sentry], p2 to:
2767 </p>
2768
2769 <blockquote>
2770 <pre>explicit sentry(basic_istream&lt;charT,traits&gt;&amp; <i>is</i> , bool <i>noskipws</i> = false);</pre>
2771 <p>
2772 -2- <i>Effects:</i> If <tt>is.good()</tt> is <del><tt>true</tt></del>
2773 <ins><tt>false</tt></ins>, <ins>calls <tt>is.setstate(failbit)</tt>.
2774 Otherwise</ins> prepares for formatted or unformatted input. ...
2775 </p>
2776 </blockquote>
2777
2778
2779
2780
2781
2782
2783 <hr>
2784 <h3><a name="421"></a>421. is basic_streambuf copy-constructible?</h3>
2785 <p><b>Section:</b> 27.5.2.1 [streambuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2786  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
2787 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.cons">issues</a> in [streambuf.cons].</p>
2788 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2789 <p><b>Discussion:</b></p>
2790 <p>
2791 The reflector thread starting with c++std-lib-11346 notes that the class
2792 template basic_streambuf, along with basic_stringbuf and basic_filebuf,
2793 is copy-constructible but that the semantics of the copy constructors
2794 are not defined anywhere. Further, different implementations behave
2795 differently in this respect: some prevent copy construction of objects
2796 of these types by declaring their copy ctors and assignment operators
2797 private, others exhibit undefined behavior, while others still give
2798 these operations well-defined semantics.
2799 </p>
2800
2801 <p>
2802 Note that this problem doesn't seem to be isolated to just the three
2803 types mentioned above. A number of other types in the library section
2804 of the standard provide a compiler-generated copy ctor and assignment
2805 operator yet fail to specify their semantics.  It's believed that the
2806 only types for which this is actually a problem (i.e. types where the
2807 compiler-generated default may be inappropriate and may not have been
2808 intended) are locale facets.  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#439">439</a>.
2809 </p>
2810
2811
2812 <p><b>Proposed resolution:</b></p>
2813 <p>
2814 27.5.2 [lib.streambuf]:  Add into the synopsis, public section, just above the destructor declaration:
2815 </p>
2816
2817 <blockquote>
2818 <pre>basic_streambuf(const basic_streambuf&amp; sb);
2819 basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
2820 </pre>
2821 </blockquote>
2822
2823 <p>Insert after 27.5.2.1, paragraph 2:</p>
2824 <blockquote>
2825 <pre>basic_streambuf(const basic_streambuf&amp; sb);
2826 </pre>
2827
2828 <p>Constructs a copy of sb.</p>
2829 <p>Postcondtions:</p>
2830 <pre>                eback() == sb.eback()
2831                 gptr()  == sb.gptr()
2832                 egptr() == sb.egptr()
2833                 pbase() == sb.pbase()
2834                 pptr()  == sb.pptr()
2835                 epptr() == sb.epptr()
2836                 getloc() == sb.getloc()
2837 </pre>
2838
2839 <pre>basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
2840 </pre>
2841
2842 <p>Assigns the data members of sb to this.</p>
2843
2844 <p>Postcondtions:</p>
2845 <pre>                eback() == sb.eback()
2846                 gptr()  == sb.gptr()
2847                 egptr() == sb.egptr()
2848                 pbase() == sb.pbase()
2849                 pptr()  == sb.pptr()
2850                 epptr() == sb.epptr()
2851                 getloc() == sb.getloc()
2852 </pre>
2853
2854 <p>Returns: *this.</p>
2855 </blockquote>
2856
2857 <p>27.7.1 [lib.stringbuf]:</p>
2858
2859 <p><b>Option A:</b></p>
2860
2861 <blockquote>
2862 <p>Insert into the basic_stringbuf synopsis in the private section:</p>
2863
2864 <pre>basic_stringbuf(const basic_stringbuf&amp;);             // not defined
2865 basic_stringbuf&amp; operator=(const basic_stringbuf&amp;);  // not defined
2866 </pre>
2867 </blockquote>
2868
2869 <p><b>Option B:</b></p>
2870
2871 <blockquote>
2872 <p>Insert into the basic_stringbuf synopsis in the public section:</p>
2873
2874 <pre>basic_stringbuf(const basic_stringbuf&amp; sb);
2875 basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);
2876 </pre>
2877
2878 <p>27.7.1.1, insert after paragraph 4:</p>
2879
2880 <pre>basic_stringbuf(const basic_stringbuf&amp; sb);</pre>
2881
2882 <p>
2883 Constructs an independent copy of sb as if with sb.str(), and with the openmode that sb was constructed with.
2884 </p>
2885
2886 <p>Postcondtions: </p>
2887 <pre>               str() == sb.str()
2888                gptr()  - eback() == sb.gptr()  - sb.eback()
2889                egptr() - eback() == sb.egptr() - sb.eback()
2890                pptr()  - pbase() == sb.pptr()  - sb.pbase()
2891                getloc() == sb.getloc()
2892 </pre>
2893
2894 <p>
2895 Note: The only requirement on epptr() is that it point beyond the
2896 initialized range if an output sequence exists. There is no requirement
2897 that epptr() - pbase() == sb.epptr() - sb.pbase().
2898 </p>
2899
2900 <pre>basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);</pre>
2901 <p>After assignment the basic_stringbuf has the same state as if it
2902 were initially copy constructed from sb, except that the
2903 basic_stringbuf is allowed to retain any excess capacity it might have,
2904 which may in turn effect the value of epptr().
2905 </p>
2906 </blockquote>
2907
2908 <p>27.8.1.1 [lib.filebuf]</p>
2909
2910 <p>Insert at the bottom of the basic_filebuf synopsis:</p>
2911
2912 <blockquote>
2913 <pre>private:
2914   basic_filebuf(const basic_filebuf&amp;);             // not defined
2915   basic_filebuf&amp; operator=(const basic_filebuf&amp;);  // not defined
2916 </pre>
2917 </blockquote>
2918 <p><i>[Kona: this is an issue for basic_streambuf itself and for its
2919   derived classes.  We are leaning toward allowing basic_streambuf to
2920   be copyable, and specifying its precise semantics.  (Probably the
2921   obvious: copying the buffer pointers.)  We are less sure whether
2922   the streambuf derived classes should be copyable.  Howard will
2923   write up a proposal.]</i></p>
2924
2925
2926 <p><i>[Sydney: Dietmar presented a new argument against basic_streambuf
2927   being copyable: it can lead to an encapsulation violation. Filebuf
2928   inherits from streambuf. Now suppose you inhert a my_hijacking_buf
2929   from streambuf. You can copy the streambuf portion of a filebuf to a
2930   my_hijacking_buf, giving you access to the pointers into the
2931   filebuf's internal buffer. Perhaps not a very strong argument, but
2932   it was strong enough to make people nervous. There was weak
2933   preference for having streambuf not be copyable. There was weak
2934   preference for having stringbuf not be copyable even if streambuf
2935   is. Move this issue to open for now.
2936 ]</i></p>
2937
2938
2939 <p><i>[
2940 2007-01-12, Howard:
2941 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1862.html#27.5.2%20-%20Class%20template%20basic_streambuf%3CcharT,traits%3E">Rvalue Reference Recommendations for Chapter 27</a>
2942 recommends protected copy constructor and assignment for <tt>basic_streambuf</tt> with the same semantics
2943 as would be generated by the compiler.  These members aid in derived classes implementing move semantics.
2944 A protected copy constructor and copy assignment operator do not expose encapsulation more so than it is
2945 today as each data member of a <tt>basic_streambuf</tt> is already both readable and writable by derived
2946 classes via various get/set protected member functions (<tt>eback()</tt>, <tt>setp()</tt>, etc.).  Rather
2947 a protected copy constructor and copy assignment operator simply make the job of derived classes implementing
2948 move semantics less tedious and error prone.
2949 ]</i></p>
2950
2951
2952
2953
2954 <p><b>Rationale:</b></p>
2955 <p>
2956 27.5.2 [lib.streambuf]: The proposed basic_streambuf copy constructor
2957 and assignment operator are the same as currently implied by the lack
2958 of declarations: public and simply copies the data members.  This
2959 resolution is not a change but a clarification of the current
2960 standard.
2961 </p>
2962
2963 <p>
2964 27.7.1 [lib.stringbuf]: There are two reasonable options: A) Make
2965 basic_stringbuf not copyable.  This is likely the status-quo of
2966 current implementations.  B) Reasonable copy semantics of
2967 basic_stringbuf can be defined and implemented.  A copyable
2968 basic_streambuf is arguably more useful than a non-copyable one.  This
2969 should be considered as new functionality and not the fixing of a
2970 defect.  If option B is chosen, ramifications from issue 432 are taken
2971 into account.
2972 </p>
2973
2974 <p>
2975 27.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for
2976 basic_filebuf.
2977 </p>
2978
2979
2980
2981
2982
2983
2984 <hr>
2985 <h3><a name="423"></a>423. effects of negative streamsize in iostreams</h3>
2986 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2987  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
2988 <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>
2989 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2990 <p><b>Discussion:</b></p>
2991
2992 <p>
2993 A third party test suite tries to exercise istream::ignore(N) with
2994 a negative value of N and expects that the implementation will treat
2995 N as if it were 0. Our implementation asserts that (N &gt;= 0) holds and
2996 aborts the test.
2997 </p>
2998
2999 <p>
3000 I can't find anything in section 27 that prohibits such values but I don't
3001 see what the effects of such calls should be, either (this applies to
3002 a number of unformatted input functions as well as some member functions
3003 of the basic_streambuf template).
3004 </p>
3005
3006
3007 <p><b>Proposed resolution:</b></p>
3008 <p>
3009 I propose that we add to each function in clause 27 that takes an argument,
3010 say N, of type streamsize a Requires clause saying that "N &gt;= 0." The intent
3011 is to allow negative streamsize values in calls to precision() and width()
3012 but disallow it in calls to streambuf::sgetn(), istream::ignore(), or
3013 ostream::write().
3014 </p>
3015
3016 <p><i>[Kona: The LWG agreed that this is probably what we want.  However, we
3017   need a review to find all places where functions in clause 27 take
3018   arguments of type streamsize that shouldn't be allowed to go
3019   negative.  Martin will do that review.]</i></p>
3020
3021
3022
3023
3024
3025
3026 <hr>
3027 <h3><a name="424"></a>424. normative notes</h3>
3028 <p><b>Section:</b> 17.3.1.1 [structure.summary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3029  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3030 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3031 <p><b>Discussion:</b></p>
3032
3033 <p>
3034 The text in 17.3.1.1, p1 says:
3035 <br>
3036
3037 "Paragraphs labelled "Note(s):" or "Example(s):" are informative, other
3038 paragraphs are normative."
3039 <br>
3040
3041 The library section makes heavy use of paragraphs labeled "Notes(s),"
3042 some of which are clearly intended to be normative (see list 1), while
3043 some others are not (see list 2). There are also those where the intent
3044 is not so clear (see list 3).
3045 <br><br>
3046
3047 List 1 -- Examples of (presumably) normative Notes:
3048 <br>
3049
3050 20.6.1.1 [allocator.members], p3,<br>
3051 20.6.1.1 [allocator.members], p10,<br>
3052 21.3.2 [string.cons], p11,<br>
3053 22.1.1.2 [locale.cons], p11,<br>
3054 23.2.2.3 [deque.modifiers], p2,<br>
3055 25.3.7 [alg.min.max], p3,<br>
3056 26.3.6 [complex.ops], p15,<br>
3057 27.5.2.4.3 [streambuf.virt.get], p7.<br>
3058 <br>
3059
3060 List 2 -- Examples of (presumably) informative Notes:
3061 <br>
3062
3063 18.5.1.3 [new.delete.placement], p3,<br>
3064 21.3.6.6 [string::replace], p14,<br>
3065 22.2.1.4.2 [locale.codecvt.virtuals], p3,<br>
3066 25.1.1 [alg.foreach], p4,<br>
3067 26.3.5 [complex.member.ops], p1,<br>
3068 27.4.2.5 [ios.base.storage], p6.<br>
3069 <br>
3070
3071 List 3 -- Examples of Notes that are not clearly either normative
3072 or informative:
3073 <br>
3074
3075 22.1.1.2 [locale.cons], p8,<br>
3076 22.1.1.5 [locale.statics], p6,<br>
3077 27.5.2.4.5 [streambuf.virt.put], p4.<br>
3078 <br>
3079
3080 None of these lists is meant to be exhaustive.
3081 </p>
3082
3083 <p><i>[Definitely a real problem.  The big problem is there's material
3084   that doesn't quite fit any of the named paragraph categories
3085   (e.g. <b>Effects</b>).  Either we need a new kind of named
3086   paragraph, or we need to put more material in unnamed paragraphs
3087   jsut after the signature.  We need to talk to the Project Editor
3088   about how to do this.
3089 ]</i></p>
3090
3091
3092
3093 <p><b>Proposed resolution:</b></p>
3094 <p><i>[Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks".
3095 Fixed as editorial.  This change has been in the WD since the post-Redmond mailing, in 2004.
3096 Recommend NAD.]</i></p>
3097
3098 <p><i>[
3099 Batavia:  We feel that the references in List 2 above should be changed from <i>Remarks</i>
3100 to <i>Notes</i>.  We also feel that those items in List 3 need to be double checked for
3101 the same change.  Alan and Pete to review.
3102 ]</i></p>
3103
3104
3105
3106
3107
3108 <hr>
3109 <h3><a name="427"></a>427. stage 2 and rationale of DR 221</h3>
3110 <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#Open">Open</a>
3111  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3112 <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>
3113 <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>
3114 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3115 <p><b>Discussion:</b></p>
3116 <p>
3117 The requirements specified in Stage 2 and reiterated in the rationale
3118 of DR 221 (and echoed again in DR 303) specify that num_get&lt;charT&gt;::
3119 do_get() compares characters on the stream against the widened elements
3120 of "012...abc...ABCX+-"
3121 </p>
3122
3123 <p>
3124 An implementation is required to allow programs to instantiate the num_get
3125 template on any charT that satisfies the requirements on a user-defined
3126 character type. These requirements do not include the ability of the
3127 character type to be equality comparable (the char_traits template must
3128 be used to perform tests for equality). Hence, the num_get template cannot
3129 be implemented to support any arbitrary character type. The num_get template
3130 must either make the assumption that the character type is equality-comparable
3131 (as some popular implementations do), or it may use char_traits&lt;charT&gt; to do
3132 the comparisons (some other popular implementations do that). This diversity
3133 of approaches makes it difficult to write portable programs that attempt to
3134 instantiate the num_get template on user-defined types.
3135 </p>
3136
3137 <p><i>[Kona: the heart of the problem is that we're theoretically
3138   supposed to use traits classes for all fundamental character
3139   operations like assignment and comparison, but facets don't have
3140   traits parameters.  This is a fundamental design flaw and it
3141   appears all over the place, not just in this one place.  It's not
3142   clear what the correct solution is, but a thorough review of facets
3143   and traits is in order.  The LWG considered and rejected the
3144   possibility of changing numeric facets to use narrowing instead of
3145   widening.  This may be a good idea for other reasons (see issue
3146   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#459">459</a>), but it doesn't solve the problem raised by this
3147   issue.  Whether we use widen or narrow the <tt>num_get</tt> facet
3148   still has no idea which traits class the user wants to use for
3149   the comparison, because only streams, not facets, are passed traits
3150   classes.   The standard does not require that two different
3151   traits classes with the same <tt>char_type</tt> must necessarily
3152   have the same behavior.]</i></p>
3153
3154
3155 <p>Informally, one possibility: require that some of the basic
3156 character operations, such as <tt>eq</tt>, <tt>lt</tt>,
3157 and <tt>assign</tt>, must behave the same way for all traits classes
3158 with the same <tt>char_type</tt>.  If we accept that limitation on
3159 traits classes, then the facet could reasonably be required to
3160 use <tt>char_traits&lt;charT&gt;</tt>.</p>
3161
3162
3163 <p><b>Proposed resolution:</b></p>
3164
3165
3166
3167
3168 <hr>
3169 <h3><a name="430"></a>430. valarray subset operations</h3>
3170 <p><b>Section:</b> 26.5.2.4 [valarray.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3171  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3172 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3173 <p><b>Discussion:</b></p>
3174 <p>
3175 The standard fails to specify the behavior of valarray::operator[](slice)
3176 and other valarray subset operations when they are passed an "invalid"
3177 slice object, i.e., either a slice that doesn't make sense at all (e.g.,
3178 slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray
3179 object (e.g., slice (2, 1, 1) for a valarray of size 1).
3180 </p>
3181 <p><i>[Kona: the LWG believes that invalid slices should invoke
3182   undefined behavior.  Valarrays are supposed to be designed for high
3183   performance, so we don't want to require specific checking.  We
3184   need wording to express this decision.]</i></p>
3185
3186
3187
3188 <p><b>Proposed resolution:</b></p>
3189
3190
3191
3192
3193 <hr>
3194 <h3><a name="431"></a>431. Swapping containers with unequal allocators</h3>
3195 <p><b>Section:</b> 20.1.2 [allocator.requirements], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3196  <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-09-20</p>
3197 <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>
3198 <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>
3199 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3200 <p><b>Discussion:</b></p>
3201 <p>Clause 20.1.2 [allocator.requirements] paragraph 4 says that implementations
3202   are permitted to supply containers that are unable to cope with
3203   allocator instances and that container implementations may assume
3204   that all instances of an allocator type compare equal.  We gave
3205   implementers this latitude as a temporary hack, and eventually we
3206   want to get rid of it.  What happens when we're dealing with
3207   allocators that <i>don't</i> compare equal?
3208 </p>
3209
3210 <p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
3211   objects of type <tt>vector&lt;int, my_alloc&gt;</tt> and that
3212   <tt>v1.get_allocator() != v2.get_allocator()</tt>.  What happens if
3213   we write <tt>v1.swap(v2)</tt>?  Informally, three possibilities:</p>
3214
3215 <p>1. This operation is illegal.  Perhaps we could say that an
3216   implementation is required to check and to throw an exception, or
3217   perhaps we could say it's undefined behavior.</p>
3218 <p>2. The operation performs a slow swap (i.e. using three
3219   invocations of <tt>operator=</tt>, leaving each allocator with its
3220   original container.  This would be an O(N) operation.</p>
3221 <p>3. The operation swaps both the vectors' contents and their
3222   allocators.  This would be an O(1) operation. That is:</p>
3223   <blockquote>
3224   <pre>    my_alloc a1(...);
3225     my_alloc a2(...);
3226     assert(a1 != a2);
3227
3228     vector&lt;int, my_alloc&gt; v1(a1);
3229     vector&lt;int, my_alloc&gt; v2(a2);
3230     assert(a1 == v1.get_allocator());
3231     assert(a2 == v2.get_allocator());
3232
3233     v1.swap(v2);
3234     assert(a1 == v2.get_allocator());
3235     assert(a2 == v1.get_allocator());
3236   </pre>
3237   </blockquote>
3238
3239 <p><i>[Kona: This is part of a general problem.  We need a paper
3240   saying how to deal with unequal allocators in general.]</i></p>
3241
3242
3243 <p><i>[pre-Sydney: Howard argues for option 3 in
3244 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html">N1599</a>.
3245 ]</i></p>
3246
3247
3248 <p><i>[
3249 2007-01-12, Howard:  This issue will now tend to come up more often with move constructors
3250 and move assignment operators.  For containers, these members transfer resources (i.e.
3251 the allocated memory) just like swap.
3252 ]</i></p>
3253
3254
3255 <p><i>[
3256 Batavia:  There is agreement to overload the container <tt>swap</tt> on the allocator's Swappable
3257 requirement using concepts.  If the allocator supports Swappable, then container's swap will
3258 swap allocators, else it will perform a "slow swap" using copy construction and copy assignment.
3259 ]</i></p>
3260
3261
3262
3263
3264 <p><b>Proposed resolution:</b></p>
3265
3266
3267
3268
3269
3270 <hr>
3271 <h3><a name="446"></a>446. Iterator equality between different containers</h3>
3272 <p><b>Section:</b> 24.1 [iterator.requirements], 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3273  <b>Submitter:</b> Andy Koenig <b>Date:</b> 2003-12-16</p>
3274 <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>
3275 <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>
3276 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3277 <p><b>Discussion:</b></p>
3278 <p>
3279 What requirements does the standard place on equality comparisons between
3280 iterators that refer to elements of different containers.  For example, if
3281 v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true?
3282 Is it allowed to throw an exception?
3283 </p>
3284
3285 <p>
3286 The standard appears to be silent on both questions.
3287 </p>
3288 <p><i>[Sydney: The intention is that comparing two iterators from
3289 different containers is undefined, but it's not clear if we say that,
3290 or even whether it's something we should be saying in clause 23 or in
3291 clause 24.  Intuitively we might want to say that equality is defined
3292 only if one iterator is reachable from another, but figuring out how
3293 to say it in any sensible way is a bit tricky: reachability is defined
3294 in terms of equality, so we can't also define equality in terms of
3295 reachability.
3296 ]</i></p>
3297
3298
3299
3300
3301 <p><b>Proposed resolution:</b></p>
3302
3303
3304
3305
3306
3307
3308 <hr>
3309 <h3><a name="454"></a>454. basic_filebuf::open should accept wchar_t names</h3>
3310 <p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3311  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
3312 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#filebuf.members">active issues</a> in [filebuf.members].</p>
3313 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.members].</p>
3314 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3315 <p><b>Discussion:</b></p>
3316 <pre>    basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
3317 </pre>
3318
3319 <p>should be supplemented with the overload:</p>
3320
3321 <pre>    basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
3322 </pre>
3323
3324 <p>
3325 Depending on the operating system, one of these forms is fundamental and
3326 the other requires an implementation-defined mapping to determine the
3327 actual filename.
3328 </p>
3329
3330 <p><i>[Sydney: Yes, we want to allow wchar_t filenames.  Bill will
3331   provide wording.]</i></p>
3332
3333
3334 <p><i>[
3335 In Toronto we noted that this is issue 5 from
3336 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1569.htm">N1569</a>.
3337 ]</i></p>
3338
3339 <p>
3340 How does this interact with the newly-defined character types, and how
3341 do we avoid interface explosion considering <tt>std::string</tt> overloads that
3342 were added? Propose another solution that is different than the
3343 suggestion proposed by PJP.
3344 </p>
3345 <p>
3346 Suggestion is to make a member template function for <tt>basic_string</tt> (for
3347 <tt>char</tt>, <tt>wchar_t</tt>, <tt>u16char</tt>, <tt>u32char</tt> instantiations), and then just keep a
3348 <tt>const char*</tt> member.
3349 </p>
3350 <p>
3351 Goal is to do implicit conversion between character string literals to
3352 appropriate <tt>basic_string</tt> type. Not quite sure if this is possible.
3353 </p>
3354 <p>
3355 Implementors are free to add specific overloads for non-char character
3356 types.
3357 </p>
3358
3359
3360
3361 <p><b>Proposed resolution:</b></p>
3362
3363 <p>Change from:</p>
3364 <blockquote>
3365 <pre>basic_filebuf&lt;charT,traits&gt;* open(
3366         const char* s,
3367         ios_base::openmode mode );
3368 </pre>
3369
3370 <p>
3371 Effects: If is_open() != false, returns a null pointer.
3372 Otherwise, initializes the filebuf as required. It then
3373 opens a file, if possible, whose name is the NTBS s ("as if"
3374 by calling std::fopen(s,modstr)).</p>
3375 </blockquote>
3376
3377 <p>to:</p>
3378
3379 <blockquote>
3380 <pre>basic_filebuf&lt;charT,traits&gt;* open(
3381         const char* s,
3382         ios_base::openmode mode );
3383
3384 basic_filebuf&lt;charT,traits&gt;* open(
3385         const wchar_t* ws,
3386         ios_base::openmode mode );
3387 </pre>
3388
3389 <p>
3390 Effects: If is_open() != false, returns a null pointer.
3391 Otherwise, initializes the filebuf as required. It then
3392 opens a file, if possible, whose name is the NTBS s ("as if"
3393 by calling std::fopen(s,modstr)).
3394 For the second signature, the NTBS s is determined from the
3395 WCBS ws in an implementation-defined manner.
3396 </p>
3397
3398 <p>
3399 (NOTE: For a system that "naturally" represents a filename
3400 as a WCBS, the NTBS s in the first signature may instead
3401 be mapped to a WCBS; if so, it follows the same mapping
3402 rules as the first argument to open.)
3403 </p>
3404 </blockquote>
3405
3406
3407
3408 <p><b>Rationale:</b></p>
3409 <p>
3410 Slightly controversial, but by a 7-1 straw poll the LWG agreed to move
3411 this to Ready.  The controversy was because the mapping between wide
3412 names and files in a filesystem is implementation defined.  The
3413 counterargument, which most but not all LWG members accepted, is that
3414 the mapping between narrow files names and files is also
3415 implemenation defined.</p>
3416
3417 <p><i>[Lillehammer: Moved back to "open" status, at Beman's urging.
3418 (1) Why just basic_filebuf, instead of also basic_fstream (and
3419 possibly other things too). (2) Why not also constructors that take
3420 std::basic_string? (3) We might want to wait until we see Beman's
3421 filesystem library; we might decide that it obviates this.]</i></p>
3422
3423
3424
3425
3426
3427
3428
3429
3430
3431 <hr>
3432 <h3><a name="458"></a>458. 24.1.5 contains unintented limitation for operator-</h3>
3433 <p><b>Section:</b> 24.1.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3434  <b>Submitter:</b> Daniel Frey <b>Date:</b> 2004-02-27</p>
3435 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
3436 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3437 <p><b>Discussion:</b></p>
3438 <p>
3439 In 24.1.5 [lib.random.access.iterators], table 76 the operational
3440 semantics for the expression "r -= n" are defined as "return r += -n".
3441 This means, that the expression -n must be valid, which is not the case
3442 for unsigned types.
3443 </p>
3444
3445 <p><i>[
3446 Sydney: Possibly not a real problem, since difference type is required
3447 to be a signed integer type. However, the wording in the standard may
3448 be less clear than we would like.
3449 ]</i></p>
3450
3451
3452
3453
3454 <p><b>Proposed resolution:</b></p>
3455 <p>
3456 To remove this limitation, I suggest to change the
3457 operational semantics for this column to:
3458 </p>
3459 <blockquote><pre>    { Distance m = n;
3460       if (m &gt;= 0)
3461         while (m--) --r;
3462       else
3463         while (m++) ++r;
3464       return r; }
3465 </pre></blockquote>
3466
3467
3468
3469
3470
3471
3472 <hr>
3473 <h3><a name="459"></a>459. Requirement for widening in stage 2 is overspecification</h3>
3474 <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#Open">Open</a>
3475  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-03-16</p>
3476 <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>
3477 <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>
3478 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3479 <p><b>Discussion:</b></p>
3480 <p>When parsing strings of wide-character digits, the standard
3481   requires the library to widen narrow-character "atoms" and compare
3482   the widened atoms against the characters that are being parsed.
3483   Simply narrowing the wide characters would be far simpler, and
3484   probably more efficient.  The two choices are equivalent except in
3485   convoluted test cases, and many implementations already ignore the
3486   standard and use narrow instead of widen.</p>
3487
3488 <p>
3489 First, I disagree that using narrow() instead of widen() would
3490 necessarily have unfortunate performance implications. A possible
3491 implementation of narrow() that allows num_get to be implemented
3492 in a much simpler and arguably comparably efficient way as calling
3493 widen() allows, i.e. without making a virtual call to do_narrow every
3494 time, is as follows:
3495 </p>
3496
3497 <pre>  inline char ctype&lt;wchar_t&gt;::narrow (wchar_t wc, char dflt) const
3498   {
3499       const unsigned wi = unsigned (wc);
3500
3501       if (wi &gt; UCHAR_MAX)
3502           return typeid (*this) == typeid (ctype&lt;wchar_t&gt;) ?
3503                  dflt : do_narrow (wc, dflt);
3504
3505       if (narrow_ [wi] &lt; 0) {
3506          const char nc = do_narrow (wc, dflt);
3507          if (nc == dflt)
3508              return dflt;
3509          narrow_ [wi] = nc;
3510       }
3511
3512       return char (narrow_ [wi]);
3513   }
3514 </pre>
3515
3516 <p>
3517 Second, I don't think the change proposed in the issue (i.e., to use
3518 narrow() instead of widen() during Stage 2) would be at all
3519 drastic. Existing implementations with the exception of libstdc++
3520 currently already use narrow() so the impact of the change on programs
3521 would presumably be isolated to just a single implementation. Further,
3522 since narrow() is not required to translate alternate wide digit
3523 representations such as those mentioned in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>
3524 to
3525 their narrow equivalents (i.e., the portable source characters '0'
3526 through '9'), the change does not necessarily imply that these
3527 alternate digits would be treated as ordinary digits and accepted as
3528 part of numbers during parsing. In fact, the requirement in 22.2.1.1.2
3529 [locale.ctype.virtuals], p13 forbids narrow() to translate an alternate
3530 digit character, wc, to an ordinary digit in the basic source
3531 character set unless the expression
3532 (ctype&lt;charT&gt;::is(ctype_base::digit, wc) == true) holds. This in
3533 turn is prohibited by the C standard (7.25.2.1.5, 7.25.2.1.5, and
3534 5.2.1, respectively) for charT of either char or wchar_t.
3535 </p>
3536
3537 <p><i>[Sydney: To a large extent this is a nonproblem. As long as
3538 you're only trafficking in char and wchar_t we're only dealing with a
3539 stable character set, so you don't really need either 'widen' or
3540 'narrow': can just use literals. Finally, it's not even clear whether
3541 widen-vs-narrow is the right question; arguably we should be using
3542 codecvt instead.]</i></p>
3543
3544
3545
3546
3547 <p><b>Proposed resolution:</b></p>
3548 <p>Change stage 2 so that implementations are permitted to use either
3549 technique to perform the comparison:</p>
3550 <ol>
3551   <li> call widen on the atoms and compare (either by using
3552       operator== or char_traits&lt;charT&gt;::eq) the input with
3553       the widened atoms, or</li>
3554   <li> call narrow on the input and compare the narrow input
3555       with the atoms</li>
3556   <li> do (1) or (2) only if charT is not char or wchar_t,
3557       respectively; i.e., avoid calling widen or narrow
3558       if it the source and destination types are the same</li>
3559 </ol>
3560
3561
3562
3563
3564
3565 <hr>
3566 <h3><a name="462"></a>462. Destroying objects with static storage duration</h3>
3567 <p><b>Section:</b> 3.6.3 [basic.start.term], 18.3 [cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3568  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-03-23</p>
3569 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3570 <p><b>Discussion:</b></p>
3571 <p>
3572 3.6.3 Termination spells out in detail the interleaving of static
3573 destructor calls and calls to functions registered with atexit. To
3574 match this behavior requires intimate cooperation between the code
3575 that calls destructors and the exit/atexit machinery. The former
3576 is tied tightly to the compiler; the latter is a primitive mechanism
3577 inherited from C that traditionally has nothing to do with static
3578 construction and destruction. The benefits of intermixing destructor
3579 calls with atexit handler calls is questionable at best, and <i>very</i>
3580 difficult to get right, particularly when mixing third-party C++
3581 libraries with different third-party C++ compilers and C libraries
3582 supplied by still other parties.
3583 </p>
3584
3585 <p>
3586 I believe the right thing to do is defer all static destruction
3587 until after all atexit handlers are called. This is a change in
3588 behavior, but one that is likely visible only to perverse test
3589 suites. At the very least, we should <i>permit</i> deferred destruction
3590 even if we don't require it.
3591 </p>
3592
3593 <p><i>[If this is to be changed, it should probably be changed by CWG.
3594   At this point, however, the LWG is leaning toward NAD.  Implementing
3595   what the standard says is hard work, but it's not impossible and
3596   most vendors went through that pain years ago.  Changing this
3597   behavior would be a user-visible change, and would break at least
3598   one real application.]</i></p>
3599
3600
3601 <p><i>[
3602 Batavia:  Send to core with our recommendation that we should permit deferred
3603 destruction but not require it.
3604 ]</i></p>
3605
3606
3607 <p><i>[
3608 Howard:  The course of action recommended in Batavia would undo LWG
3609 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a> and break current code implementing the "phoenix
3610 singleton". Search the net for "phoenix singleton atexit" to get a feel
3611 for the size of the adverse impact this change would have.  Below is
3612 sample code which implements the phoenix singleton and would break if
3613 <tt>atexit</tt> is changed in this way:
3614 ]</i></p>
3615
3616
3617 <blockquote><pre>#include &lt;cstdlib&gt;
3618 #include &lt;iostream&gt;
3619 #include &lt;type_traits&gt;
3620 #include &lt;new&gt;
3621
3622 class A
3623 {
3624     bool alive_;
3625     A(const A&amp;);
3626     A&amp; operator=(const A&amp;);
3627 public:
3628     A() : alive_(true) {std::cout &lt;&lt; "A()\n";}
3629     ~A() {alive_ = false; std::cout &lt;&lt; "~A()\n";}
3630     void use()
3631     {
3632         if (alive_)
3633             std::cout &lt;&lt; "A is alive\n";
3634         else
3635             std::cout &lt;&lt; "A is dead\n";
3636     }
3637 };
3638
3639 void deallocate_resource();
3640
3641 // This is the phoenix singleton pattern
3642 A&amp; get_resource(bool create = true)
3643 {
3644     static std::aligned_storage&lt;sizeof(A), std::alignment_of&lt;A&gt;::value&gt;::type buf;
3645     static A* a;
3646     if (create)
3647     {
3648         if (a != (A*)&amp;buf)
3649         {
3650             a = ::new (&amp;buf) A;
3651             std::atexit(deallocate_resource);
3652         }
3653     }
3654     else
3655     {
3656         a-&gt;~A();
3657         a = (A*)&amp;buf + 1;
3658     }
3659     return *a;
3660 }
3661
3662 void deallocate_resource()
3663 {
3664     get_resource(false);
3665 }
3666
3667 void use_A(const char* message)
3668 {
3669     A&amp; a = get_resource();
3670     std::cout &lt;&lt; "Using A " &lt;&lt; message &lt;&lt; "\n";
3671     a.use();
3672 }
3673
3674 struct B
3675 {
3676     ~B() {use_A("from ~B()");}
3677 };
3678
3679 B b;
3680
3681 int main()
3682 {
3683     use_A("from main()");
3684 }
3685 </pre></blockquote>
3686
3687 <p>
3688 The correct output is:
3689 </p>
3690
3691 <blockquote><pre>A()
3692 Using A from main()
3693 A is alive
3694 ~A()
3695 A()
3696 Using A from ~B()
3697 A is alive
3698 ~A()
3699 </pre></blockquote>
3700
3701
3702
3703 <p><b>Proposed resolution:</b></p>
3704 <p>
3705 </p>
3706
3707
3708
3709
3710
3711 <hr>
3712 <h3><a name="471"></a>471. result of what() implementation-defined</h3>
3713 <p><b>Section:</b> 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3714  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
3715 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#type.info">issues</a> in [type.info].</p>
3716 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3717 <p><b>Discussion:</b></p>
3718
3719 <p>[lib.exception] specifies the following:</p>
3720 <pre>    exception (const exception&amp;) throw();
3721     exception&amp; operator= (const exception&amp;) throw();
3722
3723     -4- Effects: Copies an exception object.
3724     -5- Notes: The effects of calling what() after assignment
3725         are implementation-defined.
3726 </pre>
3727
3728 <p>
3729 First, does the Note only apply to the assignment operator? If so,
3730 what are the effects of calling what() on a copy of an object? Is
3731 the returned pointer supposed to point to an identical copy of
3732 the NTBS returned by what() called on the original object or not?
3733 </p>
3734
3735 <p>
3736 Second, is this Note intended to extend to all the derived classes
3737 in section 19? I.e., does the standard provide any guarantee for
3738 the effects of what() called on a copy of any of the derived class
3739 described in section 19?
3740 </p>
3741
3742 <p>
3743 Finally, if the answer to the first question is no, I believe it
3744 constitutes a defect since throwing an exception object typically
3745 implies invoking the copy ctor on the object. If the answer is yes,
3746 then I believe the standard ought to be clarified to spell out
3747 exactly what the effects are on the copy (i.e., after the copy
3748 ctor was called).
3749 </p>
3750
3751 <p><i>[Redmond: Yes, this is fuzzy.  The issue of derived classes is
3752   fuzzy too.]</i></p>
3753
3754
3755 <p><i>[
3756 Batavia: Howard provided wording.
3757 ]</i></p>
3758
3759
3760
3761
3762 <p><b>Proposed resolution:</b></p>
3763
3764 <p>
3765 Change 18.7.1 [exception] to:
3766 </p>
3767
3768 <blockquote>
3769 <pre>exception(const exception&amp; <ins><i>e</i></ins>) throw();
3770 exception&amp; operator=(const exception&amp; <ins><i>e</i></ins>) throw();</pre>
3771 <blockquote>
3772 <p>
3773 -4- <i>Effects:</i> Copies an exception object.
3774 </p>
3775 <p>
3776 <del> -5- <i>Remarks:</i> The effects of calling what() after assignment are implementation-defined.</del>
3777 </p>
3778 <p>
3779 <ins>-5- <i>Throws:</i> Nothing.  This also applies
3780 to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
3781 </p>
3782 <p>
3783 <ins>-7- <i>Postcondition:</i> <tt>strcmp(what(), <i>e</i>.what()) == 0</tt>.  This also applies
3784 to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
3785 </p>
3786
3787 </blockquote>
3788 </blockquote>
3789
3790
3791
3792
3793 <hr>
3794 <h3><a name="473"></a>473. underspecified ctype calls</h3>
3795 <p><b>Section:</b> 22.2.1.1 [locale.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3796  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-07-01</p>
3797 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3798 <p><b>Discussion:</b></p>
3799 <p>
3800 Most ctype member functions come in two forms: one that operates
3801 on a single character at a time and another form that operates
3802 on a range of characters. Both forms are typically described by
3803 a single Effects and/or Returns clause.
3804 </p>
3805 <p>
3806 The Returns clause of each of the single-character non-virtual forms
3807 suggests that the function calls the corresponding single character
3808 virtual function, and that the array form calls the corresponding
3809 virtual array form. Neither of the two forms of each virtual member
3810 function is required to be implemented in terms of the other.
3811 </p>
3812 <p>
3813 There are three problems:
3814 </p>
3815 <p>
3816 1. One is that while the standard does suggest that each non-virtual
3817 member function calls the corresponding form of the virtual function,
3818 it doesn't actually explicitly require it.
3819 </p>
3820 <p>
3821 Implementations that cache results from some of the virtual member
3822 functions for some or all values of their arguments might want to
3823 call the array form from the non-array form the first time to fill
3824 the cache and avoid any or most subsequent virtual calls. Programs
3825 that rely on each form of the virtual function being called from
3826 the corresponding non-virtual function will see unexpected behavior
3827 when using such implementations.
3828 </p>
3829 <p>
3830 2. The second problem is that either form of each of the virtual
3831 functions can be overridden by a user-defined function in a derived
3832 class to return a value that is different from the one produced by
3833 the virtual function of the alternate form that has not been
3834 overriden.
3835 </p>
3836 <p>
3837 Thus, it might be possible for, say, ctype::widen(c) to return one
3838 value, while for ctype::widen(&amp;c, &amp;c + 1, &amp;wc) to set
3839 wc to another value. This is almost certainly not intended. Both
3840 forms of every function should be required to return the same result
3841 for the same character, otherwise the same program using an
3842 implementation that calls one form of the functions will behave
3843 differently than when using another implementation that calls the
3844 other form of the function "under the hood."
3845 </p>
3846 <p>
3847 3. The last problem is that the standard text fails to specify whether
3848 one form of any of the virtual functions is permitted to be implemented
3849 in terms of the other form or not, and if so, whether it is required
3850 or permitted to call the overridden virtual function or not.
3851 </p>
3852 <p>
3853 Thus, a program that overrides one of the virtual functions so that
3854 it calls the other form which then calls the base member might end
3855 up in an infinite loop if the called form of the base implementation
3856 of the function in turn calls the other form.
3857 </p>
3858 <p>
3859 Lillehammer: Part of this isn't a real problem. We already talk about
3860 caching. 22.1.1/6 But part is a real problem. ctype virtuals may call
3861 each other, so users don't know which ones to override to avoid avoid
3862 infinite loops.</p>
3863
3864 <p>This is a problem for all facet virtuals, not just ctype virtuals,
3865 so we probably want a blanket statement in clause 22 for all
3866 facets. The LWG is leaning toward a blanket prohibition, that a
3867 facet's virtuals may never call each other. We might want to do that
3868 in clause 27 too, for that matter. A review is necessary.  Bill will
3869 provide wording.</p>
3870
3871
3872 <p><b>Proposed resolution:</b></p>
3873
3874
3875
3876
3877 <hr>
3878 <h3><a name="484"></a>484. Convertible to T</h3>
3879 <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#Open">Open</a>
3880  <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-09-16</p>
3881 <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>
3882 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3883 <p><b>Discussion:</b></p>
3884 <p>From comp.std.c++:</p>
3885
3886 <p>
3887 I note that given an input iterator a for type T,
3888 then *a only has to be "convertable to T", not actually of type T.
3889 </p>
3890
3891 <p>Firstly, I can't seem to find an exact definition of "convertable to T".
3892 While I assume it is the obvious definition (an implicit conversion), I
3893 can't find an exact definition. Is there one?</p>
3894
3895 <p>Slightly more worryingly, there doesn't seem to be any restriction on
3896 the this type, other than it is "convertable to T". Consider two input
3897 iterators a and b. I would personally assume that most people would
3898 expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that
3899 the standard requires that, and that whatever type *a is (call it U)
3900 could have == defined on it with totally different symantics and still
3901 be a valid inputer iterator.</p>
3902
3903 <p>Is this a correct reading? When using input iterators should I write
3904 T(*a) all over the place to be sure that the object i'm using is the
3905 class I expect?</p>
3906
3907 <p>This is especially a nuisance for operations that are defined to be
3908   "convertible to bool".  (This is probably allowed so that
3909   implementations could return say an int and avoid an unnessary
3910   conversion. However all implementations I have seen simply return a
3911   bool anyway.  Typical implemtations of STL algorithms just write
3912   things like <tt>while(a!=b &amp;&amp; *a!=0)</tt>.  But strictly
3913   speaking, there are lots of types that are convertible to T but
3914   that also overload the appropriate operators so this doesn't behave
3915   as expected.</p>
3916
3917 <p>If we want to make code like this legal (which most people seem to
3918   expect), then we'll need to tighten up what we mean by "convertible
3919   to T".</p>
3920
3921 <p><i>[Lillehammer: The first part is NAD, since "convertible" is
3922  well-defined in core. The second part is basically about pathological
3923  overloads. It's a minor problem but a real one. So leave open for
3924  now, hope we solve it as part of iterator redesign.]</i></p>
3925
3926
3927
3928 <p><b>Proposed resolution:</b></p>
3929
3930
3931
3932
3933
3934 <hr>
3935 <h3><a name="485"></a>485. output iterator insufficently constrained</h3>
3936 <p><b>Section:</b> 24.1.2 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3937  <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-10-13</p>
3938 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
3939 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3940 <p><b>Discussion:</b></p>
3941 <p>
3942 The note on 24.1.2 Output iterators insufficently limits what can be
3943 performed on output iterators. While it requires that each iterator is
3944 progressed through only once and that each iterator is written to only
3945 once, it does not require the following things:</p>
3946
3947 <p>Note: Here it is assumed that x is an output iterator of type X which
3948 has not yet been assigned to.</p>
3949
3950 <p>a) That each value of the output iterator is written to:
3951 The standard allows:
3952 ++x; ++x; ++x;
3953 </p>
3954
3955 <p>
3956 b) That assignments to the output iterator are made in order
3957 X a(x); ++a; *a=1; *x=2; is allowed
3958 </p>
3959
3960 <p>
3961 c) Chains of output iterators cannot be constructed:
3962 X a(x); ++a; X b(a); ++b; X c(b); ++c; is allowed, and under the current
3963 wording (I believe) x,a,b,c could be written to in any order.
3964 </p>
3965
3966 <p>I do not believe this was the intension of the standard?</p>
3967 <p><i>[Lillehammer: Real issue.  There are lots of constraints we
3968   intended but didn't specify.  Should be solved as part of iterator
3969   redesign.]</i></p>
3970
3971
3972
3973 <p><b>Proposed resolution:</b></p>
3974
3975
3976
3977
3978
3979 <hr>
3980 <h3><a name="492"></a>492. Invalid iterator arithmetic expressions</h3>
3981 <p><b>Section:</b> 23 [containers], 24 [iterators], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3982  <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
3983 <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>
3984 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3985 <p><b>Discussion:</b></p>
3986 <p>Various clauses other than clause 25 make use of iterator arithmetic not
3987 supported by the iterator category in question.
3988 Algorithms in clause 25 are exceptional because of 25 [lib.algorithms],
3989 paragraph 9, but this paragraph does not provide semantics to the
3990 expression "iterator - n", where n denotes a value of a distance type
3991 between iterators.</p>
3992
3993 <p>1) Examples of current wording:</p>
3994
3995 <p>Current wording outside clause 25:</p>
3996
3997 <p>
3998 23.2.2.4 [lib.list.ops], paragraphs 19-21: "first + 1", "(i - 1)",
3999 "(last - first)"
4000 23.3.1.1 [lib.map.cons], paragraph 4: "last - first"
4001 23.3.2.1 [lib.multimap.cons], paragraph 4: "last - first"
4002 23.3.3.1 [lib.set.cons], paragraph 4: "last - first"
4003 23.3.4.1 [lib.multiset.cons], paragraph 4: "last - first"
4004 24.4.1 [lib.reverse.iterators], paragraph 1: "(i - 1)"
4005 </p>
4006
4007 <p>
4008 [Important note: The list is not complete, just an illustration. The
4009 same issue might well apply to other paragraphs not listed here.]</p>
4010
4011 <p>None of these expressions is valid for the corresponding iterator
4012 category.</p>
4013
4014 <p>Current wording in clause 25:</p>
4015
4016 <p>
4017 25.1.1 [lib.alg.foreach], paragraph 1: "last - 1"
4018 25.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 -
4019 (last2-first2))"
4020 25.2.8 [lib.alg.unique], paragraph 1: "(i - 1)"
4021 25.2.8 [lib.alg.unique], paragraph 5: "(i - 1)"
4022 </p>
4023
4024 <p>
4025 However, current wording of 25 [lib.algorithms], paragraph 9 covers
4026 neither of these four cases:</p>
4027
4028 <p>Current wording of 25 [lib.algorithms], paragraph 9:</p>
4029
4030 <p>
4031 "In the description of the algorithms operator + and - are used for some
4032 of the iterator categories for which they do not have to be defined. In
4033 these cases the semantics of a+n is the same as that of</p>
4034 <pre>{X tmp = a;
4035 advance(tmp, n);
4036 return tmp;
4037 }
4038 </pre>
4039 <p>and that of b-a is the same as of return distance(a, b)"</p>
4040
4041 <p>
4042 This paragrpah does not take the expression "iterator - n" into account,
4043 where n denotes a value of a distance type between two iterators [Note:
4044 According to current wording, the expression "iterator - n" would be
4045 resolved as equivalent to "return distance(n, iterator)"]. Even if the
4046 expression "iterator - n" were to be reinterpreted as equivalent to
4047 "iterator + -n" [Note: This would imply that "a" and "b" were
4048 interpreted implicitly as values of iterator types, and "n" as value of
4049 a distance type], then 24.3.4/2 interfers because it says: "Requires: n
4050 may be negative only for random access and bidirectional iterators.",
4051 and none of the paragraphs quoted above requires the iterators on which
4052 the algorithms operate to be of random access or bidirectional category.
4053 </p>
4054
4055 <p>2) Description of intended behavior:</p>
4056
4057 <p>
4058 For the rest of this Defect Report, it is assumed that the expression
4059 "iterator1 + n" and "iterator1 - iterator2" has the semantics as
4060 described in current 25 [lib.algorithms], paragraph 9, but applying to
4061 all clauses. The expression "iterator1 - n" is equivalent to an
4062 result-iterator for which the expression "result-iterator + n" yields an
4063 iterator denoting the same position as iterator1 does. The terms
4064 "iterator1", "iterator2" and "result-iterator" shall denote the value of
4065 an iterator type, and the term "n" shall denote a value of a distance
4066 type between two iterators.</p>
4067
4068 <p>
4069 All implementations known to the author of this Defect Report comply
4070 with these assumptions.
4071 No impact on current code is expected.</p>
4072
4073 <p>3) Proposed fixes:</p>
4074
4075
4076 <p>Change 25 [lib.algorithms], paragraph 9 to:</p>
4077
4078 <p>
4079 "In the description of the algorithms operator + and - are used for some
4080 of the iterator categories for which they do not have to be defined. In
4081 this paragraph, a and b denote values of an iterator type, and n denotes
4082 a value of a distance type between two iterators. In these cases the
4083 semantics of a+n is the same as that of</p>
4084 <pre>{X tmp = a;
4085 advance(tmp, n);
4086 return tmp;
4087 }
4088 </pre>
4089 <p>,the semantics of a-n denotes the value of an iterator i for which the
4090 following condition holds:
4091 advance(i, n) == a,
4092 and that of b-a is the same as of
4093 return distance(a, b)".
4094 </p>
4095
4096 <p>Comments to the new wording:</p>
4097
4098 <p>
4099 a) The wording " In this paragraph, a and b denote values of an iterator
4100 type, and n denotes a value of a distance type between two iterators."
4101 was added so the expressions "b-a" and "a-n" are distinguished regarding
4102 the types of the values on which they operate.
4103 b) The wording ",the semantics of a-n denotes the value of an iterator i
4104 for which the following condition holds: advance(i, n) == a" was added
4105 to cover the expression 'iterator - n'. The wording "advance(i, n) == a"
4106 was used to avoid a dependency on the semantics of a+n, as the wording
4107 "i + n == a" would have implied. However, such a dependency might well
4108 be deserved.
4109 c) DR 225 is not considered in the new wording.
4110 </p>
4111
4112 <p>
4113 Proposed fixes regarding invalid iterator arithmetic expressions outside
4114 clause 25:</p>
4115
4116 <p>
4117 Either
4118 a) Move modified 25 [lib.algorithms], paragraph 9 (as proposed above)
4119 before any current invalid iterator arithmetic expression. In that case,
4120 the first sentence of 25 [lib.algorithms], paragraph 9, need also to be
4121 modified and could read: "For the rest of this International Standard,
4122 ...." / "In the description of the following clauses including this
4123 ...." / "In the description of the text below ..." etc. - anyways
4124 substituting the wording "algorithms", which is a straight reference to
4125 clause 25.
4126 In that case, 25 [lib.algorithms] paragraph 9 will certainly become
4127 obsolete.
4128 Alternatively,
4129 b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
4130 paragraph 9, to the beginning of each clause containing invalid iterator
4131 arithmetic expressions.
4132 Alternatively,
4133 c) Fix each paragraph (both current wording and possible resolutions of
4134 DRs) containing invalid iterator arithmetic expressions separately.
4135 </p>
4136
4137 <p>5) References to other DRs:</p>
4138
4139 <p>
4140 See DR 225.
4141 See DR 237. The resolution could then also read "Linear in last -
4142 first".
4143 </p>
4144
4145 <p><b>Proposed resolution:</b></p>
4146
4147 <p><i>[Lillehammer: Minor issue, but real. We have a blanket statement
4148 about this in 25/11. But (a) it should be in 17, not 25; and (b) it's
4149 not quite broad enough, because there are some arithmetic expressions
4150 it doesn't cover. Bill will provide wording.]</i></p>
4151
4152
4153
4154
4155
4156
4157
4158 <hr>
4159 <h3><a name="498"></a>498. Requirements for partition() and stable_partition() too strong</h3>
4160 <p><b>Section:</b> 25.2.13 [alg.partitions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4161  <b>Submitter:</b> Sean Parent, Joe Gottman <b>Date:</b> 2005-05-04</p>
4162 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4163 <p><b>Discussion:</b></p>
4164 <p>
4165 Problem:
4166 The iterator requirements for partition() and stable_partition() [25.2.12]
4167 are listed as BidirectionalIterator, however, there are efficient algorithms
4168 for these functions that only require ForwardIterator that have been known
4169 since before the standard existed. The SGI implementation includes these (see
4170 <a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a>
4171 and
4172 <a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>).
4173 </p>
4174
4175
4176 <p><b>Proposed resolution:</b></p>
4177 <p>
4178 Change 25.2.12 from </p>
4179 <blockquote><pre>template&lt;class BidirectionalIterator, class Predicate&gt;
4180 BidirectionalIterator partition(BidirectionalIterato r first,
4181                                 BidirectionalIterator last,
4182                                 Predicate pred);
4183 </pre></blockquote>
4184 <p>to </p>
4185 <blockquote><pre>template&lt;class ForwardIterator, class Predicate&gt;
4186 ForwardIterator partition(ForwardIterator first,
4187                           ForwardIterator last,
4188                           Predicate pred);
4189 </pre></blockquote>
4190 <p>Change the complexity from </p>
4191
4192 <blockquote><p>
4193 At most (last - first)/2 swaps are done. Exactly (last - first)
4194 applications of the predicate are done.
4195 </p></blockquote>
4196
4197 <p>to </p>
4198
4199 <blockquote><p>
4200 If ForwardIterator is a bidirectional_iterator, at most (last - first)/2
4201 swaps are done; otherwise at most (last - first) swaps are done. Exactly
4202 (last - first) applications of the predicate are done.
4203 </p></blockquote>
4204
4205
4206
4207 <p><b>Rationale:</b></p>
4208 <p>
4209 Partition is a "foundation" algorithm useful in many contexts (like sorting
4210 as just one example) - my motivation for extending it to include forward
4211 iterators is slist - without this extension you can't partition an slist
4212 (without writing your own partition). Holes like this in the standard
4213 library weaken the argument for generic programming (ideally I'd be able
4214 to provide a library that would refine std::partition() to other concepts
4215 without fear of conflicting with other libraries doing the same - but
4216 that is a digression). I consider the fact that partition isn't defined
4217 to work for ForwardIterator a minor embarrassment.
4218 </p>
4219
4220 <p><i>[Mont Tremblant: Moved to Open, request motivation and use cases
4221 by next meeting. Sean provided further rationale by post-meeting
4222 mailing.]</i></p>
4223
4224
4225
4226
4227
4228
4229
4230 <hr>
4231 <h3><a name="502"></a>502. Proposition: Clarification of the interaction between a facet and an iterator</h3>
4232 <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#Open">Open</a>
4233  <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Date:</b> 2005-06-07</p>
4234 <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>
4235 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4236 <p><b>Discussion:</b></p>
4237 <p>
4238 Motivation:
4239 </p>
4240
4241 <p>
4242 This requirement seems obvious to me, it is the essence of code modularity.
4243 I have complained to Mr. Plauger that the Dinkumware library does not
4244 observe this principle but he objected that this behaviour is not covered in
4245 the standard.
4246 </p>
4247
4248
4249 <p><b>Proposed resolution:</b></p>
4250 <p>
4251 Append the following point to 22.1.1.1.1:
4252 </p>
4253
4254 <p>
4255 6. The implementation of a facet of Table 52 parametrized with an
4256 InputIterator/OutputIterator should use that iterator only as character
4257 source/sink respectively.
4258 For a *_get facet, it means that the value received depends only on the
4259 sequence of input characters and not on how they are accessed.
4260 For a *_put facet, it means that the sequence of characters output depends
4261 only on the value to be formatted and not of how the characters are stored.
4262 </p>
4263
4264 <p><i>[
4265 Berlin:  Moved to Open, Need to clean up this area to make it clear
4266 locales don't have to contain open ended sets of facets. Jack, Howard,
4267 Bill.
4268 ]</i></p>
4269
4270
4271
4272
4273
4274
4275
4276 <hr>
4277 <h3><a name="503"></a>503. more on locales</h3>
4278 <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#Open">Open</a>
4279  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2005-06-20</p>
4280 <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>
4281 <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>
4282 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4283 <p><b>Discussion:</b></p>
4284 <p>
4285 a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table
4286 51" to refer to the facet *objects* associated with a locale. And we
4287 almost certainly mean just those associated with the default or "C"
4288 locale. Otherwise, you can't switch to a locale that enforces a different
4289 mapping between narrow and wide characters, or that defines additional
4290 uppercase characters.
4291 </p>
4292
4293 <p>
4294 b) 22.2.1.5 para. 3 (codecvt) has the same issues.
4295 </p>
4296
4297 <p>
4298 c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation of
4299 a homing sequence for the basic character set, which might very well need
4300 one.
4301 </p>
4302
4303 <p>
4304 d) 22.2.1.5.2 (do_length) likewise dictates that the default mapping
4305 between wide and narrow characters be taken as one-for-one.
4306 </p>
4307
4308 <p>
4309 e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far as
4310 I can tell. The muddle is, as before, calling Table 51 a list of
4311 instantiations. But the constraint it applies seems to me to cover
4312 *all* defined uses of num_get/put, so why bother to say so?
4313 </p>
4314
4315 <p>
4316 f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiations
4317 return '.' or L'.'.) Presumably this means "as appropriate for the
4318 character type. But given the vague definition of "required" earlier,
4319 this overrules *any* change of decimal point for non "C" locales.
4320 Surely we don't want to do that.
4321 </p>
4322
4323 <p>
4324 g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiations
4325 return ',' or L','.) As above, this probably means "as appropriate for the
4326 character type. But this overrules the "C" locale, which requires *no*
4327 character ('\0') for the thousands separator. Even if we agree that we
4328 don't mean to block changes in decimal point or thousands separator,
4329 we should also eliminate this clear incompatibility with C.
4330 </p>
4331
4332 <p>
4333 h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiations
4334 return the empty string, indicating no grouping." Same considerations
4335 as for do_decimal_point.
4336 </p>
4337
4338 <p>
4339 i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table
4340 51". Same bad jargon.
4341 </p>
4342
4343 <p>
4344 j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required
4345 in Table 51". Same bad jargon.
4346 </p>
4347
4348 <p>
4349 k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous
4350 as num_get/put.
4351 </p>
4352
4353 <p>
4354 l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous
4355 as num_get/put.
4356 </p>
4357
4358 <p>
4359 m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations required
4360 in Table 51 ... return an object of type pattern initialized to
4361 {symbol, sign, none, value}." This once again *overrides* the "C"
4362 locale, as well as any other locale."
4363 </p>
4364
4365 <p>
4366 3) We constrain the use_facet calls that can be made by num_get/put,
4367 so why don't we do the same for money_get/put? Or for any of the
4368 other facets, for that matter?
4369 </p>
4370
4371 <p>
4372 4) As an almost aside, we spell out when a facet needs to use the ctype
4373 facet, but several also need to use a codecvt facet and we don't say so.
4374 </p>
4375 <p><i>[
4376 Berlin: Bill to provide wording.
4377 ]</i></p>
4378
4379
4380
4381 <p><b>Proposed resolution:</b></p>
4382 <p>
4383 </p>
4384
4385
4386
4387
4388
4389 <hr>
4390 <h3><a name="518"></a>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3>
4391 <p><b>Section:</b> 23.1.3 [unord.req], TR1 6.3.1 [tr.unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
4392  <b>Submitter:</b> Matt Austern <b>Date:</b> 2005-07-03</p>
4393 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
4394 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
4395 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
4396 <p><b>Discussion:</b></p>
4397 <p>
4398 Issue 371 deals with stability of multiset/multimap under insert and erase
4399 (i.e. do they preserve the relative order in ranges of equal elements).
4400 The same issue applies to unordered_multiset and unordered_multimap.
4401 </p>
4402 <p><i>[
4403 Moved to open (from review):  There is no resolution.
4404 ]</i></p>
4405
4406
4407 <p><i>[
4408 Toronto:  We have a resolution now.  Moved to Review.  Some concern was noted
4409 as to whether this conflicted with existing practice or not.  An additional
4410 concern was in specifying (partial) ordering for an unordered container.
4411 ]</i></p>
4412
4413
4414
4415
4416 <p><b>Proposed resolution:</b></p>
4417 <p>
4418 Wording for the proposed resolution is taken from the equivalent text for associative containers.
4419 </p>
4420
4421 <p>
4422 Change 23.1.3 [unord.req], Unordered associative containers, paragraph 6 to:
4423 </p>
4424
4425 <blockquote><p>
4426 An unordered associative container supports <i>unique</i> keys if it may
4427 contain at most one element for each key. Otherwise, it supports <i>equivalent
4428 keys</i>. <tt>unordered_set</tt> and <tt>unordered_map</tt> support
4429 unique keys. <tt>unordered_multiset</tt> and <tt>unordered_multimap</tt>
4430 support equivalent keys. In containers that support equivalent keys, elements
4431 with equivalent keys are adjacent to each other. <ins>For
4432 <tt>unordered_multiset</tt>
4433 and <tt>unordered_multimap</tt>,<tt> insert</tt> and <tt>erase</tt>
4434 preserve the relative ordering of equivalent elements.</ins>
4435 </p></blockquote>
4436
4437 <p>
4438 Change 23.1.3 [unord.req], Unordered associative containers, paragraph 8 to:
4439 </p>
4440
4441 <blockquote>
4442 <p>The elements of an unordered associative container are organized into <i>
4443 buckets</i>. Keys with the same hash code appear in the same bucket. The number
4444 of buckets is automatically increased as elements are added to an unordered
4445 associative container, so that the average number of elements per bucket is kept
4446 below a bound. Rehashing invalidates iterators, changes ordering between
4447 elements, and changes which buckets elements appear in, but does not invalidate
4448 pointers or references to elements. <ins>For <tt>unordered_multiset</tt>
4449 and <tt>unordered_multimap</tt>, rehashing
4450 preserves the relative ordering of equivalent elements.</ins></p>
4451 </blockquote>
4452
4453
4454
4455
4456
4457
4458 <hr>
4459 <h3><a name="522"></a>522. Tuple doesn't define swap</h3>
4460 <p><b>Section:</b> 20.3 [tuple], TR1 6.1 [tr.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4461  <b>Submitter:</b> Andy Koenig <b>Date:</b> 2005-07-03</p>
4462 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4463 <p><b>Discussion:</b></p>
4464 <p>
4465 Tuple doesn't define swap().  It should.
4466 </p>
4467 <p><i>[
4468 Berlin: Doug to provide wording.
4469 ]</i></p>
4470
4471 <p><i>[
4472 Batavia: Howard to provide wording.
4473 ]</i></p>
4474
4475 <p><i>[
4476 Toronto: Howard to provide wording (really this time).
4477 ]</i></p>
4478
4479
4480
4481
4482 <p><b>Proposed resolution:</b></p>
4483
4484
4485
4486
4487
4488 <hr>
4489 <h3><a name="523"></a>523. regex case-insensitive character ranges are unimplementable as specified</h3>
4490 <p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4491  <b>Submitter:</b> Eric Niebler <b>Date:</b> 2005-07-01</p>
4492 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re">issues</a> in [re].</p>
4493 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4494 <p><b>Discussion:</b></p>
4495 <p>
4496 A problem with TR1 regex is currently being discussed on the Boost
4497 developers list. It involves the handling of case-insensitive matching
4498 of character ranges such as [Z-a]. The proper behavior (according to the
4499 ECMAScript standard) is unimplementable given the current specification
4500 of the TR1 regex_traits&lt;&gt; class template. John Maddock, the author of
4501 the TR1 regex proposal, agrees there is a problem. The full discussion
4502 can be found at http://lists.boost.org/boost/2005/06/28850.php (first
4503 message copied below). We don't have any recommendations as yet.
4504 </p>
4505 <p>
4506 -- Begin original message --
4507 </p>
4508 <p>
4509 The situation of interest is described in the ECMAScript specification
4510 (ECMA-262), section 15.10.2.15:
4511 </p>
4512 <p>
4513 "Even if the pattern ignores case, the case of the two ends of a range
4514 is significant in determining which characters belong to the range.
4515 Thus, for example, the pattern /[E-F]/i matches only the letters E, F,
4516 e, and f, while the pattern /[E-f]/i matches all upper and lower-case
4517 ASCII letters as well as the symbols [, \, ], ^, _, and `."
4518 </p>
4519 <p>
4520 A more interesting case is what should happen when doing a
4521 case-insentitive match on a range such as [Z-a]. It should match z, Z,
4522 a, A and the symbols [, \, ], ^, _, and `. This is not what happens with
4523 Boost.Regex (it throws an exception from the regex constructor).
4524 </p>
4525 <p>
4526 The tough pill to swallow is that, given the specification in TR1, I
4527 don't think there is any effective way to handle this situation.
4528 According to the spec, case-insensitivity is handled with
4529 regex_traits&lt;&gt;::translate_nocase(CharT) -- two characters are equivalent
4530 if they compare equal after both are sent through the translate_nocase
4531 function. But I don't see any way of using this translation function to
4532 make character ranges case-insensitive. Consider the difficulty of
4533 detecting whether "z" is in the range [Z-a]. Applying the transformation
4534 to "z" has no effect (it is essentially std::tolower). And we're not
4535 allowed to apply the transformation to the ends of the range, because as
4536 ECMA-262 says, "the case of the two ends of a range is significant."
4537 </p>
4538 <p>
4539 So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix
4540 is to redefine translate_nocase to return a string_type containing all
4541 the characters that should compare equal to the specified character. But
4542 this function is hard to implement for Unicode, and it doesn't play nice
4543 with the existing ctype facet. What a mess!
4544 </p>
4545 <p>
4546 -- End original message --
4547 </p>
4548
4549 <p><i>[
4550 John Maddock adds:
4551 ]</i></p>
4552
4553
4554 <p>
4555 One small correction, I have since found that ICU's regex package does
4556 implement this correctly, using a similar mechanism to the current
4557 TR1.Regex.
4558 </p>
4559 <p>
4560 Given an expression [c1-c2] that is compiled as case insensitive it:
4561 </p>
4562 <p>
4563 Enumerates every character in the range c1 to c2 and converts it to it's
4564 case folded equivalent.  That case folded character is then used a key to a
4565 table of equivalence classes, and each member of the class is added to the
4566 list of possible matches supported by the character-class.  This second step
4567 isn't possible with our current traits class design, but isn't necessary if
4568 the input text is also converted to a case-folded equivalent on the fly.
4569 </p>
4570 <p>
4571 ICU applies similar brute force mechanisms to character classes such as
4572 [[:lower:]] and [[:word:]], however these are at least cached, so the impact
4573 is less noticeable in this case.
4574 </p>
4575 <p>
4576 Quick and dirty performance comparisons show that expressions such as
4577 "[X-\\x{fff0}]+" are indeed very slow to compile with ICU (about 200 times
4578 slower than a "normal" expression).  For an application that uses a lot of
4579 regexes this could have a noticeable performance impact.  ICU also has an
4580 advantage in that it knows the range of valid characters codes: code points
4581 outside that range are assumed not to require enumeration, as they can not
4582 be part of any equivalence class.  I presume that if we want the TR1.Regex
4583 to work with arbitrarily large character sets enumeration really does become
4584 impractical.
4585 </p>
4586 <p>
4587 Finally note that Unicode has:
4588 </p>
4589 <p>
4590 Three cases (upper, lower and title).
4591 One to many, and many to one case transformations.
4592 Character that have context sensitive case translations - for example an
4593 uppercase sigma has two different lowercase forms  - the form chosen depends
4594 on context(is it end of a word or not), a caseless match for an upper case
4595 sigma should match either of the lower case forms, which is why case folding
4596 is often approximated by tolower(toupper(c)).
4597 </p>
4598 <p>
4599 Probably we need some way to enumerate character equivalence classes,
4600 including digraphs (either as a result or an input), and some way to tell
4601 whether the next character pair is a valid digraph in the current locale.
4602 </p>
4603 <p>
4604 Hoping this doesn't make this even more complex that it was already,
4605 </p>
4606
4607 <p><i>[
4608 Portland:  Alisdair: Detect as invalid, throw an exception.
4609 Pete: Possible general problem with case insensitive ranges.
4610 ]</i></p>
4611
4612
4613
4614
4615 <p><b>Proposed resolution:</b></p>
4616
4617
4618
4619
4620
4621 <hr>
4622 <h3><a name="527"></a>527. tr1::bind has lost its Throws clause</h3>
4623 <p><b>Section:</b> 20.5.11.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4624  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2005-10-01</p>
4625 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4626 <p><b>Discussion:</b></p>
4627 <p>
4628 The original bind proposal gives the guarantee that tr1::bind(f, t1,
4629 ..., tN) does not throw when the copy constructors of f, t1, ..., tN
4630 don't.
4631 </p>
4632
4633 <p>
4634 This guarantee is not present in the final version of TR1.
4635 </p>
4636
4637 <p>
4638 I'm pretty certain that we never removed it on purpose. Editorial omission? :-)
4639 </p>
4640
4641 <p><i>[
4642 Berlin: not quite editorial, needs proposed wording.
4643 ]</i></p>
4644
4645 <p><i>[
4646 Batavia:  Doug to translate wording to variadic templates.
4647 ]</i></p>
4648
4649
4650 <p><i>[
4651 Toronto:  We agree but aren't quite happy with the wording.  The "t"'s no
4652 longer refer to anything.  Alan to provide improved wording.
4653 ]</i></p>
4654
4655
4656
4657
4658 <p><b>Proposed resolution:</b></p>
4659 <p>
4660 In 20.5.10.1.3 [lib.func.bind.bind] ([tr.func.bind.bind]), add a new paragraph after p2:
4661 </p>
4662 <blockquote><p>
4663 <i>Throws:</i> Nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt>
4664 throws an exception.
4665 </p></blockquote>
4666
4667 <p>
4668 Add a new paragraph after p4:
4669 </p>
4670 <blockquote><p>
4671 <i>Throws:</i> nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt>
4672 throws an exception.
4673 </p></blockquote>
4674
4675
4676
4677
4678
4679 <hr>
4680 <h3><a name="529"></a>529. The standard encourages redundant and confusing preconditions</h3>
4681 <p><b>Section:</b> 17.4.3.8 [res.on.required] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4682  <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-10-25</p>
4683 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4684 <p><b>Discussion:</b></p>
4685 <p>
4686 17.4.3.8/1 says:
4687 </p>
4688
4689 <blockquote><p>
4690 Violation of the preconditions specified in a function's
4691 Required behavior: paragraph results in undefined behavior unless the
4692 function's Throws: paragraph specifies throwing an exception when the
4693 precondition is violated.
4694 </p></blockquote>
4695
4696 <p>
4697 This implies that a precondition violation can lead to defined
4698 behavior.  That conflicts with the only reasonable definition of
4699 precondition: that a violation leads to undefined behavior.  Any other
4700 definition muddies the waters when it comes to analyzing program
4701 correctness, because precondition violations may be routinely done in
4702 correct code (e.g. you can use std::vector::at with the full
4703 expectation that you'll get an exception when your index is out of
4704 range, catch the exception, and continue).  Not only is it a bad
4705 example to set, but it encourages needless complication and redundancy
4706 in the standard.  For example:
4707 </p>
4708
4709 <blockquote><pre>  21 Strings library
4710   21.3.3 basic_string capacity
4711
4712   void resize(size_type n, charT c);
4713
4714   5 Requires: n &lt;= max_size()
4715   6 Throws: length_error if n &gt; max_size().
4716   7 Effects: Alters the length of the string designated by *this as follows:
4717 </pre></blockquote>
4718
4719 <p>
4720 The Requires clause is entirely redundant and can be dropped.  We
4721 could make that simplifying change (and many others like it) even
4722 without changing 17.4.3.8/1; the wording there just seems to encourage
4723 the redundant and error-prone Requires: clause.
4724 </p>
4725
4726 <p><i>[
4727 Batavia:  Alan and Pete to work.
4728 ]</i></p>
4729
4730
4731
4732 <p><b>Proposed resolution:</b></p>
4733 <p>
4734 1. Change 17.4.3.8/1 to read:
4735 </p>
4736
4737 <blockquote><p>
4738 Violation of the preconditions specified in a function's
4739 <i>Required behavior:</i> paragraph results in undefined behavior
4740 <del>unless the function's <i>Throws:</i> paragraph specifies throwing
4741 an exception when the precondition is violated</del>.
4742 </p></blockquote>
4743
4744 <p>
4745 2. Go through and remove redundant Requires: clauses.  Specifics to be
4746    provided by Dave A.
4747 </p>
4748
4749 <p><i>[
4750 Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution.
4751 ]</i></p>
4752
4753
4754 <p><i>[
4755 Alan provided the survey
4756 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>.
4757 ]</i></p>
4758
4759
4760
4761
4762
4763
4764
4765 <hr>
4766 <h3><a name="539"></a>539. partial_sum and adjacent_difference should mention requirements</h3>
4767 <p><b>Section:</b> 26.6.3 [partial.sum] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4768  <b>Submitter:</b> Marc Schoolderman <b>Date:</b> 2006-02-06</p>
4769 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4770 <p><b>Discussion:</b></p>
4771 <p>
4772 There are some problems in the definition of partial_sum and
4773 adjacent_difference in 26.4 [lib.numeric.ops]
4774 </p>
4775
4776 <p>
4777 Unlike <tt>accumulate</tt> and <tt>inner_product</tt>, these functions are not
4778 parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply
4779 specifies the effects clause as;
4780 </p>
4781
4782 <blockquote><p>
4783 Assigns to every element referred to by iterator <tt>i</tt> in the range
4784 <tt>[result,result + (last - first))</tt> a value correspondingly equal to
4785 </p>
4786 <blockquote><pre>((...(* first + *( first + 1)) + ...) + *( first + ( i - result )))
4787 </pre></blockquote>
4788 </blockquote>
4789
4790 <p>
4791 And similarly for BinaryOperation. Using just this definition, it seems
4792 logical to expect that:
4793 </p>
4794
4795
4796 <blockquote><pre>char i_array[4] = { 100, 100, 100, 100 };
4797 int  o_array[4];
4798
4799 std::partial_sum(i_array, i_array+4, o_array);
4800 </pre></blockquote>
4801
4802 <p>
4803 Is equivalent to
4804 </p>
4805
4806 <blockquote><pre>int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 };
4807 </pre></blockquote>
4808
4809 <p>
4810 i.e. 100, 200, 300, 400, with addition happening in the <tt>result type</tt>,
4811 <tt>int</tt>.
4812 </p>
4813
4814 <p>
4815 Yet all implementations I have tested produce 100, -56, 44, -112,
4816 because they are using an accumulator of the <tt>InputIterator</tt>'s
4817 <tt>value_type</tt>, which in this case is <tt>char</tt>, not <tt>int</tt>.
4818 </p>
4819
4820 <p>
4821 The issue becomes more noticeable when the result of the expression <tt>*i +
4822 *(i+1)</tt> or <tt>binary_op(*i, *i-1)</tt> can't be converted to the
4823 <tt>value_type</tt>. In a contrived example:
4824 </p>
4825
4826 <blockquote><pre>enum not_int { x = 1, y = 2 };
4827 ...
4828 not_int e_array[4] = { x, x, y, y };
4829 std::partial_sum(e_array, e_array+4, o_array);
4830 </pre></blockquote>
4831
4832 <p>
4833 Is it the intent that the operations happen in the <tt>input type</tt>, or in
4834 the <tt>result type</tt>?
4835 </p>
4836
4837 <p>
4838 If the intent is that operations happen in the <tt>result type</tt>, something
4839 like this should be added to the "Requires" clause of 26.4.3/4
4840 [lib.partial.sum]:
4841 </p>
4842
4843 <blockquote><p>
4844 The type of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall meet the
4845 requirements of <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt>
4846 (23.1) types.
4847 </p></blockquote>
4848
4849 <p>
4850 (As also required for <tt>T</tt> in 26.4.1 [lib.accumulate] and 26.4.2
4851 [lib.inner.product].)
4852 </p>
4853
4854 <p>
4855 The "auto initializer" feature proposed in
4856 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1894.pdf">N1894</a>
4857 is not required to
4858 implement <tt>partial_sum</tt> this way. The 'narrowing' behaviour can still be
4859 obtained by using the <tt>std::plus&lt;&gt;</tt> function object.
4860 </p>
4861
4862 <p>
4863 If the intent is that operations happen in the <tt>input type</tt>, then
4864 something like this should be added instead;
4865 </p>
4866
4867 <blockquote><p>
4868 The type of *first shall meet the requirements of
4869 <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types.
4870 The result of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall be
4871 convertible to this type.
4872 </p></blockquote>
4873
4874 <p>
4875 The 'widening' behaviour can then be obtained by writing a custom proxy
4876 iterator, which is somewhat involved.
4877 </p>
4878
4879 <p>
4880 In both cases, the semantics should probably be clarified.
4881 </p>
4882
4883 <p>
4884 26.4.4 [lib.adjacent.difference] is similarly underspecified, although
4885 all implementations seem to perform operations in the 'result' type:
4886 </p>
4887
4888 <blockquote><pre>unsigned char i_array[4] = { 4, 3, 2, 1 };
4889 int o_array[4];
4890
4891 std::adjacent_difference(i_array, i_array+4, o_array);
4892 </pre></blockquote>
4893
4894 <p>
4895 o_array is 4, -1, -1, -1 as expected, not 4, 255, 255, 255.
4896 </p>
4897
4898 <p>
4899 In any case, <tt>adjacent_difference</tt> doesn't mention the requirements on the
4900 <tt>value_type</tt>; it can be brought in line with the rest of 26.4
4901 [lib.numeric.ops] by adding the following to 26.4.4/2
4902 [lib.adjacent.difference]:
4903 </p>
4904
4905 <blockquote><p>
4906 The type of <tt>*first</tt> shall meet the requirements of
4907 <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types."
4908 </p></blockquote>
4909 <p><i>[
4910 Berlin: Giving output iterator's value_types very controversial. Suggestion of
4911 adding signatures to allow user to specify "accumulator".
4912 ]</i></p>
4913
4914
4915
4916
4917 <p><b>Proposed resolution:</b></p>
4918 <p>
4919 </p>
4920
4921
4922
4923
4924
4925 <hr>
4926 <h3><a name="546"></a>546. _Longlong and _ULonglong are integer types</h3>
4927 <p><b>Section:</b> TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4928  <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
4929 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4930 <p><b>Discussion:</b></p>
4931 <p>
4932 The TR sneaks in two new integer types, _Longlong and _Ulonglong, in [tr.c99].
4933 The rest of the TR should use that type.  I believe this affects two places.
4934 First, the random number requirements, 5.1.1/10-11, lists all of the types with
4935 which template parameters named IntType and UIntType may be instantiated.
4936 _Longlong (or "long long", assuming it is added to C++0x) should be added to the
4937 IntType list, and UIntType (again, or "unsigned long long") should be added to
4938 the UIntType list.  Second, 6.3.2 lists the types for which hash&lt;&gt; is
4939 required to be instantiable. _Longlong and _Ulonglong should be added to that
4940 list, so that people may use long long as a hash key.
4941 </p>
4942
4943
4944 <p><b>Proposed resolution:</b></p>
4945 <p>
4946 </p>
4947
4948
4949
4950
4951
4952 <hr>
4953 <h3><a name="550"></a>550. What should the return type of pow(float,int) be?</h3>
4954 <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#Open">Open</a>
4955  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-12</p>
4956 <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>
4957 <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>
4958 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4959 <p><b>Discussion:</b></p>
4960 <p>
4961 Assuming we adopt the
4962 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">C
4963 compatibility package from C99</a>  what should be the return type of the
4964 following signature be:
4965 </p>
4966 <blockquote><pre>?  pow(float, int);
4967 </pre></blockquote>
4968 <p>
4969 C++03 says that the return type should be <tt>float</tt>.
4970 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
4971 TR1</a> and C90/99 say the return type should be <tt>double</tt>.  This can put
4972 clients into a situation where C++03 provides answers that are not as high
4973 quality as C90/C99/TR1.  For example:
4974 </p>
4975 <blockquote><pre>#include &lt;math.h&gt;
4976
4977 int main()
4978 {
4979     float x = 2080703.375F;
4980     double y = pow(x, 2);
4981 }
4982 </pre></blockquote>
4983 <p>
4984 Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest:
4985 </p>
4986
4987 <blockquote><pre>y = 4329326534736.390625
4988 </pre></blockquote>
4989
4990 <p>
4991 which is exactly right.  While C++98/C++03 demands:
4992 </p>
4993
4994 <blockquote><pre>y = 4329326510080.
4995 </pre></blockquote>
4996
4997 <p>
4998 which is only approximately right.
4999 </p>
5000
5001 <p>
5002 I recommend that C++0X adopt the mixed mode arithmetic already adopted by
5003 Fortran, C and TR1 and make the return type of <tt>pow(float,int)</tt> be
5004 <tt>double</tt>.
5005 </p>
5006
5007 <p><i>[
5008 Kona (2007): Other functions that are affected by this issue include
5009 <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt>. We also believe that there is a typo in
5010 26.7/10: <tt>float nexttoward(float, long double);</tt> [sic] should be <tt>float
5011 nexttoward(float, float);</tt> Proposed Disposition: Review (the proposed
5012 resolution appears above, rather than below, the heading "Proposed
5013 resolution")
5014 ]</i></p>
5015
5016
5017 <p><i>[
5018 </i></p><p>
5019 <i>Howard, post Kona:
5020 </i></p>
5021 <blockquote>
5022 <p>
5023 <i>Unfortunately I strongly disagree with a part of the resolution
5024 from Kona.  I am moving from New to Open instead of to Review because I do not believe
5025 we have consensus on the intent of the resolution.
5026 </i></p>
5027 <p>
5028 <i>This issue does not include <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt> because
5029 the second integral parameter in each of these signatures (from C99) is <b>not</b> a
5030 <i>generic parameter</i> according to C99 7.22p2.  The corresponding C++ overloads are
5031 intended (as far as I know) to correspond directly to C99's definition of <i>generic parameter</i>.
5032 </i></p>
5033 <p>
5034 <i>For similar reasons, I do not believe that the second <tt>long double</tt> parameter of
5035 <tt>nexttoward</tt>, nor the return type of this function, is in error.  I believe the
5036 correct signature is:
5037 </i></p>
5038 <blockquote>
5039 <pre><i>float nexttoward(float, long double);
5040 </i></pre>
5041 </blockquote>
5042 <p>
5043 <i>which is what both the C++0X working paper and C99 state (as far as I currently understand).
5044 </i></p>
5045 <p>
5046 <i>This is really <b>only</b> about <tt>pow(float, int)</tt>.  And this is because C++98 took one
5047 route (with <tt>pow</tt> only) and C99 took another (with many math functions in <tt>&lt;tgmath.h&gt;</tt>.
5048 The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99.
5049 </i></p>
5050 </blockquote>
5051 <i>]</i>
5052
5053
5054
5055
5056 <p><b>Proposed resolution:</b></p>
5057 <p>
5058 Change 26.7 [c.math]
5059 </p>
5060
5061 <blockquote><pre>float pow(float, float);
5062 <del>float</del> <ins>double</ins> pow(float, int);
5063 </pre></blockquote>
5064
5065
5066
5067
5068
5069
5070 <hr>
5071 <h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3>
5072 <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#Open">Open</a>
5073  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-05</p>
5074 <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>
5075 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5076 <p><b>Discussion:</b></p>
5077 <p>
5078 In 25, p8 we allow BinaryPredicates to return a type that's convertible
5079 to bool but need not actually be bool. That allows predicates to return
5080 things like proxies and requires that implementations be careful about
5081 what kinds of expressions they use the result of the predicate in (e.g.,
5082 the expression in if (!pred(a, b)) need not be well-formed since the
5083 negation operator may be inaccessible or return a type that's not
5084 convertible to bool).
5085 </p>
5086 <p>
5087 Here's the text for reference:
5088 </p>
5089 <blockquote><p>
5090   ...if an algorithm takes BinaryPredicate binary_pred as its argument
5091  and first1 and first2 as its iterator arguments, it should work
5092  correctly in the construct if (binary_pred(*first1, first2)){...}.
5093 </p></blockquote>
5094
5095 <p>
5096 In 25.3, p2 we require that the Compare function object return true
5097 of false, which would seem to preclude such proxies. The relevant text
5098 is here:
5099 </p>
5100 <blockquote><p>
5101   Compare is used as a function object which returns true if the first
5102   argument is less than the second, and false otherwise...
5103 </p></blockquote>
5104
5105
5106 <p><b>Proposed resolution:</b></p>
5107 <p>
5108 I think we could fix this by rewording 25.3, p2 to read somthing like:
5109 </p>
5110 <blockquote><p>
5111 -2- <tt>Compare</tt> is <del>used as a function object which returns
5112 <tt>true</tt> if the first argument</del> <ins>a <tt>BinaryPredicate</tt>. The
5113 return value of the function call operator applied to an object of type
5114 <tt>Compare</tt>, when converted to type <tt>bool</tt>, yields <tt>true</tt>
5115 if the first argument of the call</ins> is less than the second, and
5116 <tt>false</tt> otherwise. <tt>Compare <i>comp</i></tt> is used throughout for
5117 algorithms assuming an ordering relation. It is assumed that <tt><i>comp</i></tt>
5118 will not apply any non-constant function through the dereferenced iterator.
5119 </p></blockquote>
5120
5121
5122 <p><i>[
5123 Portland:  Jack to define "convertible to bool" such that short circuiting isn't
5124 destroyed.
5125 ]</i></p>
5126
5127
5128
5129
5130
5131 <hr>
5132 <h3><a name="557"></a>557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)</h3>
5133 <p><b>Section:</b> 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5134  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-06</p>
5135 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint">issues</a> in [cstdint].</p>
5136 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5137 <p><b>Discussion:</b></p>
5138 <p>
5139 I'm seeing a problem with such overloads: when, _Longlong == intmax_t ==
5140 long long we end up, essentially, with the same arguments and different
5141 return types (lldiv_t and imaxdiv_t, respectively). Similar issue with
5142 abs(_Longlong) and abs(intmax_t), of course.
5143 </p>
5144 <p>
5145 Comparing sections 8.25 and 8.11, I see an important difference,
5146 however: 8.25.3 and 8.25.4 carefully describe div and abs for _Longlong
5147 types (rightfully, because not moved over directly from C99), whereas
5148 there is no equivalent in 8.11: the abs and div overloads for intmax_t
5149 types appear only in the synopsis and are not described anywhere, in
5150 particular no mention in 8.11.2 (at variance with 8.25.2).
5151 </p>
5152 <p>
5153 I'm wondering whether we really, really, want div and abs for intmax_t...
5154 </p>
5155
5156
5157
5158 <p><b>Proposed resolution:</b></p>
5159
5160
5161
5162 <p><i>[
5163 Portland: no consensus.
5164 ]</i></p>
5165
5166
5167 <p><b>Rationale:</b></p>
5168 <p><i>[
5169 Batavia, Bill: The <tt>&lt;cstdint&gt;</tt> synopsis in TR1 8.11.1 [tr.c99.cinttypes.syn] contains:
5170 ]</i></p>
5171
5172 <blockquote><pre>intmax_t imaxabs(intmax_t i);
5173 intmax_t abs(intmax_t i);
5174
5175 imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom);
5176 imaxdiv_t div(intmax_t numer, intmax_t denom);
5177 </pre></blockquote>
5178
5179 <p><i>[
5180 and in TR1 8.11.2 [tr.c99.cinttypes.def]:
5181 ]</i></p>
5182
5183
5184 <blockquote><p>
5185 The header defines all functions, types, and macros the same as C99
5186 subclause 7.8.
5187 </p></blockquote>
5188
5189 <p><i>[
5190 This is as much definition as we give for most other C99 functions,
5191 so nothing need change. We might, however, choose to add the footnote:
5192 ]</i></p>
5193
5194
5195 <blockquote><p>
5196 [<i>Note:</i> These overloads for <tt>abs</tt> and <tt>div</tt> may well be equivalent to
5197 those that take <tt>long long</tt> arguments. If so, the implementation is
5198 responsible for avoiding conflicting declarations. -- <i>end note</i>]
5199 </p></blockquote>
5200
5201
5202
5203
5204
5205
5206 <hr>
5207 <h3><a name="561"></a>561. inserter overly generic</h3>
5208 <p><b>Section:</b> 24.4.2.6.5 [inserter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
5209  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-02-21</p>
5210 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
5211 <p><b>Discussion:</b></p>
5212 <p>
5213 The declaration of <tt>std::inserter</tt> is:
5214 </p>
5215
5216 <blockquote><pre>template &lt;class Container, class Iterator&gt;
5217 insert_iterator&lt;Container&gt;
5218 inserter(Container&amp; x, Iterator i);
5219 </pre></blockquote>
5220
5221 <p>
5222 The template parameter <tt>Iterator</tt> in this function is completely unrelated
5223 to the template parameter <tt>Container</tt> when it doesn't need to be.  This
5224 causes the code to be overly generic.  That is, any type at all can be deduced
5225 as <tt>Iterator</tt>, whether or not it makes sense.  Now the same is true of
5226 <tt>Container</tt>.  However, for every free (unconstrained) template parameter
5227 one has in a signature, the opportunity for a mistaken binding grows geometrically.
5228 </p>
5229
5230 <p>
5231 It would be much better if <tt>inserter</tt> had the following signature instead:
5232 </p>
5233
5234 <blockquote><pre>template &lt;class Container&gt;
5235 insert_iterator&lt;Container&gt;
5236 inserter(Container&amp; x, typename Container::iterator i);
5237 </pre></blockquote>
5238
5239 <p>
5240 Now there is only one free template parameter.  And the second argument to
5241 <tt>inserter</tt> must be implicitly convertible to the container's iterator,
5242 else the call will not be a viable overload (allowing other functions in the
5243 overload set to take precedence).  Furthermore, the first parameter must have a
5244 nested type named <tt>iterator</tt>, or again the binding to <tt>std::inserter</tt>
5245 is not viable.  Contrast this with the current situation
5246 where any type can bind to <tt>Container</tt> or <tt>Iterator</tt> and those
5247 types need not be anything closely related to containers or iterators.
5248 </p>
5249
5250 <p>
5251 This can adversely impact well written code.  Consider:
5252 </p>
5253
5254 <blockquote><pre>#include &lt;iterator&gt;
5255 #include &lt;string&gt;
5256
5257 namespace my
5258 {
5259
5260 template &lt;class String&gt;
5261 struct my_type {};
5262
5263 struct my_container
5264 {
5265 template &lt;class String&gt;
5266 void push_back(const my_type&lt;String&gt;&amp;);
5267 };
5268
5269 template &lt;class String&gt;
5270 void inserter(const my_type&lt;String&gt;&amp; m, my_container&amp; c) {c.push_back(m);}
5271
5272 }  // my
5273
5274 int main()
5275 {
5276     my::my_container c;
5277     my::my_type&lt;std::string&gt; m;
5278     inserter(m, c);
5279 }
5280 </pre></blockquote>
5281
5282 <p>
5283 Today this code fails because the call to <tt>inserter</tt> binds to
5284 <tt>std::inserter</tt> instead of to <tt>my::inserter</tt>.  However with the
5285 proposed change <tt>std::inserter</tt> will no longer be a viable function which
5286 leaves only <tt>my::inserter</tt> in the overload resolution set.  Everything
5287 works as the client intends.
5288 </p>
5289
5290 <p>
5291 To make matters a little more insidious, the above example works today if you
5292 simply change the first argument to an rvalue:
5293 </p>
5294
5295 <blockquote><pre>    inserter(my::my_type(), c);
5296 </pre></blockquote>
5297
5298 <p>
5299 It will also work if instantiated with some string type other than
5300 <tt>std::string</tt> (or any other <tt>std</tt> type).  It will also work if
5301 <tt>&lt;iterator&gt;</tt> happens to not get included.
5302 </p>
5303
5304 <p>
5305 And it will fail again for such inocuous reaons as <tt>my_type</tt> or
5306 <tt>my_container</tt> privately deriving from any <tt>std</tt> type.
5307 </p>
5308
5309 <p>
5310 It seems unfortunate that such simple changes in the client's code can result
5311 in such radically differing behavior.
5312 </p>
5313
5314
5315
5316 <p><b>Proposed resolution:</b></p>
5317 <p>
5318 Change 24.2:
5319 </p>
5320
5321 <blockquote><p>
5322 <b>24.2 Header</b> <tt>&lt;iterator&gt;</tt> <b>synopsis</b>
5323 </p>
5324 <blockquote><pre>...
5325 template &lt;class Container<del>, class Iterator</del>&gt;
5326    insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Iterator</del> <ins>typename Container::iterator</ins> i);
5327 ...
5328 </pre></blockquote>
5329 </blockquote>
5330
5331 <p>
5332 Change 24.4.2.5:
5333 </p>
5334
5335 <blockquote><p>
5336 <b>24.4.2.5 Class template</b> <tt>insert_iterator</tt></p>
5337 <blockquote><pre>...
5338 template &lt;class Container<del>, class Iterator</del>&gt;
5339    insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Iterator</del> <ins>typename Container::iterator</ins> i);
5340 ...
5341 </pre></blockquote>
5342 </blockquote>
5343
5344 <p>
5345 Change 24.4.2.6.5:
5346 </p>
5347
5348 <blockquote>
5349 <p>
5350 <b>24.4.2.6.5</b> <tt>inserter</tt>
5351 </p>
5352 <pre>template &lt;class Container<del>, class Inserter</del>&gt;
5353    insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Inserter</del> <ins>typename Container::iterator</ins> i);
5354 </pre>
5355 <blockquote><p>
5356 -1- <i>Returns:</i> <tt>insert_iterator&lt;Container&gt;(x,<del>typename Container::iterator(</del>i<del>)</del>)</tt>.
5357 </p></blockquote>
5358 </blockquote>
5359
5360
5361
5362 <p><i>[
5363 Kona (2007): This issue will probably be addressed as a part of the
5364 concepts overhaul of the library anyway, but the proposed resolution is
5365 correct in the absence of concepts. Proposed Disposition: Ready
5366 ]</i></p>
5367
5368
5369
5370
5371
5372 <hr>
5373 <h3><a name="562"></a>562. stringbuf ctor inefficient</h3>
5374 <p><b>Section:</b> 27.7 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
5375  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
5376 <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>
5377 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
5378 <p><b>Discussion:</b></p>
5379         <p>
5380
5381 For  better efficiency,  the requirement  on the  stringbuf  ctor that
5382 takes  a  string  argument  should  be  loosened  up  to  let  it  set
5383 <code>epptr()</code>  beyond  just   one  past  the  last  initialized
5384 character  just like  <code>overflow()</code> has  been changed  to be
5385 allowed  to  do   (see  issue  432).  That  way   the  first  call  to
5386 <code>sputc()</code> on  an object won't  necessarily cause a  call to
5387 <code>overflow</code>. The corresponding change  should be made to the
5388 string overload of the <code>str()</code> member function.
5389
5390         </p>
5391
5392
5393 <p><b>Proposed resolution:</b></p>
5394         <p>
5395
5396 Change 27.7.1.1, p3 of the Working Draft, N1804, as follows:
5397
5398         </p>
5399
5400 <blockquote><pre>explicit basic_stringbuf(const basic_string&lt;charT,traits,Allocator&gt;&amp; <i>s<del>tr</del></i>,
5401                ios_base::openmode <i>which</i> = ios_base::in | ios_base::out);
5402 </pre>
5403
5404 <p>
5405 -3- <i>Effects:</i>  Constructs an object of class <tt>basic_stringbuf</tt>,
5406 initializing the base class with <tt>basic_streambuf()</tt>
5407 (27.5.2.1), and initializing <tt><i>mode</i></tt> with <tt><i>which</i></tt>.
5408 Then <ins>calls <tt>str(<i>s</i>)</tt>.</ins> <del>copies the content of
5409 <i>str</i> into the <tt>basic_stringbuf</tt> underlying character
5410 sequence. If <tt><i>which</i> &amp; ios_base::out</tt> is true, initializes the
5411 output sequence such that <tt>pbase()</tt> points to the first underlying
5412 character, <tt>epptr()</tt> points one past the last underlying character, and
5413 <tt>pptr()</tt> is equal to <tt>epptr()</tt> if <tt><i>which</i> &amp; ios_base::ate</tt>
5414 is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If
5415 <tt>which &amp; ios_base::in</tt> is true, initializes the input sequence such
5416 that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying
5417 character and <tt>egptr()</tt> points one past the last underlying character.</del>
5418 </p>
5419 </blockquote>
5420
5421         <p>
5422
5423 Change the Effects clause of the <code>str()</code> in 27.7.1.2, p2 to
5424 read:
5425
5426         </p>
5427 <blockquote>
5428 <p>
5429 -2- <i>Effects:</i> Copies the content<ins>s</ins> of <tt><i>s</i></tt> into the
5430 <tt>basic_stringbuf</tt> underlying character sequence <ins>and
5431 initializes the input and output sequences according to <tt><i>mode</i></tt></ins>.
5432 <del>If
5433 <tt><i>mode</i> &amp; ios_base::out</tt> is true, initializes the output
5434 sequence such that <tt>pbase()</tt> points to the first underlying character,
5435 <tt>epptr()</tt> points one past the last underlying character, and <tt>pptr()</tt>
5436 is equal to <tt>epptr()</tt> if <tt><i>mode</i> &amp; ios_base::in</tt>
5437 is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If
5438 <tt>mode &amp; ios_base::in</tt> is true, initializes the input sequence
5439 such that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying
5440 character and <tt>egptr()</tt> points one past the last underlying character.</del>
5441 </p>
5442
5443         <p>
5444
5445 <ins>-3- <i>Postconditions:</i>  If  <code>mode  &amp; ios_base::out</code>  is  true,
5446 <code>pbase()</code>  points  to the  first  underlying character  and
5447 <code>(epptr() &gt;= pbase() + s.size())</code> holds; in addition, if
5448 <code>mode &amp; ios_base::in</code> is true, <code>(pptr() == pbase()
5449 + s.data())</code>  holds, otherwise <code>(pptr()  == pbase())</code>
5450 is   true.    If  <code>mode   &amp;   ios_base::in</code>  is   true,
5451 <code>eback()</code>  points to  the first  underlying  character, and
5452 <code>(gptr()  ==  eback())</code>  and  <code>(egptr() ==  eback()  +
5453 s.size())</code> hold.</ins>
5454
5455         </p>
5456 </blockquote>
5457
5458
5459 <p><i>[
5460 Kona (2007) Moved to Ready.
5461 ]</i></p>
5462
5463
5464
5465
5466
5467 <hr>
5468 <h3><a name="563"></a>563. stringbuf seeking from end</h3>
5469 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
5470  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
5471 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
5472 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
5473 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
5474 <p><b>Discussion:</b></p>
5475 <p>
5476 According to  Table 92  (unchanged by issue  432), when  <code>(way ==
5477 end)</code> the  <code>newoff</code> value in out mode  is computed as
5478 the difference between <code>epptr()</code> and <code>pbase()</code>.
5479 </p>
5480         <p>
5481
5482 This value  isn't meaningful unless the  value of <code>epptr()</code>
5483 can be  precisely controlled by a  program.  That used  to be possible
5484 until  we accepted the  resolution of  issue 432,  but since  then the
5485 requirements on <code>overflow()</code> have  been relaxed to allow it
5486 to  make  more than  1  write  position  available (i.e.,  by  setting
5487 <code>epptr()</code>     to     some     unspecified    value     past
5488 <code>pptr()</code>).      So    after     the    first     call    to
5489 <code>overflow()</code>  positioning the  output sequence  relative to
5490 end will have unspecified results.
5491
5492         </p>
5493         <p>
5494
5495 In  addition,  in <code>in|out</code>  mode,  since <code>(egptr()  ==
5496 epptr())</code> need not hold, there are two different possible values
5497 for   <code>newoff</code>:    <code>epptr()   -   pbase()</code>   and
5498 <code>egptr() - eback()</code>.
5499
5500         </p>
5501
5502
5503 <p><b>Proposed resolution:</b></p>
5504         <p>
5505
5506 Change the <code>newoff</code>  column in the last row  of Table 94 to
5507 read:
5508
5509         </p>
5510 <blockquote><p>
5511
5512 the <del>end</del> <ins>high mark</ins> pointer minus the beginning
5513 pointer (<code><del>xend</del> <ins>high_mark</ins> - xbeg</code>).
5514
5515 </p></blockquote>
5516
5517
5518 <p><i>[
5519 Kona (2007) Moved to Ready.
5520 ]</i></p>
5521
5522
5523
5524
5525
5526 <hr>
5527 <h3><a name="564"></a>564. stringbuf seekpos underspecified</h3>
5528 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5529  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
5530 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
5531 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
5532 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5533 <p><b>Discussion:</b></p>
5534 <p>
5535 The   effects  of  the   <code>seekpos()</code>  member   function  of
5536 <code>basic_stringbuf</code>  simply say  that the  function positions
5537 the  input and/or  output  sequences  but fail  to  spell out  exactly
5538 how. This is in contrast  to the detail in which <code>seekoff()</code>
5539 is described.
5540 </p>
5541
5542
5543 <p><b>Proposed resolution:</b></p>
5544         <p>
5545
5546 Change 27.7.1.3, p13 to read:
5547
5548         </p>
5549 <blockquote>
5550 <p>
5551 -13- <i>Effects:</i> <ins>Same as <tt>seekoff(off_type(<i>sp</i>), ios_base::beg,
5552 <i>which</i>)</tt>.</ins> <del>Alters the stream position within the controlled sequences,
5553 if possible, to correspond to the stream position stored in <tt><i>sp</i></tt>
5554 (as described below).</del>
5555 </p>
5556 <ul>
5557 <li><del>If <tt>(<i>which</i> &amp; ios_base::in) != 0</tt>, positions the input sequence.</del></li>
5558 <li><del>If <tt>(<i>which</i> &amp; ios_base::out) != 0</tt>, positions the output sequence.</del></li>
5559 <li><del>If <tt><i>sp</i></tt> is an invalid stream position, or if the function
5560 positions neither sequence, the positioning operation fails. If <tt><i>sp</i></tt>
5561 has not been obtained by a previous successful call to one of the positioning
5562 functions (<tt>seekoff</tt>, <tt>seekpos</tt>, <tt>tellg</tt>, <tt>tellp</tt>)
5563 the effect is undefined.</del></li>
5564 </ul>
5565 </blockquote>
5566
5567
5568 <p><i>[
5569 Kona (2007): A <tt>pos_type</tt> is a position in a stream by
5570 definition, so there is no ambiguity as to what it means. Proposed
5571 Disposition: NAD
5572 ]</i></p>
5573
5574
5575 <p><i>[
5576 Post-Kona Martin adds:
5577 I'm afraid I disagree
5578 with the Kona '07 rationale for marking it NAD. The only text
5579 that describes precisely what it means to position the input
5580 or output sequence is in <tt>seekoff()</tt>. The <tt>seekpos()</tt> Effects
5581 clause is inadequate in comparison and the proposed resolution
5582 plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>.
5583 ]</i></p>
5584
5585
5586
5587
5588
5589 <hr>
5590 <h3><a name="565"></a>565. xsputn inefficient</h3>
5591 <p><b>Section:</b> 27.5.2.4.5 [streambuf.virt.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5592  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
5593 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5594 <p><b>Discussion:</b></p>
5595         <p>
5596
5597 <tt>streambuf::xsputn()</tt>  is  specified  to  have  the  effect  of
5598 "writing up to  <tt>n</tt> characters to the output  sequence as if by
5599 repeated calls to <tt>sputc(c)</tt>."
5600
5601         </p>
5602         <p>
5603
5604 Since  <tt>sputc()</tt> is required  to call  <tt>overflow()</tt> when
5605 <tt>(pptr()    ==   epptr())</tt>    is   true,    strictly   speaking
5606 <tt>xsputn()</tt>  should do  the same.   However, doing  so  would be
5607 suboptimal in  some interesting cases,  such as in unbuffered  mode or
5608 when the buffer is <tt>basic_stringbuf</tt>.
5609
5610         </p>
5611         <p>
5612
5613 Assuming  calling <tt>overflow()</tt>  is  not really  intended to  be
5614 required  and the  wording is  simply  meant to  describe the  general
5615 effect of appending to the end  of the sequence it would be worthwhile
5616 to  mention in  <tt>xsputn()</tt> that  the function  is  not actually
5617 required to cause a call to <tt>overflow()</tt>.
5618
5619         </p>
5620
5621
5622 <p><b>Proposed resolution:</b></p>
5623         <p>
5624
5625 Add the following sentence  to the <tt>xsputn()</tt> Effects clause in
5626 27.5.2.4.5, p1 (N1804):
5627
5628         </p>
5629         <blockquote>
5630             <p>
5631 -1- <i>Effects:</i> Writes up to <tt><i>n</i></tt> characters to the output
5632 sequence as if by repeated calls to <tt>sputc(<i>c</i>)</tt>. The characters
5633 written are obtained from successive elements of the array whose first element
5634 is designated by <tt><i>s</i></tt>. Writing stops when either <tt><i>n</i></tt>
5635 characters have been written or a call to <tt>sputc(<i>c</i>)</tt> would return
5636 <tt>traits::eof()</tt>. <ins>It is  uspecified whether the function  calls
5637 <tt>overflow()</tt> when <tt>(pptr() ==  epptr())</tt> becomes true or whether
5638 it achieves the same effects by other means.</ins>
5639             </p>
5640         </blockquote>
5641         <p>
5642
5643 In addition,  I suggest to  add a footnote  to this function  with the
5644 same text as Footnote 292 to  make it extra clear that derived classes
5645 are permitted to override <tt>xsputn()</tt> for efficiency.
5646
5647         </p>
5648
5649
5650 <p><i>[
5651 Kona (2007): We want to permit a <tt>streambuf</tt> that streams output directly
5652 to a device without making calls to <tt>sputc</tt> or <tt>overflow</tt>. We believe that
5653 has always been the intention of the committee. We believe that the
5654 proposed wording doesn't accomplish that. Proposed Disposition: Open
5655 ]</i></p>
5656
5657
5658
5659
5660
5661 <hr>
5662 <h3><a name="567"></a>567. streambuf inserter and extractor should be unformatted</h3>
5663 <p><b>Section:</b> 27.6 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
5664  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-25</p>
5665 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iostream.format">active issues</a> in [iostream.format].</p>
5666 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p>
5667 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
5668 <p><b>Discussion:</b></p>
5669         <p>
5670
5671 Issue  60 explicitly made  the extractor  and inserter  operators that
5672 take a  <tt>basic_streambuf*</tt> argument formatted  input and output
5673 functions,  respectively.  I  believe that's  wrong, certainly  in the
5674 case of  the extractor, since formatted functions  begin by extracting
5675 and  discarding  whitespace.  The  extractor  should  not discard  any
5676 characters.
5677
5678         </p>
5679
5680
5681 <p><b>Proposed resolution:</b></p>
5682         <p>
5683
5684 I propose to  change each operator to behave  as unformatted input and
5685 output function,  respectively. The changes below are  relative to the
5686 working draft document number N1804.
5687
5688         </p>
5689         <p>
5690
5691 Specifically, change 27.6.1.2.3, p14 as follows:
5692
5693         </p>
5694
5695             <blockquote>
5696         <p>
5697
5698 <i>Effects</i>:  Behaves as  a<ins>n un</ins>formatted  input function
5699 (as   described   in   <del>27.6.1.2.1</del><ins>27.6.1.3,   paragraph
5700 1</ins>).
5701
5702         </p>
5703             </blockquote>
5704         <p>
5705
5706 And change 27.6.2.5.3, p7 as follows:
5707
5708         </p>
5709
5710             <blockquote>
5711         <p>
5712
5713 <i>Effects</i>: Behaves  as a<ins>n un</ins>formatted  output function
5714 (as   described   in   <del>27.6.2.5.1</del><ins>27.6.2.6,   paragraph
5715 1</ins>).
5716
5717         </p>
5718             </blockquote>
5719
5720
5721 <p><i>[
5722 Kona (2007): Proposed Disposition: Ready
5723 ]</i></p>
5724
5725
5726
5727
5728
5729 <hr>
5730 <h3><a name="568"></a>568. log2 overloads missing</h3>
5731 <p><b>Section:</b> TR1 8.16.4 [tr.c99.cmath.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
5732  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-03-07</p>
5733 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
5734 <p><b>Discussion:</b></p>
5735 <p>
5736 <tt>log2</tt> is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1.
5737 </p>
5738
5739 <p>
5740 Hinnant:  This is a TR1 issue only.  It is fixed in the current (N2135) WD.
5741 </p>
5742
5743
5744 <p><b>Proposed resolution:</b></p>
5745 <p>
5746 Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
5747 </p>
5748
5749
5750
5751
5752
5753 <hr>
5754 <h3><a name="570"></a>570. Request adding additional explicit specializations of char_traits</h3>
5755 <p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5756  <b>Submitter:</b> Jack Reeves <b>Date:</b> 2006-04-06</p>
5757 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5758 <p><b>Discussion:</b></p>
5759 <p>
5760 Currently, the Standard Library specifies only a declaration for template class
5761 char_traits&lt;&gt; and requires the implementation provide two explicit
5762 specializations: char_traits&lt;char&gt; and char_traits&lt;wchar_t&gt;. I feel the Standard
5763 should require explicit specializations for all built-in character types, i.e.
5764 char, wchar_t, unsigned char, and signed char.
5765 </p>
5766 <p>
5767 I have put together a paper
5768 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>)
5769 that describes this in more detail and
5770 includes all the necessary wording.
5771 </p>
5772 <p><i>[
5773 Portland: Jack will rewrite
5774 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>
5775 to propose a primary template that will work with other integral types.
5776 ]</i></p>
5777
5778 <p><i>[
5779 Toronto: issue has grown with addition of <tt>char16_t</tt> and <tt>char32_t</tt>.
5780 ]</i></p>
5781
5782
5783
5784 <p><b>Proposed resolution:</b></p>
5785
5786
5787
5788
5789
5790 <hr>
5791 <h3><a name="573"></a>573. C++0x file positioning should handle modern file sizes</h3>
5792 <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#Open">Open</a>
5793  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-12</p>
5794 <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>
5795 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5796 <p><b>Discussion:</b></p>
5797 <p>
5798 There are two deficiencies related to file sizes:
5799 </p>
5800 <ol>
5801 <li>It doesn't appear that the Standard Library is specified in
5802       a way that handles modern file sizes, which are often too
5803       large to be represented by an unsigned long.</li>
5804
5805 <li>The std::fpos class does not currently have the ability to
5806       set/get file positions.</li>
5807 </ol>
5808 <p>
5809 The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by:
5810 </p>
5811 <ol type="A">
5812 <li>Defining fpos_t be long long, which is large enough to
5813       represent any file position likely in the foreseeable future.</li>
5814
5815 <li>Adding member functions to class fpos. For example,
5816 <blockquote><pre>fpos_t seekpos() const;
5817 </pre></blockquote>
5818 </li>
5819 </ol>
5820 <p>
5821 Because there are so many types relating to file positions and offsets (fpos_t,
5822 fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and
5823 perhaps more), it is difficult to know if the Dinkumware extensions are
5824 sufficient. But they seem a useful starting place for discussions, and they do
5825 represent existing practice.
5826 </p>
5827
5828 <p><i>[
5829 Kona (2007): We need a paper. It would be nice if someone proposed
5830 clarifications to the definitions of <tt>pos_type</tt> and <tt>off_type</tt>. Currently
5831 these definitions are horrible. Proposed Disposition: Open
5832 ]</i></p>
5833
5834
5835
5836 <p><b>Proposed resolution:</b></p>
5837 <p>
5838 </p>
5839
5840
5841
5842
5843
5844 <hr>
5845 <h3><a name="574"></a>574. DR 369 Contradicts Text</h3>
5846 <p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
5847  <b>Submitter:</b> Pete Becker <b>Date:</b> 2006-04-18</p>
5848 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
5849 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
5850 <p><b>Discussion:</b></p>
5851 <p>
5852 lib.iostream.objects requires that the standard stream objects are never
5853 destroyed, and it requires that they be destroyed.
5854 </p>
5855 <p>
5856 DR 369 adds words to say that we really mean for ios_base::Init objects to force
5857 construction of standard stream objects. It ends, though, with the phrase "these
5858 stream objects shall be destroyed after the destruction of dynamically ...".
5859 However, the rule for destruction is stated in the standard: "The objects are
5860 not destroyed during program execution."
5861 </p>
5862
5863
5864 <p><b>Proposed resolution:</b></p>
5865 <p>
5866 Change 27.3 [iostream.objects]/1:
5867 </p>
5868
5869 <blockquote>
5870 <p>
5871 -2- The objects are constructed and the associations are established at
5872 some time prior to or during the first time an object of class
5873 <tt>ios_base::Init</tt> is constructed, and in any case before the body of main
5874 begins execution.<sup>290)</sup> The objects are not destroyed during program
5875 execution.<sup>291)</sup> If a translation unit includes <tt>&lt;iostream&amp;t;</tt> or explicitly
5876 constructs an <tt>ios_base::Init</tt> object, these stream objects shall be
5877 constructed before dynamic initialization of non-local objects defined
5878 later in that translation unit<del>, and these stream objects shall be
5879 destroyed after the destruction of dynamically initialized non-local
5880 objects defined later in that translation unit</del>.
5881 </p>
5882 </blockquote>
5883
5884
5885 <p><i>[
5886 Kona (2007): From 27.3 [iostream.objects]/2, strike the words "...and these stream objects
5887 shall be destroyed after the destruction of dynamically initialized
5888 non-local objects defined later in that translation unit." Proposed
5889 Disposition: Review
5890 ]</i></p>
5891
5892
5893
5894
5895
5896 <hr>
5897 <h3><a name="579"></a>579. erase(iterator) for unordered containers should not return an iterator</h3>
5898 <p><b>Section:</b> 23.1.3 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5899  <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2006-06-13</p>
5900 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
5901 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
5902 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5903 <p><b>Discussion:</b></p>
5904 <p>
5905 See
5906 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
5907 for full discussion.
5908 </p>
5909
5910
5911 <p><b>Proposed resolution:</b></p>
5912 <p>
5913 Option 1:
5914 </p>
5915
5916 <p>
5917 The problem can be eliminated by omitting the requirement that <tt>a.erase(q)</tt> return an
5918 iterator. This is, however, in contrast with the equivalent requirements for other
5919 standard containers.
5920 </p>
5921
5922 <p>
5923 Option 2:
5924 </p>
5925
5926 <p>
5927 <tt>a.erase(q)</tt> can be made to compute the next iterator only when explicitly requested:
5928 the technique consists in returning a proxy object implicitly convertible to <tt>iterator</tt>, so
5929 that
5930 </p>
5931
5932 <blockquote><pre>iterator q1=a.erase(q);
5933 </pre></blockquote>
5934
5935 <p>
5936 works as expected, while
5937 </p>
5938
5939 <blockquote><pre>a.erase(q);
5940 </pre></blockquote>
5941
5942 <p>
5943 does not ever invoke the conversion-to-iterator operator, thus avoiding the associated
5944 computation. To allow this technique, some sections of TR1 along the line "return value
5945 is an iterator..." should be changed to "return value is an unspecified object implicitly
5946 convertible to an iterator..." Although this trick is expected to work transparently, it can
5947 have some collateral effects when the expression <tt>a.erase(q)</tt> is used inside generic
5948 code.
5949 </p>
5950
5951
5952
5953 <p><b>Rationale:</b></p>
5954 <p>
5955 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
5956 was discussed in Portland and the consensus was that there appears to be
5957 no need for either change proposed in the paper.  The consensus opinion
5958 was that since the iterator could serve as its own proxy, there appears
5959 to be no need for the change. In general, "converts to" is undesirable
5960 because it interferes with template matching.
5961 </p>
5962
5963 <p>
5964 Post Toronto:  There does not at this time appear to be consensus with the Portland consensus.
5965 </p>
5966
5967
5968
5969
5970
5971 <hr>
5972 <h3><a name="580"></a>580. unused allocator members</h3>
5973 <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#Open">Open</a>
5974  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
5975 <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>
5976 <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>
5977 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5978 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a></p>
5979 <p><b>Discussion:</b></p>
5980         <p>
5981
5982 C++ Standard Library  templates that take an allocator  as an argument
5983 are    required    to    call    the    <code>allocate()</code>    and
5984 <code>deallocate()</code>  members of the  allocator object  to obtain
5985 storage.  However, they do not appear to be required to call any other
5986 allocator      members      such     as      <code>construct()</code>,
5987 <code>destroy()</code>,           <code>address()</code>,          and
5988 <code>max_size()</code>.  This makes these allocator members less than
5989 useful in portable programs.
5990
5991         </p>
5992         <p>
5993
5994 It's unclear to me whether the absence of the requirement to use these
5995 allocator  members  is  an  unintentional  omission  or  a  deliberate
5996 choice. However,  since the functions exist in  the standard allocator
5997 and  since  they are  required  to  be  provided by  any  user-defined
5998 allocator I  believe the standard  ought to be clarified  to explictly
5999 specify  whether programs  should or  should not  be able  to  rely on
6000 standard containers calling the functions.
6001
6002         </p>
6003         <p>
6004
6005 I  propose  that all  containers  be required  to  make  use of  these
6006 functions.
6007
6008         </p>
6009 <p><i>[
6010 Batavia:  We support this resolution.  Martin to provide wording.
6011 ]</i></p>
6012
6013 <p><i>[
6014 pre-Oxford:  Martin provided wording.
6015 ]</i></p>
6016
6017
6018
6019     <p><b>Proposed resolution:</b></p>
6020 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<p>
6021
6022 Specifically, I propose to change 23.1 [container.requirements],
6023 p9 as follows:
6024
6025 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</p>
6026 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<blockquote>
6027 <p>
6028 -9- Copy constructors &nbsp;for all container types defined &nbsp;in this clause
6029 <ins>that &nbsp;&nbsp;are &nbsp;parametrized &nbsp;on &nbsp;&nbsp;<code>Allocator</code></ins> &nbsp;copy
6030 <del>an</del><ins>the</ins> &nbsp;allocator argument from &nbsp;their respective
6031 first parameters.
6032
6033 All other &nbsp;constructors for &nbsp;these container types &nbsp;take a<del>n</del>
6034 <ins>const</ins> &nbsp;<code>Allocator&amp;</code> &nbsp;argument &nbsp;(20.1.6), &nbsp;an
6035 allocator whose <code>value_type</code> is the same as the container's
6036 <code>value_type</code>.
6037
6038 A copy of this &nbsp;argument <del>is</del><ins>shall be</ins> used for any
6039 memory &nbsp;allocation <ins> and &nbsp;deallocation</ins> performed<del>,</del>
6040 by these &nbsp;constructors and by all &nbsp;member functions<del>,</del> during
6041 the &nbsp;lifetime &nbsp;of each &nbsp;container &nbsp;object. &nbsp;&nbsp;<ins>Allocation shall &nbsp;be
6042 performed &nbsp;"as &nbsp;if" &nbsp;by &nbsp;calling &nbsp;the &nbsp;<code>allocate()</code> &nbsp;member
6043 function on &nbsp;a copy &nbsp;of the allocator &nbsp;object of the &nbsp;appropriate type
6044 <sup>New &nbsp;Footnote)</sup>, &nbsp;&nbsp;and &nbsp;deallocation &nbsp;"as &nbsp;&nbsp;if" &nbsp;by &nbsp;calling
6045 <code>deallocate()</code> on &nbsp;a copy of &nbsp;the same allocator &nbsp;object of
6046 the corresponding type.</ins>
6047
6048 <ins>A &nbsp;copy of &nbsp;this argument &nbsp;shall also &nbsp;be used &nbsp;to &nbsp;construct and
6049 destroy objects whose lifetime &nbsp;is managed by the container, including
6050 but not &nbsp;limited to those of &nbsp;the container's <code>value_type</code>,
6051 and &nbsp;to &nbsp;obtain &nbsp;their &nbsp;address. &nbsp;&nbsp;All &nbsp;objects &nbsp;residing &nbsp;in &nbsp;storage
6052 allocated by a &nbsp;container's allocator shall be constructed &nbsp;"as if" by
6053 calling the <code>construct()</code> member &nbsp;function on a copy of the
6054 allocator object of &nbsp;the appropriate type. &nbsp;The same &nbsp;objects shall be
6055 destroyed "as if" &nbsp;by calling <code>destroy()</code> on a &nbsp;copy of the
6056 same allocator object &nbsp;of the same type. &nbsp;The &nbsp;address of such objects
6057 shall be obtained "as if" by calling the <code>address()</code> member
6058 function &nbsp;on &nbsp;a &nbsp;copy &nbsp;of &nbsp;the allocator &nbsp;object &nbsp;of &nbsp;the &nbsp;appropriate
6059 type.</ins>
6060
6061 <ins>Finally, a copy &nbsp;of this argument shall be &nbsp;used by its container
6062 object to determine &nbsp;the maximum number of objects &nbsp;of the container's
6063 <code>value_type</code> the container may &nbsp;store at the same time. The
6064 container &nbsp;member function <code>max_size()</code>
6065 obtains &nbsp;this number
6066 from &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the
6067 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;value
6068 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;returned &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;by
6069 &nbsp;&nbsp;&nbsp;&nbsp;a &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;call
6070 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to
6071 <code>get_allocator().max_size()</code>.</ins>
6072
6073 In &nbsp;&nbsp;all &nbsp;container &nbsp;&nbsp;types &nbsp;defined &nbsp;&nbsp;in &nbsp;this &nbsp;&nbsp;clause <ins>that &nbsp;are
6074 parametrized &nbsp;&nbsp;&nbsp;&nbsp;on &nbsp;&nbsp;&nbsp;<code>Allocator</code></ins>, &nbsp;&nbsp;&nbsp;&nbsp;the &nbsp;&nbsp;&nbsp;member
6075 <code>get_allocator()</code> &nbsp;&nbsp;&nbsp;&nbsp;returns
6076 &nbsp;&nbsp;&nbsp;&nbsp;a &nbsp;&nbsp;&nbsp;&nbsp;copy
6077 &nbsp;&nbsp;&nbsp;&nbsp;of &nbsp;&nbsp;&nbsp;&nbsp;the
6078 <code>Allocator</code> &nbsp;&nbsp;&nbsp;&nbsp;object
6079 &nbsp;&nbsp;&nbsp;&nbsp;used &nbsp;&nbsp;&nbsp;&nbsp;to
6080 &nbsp;&nbsp;&nbsp;construct &nbsp;&nbsp;&nbsp;&nbsp;the
6081 container.<sup>258)</sup>
6082 </p>
6083 <p>
6084 New Footnote: This type &nbsp;may be different from <code>Allocator</code>:
6085 it &nbsp;&nbsp;&nbsp;&nbsp;may &nbsp;&nbsp;&nbsp;be
6086 &nbsp;&nbsp;&nbsp;&nbsp;derived &nbsp;&nbsp;&nbsp;from
6087 &nbsp;&nbsp;&nbsp;&nbsp;<code>Allocator</code> &nbsp;&nbsp;&nbsp;via
6088 <code>Allocator::rebind&lt;U&gt;::other</code> &nbsp;&nbsp;for &nbsp;the &nbsp;appropriate
6089 type <code>U</code>.
6090 </p>
6091 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</blockquote>
6092 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<p>
6093 The proposed wording seems cumbersome but I couldn't think of a better
6094 way &nbsp;&nbsp;to &nbsp;describe &nbsp;&nbsp;the
6095 &nbsp;&nbsp;requirement &nbsp;that &nbsp;&nbsp;containers &nbsp;use
6096 &nbsp;&nbsp;their
6097 <code>Allocator</code> &nbsp;to manage &nbsp;only objects &nbsp;(regardless &nbsp;of their
6098 type) &nbsp;that &nbsp;persist &nbsp;over &nbsp;their &nbsp;lifetimes &nbsp;and &nbsp;not, &nbsp;for &nbsp;example,
6099 temporaries &nbsp;created on the &nbsp;stack. That &nbsp;is, containers &nbsp;shouldn't be
6100 required &nbsp;to &nbsp;call &nbsp;<code>Allocator::construct(Allocator::allocate(1),
6101 elem)</code> &nbsp;just to &nbsp;construct a &nbsp;temporary copy &nbsp;of an &nbsp;element, or
6102 <code>Allocator::destroy(Allocator::address(temp), &nbsp;&nbsp;&nbsp;&nbsp;1)</code> &nbsp;&nbsp;&nbsp;to
6103 destroy temporaries.
6104
6105 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</p>
6106
6107
6108 <p><i>[
6109 Howard: This same paragraph will need some work to accommodate <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
6110 ]</i></p>
6111
6112
6113 <p><i>[
6114 post Oxford:  This would be rendered NAD Editorial by acceptance of
6115 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
6116 ]</i></p>
6117
6118
6119
6120
6121
6122 <hr>
6123 <h3><a name="581"></a>581. <code>flush()</code> not unformatted function</h3>
6124 <p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
6125  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
6126 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p>
6127 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
6128 <p><b>Discussion:</b></p>
6129         <p>
6130
6131 The resolution of issue 60 changed <code>basic_ostream::flush()</code>
6132 so as not  to require it to behave as  an unformatted output function.
6133 That has at least two in my opinion problematic consequences:
6134
6135         </p>
6136         <p>
6137
6138 First, <code>flush()</code>  now calls <code>rdbuf()-&gt;pubsync()</code>
6139 unconditionally, without  regard to the  state of the stream.  I can't
6140 think of any reason why <code>flush()</code> should behave differently
6141 from the vast majority of stream functions in this respect.
6142
6143         </p>
6144         <p>
6145
6146 Second, <code>flush()</code> is not  required to catch exceptions from
6147 <code>pubsync()</code> or set  <code>badbit</code> in response to such
6148 events. That doesn't seem right either, as most other stream functions
6149 do so.
6150
6151         </p>
6152
6153
6154     <p><b>Proposed resolution:</b></p>
6155         <p>
6156
6157 I  propose  to revert  the  resolution of  issue  60  with respect  to
6158 <code>flush()</code>. Specifically,  I propose to  change 27.6.2.6, p7
6159 as follows:
6160
6161         </p>
6162
6163 <p>
6164 Effects: <ins>Behaves as an  unformatted output function (as described
6165 in 27.6.2.6, paragraph 1). </ins>If <code>rdbuf()</code> is not a null
6166 pointer,  <ins>constructs a  sentry  object.  If  this object  returns
6167 <code>true</code> when converted to a  value of type bool the function
6168 </ins>calls <code>rdbuf()-&gt;pubsync()</code>.  If that function returns
6169 -1    calls    <code>setstate(badbit)</code>    (which    may    throw
6170 <code>ios_base::failure</code>  (27.4.4.3)).   <ins>Otherwise, if  the
6171 sentry object returns <code>false</code>, does nothing.</ins><del>Does
6172 not  behave  as  an  unformatted  output  function  (as  described  in
6173 27.6.2.6, paragraph 1).</del>
6174 </p>
6175
6176
6177
6178 <p><i>[
6179 Kona (2007): Proposed Disposition: Ready
6180 ]</i></p>
6181
6182
6183
6184
6185
6186 <hr>
6187 <h3><a name="582"></a>582. specialized algorithms and volatile storage</h3>
6188 <p><b>Section:</b> 20.6.4.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6189  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
6190 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#uninitialized.copy">active issues</a> in [uninitialized.copy].</p>
6191 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p>
6192 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6193 <p><b>Discussion:</b></p>
6194         <p>
6195
6196 The specialized  algorithms [lib.specialized.algorithms] are specified
6197 as having the general effect of invoking the following expression:
6198
6199         </p>
6200             <pre>
6201 new (static_cast&lt;void*&gt;(&amp;*i))
6202     typename iterator_traits&lt;ForwardIterator&gt;::value_type (x)
6203
6204             </pre>
6205         <p>
6206
6207 This  expression is  ill-formed  when the  type  of the  subexpression
6208 <code>&amp;*i</code> is some volatile-qualified <code>T</code>.
6209
6210         </p>
6211
6212 <p><i>[
6213 Batavia:  Lack of support for proposed resolution but agree there is a
6214 defect.  Howard to look at wording.  Concern that move semantics
6215 properly expressed if iterator returns rvalue.
6216 ]</i></p>
6217
6218
6219
6220
6221     <p><b>Proposed resolution:</b></p>
6222         <p>
6223
6224 In order  to allow these algorithms  to operate on  volatile storage I
6225 propose to change the expression so as to make it well-formed even for
6226 pointers  to volatile  types.  Specifically,  I propose  the following
6227 changes to clauses 20 and 24. Change 20.6.4.1, p1 to read:
6228
6229         </p>
6230             <pre>
6231 <i>Effects</i>:
6232
6233 typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
6234 typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
6235
6236 for (; first != last; ++result, ++first)
6237     new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*result))
6238         value_type (*first);
6239
6240             </pre>
6241         <p>
6242
6243 change 20.6.4.2, p1 to read
6244
6245         </p>
6246             <pre>
6247 <i>Effects</i>:
6248
6249 typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
6250 typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
6251
6252 for (; first != last; ++result, ++first)
6253     new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
6254         value_type (*x);
6255
6256             </pre>
6257         <p>
6258
6259 and change 20.6.4.3, p1 to read
6260
6261         </p>
6262             <pre>
6263 <i>Effects</i>:
6264
6265 typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
6266 typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
6267
6268 for (; n--; ++first)
6269     new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
6270         value_type (*x);
6271
6272             </pre>
6273         <p>
6274
6275 In   addition,  since   there   is  no   partial  specialization   for
6276 <code>iterator_traits&lt;volatile T*&gt;</code>  I propose to  add one
6277 to parallel such specialization  for &lt;const T*&gt;. Specifically, I
6278 propose to add the following text to the end of 24.3.1, p3:
6279
6280         </p>
6281         <p>
6282
6283 and for pointers to volatile as
6284
6285         </p>
6286             <pre>
6287 namespace std {
6288 template&lt;class T&gt; struct iterator_traits&lt;volatile T*&gt; {
6289 typedef ptrdiff_t difference_type;
6290 typedef T value_type;
6291 typedef volatile T* pointer;
6292 typedef volatile T&amp; reference;
6293 typedef random_access_iterator_tag iterator_category;
6294 };
6295 }
6296
6297             </pre>
6298         <p>
6299
6300 Note that  the change to  <code>iterator_traits</code> isn't necessary
6301 in order to implement the  specialized algorithms in a way that allows
6302 them to operate on volatile  strorage. It is only necesassary in order
6303 to specify  their effects in terms  of <code>iterator_traits</code> as
6304 is  done here.   Implementations can  (and some  do) achieve  the same
6305 effect by means of function template overloading.
6306
6307         </p>
6308
6309
6310
6311
6312 <hr>
6313 <h3><a name="585"></a>585. facet error reporting</h3>
6314 <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#Open">Open</a>
6315  <b>Submitter:</b> Martin Sebor, Paolo Carlini <b>Date:</b> 2006-06-22</p>
6316 <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>
6317 <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>
6318 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6319 <p><b>Discussion:</b></p>
6320         <p>
6321
6322 Section  22.2, paragraph 2  requires facet  <code>get()</code> members
6323 that    take    an    <code>ios_base::iostate&amp;</code>    argument,
6324 <code><i>err</i></code>,  to   ignore  the  (initial)   value  of  the
6325 argument, but to set it to <code>ios_base::failbit</code> in case of a
6326 parse error.
6327
6328         </p>
6329         <p>
6330
6331 We  believe  there  are  a   few  minor  problems  with  this  blanket
6332 requirement  in   conjunction  with   the  wording  specific   to  each
6333 <code>get()</code> member function.
6334
6335         </p>
6336         <p>
6337
6338 First,  besides <code>get()</code>  there are  other  member functions
6339 with     a      slightly     different     name      (for     example,
6340 <code>get_date()</code>). It's not completely clear that the intent of
6341 the  paragraph  is  to  include  those  as  well,  and  at  least  one
6342 implementation has interpreted the requirement literally.
6343
6344         </p>
6345         <p>
6346
6347 Second,    the     requirement    to    "set     the    argument    to
6348 <code>ios_base::failbit</code>  suggests that  the  functions are  not
6349 permitted    to   set    it   to    any   other    value    (such   as
6350 <code>ios_base::eofbit</code>,   or   even  <code>ios_base::eofbit   |
6351 ios_base::failbit</code>).
6352
6353         </p>
6354         <p>
6355
6356 However, 22.2.2.1.2, p5 (Stage  3 of <code>num_get</code> parsing) and
6357 p6 (<code>bool</code> parsing)  specifies that the <code>do_get</code>
6358 functions  perform <code><i>err</i> |=  ios_base::eofbit</code>, which
6359 contradicts  the earlier  requirement to  ignore  <i>err</i>'s initial
6360 value.
6361
6362         </p>
6363         <p>
6364
6365 22.2.6.1.2,  p1  (the  Effects  clause of  the  <code>money_get</code>
6366 facet's  <code>do_get</code>  member  functions) also  specifies  that
6367 <code><i>err</i></code>'s initial  value be used to  compute the final
6368 value  by  ORing  it  with  either  <code>ios_base::failbit</code>  or
6369 with<code>ios_base::eofbit | ios_base::failbit</code>.
6370
6371         </p>
6372
6373
6374     <p><b>Proposed resolution:</b></p>
6375         <p>
6376
6377 We believe the  intent is for all facet member  functions that take an
6378 <code>ios_base::iostate&amp;</code> argument to:
6379
6380         </p>
6381             <ul>
6382                 <li>
6383
6384 ignore the initial value of the <code><i>err</i></code> argument,
6385
6386                 </li>
6387                 <li>
6388
6389 reset <code><i>err</i></code>  to <code>ios_base::goodbit</code> prior
6390 to any further processing,
6391
6392                 </li>
6393                 <li>
6394
6395 and       set      either       <code>ios_base::eofbit</code>,      or
6396 <code>ios_base::failbit</code>, or both in <code><i>err</i></code>, as
6397 appropriate,  in response  to  reaching the  end-of-file  or on  parse
6398 error, or both.
6399
6400                 </li>
6401             </ul>
6402         <p>
6403
6404 To that effect we propose to change 22.2, p2 as follows:
6405
6406         </p>
6407         <p>
6408
6409 The  <i>put</i><del>()</del>  members  make  no  provision  for  error
6410 reporting.   (Any  failures of  the  OutputIterator  argument must  be
6411 extracted   from  the   returned  iterator.)    <ins>Unless  otherwise
6412 specified, </ins>the <i>get</i><del>()</del>  members  <ins>that</ins>
6413 take an  <code>ios_base::iostate&amp;</code> argument <del>whose value
6414 they  ignore,  but  set  to  ios_base::failbit  in  case  of  a  parse
6415 error.</del><ins>,   <code><i>err</i></code>,   start  by   evaluating
6416 <code>err  =   ios_base::goodbit</code>,  and  may   subsequently  set
6417 <i>err</i>     to     either     <code>ios_base::eofbit</code>,     or
6418 <code>ios_base::failbit</code>,     or     <code>ios_base::eofbit    |
6419 ios_base::failbit</code> in response to reaching the end-of-file or in
6420 case of a parse error, or both, respectively.</ins>
6421
6422         </p>
6423
6424
6425 <p><i>[
6426 Kona (2007): We need to change the proposed wording to clarify that the
6427 phrase "the get members" actually denotes <tt>get()</tt>, <tt>get_date()</tt>, etc.
6428 Proposed Disposition: Open
6429 ]</i></p>
6430
6431
6432
6433
6434 <hr>
6435 <h3><a name="588"></a>588. requirements on zero sized tr1::arrays and other details</h3>
6436 <p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6437  <b>Submitter:</b> Gennaro Prota <b>Date:</b> 2006-07-18</p>
6438 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
6439 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
6440 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6441 <p><b>Discussion:</b></p>
6442 <p>
6443 The wording used for section 23.2.1 [lib.array] seems to be subtly
6444 ambiguous about zero sized arrays (N==0). Specifically:
6445 </p>
6446 <p>
6447 * "An instance of array&lt;T, N&gt; stores N elements of type T, so that
6448 [...]"
6449 </p>
6450 <p>
6451 Does this imply that a zero sized array object stores 0 elements, i.e.
6452 that it cannot store any element of type T? The next point clarifies
6453 the rationale behind this question, basically how to implement begin()
6454 and end():
6455 </p>
6456 <p>
6457 * 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==
6458 end() == unique value."
6459 </p>
6460 <p>
6461 What does "unique" mean in this context? Let's consider the following
6462 possible implementations, all relying on a partial specialization:
6463 </p>
6464 <blockquote><pre>a)
6465     template&lt; typename T &gt;
6466     class array&lt; T, 0 &gt; {
6467
6468         ....
6469
6470         iterator begin()
6471         { return iterator( reinterpret_cast&lt; T * &gt;( this ) ); }
6472         ....
6473
6474     };
6475 </pre></blockquote>
6476 <p>
6477 This has been used in boost, probably intending that the return value
6478 had to be unique to the specific array object and that array couldn't
6479 store any T. Note that, besides relying on a reinterpret_cast, has
6480 (more than potential) alignment problems.
6481 </p>
6482 <blockquote><pre>b)
6483     template&lt; typename T &gt;
6484     class array&lt; T, 0 &gt; {
6485
6486         T t;
6487
6488         iterator begin()
6489         { return iterator( &amp;t ); }
6490         ....
6491
6492     };
6493 </pre></blockquote>
6494 <p>
6495 This provides a value which is unique to the object and to the type of
6496 the array, but requires storing a T. Also, it would allow the user to
6497 mistakenly provide an initializer list with one element.
6498 </p>
6499 <p>
6500 A slight variant could be returning *the* null pointer of type T
6501 </p>
6502 <blockquote><pre>    return static_cast&lt;T*&gt;(0);
6503 </pre></blockquote>
6504 <p>
6505 In this case the value would be unique to the type array&lt;T, 0&gt; but not
6506 to the objects (all objects of type array&lt;T, 0&gt; with the same value
6507 for T would yield the same pointer value).
6508 </p>
6509 <p>
6510 Furthermore this is inconsistent with what the standard requires from
6511 allocation functions (see library issue 9).
6512 </p>
6513 <p>
6514 c) same as above but with t being a static data member; again, the
6515 value would be unique to the type, not to the object.
6516 </p>
6517 <p>
6518 d) to avoid storing a T *directly* while disallowing the possibility
6519 to use a one-element initializer list a non-aggregate nested class
6520 could be defined
6521 </p>
6522 <blockquote><pre>    struct holder { holder() {} T t; } h;
6523 </pre></blockquote>
6524 <p>
6525 and then begin be defined as
6526 </p>
6527 <blockquote><pre> iterator begin() { return &amp;h.t; }
6528 </pre></blockquote>
6529 <p>
6530 But then, it's arguable whether the array stores a T or not.
6531 Indirectly it does.
6532 </p>
6533 <p>
6534 -----------------------------------------------------
6535 </p>
6536 <p>
6537 Now, on different issues:
6538 </p>
6539 <p>
6540 * what's the effect of calling assign(T&amp;) on a zero-sized array? There
6541 seems to be only mention of front() and back(), in 23.2.1 [lib.array]
6542 p4 (I would also suggest to move that bullet to section 23.2.1.5
6543 [lib.array.zero], for locality of reference)
6544 </p>
6545 <p>
6546 * (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit
6547 inconsistent with that of other sequences: that's not a problem in
6548 itself, but compare it for instance with "A vector is a kind of
6549 sequence that supports random access iterators"; though the intent is
6550 obvious one might argue that the wording used for arrays doesn't tell
6551 what an array is, and relies on the reader to infer that it is what
6552 the &lt;array&gt; header defines.
6553 </p>
6554 <p>
6555 * it would be desiderable to have a static const data member of type
6556 std::size_t, with value N, for usage as integral constant expression
6557 </p>
6558 <p>
6559 * section 23.1 [lib.container.requirements] seem not to consider
6560 fixed-size containers at all, as it says: "[containers] control
6561 allocation and deallocation of these objects [the contained objects]
6562 through constructors, destructors, *insert and erase* operations"
6563 </p>
6564 <p>
6565 * max_size() isn't specified: the result is obvious but, technically,
6566 it relies on table 80: "size() of the largest possible container"
6567 which, again, doesn't seem to consider fixed size containers
6568 </p>
6569
6570
6571 <p><b>Proposed resolution:</b></p>
6572 <p>
6573 </p>
6574
6575
6576 <p><i>[
6577 Kona (2007): requirements on zero sized <tt>tr1::array</tt>s and other details
6578 Issue 617: <tt>std::array</tt> is a sequence that doesn't satisfy the sequence
6579 requirements? Alisdair will prepare a paper. Proposed Disposition: Open
6580 ]</i></p>
6581
6582
6583
6584
6585
6586 <hr>
6587 <h3><a name="595"></a>595. TR1/C++0x: fabs(complex&lt;T&gt;) redundant / wrongly specified</h3>
6588 <p><b>Section:</b> 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
6589  <b>Submitter:</b> Stefan Große Pawig <b>Date:</b> 2006-09-24</p>
6590 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
6591 <p><b>Discussion:</b></p>
6592 <p>
6593 TR1 introduced, in the C compatibility chapter, the function
6594 fabs(complex&lt;T&gt;):
6595 </p>
6596 <blockquote><pre>----- SNIP -----
6597 8.1.1 Synopsis                                [tr.c99.cmplx.syn]
6598
6599   namespace std {
6600   namespace tr1 {
6601 [...]
6602   template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp; x);
6603   } // namespace tr1
6604   } // namespace std
6605
6606 [...]
6607
6608 8.1.8 Function fabs                          [tr.c99.cmplx.fabs]
6609
6610 1 Effects: Behaves the same as C99 function cabs, defined in
6611   subclause 7.3.8.1.
6612 ----- SNIP -----
6613 </pre></blockquote>
6614
6615 <p>
6616 The current C++0X draft document (n2009.pdf) adopted this
6617 definition in chapter 26.3.1 (under the comment // 26.3.7 values)
6618 and 26.3.7/7.
6619 </p>
6620 <p>
6621 But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
6622 n1124), the referenced subclause reads
6623 </p>
6624
6625 <blockquote><pre>----- SNIP -----
6626 7.3.8.1 The cabs functions
6627
6628   Synopsis
6629
6630 1 #include &lt;complex.h&gt;
6631   double cabs(double complex z);
6632   float cabsf(float complex z);
6633   long double cabsl(long double z);
6634
6635   Description
6636
6637 2 The cabs functions compute the complex absolute value (also called
6638   norm, modulus, or magnitude) of z.
6639
6640   Returns
6641
6642 3 The cabs functions return the complex absolute value.
6643 ----- SNIP -----
6644 </pre></blockquote>
6645
6646 <p>
6647 Note that the return type of the cabs*() functions is not a complex
6648 type.  Thus, they are equivalent to the already well established
6649   template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp; x);
6650 (26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft
6651 document n2009.pdf).
6652 </p>
6653 <p>
6654 So either the return value of fabs() is specified wrongly, or fabs()
6655 does not behave the same as C99's cabs*().
6656 </p>
6657
6658 <b>Possible Resolutions</b>
6659
6660 <p>
6661 This depends on the intention behind the introduction of fabs().
6662 </p>
6663 <p>
6664 If the intention was to provide a /complex/ valued function that
6665 calculates the magnitude of its argument, this should be
6666 explicitly specified.  In TR1, the categorization under "C
6667 compatibility" is definitely wrong, since C99 does not provide
6668 such a complex valued function.
6669 </p>
6670 <p>
6671 Also, it remains questionable if such a complex valued function
6672 is really needed, since complex&lt;T&gt; supports construction and
6673 assignment from real valued arguments.  There is no difference
6674 in observable behaviour between
6675 </p>
6676 <blockquote><pre>  complex&lt;double&gt; x, y;
6677   y = fabs(x);
6678   complex&lt;double&gt; z(fabs(x));
6679 </pre></blockquote>
6680 <p>
6681 and
6682 </p>
6683 <blockquote><pre>  complex&lt;double&gt; x, y;
6684   y = abs(x);
6685   complex&lt;double&gt; z(abs(x));
6686 </pre></blockquote>
6687 <p>
6688 If on the other hand the intention was to provide the intended
6689 functionality of C99, fabs() should be either declared deprecated
6690 or (for C++0X) removed from the standard, since the functionality
6691 is already provided by the corresponding overloads of abs().
6692 </p>
6693
6694
6695
6696 <p><b>Proposed resolution:</b></p>
6697
6698 <p>
6699 Change the synopsis in 26.3.1 [complex.synopsis]:
6700 </p>
6701
6702 <blockquote><pre>template&lt;class T&gt; <del>complex&lt;</del>T<del>&gt;</del> fabs(const complex&lt;T&gt;&amp;);
6703 </pre></blockquote>
6704
6705 <p>
6706 Change 26.3.7 [complex.value.ops], p7:
6707 </p>
6708
6709 <blockquote>
6710 <pre>template&lt;class T&gt; <del>complex&lt;</del>T<del>&gt;</del> fabs(const complex&lt;T&gt;&amp; <i>x</i>);
6711 </pre>
6712 <blockquote>
6713 <p>
6714 -7- <i>Effects:</i> Behaves the same as C99 function <tt>cabs</tt>, defined in subclause 7.3.8.1.
6715 </p>
6716 </blockquote>
6717 </blockquote>
6718
6719
6720
6721 <p><i>[
6722 Kona (2007): Change the return type of <tt>fabs(complex)</tt> to <tt>T</tt>.
6723 Proposed Disposition: Ready
6724 ]</i></p>
6725
6726
6727
6728
6729
6730 <hr>
6731 <h3><a name="596"></a>596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes</h3>
6732 <p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
6733  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2006-09-26</p>
6734 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#filebuf.members">active issues</a> in [filebuf.members].</p>
6735 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.members].</p>
6736 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
6737 <p><b>Discussion:</b></p>
6738 <p>
6739 In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke
6740 </p>
6741 <blockquote><pre>   ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
6742 </pre></blockquote>
6743 <p>
6744 and we expect the open to fail, because out|in|app is not listed in
6745 Table 92, and just before the table we see very specific words:
6746 </p>
6747 <blockquote><p>
6748   If mode is not some combination of flags shown in the table
6749   then the open fails.
6750 </p></blockquote>
6751 <p>
6752 But the corresponding table in the C standard, 7.19.5.3, provides two
6753 modes "a+" and "a+b", to which the C++ modes out|in|app and
6754 out|in|app|binary would presumably apply.
6755 </p>
6756 <p>
6757 We would like to argue that the intent of Table 112 was to match the
6758 semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was
6759 unintentional.  (Otherwise there would be valid and useful behaviors
6760 available in C file I/O which are unavailable using C++, for no
6761 valid functional reason.)
6762 </p>
6763 <p>
6764 We further request that the missing modes be explicitly restored to
6765 the WP, for inclusion in C++0x.
6766 </p>
6767
6768 <p><i>[
6769 Martin adds:
6770 ]</i></p>
6771
6772
6773 <p>
6774 ...besides "a+" and "a+b" the C++ table is also missing a row
6775 for a lone app bit which in at least two current implementation
6776 as well as in Classic Iostreams corresponds to the C stdio "a"
6777 mode and has been traditionally documented as implying ios::out.
6778 Which means the table should also have a row for in|app meaning
6779 the same thing as "a+" already proposed in the issue.
6780 </p>
6781
6782
6783 <p><b>Proposed resolution:</b></p>
6784 <p>
6785 Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:
6786 </p>
6787
6788 <blockquote>
6789 <table border="1">
6790 <caption> File open modes</caption>
6791 <tbody><tr>
6792 <th colspan="5"><tt>ios_base</tt> Flag combination</th>
6793 <th><tt>stdio</tt> equivalent</th>
6794 </tr>
6795 <tr>
6796 <th><tt>binary</tt></th><th><tt>in</tt></th><th><tt>out</tt></th><th><tt>trunc</tt></th><th><tt>app</tt></th><th><tt>&nbsp;</tt></th>
6797 </tr>
6798
6799 <tr>
6800 <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
6801 </tr>
6802 <tr>
6803 <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"a"</tt></td>
6804 </tr>
6805 <tr>
6806 <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a"</tt></ins></td>
6807 </tr>
6808 <tr>
6809 <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
6810 </tr>
6811 <tr>
6812 <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r"</tt></td>
6813 </tr>
6814 <tr>
6815 <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+"</tt></td>
6816 </tr>
6817 <tr>
6818 <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+"</tt></td>
6819 </tr>
6820 <tr>
6821 <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
6822 </tr>
6823 <tr>
6824 <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
6825 </tr>
6826
6827 <tr>
6828 <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
6829 </tr>
6830 <tr>
6831 <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"ab"</tt></td>
6832 </tr>
6833 <tr>
6834 <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"ab"</tt></ins></td>
6835 </tr>
6836 <tr>
6837 <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
6838 </tr>
6839 <tr>
6840 <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"rb"</tt></td>
6841 </tr>
6842 <tr>
6843 <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+b"</tt></td>
6844 </tr>
6845 <tr>
6846 <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+b"</tt></td>
6847 </tr><tr>
6848 <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
6849 </tr>
6850 <tr>
6851 <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
6852 </tr>
6853
6854
6855 </tbody></table>
6856 </blockquote>
6857
6858
6859
6860 <p><i>[
6861 Kona (2007) Added proposed wording and moved to Review.
6862 ]</i></p>
6863
6864
6865
6866
6867
6868 <hr>
6869 <h3><a name="597"></a>597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.</h3>
6870 <p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6871  <b>Submitter:</b> Daveed Vandevoorde <b>Date:</b> 2006-04-05</p>
6872 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
6873 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
6874 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6875 <p><b>Discussion:</b></p>
6876 <p>
6877 In a private email, Daveed writes:
6878 </p>
6879 <blockquote>
6880 <p>
6881 I am not familiar with the C TR, but my guess is that the
6882 class type approach still won't match a built-in type
6883 approach because the notion of "promotion" cannot be
6884 emulated by user-defined types.
6885 </p>
6886 <p>
6887 Here is an example:
6888 </p>
6889 </blockquote>
6890 <pre>
6891                  struct S {
6892                    S(_Decimal32 const&amp;);  // Converting constructor
6893                  };
6894                  void f(S);
6895
6896                  void f(_Decimal64);
6897
6898                  void g(_Decimal32 d) {
6899                    f(d);
6900                  }
6901 </pre>
6902
6903 <blockquote>
6904 <p>
6905 If _Decimal32 is a built-in type, the call f(d) will likely
6906 resolve to f(_Decimal64) because that requires only a
6907 promotion, whereas f(S) requires a user-defined conversion.
6908 </p>
6909 <p>
6910 If _Decimal32 is a class type, I think the call f(d) will be
6911 ambiguous because both the conversion to _Decimal64 and the
6912 conversion to S will be user-defined conversions with neither
6913 better than the other.
6914 </p>
6915 </blockquote>
6916 <p>
6917 Robert comments:
6918 </p>
6919 <p>In general, a library of arithmetic types cannot exactly emulate the
6920 behavior of the intrinsic numeric types. There are several ways to tell
6921 whether an implementation of the decimal types uses compiler
6922 intrinisics or a library. For example:
6923 </p>
6924 <pre>                 _Decimal32 d1;
6925                  d1.operator+=(5);  // If d1 is a builtin type, this won't compile.
6926 </pre>
6927 <p>
6928 In preparing the decimal TR, we have three options:
6929 </p>
6930 <ol>
6931 <li>require that the decimal types be class types</li>
6932 <li>require that the decimal types be builtin types, like float and double</li>
6933 <li>specify a library of class types, but allow enough implementor
6934 latitude that a conforming implementation could instead provide builtin
6935 types</li>
6936 </ol>
6937 <p>
6938 We decided as a group to pursue option #3, but that approach implies
6939 that implementations may not agree on the semantics of certain use
6940 cases (first example, above), or on whether certain other cases are
6941 well-formed (second example). Another potentially important problem is
6942 that, under the present definition of POD, the decimal classes are not
6943 POD types, but builtins will be.
6944 </p>
6945 <p>Note that neither example above implies any problems with respect to
6946 C-to-C++ compatibility, since neither example can be expressed in C.
6947 </p>
6948
6949
6950 <p><b>Proposed resolution:</b></p>
6951
6952
6953
6954
6955
6956 <hr>
6957 <h3><a name="606"></a>606. Decimal: allow narrowing conversions</h3>
6958 <p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6959  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-15</p>
6960 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
6961 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
6962 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6963 <p><b>Discussion:</b></p>
6964 <p>
6965 In c++std-lib-17205, Martin writes:
6966 </p>
6967 <blockquote><p>...was it a deliberate design choice to make narrowing
6968 assignments ill-formed while permitting narrowing compound assignments?
6969 For instance:
6970 </p></blockquote>
6971 <pre>      decimal32 d32;
6972       decimal64 d64;
6973
6974       d32 = 64;     // error
6975       d32 += 64;    // okay
6976 </pre>
6977 <p>
6978 In c++std-lib-17229, Robert responds:
6979 </p>
6980 <blockquote><p>It is a vestige of an old idea that I forgot to remove
6981 from the paper. Narrowing assignments should be permitted. The bug is
6982 that the converting constructors that cause narrowing should not be
6983 explicit. Thanks for pointing this out.
6984 </p></blockquote>
6985
6986 <p><b>Proposed resolution:</b></p>
6987 <p>
6988 1.  In "3.2.2 Class <code>decimal32</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversions:
6989 </p>
6990 <pre>                // <i>3.2.2.2 conversion from floating-point type:</i>
6991                 <del>explicit</del> decimal32(decimal64 <i>d64</i>);
6992                 <del>explicit</del> decimal32(decimal128 <i>d128</i>);
6993 </pre>
6994 <p>
6995 2.  Do the same thing in "3.2.2.2. Conversion from floating-point type."
6996 </p>
6997 <p>
6998 3.  In "3.2.3 Class <code>decimal64</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversion:
6999 </p>
7000 <pre>                // <i>3.2.3.2 conversion from floating-point type:</i>
7001                 <del>explicit</del> decimal64(decimal128 <i>d128</i>);
7002 </pre>
7003 <p>
7004 4.  Do the same thing in "3.2.3.2. Conversion from floating-point type."
7005 </p>
7006
7007 <p><i>[
7008 Redmond: We prefer explicit conversions for narrowing and implicit for widening.
7009 ]</i></p>
7010
7011
7012
7013
7014
7015
7016 <hr>
7017 <h3><a name="612"></a>612. numeric_limits::is_modulo insufficently defined</h3>
7018 <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#Open">Open</a>
7019  <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2006-11-10</p>
7020 <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>
7021 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7022 <p><b>Discussion:</b></p>
7023 <p>
7024 18.2.1.2 55 states that "A type is modulo if it is possible to add two
7025 positive numbers together and have a result that wraps around to a
7026 third number that is less".
7027 This seems insufficent for the following reasons:
7028 </p>
7029
7030 <ol>
7031 <li>Doesn't define what that value recieved is.</li>
7032 <li>Doesn't state the result is repeatable</li>
7033 <li> Doesn't require that doing addition, subtraction and other
7034 operations on all values is defined behaviour.</li>
7035 </ol>
7036
7037 <p><i>[
7038 Batavia: Related to
7039 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2144.pdf">N2144</a>.
7040 Pete: is there an ISO definition of modulo?  Underflow on signed behavior is undefined.
7041 ]</i></p>
7042
7043
7044
7045 <p><b>Proposed resolution:</b></p>
7046 <p>
7047 Suggest 18.2.1.2 [numeric.limits.members[numeric.limits.members], paragraph 57 is ammeded to:
7048 </p>
7049
7050 <blockquote><p>
7051 A type is modulo if<ins>,</ins> <del>it is possible to add two positive numbers
7052 and have a result that wraps around to a third number that is less.</del>
7053 <ins>given any operation involving +,- or * on values of that type whose value
7054 would fall outside the range <tt>[min(), max()]</tt>, then the value returned
7055 differs from the true value by an integer multiple of <tt>(max() - min() +
7056 1)</tt>.</ins>
7057 </p></blockquote>
7058
7059
7060
7061
7062
7063
7064 <hr>
7065 <h3><a name="614"></a>614. std::string allocator requirements still inconsistent</h3>
7066 <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#Open">Open</a>
7067  <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-05</p>
7068 <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>
7069 <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>
7070 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7071 <p><b>Discussion:</b></p>
7072 <p>
7073 This is based on N2134, where 21.3.1/2 states:
7074 "... The Allocator object used shall be a copy of the Allocator object
7075 passed to the basic_string object's constructor or, if the constructor does
7076 not take an Allocator argument, a copy of a default-constructed Allocator
7077 object."
7078 </p>
7079 <p>
7080 Section 21.3.2/1 lists two constructors:
7081 </p>
7082 <blockquote><pre>basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str );
7083
7084 basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str ,
7085              size_type pos , size_type n = npos,
7086              const Allocator&amp; a = Allocator());
7087 </pre></blockquote>
7088 <p>
7089 and then says "In the first form, the Allocator value used is copied from
7090 str.get_allocator().", which isn't an option according to 21.3.1.
7091 </p>
7092 <p><i>[
7093 Batavia:  We need blanket statement to the effect of:
7094 ]</i></p>
7095
7096
7097 <ol>
7098 <li>If an allocator is passed in, use it, or,</li>
7099 <li>If a string is passed in, use its allocator.</li>
7100 </ol>
7101 <p><i>[
7102 Review constructors and functions that return a string; make sure we follow these
7103 rules (substr, operator+, etc.).  Howard to supply wording.
7104 ]</i></p>
7105
7106
7107 <p><i>[
7108 Bo adds:  The new container constructor which takes only a <tt>size_type</tt> is not
7109 consistent with 23.1 [container.requirements], p9 which says in part:
7110
7111 <blockquote>
7112 All other constructors for these container types take an
7113 <tt>Allocator&amp;</tt> argument (20.1.2), an allocator whose value type
7114 is the same as the container's value type. A copy of this argument is
7115 used for any memory allocation performed, by these constructors and by
7116 all member functions, during the lifetime of each container object.
7117 </blockquote>
7118 ]</i></p>
7119
7120
7121
7122 <p><b>Proposed resolution:</b></p>
7123 <p>
7124 </p>
7125
7126
7127
7128
7129
7130 <hr>
7131 <h3><a name="617"></a>617. std::array is a sequence that doesn't satisfy the sequence requirements?</h3>
7132 <p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
7133  <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-30</p>
7134 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
7135 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
7136 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
7137 <p><b>Discussion:</b></p>
7138 <p>
7139 The <tt>&lt;array&gt;</tt> header is given under 23.2 [sequences].
7140 23.2.1 [array]/paragraph 3 says:
7141 </p>
7142 <blockquote><p>
7143 "Unless otherwise specified, all array operations are as described in
7144 23.1 [container.requirements]".
7145 </p></blockquote>
7146 <p>
7147 However, array isn't mentioned at all in section 23.1 [container.requirements].
7148 In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear)
7149 that std::array does not have in 23.2.1 [array].
7150 </p>
7151 <p>
7152 Also, Table 83 "Optional sequence operations" lists several operations that
7153 std::array does have, but array isn't mentioned.
7154 </p>
7155
7156
7157 <p><b>Proposed resolution:</b></p>
7158 <p>
7159 </p>
7160
7161
7162
7163
7164
7165 <hr>
7166 <h3><a name="618"></a>618. valarray::cshift() effects on empty array</h3>
7167 <p><b>Section:</b> 26.5.2.7 [valarray.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
7168  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-10</p>
7169 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
7170 <p><b>Discussion:</b></p>
7171 <p>
7172 I would respectfully request an issue be opened with the intention to
7173 clarify the wording for <tt>size() == 0</tt> for <tt>cshift</tt>.
7174 </p>
7175
7176
7177 <p><b>Proposed resolution:</b></p>
7178 <p>
7179 Change 26.5.2.7 [valarray.members], paragraph 10:
7180 </p>
7181
7182 <blockquote>
7183
7184 <pre>valarray&lt;T&gt; cshift(int <i>n</i>) const;
7185 </pre>
7186
7187 <blockquote>
7188 <p>
7189 This function returns an object of class <tt>valarray&lt;T&gt;</tt>, of
7190 length <tt>size()</tt>, <del>each of whose elements <tt>I</tt> is
7191 <tt>(*this)[(I + n ) % size()]</tt>. Thus, if element zero is taken as
7192 the leftmost element, a positive value of <i>n</i> shifts the elements
7193 circularly left <i>n</i> places.</del> <ins>that is a circular shift of <tt>*this</tt>. If
7194 element zero is taken as the leftmost element, a non-negative value of
7195 <i>n</i> shifts the elements circularly left <i>n</i> places and a
7196 negative value of <i>n</i> shifts the elements circularly right
7197 -<i>n</i> places.</ins>
7198 </p>
7199 </blockquote>
7200 </blockquote>
7201
7202
7203
7204 <p><b>Rationale:</b></p>
7205 <p>
7206 We do not believe that there is any real ambiguity about what happens
7207 when <tt>size() == 0</tt>, but we do believe that spelling this out as a C++
7208 expression causes more trouble that it solves. The expression is
7209 certainly wrong when <tt>n &lt; 0</tt>, since the sign of % with negative arguments
7210 is implementation defined.
7211 </p>
7212
7213
7214 <p><i>[
7215 Kona (2007) Changed proposed wording, added rationale and set to Review.
7216 ]</i></p>
7217
7218
7219
7220
7221
7222 <hr>
7223 <h3><a name="620"></a>620. valid uses of empty valarrays</h3>
7224 <p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
7225  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
7226 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p>
7227 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
7228 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
7229 <p><b>Discussion:</b></p>
7230         <p>
7231
7232 The <i>Effects</i>  clause for the  default <code>valarray</code> ctor
7233 suggests  that  it  is possible  to  increase  the  size of  an  empty
7234 <code>valarray</code>  object   by  calling  other   non-const  member
7235 functions of the class besides <code>resize()</code>. However, such an
7236 interpretation would  be contradicted by  the requirement on  the copy
7237 assignment  operator  (and  apparently   also  that  on  the  computed
7238 assignments)  that the  assigned arrays  be  the same  size.  See  the
7239 reflector discussion starting with c++std-lib-17871.
7240
7241         </p>
7242         <p>
7243
7244 In  addition,  <i>Footnote</i> 280  uses  some questionable  normative
7245 language.
7246
7247         </p>
7248
7249
7250 <p><b>Proposed resolution:</b></p>
7251         <p>
7252
7253 Reword the <i>Effects</i> clause and <i>Footnote 280</i> as follows (26.5.2.1 [valarray.cons]):
7254
7255         </p>
7256         <blockquote>
7257             <p>
7258
7259 <code>valarray();</code>
7260
7261             </p>
7262             <p>
7263
7264 <i>Effects</i>:      Constructs      an      object      of      class
7265 <code>valarray&lt;T&gt;</code>,<sup>279)</sup>    which    has    zero
7266 length<del> until it is passed into a library function as a modifiable
7267 lvalue or through a non-constant this pointer</del>.<sup>280)</sup>
7268
7269             </p>
7270             <p>
7271
7272 <ins><i>Postcondition</i>: <code>size() == 0</code>.</ins>
7273
7274             </p>
7275             <p>
7276
7277 <i>Footnote  280</i>:  This default  constructor  is essential,  since
7278 arrays  of  <code>valarray</code>  <del>are  likely to  prove  useful.
7279 There  shall also  be  a way  to change  the  size of  an array  after
7280 initialization;  this  is  supplied  by the  semantics</del>  <ins>may be
7281 useful.   The  length  of  an  empty  array  can  be  increased  after
7282 initialization  by  means</ins>  of the  <code>resize()</code>  member
7283 function.
7284
7285             </p>
7286         </blockquote>
7287
7288
7289
7290
7291
7292 <hr>
7293 <h3><a name="621"></a>621. non-const copy assignment operators of helper arrays</h3>
7294 <p><b>Section:</b> 26.5 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
7295  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
7296 <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>
7297 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
7298 <p><b>Discussion:</b></p>
7299         <p>
7300
7301 The computed and  "fill" assignment operators of <code>valarray</code>
7302 helper     array     class    templates     (<code>slice_array</code>,
7303 <code>gslice_array</code>,         <code>mask_array</code>,        and
7304 <code>indirect_array</code>) are const  member functions of each class
7305 template     (the     latter    by     the     resolution    of  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a>
7306 since  they have reference  semantics and thus do  not affect
7307 the state of  the object on which they are  called.  However, the copy
7308 assignment  operators  of  these  class  templates,  which  also  have
7309 reference semantics,  are non-const.   The absence of  constness opens
7310 the door to speculation about whether they really are intended to have
7311 reference semantics (existing implementations vary widely).
7312
7313         </p>
7314
7315 <p>
7316 Pre-Kona, Martin adds:
7317 </p>
7318
7319 <p>
7320 I realized that adding the const qualifier to the
7321 functions as I suggested would break the const correctness of the
7322 classes. A few possible solutions come to mind:
7323 </p>
7324
7325 <ol>
7326 <li>Add the const qualifier to the return types of these functions.</li>
7327 <li>Change the return type of all the functions to void to match
7328 the signatures of all the other assignment operators these classes
7329 define.</li>
7330 <li>Prohibit the copy assignment of these classes by declaring the
7331 copy assignment operators private (as is done and documented by
7332 some implementations).</li>
7333 </ol>
7334
7335
7336
7337 <p><b>Proposed resolution:</b></p>
7338         <p>
7339
7340 Declare  the  copy  assignment  operators  of all  four  helper  array
7341 class templates const.
7342
7343         </p>
7344         <p>
7345
7346 Specifically,  make the following edits:
7347
7348         </p>
7349         <p>
7350
7351 Change     the    signature     in     26.5.5 [template.slice.array]    and
7352 26.5.5.1 [slice.arr.assign] as follows:
7353
7354         </p>
7355         <blockquote><pre>
7356 <code><ins>const</ins> slice_array&amp; operator= (const slice_array&amp;)<ins> const</ins>;</code>
7357
7358         </pre></blockquote>
7359         <p>
7360
7361 Change     the     signature     in    26.5.7 [template.gslice.array]     and
7362 26.5.7.1 [gslice.array.assign] as follows:
7363
7364         </p>
7365         <blockquote><pre>
7366 <code><ins>const</ins> gslice_array&amp; operator= (const gslice_array&amp;)<ins> const</ins>;</code>
7367
7368         </pre></blockquote>
7369         <p>
7370
7371 Change the  signature in 26.5.8 [template.mask.array]  and 26.5.8.1 [mask.array.assign] as
7372 follows:
7373
7374         </p>
7375         <blockquote><pre>
7376 <code><ins>const</ins> mask_array&amp; operator= (const mask_array&amp;)<ins> const</ins>;</code>
7377
7378         </pre></blockquote>
7379         <p>
7380
7381 Change     the     signature     in    26.5.9 [template.indirect.array] and
7382 26.5.9.1 [indirect.array.assign] as follows:
7383
7384         </p>
7385         <blockquote><pre>
7386 <code><ins>const</ins> indirect_array&amp; operator= (const indirect_array&amp;)<ins> const</ins>;</code>
7387
7388         </pre></blockquote>
7389
7390
7391 <p><i>[
7392 Kona (2007) Added const qualification to the return types and set to Ready.
7393 ]</i></p>
7394
7395
7396
7397
7398
7399 <hr>
7400 <h3><a name="622"></a>622. behavior of <code>filebuf</code> dtor and <code>close</code> on error</h3>
7401 <p><b>Section:</b> 27.8.1.17 [fstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
7402  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
7403 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
7404 <p><b>Discussion:</b></p>
7405         <p>
7406
7407 <code>basic_filebuf</code>  dtor is  specified to  have  the following
7408 straightforward effects:
7409
7410         </p>
7411         <blockquote><p>
7412
7413 <i>Effects</i>:       Destroys      an      object       of      class
7414 <code>basic_filebuf</code>. Calls <code>close()</code>.
7415
7416         </p></blockquote>
7417         <p>
7418
7419 <code>close()</code> does a lot of potentially complicated processing,
7420 including calling <code>overflow()</code> to write out the termination
7421 sequence  (to   bring  the  output  sequence  to   its  initial  shift
7422 state). Since  any of the  functions called during the  processing can
7423 throw an exception, what should the  effects of an exception be on the
7424 dtor? Should the  dtor catch and swallow it or  should it propagate it
7425 to the caller?  The text doesn't  seem to provide any guidance in this
7426 regard  other  than  the  general  restriction on  throwing  (but  not
7427 propagating)  exceptions  from   destructors  of  library  classes  in
7428 17.4.4.8 [res.on.exception.handling].
7429
7430         </p>
7431         <p>
7432
7433 Further,  the last thing  <code>close()</code> is  specified to  do is
7434 call <code>fclose()</code> to close the <code>FILE</code> pointer. The
7435 last sentence of the <i>Effects</i> clause reads:
7436
7437         </p>
7438         <blockquote><p>
7439
7440 ...   If    any   of    the   calls   to    <code>overflow</code>   or
7441 <code>std::fclose</code> fails then <code>close</code> fails.
7442
7443         </p></blockquote>
7444         <p>
7445
7446 This  suggests that  <code>close()</code>  might be  required to  call
7447 <code>fclose()</code>   if  and  only   if  none   of  the   calls  to
7448 <code>overflow()</code> fails, and avoid closing the <code>FILE</code>
7449 otherwise. This  way, if  <code>overflow()</code> failed to  flush out
7450 the data, the caller  would have  the opportunity to  try to  flush it
7451 again (perhaps  after trying  to deal with  whatever problem  may have
7452 caused the failure), rather than losing it outright.
7453
7454         </p>
7455         <p>
7456
7457 On the other hand,  the function's <i>Postcondition</i> specifies that
7458 <code>is_open() ==  false</code>, which  suggests that it  should call
7459 <code>fclose()</code>       unconditionally.       However,      since
7460 <i>Postcondition</i> clauses  are specified for many  functions in the
7461 standard,  including constructors  where they  obviously  cannot apply
7462 after an  exception, it's not clear  whether this <i>Postcondition</i>
7463 clause is intended to apply even after an exception.
7464
7465         </p>
7466         <p>
7467
7468 It  might  be worth  noting  that  the  traditional behavior  (Classic
7469 Iostreams  <code>fstream::close()</code> and  C <code>fclose()</code>)
7470 is  to  close  the  <code>FILE</code> unconditionally,  regardless  of
7471 errors.
7472
7473         </p>
7474
7475 <p><i>[
7476 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">418</a> for related issues.
7477 ]</i></p>
7478
7479
7480
7481
7482 <p><b>Proposed resolution:</b></p>
7483         <p>
7484
7485 After discussing this  on the reflector (see the  thread starting with
7486 c++std-lib-17650) we propose that <code>close()</code> be clarified to
7487 match the traditional behavior, that is to close the <code>FILE</code>
7488 unconditionally,  even after  errors or  exceptions.  In  addition, we
7489 propose the dtor description be amended so as to explicitly require it
7490 to catch and swallow any exceptions thrown by <code>close()</code>.
7491
7492         </p>
7493         <p>
7494
7495 Specifically,   we   propose   to   make  the   following   edits   in
7496 27.8.1.4 [filebuf.members]:
7497
7498         </p>
7499         <blockquote>
7500             <pre>
7501 <code>basic_filebuf&lt;charT,traits&gt;* close();</code>
7502
7503             </pre>
7504             <p>
7505
7506 <i>Effects</i>:  If <code>is_open()  == false</code>,  returns  a null
7507 pointer.        If      a       put      area       exists,      calls
7508 <code>overflow(traits::eof())</code> to flush  characters. If the last
7509 virtual   member  function   called  on   <code>*this</code>  (between
7510 <code>underflow</code>,  <code>overflow</code>,  <code>seekoff</code>,
7511 and   <code>seekpos</code>)  was   <code>overflow</code>   then  calls
7512 <code>a_codecvt.unshift</code> (possibly several times) to determine a
7513 termination   sequence,    inserts   those   characters    and   calls
7514 <code>overflow(traits::eof())</code>  again.  Finally<ins>, regardless
7515 of whether  any of the preceding  calls fails or  throws an exception,
7516 the  function</ins> <del>it</del>  closes   the  file   ("as   if"  by   calling
7517 <code>std::fclose(file)</code>).<sup>334)</sup>  If any  of  the calls
7518 <ins>made    by   the    function</ins><del>to   <code>overflow</code>
7519 or</del><ins>,  including  </ins><code>std::fclose</code><ins>, </ins>
7520 fails then <code>close</code> fails<ins>  by returning a null pointer.
7521 If one of these calls throws an exception, the exception is caught and
7522 rethrown after closing the file.</ins>
7523
7524             </p>
7525         </blockquote>
7526         <p>
7527
7528 And to make the following edits in 27.8.1.2 [filebuf.cons].
7529
7530         </p>
7531         <blockquote>
7532             <pre>
7533 <code>virtual ~basic_filebuf();</code>
7534
7535             </pre>
7536             <p>
7537
7538 <i>Effects</i>:       Destroys      an      object       of      class
7539 <code>basic_filebuf&lt;charT,traits&gt;</code>.                   Calls
7540 <code>close()</code>.    <ins>If  an   exception  occurs   during  the
7541 destruction of the object, including the call to <code>close()</code>,
7542 the     exception    is     caught    but     not     rethrown    (see
7543 17.4.4.8 [res.on.exception.handling]).</ins>
7544
7545             </p>
7546         </blockquote>
7547
7548
7549
7550
7551
7552 <hr>
7553 <h3><a name="623"></a>623. <code>pubimbue</code> forbidden to call <code>imbue</code></h3>
7554 <p><b>Section:</b> 27.1.1 [iostream.limits.imbue] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
7555  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
7556 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
7557 <p><b>Discussion:</b></p>
7558         <p>
7559
7560 27.1.1 [iostream.limits.imbue]  specifies  that  "no  function  described  in
7561 clause 27 except  for <code>ios_base::imbue</code> causes any instance
7562 of                   <code>basic_ios::imbue</code>                  or
7563 <code>basic_streambuf::imbue</code> to be called."
7564
7565         </p>
7566         <p>
7567
7568 That      contradicts      the      <i>Effects</i>     clause      for
7569 <code>basic_streambuf::pubimbue()</code>  which requires  the function
7570 to do just that: call <code>basic_streambuf::imbue()</code>.
7571
7572         </p>
7573
7574
7575 <p><b>Proposed resolution:</b></p>
7576         <p>
7577
7578 To    fix   this,    rephrase    the   sentence    above   to    allow
7579 <code>pubimbue</code> to do what  it was designed to do. Specifically.
7580 change 27.1.1 [iostream.limits.imbue], p1 to read:
7581
7582         </p>
7583         <blockquote><p>
7584
7585 No     function    described     in    clause     27     except    for
7586 <code>ios_base::imbue</code>  <ins>and <code>basic_filebuf::pubimbue</code></ins>
7587 causes    any    instance    of    <code>basic_ios::imbue</code>    or
7588 <code>basic_streambuf::imbue</code> to be called. ...
7589
7590         </p></blockquote>
7591
7592
7593
7594
7595
7596 <hr>
7597 <h3><a name="624"></a>624. <code>valarray</code> assignment and arrays of unequal length</h3>
7598 <p><b>Section:</b> 26.5.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
7599  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
7600 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
7601 <p><b>Discussion:</b></p>
7602         <p>
7603
7604 The behavior of the  <code>valarray</code> copy assignment operator is
7605 defined only when both sides have  the same number of elements and the
7606 spec is explicit about assignments of arrays of unequal lengths having
7607 undefined behavior.
7608
7609         </p>
7610         <p>
7611
7612 However, the generalized  subscripting assignment operators overloaded
7613 on <code>slice_array</code>  et al (26.5.2.2 [valarray.assign])  don't have any
7614 such restriction, leading  the reader to believe that  the behavior of
7615 these  overloads is  well defined  regardless  of the  lengths of  the
7616 arguments.
7617
7618         </p>
7619         <p>
7620
7621 For example,  based on  the reading  of the spec  the behavior  of the
7622 snippet below can be expected to be well-defined:
7623
7624         </p>
7625         <pre>    const std::slice from_0_to_3 (0, 3, 1);   // refers to elements 0, 1, 2
7626     const std::valarray&lt;int&gt; a (1, 3);        // a = { 1, 1, 1 }
7627     std::valarray&lt;int&gt;       b (2, 4);        // b = { 2, 2, 2, 2 }
7628
7629     b = a [from_0_to_3];
7630         </pre>
7631         <p>
7632
7633 In practice, <code>b</code> may end up being <code>{ 1, 1, 1 }</code>,
7634 <code>{  1,  1, 1,  2  }</code>,  or  anything else,  indicating  that
7635 existing implementations vary.
7636
7637         </p>
7638
7639 <p>
7640 Quoting from Section 3.4, Assignment operators, of Al Vermeulen's
7641 Proposal for Standard C++ Array Classes (see c++std-lib-704;
7642 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>):
7643 </p>
7644 <blockquote><p>
7645   ...if the size of the array on the right hand side of the equal
7646   sign differs from the size of the array on the left, a run time
7647   error occurs. How this error is handled is implementation
7648   dependent; for compilers which support it, throwing an exception
7649   would be reasonable.
7650 </p></blockquote>
7651
7652 <p>
7653 And see more history in
7654 <a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/1993/N0280.pdf">N0280</a>.
7655 </p>
7656
7657         <p>
7658
7659 It has  been argued in  discussions on the committee's  reflector that
7660 the semantics of all <code>valarray</code> assignment operators should
7661 be permitted to be undefined unless  the  length  of the arrays  being
7662 assigned is the same as the length of the one being assigned from. See
7663 the thread starting at c++std-lib-17786.
7664
7665         </p>
7666         <p>
7667
7668 In order  to reflect  such views, the  standard must specify  that the
7669 size of the  array referred to by the argument  of the assignment must
7670 match the size of the array  under assignment, for example by adding a
7671 <i>Requires</i> clause to 26.5.2.2 [valarray.assign] as follows:
7672
7673         </p>
7674         <blockquote><p>
7675
7676 <i>Requires</i>: The length of the  array to which the argument refers
7677 equals <code>size()</code>.
7678
7679         </p></blockquote>
7680
7681         <p>
7682
7683 Note that it's  far from clear that such leeway  is necessary in order
7684 to implement <code>valarray</code> efficiently.
7685
7686         </p>
7687
7688
7689 <p><b>Proposed resolution:</b></p>
7690 <p>
7691 Insert new paragraph into 26.5.2.2 [valarray.assign]:
7692 </p>
7693
7694 <blockquote>
7695 <pre>valarray&lt;T&gt;&amp; operator=(const slice_array&lt;T&gt;&amp;);
7696 valarray&lt;T&gt;&amp; operator=(const gslice_array&lt;T&gt;&amp;);
7697 valarray&lt;T&gt;&amp; operator=(const mask_array&lt;T&gt;&amp;);
7698 valarray&lt;T&gt;&amp; operator=(const indirect_array&lt;T&gt;&amp;);
7699 </pre>
7700 <blockquote>
7701 <p><ins>
7702 <i>Requires</i>: The length of the  array to which the argument refers
7703 equals <code>size()</code>.
7704 </ins></p>
7705 <p>
7706 These operators allow the results of a generalized subscripting operation to be assigned directly to a <tt>valarray</tt>.
7707 </p>
7708 </blockquote>
7709 </blockquote>
7710
7711
7712
7713
7714
7715 <hr>
7716 <h3><a name="625"></a>625. mixed up <i>Effects</i> and <i>Returns</i> clauses</h3>
7717 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
7718  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
7719 <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>
7720 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7721 <p><b>Discussion:</b></p>
7722         <p>
7723
7724 Many  member functions  of  <code>basic_string</code> are  overloaded,
7725 with  some of  the  overloads taking  a <code>string</code>  argument,
7726 others  <code>value_type*</code>,  others <code>size_type</code>,  and
7727 others still <code>iterators</code>. Often, the requirements on one of
7728 the   overloads  are   expressed  in   the  form   of  <i>Effects</i>,
7729 <i>Throws</i>,      and     in      the     Working      Paper
7730 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
7731 also <i>Remark</i> clauses,  while those on the rest  of the overloads
7732 via a reference to this overload and using a <i>Returns</i> clause.
7733
7734         </p><p>
7735         </p>
7736
7737 The  difference between  the two  forms of  specification is  that per
7738 17.3.1.3 [structure.specifications],  p3,  an  <i>Effects</i> clause  specifies
7739 <i>"actions  performed  by the  functions,"</i>  i.e., its  observable
7740 effects,  while a <i>Returns</i>  clause is  <i>"a description  of the
7741 return  value(s)   of  a  function"</i>  that  does   not  impose  any
7742 requirements on the function's observable effects.
7743
7744         <p>
7745         </p>
7746
7747 Since only  <i>Notes</i> are explicitly defined to  be informative and
7748 all  other paragraphs  are explicitly  defined to  be  normative, like
7749 <i>Effects</i> and <i>Returns</i>,  the new <i>Remark</i> clauses also
7750 impose normative requirements.
7751
7752         <p>
7753         </p>
7754
7755 So  by this  strict  reading of  the  standard there  are some  member
7756 functions of  <code>basic_string</code> that are required  to throw an
7757 exception under  some conditions or use specific  traits members while
7758 many other otherwise equivalent overloads, while obliged to return the
7759 same  values, aren't required  to follow  the exact  same requirements
7760 with regards to the observable effects.
7761
7762         <p>
7763         </p>
7764
7765 Here's an example of this  problem that was precipitated by the change
7766 from informative Notes to normative <i>Remark</i>s (presumably made to
7767 address <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>):
7768
7769         <p>
7770         </p>
7771
7772 In the Working  Paper, <code>find(string, size_type)</code> contains a
7773 <i>Remark</i>  clause (which  is  just a  <i>Note</i>  in the  current
7774 standard) requiring it to use <code>traits::eq()</code>.
7775
7776         <p>
7777         </p>
7778
7779 <code>find(const  charT  *s,  size_type  pos)</code> is  specified  to
7780 return  <code>find(string(s), pos)</code>  by a  <i>Returns</i> clause
7781 and so  it is not required to  use <code>traits::eq()</code>. However,
7782 the Working  Paper has  replaced the original  informative <i>Note</i>
7783 about   the  function   using  <code>traits::length()</code>   with  a
7784 normative  requirement  in  the   form  of  a  <i>Remark</i>.  Calling
7785 <code>traits::length()</code> may be  suboptimal, for example when the
7786 argument is a  very long array whose initial  substring doesn't appear
7787 anywhere in <code>*this</code>.
7788
7789         <p>
7790         </p>
7791
7792 Here's another  similar example,  one that existed  even prior  to the
7793 introduction of <i>Remark</i>s:
7794
7795         <p>
7796         </p>
7797
7798 <code> insert(size_type  pos, string, size_type,  size_type)</code> is
7799 required   to   throw   <code>out_of_range</code>   if   <code>pos   &gt;
7800 size()</code>.
7801
7802         <p>
7803         </p>
7804
7805 <code>insert(size_type pos, string  str)</code> is specified to return
7806 <code>insert(pos, str, 0, npos)</code>  by a <i>Returns</i> clause and
7807 so its  effects when <code>pos  &gt; size()</code> are  strictly speaking
7808 unspecified.
7809
7810
7811         <p>
7812
7813 I  believe  a  careful   review  of  the  current  <i>Effects</i>  and
7814 <i>Returns</i>  clauses  is  needed  in  order to  identify  all  such
7815 problematic cases. In  addition, a review of the  Working Paper should
7816 be done to make sure that the newly introduced normative <i>Remark</i>
7817 clauses do not impose  any undesirable normative requirements in place
7818 of the original informative <i>Notes</i>.
7819
7820         </p>
7821 <p><i>[
7822 Batavia:  Alan and Pete to work.
7823 ]</i></p>
7824
7825
7826
7827 <p><b>Proposed resolution:</b></p>
7828 <p>
7829 </p>
7830
7831
7832
7833
7834
7835 <hr>
7836 <h3><a name="626"></a>626. new <i>Remark</i> clauses not documented</h3>
7837 <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#Open">Open</a>
7838  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
7839 <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>
7840 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7841 <p><b>Discussion:</b></p>
7842         <p>
7843
7844 The <i>Remark</i> clauses newly  introduced into the Working Paper
7845 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
7846 are  not mentioned  in  17.3.1.3 [structure.specifications] where  we list  the
7847 meaning  of <i>Effects</i>, <i>Requires</i>,  and other  clauses (with
7848 the exception  of <i>Notes</i> which are documented  as informative in
7849 17.3.1.1 [structure.summary], p2, and which they replace in many cases).
7850
7851         </p>
7852         <p>
7853
7854 Propose add a bullet for <i>Remarks</i> along with a brief description.
7855
7856         </p>
7857 <p><i>[
7858 Batavia:  Alan and Pete to work.
7859 ]</i></p>
7860
7861
7862
7863 <p><b>Proposed resolution:</b></p>
7864 <p>
7865 </p>
7866
7867
7868
7869
7870
7871 <hr>
7872 <h3><a name="627"></a>627. Low memory and exceptions</h3>
7873 <p><b>Section:</b> 18.5.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
7874  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-01-23</p>
7875 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p>
7876 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7877 <p><b>Discussion:</b></p>
7878 <p>
7879 I recognize the need for nothrow guarantees in the exception reporting
7880 mechanism, but I strongly believe that implementors also need an escape hatch
7881 when memory gets really low. (Like, there's not enough heap to construct and
7882 copy exception objects, or not enough stack to process the throw.) I'd like to
7883 think we can put this escape hatch in 18.5.1.1 [new.delete.single],
7884 <tt>operator new</tt>, but I'm not sure how to do it. We need more than a
7885 footnote, but the wording has to be a bit vague. The idea is that if
7886 <tt>new</tt> can't allocate something sufficiently small, it has the right to
7887 <tt>abort</tt>/call <tt>terminate</tt>/call <tt>unexpected</tt>.
7888 </p>
7889
7890
7891 <p><b>Proposed resolution:</b></p>
7892 <p>
7893 </p>
7894
7895
7896
7897
7898
7899 <hr>
7900 <h3><a name="629"></a>629. complex<t> insertion and locale dependence</t></h3>
7901 <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#Open">Open</a>
7902  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-28</p>
7903 <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>
7904 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7905 <p><b>Discussion:</b></p>
7906 <p>
7907 is there an issue opened for (0,3) as complex number with
7908 the French local?  With the English local, the above parses as an
7909 imaginery complex number.  With the French locale it parses as a
7910 real complex number.
7911 </p>
7912
7913 <p>
7914 Further notes/ideas from the lib-reflector, messages 17982-17984:
7915 </p>
7916
7917 <blockquote>
7918 <p>
7919 Add additional entries in num_punct to cover the complex separator (French would be ';').
7920 </p>
7921 <p>
7922 Insert a space before the comma, which should eliminate the ambiguity.
7923 </p>
7924 <p>
7925 Solve the problem for ordered sequences in general, perhaps with a
7926 dedicated facet.  Then complex should use that solution.
7927 </p>
7928 </blockquote>
7929
7930
7931
7932 <p><b>Proposed resolution:</b></p>
7933 <p>
7934 </p>
7935
7936
7937
7938
7939
7940 <hr>
7941 <h3><a name="630"></a>630. arrays of valarray</h3>
7942 <p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
7943  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-28</p>
7944 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p>
7945 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
7946 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7947 <p><b>Discussion:</b></p>
7948         <p>
7949
7950 Section 26.1 [numeric.requirements], p1     suggests     that     a
7951 <code>valarray</code>  specialization on  a  type <code>T</code>  that
7952 satisfies  the requirements enumerated  in the  paragraph is  itself a
7953 valid  type   on  which  <code>valarray</code>   may  be  instantiated
7954 (Footnote       269        makes       this       clear).        I.e.,
7955 <code>valarray&lt;valarray&lt;T&gt;  &gt;</code> is  valid as  long as
7956 <code>T</code>   is   valid.    However,  since   implementations   of
7957 <code>valarray</code> are permitted to initialize storage allocated by
7958 the class by  invoking the default ctor of  <code>T</code> followed by
7959 the    copy    assignment    operator,   such    implementations    of
7960 <code>valarray</code>   wouldn't  work  with   (perhaps  user-defined)
7961 specializations of <code>valarray</code> whose assignment operator had
7962 undefined behavior when the size of its argument didn't match the size
7963 of <code>*this</code>.  By <i>"wouldn't work"</i> I mean that it would
7964 be  impossible  to resize  such  an array  of  arrays  by calling  the
7965 <code>resize()</code> member  function on it if the  function used the
7966 copy  assignment operator  after constructing  all elements  using the
7967 default  ctor (e.g.,  by invoking  <code>new  value_type[N]</code>) to
7968 obtain default-initialized storage) as it's permitted to do.
7969
7970         </p>
7971         <p>
7972
7973 Stated      more     generally,      the      problem     is      that
7974 <code>valarray&lt;valarray&lt;T&gt;  &gt;::resize(size_t)</code> isn't
7975 required or  guaranteed to have well-defined semantics  for every type
7976 <code>T</code>     that      satisfies     all     requirements     in
7977 26.1 [numeric.requirements].
7978
7979         </p>
7980         <p>
7981
7982 I  believe  this  problem  was  introduced  by  the  adoption  of  the
7983 resolution                outlined                in                <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0857.asc">N0857</a>,
7984 <i>Assignment  of  valarrays</i>,  from  1996.   The  copy  assignment
7985 operator  of  the original  numerical  array  classes  proposed in  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0280.pdf">N0280</a>,
7986 as      well       as      the      one       proposed      in      <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>
7987 (both  from 1993), had  well-defined semantics  for arrays  of unequal
7988 size (the  latter explicitly  only when <code>*this</code>  was empty;
7989 assignment of non empty arrays of unequal size was a runtime error).
7990
7991         </p>
7992         <p>
7993
7994 The  justification for  the  change given  in  N0857 was the "loss  of
7995 performance [deemed]  only significant  for very simple  operations on
7996 small arrays or for architectures with very few registers."
7997
7998         </p>
7999         <p>
8000
8001 Since tiny  arrays on a  limited subset of hardware  architectures are
8002 likely  to  be  an   exceedingly  rare  case  (despite  the  continued
8003 popularity of  x86) I  propose to revert  the resolution and  make the
8004 behavior    of   all   <code>valarray</code>    assignment   operators
8005 well-defined even  for non-conformal  arrays (i.e., arrays  of unequal
8006 size).   I have implemented  this change  and measured  no significant
8007 degradation  in performance in  the common  case (non-empty  arrays of
8008 equal size).  I  have measured a 50% (and in  some cases even greater)
8009 speedup  in the  case of  assignments to  empty arrays  versus calling
8010 <code>resize()</code>  first followed  by  an invocation  of the  copy
8011 assignment operator.
8012
8013         </p>
8014
8015
8016 <p><b>Proposed resolution:</b></p>
8017         <p>
8018
8019 Change 26.5.2.2 [valarray.assign], p1 as follows:
8020
8021         </p>
8022         <blockquote>
8023             <p>
8024                 <code>
8025
8026 valarray&lt;T&gt;&amp; operator=(const valarray&lt;T&gt;&amp;<ins> x</ins>);
8027
8028                 </code>
8029             </p>
8030             <p>
8031
8032 -1- Each element of the <code>*this</code> array is assigned the value
8033 of  the  corresponding  element   of  the  argument  array.   <del>The
8034 resulting behavior is undefined if </del><ins>When </ins>the length of
8035 the  argument  array  is  not   equal  to  the  length  of  the  *this
8036 array<del>.</del><ins>  resizes  <code>*this</code>  to make  the  two
8037 arrays     the      same     length,     as      if     by     calling
8038 <code>resize(x.size())</code>, before performing the assignment.</ins>
8039
8040             </p>
8041         </blockquote>
8042         <p>
8043
8044 And  add a new  paragraph just  below paragraph  1 with  the following
8045 text:
8046
8047         </p>
8048         <blockquote>
8049             <p>
8050
8051 <ins>-2- <i>Postcondition</i>: <code>size() == x.size()</code>.</ins>
8052
8053             </p>
8054         </blockquote>
8055         <p>
8056
8057 Also add the following paragraph to 26.5.2.2 [valarray.assign], immediately after p4:
8058
8059         </p>
8060         <blockquote>
8061             <p>
8062
8063 <ins>-?- When the length,  <i><code>N</code></i> of the array referred
8064 to by the  argument is not equal to  the length of <code>*this</code>,
8065 the  operator resizes <code>*this</code>  to make  the two  arrays the
8066 same  length, as if  by calling  <code>resize(<i>N</i>)</code>, before
8067 performing the assignment.</ins>
8068
8069             </p>
8070         </blockquote>
8071
8072
8073 <p><i>[
8074 Kona (2007): Gaby to propose wording for an alternative resolution in
8075 which you can assign to a <tt>valarray</tt> of size 0, but not to any other
8076 <tt>valarray</tt> whose size is unequal to the right hand side of the assignment.
8077 ]</i></p>
8078
8079
8080
8081
8082
8083 <hr>
8084 <h3><a name="631"></a>631. conflicting requirements for <tt>BinaryPredicate</tt></h3>
8085 <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8086  <b>Submitter:</b> James Kanze <b>Date:</b> 2007-01-31</p>
8087 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
8088 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8089 <p><b>Discussion:</b></p>
8090 <p>
8091 The general requirements for <tt><tt>BinaryPredicate</tt></tt> (in 25 [algorithms]/8) contradict the implied specific requirements for
8092 some functions. In particular, it says that:
8093 </p>
8094
8095 <blockquote><p>
8096 [...] if an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt>
8097 as its argument and <tt><i>first1</i></tt> and <i>first2</i> as its
8098 iterator arguments, it should work correctly in the construct <tt>if
8099 (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt>.
8100 <tt>BinaryPredicate</tt> always takes the first iterator type as its
8101 first argument, that is, in those cases when <tt>T <i>value</i></tt> is
8102 part of the signature, it should work correctly in the context of <tt>if
8103 (binary_pred (*<i>first1</i> , <i>value</i>)){...}</tt>.
8104 </p></blockquote>
8105
8106 <p>
8107 In the description of <tt>upper_bound</tt> (25.3.3.2 [upper.bound]/2), however, the use is described as
8108 "<tt>!comp(<i>value</i>, <i>e</i>)</tt>", where <tt><i>e</i></tt> is an
8109 element of the sequence (a result of dereferencing
8110 <tt>*<i>first</i></tt>).
8111 </p>
8112
8113 <p>
8114 In the description of <tt>lexicographical_compare</tt>, we have both
8115 "<tt>*<i>first1</i> &lt; *<i>first2</i></tt>" and "<tt>*<i>first2</i>
8116 &lt; *<i>first1</i></tt>" (which presumably implies "<tt>comp(
8117 *<i>first1</i>, *<i>first2</i> )</tt>" and "<tt>comp( *<i>first2</i>,
8118 *<i>first1</i> )</tt>".
8119 </p>
8120
8121 <p><i>[
8122 Toronto:  Moved to Open.  ConceptGCC seems to get <tt>lower_bound</tt>
8123 and <tt>upper_bound</tt> to work withoutt these changes.
8124 ]</i></p>
8125
8126
8127
8128
8129 <p><b>Proposed resolution:</b></p>
8130 <p>
8131 Logically, the <tt>BinaryPredicate</tt> is used as an ordering
8132 relationship, with the semantics of "less than".  Depending on the
8133 function, it may be used to determine equality, or any of the inequality
8134 relationships; doing this requires being able to use it with either
8135 parameter first.  I would thus suggest that the requirement be:
8136 </p>
8137
8138 <blockquote><p>
8139 [...] <tt>BinaryPredicate</tt> always takes the first iterator
8140 <tt>value_type</tt> as one of its arguments, it is unspecified which. If
8141 an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt> as its
8142 argument and <tt><i><i>first1</i></i></tt> and <i>first2</i> as its
8143 iterator arguments, it should work correctly both in the construct
8144 <tt>if (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt> and
8145 <tt>if (binary_pred (*<i>first2</i>, *<i>first1</i>)){...}</tt>.  In
8146 those cases when <tt>T <i>value</i></tt> is part of the signature, it
8147 should work correctly in the context of <tt>if (binary_pred
8148 (*<i>first1</i> , <i>value</i>)){...}</tt> and of <tt>if (binary_pred
8149 (<i>value</i>, *<i>first1</i>)){...}</tt>. [<i>Note:</i> if the two
8150 types are not identical, and neither is convertable to the other, this
8151 may require that the <tt>BinaryPredicate</tt> be a functional object
8152 with two overloaded <tt>operator()()</tt> functions. <i>--end note</i>]
8153 </p></blockquote>
8154
8155 <p>
8156 Alternatively, one could specify an order for each function. IMHO, this
8157 would be more work for the committee, more work for the implementors,
8158 and of no real advantage for the user: some functions, such as
8159 <tt>lexicographical_compare</tt> or <tt>equal_range</tt>, will still require both
8160 functions, and it seems like a much easier rule to teach that both
8161 functions are always required, rather than to have a complicated list of
8162 when you only need one, and which one.
8163 </p>
8164
8165
8166
8167
8168
8169 <hr>
8170 <h3><a name="632"></a>632. Time complexity of size() for std::set</h3>
8171 <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#Open">Open</a>
8172  <b>Submitter:</b> Lionel B <b>Date:</b> 2007-02-01</p>
8173 <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>
8174 <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>
8175 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8176 <p><b>Discussion:</b></p>
8177 <p>
8178 A recent news group discussion:
8179 </p>
8180 <blockquote>
8181 <p>
8182 Anyone know if the Standard has anything to say about the time complexity
8183 of size() for std::set?   I need to access a set's size (/not/ to know if it is empty!) heavily
8184 during an algorithm and was thus wondering whether I'd be better off
8185 tracking the size "manually" or whether that'd be pointless.
8186 </p>
8187 <p>
8188 That would be pointless. size() is O(1).
8189 </p>
8190 <p>
8191 Nit: the standard says "should" have constant time. Implementations may take
8192 license to do worse. I know that some do this for <tt>std::list&lt;&gt;</tt> as a part of
8193 some trade-off with other operation.
8194 </p>
8195
8196 <p>
8197 I was aware of that, hence my reluctance to use size() for std::set.
8198 </p>
8199 <p>
8200 However, this reason would not apply to <tt>std::set&lt;&gt;</tt> as far as I can see.
8201 </p>
8202 <p>
8203 Ok, I guess the only option is to try it and see...
8204 </p>
8205 </blockquote>
8206
8207 <p>
8208 If I have any recommendation to the C++ Standards Committee it is that
8209 implementations must (not "should"!) document clearly[1], where known, the
8210 time complexity of *all* container access operations.
8211 </p>
8212 <p>
8213 [1] In my case (gcc 4.1.1) I can't swear that the time complexity of size()
8214 for std::set is not documented... but if it is it's certainly well hidden
8215 away.
8216 </p>
8217
8218
8219 <p><b>Proposed resolution:</b></p>
8220 <p>
8221 </p>
8222
8223
8224 <p><i>[
8225 Kona (2007): This issue affects all the containers. We'd love to see a
8226 paper dealing with the broad issue. We think that the complexity of the
8227 <tt>size()</tt> member of every container -- except possibly <tt>list</tt> -- should be
8228 O(1). Alan has volunteered to provide wording.
8229 ]</i></p>
8230
8231
8232
8233
8234
8235 <hr>
8236 <h3><a name="635"></a>635. domain of <tt>allocator::address</tt></h3>
8237 <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#Open">Open</a>
8238  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-02-08</p>
8239 <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>
8240 <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>
8241 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8242 <p><b>Discussion:</b></p>
8243 <p>
8244 The table of allocator requirements in 20.1.2 [allocator.requirements] describes
8245 <tt>allocator::address</tt> as:
8246 </p>
8247 <blockquote><pre>a.address(r)
8248 a.address(s)
8249 </pre></blockquote>
8250 <p>
8251 where <tt>r</tt> and <tt>s</tt> are described as:
8252 </p>
8253 <blockquote><p>
8254 a value of type <tt>X::reference</tt> obtained by the expression <tt>*p</tt>.
8255 </p></blockquote>
8256
8257 <p>
8258 and <tt>p</tt> is
8259 </p>
8260
8261 <blockquote><p>
8262 a value of type <tt>X::pointer</tt>, obtained by calling <tt>a1.allocate</tt>,
8263 where <tt>a1 == a</tt>
8264 </p></blockquote>
8265
8266 <p>
8267 This all implies that to get the address of some value of type <tt>T</tt> that
8268 value must have been allocated by this allocator or a copy of it.
8269 </p>
8270
8271 <p>
8272 However sometimes container code needs to compare the address of an external value of
8273 type <tt>T</tt> with an internal value.  For example <tt>list::remove(const T&amp; t)</tt>
8274 may want to compare the address of the external value <tt>t</tt> with that of a value
8275 stored within the list.  Similarly <tt>vector</tt> or <tt>deque insert</tt> may
8276 want to make similar comparisons (to check for self-referencing calls).
8277 </p>
8278
8279 <p>
8280 Mandating that <tt>allocator::address</tt> can only be called for values which the
8281 allocator allocated seems overly restrictive.
8282 </p>
8283
8284
8285
8286 <p><b>Proposed resolution:</b></p>
8287 <p>
8288 Change 20.1.2 [allocator.requirements]:
8289 </p>
8290
8291 <blockquote>
8292 <p>
8293 <tt>r</tt> : a value of type <tt>X::reference</tt> <del>obtained by the expression *p</del>.
8294 </p>
8295 <p>
8296 <tt>s</tt> : a value of type <tt>X::const_reference</tt> <del>obtained by the
8297 expression <tt>*q</tt> or by conversion from a value <tt>r</tt></del>.
8298 </p>
8299 </blockquote>
8300
8301 <p><i>[
8302 post Oxford:  This would be rendered NAD Editorial by acceptance of
8303 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
8304 ]</i></p>
8305
8306
8307 <p><i>[
8308 Kona (2007):  This issue is section 8 of N2387.  There was some discussion of it but
8309 no resolution to this issue was recorded.  Moved to Open.
8310 ]</i></p>
8311
8312
8313
8314
8315
8316
8317
8318 <hr>
8319 <h3><a name="638"></a>638. deque end invalidation during erase</h3>
8320 <p><b>Section:</b> 23.2.2.3 [deque.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
8321  <b>Submitter:</b> Steve LoBasso <b>Date:</b> 2007-02-17</p>
8322 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
8323 <p><b>Discussion:</b></p>
8324 <p>
8325 The standard states at 23.2.2.3 [deque.modifiers]/4:
8326 </p>
8327 <blockquote><pre>deque erase(...)
8328 </pre>
8329  <p>
8330 <i>Effects:</i> ... An erase at either end of the deque invalidates only
8331 the iterators and the references to the erased elements.
8332 </p>
8333 </blockquote>
8334 <p>
8335 This does not state that iterators to end will be invalidated.
8336 It needs to be amended in such a way as to account for end invalidation.
8337 </p>
8338 <p>
8339 Something like:
8340 </p>
8341 <blockquote><p>
8342 Any time the last element is erased, iterators to end are invalidated.
8343 </p></blockquote>
8344
8345 <p>
8346 This would handle situations like:
8347 </p>
8348 <blockquote><pre>erase(begin(), end())
8349 erase(end() - 1)
8350 pop_back()
8351 resize(n, ...) where n &lt; size()
8352 pop_front() with size() == 1
8353
8354 </pre></blockquote>
8355
8356
8357
8358 <p><b>Proposed resolution:</b></p>
8359 <p>
8360 Change 23.2.2.3 [deque.modifiers], p4:
8361 </p>
8362
8363 <blockquote>
8364 <pre>iterator erase(const_iterator position);
8365 iterator erase(const_iterator first, const_iterator last);
8366 </pre>
8367
8368 <blockquote>
8369 <p>
8370 -4- <i>Effects:</i> An erase in the middle of the <tt>deque</tt>
8371 invalidates all the iterators and references to elements of the
8372 <tt>deque</tt> <ins>and the past-the-end iterator</ins>. An erase at
8373 either end of the <tt>deque</tt> invalidates only the iterators and the
8374 references to the erased elements<ins>, except that erasing at the end
8375 also invalidates the past-the-end iterator</ins>.
8376 </p>
8377 </blockquote>
8378 </blockquote>
8379
8380
8381
8382 <p><i>[
8383 Kona (2007): Proposed wording added and moved to Review.
8384 ]</i></p>
8385
8386
8387
8388
8389
8390 <hr>
8391 <h3><a name="645"></a>645. Missing members in match_results</h3>
8392 <p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
8393  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p>
8394 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.results">active issues</a> in [re.results].</p>
8395 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p>
8396 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
8397 <p><b>Discussion:</b></p>
8398 <p>
8399 According to the description given in 28.10 [re.results]/2 the class template
8400 match_results "shall satisfy the requirements of a Sequence, [..],
8401 except that only operations defined for const-qualified Sequences
8402 are supported".
8403 Comparing the provided operations from 28.10 [re.results]/3 with the
8404 sequence/container tables 80 and 81 one recognizes the following
8405 missing operations:
8406 </p>
8407
8408 <p>
8409 1) The members
8410 </p>
8411
8412 <blockquote><pre>const_iterator rbegin() const;
8413 const_iterator rend() const;
8414 </pre></blockquote>
8415
8416 <p>
8417 should exists because 23.1/10 demands these for containers
8418 (all sequences are containers) which support bidirectional
8419 iterators. Aren't these supported by match_result? This is not
8420 explicitely expressed, but it's somewhat implied by two arguments:
8421 </p>
8422 <p>
8423 (a) Several typedefs delegate to
8424 <tt>iterator_traits&lt;BidirectionalIterator&gt;</tt>.
8425 </p>
8426 <p>
8427 (b) The existence of <tt>const_reference operator[](size_type n) const</tt>
8428 implies even random-access iteration.
8429 I also suggest, that <tt>match_result</tt> should explicitly mention,
8430 which minimum iterator category is supported and if this does
8431 not include random-access the existence of <tt>operator[]</tt> is
8432 somewhat questionable.
8433 </p>
8434 <p>
8435 2) The new "convenience" members
8436 </p>
8437 <blockquote><pre>const_iterator cbegin() const;
8438 const_iterator cend() const;
8439 const_iterator crbegin() const;
8440 const_iterator crend() const;
8441 </pre></blockquote>
8442 <p>
8443 should be added according to tables 80/81.
8444 </p>
8445
8446
8447 <p><b>Proposed resolution:</b></p>
8448 <p>
8449 Add the following members to the <tt>match_results</tt> synopsis after <tt>end()</tt> in 28.10 [re.results]
8450 para 3:
8451 </p>
8452
8453 <blockquote><pre>const_iterator cbegin() const;
8454 const_iterator cend() const;
8455 </pre></blockquote>
8456
8457 <p>
8458 In section 28.10.3 [re.results.acc] change:
8459 </p>
8460
8461 <blockquote>
8462 <pre>const_iterator begin() const;
8463 <ins>const_iterator cbegin() const;</ins>
8464 </pre>
8465 <blockquote>
8466 <p>
8467 -7- <i>Returns:</i> A starting iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
8468 </p>
8469 </blockquote>
8470
8471 <pre>const_iterator end() const;
8472 <ins>const_iterator cend() const;</ins>
8473 </pre>
8474 <blockquote>
8475 <p>
8476 -8- <i>Returns:</i> A terminating iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
8477 </p>
8478 </blockquote>
8479 </blockquote>
8480
8481
8482
8483 <p><i>[
8484 Kona (2007): Voted to adopt proposed wording in
8485 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>
8486 except removing the entry in the table container requirements.  Moved to Review.
8487 ]</i></p>
8488
8489
8490
8491
8492
8493 <hr>
8494 <h3><a name="653"></a>653. Library reserved names</h3>
8495 <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#Open">Open</a>
8496  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-03-08</p>
8497 <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>
8498 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8499 <p><b>Discussion:</b></p>
8500 <p>
8501 </p>
8502 <blockquote>
8503 <p>
8504 1.2 [intro.refs] Normative references
8505 </p>
8506
8507 <p>
8508 The following standards contain provisions which, through reference in
8509 this text, constitute provisions of this Interna- tional Standard. At
8510 the time of publication, the editions indicated were valid. All
8511 standards are subject to revision, and parties to agreements based on
8512 this International Standard are encouraged to investigate the
8513 possibility of applying the most recent editions of the standards
8514 indicated below. Members of IEC and ISO maintain registers of currently
8515 valid International Standards.
8516 </p>
8517
8518 <ul>
8519 <li>Ecma International, ECMAScript Language Specification, Standard
8520 Ecma-262, third edition, 1999.</li>
8521 <li>ISO/IEC 2382 (all parts), Information technology - Vocabulary</li>
8522 <li>ISO/IEC 9899:1990, Programming languages - C</li>
8523 <li>ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: C
8524 Integrity</li>
8525 <li>ISO/IEC 9899:1999, Programming languages - C</li>
8526 <li>ISO/IEC 9899:1999/Cor.1:2001 Programming languages - C</li>
8527 <li>ISO/IEC 9899:1999/Cor.2:2004 Programming languages - C</li>
8528 <li>ISO/IEC 9945:2003, Information Technology-Portable Operating System
8529 Interface (POSIX)</li>
8530 <li>ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet
8531 Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual
8532 Plane</li>
8533 </ul>
8534 </blockquote>
8535
8536 <p>
8537 I'm not sure how many of those reserve naming patterns that might affect
8538 us, but I am equally sure I don't own a copy of any of these to check!
8539 </p>
8540 <p>
8541 The point is to list the reserved naming patterns, rather than the
8542 individual names themselves - although we may want to list C keywords
8543 that are valid identifiers in C++ but likely to cause trouble in shared
8544 headers (e.g. restrict)
8545 </p>
8546
8547 <p><i>[
8548 Kona (2007): Recommend NAD.  No one has identified a specific defect, just the possibility of one.
8549 ]</i></p>
8550
8551
8552 <p><i>[
8553 Post-Kona: Alisdair request Open. A good example of the problem was a
8554 discussion of the system error proposal, where it was pointed out an all-caps
8555 identifier starting with a capital E conflicted with reserved macro names for
8556 both Posix and C.  I had absolutely no idea of this rule, and suspect I was
8557 not the only one in the room.<br>
8558 <br>
8559 Resolution will require someone with access to all the listed documents to
8560 research their respective name reservation rules, or people with access to
8561 specific documents add their rules to this issue until the list is complete.
8562 ]</i></p>
8563
8564
8565
8566
8567 <p><b>Proposed resolution:</b></p>
8568
8569
8570
8571
8572
8573 <hr>
8574 <h3><a name="659"></a>659. istreambuf_iterator should have an operator-&gt;()</h3>
8575 <p><b>Section:</b> 24.5.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8576  <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-03-25</p>
8577 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p>
8578 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8579 <p><b>Discussion:</b></p>
8580 <p>
8581 Greg Herlihy has clearly demonstrated that a user defined input
8582 iterator should have an operator-&gt;(), even if its
8583 value type is a built-in type (comp.std.c++, "Re: Should any iterator
8584 have an operator-&gt;() in C++0x?", March 2007). &nbsp;And as Howard
8585 Hinnant remarked in the same thread that the input iterator
8586 <tt>istreambuf_iterator</tt> doesn't have one, this must be a
8587 defect!
8588 </p>
8589 <p>
8590 Based on Greg's example, the following code demonstrates the issue:
8591 </p><pre>&nbsp;#include &lt;iostream&gt;
8592 &nbsp;#include &lt;fstream&gt;
8593 &nbsp;#include &lt;streambuf&gt;
8594
8595 &nbsp;typedef char C;
8596 &nbsp;int main ()
8597 &nbsp;{
8598 &nbsp;&nbsp;&nbsp;std::ifstream s("filename", std::ios::in);
8599 &nbsp;&nbsp;&nbsp;std::istreambuf_iterator&lt;char&gt; i(s);
8600
8601 &nbsp;&nbsp;&nbsp;(*i).~C(); &nbsp;// This is well-formed...
8602 &nbsp;&nbsp;&nbsp;i-&gt;~C(); &nbsp;// ... so this should be supported!
8603 &nbsp;}
8604 </pre>
8605
8606 <p>
8607 Of course, operator-&gt; is also needed when the value_type of
8608 istreambuf_iterator is a class.
8609 </p>
8610 <p>
8611 The operator-&gt; could be implemented in various ways. &nbsp;For instance,
8612 by storing the current value inside the iterator, and returning its
8613 address. &nbsp;Or by returning a proxy, like operator_arrow_proxy, from
8614 <a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a>
8615 </p>
8616 <p>
8617 I hope that the resolution of this issue will contribute to getting a
8618 clear and consistent definition of iterator concepts.
8619 </p>
8620
8621
8622 <p><b>Proposed resolution:</b></p>
8623 <p>
8624 Add to the synopsis in 24.5.3 [istreambuf.iterator]:
8625 </p>
8626
8627 <blockquote><pre>charT operator*() const;
8628 <ins>pointer operator-&gt;() const;</ins>
8629 istreambuf_iterator&lt;charT,traits&gt;&amp; operator++();
8630 </pre></blockquote>
8631
8632 <p>
8633 Change 24.5.3 [istreambuf.iterator], p1:
8634 </p>
8635
8636 <blockquote><p>
8637 The class template <tt>istreambuf_iterator</tt> reads successive
8638 characters from the <tt>streambuf</tt> for which it was constructed.
8639 <tt>operator*</tt> provides access to the current input character, if
8640 any. <ins><tt>operator-&gt;</tt> may return a proxy.</ins> Each time
8641 <tt>operator++</tt> is evaluated, the iterator advances to the next
8642 input character. If the end of stream is reached
8643 (<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the
8644 iterator becomes equal to the end of stream iterator value. The default
8645 constructor <tt>istreambuf_iterator()</tt> and the constructor
8646 <tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator
8647 object suitable for use as an end-of-range.
8648 </p></blockquote>
8649
8650
8651
8652 <p><i>[
8653 Kona (2007): The proposed resolution is inconsistent because the return
8654 type of <tt>istreambuf_iterator::operator-&gt;()</tt> is specified to be <tt>pointer</tt>,
8655 but the proposed text also states that "<tt>operator-&gt;</tt> may return a proxy."
8656 ]</i></p>
8657
8658
8659 <p><i>[
8660 Niels Dekker (mailed to Howard Hinnant):
8661 ]</i></p>
8662
8663 <blockquote>
8664 <p>
8665 The proposed resolution does
8666 not seem inconsistent to me. <tt>istreambuf_iterator::operator-&gt;()</tt> should
8667 have <tt>istreambuf_iterator::pointer</tt> as return type, and this return type
8668 may in fact be a proxy.
8669 </p>
8670 <p>
8671 AFAIK, the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a> ("<tt>iterator_traits::reference</tt>
8672 unspecified for some iterator categories") implies that for any iterator
8673 class <tt>Iter</tt>, the return type of <tt>operator-&gt;()</tt> is <tt>Iter::pointer</tt>, by
8674 definition. &nbsp;I don't think <tt>Iter::pointer</tt> needs to be a raw pointer.
8675 </p>
8676 <p>
8677 Still I wouldn't mind if the text "<tt>operator-&gt;</tt> may return a proxy" would
8678 be removed from the resolution. I think it's up to the library
8679 implementation, how to implement <tt>istreambuf_iterator::operator-&gt;()</tt>. &nbsp;As
8680 longs as it behaves as expected: <tt>i-&gt;m</tt> should have the same effect as
8681 <tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i-&gt;~C()</tt>. &nbsp;The main issue
8682 is just: <tt>istreambuf_iterator</tt> should have an <tt>operator-&gt;()</tt>!
8683 </p>
8684 </blockquote>
8685
8686
8687
8688
8689 <hr>
8690 <h3><a name="661"></a>661. New 27.6.1.2.2 changes make special extractions useless</h3>
8691 <p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
8692  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-04-01</p>
8693 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.formatted.arithmetic">active issues</a> in [istream.formatted.arithmetic].</p>
8694 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
8695 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
8696 <p><b>Discussion:</b></p>
8697 <p>
8698 To the more drastic changes of 27.6.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong
8699 the explicit description of the extraction of the types short and int in
8700 terms of as-if code fragments.
8701 </p>
8702
8703 <ol>
8704 <li>
8705 The corresponding as-if extractions in paragraph 2 and 3 will never
8706 result in a change of the operator&gt;&gt; argument val, because the
8707 contents of the local variable lval is in no case written into val.
8708 Furtheron both fragments need a currently missing parentheses in the
8709 beginning of the if-statement to be valid C++.
8710 </li>
8711 <li>I would like to ask whether the omission of a similar explicit
8712 extraction of unsigned short and unsigned int in terms of long -
8713 compared to their corresponding new insertions, as described in
8714 27.6.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or
8715 an
8716 oversight.
8717 </li>
8718 </ol>
8719
8720
8721 <p><b>Proposed resolution:</b></p>
8722 <ol>
8723 <li>
8724 <p>
8725 In 27.6.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment
8726 </p>
8727 <blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
8728 iostate err = 0;
8729 long lval;
8730 use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval );
8731 if (err == 0) <ins>{</ins>
8732   <del>&amp;&amp;</del> <ins>if</ins> (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval)<del>)</del>
8733       err = ios_base::failbit;
8734   <ins>else
8735     val = static_cast&lt;short&gt;(lval);
8736 }</ins>
8737 setstate(err);
8738 </pre></blockquote>
8739
8740 <p>
8741 Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
8742 </p>
8743
8744 <blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
8745 iostate err = 0;
8746 long lval;
8747 use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval );
8748 if (err == 0) <ins>{</ins>
8749   <del>&amp;&amp;</del> <ins>if</ins> (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval)<del>)</del>
8750       err = ios_base::failbit;
8751   <ins>else
8752     val = static_cast&lt;int&gt;(lval);
8753 }</ins>
8754 setstate(err);
8755 </pre></blockquote>
8756 </li>
8757 <li>
8758 ---
8759 </li>
8760 </ol>
8761
8762
8763 <p><i>[
8764 Kona (2007): Note to the editor: the name lval in the call to <tt>use_facet</tt>
8765 is incorrectly italicized in the code fragments corresponding to
8766 <tt>operator&gt;&gt;(short &amp;)</tt> and <tt>operator &gt;&gt;(int &amp;)</tt>. Also, val -- which appears
8767 twice on the line with the <tt>static_cast</tt> in the proposed resolution --
8768 should be italicized. Also, in response to part two of the issue: this
8769 is deliberate.
8770 ]</i></p>
8771
8772
8773
8774
8775
8776 <hr>
8777 <h3><a name="664"></a>664. <tt>do_unshift</tt> for <tt>codecvt&lt;char, char, mbstate_t&gt;</tt></h3>
8778 <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#Ready">Ready</a>
8779  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
8780 <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>
8781 <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>
8782 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
8783 <p><b>Discussion:</b></p>
8784 <p>
8785 22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding <tt>do_unshift</tt>):
8786 </p>
8787
8788 <blockquote><p>
8789 <i>Effects:</i> Places characters starting at to that should be appended to
8790 terminate a sequence when the current <tt>stateT</tt> is given by
8791 <tt><i>state</i></tt>.<sup>237)</sup> Stores no more than <tt>(<i>to_limit</i> -
8792 <i>to</i>)</tt> destination elements, and leaves the <tt><i>to_next</i></tt>
8793 pointer pointing one beyond the last element successfully stored.
8794 <em><tt>codecvt&lt;char, char, mbstate_t&gt;</tt> stores no characters.</em>
8795 </p></blockquote>
8796
8797 <p>
8798 The following objection has been raised:
8799 </p>
8800
8801 <blockquote><p>
8802 Since the C++ Standard permits a nontrivial conversion for the required
8803 instantiations of <tt>codecvt</tt>, it is overly restrictive to say that
8804 <tt>do_unshift</tt> must store no characters and return <tt>noconv</tt>.
8805 </p></blockquote>
8806
8807 <p>
8808 [Plum ref _222152Y50]
8809 </p>
8810
8811
8812 <p><b>Proposed resolution:</b></p>
8813 <p>
8814 Change 22.2.1.4.2 [locale.codecvt.virtuals], p7:
8815 </p>
8816
8817 <blockquote>
8818 <p>
8819 <i>Effects:</i> Places characters starting at <i>to</i> that should be
8820 appended to terminate a sequence when the current <tt>stateT</tt> is
8821 given by state.<sup>237)</sup> Stores no more than (<i>to_limit -to</i>)
8822 destination elements, and leaves the <i>to_next</i> pointer pointing one
8823 beyond the last element successfully stored. <del><tt>codecvt&lt;char, char,
8824 mbstate_t&gt;</tt> stores no characters.</del>
8825 </p>
8826 </blockquote>
8827
8828
8829
8830
8831
8832 <hr>
8833 <h3><a name="665"></a>665. <tt>do_unshift</tt> return value</h3>
8834 <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#Ready">Ready</a>
8835  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
8836 <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>
8837 <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>
8838 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
8839 <p><b>Discussion:</b></p>
8840 <p>
8841 22.2.1.4.2 [locale.codecvt.virtuals], para 8 says:
8842 </p>
8843
8844 <blockquote><p>
8845 <tt>codecvt&lt;char,char,mbstate_t&gt;</tt>, returns <tt>noconv</tt>.
8846 </p></blockquote>
8847
8848 <p>
8849 The following objection has been raised:
8850 </p>
8851
8852 <blockquote><p>
8853 Despite what the C++ Standard&nbsp;
8854 says, <tt>unshift</tt> can't always return <tt>noconv</tt> for the default facets, since&nbsp;
8855 they can be nontrivial. At least one implementation does whatever the&nbsp;
8856 C functions do.
8857 </p></blockquote>
8858
8859 <p>
8860 [Plum ref _222152Y62]
8861 </p>
8862
8863
8864 <p><b>Proposed resolution:</b></p>
8865 <p>
8866 Change 22.2.1.4.2 [locale.codecvt.virtuals], p8:
8867 </p>
8868
8869 <blockquote>
8870 <p><i>Returns:</i> An enumeration value, as summarized in Table 76:</p>
8871 <p>...</p>
8872 <p>
8873 <del><tt>codecvt&lt;char,char,mbstate_t&gt;</tt>, returns <tt>noconv</tt>.</del>
8874 </p>
8875 </blockquote>
8876
8877
8878
8879
8880
8881
8882 <hr>
8883 <h3><a name="666"></a>666. <tt>moneypunct::do_curr_symbol()</tt></h3>
8884 <p><b>Section:</b> 22.2.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
8885  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
8886 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.moneypunct.virtuals">issues</a> in [locale.moneypunct.virtuals].</p>
8887 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
8888 <p><b>Discussion:</b></p>
8889 <p>
8890 22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
8891 </p>
8892
8893 <blockquote><p>
8894 <sup>257)</sup> For international&nbsp;
8895 specializations (second template parameter <tt>true</tt>) this is always four&nbsp;
8896 characters long, usually three letters and a space.
8897 </p></blockquote>
8898
8899 <p>
8900 The following objection has been raised:
8901 </p>
8902
8903 <blockquote><p>
8904 The international currency&nbsp;
8905 symbol is whatever the underlying locale says it is, not necessarily&nbsp;
8906 four characters long.
8907 </p></blockquote>
8908
8909 <p>
8910 [Plum ref _222632Y41]
8911 </p>
8912
8913
8914 <p><b>Proposed resolution:</b></p>
8915 <p>
8916 Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]:
8917 </p>
8918
8919 <blockquote>
8920 <p>
8921 <sup>253)</sup> For international specializations (second template
8922 parameter <tt>true</tt>) this is <del>always</del> <ins>typically</ins>
8923 four characters long, usually three letters and a space.
8924 </p>
8925 </blockquote>
8926
8927
8928
8929
8930
8931 <hr>
8932 <h3><a name="667"></a>667. <tt>money_get</tt>'s widened minus sign</h3>
8933 <p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8934  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
8935 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
8936 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
8937 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8938 <p><b>Discussion:</b></p>
8939 <p>
8940 22.2.6.1.2 [locale.money.get.virtuals], para 1 says:
8941 </p>
8942
8943 <blockquote><p>
8944 The result is returned as an integral value&nbsp;
8945 stored in <tt>units</tt> or as a sequence of digits possibly preceded by a&nbsp;
8946 minus sign (as produced by <tt>ct.widen(c)</tt> where <tt>c</tt> is '-' or in the range&nbsp;
8947 from '0' through '9', inclusive) stored in <tt>digits</tt>.
8948 </p></blockquote>
8949
8950 <p>
8951 The following
8952 objection has been raised:
8953 </p>
8954
8955 <blockquote><p>
8956 Some implementations interpret this to mean that a facet derived from
8957 <tt>ctype&lt;wchar_t&gt;</tt> can provide its own member <tt>do_widen(char)</tt>
8958 which produces e.g. <tt>L'@'</tt> for the "widened" minus sign, and that the
8959 <tt>'@'</tt> symbol will appear in the resulting sequence of digits.&nbsp; Other
8960 implementations have assumed that one or more places in the standard permit the
8961 implementation to "hard-wire" <tt>L'-'</tt> as the "widened" minus sign.&nbsp; Are
8962 both interpretations permissible, or only&nbsp; one?
8963 </p></blockquote>
8964
8965 <p>
8966 [Plum ref _222612Y14]
8967 </p>
8968
8969 <p>
8970 Furthermore: if <tt>ct.widen('9')</tt> produces <tt>L'X'</tt> (a non-digit), does a
8971 parse fail if a <tt>'9'</tt> appears in the subject string? [Plum ref _22263Y33]
8972 </p>
8973
8974 <p><i>[
8975 Kona (2007): Bill and Dietmar to provide proposed wording.
8976 ]</i></p>
8977
8978
8979
8980 <p><b>Proposed resolution:</b></p>
8981 <p>
8982 </p>
8983
8984
8985
8986
8987
8988 <hr>
8989 <h3><a name="668"></a>668. <tt>money_get</tt>'s empty minus sign</h3>
8990 <p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8991  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
8992 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
8993 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
8994 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8995 <p><b>Discussion:</b></p>
8996 <p>
8997 22.2.6.1.2 [locale.money.get.virtuals], para 3 says:
8998 </p>
8999
9000 <blockquote><p>
9001 If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
9002 optional, and if no sign is detected, the result is given the sign&nbsp;
9003 that corresponds to the source of the empty string.
9004 </p></blockquote>
9005
9006 <p>
9007 The following
9008 objection has been raised:
9009 </p>
9010
9011 <blockquote><p>
9012 A <tt>negative_sign</tt> of "" means "there is no&nbsp;
9013 way to write a negative sign" not "any null sequence is a negative&nbsp;
9014 sign, so it's always there when you look for it".
9015 </p></blockquote>
9016
9017 <p>
9018 [Plum ref _222612Y32]
9019 </p>
9020
9021 <p><i>[
9022 Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
9023 ]</i></p>
9024
9025
9026
9027
9028 <p><b>Proposed resolution:</b></p>
9029 <p>
9030 </p>
9031
9032
9033
9034
9035
9036 <hr>
9037 <h3><a name="669"></a>669. Equivalent postive and negative signs in <tt>money_get</tt></h3>
9038 <p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9039  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
9040 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
9041 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
9042 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9043 <p><b>Discussion:</b></p>
9044 <p>
9045 22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
9046 </p>
9047
9048 <blockquote><p>
9049 If the first character of <tt>pos</tt> is equal to the first character of <tt>neg</tt>,&nbsp;
9050 or if both strings are empty, the result is given a positive sign.
9051 </p></blockquote>
9052
9053 <p>
9054 One interpretation is that an input sequence must match either the
9055 positive pattern or the negative pattern, and then in either event it
9056 is interpreted as positive.&nbsp; The following objections has been raised:
9057 </p>
9058
9059 <blockquote><p>
9060 The input can successfully match only a positive sign, so the negative
9061 pattern is an unsuccessful match.
9062 </p></blockquote>
9063
9064 <p>
9065 [Plum ref _222612Y34, 222612Y51b]
9066 </p>
9067
9068 <p><i>[
9069 Bill to provide proposed wording and interpretation of existing wording.
9070 ]</i></p>
9071
9072
9073
9074
9075 <p><b>Proposed resolution:</b></p>
9076 <p>
9077 </p>
9078
9079
9080
9081
9082
9083 <hr>
9084 <h3><a name="670"></a>670. <tt>money_base::pattern</tt> and <tt>space</tt></h3>
9085 <p><b>Section:</b> 22.2.6.3 [locale.moneypunct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9086  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
9087 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9088 <p><b>Discussion:</b></p>
9089 <p>
9090 22.2.6.3 [locale.moneypunct], para 2 says:
9091 </p>
9092
9093 <blockquote><p>
9094 The value <tt>space</tt> indicates that at least one space is required at&nbsp;
9095 that position.
9096 </p></blockquote>
9097
9098 <p>
9099 The following objection has been raised:
9100 </p>
9101
9102 <blockquote><p>
9103 Whitespace&nbsp;is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
9104 </p></blockquote>
9105
9106 <p>
9107 [Plum ref _22263Y22]
9108 </p>
9109
9110 <p><i>[
9111 Kona (2007): Bill to provide proposed wording. We agree that C++03 is
9112 ambiguous, and that we want C++0X to say "space" means 0 or more
9113 whitespace characters on input.
9114 ]</i></p>
9115
9116
9117
9118
9119 <p><b>Proposed resolution:</b></p>
9120 <p>
9121 </p>
9122
9123
9124
9125
9126
9127 <hr>
9128 <h3><a name="671"></a>671. precision of hexfloat</h3>
9129 <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#Open">Open</a>
9130  <b>Submitter:</b> John Salmon <b>Date:</b> 2007-04-20</p>
9131 <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>
9132 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9133 <p><b>Discussion:</b></p>
9134 <p>
9135 I am trying to understand how TR1 supports hex float (%a) output.
9136 </p>
9137 <p>
9138 As far as I can tell, it does so via the following:
9139 </p>
9140 <p>
9141 8.15 Additions to header &lt;locale&gt; [tr.c99.locale]
9142 </p>
9143 <p>
9144 In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
9145 the line:
9146 floatfield == ios_base::scientific %E
9147 </p>
9148 <p>
9149 add the two lines:
9150 </p>
9151 <blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific &amp;&amp; !uppercase %a
9152 floatfield == ios_base::fixed | ios_base::scientific %A 2
9153 </pre></blockquote>
9154 <p>
9155 [Note: The additional requirements on print and scan functions, later
9156 in this clause, ensure that the print functions generate hexadecimal
9157 floating-point fields with a %a or %A conversion specifier, and that
9158 the scan functions match hexadecimal floating-point fields with a %g
9159 conversion specifier. &nbsp;end note]
9160 </p>
9161 <p>
9162 Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find:
9163 </p>
9164 <p>
9165 For conversion from a floating-point type, if (flags &amp; fixed) != 0 or
9166 if str.precision() &gt; 0, then str.precision() is specified in the
9167 conversion specification.
9168 </p>
9169 <p>
9170 This would seem to imply that when floatfield == fixed|scientific, the
9171 precision of the conversion specifier is to be taken from
9172 str.precision(). &nbsp;Is this really what's intended? &nbsp;I sincerely hope
9173 that I'm either missing something or this is an oversight. &nbsp;Please
9174 tell me that the committee did not intend to mandate that hex floats
9175 (and doubles) should by default be printed as if by %.6a.
9176 </p>
9177
9178 <p><i>[
9179 Howard: I think the fundamental issue we overlooked was that with %f,
9180 %e, %g, the default precision was always 6. &nbsp;With %a the default
9181 precision is not 6, it is infinity. &nbsp;So for the first time, we need to
9182 distinguish between the default value of precision, and the precision
9183 value 6.
9184 ]</i></p>
9185
9186
9187
9188
9189 <p><b>Proposed resolution:</b></p>
9190 <p>
9191 </p>
9192
9193
9194 <p><i>[
9195 Kona (2007): Robert volunteers to propose wording.
9196 ]</i></p>
9197
9198
9199
9200
9201
9202 <hr>
9203 <h3><a name="672"></a>672. Swappable requirements need updating</h3>
9204 <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#Review">Review</a>
9205  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</p>
9206 <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>
9207 <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>
9208 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
9209 <p><b>Discussion:</b></p>
9210 <p>
9211 The current <tt>Swappable</tt> is:
9212 </p>
9213
9214 <blockquote>
9215 <table border="1">
9216 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
9217 <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
9218 <tr><td><tt>swap(s,t)</tt></td><td><tt>void</tt></td><td><tt>t</tt> has the value originally held by <tt>u</tt>, and <tt>u</tt> has the value originally
9219 held by <tt>t</tt></td></tr>
9220 <tr><td colspan="3">
9221 <p>
9222 The Swappable requirement is met by satisfying one or more of the following conditions:
9223 </p>
9224 <ul>
9225 <li>
9226 <tt>T</tt> is Swappable if <tt>T</tt> satisfies the <tt>CopyConstructible</tt> requirements (Table 34)
9227 and the <tt>CopyAssignable</tt> requirements (Table 36);
9228 </li>
9229 <li>
9230 <tt>T</tt> is Swappable if a namespace scope function named <tt>swap</tt> exists in the same
9231 namespace as the definition of <tt>T</tt>, such that the expression <tt>swap(t,u)</tt> is valid
9232 and has the semantics described in this table.
9233 </li>
9234 </ul>
9235 </td></tr>
9236 </tbody></table>
9237 </blockquote>
9238
9239 <p>
9240 With the passage of rvalue reference into the language, <tt>Swappable</tt> needs to be updated to
9241 require only <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.  This is a minimum.
9242 </p>
9243
9244 <p>
9245 Additionally we may want to support proxy references such that the following code is acceptable:
9246 </p>
9247
9248 <blockquote><pre>namespace Mine {
9249
9250 template &lt;class T&gt;
9251 struct proxy {...};
9252
9253 template &lt;class T&gt;
9254 struct proxied_iterator
9255 {
9256    typedef T value_type;
9257    typedef proxy&lt;T&gt; reference;
9258    reference operator*() const;
9259    ...
9260 };
9261
9262 struct A
9263 {
9264    // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
9265    void swap(A&amp;);
9266    ...
9267 };
9268
9269 void swap(A&amp;, A&amp;);
9270 void swap(proxy&lt;A&gt;, A&amp;);
9271 void swap(A&amp;, proxy&lt;A&gt;);
9272 void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);
9273
9274 }  // Mine
9275
9276 ...
9277
9278 Mine::proxied_iterator&lt;Mine::A&gt; i(...)
9279 Mine::A a;
9280 swap(*i1, a);
9281 </pre></blockquote>
9282
9283 <p>
9284 I.e. here is a call to <tt>swap</tt> which the user enables swapping between a proxy to a class and the class
9285 itself.  We do not need to anything in terms of implementation except not block their way with overly
9286 constrained concepts.  That is, the <tt>Swappable</tt> concept should be expanded to allow swapping
9287 between two different types for the case that one is binding to a user-defined <tt>swap</tt>.
9288 </p>
9289
9290
9291
9292 <p><b>Proposed resolution:</b></p>
9293
9294 <p>
9295 Change 20.1.1 [utility.arg.requirements]:
9296 </p>
9297
9298 <blockquote>
9299
9300 <p>
9301 -1- The template definitions in the C++ Standard Library refer to various
9302 named requirements whose details are set out in tables 31-38. In these
9303 tables, <tt>T</tt> is a type to be supplied by a C++ program
9304 instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
9305 values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
9306 lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
9307 <tt>const</tt>) <tt>T</tt>; and <tt>rv</tt> is a non-<tt>const</tt>
9308 rvalue of type <tt>T</tt>.
9309 </p>
9310
9311 <table border="1">
9312 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
9313 <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
9314 <tr><td><tt>swap(s,t)</tt></td><td><tt>void</tt></td>
9315 <td><tt>t</tt> has the value originally
9316 held by <tt>u</tt>, and
9317 <tt>u</tt> has the value originally held
9318 by <tt>t</tt></td></tr>
9319 <tr><td colspan="3">
9320 <p>
9321 The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
9322 </p>
9323 <ul>
9324 <li>
9325 <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> satisfies the
9326 <del><tt>CopyConstructible</tt></del> <ins>MoveConstructible</ins>
9327 requirements (Table <del>34</del> <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del> <ins>MoveAssignable</ins>
9328 requirements (Table <del>36</del> <ins>35</ins>);
9329 </li>
9330 <li>
9331 <tt>T</tt> is <tt>Swappable</tt> if a namespace scope function named
9332 <tt>swap</tt> exists in the same namespace as the definition of
9333 <tt>T</tt>, such that the expression
9334 <tt>swap(t,u)</tt> is valid and has the
9335 semantics described in this table.
9336 </li>
9337 </ul>
9338 </td></tr>
9339 </tbody></table>
9340 </blockquote>
9341
9342
9343
9344 <p><i>[
9345 Kona (2007): We like the change to the <tt>Swappable</tt> requirements to use
9346 move semantics. The issue relating to the support of proxies is
9347 separable from the one relating to move semantics, and it's bigger than
9348 just swap. We'd like to address only the move semantics changes under
9349 this issue, and open a separated issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>) to handle proxies. Also, there
9350 may be a third issue, in that the current definition of <tt>Swappable</tt> does
9351 not permit rvalues to be operands to a swap operation, and Howard's
9352 proposed resolution would allow the right-most operand to be an rvalue,
9353 but it would not allow the left-most operand to be an rvalue (some swap
9354 functions in the library have been overloaded to permit left operands to
9355 swap to be rvalues).
9356 ]</i></p>
9357
9358
9359
9360
9361
9362 <hr>
9363 <h3><a name="673"></a>673. <tt>unique_ptr</tt> update</h3>
9364 <p><b>Section:</b> 20.6.5 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9365  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</p>
9366 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9367 <p><b>Discussion:</b></p>
9368 <p>
9369 Since the publication of
9370 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
9371 there have been a few small but significant advances which should be included into
9372 <tt>unique_ptr</tt>.  There exists a
9373 <a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">reference implmenation</a>
9374 for all of these changes.
9375 </p>
9376
9377 <ul>
9378
9379 <li>
9380 <p>
9381 Even though <tt>unique_ptr&lt;void&gt;</tt> is not a valid use case (unlike for <tt>shared_ptr&lt;void&gt;</tt>),
9382 unexpected cases to crop up which require the instantiation of the interface of <tt>unique_ptr&lt;void&gt;</tt>
9383 even if it is never used.  For example see
9384 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidently
9385 happened to <tt>auto_ptr</tt>.  I believe the most robust way to protect <tt>unique_ptr</tt> against this
9386 type of failure is to augment the return type of <tt>unique_ptr&lt;T&gt;:operator*()</tt> with
9387 <tt>add_lvalue_reference&lt;T&gt;::type</tt>.  This means that given an instantiated <tt>unique_ptr&lt;void&gt;</tt>
9388 the act of dereferencing it will simply return <tt>void</tt> instead of causing a compile time failure.
9389 This is simpler than creating a <tt>unique_ptr&lt;void&gt;</tt> specialization which isn't robust in the
9390 face of <tt><i>cv-</i></tt>qualified <tt>void</tt> types.
9391 </p>
9392
9393 <p>
9394 This resolution also supports instantiations such as <tt>unique_ptr&lt;void, free_deleter&gt;</tt>
9395 which could be very useful to the client.
9396 </p>
9397
9398 </li>
9399
9400 <li>
9401 <p>
9402 Efforts have been made to better support containers and smart pointers in shared
9403 memory contexts.  One of the key hurdles in such support is not assuming that a
9404 pointer type is actually a <tt>T*</tt>.  This can easily be accomplished
9405 for <tt>unique_ptr</tt> by having the deleter define the pointer type:
9406 <tt>D::pointer</tt>.  Furthermore this type can easily be defaulted to
9407 <tt>T*</tt> should the deleter <tt>D</tt> choose not to define a pointer
9408 type (reference implementation
9409 <a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">here</a>).
9410 This change has no run time overhead.  It has no interface overhead on
9411 authors of custom delter types.  It simply allows (but not requires)
9412 authors of custom deleter types to define a smart pointer for the
9413 storage type of <tt>unique_ptr</tt> if they find such functionality
9414 useful.  <tt>std::default_delete</tt> is an example of a deleter which
9415 defaults <tt>pointer</tt> to <tt>T*</tt> by simply ignoring this issue
9416 and not including a <tt>pointer typedef</tt>.
9417 </p>
9418 </li>
9419
9420 <li>
9421 <p>
9422 When the deleter type is a function pointer then it is unsafe to construct
9423 a <tt>unique_ptr</tt> without specifying the function pointer in the constructor.
9424 This case is easy to check for with a <tt>static_assert</tt> assuring that the
9425 deleter is not a pointer type in those constructors which do not accept deleters.
9426 </p>
9427
9428 <blockquote><pre>unique_ptr&lt;A, void(*)(void*)&gt; p(new A);  // error, no function given to delete the pointer!
9429 </pre></blockquote>
9430
9431 </li>
9432
9433 </ul>
9434
9435 <p><i>[
9436 Kona (2007): We don't like the solution given to the first bullet in
9437 light of concepts. The second bullet solves the problem of supporting
9438 fancy pointers for one library component only. The full LWG needs to
9439 decide whether to solve the problem of supporting fancy pointers
9440 piecemeal, or whether a paper addressing the whole library is needed. We
9441 think that the third bullet is correct.
9442 ]</i></p>
9443
9444
9445 <p><i>[
9446 Post Kona: Howard adds example user code related to the first bullet:
9447 ]</i></p>
9448
9449
9450 <blockquote>
9451 <pre>void legacy_code(void*, std::size_t);
9452
9453 void foo(std::size_t N)
9454 {
9455     std::unique_ptr&lt;void, void(*)(void*)&gt; ptr(std::malloc(N), std::free);
9456     legacy_code(ptr.get(), N);
9457 }   // unique_ptr used for exception safety purposes
9458 </pre>
9459 </blockquote>
9460
9461 <p>
9462 I.e. <tt>unique_ptr&lt;void&gt;</tt> <i>is</i> a useful tool that we don't want
9463 to disable with concepts.  The only part of <tt>unique_ptr&lt;void&gt;</tt> we
9464 want to disable (with concepts or by other means) are the two member functions:
9465 </p>
9466
9467 <blockquote><pre>T&amp; operator*() const;
9468 T* operator-&gt;() const;
9469 </pre></blockquote>
9470
9471
9472
9473 <p><b>Proposed resolution:</b></p>
9474
9475 <p><i>[
9476 I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review
9477 the proposed resolutions below.
9478 ]</i></p>
9479
9480
9481 <ul>
9482 <li>
9483
9484 <p>
9485 Change 20.6.5.2 [unique.ptr.single]:
9486 </p>
9487
9488 <blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
9489    ...
9490    <del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
9491    ...
9492 };
9493 </pre></blockquote>
9494
9495 <p>
9496 Change 20.6.5.2.4 [unique.ptr.single.observers]:
9497 </p>
9498
9499 <blockquote><pre><del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
9500 </pre></blockquote>
9501
9502 </li>
9503
9504 <li>
9505 <p>
9506 Change 20.6.5.2 [unique.ptr.single]:
9507 </p>
9508
9509 <blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
9510 public:
9511   <ins>typedef <i>implementation (see description below)</i> pointer;</ins>
9512    ...
9513    explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
9514    ...
9515    unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
9516    unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
9517    ...
9518    <del>T*</del> <ins>pointer</ins> operator-&gt;() const;
9519    <del>T*</del> <ins>pointer</ins> get() const;
9520    ...
9521    <del>T*</del> <ins>pointer</ins> release();
9522    void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
9523 };
9524 </pre></blockquote>
9525
9526 <p>
9527 <ins>
9528 -3- If the type <tt>remove_reference&lt;D&gt;::type::pointer</tt>
9529 exists, then <tt>unique_ptr&lt;T, D&gt;::pointer</tt> is a typedef to
9530 <tt>remove_reference&lt;D&gt;::type::pointer</tt>.  Otherwise
9531 <tt>unique_ptr&lt;T, D&gt;::pointer</tt> is a typedef to <tt>T*</tt>.
9532 The type <tt>unique_ptr&lt;T, D&gt;::pointer</tt> must be <tt>CopyConstructible</tt>
9533 and <tt>CopyAssignable</tt>.
9534 </ins>
9535 </p>
9536
9537 <p>
9538 Change 20.6.5.2.1 [unique.ptr.single.ctor]:
9539 </p>
9540
9541 <blockquote><pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
9542 ...
9543 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
9544 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
9545 ...
9546 unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp; d);
9547 unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp;&amp; d);
9548 ...
9549 unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp; d);
9550 unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp;&amp; d);
9551 ...
9552 unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp; d);
9553 unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp;&amp; d);
9554 ...
9555 </pre></blockquote>
9556
9557 <p>
9558 -23- <i>Requires:</i> If <tt>D</tt> is not a reference type,
9559 construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
9560 must be well formed and not throw an exception. If <tt>D</tt> is a
9561 reference type, then <tt>E</tt> must be the same type as <tt>D</tt>
9562 (diagnostic required). <del><tt>U*</tt></del> <ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins>
9563 must be implicitly convertible to <del><tt>T*</tt></del>
9564 <ins>pointer</ins>.
9565 </p>
9566
9567 <p>
9568 -25- <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before
9569 the construction, modulo any required offset adjustments resulting from
9570 the cast from <del><tt>U*</tt></del>
9571 <ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> to <del><tt>T*</tt></del>
9572 <ins>pointer</ins>. <tt>get_deleter()</tt> returns a reference to the
9573 internally stored deleter which was constructed from
9574 <tt>u.get_deleter()</tt>.
9575 </p>
9576
9577 <p>
9578 Change 20.6.5.2.3 [unique.ptr.single.asgn]:
9579 </p>
9580
9581 <blockquote>
9582 <p>
9583 -8- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
9584 <tt>D</tt> must not throw an exception. <del><tt>U*</tt></del>
9585 <ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> must be implicitly
9586 convertible to <del><tt>T*</tt></del> <ins>pointer</ins>.
9587 </p>
9588 </blockquote>
9589
9590 <p>
9591 Change 20.6.5.2.4 [unique.ptr.single.observers]:
9592 </p>
9593
9594 <blockquote>
9595 <pre><del>T*</del> <ins>pointer</ins> operator-&gt;() const;</pre>
9596 ...
9597 <pre><del>T*</del> <ins>pointer</ins> get() const;</pre>
9598 </blockquote>
9599
9600 <p>
9601 Change 20.6.5.2.5 [unique.ptr.single.modifiers]:
9602 </p>
9603
9604 <blockquote>
9605 <pre><del>T*</del> <ins>pointer</ins> release();</pre>
9606 ...
9607 <pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);</pre>
9608 </blockquote>
9609
9610 <p>
9611 Change 20.6.5.3 [unique.ptr.runtime]:
9612 </p>
9613
9614 <blockquote><pre>template &lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt; {
9615 public:
9616   <ins>typedef <i>implementation</i> pointer;</ins>
9617    ...
9618    explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
9619    ...
9620    unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
9621    unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
9622    ...
9623    <del>T*</del> <ins>pointer</ins> get() const;
9624    ...
9625    <del>T*</del> <ins>pointer</ins> release();
9626    void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
9627 };
9628 </pre></blockquote>
9629
9630 <p>
9631 Change 20.6.5.3.1 [unique.ptr.runtime.ctor]:
9632 </p>
9633
9634 <blockquote>
9635 <pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
9636 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
9637 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
9638 </pre>
9639
9640 <p>
9641 These constructors behave the same as in the primary template except
9642 that they do not accept pointer types which are convertible to
9643 <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins>. [<i>Note:</i> One
9644 implementation technique is to create private templated overloads of
9645 these members. <i>-- end note</i>]
9646 </p>
9647 </blockquote>
9648
9649 <p>
9650 Change 20.6.5.3.3 [unique.ptr.runtime.modifiers]:
9651 </p>
9652
9653 <blockquote>
9654 <pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
9655 </pre>
9656
9657 <p>
9658 -1- <i>Requires:</i> Does not accept pointer types which are convertible
9659 to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
9660 required). [<i>Note:</i> One implementation technique is to create a private
9661 templated overload. <i>-- end note</i>]
9662 </p>
9663 </blockquote>
9664
9665 <p>
9666 Change 20.6.5.4 [unique.ptr.compiletime]:
9667 </p>
9668
9669 <blockquote><pre>template &lt;class T, class D,  size_t N&gt; class unique_ptr&lt;T[N], D&gt; {
9670 public:
9671   <ins>typedef <i>implementation</i> pointer;</ins>
9672    ...
9673    explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
9674    ...
9675    unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
9676    unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
9677    ...
9678    <del>T*</del> <ins>pointer</ins> get() const;
9679    ...
9680    <del>T*</del> <ins>pointer</ins> release();
9681    void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
9682 };
9683 </pre></blockquote>
9684
9685 <p>
9686 Change 20.6.5.4.3 [unique.ptr.compiletime.modifiers]:
9687 </p>
9688
9689 <blockquote>
9690 <pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
9691 </pre>
9692
9693 <p>
9694 -1- <i>Requires:</i> Does not accept pointer types which are convertible
9695 to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (dignostic required). [<i>Note:</i> One implementation
9696 technique is to create a private templated overload. <i>--end note</i>]
9697 </p>
9698
9699 </blockquote>
9700
9701 </li>
9702
9703 <li>
9704
9705 <p>
9706 Change 20.6.5.2.1 [unique.ptr.single.ctor]:
9707 </p>
9708
9709 <blockquote>
9710 <pre>unique_ptr();</pre>
9711 <blockquote>
9712 <p>
9713 <i>Requires:</i> <tt>D</tt> must be default constructible, and that
9714 construction must not throw an exception. <tt>D</tt> must not be a
9715 reference type <ins>or pointer type (diagnostic required)</ins>.
9716 </p>
9717 </blockquote>
9718 <pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
9719 <blockquote>
9720 <p>
9721 <i>Requires:</i>  The expression <tt>D()(p)</tt> must be well formed.
9722 The default constructor of <tt>D</tt> must not throw an exception.
9723 <tt>D</tt> must not be a reference type <ins>or pointer type (diagnostic
9724 required)</ins>.
9725 </p>
9726 </blockquote>
9727 </blockquote>
9728
9729 <p>
9730 Change 20.6.5.2.1 [unique.ptr.single.ctor]:
9731 </p>
9732
9733 <blockquote>
9734 <pre>unique_ptr();</pre>
9735 <blockquote>
9736 <p>
9737 <i>Requires:</i> <tt>D</tt> must be default constructible, and that
9738 construction must not throw an exception. <tt>D</tt> must not be a
9739 reference type <ins>or pointer type (diagnostic required)</ins>.
9740 </p>
9741 </blockquote>
9742 <pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
9743 <blockquote>
9744 <p>
9745 <i>Requires:</i>  The expression <tt>D()(p)</tt> must be well formed.
9746 The default constructor of <tt>D</tt> must not throw an exception.
9747 <tt>D</tt> must not be a reference type <ins>or pointer type (diagnostic
9748 required)</ins>.
9749 </p>
9750 </blockquote>
9751 </blockquote>
9752
9753 </li>
9754
9755 </ul>
9756
9757
9758
9759
9760
9761
9762 <hr>
9763 <h3><a name="674"></a>674. <tt>shared_ptr</tt> interface changes for consistency with N1856</h3>
9764 <p><b>Section:</b> 20.6.6.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
9765  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-05</p>
9766 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
9767 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
9768 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
9769 <p><b>Discussion:</b></p>
9770 <p>
9771 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> does not propose
9772 any changes to <tt>shared_ptr</tt>. It needs to be updated to use a rvalue reference where appropriate
9773 and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>.
9774 </p>
9775
9776
9777 <p><b>Proposed resolution:</b></p>
9778
9779 <p>
9780 Change 20.6.6.2 [util.smartptr.shared] as follows:
9781 </p>
9782
9783 <blockquote>
9784 <pre>template&lt;class Y&gt; explicit shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
9785 <ins>template&lt;class Y, class D&gt; explicit shared_ptr(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
9786 template&lt;class Y, class D&gt; explicit shared_ptr(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins>
9787 ...
9788 template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
9789 <ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
9790 template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
9791 </blockquote>
9792
9793 <p>
9794 Change 20.6.6.2.1 [util.smartptr.shared.const] as follows:
9795 </p>
9796
9797 <blockquote>
9798 <pre><ins>template&lt;class Y&gt; shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</ins></pre>
9799 </blockquote>
9800
9801 <p>
9802 Add to 20.6.6.2.1 [util.smartptr.shared.const]:
9803 </p>
9804
9805 <blockquote>
9806 <pre><ins>template&lt;class Y, class D&gt; shared_ptr(unique_ptr&lt;Y, D&gt;&amp;&amp; r);</ins></pre>
9807 <blockquote>
9808
9809 <p><ins>
9810 <i>Effects:</i> Equivalent to <tt>shared_ptr( r.release(), r.get_deleter() )</tt> when <tt>D</tt> is
9811           not a reference type, <tt>shared_ptr( r.release(), ref( r.get_deleter() ) )</tt>
9812           otherwise.
9813 </ins></p>
9814
9815 <p><ins>
9816 <i>Exception safety:</i> If an exception is thrown, the constructor has no effect.
9817 </ins></p>
9818 </blockquote>
9819
9820 </blockquote>
9821
9822 <p>
9823 Change 20.6.6.2.3 [util.smartptr.shared.assign] as follows:
9824 </p>
9825
9826 <blockquote>
9827 <pre>template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</pre>
9828 </blockquote>
9829
9830 <p>
9831 Add to 20.6.6.2.3 [util.smartptr.shared.assign]:
9832 </p>
9833
9834 <blockquote>
9835 <pre><ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
9836
9837 <blockquote>
9838 <p><ins>
9839 -4- <i>Effects:</i> Equivalent to <tt>shared_ptr(std::move(r)).swap(*this)</tt>.
9840 </ins></p>
9841 <p><ins>
9842 -5- <i>Returns:</i> <tt>*this</tt>.
9843 </ins></p>
9844 </blockquote>
9845
9846 </blockquote>
9847
9848
9849
9850 <p><i>[
9851 Kona (2007): We may need to open an issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>) to deal with the question of
9852 whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
9853 ]</i></p>
9854
9855
9856
9857
9858
9859 <hr>
9860 <h3><a name="675"></a>675. Move assignment of containers</h3>
9861 <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#Ready">Ready</a>
9862  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p>
9863 <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>
9864 <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>
9865 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
9866 <p><b>Discussion:</b></p>
9867 <p>
9868 James Hopkin pointed out to me that if <tt>vector&lt;T&gt;</tt> move assignment is O(1)
9869 (just a <tt>swap</tt>) then containers such as <tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> might have
9870 the wrong semantics under move assignment when the source is not truly an rvalue, but a
9871 moved-from lvalue (destructors could run late).
9872 </p>
9873
9874 <blockquote><pre><tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v1;
9875 <tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v2;
9876 ...
9877 v1 = v2;               // #1
9878 v1 = std::move(v2);    // #2
9879 </pre></blockquote>
9880
9881 <p>
9882 Move semantics means not caring what happens to the source (<tt>v2</tt> in this example).
9883 It doesn't mean not caring what happens to the target (<tt>v1</tt>).  In the above example
9884 both assignments should have the same effect on <tt>v1</tt>.  Any non-shared <tt>ostream</tt>'s
9885 <tt>v1</tt> owns before the assignment should be closed, whether <tt>v1</tt> is undergoing
9886 copy assignment or move assignment.
9887 </p>
9888
9889 <p>
9890 This implies that the semantics of move assignment of a generic container should be
9891 <tt>clear, swap</tt> instead of just swap.  An alternative which could achieve the same
9892 effect would be to move assign each element.  In either case, the complexity of move
9893 assignment needs to be relaxed to <tt>O(v1.size())</tt>.
9894 </p>
9895
9896 <p>
9897 The performance hit of this change is not nearly as drastic as it sounds.
9898 In practice, the target of a move assignment has always just been move constructed
9899 or move assigned <i>from</i>.  Therefore under <tt>clear, swap</tt> semantics (in
9900 this common use case) we are still achieving O(1) complexity.
9901 </p>
9902
9903
9904
9905 <p><b>Proposed resolution:</b></p>
9906 <p>
9907 Change 23.1 [container.requirements]:
9908 </p>
9909
9910 <blockquote>
9911 <table border="1">
9912 <caption>Table 86: Container requirements</caption>
9913 <tbody><tr>
9914 <th>expression</th><th>return type</th><th>operational semantics</th>
9915 <th>assertion/note pre/post-condition</th><th>complexity</th>
9916 </tr>
9917 <tr>
9918 <td><tt>a = rv;</tt></td><td><tt>X&amp;</tt></td>
9919 <td><ins>All existing elements of <tt>a</tt> are either move assigned or destructed</ins></td>
9920 <td><tt>a</tt> shall be equal to the
9921 value that <tt>rv</tt> had
9922 before this construction
9923 </td>
9924 <td><del>constant</del> <ins>linear in <tt>a.size()</tt></ins></td>
9925 </tr>
9926 </tbody></table>
9927 </blockquote>
9928
9929
9930
9931
9932
9933
9934 <hr>
9935 <h3><a name="676"></a>676. Moving the unordered containers</h3>
9936 <p><b>Section:</b> 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
9937  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p>
9938 <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>
9939 <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>
9940 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
9941 <p><b>Discussion:</b></p>
9942 <p>
9943 Move semantics are missing from the <tt>unordered</tt> containers.  The proposed
9944 resolution below adds move-support consistent with
9945 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html">N1858</a>
9946 and the current working draft.
9947 </p>
9948
9949 <p>
9950 The current proposed resolution simply lists the requirements for each function.
9951 These might better be hoisted into the requirements table for unordered associative containers.
9952 Futhermore a mild reorganization of the container requirements could well be in order.
9953 This defect report is purposefully ignoring these larger issues and just focusing
9954 on getting the unordered containers "moved".
9955 </p>
9956
9957
9958
9959 <p><b>Proposed resolution:</b></p>
9960
9961 <p>
9962 Add to 23.4 [unord]:
9963 </p>
9964
9965 <blockquote><pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9966   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9967             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
9968
9969 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9970   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9971             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
9972
9973 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9974   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
9975             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
9976
9977 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9978   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9979             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
9980
9981 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9982   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9983             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
9984
9985 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9986   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
9987             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
9988
9989 ...
9990
9991 template &lt;class Value, class Hash, class Pred, class Alloc&gt;
9992   void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
9993             unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; y);
9994
9995 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
9996   void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
9997             unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
9998
9999 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
10000   void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; x,
10001             unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; y);</ins>
10002
10003 template &lt;class Value, class Hash, class Pred, class Alloc&gt;
10004   void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
10005             unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; y);
10006
10007 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
10008   void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
10009             unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
10010
10011 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
10012   void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; x,
10013             unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; y);</ins>
10014 </pre></blockquote>
10015
10016 <p><b><tt>unordered_map</tt></b></p>
10017
10018 <p>
10019 Change 23.4.1 [unord.map]:
10020 </p>
10021
10022 <blockquote><pre>class unordered_map
10023 {
10024     ...
10025     unordered_map(const unordered_map&amp;);
10026     <ins>unordered_map(unordered_map&amp;&amp;);</ins>
10027     ~unordered_map();
10028     unordered_map&amp; operator=(const unordered_map&amp;);
10029     <ins>unordered_map&amp; operator=(unordered_map&amp;&amp;);</ins>
10030     ...
10031     // modifiers
10032     <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj);
10033     <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);</ins>
10034     iterator       insert(iterator hint, const value_type&amp; obj);
10035     <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; obj);</ins>
10036     const_iterator insert(const_iterator hint, const value_type&amp; obj);
10037     <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
10038     ...
10039     void swap(unordered_map&amp;<ins>&amp;</ins>);
10040     ...
10041     mapped_type&amp; operator[](const key_type&amp; k);
10042     <ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins>
10043     ...
10044 };
10045
10046 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10047   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
10048             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
10049
10050 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10051   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
10052             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
10053
10054 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10055   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
10056             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
10057 </pre></blockquote>
10058
10059 <p>
10060 Add to 23.4.1.1 [unord.map.cnstr]:
10061 </p>
10062
10063 <blockquote>
10064 <pre>template &lt;class InputIterator&gt;
10065   unordered_map(InputIterator f, InputIterator l,
10066                 size_type n = <i>implementation-defined</i>,
10067                 const hasher&amp; hf = hasher(),
10068                 const key_equal&amp; eql = key_equal(),
10069                 const allocator_type&amp; a = allocator_type());
10070 </pre>
10071
10072 <blockquote><p>
10073 <ins>
10074 <i>Requires:</i> If the iterator's dereference operator returns an
10075 lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
10076 then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
10077 <tt>CopyConstructible</tt>.
10078 </ins>
10079 </p></blockquote>
10080 </blockquote>
10081
10082 <p>
10083 Add to 23.4.1.2 [unord.map.elem]:
10084 </p>
10085
10086 <blockquote>
10087
10088 <pre>mapped_type&amp; operator[](const key_type&amp; k);</pre>
10089
10090 <blockquote>
10091 <p>...</p>
10092 <p><ins>
10093 <i>Requires:</i> <tt>key_type</tt> shall be <tt>CopyConstructible</tt>
10094 and <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
10095 </ins></p>
10096 </blockquote>
10097
10098 <pre><ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins></pre>
10099
10100 <blockquote>
10101 <p><ins>
10102 <i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an
10103 element whose key is equivalent to <tt>k</tt> , inserts the value
10104 <tt>std::pair&lt;const key_type, mapped_type&gt;(std::move(k), mapped_type())</tt>.
10105 </ins></p>
10106
10107 <p><ins>
10108 <i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
10109 </ins></p>
10110
10111 <p><ins>
10112 <i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the
10113 (unique) element whose key is equivalent to <tt>k</tt>.
10114 </ins></p>
10115
10116 </blockquote>
10117
10118 </blockquote>
10119
10120 <p>
10121 Add new section [unord.map.modifiers]:
10122 </p>
10123
10124 <blockquote>
10125 <pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
10126 <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);</ins>
10127 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
10128 <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; x);</ins>
10129 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
10130 <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
10131 <ins>template &lt;class InputIterator&gt;
10132   void insert(InputIterator first, InputIterator last);</ins>
10133 </pre>
10134
10135 <blockquote>
10136 <p><ins>
10137 <i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
10138 requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
10139 <tt>CopyConstructible</tt>.
10140 </ins></p>
10141
10142 <p><ins>
10143 <tt>P</tt> shall be convertible to <tt>value_type</tt>.
10144  If <tt>P</tt> is instantiated as a reference
10145 type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
10146 is considered to be an rvalue as it is converted to <tt>value_type</tt>
10147 and inserted into the <tt>unordered_map</tt>. Specifically, in such
10148 cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
10149 <tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
10150 requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
10151 mapped_type&gt;</tt>, then <tt>key_type</tt> must be
10152 <tt>CopyConstructible</tt>).
10153 </ins></p>
10154
10155 <p><ins>
10156 The signature taking <tt>InputIterator</tt>
10157 parameters requires <tt>CopyConstructible</tt> of both
10158 <tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
10159 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
10160 <tt>value_type</tt>.
10161 </ins></p>
10162
10163 </blockquote>
10164
10165 </blockquote>
10166
10167 <p>
10168 Add to 23.4.1.3 [unord.map.swap]:
10169 </p>
10170
10171 <blockquote>
10172 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10173   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
10174             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
10175 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10176   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
10177             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
10178 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10179   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
10180             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
10181 </pre>
10182 </blockquote>
10183
10184 <p><b><tt>unordered_multimap</tt></b></p>
10185
10186 <p>
10187 Change 23.4.2 [unord.multimap]:
10188 </p>
10189
10190 <blockquote><pre>class unordered_multimap
10191 {
10192     ...
10193     unordered_multimap(const unordered_multimap&amp;);
10194     <ins>unordered_multimap(unordered_multimap&amp;&amp;);</ins>
10195     ~unordered_multimap();
10196     unordered_multimap&amp; operator=(const unordered_multimap&amp;);
10197     <ins>unordered_multimap&amp; operator=(unordered_multimap&amp;&amp;);</ins>
10198     ...
10199     // modifiers
10200     iterator insert(const value_type&amp; obj);
10201     <ins>template &lt;class P&gt; iterator insert(P&amp;&amp; obj);</ins>
10202     iterator       insert(iterator hint, const value_type&amp; obj);
10203     <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; obj);</ins>
10204     const_iterator insert(const_iterator hint, const value_type&amp; obj);
10205     <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
10206     ...
10207     void swap(unordered_multimap&amp;<ins>&amp;</ins>);
10208     ...
10209 };
10210
10211 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10212   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
10213             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
10214
10215 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10216   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
10217             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
10218
10219 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10220   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
10221             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
10222 </pre></blockquote>
10223
10224 <p>
10225 Add to 23.4.2.1 [unord.multimap.cnstr]:
10226 </p>
10227
10228 <blockquote>
10229 <pre>template &lt;class InputIterator&gt;
10230   unordered_multimap(InputIterator f, InputIterator l,
10231                 size_type n = <i>implementation-defined</i>,
10232                 const hasher&amp; hf = hasher(),
10233                 const key_equal&amp; eql = key_equal(),
10234                 const allocator_type&amp; a = allocator_type());
10235 </pre>
10236
10237 <blockquote><p>
10238 <ins>
10239 <i>Requires:</i> If the iterator's dereference operator returns an
10240 lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
10241 then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
10242 <tt>CopyConstructible</tt>.
10243 </ins>
10244 </p></blockquote>
10245 </blockquote>
10246
10247 <p>
10248 Add new section [unord.multimap.modifiers]:
10249 </p>
10250
10251 <blockquote>
10252 <pre><ins>iterator insert(const value_type&amp; x);</ins>
10253 <ins>template &lt;class P&gt; iterator       insert(P&amp;&amp; x);</ins>
10254 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
10255 <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; x);</ins>
10256 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
10257 <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
10258 <ins>template &lt;class InputIterator&gt;
10259   void insert(InputIterator first, InputIterator last);</ins>
10260 </pre>
10261
10262 <blockquote>
10263 <p><ins>
10264 <i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
10265 requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
10266 <tt>CopyConstructible</tt>.
10267 </ins></p>
10268
10269 <p><ins>
10270 <tt>P</tt> shall be convertible to <tt>value_type</tt>.
10271  If <tt>P</tt> is instantiated as a reference
10272 type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
10273 is considered to be an rvalue as it is converted to <tt>value_type</tt>
10274 and inserted into the <tt>unordered_multimap</tt>. Specifically, in such
10275 cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
10276 <tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
10277 requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
10278 mapped_type&gt;</tt>, then <tt>key_type</tt> must be
10279 <tt>CopyConstructible</tt>).
10280 </ins></p>
10281
10282 <p><ins>
10283 The signature taking <tt>InputIterator</tt>
10284 parameters requires <tt>CopyConstructible</tt> of both
10285 <tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
10286 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
10287 <tt>value_type</tt>.
10288 </ins></p>
10289 </blockquote>
10290
10291 </blockquote>
10292
10293 <p>
10294 Add to 23.4.2.2 [unord.multimap.swap]:
10295 </p>
10296
10297 <blockquote>
10298 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10299   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
10300             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
10301 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10302   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
10303             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
10304 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10305   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
10306             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
10307 </pre>
10308 </blockquote>
10309
10310 <p><b><tt>unordered_set</tt></b></p>
10311
10312 <p>
10313 Change 23.4.3 [unord.set]:
10314 </p>
10315
10316 <blockquote><pre>class unordered_set
10317 {
10318     ...
10319     unordered_set(const unordered_set&amp;);
10320     <ins>unordered_set(unordered_set&amp;&amp;);</ins>
10321     ~unordered_set();
10322     unordered_set&amp; operator=(const unordered_set&amp;);
10323     <ins>unordered_set&amp; operator=(unordered_set&amp;&amp;);</ins>
10324     ...
10325     // modifiers
10326     <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj);
10327     <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; obj);</ins>
10328     iterator       insert(iterator hint, const value_type&amp; obj);
10329     <ins>iterator       insert(iterator hint, value_type&amp;&amp; obj);</ins>
10330     const_iterator insert(const_iterator hint, const value_type&amp; obj);
10331     <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
10332     ...
10333     void swap(unordered_set&amp;<ins>&amp;</ins>);
10334     ...
10335 };
10336
10337 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10338   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
10339             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
10340
10341 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10342   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
10343             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
10344
10345 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10346   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
10347             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
10348 </pre></blockquote>
10349
10350 <p>
10351 Add to 23.4.3.1 [unord.set.cnstr]:
10352 </p>
10353
10354 <blockquote>
10355 <pre>template &lt;class InputIterator&gt;
10356   unordered_set(InputIterator f, InputIterator l,
10357                 size_type n = <i>implementation-defined</i>,
10358                 const hasher&amp; hf = hasher(),
10359                 const key_equal&amp; eql = key_equal(),
10360                 const allocator_type&amp; a = allocator_type());
10361 </pre>
10362
10363 <blockquote><p>
10364 <ins>
10365 <i>Requires:</i> If the iterator's dereference operator returns an
10366 lvalue or a const rvalue <tt>value_type</tt>, then the
10367 <tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
10368 </ins>
10369 </p></blockquote>
10370 </blockquote>
10371
10372 <p>
10373 Add new section [unord.set.modifiers]:
10374 </p>
10375
10376 <blockquote>
10377 <pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
10378 <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; x);</ins>
10379 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
10380 <ins>iterator       insert(iterator hint, value_type&amp;&amp; x);</ins>
10381 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
10382 <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
10383 <ins>template &lt;class InputIterator&gt;
10384   void insert(InputIterator first, InputIterator last);</ins>
10385 </pre>
10386
10387 <blockquote>
10388
10389 <p><ins>
10390 <i>Requires:</i> Those signatures taking a <tt>const
10391 value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
10392 be <tt>CopyConstructible</tt>.
10393 </ins></p>
10394
10395 <p><ins>
10396 The signature taking <tt>InputIterator</tt> parameters requires
10397 <tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
10398 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
10399 <tt>value_type</tt>.
10400 </ins></p>
10401
10402 </blockquote>
10403
10404 </blockquote>
10405
10406 <p>
10407 Add to 23.4.3.2 [unord.set.swap]:
10408 </p>
10409
10410 <blockquote>
10411 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10412   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
10413             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
10414 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10415   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
10416             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
10417 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10418   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
10419             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
10420 </pre>
10421 </blockquote>
10422
10423 <p><b><tt>unordered_multiset</tt></b></p>
10424
10425 <p>
10426 Change 23.4.4 [unord.multiset]:
10427 </p>
10428
10429 <blockquote><pre>class unordered_multiset
10430 {
10431     ...
10432     unordered_multiset(const unordered_multiset&amp;);
10433     <ins>unordered_multiset(unordered_multiset&amp;&amp;);</ins>
10434     ~unordered_multiset();
10435     unordered_multiset&amp; operator=(const unordered_multiset&amp;);
10436     <ins>unordered_multiset&amp; operator=(unordered_multiset&amp;&amp;);</ins>
10437     ...
10438     // modifiers
10439     iterator insert(const value_type&amp; obj);
10440     <ins>iterator insert(value_type&amp;&amp; obj);</ins>
10441     iterator       insert(iterator hint, const value_type&amp; obj);
10442     <ins>iterator       insert(iterator hint, value_type&amp;&amp; obj);</ins>
10443     const_iterator insert(const_iterator hint, const value_type&amp; obj);
10444     <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
10445     ...
10446     void swap(unordered_multiset&amp;<ins>&amp;</ins>);
10447     ...
10448 };
10449
10450 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10451   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
10452             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
10453
10454 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10455   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
10456             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
10457
10458 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10459   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
10460             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
10461 </pre></blockquote>
10462
10463 <p>
10464 Add to 23.4.4.1 [unord.multiset.cnstr]:
10465 </p>
10466
10467 <blockquote>
10468 <pre>template &lt;class InputIterator&gt;
10469   unordered_multiset(InputIterator f, InputIterator l,
10470                 size_type n = <i>implementation-defined</i>,
10471                 const hasher&amp; hf = hasher(),
10472                 const key_equal&amp; eql = key_equal(),
10473                 const allocator_type&amp; a = allocator_type());
10474 </pre>
10475
10476 <blockquote><p>
10477 <ins>
10478 <i>Requires:</i> If the iterator's dereference operator returns an
10479 lvalue or a const rvalue <tt>value_type</tt>, then the
10480 <tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
10481 </ins>
10482 </p></blockquote>
10483 </blockquote>
10484
10485 <p>
10486 Add new section [unord.multiset.modifiers]:
10487 </p>
10488
10489 <blockquote>
10490 <pre><ins>iterator insert(const value_type&amp; x);</ins>
10491 <ins>iterator insert(value_type&amp;&amp; x);</ins>
10492 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
10493 <ins>iterator       insert(iterator hint, value_type&amp;&amp; x);</ins>
10494 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
10495 <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
10496 <ins>template &lt;class InputIterator&gt;
10497   void insert(InputIterator first, InputIterator last);</ins>
10498 </pre>
10499
10500 <blockquote>
10501
10502 <p><ins>
10503 <i>Requires:</i> Those signatures taking a <tt>const
10504 value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
10505 be <tt>CopyConstructible</tt>.
10506 </ins></p>
10507
10508 <p><ins>
10509 The signature taking <tt>InputIterator</tt> parameters requires
10510 <tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
10511 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
10512 <tt>value_type</tt>.
10513 </ins></p>
10514
10515 </blockquote>
10516
10517 </blockquote>
10518
10519 <p>
10520 Add to 23.4.4.2 [unord.multiset.swap]:
10521 </p>
10522
10523 <blockquote>
10524 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10525   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
10526             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
10527 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10528   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
10529             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
10530 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
10531   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
10532             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
10533 </pre>
10534 </blockquote>
10535
10536
10537
10538
10539
10540
10541 <hr>
10542 <h3><a name="679"></a>679. resize parameter by value</h3>
10543 <p><b>Section:</b> 23.2 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
10544  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p>
10545 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
10546 <p><b>Discussion:</b></p>
10547 <p>
10548 The C++98 standard specifies that one member function alone of the containers
10549 passes its parameter (<tt>T</tt>) by value instead of by const reference:
10550 </p>
10551
10552 <blockquote><pre>void resize(size_type sz, T c = T());
10553 </pre></blockquote>
10554
10555 <p>
10556 This fact has been discussed / debated repeatedly over the years, the first time
10557 being even before C++98 was ratified.  The rationale for passing this parameter by
10558 value has been:
10559 </p>
10560
10561 <blockquote>
10562 <p>
10563 So that self referencing statements are guaranteed to work, for example:
10564 </p>
10565 <blockquote><pre>v.resize(v.size() + 1, v[0]);
10566 </pre></blockquote>
10567 </blockquote>
10568
10569 <p>
10570 However this rationale is not convincing as the signature for <tt>push_back</tt> is:
10571 </p>
10572
10573 <blockquote><pre>void push_back(const T&amp; x);
10574 </pre></blockquote>
10575
10576 <p>
10577 And <tt>push_back</tt> has similar semantics to <tt>resize</tt> (append).
10578 And <tt>push_back</tt> must also work in the self referencing case:
10579 </p>
10580
10581 <blockquote><pre>v.push_back(v[0]);  // must work
10582 </pre></blockquote>
10583
10584 <p>
10585 The problem with passing <tt>T</tt> by value is that it can be significantly more
10586 expensive than passing by reference.  The converse is also true, however when it is
10587 true it is usually far less dramatic (e.g. for scalar types).
10588 </p>
10589
10590 <p>
10591 Even with move semantics available, passing this parameter by value can be expensive.
10592 Consider for example <tt>vector&lt;vector&lt;int&gt;&gt;</tt>:
10593 </p>
10594
10595 <blockquote><pre>std::vector&lt;int&gt; x(1000);
10596 std::vector&lt;std::vector&lt;int&gt;&gt; v;
10597 ...
10598 v.resize(v.size()+1, x);
10599 </pre></blockquote>
10600
10601 <p>
10602 In the pass-by-value case, <tt>x</tt> is copied once to the parameter of
10603 <tt>resize</tt>.  And then internally, since the code can not know at compile
10604 time by how much <tt>resize</tt> is growing the <tt>vector</tt>, <tt>x</tt> is
10605 usually copied (not moved) a second time from <tt>resize</tt>'s parameter into its proper place
10606 within the <tt>vector</tt>.
10607 </p>
10608
10609 <p>
10610 With pass-by-const-reference, the <tt>x</tt> in the above example need be copied
10611 only once.  In this case, <tt>x</tt> has an expensive copy constructor and so any
10612 copies that can be saved represents a significant savings.
10613 </p>
10614
10615 <p>
10616 If we can be efficient for <tt>push_back</tt>, we should be efficient for <tt>resize</tt>
10617 as well.  The resize taking a reference parameter has been coded and shipped in the
10618 CodeWarrior library with no reports of problems which I am aware of.
10619 </p>
10620
10621
10622
10623 <p><b>Proposed resolution:</b></p>
10624 <p>
10625 Change 23.2.2 [deque], p2:
10626 </p>
10627
10628 <blockquote><pre>class deque {
10629    ...
10630    void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
10631 </pre></blockquote>
10632
10633 <p>
10634 Change 23.2.2.2 [deque.capacity], p3:
10635 </p>
10636
10637 <blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
10638 </pre></blockquote>
10639
10640 <p>
10641 Change 23.2.3 [list], p2:
10642 </p>
10643
10644 <blockquote><pre>class list {
10645    ...
10646    void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
10647 </pre></blockquote>
10648
10649 <p>
10650 Change 23.2.3.2 [list.capacity], p3:
10651 </p>
10652
10653 <blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
10654 </pre></blockquote>
10655
10656 <p>
10657 Change 23.2.5 [vector], p2:
10658 </p>
10659
10660 <blockquote><pre>class vector {
10661    ...
10662    void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
10663 </pre></blockquote>
10664
10665 <p>
10666 Change 23.2.5.2 [vector.capacity], p11:
10667 </p>
10668
10669 <blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
10670 </pre></blockquote>
10671
10672
10673
10674
10675
10676
10677 <hr>
10678 <h3><a name="680"></a>680. move_iterator operator-&gt; return</h3>
10679 <p><b>Section:</b> 24.4.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
10680  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p>
10681 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
10682 <p><b>Discussion:</b></p>
10683 <p>
10684 <tt>move_iterator</tt>'s <tt>operator-&gt;</tt> return type <tt>pointer</tt>
10685 does not consistently match the type which is returned in the description
10686 in 24.4.3.3.5 [move.iter.op.ref].
10687 </p>
10688
10689 <blockquote><pre>template &lt;class Iterator&gt;
10690 class move_iterator {
10691 public:
10692     ...
10693     typedef typename iterator_traits&lt;Iterator&gt;::pointer pointer;
10694     ...
10695     pointer operator-&gt;() const {return current;}
10696     ...
10697 private:
10698     Iterator current; // exposition only
10699 };
10700 </pre></blockquote>
10701
10702
10703 <p>
10704 There are two possible fixes.
10705 </p>
10706
10707 <ol>
10708 <li><tt>pointer operator-&gt;() const {return &amp;*current;}</tt></li>
10709 <li><tt>typedef Iterator pointer;</tt></li>
10710 </ol>
10711
10712 <p>
10713 The first solution is the one chosen by <tt>reverse_iterator</tt>.  A potential
10714 disadvantage of this is it may not work well with iterators which return a
10715 proxy on dereference and that proxy has overloaded <tt>operator&amp;()</tt>.  Proxy
10716 references often need to overloaad <tt>operator&amp;()</tt> to return a proxy
10717 pointer.  That proxy pointer may or may not be the same type as the iterator's
10718 <tt>pointer</tt> type.
10719 </p>
10720
10721 <p>
10722 By simply returning the <tt>Iterator</tt> and taking advantage of the fact that
10723 the language forwards calls to <tt>operator-&gt;</tt> automatically until it
10724 finds a non-class type, the second solution avoids the issue of an overloaded
10725 <tt>operator&amp;()</tt> entirely.
10726 </p>
10727
10728 <p><b>Proposed resolution:</b></p>
10729 <p>
10730 Change the synopsis in 24.4.3.1 [move.iterator]:
10731 </p>
10732
10733 <blockquote><pre>typedef <del>typename iterator_traits&lt;</del>Iterator<del>&gt;::pointer</del> pointer;
10734 </pre></blockquote>
10735
10736
10737
10738
10739
10740
10741 <hr>
10742 <h3><a name="684"></a>684. Unclear which members of match_results should be used in comparison</h3>
10743 <p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
10744  <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p>
10745 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.results">active issues</a> in [re.results].</p>
10746 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p>
10747 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
10748 <p><b>Discussion:</b></p>
10749 <p>
10750 In 28.4 [re.syn] of N2284, two template functions
10751 are declared here:
10752 </p>
10753 <blockquote><pre>// 28.10, class template match_results:
10754 &nbsp; &lt;<i>snip</i>&gt;
10755 // match_results comparisons
10756 &nbsp; template &lt;class BidirectionalIterator, class Allocator&gt;
10757 &nbsp; &nbsp; bool operator== (const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
10758 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
10759 &nbsp; template &lt;class BidirectionalIterator, class Allocator&gt;
10760 &nbsp; &nbsp; bool operator!= (const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
10761 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
10762
10763 // 28.10.6, match_results swap:
10764 </pre></blockquote>
10765
10766 <p>
10767 But the details of these two bool operator functions (i.e., which members of
10768 <tt>match_results</tt> should be used in comparison) are not described in any
10769 following sections.
10770 </p>
10771
10772 <p><i>[
10773 John adds:
10774 ]</i></p>
10775
10776
10777 <blockquote><p>
10778 That looks like a bug: <tt>operator==</tt> should return <tt>true</tt> only if
10779 the two objects refer to the same match - ie if one object was constructed as a
10780 copy of the other.
10781 </p></blockquote>
10782
10783 <p><i>[
10784 Kona (2007): Bill and Pete to add minor wording to that proposed in
10785 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
10786 ]</i></p>
10787
10788
10789
10790 <p><b>Proposed resolution:</b></p>
10791 <p>
10792 Add a new section after 28.10.6 [re.results.swap], which reads:
10793 </p>
10794 <p>
10795 28.10.7 match_results non-member functions.
10796 </p>
10797
10798 <blockquote>
10799 <pre>template&lt;class BidirectionalIterator, class Allocator&gt;
10800   bool operator==(const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
10801                   const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
10802 </pre>
10803 <blockquote>
10804 <p>
10805 <i>Returns:</i> <tt>true</tt> only if the two objects refer to the same match.
10806 </p>
10807 </blockquote>
10808 </blockquote>
10809
10810 <blockquote>
10811 <pre>template&lt;class BidirectionalIterator, class Allocator&gt;
10812   bool operator!=(const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
10813                   const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
10814 </pre>
10815 <blockquote>
10816 <p>
10817 <i>Returns:</i> <tt>!(m1 == m2)</tt>.
10818 </p>
10819 </blockquote>
10820 </blockquote>
10821
10822 <blockquote>
10823 <pre>template&lt;class BidirectionalIterator, class Allocator&gt;
10824   void swap(match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
10825             match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
10826 </pre>
10827 <blockquote>
10828 <p>
10829 <i>Returns:</i> <tt>m1.swap(m2)</tt>.
10830 </p>
10831 </blockquote>
10832 </blockquote>
10833
10834
10835
10836
10837
10838 <hr>
10839 <h3><a name="685"></a>685. reverse_iterator/move_iterator difference has invalid signatures</h3>
10840 <p><b>Section:</b> 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
10841  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-06-10</p>
10842 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
10843 <p><b>Discussion:</b></p>
10844 <p>
10845 In C++03 the difference between two <tt>reverse_iterators</tt>
10846 </p>
10847 <blockquote><pre>ri1 - ri2
10848 </pre></blockquote>
10849 <p>
10850 is possible to compute only if both iterators have the same base
10851 iterator. The result type is the <tt>difference_type</tt> of the base iterator.
10852 </p>
10853 <p>
10854 In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff]
10855 </p>
10856 <blockquote><pre>template&lt;class Iterator1, class Iterator2&gt;
10857 typename reverse_iterator&lt;Iterator&gt;::difference_type
10858 &nbsp; &nbsp;operator-(const reverse_iterator&lt;Iterator1&gt;&amp; x,
10859 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; const reverse_iterator&lt;Iterator2&gt;&amp; y);
10860 </pre></blockquote>
10861 <p>
10862 The return type is the same as the C++03 one, based on the no longer
10863 present <tt>Iterator</tt> template parameter.
10864 </p>
10865 <p>
10866 Besides being slightly invalid, should this operator work only when
10867 <tt>Iterator1</tt> and <tt>Iterator2</tt> has the same <tt>difference_type</tt>? Or should the
10868 implementation choose one of them? Which one?
10869 </p>
10870 <p>
10871 The same problem now also appears in <tt>operator-()</tt> for <tt>move_iterator</tt>
10872 24.4.3.3.14 [move.iter.nonmember].
10873 </p>
10874
10875
10876 <p><b>Proposed resolution:</b></p>
10877 <p>
10878 Change the synopsis in 24.4.1.1 [reverse.iterator]:
10879 </p>
10880
10881 <blockquote>
10882 <pre>template &lt;class Iterator1, class Iterator2&gt;
10883   <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-(
10884     const reverse_iterator&lt;Iterator1&gt;&amp; x,
10885     const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(operator-(Iterator1, Iterator2))</ins>;
10886 </pre>
10887 <blockquote>
10888 <p>
10889 <i>Returns:</i> <tt>y.current - x.current</tt>.
10890 </p>
10891 </blockquote>
10892 </blockquote>
10893
10894 <p>
10895 Change 24.4.1.3.19 [reverse.iter.opdiff]:
10896 </p>
10897
10898 <blockquote>
10899 <pre>template &lt;class Iterator1, class Iterator2&gt;
10900   <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-(
10901     const reverse_iterator&lt;Iterator1&gt;&amp; x,
10902     const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(operator-(Iterator1, Iterator2))</ins>;
10903 </pre>
10904 <blockquote>
10905 <p>
10906 <i>Returns:</i> <tt>y.current - x.current</tt>.
10907 </p>
10908 </blockquote>
10909 </blockquote>
10910
10911
10912 <p>
10913 Change the synopsis in 24.4.3.1 [move.iterator]:
10914 </p>
10915
10916 <blockquote>
10917 <pre>template &lt;class Iterator1, class Iterator2&gt;
10918   <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-(
10919     const move_iterator&lt;Iterator1&gt;&amp; x,
10920     const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(operator-(Iterator1, Iterator2))</ins>;
10921 </pre>
10922 <blockquote>
10923 <p>
10924 <i>Returns:</i> <tt>y.current - x.current</tt>.
10925 </p>
10926 </blockquote>
10927 </blockquote>
10928
10929 <p>
10930 Change 24.4.3.3.14 [move.iter.nonmember]:
10931 </p>
10932
10933 <blockquote>
10934 <pre>template &lt;class Iterator1, class Iterator2&gt;
10935   <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-(
10936     const move_iterator&lt;Iterator1&gt;&amp; x,
10937     const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(operator-(Iterator1, Iterator2))</ins>;
10938 </pre>
10939 <blockquote>
10940 <p>
10941 <i>Returns:</i> <tt>x.base() - y.base()</tt>.
10942 </p>
10943 </blockquote>
10944 </blockquote>
10945
10946
10947
10948
10949
10950 <hr>
10951 <h3><a name="686"></a>686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type</h3>
10952 <p><b>Section:</b> 20.6.5.2.4 [unique.ptr.single.observers], 20.6.6.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
10953  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-06-14</p>
10954 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
10955 <p><b>Discussion:</b></p>
10956 <p>
10957 The standard library uses the <tt>operator <i>unspecified-bool-type</i>() const</tt> idiom in
10958 five places. In three of those places (20.5.15.2.3 [func.wrap.func.cap], function capacity
10959 for example) the returned value is constrained to disallow
10960 unintended conversions to int. The standardese is
10961 </p>
10962 <blockquote><p>
10963 The return type shall not be convertible to <tt>int</tt>.
10964 </p></blockquote>
10965 <p>
10966 This constraint is omitted for <tt>unique_ptr</tt> and <tt>shared_ptr</tt>. It should be added for those.
10967 </p>
10968
10969
10970 <p><b>Proposed resolution:</b></p>
10971 <p>
10972 To the <i>Returns</i> paragraph for <tt>operator <i>unspecified-bool-type</i>()
10973 const</tt>
10974 of 20.6.5.2.4 [unique.ptr.single.observers] paragraph 11 and 20.6.6.2.5
10975 [util.smartptr.shared.obs] paragraph 16, add the sentence:
10976 </p>
10977 <blockquote><p>
10978 The return type shall not be convertible to <tt>int</tt>.
10979 </p></blockquote>
10980
10981
10982 <p><i>[
10983 Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue.
10984 ]</i></p>
10985
10986
10987
10988
10989
10990 <hr>
10991 <h3><a name="687"></a>687. shared_ptr conversion constructor not constrained</h3>
10992 <p><b>Section:</b> 20.6.6.2.1 [util.smartptr.shared.const], 20.6.6.3.1 [util.smartptr.weak.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
10993  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
10994 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
10995 <p><b>Discussion:</b></p>
10996 <p>
10997 Since all conversions from <tt>shared_ptr&lt;T&gt;</tt> to <tt>shared_ptr&lt;U&gt;</tt> have the same
10998 rank regardless of the relationship between <tt>T</tt> and <tt>U</tt>, reasonable user
10999 code that works with raw pointers fails with <tt>shared_ptr</tt>:
11000 </p>
11001
11002 <blockquote><pre>void f( shared_ptr&lt;void&gt; );
11003 void f( shared_ptr&lt;int&gt; );
11004
11005 int main()
11006 {
11007 &nbsp;&nbsp;f( shared_ptr&lt;double&gt;() ); // ambiguous
11008 }
11009 </pre></blockquote>
11010
11011 <p>
11012 Now that we officially have <tt>enable_if</tt>, we can constrain the constructor
11013 and the corresponding assignment operator to only participate in the
11014 overload resolution when the pointer types are compatible.
11015 </p>
11016
11017
11018 <p><b>Proposed resolution:</b></p>
11019 <p>
11020 In 20.6.6.2.1 [util.smartptr.shared.const], change:
11021 </p>
11022
11023 <blockquote><p>
11024 -14- <i>Requires:</i> <del>For the second constructor</del> <ins>The
11025 second constructor shall not participate in the overload resolution
11026 unless</ins> <tt>Y*</tt> <del>shall be</del> <ins>is implicitly</ins> convertible
11027 to <tt>T*</tt>.
11028 </p></blockquote>
11029
11030 <p>
11031 In 20.6.6.3.1 [util.smartptr.weak.const], change:
11032 </p>
11033
11034 <blockquote>
11035 <pre><del>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</del>
11036 <del>weak_ptr(weak_ptr const&amp; r);</del>
11037 <del>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</del>
11038 <ins>weak_ptr(weak_ptr const&amp; r);</ins>
11039 <ins>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</ins>
11040 <ins>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</ins>
11041 </pre>
11042 <blockquote><p>
11043 -4- <i>Requires:</i> <del>For</del> <del>t</del><ins>T</ins>he second and
11044 third constructors<del>,</del> <ins>shall not participate in the
11045 overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del>
11046 <ins>is implicitly</ins> convertible to <tt>T*</tt>.
11047 </p></blockquote>
11048 </blockquote>
11049
11050
11051
11052
11053
11054
11055 <hr>
11056 <h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3>
11057 <p><b>Section:</b> 20.5.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
11058  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
11059 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#refwrap.const">active issues</a> in [refwrap.const].</p>
11060 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p>
11061 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
11062 <p><b>Discussion:</b></p>
11063 <p>
11064 A <tt>reference_wrapper</tt> can be constructed from an rvalue, either by using
11065 the constructor, or via <tt>cref</tt> (and <tt>ref</tt> in some corner cases). This leads
11066 to a dangling reference being stored into the <tt>reference_wrapper</tt> object.
11067 Now that we have a mechanism to detect an rvalue, we can fix them to
11068 disallow this source of undefined behavior.
11069 </p>
11070
11071 <p>
11072 Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
11073 </p>
11074
11075
11076
11077 <p><b>Proposed resolution:</b></p>
11078 <p>
11079 In 20.5.5 [refwrap], add:
11080 </p>
11081
11082 <blockquote><pre><ins>private:</ins>
11083 <ins>&nbsp;&nbsp;explicit reference_wrapper(T&amp;&amp;);</ins>
11084 </pre></blockquote>
11085
11086 <p>
11087 In 20.5.5.1 [refwrap.const], add:
11088 </p>
11089
11090 <blockquote>
11091 <pre><ins>explicit reference_wrapper(T&amp;&amp;);</ins>
11092 </pre>
11093 <blockquote><p>
11094 <ins>-?- Not defined to disallow creating a <tt>reference_wrapper</tt> from an rvalue.</ins>
11095 </p></blockquote>
11096 </blockquote>
11097
11098 <p>
11099 In the synopsis of <tt>&lt;functional&gt;</tt> (20.5.5 [refwrap]), change the declarations
11100 of <tt>ref</tt> and <tt>cref</tt> to:
11101 </p>
11102
11103 <blockquote><pre>template&lt;class T&gt; reference_wrapper&lt;T&gt; ref(T&amp;<ins>&amp;</ins>);
11104 template&lt;class T&gt; reference_wrapper&lt;const T&gt; cref(<del>const</del> T&amp;<ins>&amp;</ins>);
11105 </pre></blockquote>
11106
11107 <p>
11108 In 20.5.5.5 [refwrap.helpers], change:
11109 </p>
11110
11111 <blockquote>
11112 <pre>template&lt;class T&gt; reference_wrapper&lt;T&gt; ref(T&amp;<ins>&amp;</ins> t);
11113 </pre>
11114 <blockquote>
11115 <p>
11116 <ins>-1- <i>Requires:</i> <tt>t</tt> shall be an lvalue.</ins>
11117 </p>
11118 </blockquote>
11119 </blockquote>
11120
11121 <p>and change:</p>
11122
11123 <blockquote>
11124 <pre>template&lt;class T&gt; reference_wrapper&lt;const T&gt; cref(<del>const</del> T&amp;<ins>&amp;</ins> t);
11125 </pre>
11126 <blockquote>
11127 <p>
11128 <ins>-6- <i>Requires:</i> <tt>t</tt> shall be an lvalue.</ins>
11129 </p>
11130 </blockquote>
11131 </blockquote>
11132
11133
11134
11135 <p><i>[
11136 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
11137 addresses the first part of the resolution but not the second.
11138 ]</i></p>
11139
11140
11141
11142
11143
11144 <hr>
11145 <h3><a name="689"></a>689. reference_wrapper constructor overly constrained</h3>
11146 <p><b>Section:</b> 20.5.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
11147  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
11148 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#refwrap.const">active issues</a> in [refwrap.const].</p>
11149 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p>
11150 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
11151 <p><b>Discussion:</b></p>
11152 <p>
11153 The constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary
11154 motivation behind this is the safety problem with respect to rvalues,
11155 which is addressed by the proposed resolution of the previous issue.
11156 Therefore we should consider relaxing the requirements on the
11157 constructor since requests for the implicit conversion keep resurfacing.
11158 </p>
11159 <p>
11160 Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
11161 </p>
11162
11163
11164 <p><b>Proposed resolution:</b></p>
11165 <p>
11166 Remove the <tt>explicit</tt> from the constructor of <tt>reference_wrapper</tt>. If the
11167 proposed resolution of the previous issue is accepted, remove the
11168 <tt>explicit</tt> from the <tt>T&amp;&amp;</tt> constructor as well to keep them in sync.
11169 </p>
11170
11171
11172
11173
11174
11175 <hr>
11176 <h3><a name="691"></a>691. const_local_iterator cbegin, cend missing from TR1</h3>
11177 <p><b>Section:</b> 23.4 [unord], TR1 6.3 [tr.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
11178  <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2007-06-14</p>
11179 <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>
11180 <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>
11181 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
11182 <p><b>Discussion:</b></p>
11183 <p>
11184 The last version of TR1 does not include the following member
11185 functions
11186 for unordered containers:
11187 </p>
11188
11189 <blockquote><pre>const_local_iterator cbegin(size_type n) const;
11190 const_local_iterator cend(size_type n) const;
11191 </pre></blockquote>
11192
11193 <p>
11194 which looks like an oversight to me. I've checked th TR1 issues lists
11195 and the latest working draft of the C++0x std (N2284) and haven't
11196 found any mention to these menfuns or to their absence.
11197 </p>
11198 <p>
11199 Is this really an oversight, or am I missing something?
11200 </p>
11201
11202
11203
11204 <p><b>Proposed resolution:</b></p>
11205 <p>
11206 Add the following two rows to table 93 (unordered associative container
11207 requirements) in section 23.1.3 [unord.req]:
11208 </p>
11209
11210 <blockquote>
11211 <table border="1">
11212 <caption>Unordered associative container requirements (in addition to container)</caption>
11213 <tbody><tr>
11214 <th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
11215 </tr>
11216 <tr>
11217 <td><ins><tt>b.cbegin(n)</tt></ins></td> <td><ins><tt>const_local_iterator</tt></ins></td> <td><ins><tt>n</tt> shall be in the range <tt>[0, bucket_count())</tt>. Note: <tt>[b.cbegin(n), b.cend(n))</tt> is a valid range containing all of the elements in the <tt>n</tt><sup><i>th</i></sup> bucket.</ins></td> <td><ins>Constant</ins></td>
11218 </tr>
11219 <tr>
11220 <td><ins><tt>b.cend(n)</tt></ins></td> <td><ins><tt>const_local_iterator</tt></ins></td> <td><ins><tt>n</tt> shall be in the range <tt>[0, bucket_count())</tt>.</ins></td> <td><ins>Constant</ins></td>
11221 </tr>
11222 </tbody></table>
11223 </blockquote>
11224
11225 <p>
11226 Add to the synopsis in 23.4.1 [unord.map]:
11227 </p>
11228
11229 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
11230 const_local_iterator cend(size_type n) const;</ins>
11231 </pre></blockquote>
11232
11233 <p>
11234 Add to the synopsis in 23.4.2 [unord.multimap]:
11235 </p>
11236
11237 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
11238 const_local_iterator cend(size_type n) const;</ins>
11239 </pre></blockquote>
11240
11241 <p>
11242 Add to the synopsis in 23.4.3 [unord.set]:
11243 </p>
11244
11245 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
11246 const_local_iterator cend(size_type n) const;</ins>
11247 </pre></blockquote>
11248
11249 <p>
11250 Add to the synopsis in 23.4.4 [unord.multiset]:
11251 </p>
11252
11253 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
11254 const_local_iterator cend(size_type n) const;</ins>
11255 </pre></blockquote>
11256
11257
11258
11259
11260
11261
11262 <hr>
11263 <h3><a name="692"></a>692. <code>get_money</code> and <code>put_money</code> should be&nbsp;formatted I/O functions</h3>
11264 <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#New">New</a>
11265  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
11266 <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>
11267 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
11268 <p><b>Discussion:</b></p>
11269 <p>
11270 In a private email Bill Plauger notes:
11271 </p>
11272 <blockquote><p>
11273 I &nbsp;believe that &nbsp;the function &nbsp;that &nbsp;implements <code>get_money</code>
11274 [from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2072.html">N2072</a>]
11275 should behave &nbsp;as a &nbsp;formatted input function, &nbsp;and the &nbsp;function that
11276 implements <code>put_money</code> should &nbsp;behave as a formatted output
11277 function. This &nbsp;has implications regarding the &nbsp;skipping of whitespace
11278 and the handling of errors, among other things.
11279 </p>
11280 <p>
11281 The words &nbsp;don't say that &nbsp;right now and &nbsp;I'm far from &nbsp;convinced that
11282 such a change is editorial.
11283 </p></blockquote>
11284 <p>
11285 Martin's response:
11286 </p>
11287 <blockquote><p>
11288 I agree that the manipulators should handle exceptions the same way as
11289 formatted I/O functions do. The text in N2072 assumes so but the
11290 <i>Returns</i> clause explicitly omits exception handling for the sake
11291 of brevity. The spec should be clarified to that effect.
11292 </p>
11293 <p>
11294 As for dealing &nbsp;with whitespace, I also agree it &nbsp;would make sense for
11295 the extractors &nbsp;and inserters involving the new &nbsp;manipulators to treat
11296 it the same way as formatted I/O.
11297 </p></blockquote>
11298
11299
11300 <p><b>Proposed resolution:</b></p>
11301 <p>
11302 Add &nbsp;a new &nbsp;paragraph immediately &nbsp;above &nbsp;p4 of 27.6.4 [ext.manip] with &nbsp;the
11303 following text:
11304 </p>
11305 <blockquote><p>
11306 <i>Effects</i>: &nbsp;The &nbsp;&nbsp;expression &nbsp;<code><i>in</i> &gt;&gt; get_money(mon, intl)</code>
11307 described below behaves as a formatted input function (as
11308 described in 27.6.1.2.1 [istream.formatted.reqmts]).
11309 </p></blockquote>
11310 <p>
11311 Also change p4 of 27.6.4 [ext.manip] as follows:
11312 </p>
11313 <blockquote><p>
11314 <i>Returns</i>: An object <code>s</code> of unspecified type such that
11315 if <code>in</code> is &nbsp;an object of type <code>basic_istream&lt;charT,
11316 traits&gt;</code> &nbsp;&nbsp;&nbsp;then &nbsp;&nbsp;&nbsp;the &nbsp;&nbsp;&nbsp;expression &nbsp;&nbsp;<code><i>in</i> &gt;&gt; get_money(mon, intl)</code> behaves as <ins>a formatted input function
11317 that &nbsp;&nbsp;&nbsp;calls &nbsp;&nbsp;&nbsp;</ins><code>f(in, mon, intl)</code><del> &nbsp;&nbsp;&nbsp;were
11318 called</del>. The function <code>f</code> can be defined as...
11319 </p></blockquote>
11320
11321
11322
11323
11324
11325 <hr>
11326 <h3><a name="693"></a>693. <code>std::bitset::all()</code> missing</h3>
11327 <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#Ready">Ready</a>
11328  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
11329 <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>
11330 <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>
11331 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
11332 <p><b>Discussion:</b></p>
11333 <p>
11334 The  <code>bitset</code> class template  provides the  member function
11335 <code>any()</code> to determine whether an  object of the type has any
11336 bits  set, and  the member  function <code>none()</code>  to determine
11337 whether all of an object's  bits are clear. However, the template does
11338 not   provide  a   corresponding  function   to  discover   whether  a
11339 <code>bitset</code>  object  has  all  its  bits  set.   While  it  is
11340 possible,  even easy,  to  obtain this  information  by comparing  the
11341 result of <code>count()</code>  with the result of <code>size()</code>
11342 for  equality  (i.e.,  via  <code>b.count()  ==  b.size()</code>)  the
11343 operation  is   less  efficient   than  a  member   function  designed
11344 specifically  for that purpose  could be.   (<code>count()</code> must
11345 count  all non-zero bits  in a  <code>bitset</code> a  word at  a time
11346 while <code>all()</code> could stop counting as soon as it encountered
11347 the first word with a zero bit).
11348 </p>
11349
11350
11351 <p><b>Proposed resolution:</b></p>
11352 <p>
11353 Add  a declaration of the new  member function <code>all()</code> to the
11354 defintion of the <code>bitset</code> template in 23.3.5 [template.bitset], p1,
11355 right above the declaration of <code>any()</code> as shown below:
11356 </p>
11357
11358 <blockquote><pre>bool operator!=(const bitset&lt;N&gt;&amp; rhs) const;
11359 bool test(size_t pos) const;
11360 <ins>bool all() const;</ins>
11361 bool any() const;
11362 bool none() const;
11363 </pre></blockquote>
11364
11365 <p>
11366 Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text:
11367 </p>
11368 <blockquote><p>
11369 <code>bool all() const;</code>
11370 </p>
11371 <blockquote>
11372 <i>Returns</i>: <code>count() == size()</code>.
11373 </blockquote>
11374 </blockquote>
11375
11376 <p>
11377 In  addition,   change  the  description   of  <code>any()</code>  and
11378 <code>none()</code>   for  consistency   with   <code>all()</code>  as
11379 follows:
11380 </p>
11381 <blockquote><p>
11382 <code>bool any() const;</code>
11383 </p>
11384 <blockquote>
11385 <p>
11386 <i>Returns</i>: <del><code>true</code> if any bit in <code>*this</code>
11387 is one</del><ins><code>count() != 0</code></ins>.
11388 </p>
11389 </blockquote>
11390 <p>
11391 <code>bool none() const;</code>
11392 </p>
11393 <blockquote>
11394 <p>
11395 <i>Returns</i>: <del><code>true</code> if no bit in <code>*this</code>
11396 is one</del><ins><code>count() == 0</code></ins>.
11397 </p>
11398 </blockquote>
11399 </blockquote>
11400
11401
11402
11403
11404
11405 <hr>
11406 <h3><a name="694"></a>694. <code>std::bitset</code> and <code>long long</code></h3>
11407 <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#Ready">Ready</a>
11408  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
11409 <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>
11410 <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>
11411 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
11412 <p><b>Discussion:</b></p>
11413 <p>
11414 Objects of the  <code>bitset</code> class template specializations can
11415 be constructed from  and explicitly converted to values  of the widest
11416 C++ integer  type, <code>unsigned long</code>.   With the introduction
11417 of  <code>long long</code> into  the language  the template  should be
11418 enhanced to make it possible  to interoperate with values of this type
11419 as well, or  perhaps <code>uintmax_t</code>.  See c++std-lib-18274 for
11420 a brief discussion in support of this change.
11421 </p>
11422
11423
11424 <p><b>Proposed resolution:</b></p>
11425 <p>
11426 For simplicity,  instead of  adding overloads for  <code>unsigned long
11427 long</code> and dealing with possible ambiguities in the spec, replace
11428 the <code>bitset</code> ctor  that takes an <code>unsigned long</code>
11429 argument  with  one  taking  <code>unsigned long  long</code>  in  the
11430 definition  of the  template as  shown below.   (The  standard permits
11431 implementations  to add  overloads on  other integer  types  or employ
11432 template tricks to  achieve the same effect provided  they don't cause
11433 ambiguities or changes in behavior.)
11434 </p>
11435 <blockquote>
11436 <pre>// [bitset.cons] constructors:
11437 bitset();
11438 bitset(unsigned <ins>long</ins> long val);
11439 template&lt;class charT, class traits, class Allocator&gt;
11440 explicit bitset(
11441                 const basic_string&lt;charT,traits,Allocator&gt;&amp; str,
11442                 typename basic_string&lt;charT,traits,Allocator&gt;::size_type pos = 0,
11443                 typename basic_string&lt;charT,traits,Allocator&gt;::size_type n =
11444                     basic_string&lt;charT,traits,Allocator&gt;::npos);
11445 </pre>
11446 </blockquote>
11447 <p>
11448 Make a corresponding change in 23.3.5.1 [bitset.cons], p2:
11449 </p>
11450 <blockquote>
11451 <p>
11452 <code>bitset(unsigned <ins>long</ins> long val);</code>
11453 </p>
11454 <blockquote>
11455 <i>Effects</i>:  Constructs   an  object  of   class  bitset&lt;N&gt;,
11456 initializing  the  first <code><i>M</i></code>  bit  positions to  the
11457 corresponding      bit     values      in     <code><i>val</i></code>.
11458 <code><i>M</i></code> is the  smaller of <code><i>N</i></code> and the
11459 number of bits in  the value representation (section [basic.types]) of
11460 <code>unsigned  <ins> long</ins> long</code>.   If  <code><i>M</i> &lt;
11461 <i>N</i></code>  <ins>is  <code>true</code></ins>,  the remaining  bit
11462 positions are initialized to zero.
11463 </blockquote>
11464 </blockquote>
11465
11466 <p>
11467 Additionally, introduce a new member function <code>to_ullong()</code>
11468 to make  it possible to  convert <code>bitset</code> to values  of the
11469 new  type. Add  the following  declaration  to the  definition of  the
11470 template, immediate  after the declaration  of <code>to_ulong()</code>
11471 in 23.3.5 [template.bitset], p1, as shown below:
11472 </p>
11473 <blockquote>
11474 <pre>// element access:
11475 bool operator[](size_t pos) const; // for b[i];
11476 reference operator[](size_t pos); // for b[i];
11477 unsigned long to_ulong() const;
11478 <ins>unsigned long long to_ullong() const;</ins>
11479 template &lt;class charT, class traits, class Allocator&gt;
11480 basic_string&lt;charT, traits, Allocator&gt; to_string() const;
11481 </pre>
11482 </blockquote>
11483 <p>
11484 And add a description of  the new member function to 23.3.5.2 [bitset.members],
11485 below  the  description of  the  existing <code>to_ulong()</code>  (if
11486 possible), with the following text:
11487 </p>
11488 <blockquote>
11489 <p>
11490 <code>unsigned long long to_ullong() const;</code>
11491 </p>
11492 <blockquote>
11493 <i>Throws</i>:  <code>overflow_error</code>   if  the  integral  value
11494 <code><i>x</i></code> corresponding to  the bits in <code>*this</code>
11495 cannot be represented as type <code>unsigned long long</code>.
11496 </blockquote>
11497 <blockquote>
11498 <i>Returns:</i> <code><i>x</i></code>.
11499 </blockquote>
11500 </blockquote>
11501
11502
11503
11504
11505
11506 <hr>
11507 <h3><a name="695"></a>695. ctype&lt;char&gt;::classic_table() not accessible</h3>
11508 <p><b>Section:</b> 22.2.1.3 [facet.ctype.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
11509  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
11510 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
11511 <p><b>Discussion:</b></p>
11512 <p>
11513 The   <code>ctype&lt;char&gt;::classic_table()</code>   static  member
11514 function    returns    a    pointer    to   an    array    of    const
11515 <code>ctype_base::mask</code>    objects    (enums)   that    contains
11516 <code>ctype&lt;char&gt;::table_size</code>    elements.    The   table
11517 describes the properties of the character set in the "C" locale (i.e.,
11518 whether a  character at an index  given by its value  is alpha, digit,
11519 punct,   etc.),   and   is    typically   used   to   initialize   the
11520 <code>ctype&lt;char&gt;</code>  facet in the  classic "C"  locale (the
11521 protected      <code>ctype&lt;char&gt;</code>      member     function
11522 <code>table()</code>    then    returns     the    same    value    as
11523 <code>classic_table()</code>).
11524 </p>
11525 <p>
11526 However, while <code>ctype&lt;char&gt;::table_size</code> (the size of
11527 the   table)    is   a   public    static   const   member    of   the
11528 <code>ctype&lt;char&gt;</code>           specialization,           the
11529 <code>classic_table()</code> static member function is protected. That
11530 makes getting at the classic  data less than convenient (i.e., one has
11531 to create  a whole derived class just  to get at the  masks array). It
11532 makes  little sense  to expose  the size  of the  table in  the public
11533 interface while making the table itself protected, especially when the
11534 table is a constant object.
11535 </p>
11536 <p>
11537 The  same argument  can be  made for  the non-static  protected member
11538 function <code>table()</code>.
11539 </p>
11540
11541
11542 <p><b>Proposed resolution:</b></p>
11543 <p>
11544 Make     the    <code>ctype&lt;char&gt;::classic_table()</code>    and
11545 <code>ctype&lt;char&gt;::table()</code>  member  functions  public  by
11546 moving their declarations into the public section of the definition of
11547 specialization in 22.2.1.3 [facet.ctype.special] as shown below:
11548 </p>
11549 <blockquote>
11550 <pre>  static locale::id id;
11551   static const size_t table_size = IMPLEMENTATION_DEFINED;
11552 <del>protected:</del>
11553   const mask* table() const throw();
11554   static const mask* classic_table() throw();
11555 <ins>protected:</ins>
11556
11557 ~ctype(); // virtual
11558 virtual char do_toupper(char c) const;
11559 </pre>
11560 </blockquote>
11561
11562
11563
11564
11565
11566 <hr>
11567 <h3><a name="696"></a>696. <code>istream::operator&gt;&gt;(int&amp;)</code> broken</h3>
11568 <p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
11569  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-23</p>
11570 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.formatted.arithmetic">active issues</a> in [istream.formatted.arithmetic].</p>
11571 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
11572 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
11573 <p><b>Discussion:</b></p>
11574 <p>
11575 From message c++std-lib-17897:
11576 </p>
11577 <p>
11578 The  code  shown  in  27.6.1.2.2 [istream.formatted.arithmetic] as  the  "as  if"
11579 implementation  of the  two arithmetic  extractors that  don't  have a
11580 corresponding     <code>num_get</code>     interface    (i.e.,     the
11581 <code>short</code> and <code>int</code>  overloads) is subtly buggy in
11582 how  it  deals  with  <code>EOF</code>, overflow,  and  other  similar
11583 conditions (in addition to containing a few typos).
11584 </p>
11585 <p>
11586 One  problem is  that if  <code>num_get::get()</code> reaches  the EOF
11587 after reading in  an otherwise valid value that  exceeds the limits of
11588 the    narrower    type     (but    not    <code>LONG_MIN</code>    or
11589 <code>LONG_MAX</code>),   it  will   set   <code><i>err</i></code>  to
11590 <code>eofbit</code>.   Because   of  the  if   condition  testing  for
11591 <code>(<i>err</i> == 0)</code>,    the   extractor    won't   set
11592 <code>failbit</code>  (and presumably,  return  a bogus  value to  the
11593 caller).
11594 </p>
11595 <p>
11596 Another  problem with  the code  is that  it never  actually  sets the
11597 argument to  the extracted  value. It can't  happen after the  call to
11598 <code>setstate()</code> since  the function may  throw, so we  need to
11599 show when  and how it's done (we  can't just punt as  say: "it happens
11600 afterwards"). However, it  turns out that showing how  it's done isn't
11601 quite so  easy since  the argument is  normally left unchanged  by the
11602 facet on error  except when the error is due  to a misplaced thousands
11603 separator,  which causes  <code>failbit</code> to  be set  but doesn't
11604 prevent the facet from storing the value.
11605 </p>
11606
11607
11608 <p><b>Proposed resolution:</b></p>
11609 <p>
11610 </p>
11611
11612
11613
11614
11615
11616 <hr>
11617 <h3><a name="697"></a>697. New <tt>&lt;system_error&gt;</tt> header leads to name clashes</h3>
11618 <p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
11619  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-06-24</p>
11620 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
11621 <p><b>Discussion:</b></p>
11622 <p>
11623 The most recent state of
11624 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>
11625 as well as the current draft
11626 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
11627 (section 19.4 [syserr], p.2) proposes a
11628 new
11629 enumeration type <tt>posix_errno</tt> immediatly in the namespace <tt>std</tt>. One of
11630 the enumerators has the name <tt>invalid_argument</tt>, or fully qualified:
11631 <tt>std::invalid_argument</tt>. This name clashes with the exception type
11632 <tt>std::invalid_argument</tt>, see 19.1 [std.exceptions]/p.3. This clash makes
11633 e.g. the following snippet invalid:
11634 </p>
11635
11636 <blockquote><pre>#include &lt;system_error&gt;
11637 #include &lt;stdexcept&gt;
11638
11639 void foo() { throw std::invalid_argument("Don't call us - we call you!"); }
11640 </pre></blockquote>
11641
11642 <p>
11643 I propose that this enumeration type (and probably the remaining parts
11644 of
11645 <tt>&lt;system_error&gt;</tt> as well) should be moved into one additional inner
11646 namespace, e.g. <tt>sys</tt> or <tt>system</tt> to reduce foreseeable future clashes
11647 due
11648 to the great number of members that <tt>std::posix_errno</tt> already contains
11649 (Btw.: Why has the already proposed <tt>std::sys</tt> sub-namespace from
11650 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html">N2066</a>
11651 been rejected?). A further clash <em>candidate</em> seems to be
11652 <tt>std::protocol_error</tt>
11653 (a reasonable name for an exception related to a std network library,
11654 I guess).
11655 </p>
11656
11657 <p>
11658 Another possible resolution would rely on the proposed strongly typed
11659 enums,
11660 as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2213.pdf">N2213</a>.
11661 But maybe the forbidden implicit conversion to integral types would
11662 make
11663 these enumerators less attractive in this special case?
11664 </p>
11665
11666
11667 <p><b>Proposed resolution:</b></p>
11668 <p>
11669 </p>
11670
11671
11672
11673
11674
11675
11676 <hr>
11677 <h3><a name="698"></a>698. Some system_error issues</h3>
11678 <p><b>Section:</b> 19.4.5.1 [syserr.syserr.overview] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
11679  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-06-24</p>
11680 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
11681 <p><b>Discussion:</b></p>
11682 <p>
11683 In 19.4.5.1 [syserr.syserr.overview] we have the class definition of
11684 <tt>std::system_error</tt>. In contrast to all exception classes, which
11685 are constructible with a <tt>what_arg string</tt> (see 19.1 [std.exceptions],
11686 or <tt>ios_base::failure</tt> in 27.4.2.1.1 [ios::failure]), only overloads with with
11687 <tt>const string&amp;</tt> are possible. For consistency with the re-designed
11688 remaining exception classes this class should also provide
11689 c'tors which accept a const <tt>char* what_arg</tt> string.
11690 </p>
11691 <p>
11692 Please note that this proposed addition makes sense even
11693 considering the given implementation hint for <tt>what()</tt>, because
11694 <tt>what_arg</tt> is required to be set as <tt>what_arg</tt> of the base class
11695 <tt>runtime_error</tt>, which now has the additional c'tor overload
11696 accepting a <tt>const char*</tt>.
11697 </p>
11698
11699
11700 <p><b>Proposed resolution:</b></p>
11701 <p>
11702 </p>
11703
11704
11705
11706
11707
11708 <hr>
11709 <h3><a name="700"></a>700. N1856 defines struct <tt>identity</tt></h3>
11710 <p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
11711  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</p>
11712 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
11713 <p><b>Discussion:</b></p>
11714 <p>
11715 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
11716 defines struct <tt>identity</tt> in <tt>&lt;utility&gt;</tt> which clashes with
11717 the traditional definition of struct <tt>identity</tt> in <tt>&lt;functional&gt;</tt>
11718 (not standard, but a common extension from old STL). Be nice
11719 if we could avoid this name clash for backward compatibility.
11720 </p>
11721
11722
11723 <p><b>Proposed resolution:</b></p>
11724 <p>
11725 Change 20.2.2 [forward]:
11726 </p>
11727
11728 <blockquote>
11729 <pre>template &lt;class T&gt; struct identity
11730 {
11731     typedef T type;
11732     <ins>const T&amp; operator()(const T&amp; x) const;</ins>
11733 };
11734 </pre>
11735 <blockquote>
11736 <pre><ins>const T&amp; operator()(const T&amp; x) const;</ins>
11737 </pre>
11738 <blockquote>
11739 <p>
11740 <ins><i>Returns:</i> <tt>x</tt>.</ins>
11741 </p>
11742 </blockquote>
11743 </blockquote>
11744
11745 </blockquote>
11746
11747
11748
11749
11750
11751
11752 <hr>
11753 <h3><a name="701"></a>701. assoc laguerre poly's</h3>
11754 <p><b>Section:</b> TR1 5.2.1.1 [tr.num.sf.Lnm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
11755  <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p>
11756 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
11757 <p><b>Discussion:</b></p>
11758 <p>
11759 I see that the definition the associated Laguerre
11760 polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since
11761 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf">N1687</a>.
11762 However, the draft standard only specifies ranks of integer value <tt>m</tt>,
11763 while the associated Laguerre polynomials are actually valid for real
11764 values of <tt>m &gt; -1</tt>. &nbsp;In the case of non-integer values of <tt>m</tt>, the
11765 definition &nbsp;<tt><i>L</i><sub>n</sub><sup>(m)</sup> = (1/n!)e<sup>x</sup>x<sup>-m</sup> (d/dx)<sup>n</sup> (e<sup>-x</sup>x<sup>m+n</sup>)</tt>
11766 must be used, which also holds for integer values of <tt>m</tt>. &nbsp;See
11767 Abramowitz &amp; Stegun, 22.11.6 for the general case, and 22.5.16-17 for
11768 the integer case.&nbsp;&nbsp;In fact fractional values are most commonly used in
11769 physics, for example to <tt>m = +/- 1/2</tt> to describe the harmonic
11770 oscillator in 1 dimension, and <tt>1/2, 3/2, 5/2, ...</tt> in 3
11771 dimensions.
11772 </p>
11773 <p>
11774 If I am correct, the calculation of the more general case is no
11775 more difficult, and is in fact the function implemented in the GNU
11776 Scientific Library.&nbsp;&nbsp;I would urge you to consider upgrading the
11777 standard, either adding extra functions for real <tt>m</tt> or switching the
11778 current ones to <tt>double</tt>.
11779 </p>
11780
11781
11782 <p><b>Proposed resolution:</b></p>
11783 <p>
11784 </p>
11785
11786
11787
11788
11789
11790 <hr>
11791 <h3><a name="702"></a>702. Restriction in associated Legendre functions</h3>
11792 <p><b>Section:</b> TR1 5.2.1.2 [tr.num.sf.Plm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
11793  <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p>
11794 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
11795 <p><b>Discussion:</b></p>
11796 <p>
11797 One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should&nbsp;&nbsp;be
11798 <tt>|x| &lt;= 1</tt>, not <tt>x &gt;= 0</tt>.</p>
11799
11800
11801 <p><b>Proposed resolution:</b></p>
11802 <p>
11803 </p>
11804
11805
11806
11807
11808
11809 <hr>
11810 <h3><a name="703"></a>703. <tt>map::at()</tt> need a complexity specification</h3>
11811 <p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
11812  <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-07-03</p>
11813 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p>
11814 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
11815 <p><b>Discussion:</b></p>
11816 <p>
11817 <tt>map::at()</tt> need a complexity specification.
11818 </p>
11819
11820
11821 <p><b>Proposed resolution:</b></p>
11822 <p>
11823 Add the following to the specification of <tt>map::at()</tt>, 23.3.1.2 [map.access]:
11824 </p>
11825 <blockquote>
11826 <p>
11827 <i>Complexity:</i> logarithmic.
11828 </p>
11829 </blockquote>
11830
11831
11832
11833
11834
11835 <hr>
11836 <h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</h3>
11837 <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#Open">Open</a>
11838  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-20</p>
11839 <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>
11840 <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>
11841 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
11842 <p><b>Discussion:</b></p>
11843 <p>
11844 The move-related changes inadvertently overwrote the intent of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.
11845 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a> removed the requirement of <tt>CopyAssignable</tt> from
11846 most of the member functions of node-based containers.  But the move-related changes
11847 unnecessarily introduced the <tt>MoveAssignable</tt> requirement for those members which used to
11848 require <tt>CopyAssignable</tt>.
11849 </p>
11850
11851 <p>
11852 We also discussed (c++std-lib-18722) the possibility of dropping <tt>MoveAssignable</tt>
11853 from some of the sequence requirements.  Additionally the <i>in-place</i> construction
11854 work may further reduce requirements.  For purposes of an easy reference, here are the
11855 minimum sequence requirements as I currently understand them.  Those items in requirements
11856 table in the working draft which do not appear below have been purposefully omitted for
11857 brevity as they do not have any requirements of this nature.  Some items which do not
11858 have any requirements of this nature are included below just to confirm that they were
11859 not omitted by mistake.
11860 </p>
11861
11862 <table border="1">
11863 <caption>Container Requirements</caption>
11864 <tbody><tr><td><tt>X u(a)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
11865 <tr><td><tt>X u(rv)</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveConstructible</tt></td></tr>
11866 <tr><td><tt>a = u</tt></td><td>Sequences require <tt>value_type</tt> to be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
11867                                Associative containers require <tt>value_type</tt> to be <tt>CopyConstructible</tt>.</td></tr>
11868 <tr><td><tt>a = rv</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveAssignable</tt>.
11869                                 Sequences with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
11870                                 Associative containers with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
11871 <tr><td><tt>swap(a,u)</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>Swappable</tt>.
11872                                 Sequences with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>Swappable</tt>, <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
11873                                 Associative containers with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
11874 </tbody></table>
11875
11876 <p>
11877 </p>
11878
11879 <table border="1">
11880 <caption>Sequence Requirements</caption>
11881 <tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr>
11882 <tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
11883 <tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
11884                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
11885 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
11886                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
11887 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
11888                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
11889 <tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
11890                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
11891 <tr><td><tt>a.insert(p, i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
11892                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt> when the iterators return an lvalue.
11893                                         If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
11894                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt> when the iterators return an rvalue.</td></tr>
11895 <tr><td><tt>a.erase(p)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
11896 <tr><td><tt>a.erase(q1, q2)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
11897 <tr><td><tt>a.clear()</tt></td><td></td></tr>
11898 <tr><td><tt>a.assign(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
11899                                         If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
11900 <tr><td><tt>a.assign(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.</td></tr>
11901 <tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>.
11902                                      The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
11903 <tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
11904 </tbody></table>
11905
11906 <p>
11907 </p>
11908
11909 <table border="1">
11910 <caption>Optional Sequence Requirements</caption>
11911 <tbody><tr><td><tt>a.front()</tt></td><td></td></tr>
11912 <tr><td><tt>a.back()</tt></td><td></td></tr>
11913 <tr><td><tt>a.push_front(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
11914 <tr><td><tt>a.push_front(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
11915 <tr><td><tt>a.push_back(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
11916 <tr><td><tt>a.push_back(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
11917 <tr><td><tt>a.pop_front()</tt></td><td></td></tr>
11918 <tr><td><tt>a.pop_back()</tt></td><td></td></tr>
11919 <tr><td><tt>a[n]</tt></td><td></td></tr>
11920 <tr><td><tt>a.at[n]</tt></td><td></td></tr>
11921 </tbody></table>
11922
11923 <p>
11924 </p>
11925
11926 <table border="1">
11927 <caption>Associative Container Requirements</caption>
11928 <tbody><tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
11929                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
11930 <tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
11931 <tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
11932 <tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
11933 <tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
11934 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
11935 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
11936 <tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
11937                                         If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
11938 </tbody></table>
11939
11940 <p>
11941 </p>
11942
11943 <table border="1">
11944 <caption>Unordered Associative Container Requirements</caption>
11945 <tbody><tr><td><tt>X(i, j, n, hf, eq)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
11946                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
11947 <tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
11948 <tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
11949 <tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
11950 <tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
11951 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
11952 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
11953 <tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
11954                                         If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
11955 </tbody></table>
11956
11957 <p>
11958 </p>
11959
11960 <table border="1">
11961 <caption>Miscellaneous Requirements</caption>
11962 <tbody><tr><td><tt>map[lvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>CopyConstructible</tt>.
11963                                          The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
11964 <tr><td><tt>map[rvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>MoveConstructible</tt>.
11965                                          The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
11966 </tbody></table>
11967
11968 <p><i>[
11969 Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
11970 ]</i></p>
11971
11972
11973
11974
11975 <p><b>Proposed resolution:</b></p>
11976
11977
11978
11979
11980
11981
11982 <hr>
11983 <h3><a name="705"></a>705. type-trait <tt>decay</tt> incompletely specified</h3>
11984 <p><b>Section:</b> 20.4.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
11985  <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p>
11986 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
11987 <p><b>Discussion:</b></p>
11988 <p>
11989 The current working draft has a type-trait <tt>decay</tt> in 20.4.7 [meta.trans.other].
11990 </p>
11991
11992 <p>
11993 Its use is to turn C++03 pass-by-value parameters into efficient C++0x
11994 pass-by-rvalue-reference parameters. However, the current definition
11995 introduces an incompatible change where the cv-qualification of the
11996 parameter type is retained. The deduced type should loose such
11997 cv-qualification, as pass-by-value does.
11998 </p>
11999
12000
12001 <p><b>Proposed resolution:</b></p>
12002 <p>
12003 In 20.4.7 [meta.trans.other] change the last sentence:
12004 </p>
12005
12006 <blockquote><p>
12007 Otherwise the  member typedef <tt>type</tt> equals <tt><ins>remove_cv&lt;</ins>U<ins>&gt;::type</ins></tt>.
12008 </p></blockquote>
12009
12010 <p>
12011 In 20.3.1.2 [tuple.creation]/1 change:
12012 </p>
12013
12014 <blockquote><p>
12015 <del>where each <tt>Vi</tt> in <tt>VTypes</tt> is <tt>X&amp;</tt> if, for the
12016 corresponding type <tt>Ti</tt> in <tt>Types</tt>,
12017 <tt>remove_cv&lt;remove_reference&lt;Ti&gt;::type&gt;::type</tt> equals
12018 <tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
12019 <tt>decay&lt;Ti&gt;::type</tt>.</del>
12020 <ins>Let <tt>Ui</tt> be <tt>decay&lt;Ti&gt;::type</tt> for each
12021 <tt>Ti</tt> in <tt>Types</tt>. Then each <tt>Vi</tt> in <tt>VTypes</tt>
12022 is <tt>X&amp;</tt> if <tt>Ui</tt> equals
12023 <tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
12024 <tt>Ui</tt>.</ins>
12025 </p></blockquote>
12026
12027
12028
12029
12030
12031
12032 <hr>
12033 <h3><a name="706"></a>706. <tt>make_pair()</tt> should behave as <tt>make_tuple()</tt> wrt. <tt>reference_wrapper()</tt></h3>
12034 <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#Ready">Ready</a>
12035  <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p>
12036 <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>
12037 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
12038 <p><b>Discussion:</b></p>
12039 <p>
12040 The current draft has <tt>make_pair()</tt> in 20.2.3 [pairs]/16
12041 and <tt>make_tuple()</tt> in 20.3.1.2 [tuple.creation].
12042 <tt>make_tuple()</tt> detects the presence of
12043 <tt>reference_wrapper&lt;X&gt;</tt> arguments and "unwraps" the reference in
12044 such cases. <tt>make_pair()</tt> would OTOH create a
12045 <tt>reference_wrapper&lt;X&gt;</tt> member. I suggest that the two
12046 functions are made to behave similar in this respect to minimize
12047 confusion.
12048 </p>
12049
12050
12051 <p><b>Proposed resolution:</b></p>
12052 <p>
12053 In 20.2 [utility] change the synopsis for make_pair() to read
12054 </p>
12055
12056 <blockquote><pre>template &lt;class T1, class T2&gt;
12057   pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>, <del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt; make_pair(T1&amp;&amp;, T2&amp;&amp;);
12058 </pre></blockquote>
12059
12060 <p>
12061 In 20.2.3 [pairs]/16 change the declaration to match the above synopsis.
12062 Then change the 20.2.3 [pairs]/17 to:
12063 </p>
12064
12065 <blockquote>
12066 <p>
12067 <i>Returns:</i> <tt>pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>,<del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt;(forward&lt;T1&gt;(x),forward&lt;T2&gt;(y))</tt> <ins>where <tt>V1</tt> and
12068 <tt>V2</tt> are determined as follows: Let <tt>Ui</tt> be
12069 <tt>decay&lt;Ti&gt;::type</tt> for each <tt>Ti</tt>. Then each
12070 <tt>Vi</tt> is <tt>X&amp;</tt> if <tt>Ui</tt> equals
12071 <tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
12072 <tt>Ui</tt>.</ins>
12073 </p>
12074 </blockquote>
12075
12076
12077
12078
12079
12080
12081 <hr>
12082 <h3><a name="707"></a>707. null pointer constant for <tt>exception_ptr</tt></h3>
12083 <p><b>Section:</b> 18.7.1 [exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
12084  <b>Submitter:</b> Jens Maurer <b>Date:</b> 2007-07-20</p>
12085 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
12086 <p><b>Discussion:</b></p>
12087
12088 <p>
12089 From the Toronto Core wiki:
12090 </p>
12091
12092 <p>
12093 What do you mean by "null pointer constant"? How do you guarantee that
12094 <tt>exception_ptr() == 1</tt> doesn't work? &nbsp;Do you even want to prevent that?
12095 What's the semantics? &nbsp;What about <tt>void *p = 0; exception_ptr() == p</tt>?
12096 Maybe disallow those in the interface, but how do you do that with
12097 portable C++? Could specify just "make it work".
12098 </p>
12099
12100 <p>
12101 Peter's response:
12102 </p>
12103
12104 <p>
12105 null pointer constant as defined in 4.10 [conv.ptr]. Intent is "just make it
12106 work", can be implemented as assignment operator taking a unique pointer
12107 to member, as in the unspecified bool type idiom.
12108 </p>
12109
12110
12111
12112 <p><b>Proposed resolution:</b></p>
12113 <p>
12114 </p>
12115
12116
12117
12118
12119
12120 <hr>
12121 <h3><a name="708"></a>708. Locales need to be per thread and updated for POSIX changes</h3>
12122 <p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
12123  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-07-28</p>
12124 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
12125 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
12126 <p><b>Discussion:</b></p>
12127 <p>
12128 The POSIX "Extended API Set Part 4,"
12129 </p>
12130 <blockquote><p>
12131 <a href="http://www.opengroup.org/sib/details.tpl?id=C065">http://www.opengroup.org/sib/details.tpl?id=C065</a>
12132 </p></blockquote>
12133 <p>
12134 introduces extensions to the C locale mechanism that
12135 allow multiple concurrent locales to be used in the same application
12136 by introducing a type <tt>locale_t</tt> that is very similar to
12137 <tt>std::locale</tt>, and a number of <tt>_l</tt> functions that make use of it.
12138 </p>
12139 <p>
12140 The global locale (set by setlocale) is now specified to be per-
12141 process. If a thread does not call <tt>uselocale</tt>, the global locale is
12142 in effect for that thread. It can install a per-thread locale by
12143 using <tt>uselocale</tt>.
12144 </p>
12145 <p>
12146 There is also a nice <tt>querylocale</tt> mechanism by which one can obtain
12147 the name (such as "de_DE") for a specific <tt>facet</tt>, even for combined
12148 locales, with no <tt>std::locale</tt> equivalent.
12149 </p>
12150 <p>
12151 <tt>std::locale</tt> should be harmonized with the new POSIX <tt>locale_t</tt>
12152 mechanism and provide equivalents for <tt>uselocale</tt> and <tt>querylocale</tt>.
12153 </p>
12154
12155 <p><i>[
12156 Kona (2007): Bill and Nick to provide wording.
12157 ]</i></p>
12158
12159
12160
12161
12162 <p><b>Proposed resolution:</b></p>
12163 <p>
12164 </p>
12165
12166
12167
12168
12169
12170 <hr>
12171 <h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3>
12172 <p><b>Section:</b> 21.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
12173  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-13</p>
12174 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
12175 <p><b>Discussion:</b></p>
12176 <p>
12177 The changes made for <tt>constexpr</tt> in 21.1.3 [char.traits.specializations] have
12178 not only changed the <tt>not_eof</tt> function from pass by const reference to
12179 pass by value, it has also changed the parameter type from <tt>int_type</tt> to
12180 <tt>char_type</tt>.
12181 </p>
12182 <p>
12183 This doesn't work for type <tt>char</tt>, and is inconsistent with the
12184 requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require].
12185 </p>
12186
12187 <p>
12188 Pete adds:
12189 </p>
12190
12191 <blockquote><p>
12192 For what it's worth, that may not have been an intentional change.
12193 N2349, which detailed the changes for adding constant expressions to
12194 the library, has strikeout bars through the <tt>const</tt> and the <tt>&amp;</tt> that
12195 surround the <tt>char_type</tt> argument, but none through <tt>char_type</tt> itself.
12196 So the intention may have been just to change to pass by value, with
12197 text incorrectly copied from the standard.
12198 </p></blockquote>
12199
12200
12201
12202 <p><b>Proposed resolution:</b></p>
12203 <p>
12204 Change the signature in 21.1.3.1 [char.traits.specializations.char],
12205 21.1.3.2 [char.traits.specializations.char16_t], 21.1.3.3 [char.traits.specializations.char32_t],
12206 and 21.1.3.4 [char.traits.specializations.wchar.t] to
12207 </p>
12208
12209 <blockquote><pre>static constexpr int_type not_eof(<del>char_type</del> <ins>int_type</ins> c);
12210 </pre></blockquote>
12211
12212
12213
12214
12215
12216
12217 <hr>
12218 <h3><a name="710"></a>710. Missing postconditions</h3>
12219 <p><b>Section:</b> 20.6.6.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
12220  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</p>
12221 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
12222 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
12223 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
12224 <p><b>Discussion:</b></p>
12225 <p>
12226 A discussion on
12227 <a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
12228 has identified a contradiction in the <tt>shared_ptr</tt> specification.
12229 The <tt>shared_ptr</tt> move constructor and the cast functions are
12230 missing postconditions for the <tt>get()</tt> accessor.
12231 </p>
12232
12233
12234 <p><b>Proposed resolution:</b></p>
12235 <p>
12236 Add to 20.6.6.2.1 [util.smartptr.shared.const]:
12237 </p>
12238
12239 <blockquote>
12240 <pre>shared_ptr(shared_ptr&amp;&amp; r);
12241 template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt;&amp;&amp; r);
12242 </pre>
12243 <blockquote>
12244 <p>
12245 <i>Postconditions:</i>  <tt>*this</tt> shall contain the old value of <tt>r</tt>. <tt>r</tt>
12246 shall be empty. <ins><tt>r.get() == 0</tt>.</ins>
12247 </p>
12248 </blockquote>
12249 </blockquote>
12250
12251 <p>
12252 Add to 20.6.6.2.10 [util.smartptr.shared.cast]:
12253 </p>
12254
12255 <blockquote>
12256 <pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; static_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
12257 </pre>
12258 <blockquote>
12259 <p>
12260 <ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
12261 <tt>w.get() == static_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
12262 </p>
12263 </blockquote>
12264 </blockquote>
12265
12266 <blockquote>
12267 <pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; dynamic_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
12268 </pre>
12269 <blockquote>
12270 <p>
12271 <ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast&lt;T*&gt;(r.get())</tt>.</ins>
12272 </p>
12273 </blockquote>
12274 </blockquote>
12275
12276 <blockquote>
12277 <pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; const_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
12278 </pre>
12279 <blockquote>
12280 <p>
12281 <ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
12282 <tt>w.get() == const_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
12283 </p>
12284 </blockquote>
12285 </blockquote>
12286
12287 <p>
12288 Alberto Ganesh Barbati has written an
12289 <a href="http://barbati.net/c++/shared_ptr.pdf">alternative proposal</a>
12290 where he suggests (among other things) that the casts be respecified in terms of
12291 the aliasing constructor as follows:
12292 </p>
12293
12294 <p>
12295 Change 20.6.6.2.10 [util.smartptr.shared.cast]:
12296 </p>
12297
12298 <blockquote>
12299 <p>
12300 -2- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
12301 shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
12302 object that stores <tt>static_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
12303 <tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, static_cast&lt;T*&gt;(r.get())</tt>.</ins>
12304 </p>
12305 </blockquote>
12306
12307 <blockquote>
12308 <p>
12309 -6- <i>Returns:</i>
12310 </p>
12311 <ul>
12312 <li><del>When <tt>dynamic_cast&lt;T*&gt;(r.get())</tt> returns a nonzero value,
12313 a <tt>shared_ptr&lt;T&gt;</tt> object that stores a copy
12314 of it and <i>shares ownership</i> with <tt>r</tt>;</del></li>
12315 <li><del>Otherwise, an <i>empty</i> <tt>shared_ptr&lt;T&gt;</tt> object.</del></li>
12316 <li><ins>If <tt>p = dynamic_cast&lt;T*&gt;(r.get())</tt> is a non-null pointer, <tt>shared_ptr&lt;T&gt;(r, p);</tt></ins></li>
12317 <li><ins>Otherwise, <tt>shared_ptr&lt;T&gt;()</tt>.</ins></li>
12318 </ul>
12319 </blockquote>
12320
12321 <blockquote>
12322 <p>
12323 -10- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
12324 shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
12325 object that stores <tt>const_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
12326 <tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, const_cast&lt;T*&gt;(r.get())</tt>.</ins>
12327 </p>
12328 </blockquote>
12329
12330 <p>
12331 This takes care of the missing postconditions for the casts by bringing
12332 in the aliasing constructor postcondition "by reference".
12333 </p>
12334
12335
12336
12337
12338
12339
12340 <hr>
12341 <h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
12342 <p><b>Section:</b> 20.6.6.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
12343  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</p>
12344 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
12345 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
12346 <p><b>Discussion:</b></p>
12347 <p>
12348 A discussion on
12349 <a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
12350 has identified a contradiction in the <tt>shared_ptr</tt> specification.
12351 The note:
12352 </p>
12353
12354 <blockquote><p>
12355 [ <i>Note:</i> this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
12356 -end note ]
12357 </p></blockquote>
12358
12359 <p>
12360 after the aliasing constructor
12361 </p>
12362
12363 <blockquote><pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
12364 </pre></blockquote>
12365
12366 <p>
12367 reflects the intent of
12368 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
12369 to, well, allow the creation of an empty <tt>shared_ptr</tt>
12370 with a non-NULL stored pointer.
12371 </p>
12372
12373 <p>
12374 This is contradicted by the second sentence in the Returns clause of 20.6.6.2.5 [util.smartptr.shared.obs]:
12375 </p>
12376
12377 <blockquote>
12378 <pre>T* get() const;
12379 </pre>
12380 <blockquote><p>
12381 <i>Returns:</i> the stored pointer. Returns a null pointer if <tt>*this</tt> is empty.
12382 </p></blockquote>
12383 </blockquote>
12384
12385
12386
12387 <p><b>Proposed resolution:</b></p>
12388 <p>
12389 In keeping the N2351 spirit and obviously my preference, change 20.6.6.2.5 [util.smartptr.shared.obs]:
12390 </p>
12391
12392 <blockquote>
12393 <pre>T* get() const;
12394 </pre>
12395 <blockquote><p>
12396 <i>Returns:</i> the stored pointer. <del>Returns a null pointer if <tt>*this</tt> is empty.</del>
12397 </p></blockquote>
12398 </blockquote>
12399
12400 <p>
12401 Alternative proposed resolution: (I won't be happy if we do this, but it's possible):
12402 </p>
12403
12404 <p>
12405 Change 20.6.6.2.1 [util.smartptr.shared.const]:
12406 </p>
12407
12408 <blockquote>
12409 <pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
12410 </pre>
12411 <blockquote>
12412 <p>
12413 <ins><i>Requires:</i> If <tt>r</tt> is empty, <tt>p</tt> shall be <tt>0</tt>.</ins>
12414 </p>
12415 <p>
12416 <del>[ <i>Note:</i> this constructor allows creation of an empty <tt>shared_ptr</tt>
12417 instance with a non-NULL stored pointer.
12418 -- <i>end note</i> ]</del>
12419 </p>
12420 </blockquote>
12421 </blockquote>
12422
12423
12424
12425
12426
12427
12428 <hr>
12429 <h3><a name="713"></a>713. <tt>sort()</tt> complexity is too lax</h3>
12430 <p><b>Section:</b> 25.3.1.1 [sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
12431  <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
12432 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
12433 <p><b>Discussion:</b></p>
12434 <p>
12435 The complexity of <tt>sort()</tt> is specified as "Approximately <tt>N
12436 log(N)</tt> (where <tt>N == last - first</tt> ) comparisons on the
12437 average", with no worst case complicity specified. The intention was to
12438 allow a median-of-three quicksort implementation, which is usually <tt>O(N
12439 log N)</tt> but can be quadratic for pathological inputs. However, there is
12440 no longer any reason to allow implementers the freedom to have a
12441 worst-cast-quadratic sort algorithm. Implementers who want to use
12442 quicksort can use a variant like David Musser's "Introsort" (Software
12443 Practice and Experience 27:983-993, 1997), which is guaranteed to be <tt>O(N
12444 log N)</tt> in the worst case without incurring additional overhead in the
12445 average case. Most C++ library implementers already do this, and there
12446 is no reason not to guarantee it in the standard.
12447 </p>
12448
12449
12450 <p><b>Proposed resolution:</b></p>
12451 <p>
12452 In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
12453 </p>
12454
12455 <blockquote>
12456 <p>
12457 <i>Complexity:</i> <del>Approximately</del> <ins>O(</ins><i>N</i> log(<i>N</i>)<ins>)</ins> <del>(where <i>N</i> == <i>last</i> - <i>first</i> )
12458 </del>comparisons<del> on the average</del>.<del><sup>266)</sup></del>
12459 </p>
12460 <p>
12461 <del><sup>266)</sup>
12462 If the worst case behavior is important <tt>stable_sort()</tt> (25.3.1.2) or <tt>partial_sort()</tt>
12463 (25.3.1.3) should be used.</del>
12464 </p>
12465 </blockquote>
12466
12467
12468
12469
12470
12471
12472 <hr>
12473 <h3><a name="714"></a>714. <tt>search_n</tt> complexity is too lax</h3>
12474 <p><b>Section:</b> 25.1.9 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
12475  <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
12476 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.search">issues</a> in [alg.search].</p>
12477 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
12478 <p><b>Discussion:</b></p>
12479 <p>
12480 The complexity for <tt>search_n</tt> (25.1.9 [alg.search] par 7) is specified as "At most
12481 (last - first ) * count applications of the corresponding predicate if
12482 count is positive, or 0 otherwise." This is unnecessarily pessimistic.
12483 Regardless of the value of count, there is no reason to examine any
12484 element in the range more than once.
12485 </p>
12486
12487
12488 <p><b>Proposed resolution:</b></p>
12489 <p>
12490 Change the complexity to "At most (last - first) applications of the corresponding predicate".
12491 </p>
12492
12493 <blockquote>
12494 <pre>template&lt;class ForwardIterator, class Size, class T&gt;
12495   ForwardIterator
12496     search_n(ForwardIterator first , ForwardIterator last , Size count ,
12497              const T&amp; value );
12498
12499 template&lt;class ForwardIterator, class Size, class T,
12500          class BinaryPredicate&gt;
12501   ForwardIterator
12502     search_n(ForwardIterator first , ForwardIterator last , Size count ,
12503              const T&amp; value , BinaryPredicate pred );
12504 </pre>
12505 <blockquote>
12506 <p>
12507 <i>Complexity:</i> At most <tt>(last - first ) <del>* count</del></tt> applications of the corresponding predicate
12508 <del>if <tt>count</tt> is positive, or 0 otherwise</del>.
12509 </p>
12510 </blockquote>
12511 </blockquote>
12512
12513
12514
12515
12516
12517
12518 <hr>
12519 <h3><a name="715"></a>715. <tt>minmax_element</tt> complexity is too lax</h3>
12520 <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#New">New</a>
12521  <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
12522 <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>
12523 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
12524 <p><b>Discussion:</b></p>
12525 <p>
12526 The complexity for <tt>minmax_element</tt> (25.3.7 [alg.min.max] par 16) says "At most <tt>max(2 *
12527 (last - first ) - 2, 0)</tt> applications of the corresponding comparisons",
12528 i.e. the worst case complexity is no better than calling <tt>min_element</tt> and
12529 <tt>max_element</tt> separately. This is gratuitously inefficient. There is a
12530 well known technique that does better: see section 9.1 of CLRS
12531 (Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein).
12532 </p>
12533
12534
12535 <p><b>Proposed resolution:</b></p>
12536 <p>
12537 Change 25.3.7 [alg.min.max] to:
12538 </p>
12539
12540 <blockquote>
12541 <pre>template&lt;class ForwardIterator&gt;
12542   pair&lt;ForwardIterator, ForwardIterator&gt;
12543     minmax_element(ForwardIterator first , ForwardIterator last);
12544 template&lt;class ForwardIterator, class Compare&gt;
12545   pair&lt;ForwardIterator, ForwardIterator&gt;
12546     minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
12547 </pre>
12548 <blockquote>
12549 <p>
12550 <i>Returns:</i> <tt>make_pair(m, M)</tt>, where <tt>m</tt> is
12551 <del><tt>min_element(first, last)</tt> or <tt>min_element(first, last,
12552 comp)</tt></del> <ins>the first iterator <tt>i</tt> in <tt>[first,
12553 last)</tt> such that no other element in the range is smaller,</ins> and
12554 <ins>where</ins> <tt>M</tt> is <del><tt>max_element(first, last)</tt> or
12555 <tt>max_element(first, last, comp)</tt></del> <ins>the last iterator
12556 <tt>i</tt> in <tt>[first, last)</tt> such that no other element in the
12557 range is larger</ins>.
12558 </p>
12559 <p>
12560 <i>Complexity:</i> At most <del><tt>max(2 * (last - first ) - 2, 0)</tt></del>
12561 <ins><tt>max(&#8970;(3/2) (N-1)&#8971;, 0)</tt></ins> applications of the
12562 corresponding <del>comparisons</del> <ins>predicate, where <tt>N</tt> is <tt>distance(first, last)</tt></ins>.
12563 </p>
12564 </blockquote>
12565 </blockquote>
12566
12567
12568
12569
12570
12571
12572 <hr>
12573 <h3><a name="716"></a>716. Production in [re.grammar] not actually modified</h3>
12574 <p><b>Section:</b> 28.13 [re.grammar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
12575  <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-08-31</p>
12576 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
12577 <p><b>Discussion:</b></p>
12578 <p>
12579 TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
12580 </p>
12581
12582 <blockquote>
12583 <p>
12584 The following productions within the ECMAScript grammar are modified as follows:
12585 </p>
12586
12587 <blockquote><pre>CharacterClass ::
12588 [ [lookahead &#8713; {^}] ClassRanges ]
12589 [ ^ ClassRanges ]
12590 </pre></blockquote>
12591
12592 </blockquote>
12593
12594 <p>
12595 This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
12596 </p>
12597
12598 <p>
12599 Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
12600 </p>
12601
12602
12603 <p><b>Proposed resolution:</b></p>
12604 <p>
12605 Remove this mention of the CharacterClass production.
12606 </p>
12607
12608 <blockquote><pre><del>CharacterClass ::
12609 [ [lookahead &#8713; {^}] ClassRanges ]
12610 [ ^ ClassRanges ]</del>
12611 </pre></blockquote>
12612
12613
12614
12615
12616
12617
12618 <hr>
12619 <h3><a name="717"></a>717. Incomplete <tt>valarray::operator[]</tt> specification in [valarray.access]</h3>
12620 <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#New">New</a>
12621  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-27</p>
12622 <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>
12623 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
12624 <p><b>Discussion:</b></p>
12625 <p>
12626 Since the return type of <tt>valarray</tt>'s <tt>operator[] const</tt> overload has been
12627 changed to <tt>const T&amp;</tt> as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> several paragraphs of
12628 the section 26.5.2.3 [valarray.access] are now
12629 incompletely
12630 specified, because many requirements and guarantees should now also
12631 apply to the const overload. Most notably, the address and reference
12632 guarantees should be extended to the const overload case.
12633 </p>
12634
12635
12636 <p><b>Proposed resolution:</b></p>
12637 <p>
12638 Change 26.5.2.3 [valarray.access]:
12639 </p>
12640
12641 <blockquote>
12642 <p>
12643 -1- <del>When applied to a constant array, the subscript operator returns a
12644 reference to the corresponding element of the array. When applied to a
12645 non-constant array, t</del><ins>T</ins>he subscript operator returns a
12646 reference to the corresponding element of the array.
12647 </p>
12648
12649 <p>
12650 -3- The expression <tt>&amp;a[i+j] == &amp;a[i] + j</tt> evaluates as <tt>true</tt> for all <tt>size_t i</tt>
12651 and <tt>size_t j</tt> such that <tt>i+j</tt> is less
12652 than the length of the <del>non-constant</del> array <tt>a</tt>.
12653 </p>
12654
12655 <p>
12656 -4- Likewise, the expression <tt>&amp;a[i] != &amp;b[j]</tt> evaluates
12657 as <tt>true</tt> for any two <del>non-constant</del> arrays <tt>a</tt> and
12658 <tt>b</tt> and for any <tt>size_t i</tt> and <tt>size_t j</tt> such that
12659 <tt>i</tt> is less than the length of <tt>a</tt> and <tt>j</tt> is less
12660 than the length of <tt>b</tt>. This property indicates an absence of
12661 aliasing and may be used to advantage by optimizing
12662 compilers.<sup>281)</sup>
12663 </p>
12664
12665 <p>
12666 -5- The reference returned by the subscript operator for a<ins>n</ins> <del>non-constant</del> array is guaranteed to be valid until
12667 the member function <tt>resize(size_t, T)</tt> (26.5.2.7) is called for that array or until the lifetime
12668 of that array ends, whichever happens first.
12669 </p>
12670
12671 </blockquote>
12672
12673
12674
12675
12676
12677
12678 <hr>
12679 <h3><a name="718"></a>718. <tt>basic_string</tt> is not a sequence</h3>
12680 <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#New">New</a>
12681  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-18</p>
12682 <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>
12683 <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>
12684 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
12685 <p><b>Discussion:</b></p>
12686 <p>
12687 Paragraph 21.3 [basic.string]/3 states:
12688 </p>
12689
12690 <blockquote>
12691 <p>
12692 The class template <tt>basic_string</tt> conforms to the requirements for a
12693 Sequence (23.1.1) and for a Reversible Container (23.1).
12694 </p>
12695 </blockquote>
12696
12697 <p>
12698 First of all, 23.1.1 [sequence.reqmts] is no longer "Sequence" but "Sequence container".
12699 Secondly, after the resent changes to containers (<tt>emplace</tt>, <tt>push_back</tt>,
12700 <tt>const_iterator</tt> parameters to <tt>insert</tt> and <tt>erase</tt>), <tt>basic_string</tt> is not
12701 even close to conform to the current requirements.
12702 </p>
12703
12704
12705 <p><b>Proposed resolution:</b></p>
12706 <p>
12707 Remove this sentence, in recognition of the fact that <tt>basic_string</tt> is
12708 not just a <tt>vector</tt>-light for literal types, but something quite
12709 different, a string abstraction in its own right.
12710 </p>
12711
12712
12713
12714
12715
12716 <hr>
12717 <h3><a name="719"></a>719. <tt>std::is_literal</tt> type traits should be provided</h3>
12718 <p><b>Section:</b> 20.4 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
12719  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p>
12720 <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>
12721 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
12722 <p><b>Discussion:</b></p>
12723 <p>
12724 Since the inclusion of <tt>constexpr</tt> in the standard draft N2369 we have
12725 a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
12726 </p>
12727
12728 <blockquote>
12729 <p>
12730 -11- A type is a <i>literal</i> type if it is:
12731 </p>
12732 <ul>
12733 <li>a scalar type; or</li>
12734 <li><p>a class type (clause 9) with</p>
12735 <ul>
12736 <li>a trivial copy constructor,</li>
12737 <li>a trivial destructor,</li>
12738 <li>at least one constexpr constructor other than the copy constructor,</li>
12739 <li>no virtual base classes, and</li>
12740 <li>all non-static data members and base classes of literal types; or</li>
12741 </ul>
12742 </li>
12743 <li>an array of literal type.</li>
12744 </ul>
12745 </blockquote>
12746
12747 <p>
12748 I strongly suggest that the standard provides a type traits for
12749 literal types in 20.4.4.3 [meta.unary.prop] for several reasons:
12750 </p>
12751
12752 <ol type="a">
12753 <li>To keep the traits in sync with existing types.</li>
12754 <li>I see many reasons for programmers to use this trait in template
12755    code to provide optimized template definitions for these types,
12756    see below.</li>
12757 <li>A user-provided definition of this trait is practically impossible
12758 to write portably.</li>
12759 </ol>
12760
12761 <p>
12762 The special problem of reason (c) is that I don't see currently a
12763 way to portably test the condition for literal class types:
12764 </p>
12765
12766 <blockquote>
12767 <ul>
12768 <li>at least one constexpr constructor other than the copy constructor,</li>
12769 </ul>
12770 </blockquote>
12771
12772 <p>
12773 Here follows a simply example to demonstrate it's usefulness:
12774 </p>
12775
12776 <blockquote><pre>template &lt;typename T&gt;
12777 constexpr typename std::enable_if&lt;std::is_literal&lt;T&gt;::value, T&gt;::type
12778 abs(T x) {
12779   return x &lt; T() ? -x : x;
12780 }
12781
12782 template &lt;typename T&gt;
12783 typename std::enable_if&lt;!std::is_literal&lt;T&gt;::value, T&gt;::type
12784 abs(const T&amp; x) {
12785   return x &lt; T() ? -x : x;
12786 }
12787 </pre></blockquote>
12788
12789 <p>
12790 Here we have the possibility to provide a general <tt>abs</tt> function
12791 template that can be used in ICE's if it's argument is a literal
12792 type which's value is a constant expression, otherwise we
12793 have an optimized version for arguments which are expensive
12794 to copy and therefore need the usage of arguments of
12795 reference type (instead of <tt>const T&amp;</tt> we could decide to
12796 use <tt>T&amp;&amp;</tt>, but that is another issue).
12797 </p>
12798
12799
12800
12801 <p><b>Proposed resolution:</b></p>
12802 <p>
12803 In 20.4.2 [meta.type.synop] in the group "type properties",
12804 just below the line
12805 </p>
12806
12807 <blockquote><pre>template &lt;class T&gt; struct is_pod;
12808 </pre></blockquote>
12809
12810 <p>
12811 add a new one:
12812 </p>
12813
12814 <blockquote><pre>template &lt;class T&gt; struct is_literal;
12815 </pre></blockquote>
12816
12817 <p>
12818 In 20.4.4.3 [meta.unary.prop], table Type Property Predicates, just
12819 below the line for the <tt>is_pod</tt> property add a new line:
12820 </p>
12821
12822 <table border="1">
12823 <tbody><tr>
12824 <th>Template</th><th>Condition</th><th>Preconditions</th>
12825 </tr>
12826 <tr>
12827 <td><tt>template &lt;class T&gt; struct is_literal;</tt></td>
12828 <td><tt>T</tt> is a literal type (3.9)</td>
12829 <td><tt>T</tt> shall be a complete type, an
12830 array of unknown bound, or
12831 (possibly cv-qualified) <tt>void</tt>.</td>
12832 </tr>
12833 </tbody></table>
12834
12835
12836
12837
12838
12839
12840 <hr>
12841 <h3><a name="720"></a>720. Omissions in constexpr usages</h3>
12842 <p><b>Section:</b> 23.2.1 [array], 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
12843  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p>
12844 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
12845 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
12846 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
12847 <p><b>Discussion:</b></p>
12848 <ol>
12849 <li>
12850 The member function <tt>bool array&lt;T,N&gt;::empty() const</tt> should be a
12851 <tt>constexpr</tt> because this is easily to proof and to implement following it's operational
12852 semantics defined by Table 87 (Container requirements) which says: <tt>a.size() == 0</tt>.
12853 </li>
12854 <li>
12855 The member function <tt>bool bitset&lt;N&gt;::test() const</tt> must be a
12856 <tt>constexpr</tt> (otherwise it would violate the specification of <tt>constexpr
12857 bitset&lt;N&gt;::operator[](size_t) const</tt>, because it's return clause delegates to <tt>test()</tt>).
12858 </li>
12859 <li>
12860 I wonder how the constructor <tt>bitset&lt;N&gt;::bitset(unsigned long)</tt> can
12861 be declared as a <tt>constexpr</tt>. Current implementations usually have no such <tt>bitset</tt>
12862 c'tor which would fulfill the requirements of a <tt>constexpr</tt> c'tor because they have a
12863 non-empty c'tor body that typically contains for-loops or <tt>memcpy</tt> to compute the
12864 initialisation. What have I overlooked here?
12865 </li>
12866 </ol>
12867
12868
12869 <p><b>Proposed resolution:</b></p>
12870 <ol>
12871 <li>
12872 <p>In the class template definition of 23.2.1 [array]/p. 3 change</p>
12873 <blockquote><pre><ins>constexpr</ins> bool empty() const;
12874 </pre></blockquote>
12875 </li>
12876
12877 <li>
12878 <p>In the class template definition of 23.3.5 [template.bitset]/p. 1 change</p>
12879 <blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
12880 </pre></blockquote>
12881
12882 <p>
12883 and in 23.3.5.2 [bitset.members] change
12884 </p>
12885
12886 <blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
12887 </pre></blockquote>
12888
12889 </li>
12890 </ol>
12891
12892
12893
12894
12895
12896 <hr>
12897 <h3><a name="721"></a>721. <tt>wstring_convert</tt> inconsistensies</h3>
12898 <p><b>Section:</b> 22.1.3.2.2 [conversions.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
12899  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-27</p>
12900 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
12901 <p><b>Discussion:</b></p>
12902 <p>
12903 Paragraph 3 says that the <tt>Codecvt</tt> template parameter shall meet the
12904 requirements of <tt>std::codecvt</tt>, even though <tt>std::codecvt</tt> itself cannot
12905 be used (because of a protected destructor).
12906 </p>
12907
12908 <p>
12909 How are we going to explain this code to beginning programmers?
12910 </p>
12911
12912 <blockquote><pre>template&lt;class I, class E, class S&gt;
12913 struct codecvt : std::codecvt&lt;I, E, S&gt;
12914 {
12915     ~codecvt()
12916     { }
12917 };
12918
12919 void main()
12920 {
12921     std::wstring_convert&lt;codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt; compiles_ok;
12922
12923     std::wstring_convert&lt;std::codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt;   not_ok;
12924 }
12925 </pre></blockquote>
12926
12927
12928
12929 <p><b>Proposed resolution:</b></p>
12930 <p>
12931 </p>
12932
12933
12934
12935
12936
12937 <hr>
12938 <h3><a name="722"></a>722. Missing [c.math] functions <tt>nanf</tt> and <tt>nanl</tt></h3>
12939 <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#New">New</a>
12940  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-27</p>
12941 <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>
12942 <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>
12943 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
12944 <p><b>Discussion:</b></p>
12945 <p>
12946 In the listing of 26.7 [c.math], table 108: Header <tt>&lt;cmath&gt;</tt> synopsis I miss
12947 the following C99 functions (from 7.12.11.2):
12948 </p>
12949
12950 <blockquote><pre>float nanf(const char *tagp);
12951 long double nanl(const char *tagp);
12952 </pre></blockquote>
12953
12954 <p>
12955 (Note: These functions cannot be overloaded and they are also not
12956 listed anywhere else)
12957 </p>
12958
12959
12960 <p><b>Proposed resolution:</b></p>
12961 <p>
12962 In 26.7 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt>
12963 just after the existing entry <tt>nan</tt>.
12964 </p>
12965
12966
12967
12968
12969
12970 <hr>
12971 <h3><a name="723"></a>723. <tt>basic_regex</tt> should be moveable</h3>
12972 <p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
12973  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-29</p>
12974 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex">issues</a> in [re.regex].</p>
12975 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
12976 <p><b>Discussion:</b></p>
12977 <p>
12978 According to the current state of the standard draft, the class
12979 template <tt>basic_regex</tt>, as described in 28.8 [re.regex]/3, is
12980 neither <tt>MoveConstructible</tt> nor <tt>MoveAssignable</tt>.
12981 IMO it should be, because typical regex state machines tend
12982 to have a rather large data quantum and I have seen several
12983 use cases, where a factory function returns regex values,
12984 which would take advantage of moveabilities.
12985 </p>
12986
12987
12988 <p><b>Proposed resolution:</b></p>
12989 <ol type="a">
12990 <li>
12991 <p>
12992 In the header <tt>&lt;regex&gt;</tt> synopsis 28.4 [re.syn], just below the function
12993 template <tt>swap</tt> add two further overloads:
12994 </p>
12995 <blockquote><pre>template &lt;class charT, class traits&gt;
12996   void swap(basic_regex&lt;charT, traits&gt;&amp; e1,  basic_regex&lt;charT, traits&gt;&amp; e2);
12997 <ins>template &lt;class charT, class traits&gt;
12998   void swap(basic_regex&lt;charT, traits&gt;&amp;&amp; e1, basic_regex&lt;charT, traits&gt;&amp; e2);
12999 template &lt;class charT, class traits&gt;
13000   void swap(basic_regex&lt;charT, traits&gt;&amp; e1,  basic_regex&lt;charT, traits&gt;&amp;&amp; e2);</ins>
13001 </pre></blockquote>
13002 <p>
13003 In the class definition of <tt>basic_regex</tt>, just below 28.8 [re.regex]/3,
13004 perform the following changes:
13005 </p>
13006 </li>
13007
13008 <li>
13009 <p>Just after the copy c'tor:</p>
13010 <blockquote><pre>basic_regex(basic_regex&amp;&amp;);
13011 </pre></blockquote>
13012 </li>
13013
13014 <li>
13015 <p>Just after the copy-assignment op.:</p>
13016 <blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
13017 </pre></blockquote>
13018 </li>
13019
13020 <li>
13021 <p>Just after the first <tt>assign</tt> overload insert:</p>
13022 <blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
13023 </pre></blockquote>
13024 </li>
13025
13026 <li>
13027 <p>Change the current <tt>swap</tt> function to read:</p>
13028 <blockquote><pre>void swap(basic_regex&amp;&amp;);
13029 </pre></blockquote>
13030 </li>
13031
13032 <li>
13033 <p>In 28.8.2 [re.regex.construct], just below the copy c'tor add a
13034 corresponding member definition of:</p>
13035 <blockquote><pre>basic_regex(basic_regex&amp;&amp;);
13036 </pre></blockquote>
13037 </li>
13038
13039 <li>
13040 <p>Also in 28.8.2 [re.regex.construct], just below the copy assignment
13041 c'tor add a corresponding member definition of:</p>
13042 <blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
13043 </pre></blockquote>
13044 </li>
13045
13046 <li>
13047 <p>In 28.8.3 [re.regex.assign], just below the first <tt>assign</tt> overload add
13048 a corresponding member definition of:</p>
13049 <blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
13050 </pre></blockquote>
13051 </li>
13052
13053 <li>
13054 <p>In 28.8.6 [re.regex.swap], change the signature of <tt>swap</tt> to
13055 say:</p>
13056 <blockquote><pre>void swap(basic_regex&amp;&amp; e);
13057 </pre></blockquote>
13058 </li>
13059
13060 <li>
13061 <p>In 28.8.7.1 [re.regex.nmswap], just below the single binary <tt>swap</tt>
13062 function, add the two missing overloads:</p>
13063 <blockquote><pre>template &lt;class charT, class traits&gt;
13064   void swap(basic_regex&lt;charT, traits&gt;&amp;&amp; e1, basic_regex&lt;charT, traits&gt;&amp; e2);
13065 template &lt;class charT, class traits&gt;
13066   void swap(basic_regex&lt;charT, traits&gt;&amp; e1, basic_regex&lt;charT, traits&gt;&amp;&amp; e2);
13067 </pre></blockquote>
13068 </li>
13069 </ol>
13070
13071 <p>
13072 Of course there would be need of corresponding proper standardese
13073 to describe these additions.
13074 </p>
13075
13076
13077
13078
13079
13080
13081 <hr>
13082 <h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3>
13083 <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#New">New</a>
13084  <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2007-09-12</p>
13085 <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>
13086 <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>
13087 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13088 <p><b>Discussion:</b></p>
13089 <p>
13090 The <tt>DefaultConstructible</tt> requirement is referenced in
13091 several places in the August 2007 working draft
13092 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf">N2369</a>,
13093 but is not defined anywhere.
13094 </p>
13095
13096
13097 <p><b>Proposed resolution:</b></p>
13098 <p>
13099 In section 20.1.1 [utility.arg.requirements], before table 33, add the
13100 following table:
13101 </p>
13102
13103 <p style="text-align: center;" align="center">Table 33: <tt>DefaultConstructible</tt> requirements</p>
13104
13105 <div align="center">
13106
13107 <table style="border-collapse: collapse;" border="0" cellpadding="0" cellspacing="0">
13108  <tbody><tr>
13109   <td style="border-style: solid none double solid; border-color: navy -moz-use-text-color navy navy; border-width: 1pt medium 1.5pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
13110   <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">expression</p>
13111   </td>
13112   <td style="border-style: solid solid double none; border-color: navy navy navy -moz-use-text-color; border-width: 1pt 1pt 1.5pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
13113   <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">post-condition</p>
13114   </td>
13115  </tr>
13116  <tr>
13117   <td style="border-style: none none solid solid; border-color: -moz-use-text-color -moz-use-text-color navy navy; border-width: medium medium 1pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
13118   <p style="margin: 0in 0in 0.0001pt;"><tt>T
13119   t;</tt><br>
13120   <tt>T()</tt></p>
13121   </td>
13122   <td style="border-style: none solid solid none; border-color: -moz-use-text-color navy navy -moz-use-text-color; border-width: medium 1pt 1pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
13123   <p style="margin: 0in 0in 0.0001pt;"><tt>T</tt>
13124   is <i>default constructed.</i></p>
13125   </td>
13126  </tr>
13127 </tbody></table>
13128
13129 </div>
13130
13131
13132
13133
13134
13135
13136 <hr>
13137 <h3><a name="725"></a>725. Optional sequence container requirements column label</h3>
13138 <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#New">New</a>
13139  <b>Submitter:</b> David Abrahams <b>Date:</b> 2007-09-16</p>
13140 <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>
13141 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13142 <p><b>Discussion:</b></p>
13143 <p>
13144 Table 90: (Optional sequence container operations) states the
13145 "assertion note pre/post-condition" of <tt>operator[]</tt> to be
13146 </p>
13147
13148 <blockquote><pre>*(a.begin() + n)
13149 </pre></blockquote>
13150
13151 <p>
13152 Surely that's meant to be "operational semantics?"
13153 </p>
13154
13155
13156
13157 <p><b>Proposed resolution:</b></p>
13158 <blockquote>
13159 <table border="1">
13160 <caption>Table 90: Optional sequence container operations</caption>
13161 <tbody><tr>
13162 <th>expression</th> <th>return type</th> <th><del>assertion/note<br>pre/post-condition</del><br> <ins>operational semantics</ins></th> <th>container</th>
13163 </tr>
13164 </tbody></table>
13165 </blockquote>
13166
13167
13168
13169
13170
13171
13172 <hr>
13173 <h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3>
13174 <p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
13175  <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p>
13176 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
13177 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
13178 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13179 <p><b>Discussion:</b></p>
13180 <p>
13181 Two overloads of <tt>regex_replace()</tt> are currently provided:
13182 </p>
13183
13184 <blockquote><pre>template &lt;class OutputIterator, class BidirectionalIterator,
13185     class traits, class charT&gt;
13186   OutputIterator
13187   regex_replace(OutputIterator out,
13188                 BidirectionalIterator first, BidirectionalIterator last,
13189                 const basic_regex&lt;charT, traits&gt;&amp; e,
13190                 const basic_string&lt;charT&gt;&amp; fmt,
13191                 regex_constants::match_flag_type flags =
13192                   regex_constants::match_default);
13193 &nbsp;
13194 template &lt;class traits, class charT&gt;
13195   basic_string&lt;charT&gt;
13196   regex_replace(const basic_string&lt;charT&gt;&amp; s,
13197                 const basic_regex&lt;charT, traits&gt;&amp; e,
13198                 const basic_string&lt;charT&gt;&amp; fmt,
13199                 regex_constants::match_flag_type flags =
13200                   regex_constants::match_default);
13201 </pre></blockquote>
13202
13203 <ol>
13204 <li>Overloads taking <tt>const charT *</tt> are provided for <tt>regex_match()</tt> and
13205 <tt>regex_search()</tt>, but not <tt>regex_replace()</tt>.&nbsp; This is inconsistent.</li>
13206 <li>
13207 <p>The absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p>
13208
13209 <blockquote><pre>const string s("kitten");
13210 const regex r("en");
13211 cout &lt;&lt; regex_replace(s, r, "y") &lt;&lt; endl;
13212 </pre></blockquote>
13213
13214 <p>
13215 The compiler error message will be something like "could not deduce
13216 template argument for 'const std::basic_string&lt;_Elem&gt; &amp;' from 'const
13217 char[1]'".
13218 </p>
13219
13220 <p>
13221 Users expect that anything taking a <tt>basic_string&lt;charT&gt;</tt> can also take a
13222 <tt>const charT *</tt>.&nbsp; In their own code, when they write a function taking
13223 <tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const
13224 wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor.&nbsp; Because the
13225 regex algorithms are templated on <tt>charT</tt>, they can't rely on
13226 <tt>basic_string</tt>'s implicit constructor (as the compiler error message
13227 indicates, template argument deduction fails first).
13228 </p>
13229
13230 <p>
13231 If a user figures out what the compiler error message means, workarounds
13232 are available - but they are all verbose.&nbsp; Explicit template arguments
13233 could be given to <tt>regex_replace()</tt>, allowing <tt>basic_string</tt>'s implicit
13234 constructor to be invoked - but <tt>charT</tt> is the last template argument, not
13235 the first, so this would be extremely verbose.&nbsp; Therefore, constructing
13236 a <tt>basic_string</tt> from each C string is the simplest workaround.
13237 </p>
13238 </li>
13239
13240 <li>
13241 There is an efficiency consideration: constructing <tt>basic_string</tt>s can
13242 impose performance costs that could be avoided by a library
13243 implementation taking C strings and dealing with them directly.&nbsp;
13244 (Currently, for replacement sources, C strings can be converted into
13245 iterator pairs at the cost of verbosity, but for format strings, there
13246 is no way to avoid constructing a <tt>basic_string</tt>.)
13247 </li>
13248 </ol>
13249
13250
13251
13252 <p><b>Proposed resolution:</b></p>
13253 <p>
13254 Provide additional overloads for <tt>regex_replace()</tt>: one additional
13255 overload of the iterator-based form (taking <tt>const charT* fmt</tt>), and three
13256 additional overloads of the convenience form (one taking <tt>const charT*
13257 str</tt>, another taking <tt>const charT* fmt</tt>, and the third taking both <tt>const
13258 charT* str</tt> and <tt>const charT* fmt</tt>).  28.11.4 [re.alg.replace]:
13259 </p>
13260
13261 <blockquote>
13262 <pre>template &lt;class OutputIterator, class BidirectionalIterator,
13263     class traits, class charT&gt;
13264   OutputIterator
13265   regex_replace(OutputIterator out,
13266                 BidirectionalIterator first, BidirectionalIterator last,
13267                 const basic_regex&lt;charT, traits&gt;&amp; e,
13268                 const basic_string&lt;charT&gt;&amp; fmt,
13269                 regex_constants::match_flag_type flags =
13270                   regex_constants::match_default);
13271
13272 <ins>template &lt;class OutputIterator, class BidirectionalIterator,
13273     class traits, class charT&gt;
13274   OutputIterator
13275   regex_replace(OutputIterator out,
13276                 BidirectionalIterator first, BidirectionalIterator last,
13277                 const basic_regex&lt;charT, traits&gt;&amp; e,
13278                 const charT* fmt,
13279                 regex_constants::match_flag_type flags =
13280                   regex_constants::match_default);</ins>
13281 </pre>
13282 <p>...</p>
13283 <pre>template &lt;class traits, class charT&gt;
13284   basic_string&lt;charT&gt;
13285   regex_replace(const basic_string&lt;charT&gt;&amp; s,
13286                 const basic_regex&lt;charT, traits&gt;&amp; e,
13287                 const basic_string&lt;charT&gt;&amp; fmt,
13288                 regex_constants::match_flag_type flags =
13289                   regex_constants::match_default);
13290
13291 <ins>template &lt;class traits, class charT&gt;
13292   basic_string&lt;charT&gt;
13293   regex_replace(const basic_string&lt;charT&gt;&amp; s,
13294                 const basic_regex&lt;charT, traits&gt;&amp; e,
13295                 const charT* fmt,
13296                 regex_constants::match_flag_type flags =
13297                   regex_constants::match_default);</ins>
13298
13299 <ins>template &lt;class traits, class charT&gt;
13300   basic_string&lt;charT&gt;
13301   regex_replace(const charT* s,
13302                 const basic_regex&lt;charT, traits&gt;&amp; e,
13303                 const basic_string&lt;charT&gt;&amp; fmt,
13304                 regex_constants::match_flag_type flags =
13305                   regex_constants::match_default);</ins>
13306
13307 <ins>template &lt;class traits, class charT&gt;
13308   basic_string&lt;charT&gt;
13309   regex_replace(const charT* s,
13310                 const basic_regex&lt;charT, traits&gt;&amp; e,
13311                 const charT* fmt,
13312                 regex_constants::match_flag_type flags =
13313                   regex_constants::match_default);</ins>
13314 </pre>
13315 </blockquote>
13316
13317
13318
13319
13320
13321
13322 <hr>
13323 <h3><a name="727"></a>727. <tt>regex_replace()</tt> doesn't accept <tt>basic_string</tt>s with custom traits and allocators</h3>
13324 <p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
13325  <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p>
13326 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
13327 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
13328 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13329 <p><b>Discussion:</b></p>
13330 <p>
13331 <tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string&lt;charT, ST,
13332 SA&gt;&amp;</tt>.&nbsp; <tt>regex_replace()</tt> takes <tt>const basic_string&lt;charT&gt;&amp;</tt>.&nbsp; This prevents
13333 <tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
13334 allocators.
13335 </p>
13336
13337
13338 <p><b>Proposed resolution:</b></p>
13339 <p>
13340 Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally
13341 templated on <tt>class ST, class SA</tt> and take <tt>const basic_string&lt;charT, ST,
13342 SA&gt;&amp;</tt>.&nbsp; Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place
13343 <tt>class ST, class SA</tt> as the first template arguments; compatibility with
13344 existing code using TR1 and giving explicit template arguments to
13345 <tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template
13346 arguments.
13347 </p>
13348
13349
13350
13351
13352
13353 <hr>
13354 <h3><a name="728"></a>728. Problem in [rand.eng.mers]/6</h3>
13355 <p><b>Section:</b> 26.4.3.2 [rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
13356  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
13357 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13358 <p><b>Discussion:</b></p>
13359 <p>
13360 The <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given
13361 as an algorithm parameterized over the number of bits <tt>W</tt>. I doubt whether the given generalization
13362 of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate
13363 for other bit widths. For instance, <tt>W</tt> could be theoretically 16 and <tt>UIntType</tt> a 16-bit integer, in
13364 which case the given multiplier would not fit into the <tt>UIntType</tt>. Moreover, T. Nishimura and M.
13365 Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister
13366 [<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/VERSIONS/C-LANG/mt19937-64.c">reference</a>].
13367 </p>
13368
13369 <p>
13370 I see two possible resolutions:
13371 </p>
13372
13373 <ol type="a">
13374 <li>Restrict the parameter <tt>W</tt> of the <tt>mersenne_twister_template</tt> to values of 32 or 64 and use the
13375 multiplier from [the above reference] for the 64-bit case (my preference)</li>
13376 <li>Interpret the state array for any <tt>W</tt> as a 32-bit array of appropriate length (and a specified byte
13377 order) and always employ the 32-bit algorithm for seeding
13378 </li>
13379 </ol>
13380
13381 <p>
13382 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13383 for further discussion.
13384 </p>
13385
13386
13387
13388 <p><b>Proposed resolution:</b></p>
13389
13390 <p>
13391 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13392 for the proposed resolution.
13393 </p>
13394
13395
13396
13397
13398
13399
13400 <hr>
13401 <h3><a name="729"></a>729. Problem in [rand.req.eng]/3</h3>
13402 <p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
13403  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
13404 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
13405 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13406 <p><b>Discussion:</b></p>
13407 <p>
13408 The 3rd table row in 26.4.1.3 [rand.req.eng]/3 requires random number engines to accept any
13409 arithmetic type as a seed, which is then casted to the engine's <tt>result_type</tt> and subsequently
13410 used for seeding the state of the engine. The requirement stated as "Creates an engine with
13411 initial state determined by <tt>static_cast&lt;X::result_type&gt;(s)</tt>" forces random number engines
13412 to either use a seeding method that completely depends on the <tt>result_type</tt> (see the discussion
13413 of seeding for the <tt>mersenne_twister_engine</tt> in point T2 above) or at least to throw away "bits
13414 of randomness" in the seed value if the <tt>result_type</tt> is smaller than the seed type. This seems
13415 to be inappropriate for many modern random number generators, in particular F2-linear or
13416 cryptographic ones, which operate on an internal bit array that in principle is independent of the
13417 type of numbers returned.
13418 </p>
13419
13420 <p>
13421 <b>Posible resolution:</b> I propose to change the wording to a version similar to "Creates an
13422 engine with initial state determined by <tt>static_cast&lt;UintType&gt;(s)</tt>, where <tt>UintType</tt> is an
13423 implementation specific unsigned integer type."
13424 </p>
13425
13426 <p>
13427 Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types.
13428 </p>
13429
13430 <p>
13431 Similarly, the type of the seed in 26.4.1.4 [rand.req.adapt]/3 e) could be left unspecified.
13432 </p>
13433
13434 <p>
13435 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13436 for further discussion.
13437 </p>
13438
13439
13440
13441 <p><b>Proposed resolution:</b></p>
13442 <p>
13443 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13444 for further discussion.
13445 </p>
13446
13447
13448
13449
13450
13451
13452 <hr>
13453 <h3><a name="730"></a>730. Comment on [rand.req.adapt]/3 e)</h3>
13454 <p><b>Section:</b> 26.4.1.4 [rand.req.adapt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
13455  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
13456 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13457 <p><b>Discussion:</b></p>
13458 <p>
13459 If an engine adaptor is invoked with an argument of type <tt>seed_seq</tt>, then all base
13460 engines are specified to be seeded with this <tt>seed_seq</tt>. As <tt>seed_seq</tt>'s randomization method is
13461 qualified as constant, this procedure will ef fectively initialize all base engines with the same seed
13462 (though the resulting state might still dif fer to a certain degree if the engines are of different types).
13463 It is not clear whether this mode of operation is in general appropriate, hence -- as far as the
13464 stated requirements are of general nature and not just specific to the engine adaptors provided by
13465 the library -- it might be better to leave the behaviour unspecified, since the current definition of
13466 <tt>seed_seq</tt> does not allow for a generally satisfying specification.
13467 </p>
13468
13469 <p>
13470 <b>Posssible resolution:</b> [As above]
13471 </p>
13472
13473 <p>
13474 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13475 for further discussion.
13476 </p>
13477
13478
13479
13480 <p><b>Proposed resolution:</b></p>
13481 <p>
13482 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13483 for the proposed resolution.
13484 </p>
13485
13486
13487
13488
13489
13490 <hr>
13491 <h3><a name="731"></a>731. proposal for a customizable <tt>seed_seq</tt></h3>
13492 <p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
13493  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
13494 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
13495 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13496 <p><b>Discussion:</b></p>
13497 <p>
13498 The proper way to seed random number engines seems to be the most frequently
13499 discussed issue of the 26.4 [rand] proposal. While the new <tt>seed_seq</tt> approach is already rather
13500 general and probably sufficient for most situations, it is unlikely to be optimal in every case (one
13501 problem was pointed out in point T5 above). In some situations it might, for instance, be better to
13502 seed the state with a cryptographic generator.
13503 </p>
13504 <p>
13505 In my opinion this is a pretty strong argument for extending the standard with a simple facility to
13506 customize the seeding procedure. This could, for example, be done with the following minimal
13507 changes:
13508 </p>
13509
13510 <p>
13511 <b>Possible resolution:</b>
13512 </p>
13513
13514 <ol type="a">
13515 <li>
13516 Turn the interface specification of 26.4.7.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the
13517 exact behaviour of the constructors and the randomize method are left unspecified and where the
13518 const qualification for randomize is removed. Classes implementing this interface are additionally
13519 required to specialize the traits class in c).
13520 </li>
13521 <li>
13522 Provide the class <tt>seed_seq</tt> as a default implementation of the SeedSeq interface.
13523 </li>
13524 <li>
13525 <p>
13526 Supplement the <tt>seed_seq</tt> with a traits class
13527 </p>
13528 <blockquote><pre>template &lt;typename T&gt;
13529 struct is_seed_seq { static const bool value = false; }
13530 </pre></blockquote>
13531 <p>and the specialization</p>
13532 <blockquote><pre>template &lt;&gt;
13533 struct is_seed_seq&lt;seed_seq&gt; { static const bool value = true; }
13534 </pre></blockquote>
13535 <p>which users can supplement with further specializations.</p>
13536 </li>
13537 <li>
13538 Change 26.4.1.3 [rand.req.eng]/1 d) to "q is an lvalue of a type that fulfils the SeedSeq requirements", and
13539 modify the constructors and seed methods in 26.4.3 [rand.eng] appropriately (the actual implementation
13540 could be done using the SFINAE technique).
13541 </li>
13542 </ol>
13543
13544
13545 <p><b>Proposed resolution:</b></p>
13546 <p>
13547 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13548 for the proposed resolution.
13549 </p>
13550
13551
13552
13553
13554
13555 <hr>
13556 <h3><a name="732"></a>732. Defect in [rand.dist.samp.genpdf]</h3>
13557 <p><b>Section:</b> 26.4.8.5.3 [rand.dist.samp.genpdf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
13558  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
13559 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13560 <p><b>Discussion:</b></p>
13561 <p>
13562 26.4.8.5.3 [rand.dist.samp.genpdf] describes the interface for a distribution template that is
13563 meant to simulate random numbers from any general distribution given only the density and the
13564 support of the distribution. I'm not aware of any general purpose algorithm that would be capable
13565 of correctly and efficiently implementing the described functionality. From what I know, this is
13566 essentially an unsolved research problem. Existing algorithms either require more knowledge
13567 about the distribution and the problem domain or work only under very limited circumstances.
13568 Even the state of the art special purpose library UNU.RAN does not solve the problem in full
13569 generality, and in any case, testing and customer support for such a library feature would be a
13570 nightmare.
13571 </p>
13572
13573 <p>
13574 <b>Possible resolution:</b> For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf].
13575 </p>
13576
13577
13578 <p><b>Proposed resolution:</b></p>
13579 <p>
13580 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13581 for the proposed resolution.
13582 </p>
13583
13584
13585
13586
13587
13588 <hr>
13589 <h3><a name="733"></a>733. Comment on [rand.req.dist]/9</h3>
13590 <p><b>Section:</b> 26.4.1.5 [rand.req.dist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
13591  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
13592 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13593 <p><b>Discussion:</b></p>
13594 <p>
13595 The requirement "P shall have a declaration of the form <tt>typedef X distribution_-
13596 type</tt>" effectively makes the use of inheritance for implementing distributions very inconvenient,
13597 because the child of a distribution class in general will not satisfy this requirement. In my opinion
13598 the benefits of having a typedef in the parameter class pointing back to the distribution class are
13599 not worth the hassle this requirement causes. [In my code base I never made use of the nested
13600 typedef but on several occasions could have profited from being able to use simple inheritance for
13601 the implementation of a distribution class.]
13602 </p>
13603
13604 <p>
13605 <b>Proposed resolution:</b> I propose to drop this requirement.
13606 </p>
13607
13608
13609 <p><b>Proposed resolution:</b></p>
13610 <p>
13611 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13612 for the proposed resolution.
13613 </p>
13614
13615
13616
13617
13618
13619 <hr>
13620 <h3><a name="734"></a>734. Unnecessary restriction in [rand.dist.norm.chisq]</h3>
13621 <p><b>Section:</b> 26.4.8.4.3 [rand.dist.norm.chisq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
13622  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
13623 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13624 <p><b>Discussion:</b></p>
13625 <p>
13626 <tt>chi_squared_distribution</tt>, <tt>fisher_f_distribution</tt> and <tt>student_t_distribution</tt>
13627 have parameters for the "degrees of freedom" <tt>n</tt> and <tt>m</tt> that are specified as integers. For the
13628 following two reasons this is an unnecessary restriction: First, in many applications such as
13629 Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param-
13630 eters as continuous variables. Second, the standard non-naive algorithms (i.e.
13631 O(1) algorithms)
13632 for simulating from these distributions work with floating-point parameters anyway (all three
13633 distributions could be easily implemented using the Gamma distribution, for instance).
13634 </p>
13635
13636 <p>
13637 Similar arguments could in principle be made for the parameters <tt>t</tt> and <tt>k</tt> of the discrete
13638 <tt>binomial_distribution</tt> and <tt>negative_binomial_distribution</tt>, though in both cases continuous
13639 parameters are less frequently used in practice and in case of the <tt>binomial_distribution</tt>
13640 the implementation would be significantly complicated by a non-discrete parameter (in most
13641 implementations one would need an approximation of the log-gamma function instead of just the
13642 log-factorial function).
13643 </p>
13644
13645 <p>
13646 <b>Possible resolution:</b> For these reasons, I propose to change the type of the respective parameters
13647 to double.
13648 </p>
13649
13650
13651 <p><b>Proposed resolution:</b></p>
13652 <p>
13653 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13654 for the proposed resolution.
13655 </p>
13656
13657
13658
13659
13660
13661 <hr>
13662 <h3><a name="735"></a>735. Unfortunate naming</h3>
13663 <p><b>Section:</b> 26.4.8.2.2 [rand.dist.bern.bin], 26.4.8.2.4 [rand.dist.bern.negbin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
13664  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
13665 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13666 <p><b>Discussion:</b></p>
13667 <p>
13668 In my opinion the choice of name for the <tt>t</tt> parameter of the <tt>binomial_distribution</tt>
13669 is very unfortunate. In virtually every internet reference, book and software implementation
13670 this parameter is called <tt>n</tt> instead, see for example Wikipedia, Mathworld, Evans et al. (1993)
13671 Statistical Distributions, 2nd E., Wiley, p. 38, the R statistical computing language, p. 926,
13672 Mathematica and Matlab.
13673 </p>
13674
13675 <p>
13676 Similarly, the choice of <tt>k</tt> for the parameter of the negative binomial distributions is rather unusual.
13677 The most common choice for the negative binomial distribution seems to be <tt>r</tt> instead.
13678 </p>
13679
13680 <p>
13681 Choosing unusual names for the parameters causes confusion among users and makes the
13682 interface unnecessarily inconvenient to use.
13683 </p>
13684
13685 <p>
13686 <b>Possible resolution:</b> For these reasons, I propose to change the name of the respective parameters
13687 to <tt>n</tt> and <tt>r</tt>.
13688 </p>
13689
13690
13691 <p><b>Proposed resolution:</b></p>
13692 <p>
13693 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13694 for the proposed resolution.
13695 </p>
13696
13697
13698
13699
13700
13701 <hr>
13702 <h3><a name="736"></a>736. Comment on [rand.dist.samp.discrete]</h3>
13703 <p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
13704  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
13705 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13706 <p><b>Discussion:</b></p>
13707 <ol type="a">
13708 <li>
13709 The specification for <tt>discrete_distribution</tt> requires the member <tt>probabilities()</tt>
13710 to return a vector of <i>standardized</i> probabilities, which forces the implementation every time to
13711 divide each probability by the sum of all probabilities, as the sum will in practice almost never be
13712 exactly 1.0. This is unnecessarily inef ficient as the implementation would otherwise not need to
13713 compute the standardized probabilities at all and could instead work with the non-standardized
13714 probabilities and the sum. If there was no standardization the user would just get back the
13715 probabilities that were previously supplied to the distribution object, which to me seems to be the
13716 more obvious solution.
13717 </li>
13718 <li>
13719 The behaviour of <tt>discrete_distribution</tt> is not specified in case the number of given
13720 probabilities is larger than the maximum number representable by the IntType.
13721 </li>
13722 </ol>
13723
13724 <p>
13725 <b>Possible resolution:</b> I propose to change the specification such that the non-standardized
13726 probabilities need to be returned and that an additional requirement is included for the number
13727 of probabilities to be smaller than the maximum of IntType.
13728 </p>
13729
13730
13731 <p><b>Proposed resolution:</b></p>
13732 <p>
13733 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13734 for the proposed resolution.
13735 </p>
13736
13737
13738
13739
13740
13741 <hr>
13742 <h3><a name="737"></a>737. Comment on [rand.dist.samp.pconst]</h3>
13743 <p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
13744  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
13745 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13746 <p><b>Discussion:</b></p>
13747 <ol type="a">
13748 <li>
13749 The discussion in point T11 above regarding <tt>probabilities()</tt> similarly applies
13750 to the method <tt>densities()</tt> of <tt>piecewise_constant_distribution</tt>.
13751 </li>
13752 <li>
13753 <p>
13754 The design of the constructor
13755 </p>
13756 <blockquote><pre>template &lt;class InputIteratorB, class InputIteratorW&gt;
13757 piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB,
13758                                  InputIteratorW firstW);
13759 </pre></blockquote>
13760 <p>
13761 is unnecessarily unsafe, as there is no separate end-iterator given for the weights. I can't see
13762 any performance or convenience reasons that would justify the risks inherent in such a function
13763 interface, in particular the risk that input error might go unnoticed.
13764 </p>
13765 </li>
13766 </ol>
13767
13768 <p>
13769 <b>Possible resolution:</b> I propose to add an <tt>InputIteratorW lastW</tt> argument to the interface.
13770 </p>
13771
13772
13773 <p><b>Proposed resolution:</b></p>
13774 <p>
13775 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13776 for the proposed resolution.
13777 </p>
13778
13779
13780
13781
13782
13783 <hr>
13784 <h3><a name="738"></a>738. Editorial issue in [rand.adapt.disc]/3</h3>
13785 <p><b>Section:</b> 26.4.4.1 [rand.adapt.disc] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
13786  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
13787 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13788 <p><b>Discussion:</b></p>
13789 <p>
13790 Since the template parameter <tt>p</tt> and <tt>r</tt> are of type <tt>size_t</tt>, the member <tt>n</tt> in the class
13791 exposition should have type <tt>size_t</tt>, too.
13792 </p>
13793
13794
13795 <p><b>Proposed resolution:</b></p>
13796 <p>
13797 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13798 for the proposed resolution.
13799 </p>
13800
13801
13802
13803
13804
13805 <hr>
13806 <h3><a name="739"></a>739. Defect in [rand.util.canonical]/3</h3>
13807 <p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
13808  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
13809 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.canonical">issues</a> in [rand.util.canonical].</p>
13810 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13811 <p><b>Discussion:</b></p>
13812 <p>
13813 The complexity of <tt>generate_canonical</tt> is specified to be "exactly k=max(1, ceil(b/log2
13814 R)) invocations of g". This terms involves a logarithm that is not rounded and hence can not (in
13815 general) be computed at compile time. As this function template is performance critical, I propose
13816 to replace ceil(b/log2 R) with ceil(b/floor(log2 R)).
13817 </p>
13818
13819 <p>
13820 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13821 for further discussion.
13822 </p>
13823
13824
13825
13826 <p><b>Proposed resolution:</b></p>
13827 <p>
13828 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13829 for the proposed resolution.
13830 </p>
13831
13832
13833
13834
13835
13836 <hr>
13837 <h3><a name="740"></a>740. Please remove <tt>*_ptr&lt;T[N]&gt;</tt></h3>
13838 <p><b>Section:</b> 20.6.5.4 [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
13839  <b>Submitter:</b> Herb Sutter <b>Date:</b> 2007-10-04</p>
13840 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13841 <p><b>Discussion:</b></p>
13842 <p>
13843 Please don't provide <tt>*_ptr&lt;T[N]&gt;</tt>. It doesn't enable any useful
13844 bounds-checking (e.g., you could imagine that doing <tt>op++</tt> on a
13845 <tt>shared_ptr&lt;T[N]&gt;</tt> yields a <tt>shared_ptr&lt;T[N-1]&gt;</tt>, but that promising path
13846 immediately falters on <tt>op--</tt> which can't reliably dereference because we
13847 don't know the lower bound). Also, most buffers you'd want to point to
13848 don't have a compile-time known size.
13849 </p>
13850
13851 <p>
13852 To enable any bounds-checking would require run-time information, with
13853 the usual triplet: base (lower bound), current offset, and max offset
13854 (upper  bound). And I can sympathize with the point of view that you
13855 wouldn't want to require this on <tt>*_ptr</tt> itself. But please let's not
13856 follow the <tt>&lt;T[N]&gt;</tt> path, especially not with additional functions to
13857 query the bounds etc., because this sets wrong user expectations by
13858 embarking on a path that doesn't go all the way to bounds checking as it
13859 seems to imply.
13860 </p>
13861
13862 <p>
13863 If bounds checking is desired, consider a <tt>checked_*_ptr</tt> instead (e.g.,
13864 <tt>checked_shared_ptr</tt>). And make the interfaces otherwise identical so that
13865 user code could easily <tt>#define/typedef</tt> between prepending <tt>checked_</tt> on
13866 debug builds and not doing so on release builds (for example).
13867 </p>
13868
13869 <p>
13870 Note that some may object that <tt>checked_*_ptr</tt> may seem to make the smart
13871 pointer more like <tt>vector</tt>, and we don't want two ways to spell <tt>vector</tt>. I
13872 don't agree, but if that were true that would be another reason to
13873 remove <tt>*_ptr&lt;T[N]&gt;</tt> which equally makes the smart pointer more like
13874 <tt>std::array.</tt> :-)
13875 </p>
13876
13877
13878 <p><b>Proposed resolution:</b></p>
13879 <p>
13880 Change the synopsis under 20.6.5 [unique.ptr] p2:
13881 </p>
13882
13883 <blockquote><pre>...
13884 template&lt;class T&gt; struct default_delete;
13885 template&lt;class T&gt; struct default_delete&lt;T[]&gt;;
13886 <del>template&lt;class T, size_t N&gt; struct default_delete&lt;T[N]&gt;;</del>
13887
13888 template&lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr;
13889 template&lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt;;
13890 <del>template&lt;class T, class D, size_t N&gt; class unique_ptr&lt;T[N], D&gt;;</del>
13891 ...
13892 </pre></blockquote>
13893
13894 <p>
13895 Remove the entire section 20.6.5.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete&lt;T[N]&gt;</tt></b>.
13896 </p>
13897
13898 <p>
13899 Remove the entire section 20.6.5.4 [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b>
13900 and its subsections: 20.6.5.4.1 [unique.ptr.compiletime.dtor], 20.6.5.4.2 [unique.ptr.compiletime.observers],
13901 20.6.5.4.3 [unique.ptr.compiletime.modifiers].
13902 </p>
13903
13904
13905
13906
13907
13908
13909 <hr>
13910 <h3><a name="741"></a>741. Const-incorrect <tt>get_deleter</tt> function for <tt>shared_ptr</tt></h3>
13911 <p><b>Section:</b> 20.6.6.2.11 [util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
13912  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-09-27</p>
13913 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
13914 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13915 <p><b>Discussion:</b></p>
13916 <p>
13917 The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
13918 </p>
13919
13920 <p>
13921 According to the recent draft N2369, both the header memory synopsis
13922 of 20.6 [memory] and 20.6.6.2.11 [util.smartptr.getdeleter] declare:
13923 </p>
13924
13925 <blockquote><pre>template&lt;class D, class T&gt; D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
13926 </pre></blockquote>
13927
13928 <p>
13929 This allows to retrieve the pointer to a mutable deleter of a <tt>const
13930 shared_ptr</tt> (if that owns one) and therefore contradicts the usual
13931 philosophy that associated functors are either read-only (e.g.
13932 <tt>key_comp</tt> or <tt>value_comp</tt> of <tt>std::map</tt>) or do at least reflect
13933 the mutability of the owner (as seen for the both overloads of
13934 <tt>unique_ptr::get_deleter</tt>).
13935 Even the next similar counter-part of <tt>get_deleter</tt> - the two
13936 overloads of <tt>function::target</tt> in the class template function
13937 synopsis 20.5.15.2 [func.wrap.func] or in 20.5.15.2.5 [func.wrap.func.targ] - do
13938 properly mirror the const-state of the owner.
13939 </p>
13940
13941 <b>Possible proposed resolutions:</b>
13942
13943 <p>
13944 Replace the declarations of <tt>get_deleter</tt> in the header <tt>&lt;memory&gt;</tt>
13945 synopsis of 20.6 [memory] and in 20.6.6.2.11 [util.smartptr.getdeleter] by one of the
13946 following alternatives (A) or (B):
13947 </p>
13948
13949 <ol type="A">
13950 <li>
13951 Provide <b>only</b> the immutable variant. This would reflect the
13952 current praxis of <tt>container::get_allocator()</tt>, <tt>map::key_comp()</tt>, or
13953 <tt>map::value_comp</tt>.
13954
13955 <blockquote><pre>template&lt;class D, class T&gt; const D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
13956 </pre></blockquote>
13957 </li>
13958 <li>
13959 Just remove the function.
13960 </li>
13961 </ol>
13962
13963 <p>
13964 Alberto Ganesh Barbati adds:
13965 </p>
13966
13967 <ol start="3" type="A">
13968 <li>
13969 <p>
13970 Replace it with two functions:
13971 </p>
13972 <blockquote><pre>template &lt;class D, class T&gt; D get_deleter(shared_ptr&lt;T&gt; const&amp;);
13973 template &lt;class D, class T&gt; bool has_deleter(shared_ptr&lt;T&gt; const&amp;);
13974 </pre></blockquote>
13975
13976 <p>
13977 The first one would throw if <tt>D</tt> is the wrong type, while the latter would
13978 never throw. This approach would reflect the current praxis of
13979 <tt>use_facet/has_facet</tt>, with the twist of returning the deleter by value as
13980 <tt>container::get_allocator()</tt> do.
13981 </p>
13982 </li>
13983 </ol>
13984
13985 <p>
13986 Peter Dimov adds:
13987 </p>
13988
13989 <blockquote>
13990 <p>
13991 My favorite option is "not a defect". A, B and C break useful code.
13992 </p>
13993 </blockquote>
13994
13995
13996
13997 <p><b>Proposed resolution:</b></p>
13998 <p>
13999 </p>
14000
14001
14002
14003
14004
14005 <hr>
14006 <h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3>
14007 <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#New">New</a>
14008  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p>
14009 <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>
14010 <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>
14011 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14012 <p><b>Discussion:</b></p>
14013 <p>
14014 This issue was split from <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#672">672</a> now just
14015 deals with changing the requirements of <tt>T</tt> in the <tt>Swappable</tt>
14016 requirement from <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> to
14017 <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
14018 </p>
14019
14020 <p>
14021 This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators.  Here
14022 is example code:
14023 </p>
14024
14025 <blockquote><pre>namespace Mine {
14026
14027 template &lt;class T&gt;
14028 struct proxy {...};
14029
14030 template &lt;class T&gt;
14031 struct proxied_iterator
14032 {
14033    typedef T value_type;
14034    typedef proxy&lt;T&gt; reference;
14035    reference operator*() const;
14036    ...
14037 };
14038
14039 struct A
14040 {
14041    // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
14042    void swap(A&amp;);
14043    ...
14044 };
14045
14046 void swap(A&amp;, A&amp;);
14047 void swap(proxy&lt;A&gt;, A&amp;);
14048 void swap(A&amp;, proxy&lt;A&gt;);
14049 void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);
14050
14051 }  // Mine
14052
14053 ...
14054
14055 Mine::proxied_iterator&lt;Mine::A&gt; i(...)
14056 Mine::A a;
14057 <b>swap(*i1, a);</b>
14058 </pre></blockquote>
14059
14060 <p>
14061 The key point to note in the above code is that in the call to <tt>swap</tt>, <tt>*i1</tt>
14062 and <tt>a</tt> are different types (currently types can only be <tt>Swappable</tt> with the
14063 same type).  A secondary point is that to support proxies, one must be able to pass rvalues
14064 to <tt>swap</tt>.  But note that I am not stating that the general purpose <tt>std::swap</tt>
14065 should accept rvalues!  Only that overloaded <tt>swap</tt>s, as in the example above, be allowed
14066 to take rvalues.
14067 </p>
14068
14069 <p>
14070 That is, no standard library code needs to change.  We simply need to have a more flexible
14071 definition of <tt>Swappable</tt>.
14072 </p>
14073
14074
14075
14076 <p><b>Proposed resolution:</b></p>
14077 <p>
14078 Change 20.1.1 [utility.arg.requirements]:
14079 </p>
14080
14081 <blockquote>
14082
14083 <p>
14084 -1- The template definitions in the C++ Standard Library refer to various
14085 named requirements whose details are set out in tables 31-38. In these
14086 tables, <tt>T</tt> <ins>and <tt>V</tt> are</ins> <del>is a</del> type<ins>s</ins> to be supplied by a C++ program
14087 instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
14088 values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
14089 lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
14090 <tt>const</tt>) <tt>T</tt>; <del>and</del> <tt>rv</tt> is a non-<tt>const</tt>
14091 rvalue of type <tt>T</tt><ins>; <tt>w</tt> is a value of type <tt>T</tt>; and <tt>v</tt> is a value of type <tt>V</tt></ins>.
14092 </p>
14093
14094 <table border="1">
14095 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
14096 <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
14097 <tr><td><tt>swap(<del>s</del><ins>w</ins>,<del>t</del><ins>v</ins>)</tt></td><td><tt>void</tt></td>
14098 <td><del><tt>t</tt></del><ins><tt>w</tt></ins> has the value originally
14099 held by <del><tt>u</tt></del><ins><tt>v</tt></ins>, and
14100 <del><tt>u</tt></del><ins><tt>v</tt></ins> has the value originally held
14101 by <del><tt>t</tt></del><ins><tt>w</tt></ins></td></tr>
14102 <tr><td colspan="3">
14103 <p>
14104 The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
14105 </p>
14106 <ul>
14107 <li>
14108 <tt>T</tt> is <tt>Swappable</tt> if <ins><tt>T</tt> and <tt>V</tt> are
14109 the same type and </ins> <tt>T</tt> satisfies the
14110 <del><tt>CopyConstructible</tt></del>
14111 <ins><tt>MoveConstructible</tt></ins> requirements (Table <del>34</del>
14112 <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del>
14113 <ins><tt>MoveAssignable</tt></ins> requirements (Table <del>36</del>
14114 <ins>35</ins>);
14115 </li>
14116 <li>
14117 <tt>T</tt> is <tt>Swappable</tt> <ins>with <tt>V</tt></ins> if a namespace scope function named
14118 <tt>swap</tt> exists in the same namespace as the definition of
14119 <tt>T</tt> <ins>or <tt>V</tt></ins>, such that the expression
14120 <tt>swap(<del>t</del><ins>w</ins>,<del>u</del> <ins>v</ins>)</tt> is valid and has the
14121 semantics described in this table.
14122 </li>
14123 </ul>
14124 </td></tr>
14125 </tbody></table>
14126 </blockquote>
14127
14128
14129
14130
14131
14132
14133 <hr>
14134 <h3><a name="743"></a>743. rvalue <tt>swap</tt> for <tt>shared_ptr</tt></h3>
14135 <p><b>Section:</b> 20.6.6.2.9 [util.smartptr.shared.spec] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14136  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p>
14137 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14138 <p><b>Discussion:</b></p>
14139 <p>
14140 When the LWG looked at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a> in Kona the following note was made:
14141 </p>
14142
14143 <blockquote><p>
14144 We may need to open an issue to deal with the question of
14145 whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
14146 </p></blockquote>
14147
14148 <p>
14149 This issue was opened in response to that note.
14150 </p>
14151
14152 <p>
14153 I believe allowing rvalue <tt>shared_ptr</tt>s to <tt>swap</tt> is both
14154 appropriate, and consistent with how other library components are currently specified.
14155 </p>
14156
14157
14158
14159 <p><b>Proposed resolution:</b></p>
14160 <p>
14161 Change the synopsis in 20.6.6.2 [util.smartptr.shared]:
14162 </p>
14163
14164 <blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
14165 ...
14166 template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
14167 <ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
14168 template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
14169 </pre></blockquote>
14170
14171 <p>
14172 Change 20.6.6.2.4 [util.smartptr.shared.mod]:
14173 </p>
14174
14175 <blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
14176 </pre></blockquote>
14177
14178 <p>
14179 Change 20.6.6.2.9 [util.smartptr.shared.spec]:
14180 </p>
14181
14182 <blockquote><pre>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
14183 <ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
14184 template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
14185 </pre></blockquote>
14186
14187
14188
14189
14190
14191 <hr>
14192 <h3><a name="744"></a>744. What is the lifetime of an exception pointed to by an exception_ptr?</h3>
14193 <p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14194  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
14195 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
14196 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
14197 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14198 <p><b>Discussion:</b></p>
14199 <p>
14200 Without some lifetime guarantee, it is hard to know how this type can be
14201 used. &nbsp;Very specifically, I don't see how the current wording would
14202 guarantee and exception_ptr caught at the end of one thread could be safely
14203 stored and rethrown in another thread - the original motivation for this
14204 API.
14205 </p>
14206 <p>
14207 (Peter Dimov agreed it should be clearer, maybe a non-normative note to
14208 explain?)
14209 </p>
14210
14211
14212 <p><b>Proposed resolution:</b></p>
14213 <p>
14214 </p>
14215
14216
14217
14218
14219
14220 <hr>
14221 <h3><a name="745"></a>745. copy_exception API slices.</h3>
14222 <p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14223  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
14224 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
14225 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
14226 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14227 <p><b>Discussion:</b></p>
14228 <p>
14229 It could be I did not understand the design rationale, but I thought
14230 copy_exception would produce an exception_ptr to the most-derived (dynamic)
14231 type of the passed exception. &nbsp;Instead it slices, which appears to be less
14232 useful, and a likely source of FAQ questions in the future.
14233 </p>
14234 <p>
14235 (Peter Dimov suggests NAD)
14236 </p>
14237
14238
14239 <p><b>Proposed resolution:</b></p>
14240 <p>
14241 </p>
14242
14243
14244
14245
14246
14247 <hr>
14248 <h3><a name="746"></a>746. current_exception may fail with bad_alloc</h3>
14249 <p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14250  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
14251 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
14252 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
14253 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14254 <p><b>Discussion:</b></p>
14255 <p>
14256 I understand that the attempt to copy an exception may run out of memory,
14257 but I believe this is the only part of the standard that mandates failure
14258 with specifically <tt>bad_alloc</tt>, as opposed to allowing an
14259 implementation-defined type derived from <tt>bad_alloc</tt>. &nbsp;For instance, the Core
14260 language for a failed new expression is:
14261 </p>
14262 <blockquote>
14263 <p>
14264 Any other allocation function that fails to allocate storage shall indicate
14265 failure only by throwing an exception of a type that would match a handler
14266 (15.3) of type <tt>std::bad_alloc</tt> (18.5.2.1).
14267 </p>
14268 </blockquote>
14269 <p>
14270 I think we should allow similar freedom here (or add a blanket
14271 compatible-exception freedom paragraph in 17)
14272 </p>
14273 <p>
14274 I prefer the clause 17 approach myself, and maybe clean up any outstanding
14275 wording that could also rely on it.
14276 </p>
14277
14278
14279 <p><b>Proposed resolution:</b></p>
14280 <p>
14281 </p>
14282
14283
14284
14285
14286
14287 <hr>
14288 <h3><a name="747"></a>747. We have 3 separate type traits to identify classes supporting no-throw operations</h3>
14289 <p><b>Section:</b> 20.4.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14290  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
14291 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
14292 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
14293 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14294 <p><b>Discussion:</b></p>
14295 <p>
14296 We have 3 separate type traits to identify classes supporting no-throw
14297 operations, which are very useful when trying to provide exception safety
14298 guarantees. &nbsp;However, I'm not entirely clear on what the current wording
14299 requires of a conforming implementation. &nbsp;To quote from
14300 <tt>has_nothrow_default_constructor</tt>:
14301 </p>
14302 <blockquote><p>
14303 or <tt>T</tt> is a class type with a default constructor that is known not to throw
14304 any exceptions
14305 </p></blockquote>
14306 <p>
14307 What level of magic do we expect to deduce if this is known?
14308 </p>
14309 <p>
14310 E.g.
14311 </p>
14312
14313 <blockquote><pre>struct test{
14314 &nbsp;int x;
14315 &nbsp;test() : x() {}
14316 };
14317 </pre></blockquote>
14318 <p>
14319 Should I expect a conforming compiler to
14320 &nbsp;<tt>assert( has_nothrow_constructor&lt;test&gt;::value )</tt>
14321 </p>
14322 <p>
14323 Is this a QoI issue?
14324 </p>
14325 <p>
14326 Should I expect to 'know' only if-and-only-if there is an inline definition
14327 available?
14328 </p>
14329 <p>
14330 Should I never expect that to be true, and insist that the user supplies an
14331 empty throw spec if they want to assert the no-throw guarantee?
14332 </p>
14333 <p>
14334 It would be helpful to maybe have a footnote explaining what is required,
14335 but right now I don't know what to suggest putting in the footnote.
14336 </p>
14337 <p>
14338 (agreement since is that trivial ops and explicit no-throws are required.
14339 Open if QoI should be allowed to detect further)
14340 </p>
14341
14342
14343 <p><b>Proposed resolution:</b></p>
14344 <p>
14345 </p>
14346
14347
14348
14349
14350
14351 <hr>
14352 <h3><a name="748"></a>748. The is_abstract type trait is defined by reference to 10.4.</h3>
14353 <p><b>Section:</b> 20.4.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14354  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
14355 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
14356 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
14357 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14358 <p><b>Discussion:</b></p>
14359 <p>
14360 I am trying to decide is a pure virtual function is a <i>necessary</i> as well as
14361 sufficient requirement to be classified as abstract?
14362 </p>
14363 <p>
14364 For instance, is the following (non-polymorphic) type considered abstract?
14365 </p>
14366 <blockquote><pre>struct abstract {
14367 protected:
14368 &nbsp;abstract(){}
14369 &nbsp;abstract( abstract const &amp; ) {}
14370 &nbsp;~abstract() {}
14371 };
14372 </pre></blockquote>
14373 <p>
14374 (Suggested that this may be NAD, with an editorial fix-up from Pete on the
14375 core wording to make clear that abstract requires a pure virtual function)
14376 </p>
14377
14378
14379 <p><b>Proposed resolution:</b></p>
14380 <p>
14381 </p>
14382
14383
14384
14385
14386
14387 <hr>
14388 <h3><a name="749"></a>749. Currently <tt>has_nothrow_copy_constructor&lt;T&gt;::value</tt> is true if T has 'a' nothrow copy constructor.</h3>
14389 <p><b>Section:</b> 20.4.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14390  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
14391 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
14392 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
14393 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14394 <p><b>Discussion:</b></p>
14395 <p>
14396 Unfortunately a class can have multiple copy constructors, and I believe to
14397 be useful this trait should only return true is ALL copy constructors are
14398 no-throw.
14399 </p>
14400 <p>
14401 For instance:
14402 </p>
14403 <blockquote>
14404 <pre>struct awkward {
14405 &nbsp;awkward( const awkward &amp; ) throw() {}
14406 &nbsp;awkward( awkward &amp; ) { throw "oops"; } };
14407 </pre>
14408 </blockquote>
14409
14410
14411 <p><b>Proposed resolution:</b></p>
14412 <p>
14413 </p>
14414
14415
14416
14417
14418
14419 <hr>
14420 <h3><a name="750"></a>750. The current definition for <tt>is_convertible</tt> requires that the type be
14421 implicitly convertible, so explicit constructors are ignored.</h3>
14422 <p><b>Section:</b> 20.4.5 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14423  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
14424 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14425 <p><b>Discussion:</b></p>
14426 <p>
14427 With the pending arrival of explicit conversion functions though, I'm
14428 wondering if we want an additional trait, <tt>is_explictly_convertible</tt>?
14429 </p>
14430
14431
14432 <p><b>Proposed resolution:</b></p>
14433 <p>
14434 </p>
14435
14436
14437
14438
14439
14440 <hr>
14441 <h3><a name="751"></a>751. change pass-by-reference members of <tt>vector&lt;bool&gt;</tt> to pass-by-value?</h3>
14442 <p><b>Section:</b> 23.2.6 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14443  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
14444 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14445 <p><b>Discussion:</b></p>
14446 <p>
14447 A number of vector&lt;bool&gt; members take const bool&amp; as arguments.
14448 Is there any chance we could change them to pass-by-value or would I
14449 be wasting everyone's time if wrote up an issue?
14450 </p>
14451
14452
14453 <p><b>Proposed resolution:</b></p>
14454 <p>
14455 </p>
14456
14457
14458
14459
14460
14461 <hr>
14462 <h3><a name="752"></a>752. Allocator complexity requirement</h3>
14463 <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#New">New</a>
14464  <b>Submitter:</b> Hans Boehm <b>Date:</b> 2007-10-11</p>
14465 <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>
14466 <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>
14467 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14468 <p><b>Discussion:</b></p>
14469 <p>
14470 Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations
14471 on the allocators are expected to be amortized constant time."?
14472 </p>
14473 <p>
14474 As I think I pointed out earlier, this is currently fiction for
14475 <tt>allocate()</tt> if it has to obtain memory from the OS, and it's unclear to
14476 me how to interpret this for <tt>construct()</tt> and <tt>destroy()</tt> if they deal with
14477 large objects. &nbsp;Would it be controversial to officially let these take
14478 time linear in the size of the object, as they already do in real life?
14479 </p>
14480 <p>
14481 <tt>Allocate()</tt> more blatantly takes time proportional to the size of the
14482 object if you mix in GC. &nbsp;But it's not really a new problem, and I think
14483 we'd be confusing things by leaving the bogus requirements there. &nbsp;The
14484 current requirement on <tt>allocate()</tt> is generally not important anyway,
14485 since it takes O(size) to construct objects in the resulting space.
14486 There are real performance issues here, but they're all concerned with
14487 the constants, not the asymptotic complexity.
14488 </p>
14489
14490
14491 <p><b>Proposed resolution:</b></p>
14492 <p>
14493 Change 20.1.2 [allocator.requirements]/2:
14494 </p>
14495
14496 <blockquote>
14497 <p>
14498 -2- Table 39 describes the requirements on types manipulated through
14499 allocators. All the operations on the allocators are expected to be
14500 amortized constant time<ins>, except that <tt>allocate</tt> and
14501 <tt>construct</tt> may require time proportional to the size of the
14502 object allocated or constructed</ins>. Table 40 describes the
14503 requirements on allocator types.
14504 </p>
14505 </blockquote>
14506
14507
14508
14509
14510
14511 <hr>
14512 <h3><a name="753"></a>753. Move constructor in draft</h3>
14513 <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#New">New</a>
14514  <b>Submitter:</b> Yechezkel Mett <b>Date:</b> 2007-10-14</p>
14515 <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>
14516 <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>
14517 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14518 <p><b>Discussion:</b></p>
14519 <p>
14520 The draft standard n2369 uses the term <i>move constructor</i> in a few
14521 places, but doesn't seem to define it.
14522 </p>
14523
14524 <p>
14525 <tt>MoveConstructible</tt> requirements are defined in Table 33 in 20.1.1 [utility.arg.requirements] as
14526 follows:
14527 </p>
14528
14529 <blockquote>
14530 <table border="1">
14531 <caption><tt>MoveConstructible</tt> requirements</caption>
14532 <tbody><tr>
14533 <th>expression</th> <th>post-condition</th>
14534 </tr>
14535 <tr>
14536 <td><tt>T t = rv</tt></td> <td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
14537 </tr>
14538 <tr>
14539 <td colspan="2">[<i>Note:</i> There is no requirement on the value of <tt>rv</tt> after the
14540 construction. <i>-- end note</i>]</td>
14541 </tr>
14542 </tbody></table>
14543 </blockquote>
14544
14545 <p>
14546 (where <tt>rv</tt> is a non-const rvalue of type <tt>T</tt>).
14547 </p>
14548
14549 <p>
14550 So I assume the move constructor is the constructor that would be used
14551 in filling the above requirement.
14552 </p>
14553
14554 <p>
14555 For <tt>vector::reserve</tt>, <tt>vector::resize</tt> and the <tt>vector</tt> modifiers given in
14556 23.2.5.4 [vector.modifiers] we have
14557 </p>
14558
14559 <blockquote>
14560 <i>Requires:</i> If <tt>value_type</tt> has a move constructor, that constructor shall
14561 not throw any exceptions.
14562 </blockquote>
14563
14564 <p>
14565 Firstly "If <tt>value_type</tt> has a move constructor" is superfluous; every
14566 type which can be put into a <tt>vector</tt> has a move constructor (a copy
14567 constructor is also a move constructor). Secondly it means that for
14568 any <tt>value_type</tt> which has a throwing copy constructor and no other move
14569 constructor these functions cannot be used -- which I think will come
14570 as a shock to people who have been using such types in <tt>vector</tt> until
14571 now!
14572 </p>
14573
14574 <p>
14575 I can see two ways to correct this. The simpler, which is presumably
14576 what was intended, is to say "If <tt>value_type</tt> has a move constructor and
14577 no copy constructor, the move constructor shall not throw any
14578 exceptions" or "If <tt>value_type</tt> has a move constructor which changes the
14579 value of its parameter,".
14580 </p>
14581
14582 <p>
14583 The other alternative is add to <tt>MoveConstructible</tt> the requirement that
14584 the expression does not throw. This would mean that not every type
14585 that satisfies the <tt>CopyConstructible</tt> requirements also satisfies the
14586 <tt>MoveConstructible</tt> requirements. It would mean changing requirements in
14587 various places in the draft to allow either <tt>MoveConstructible</tt> or
14588 <tt>CopyConstructible</tt>, but I think the result would be clearer and
14589 possibly more concise too.
14590 </p>
14591
14592
14593 <p><b>Proposed resolution:</b></p>
14594 <p>
14595 </p>
14596
14597
14598
14599
14600
14601 <hr>
14602 <h3><a name="754"></a>754. Ambiguous return clause for <tt>std::uninitialized_copy</tt></h3>
14603 <p><b>Section:</b> 20.6.4.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14604  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-10-15</p>
14605 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#uninitialized.copy">active issues</a> in [uninitialized.copy].</p>
14606 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p>
14607 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14608 <p><b>Discussion:</b></p>
14609 <p>
14610 14882-2003, [lib.uninitialized.copy] is currently written as follows:
14611 </p>
14612
14613 <blockquote>
14614 <pre>template &lt;class InputIterator, class ForwardIterator&gt;
14615   ForwardIterator uninitialized_copy(InputIterator <i>first</i>, InputIterator <i>last</i>,
14616                                      ForwardIterator <i>result</i>);
14617 </pre>
14618 <blockquote>
14619 <p>
14620 -1- <i>Effects:</i>
14621 </p>
14622 <blockquote><pre>for (; first != last; ++result, ++first)
14623   new (static_cast&lt;void*&gt;(&amp;*result))
14624     typename iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
14625 </pre></blockquote>
14626 <p>
14627 -2- <i>Returns:</i> <tt><i>result</i></tt>
14628 </p>
14629 </blockquote>
14630 </blockquote>
14631
14632 <p>
14633 similarily for N2369, and its corresponding section
14634 20.6.4.1 [uninitialized.copy].
14635 </p>
14636
14637 <p>
14638 It's not clear to me what the return clause is supposed to mean, I see
14639 two
14640 possible interpretations:
14641 </p>
14642
14643 <ol type="a">
14644 <li>
14645 The notion of <tt><i>result</i></tt> is supposed to mean the value given by the
14646 function parameter <tt><i>result</i></tt> [Note to the issue editor: Please use italics for
14647 <tt><i>result</i></tt>].
14648 This seems somewhat implied by recognizing that both the function
14649 parameter
14650 and the name used in the clause do have the same italic font.
14651 </li>
14652 <li>
14653 The notion of "result" is supposed to mean the value of <tt><i>result</i></tt>
14654 after the
14655 preceding effects clause. This is in fact what all implementations I
14656 checked
14657 do (and which is probably it's intend, because it matches the
14658 specification of <tt>std::copy</tt>).
14659 </li>
14660 </ol>
14661
14662 <p>
14663 The problem is: I see nothing in the standard which grants that this
14664 interpretation
14665 is correct, specifically [lib.structure.specifications] or
14666 17.3.1.3 [structure.specifications]
14667 resp. do not clarify which "look-up" rules apply for names found in
14668 the elements
14669 of the detailed specifications - Do they relate to the corresponding
14670 synopsis or
14671 to the effects clause (or possibly other elements)? Fortunately most
14672 detailed
14673 descriptions are unambigious in this regard, e.g. this problem does
14674 not apply
14675 for <tt>std::copy</tt>.
14676 </p>
14677
14678
14679
14680 <p><b>Proposed resolution:</b></p>
14681 <p>
14682 Change the wording of the return clause to say (20.6.4.1 [uninitialized.copy]):
14683 </p>
14684
14685 <blockquote>
14686 <p>
14687 -2- <i>Returns:</i> <ins>The value of</ins> <tt><i>result</i></tt> <ins>after effects have taken place.</ins>
14688 </p>
14689 </blockquote>
14690
14691
14692
14693
14694
14695
14696 </body></html>